Wikipedia:Village pump (all)

From Wikipedia, the free encyclopedia
Jump to: navigation, search

This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.

Click here to purge the server cache of this page (to see recent changes on Village pump subpages)


Village pump sections

Edit-find-replace.svg
Policy
watch
To discuss existing and proposed policies

Preferences-system.svg
Technical
watch
To discuss technical issues. For wiki software bug reports, use Phabricator

Dialog-information on.svg
Proposals
watch
To discuss new proposals that are not policy-related. See also: perennial proposals.

Tools-hammer.svg
Idea lab
watch
To discuss ideas before proposing them to the community and attempt to find solutions to issues

Help-browser.svg
Miscellaneous
watch
To post messages that do not fit into any other category

View all village pump sections at once

Other help and discussion locations
I want... Where to go
...help using Wikipedia Help desk
...to find my way around Wikipedia Department directory
...specific facts (e.g. Who was the first pope?) Reference desk
...constructive criticism from others for a specific article Peer review
...help resolving a specific article edit dispute or making a user conduct dispute complaint  Requests for comment
...to comment on a specific article Article's talk page
...to view other Wikimedia projects Wikimedia Meta-Wiki
...to learn about citing Wikipedia in a bibliography Citing Wikipedia
...to report sites that copy Wikipedia content Mirrors and forks
...to ask questions or make comments Questions


Contents

Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).

Policy

Why is the copyright license described in two different ways?

Recently there was a discussion on meta at meta:Terms of use/Creative Commons 4.0 about updating the Wikimedia Foundation Terms of Use for Wikimedia projects to use the updated version of the Creative Commons license, 4.0 instead of 3.0 as currently used.

While reading up on that I noticed that English Wikipedia uses two different descriptions of the copyright license. Anyone contributing to Wikipedia has to "irrevocably agree to release your contribution under the CC BY-SA 3.0 License and the GFDL". To see this text, go to any place on Wikipedia, click edit or edit source at the top of the screen, then scroll to the bottom above the "save" button. There actually are two text editors - one with source code and one that is WYSIWYG, but both of them prominently feature this text.

The second place is at the bottom of every Wikipedia article. This is much more prominent, because whereas the other place is seen by editors, this place is seen by everyone. Scroll to the bottom of any Wikipedia article and see where it says, "Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply."

I find it surprising that there is one sort of text to which editors agree when they make submissions, but another text is presented on all pages for readers. Presumably since everything readers access went through the submission process, the two places should have matching text. However, the reader space only notes the CC license, whereas the submission space requires agreement to dual licensing. I do not know how or why these texts came to be different.

Wikipedia has used the dual licensing system of "Creative Commons plus GNU Free Documentation License" for a long time and I wonder how it came to be that the GFDL license is not presented to Wikipedia readers, whereas the CC license is. Does anyone have any insight on how this came to be? This might be a bigger issue than English Wikipedia but I thought I would ask here first. Thanks. Blue Rasberry (talk) 19:53, 22 November 2016 (UTC)

Everything on Wikipedia is available under CC-BY-SA, but not all of it is available under the GFDL. If you want to add some text copied from elsewhere which is available under CC-BY-SA but not under the GFDL then that is absolutely fine, as long as you mark it as such. You can't add GFDL-only material unless it was added to Wikipedia prior to the introduction of CC-BY-SA. CC-BY-SA is definitely our preferred licence and is more suitable for our type of content, I expect that's why it's the only one shown to readers. GFDL is essentially there for historical reasons. Hut 8.5 11:03, 24 November 2016 (UTC)
Hut 8.5 Thanks for replying. I have the impression that what you just said is what many regular Wikipedia contributors believe, and that most people would be surprised if that were not the case.
But can you please look again, and please confirm whether what you just wrote is really accurate? You just wrote, "Everything on Wikipedia is available under CC-BY-SA, but not all of it is available under the GFDL." Can you comment on how that reconciles with the agreement above the "save" button, which says, "By saving changes, you agree to the Terms of Use, and you irrevocably agree to release your contribution under the CC BY-SA 3.0 License and the GFDL"? I have never seen anyone contest the GFDL release for the save button, and I am not even sure that is possible. What reason do you have to believe that less than 100% of current Wikipedia contributions are not dual licensed with GFDL and CC-By? It seems to me that all user-submitted content, at least since the 2009 dual-licensing scheme, has been GFDL licensed along with CC, which makes it a present concern and not something historical.
Again - I will confirm that there is a popular understanding in circulation that matches what you just described. I feel so unsure about things that I am seeking other perspectives. I am not surprised that you said what you said, but I wonder if that perspective is a correct one and if so, how that can be considering that I do not see a path into Wikipedia except with a GFDL license. Thanks for any further comment you can give. Blue Rasberry (talk) 18:44, 28 November 2016 (UTC)
The factor you're overlooking is that the text above the save button only applies to text you wrote (or otherwise hold the rights to). If you copy text from somewhere which was written by someone else and which is only available under CC-BY-SA then you can't make it available under the GFDL by clicking the Save Changes button because you don't own the rights to it in the first place. Doing this is perfectly acceptable as long as you clearly mark the text. Hut 8.5 19:30, 28 November 2016 (UTC)
Hut 8.5 I know that this is done, but it is done rarely, and I still do not see how that practice is reconciled with the submission requirement that "you irrevocably agree to release your contribution under the CC BY-SA 3.0 License and the GFDL". I am not aware of discussion about why there should be a different requirement for when someone posts their own content versus when they post someone else's. (still strange, but at meta:Licensing_update/Questions_and_Answers#Replacing_GFDL_with_CC-BY-SA.3F it says, "with the exception of CC-BY-SA-only additions from external sources". As Hut 8.5 said and RP88 suggests below, this is a path for content to enter Wikipedia without dual licensing. Blue Rasberry (talk) 13:37, 29 November 2016 (UTC))
I know that the policy around posting open license content into Wikipedia is shaky because I contributed to a new guide just started a few months ago called Wikipedia:Adding open license text to Wikipedia. So far as I know, the new suggestions posted there are the only guidance posted anywhere in English Wikipedia. I think that the newness of the "adding text" policy is supporting evidence that this is rarely done. I was unable to find many people posting text into Wikipedia when that policy was being developed. Because of that (striken following Isaacl's post with links. Blue Rasberry (talk) 13:40, 29 November 2016 (UTC)), I expect that practically all English Wikipedia content is submitted with dual licensing because it is so unusual to post open text into Wikipedia.
Do you have a guess about how much content is posted in a way that is not dual licensed? Do you think it is 1%? 5%? 10%? Blue Rasberry (talk) 20:01, 28 November 2016 (UTC)
If you haven't already seen it, here is the related licensing update page, which links to the corresponding licensing update page on meta Wikipedia that describes the motivation. There is also a questions and answers page on meta. isaacl (talk) 00:12, 29 November 2016 (UTC)
Regarding existing guidance on reusing text from other sources, if you haven't seen it already, there is Wikipedia:FAQ/Copyright#Can I add something to Wikipedia that I got from somewhere else.3F. isaacl (talk) 17:01, 29 November 2016 (UTC)
I don't know a percentage, there are at least ~700 articles that are not dual-licensed and can only be used under CC-BY-SA 3.0. You can find some by looking at Category:Articles with imported Creative Commons Attribution-ShareAlike 3.0 text. Relevant templates include {{CCBYSASource}}, {{CC-notice}}, and possibly other text attribution templates. —RP88 (talk) 01:20, 29 November 2016 (UTC)
Thanks for sharing. I had not seen this kind of article tagging. That is insightful.
700 articles out of 5,000,000+ total is not many. Also, I browsed the articles in that category, and it seems that many of them are mixed with dual-licensed text such that parts of the article do have dual licensing. If there were 50,000 articles then that would be 1%. If there are only a few collections like this of one-license content, then it seems to me that most of Wikipedia's content is dual-licensed. Blue Rasberry (talk) 22:42, 29 November 2016 (UTC)

Present statements - propose change

I think these statements are correct.

  1. The majority of text on English Wikipedia - likely more than 90% - is dual licensed with CC and GFDL
  2. The majority of incoming submissions to English Wikipedia - likely more than 90% - is dual licensed with CC and GFDL
  3. The notice to readers on English Wikipedia says that the text is CC licensed, but not GFDL licensed

@Isaacl, RP88, and Hut 8.5: - I am guessing about the 90% number. I think the truth is closer to 99%+, but 90% seems safe and anything less than 51% seems implausible to me. Would any of you doubt the accuracy of any of these statements?

Assuming that these statements are correct, I would like to advocate that the copyright notice change from "Text is available under the Creative Commons Attribution-ShareAlike License" to that, plus "and the GFDL". I feel that the text for submission should be reconciled with the text for reading. I think that Wikipedia's copyright notice should be aligned with the majority of content, and since the majority of content is dual licensed, then that is how the copyright notice should read. The truth of situation is more complicated, but it is more correct more often to say CC+GFDL than to say CC only.

Am I missing something here? Is there a counterpoint to this? Am I wrong on some premise? Blue Rasberry (talk) 22:42, 29 November 2016 (UTC)

Just a note, the copyright footer can be found at MediaWiki:Wikimedia-copyright. Unless something has changed, all copyright related notices like these cannot just be changed without approval from WMF-Legal. If this is going to happen you are going to need to notify someone. User:Mdennis (WMF) is probably a good start as she would be able to get in touch with the proper people. --Majora (talk) 22:49, 29 November 2016 (UTC)
  • Not sure it's a good idea to put legal text on lots of pages which is factually incorrect, although I suppose we could use something like "and unless otherwise noted the GFDL". But yes this text shouldn't be changed without consultation with WMF Legal. Hut 8.5 07:24, 30 November 2016 (UTC)
I think the existing notice ”Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. See Terms of Use for details“ is fine. The phrase "Text is available under the Creative Commons Attribution-ShareAlike License” accurately states WMF's intention that all text should be CC-BY-SA licensed and the phrase “additional terms may apply" accommodates both cases in which rights are further restricted (such as short quotations of non-free text) as well as cases in which rights are more expansive (such as the common case that most text on en.WP is also available under the GFDL). The Terms of Use carefully identifies both category of cases. —RP88 (talk) 10:55, 30 November 2016 (UTC)
Thanks for the comments everyone.
@Majora: Thanks for the link to that MediaWiki page here on English Wikipedia. I did not know where to find that. I posted a similar comment there to ask for more information. Yes, if there is to be a change, then WMF legal would have to approve it.
@Hut 8.5: I confirm, it would be incorrect to say that all 5 million articles have GFDL licenses. However, I think it is true for all but somewhere between 100-5000 of them, so it is almost always true. I imagined that the CC license and GFDL were of equal value when they apply. If they are of equal value, then perhaps there are 5 million problems in not list both, versus only 5000 problems by mistakenly listing both in the rare cases where only one applies. As soon as a human or bot touches any article with a copyrightable edit, then immediately that article has GFDL licensed components. It might be the case that there are 0 articles with only CC licensing; I am not sure.
@RP88: Some of what you say seems right, but if we omit one brand name, then why not omit all? We could say, "Text is available under a free and open license; additional terms may apply". If we list one brand of license, and actually two apply, then does that mean that one license is less relevant as compared to the other? Giving credit to both seems like such a small thing. Why was it decided to omit the GFDL?
Thanks. I still am not clear on what happened, but I appreciate everything shared until now. Everything that everyone here seems reasonable, but I am still thinking about this. If anyone thinks they have another perspective or insight then I still would like to learn more. Blue Rasberry (talk) 23:31, 6 December 2016 (UTC)
The GFDL was designed for printed software manuals and so has provisions that are burdensome in the context of a wiki. For strong proponents of the GFDL, these provisions are important; for others, CC BY-SA is more permissive and thus more flexible in how it permits reuse. So whether or not promoting the use of GFDL on a equal basis is a good thing depends on how you feel about the GFDL.
Regarding "As soon as a human ... touches any article with a copyrightable edit": since contributions are released on a dual-licensed basis, someone can still re-use that edit in another work that is solely CC BY-SA. The re-user is free to pick either license. isaacl (talk) 03:25, 7 December 2016 (UTC)

Requested edit filter No emoji's in edit summaries

withdrawn

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.

I am opening this thread to gain consensus for an edit filter I requested "No emoji's in edit summaries". I have to admit I'm not very good at sponsoring or formatting these types of discussions, so any help in that regards will be appreciated. It's mentioned at the filter request that this topic might require new or changed policy, hence the use of this venue. - Mlpearc (open channel) 18:24, 30 November 2016 (UTC)

Discussion

  • @Mlpearc: Please clarify. The edit you used as an example at WP:EF/R was by an anonymous user. Due to significant disruption, there is already a filter disallowing the addition of emojis in wikitext by unconfirmed users, so we could just as easily check edit summaries as well. Why do we need to disallow it from all users? The point should to prevent disruption MusikAnimal talk 19:12, 30 November 2016 (UTC)
    @MusikAnimal: The All users is just due to I have no idea about the structure of filters, preventing disruption is my goal. - Mlpearc (open channel) 19:28, 30 November 2016 (UTC)
    @Mlpearc: If you just want to prevent disruption, I recommend you self-close this proposal. We can target the disruption without the controversial blanket all-user disallowing of emojis MusikAnimal talk 19:33, 30 November 2016 (UTC)
    This would be my preference - there is no need to disallow emojis across the board, only where there has been disruption -- samtar talk or stalk 19:16, 30 November 2016 (UTC)

Support

Oppose

  • While I find the idea of using emojis in edit summaries somewhat silly, this proposal needs an actual rationale - "it's silly" on its own is not a rationale for anything. Jo-Jo Eumerus (talk, contributions) 19:18, 30 November 2016 (UTC)
@Jo-Jo Eumerus: where did I say "silly" ? I can not find it. My rational is in my filter request Seems more disruptive and unnecessary than useful or needed - Mlpearc (open channel) 19:24, 30 November 2016 (UTC)
@Mlpearc: I was referring to my own somewhat silly, sorry. I am not convinced it's disruptive enough to merit any kind of countermeasure, really. And "not needed" is never on its own a reason for anything. Jo-Jo Eumerus (talk, contributions) 19:29, 30 November 2016 (UTC)
  • Strong oppose: emoji are legitimate means of textual communication as standardised in Unicode. No reason has been presented by the proposer other than "seems more disruptive and unnecesary than useful or needed". Your subjective opinion of what characters are useful to type is not a valid basis for policy change. You have presented no evidence that sufficient disruption is associated with emoji in edit summaries that the collateral damage of blocking such edits would be valid, and you have presented no argument that emoji in edit summaries are inherently disruptive. Hint: you can't, because, for example, my edit summary in this edit is not disruptive and describes my edit, because it makes me sad you have proposed this. Also you say edit summaries "are supposed to describe an edit not how you feel, that's what talk pages are for": edits on talk pages can involve expressing feelings, so that is a potential use case for emoji according to your own standard. Why do you want to ban something that does no harm and might bring a little bit of harmless fun? BethNaught (talk) 19:22, 30 November 2016 (UTC)
@BethNaught: I agree, as I said earlier, Just for the record, I do like emoji's and use them all the time, on IRC, talk page discussions and texting, I do have issues when used in edit summaries (which are supposed to describe an edit not how you feel, that's what talk pages are for) and I don't like them in usernames either, but I'll bite my tongue on that for now. - Mlpearc (open channel) 19:30, 30 November 2016 (UTC)
With what do you agree? It is your vagueness that has caused this fuss. If you want to ban emoji only in certain circumstances, amend your proposal now with specific circumstances for a ban and evidence why it is necessary. So far you have not done either. BethNaught (talk) 19:35, 30 November 2016 (UTC)
@BethNaught: "emoji are legitimate means of textual communication as standardised in Unicode" - Mlpearc (open channel) 19:42, 30 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.

WP:GNG and WP:BASIC

If I am correct, then WP:GNG and WP:BASIC are the first pillar of notability.

Unfortunately many schools, colleges and universities are kept in WP:AFD with the excuse WP:SCHOOLOUTCOMES. Some schools and universities established less than a year ago. They don't have any third party independent reviews. They fail every criteria of (WP:GNG) WP:BASIC.

Whereas some sportsperson who has got media coverage in major newspapers and the articles published discuss the person as a heading (not a passing mention in one line), but editors vote delete as they don't pass individual criteria of Wikipedia:Notability (sports). Some of them are junior level players who participate in world championships. Even if they pass WP:GNG, but fail the community set criteria of those particular sports. --Marvellous Spider-Man 04:10, 1 December 2016 (UTC) .

WP:BASIC applies to people, not institutions. If you have come here to argue against schools, without bothering to understand the policies you cite, you're on even more of a hiding to nothing than you were already on. You disagree with school article retention? Fine. Others do not. They'll not be convinced by you here, I think, so at best you're tilting at windmills. --Tagishsimon (talk) 04:20, 1 December 2016 (UTC)
Corrected. Marvellous Spider-Man 04:42, 1 December 2016 (UTC)
Regarding the sports-specific notability guidelines, they do not supplant the general notability guideline. If someone meets the general notability guideline, then the standard for inclusion in Wikipedia is met, regardless of the sports-related guidelines. This is discussed in the first paragraph of Wikipedia:Notability (sports), in bold, the second paragraph of the section "Applicable policies and guidelines", as well as the frequently asked questions list. isaacl (talk) 04:25, 1 December 2016 (UTC)
I know, but some editors vote delete, even if they pass WP:GNG. Marvellous Spider-Man 04:42, 1 December 2016 (UTC)
I think you'll find it's a bit more complicated than that. A subject can pass the criteria of some SNGs and still fail NOT, which requires (without exception even for things like "competed in the 1912 Olympics" or "is claimed by his employer to be a world-famous academic") that "All article topics must be verifiable with independent, third-party sources".
If you find a government-run school that truly cannot be verified with independent source (suggestion: find the name of the local newspaper and search for its coverage directly), then you should consider nominating it for {{db-hoax}}. Despite hundreds, or perhaps thousands, of deletion attempts on schools over the last decade, I don't believe that we've ever seen a typical, government-run school that doesn't meet the GNG when editors search properly. WhatamIdoing (talk) 01:02, 6 December 2016 (UTC)
@WhatamIdoing: I think I was not able to explain what I was asking the Wikipedians to reconsider. My main suggestion was to keep sportsperson articles who pass WP:GNG. I don't have much problems with school articles being kept. I mentioned schooloutcomes to compare with AFDs of sportspersons passing WP:GNG but failing WP:NSPORTS. Marvellous Spider-Man 01:17, 6 December 2016 (UTC)
The main benefit of some SNGs is to limit simplistic interpretations of the GNG. Under GNG, you can make an argument (which might or might not be convincing) that any two articles about any subject in any neighborhood newspaper means that you deserve a Wikipedia article. If you follow that approach, then you'll be writing articles about several high school athletes per school each year, every coach, most businesses and professionals in small towns (e.g., most dentists), and certainly every politician, most upper-level civil servants (e.g., every police chief), and every government-owned building. In fact, by that minimal standard, I think I could write four or five separate articles about what didn't get built on a particular piece of empty land in my city during the last two decades, plus three articles about what used to be there.
And that's not what we want. Merely meeting the minimum standard (complying with one SNG+NOT or complying with GNG+NOT) is not the end of the discussion. Editors need to consider not only the most appropriate guideline to apply, but also whether meeting the minimum is enough. In the case of athletes and businesses, editors run to the conservative side. Merely meeting the minimum isn't enough, and athletes should be merged up to relevant teams, locations, or other, broader articles. WhatamIdoing (talk) 05:30, 6 December 2016 (UTC)
The long-held consensus in discussions on the sports-specific notability guidelines is they do not create a higher bar above the general notability guideline. They only provide a respite from immediate deletion, to allow for time to locate appropriate sources establishing that the criteria for inclusion in Wikipedia are met. Routine coverage of sporting events is not considered to meet the needs of the general notability guideline. isaacl (talk) 05:40, 6 December 2016 (UTC)
I'm familiar with that story. But I think the reality is that some of those criteria actually do create a higher bar. For example, NSPORTS excludes routine coverage (as does WP:CORP, which goes even further to specify that a local business can't be notable if it is only covered by its local neighborhood newspaper), but the GNG does not have such exclusions.
IMO this "higher bar" is a good thing. WhatamIdoing (talk) 00:36, 7 December 2016 (UTC)
Yes, the sports-specific notability guidelines and the FAQ discuss this scenario as well. I was only addressing the question of editors solely using the sports-specific notability guidelines, excluding consideration of the general notability guideline. isaacl (talk) 05:40, 6 December 2016 (UTC)
Editors at AFD must use their best judgment to determine which of the guidelines is most applicable. WhatamIdoing (talk) 00:38, 7 December 2016 (UTC)
Historically, passing the topic-specific guidelines are taken as presumed notability. There's usually a strong reason to believe that with infinite time, effort, and access to find sources, subjects meeting the topic-specific guidelines would be found to meet GNG. For instance, sports-related sources are notoriously susceptible to decay. It's fairly rare to be able to find much information online about specific NFL players (outside of the most well-known) going back more than a year, for instance. The various journalism sources quickly change their links and make old content inaccessible. It stops showing up in search results. If we had a time machine or access to printed copies of old sources, we could definitely show notability, but we have the topic-specific guideline to make it less burdensome to demonstrate notability for players that we know, based on their professional activities, are highly likely to satisfy GNG. ~ Rob13Talk 00:52, 7 December 2016 (UTC)

RFC on lists being promoted as GAs

Interested editors may comment on the GA nominations talk page. Thanks. Lourdes 08:35, 2 December 2016 (UTC)

What happens in this scenario (re: drafts)

  1. User 1 creates a draft of an article and does not move it into articlespace. Using the example that spurred on this post, let's say it's a stub of a newly notable subject kept in draftspace until more than two sources could be found, because it did not meet User 1's standards.
  2. The next day, User 2 creates a very similar stub, also with two sources (sharing one in common with the draft), in article space. It's hard to say one is much better or worse than the other, but the second was clearly not the product of copying, despite sharing some content. (i.e. it was almost certainly matter of User 2 simply not noticing the draft).

If nobody edited the draft following its creation, a history merge, as I understand it, would be feasible. But what if that's not the case?

It seems like the entire idea of using the draft space is made problematic if they can simply be ignored by someone who sees the available sourcing as sufficient for mainspace. On the other hand, does it really make sense to "penalize" User 2 for not noticing the draft (they're easy to miss if you don't search for them, after all).

The example that led me here is Draft:Ram Point and Ram Point. I disclose these self-consciously, because the whole idea of "credit" for articles is obviously fraught, and that draft is not proud work (after all, it's there because I didn't think it was good enough). The reason I'm pursuing the matter is because what if it weren't a lousy stub -- what if it were a more substantial article I wanted to work on in draftspace for a while before moving it -- but then meanwhile someone else created nearly the same thing? We encourage new users to work in drafts/sandboxes all the time. Students in particular regularly use drafts to collaborate over a period of weeks prior to moving into the mainspace. Also just a matter of principle, because I like the draft space and want people to use it more, but if people don't take into account that notification that appears when they're about to create a page for which a draft exists, then who would want to use it? — Rhododendrites talk \\ 18:05, 3 December 2016 (UTC)

  • Here is how I would handle it... User 1 should continue to work on "his" draft (in User Space), ignoring the fact that there is an active stub article for now... then, when he feels that "his" draft is "up to snuff", simply merge it into the existing stub. To put it another way... think of user 1's version as if it were a "re-write" that is still in draft form. When the "re-write" is ready, merge it into the existing stub. Blueboar (talk) 19:51, 3 December 2016 (UTC)
and... if User 1 seeks collaboration on the draft "re-write"... leave a note with a link pointing to the draft on the stub's talk page. Blueboar (talk) 20:00, 3 December 2016 (UTC)
@Blueboar: Thanks. This is sort of beside the original point I was looking for clarification on, though. "Credit", as I said, is thorny, and I'm not particularly thrilled about this being the one I put forward for discussion, but the implications of this not being hashed out properly seem significant. Wikipedians take some sense of satisfaction/value in having made a contribution like a creating an article, taking an article to GA/FA, having an article in DYK/ITN, etc. As there's obviously no public-facing sense of "credit", they're ways we informally nod to a sense of "credit" behind the scenes. In part for that reason, when we have two articles in article space about the same subject -- at least as I understand it -- the one which was created second is merged into the one created first. So I guess the more succinct way to ask this question is what happens when the first article was in the draft namespace? If, despite the notice of a draft (assuming the same article title), someone creates an article anyway, is the original then turned into possible merge material (or not even, if, as in this case, the content is largely the same) as though it were the second article created in mainspace? — Rhododendrites talk \\ 15:37, 4 December 2016 (UTC)
Personally, I don't care about "credit"... sure, only one editor can "take credit" for creating the stub... but that isn't worth much. I give far more credit to those who build on that stub and improve the article so it is no longer just a stub. It's the end product that matters, not the starting point. So... let the other guy have "credit" for the initial creation... you can take credit for the far more meaningful re-write and improvement. Blueboar (talk) 20:55, 4 December 2016 (UTC)
This is well and good, but I'm looking for the policy/guideline/precedent for a given scenario rather than advice (fine as the advice may be). Perhaps there is none, in which case I would like to at least see that there is no answer written down somewhere to make it less of an open question. — Rhododendrites talk \\ 23:13, 4 December 2016 (UTC)
Oh... OK. Sorry to misunderstand what you were asking. As far as I know, there is no policy or guideline that covers what you are talking about. Blueboar (talk) 00:21, 5 December 2016 (UTC)
Whoever's working on the Wikipedia:Four Award these days might have some insight into your question. WhatamIdoing (talk) 01:07, 6 December 2016 (UTC)
@Whatamidoing: Out of curiosity, why? The premise here is a stub (representative of an article of any given quality), and what to do at the point of realizing a duplicate article was created. Maybe I'm misreading what the Four Award is all about? — Rhododendrites talk \\ 01:21, 6 December 2016 (UTC)
Over the years, the Four Award has had occasion to discuss who "really" created an article, and specifically in the context of "taking credit" (although that's not your personal main goal). They are therefore likely to be familiar with the issues and the typical arguments for and against considering any particular version to be "first". WhatamIdoing (talk) 05:16, 6 December 2016 (UTC)

Let me extract a rewording from the thread above, since I think I may have been unclear:

  • If two articles exist on the same subject, the typical preference is to retain the older version and merge/redirect (or occasionally delete) the one created second. There are exceptions, but that's what's typical. My question is: what happens when the article that was created first is in the drafts namespace?
  • Does a draft inherently forfeit the right to be the merge target rather than the merge source, regardless of when it was created or the extent of its content?Rhododendrites talk \\ 01:21, 6 December 2016 (UTC)
    • Draft space exists as a place to start articles. A person seeking to start a new article on a subject that could reasonably be expected to have an existing draft should check to see whether there is a draft first. Of course, when you start a draft at a title where an article already exists, you get a warning that the article exists. This should work both ways. bd2412 T 01:28, 6 December 2016 (UTC)
      • @BD2412: So if there is an existing draft at that title (and thus a warning is displayed), but a second article is created anyway, what are the next steps? Is your response different if it's at a different title (and thus no warning)? — Rhododendrites talk \\ 02:14, 6 December 2016 (UTC)
  • There is related history.  I was working on an incubated draft, and someone created a version of the article in mainspace, which was in turn nominated for deletion.  The closer not only closed as delete, he decided to also delete the draft.  Unscintillating (talk) 02:58, 6 December 2016 (UTC)
  • "This should work both ways. bd2412 T 01:28, 6 December 2016 (UTC)" Yes. When starting a page in mainspace, you should be warned that there is a page similarly titled and draftspace. And vice versa. And "similar", not exact. Indeed, when starting a page in either place, a Wikipedia search (all namespaces) should be done. Otherwise, the creation of DraftSpace was an exercise begging for a huge amount of content forking. --SmokeyJoe (talk) 03:29, 6 December 2016 (UTC)
    • This is along the lines of what I figured, but I don't see a concrete place to point or clear recommendation for steps to follow. I imagine anyone simply tagging the duplicate as such (csd) or otherwise deleting it to make way to move in the original would receive more than a little flak for doing so... — Rhododendrites talk \\ 04:32, 6 December 2016 (UTC)

Proposed activity requirements for maintaining bot flags

Please see Wikipedia_talk:Bot_policy#Activity_requirements for a proposed amendment to the bot policy. — xaosflux Talk 19:20, 3 December 2016 (UTC)

Insufficient participation in WP:FFD

At WT:FFD#Insufficient participation in discussions?, I discussed declining or insufficient participation in WP:FFD nominations. However, the discussion went dead for one month. Therefore, I figured that this needs more attention at the VPP. One or two say that files that obviously violate rules have been deleted, despite lack of participation. Maybe I misread things. Anyway, despite being notified by bots, amount of participants is still very low. Is the layout of the page the problem, including adding a nomination? If not, why else would many people not participate? --George Ho (talk) 09:00, 4 December 2016 (UTC)

Because nobody cares? The entirety of the file namespace is maintained by a handful of people. Less than 10 at my last count and certainly less than 20 at any given time. Even though most of the copyright violations come in the form of images it simply isn't that high up on the list of things editors want to deal with. There is no quorum at FFD. It is not AFD. If there is no participation and the request is for deletion, the result is deletion. It is better to air err on the side of caution for these things anyways. --Majora (talk) 19:44, 4 December 2016 (UTC)
Do you mean "err on the side of caution", Majora? George Ho (talk) 19:50, 4 December 2016 (UTC)
I did. Silly homophones. --Majora (talk) 19:52, 4 December 2016 (UTC)

Is fixing subsection redirects improperly worse than not doing it at all?

(Note; originally posted here, then I realised it was more suited to the Village Pump. Also, this is now less about the editor in question, and more about the general matter of principle and policy.)

In this edit a redirect-to-subsection is converted to a piped subsection redirect. Our guidelines on this state we should prefer the redirect for reasons of maintainability amongst others, so normally it'd be considered counter productive.

However, in this case, the redirect's subsection anchor link (but not the link to the parent article) was broken beforehand, so it could be argued that- on an immediate and purely local level, this was an improvement. On the other hand, fixing things in this way in general is bad overall because it decreases maintainability and negates the reason it was linked via a redirect in the first place.

Clearly, the best solution would be to fix the redirect instead, or to encourage the editor to do things that way.... that isn't in question.

The issue is:- Should editors be discouraged- and even prohibited- from "fixes" like the one above, even if the alternative is that the slightly faulty redirect remains in place instead?

Ubcule (talk) 19:47, 5 December 2016 (UTC)

If the problem is with the redirect, then the redirect should be fixed, as there are probably >1 incoming links to the redirect and one edit fixes them all instead of having to make edits to a lot of articles. In this case the redirect has but 4 links, but it still saves time. As for whether it should be allowed, I think context goes a long way. If it's just some editor happening upon a page and fixing a broken link, I think it's fine and within the spirit if not the letter of the law. On the other hand, if someone is going around doing these en masse (as it is in your case), whether automated or not, I think it should be discouraged from continuing, but I don't know if the edits should be reverted—they're not necessarily harmful. Pinguinn 🐧 21:32, 5 December 2016 (UTC)
IMO broken links should not be kept. We should not let the perfect be the enemy of the good. It is desirable to have things working, even if the fix isn't complete.
If someone's doing this systematically, it might be helpful to point out an even better way to do this (as I once did, years ago, to someone who was systematically replacing project-space shortcuts with spelled-out names: it's more helpful to spell out "WP:NPOV" than "WP:DUE"). But it's also worth noting relevant limitations: the edit in question was made on the mobile site, and redirects do not seem to be so visible there. WhatamIdoing (talk) 01:18, 6 December 2016 (UTC)
Thanks for the feedback.
@WhatamIdoing:; I'm aware that perfection is not required, and have a similar rule of thumb personally- if something is left better than it was before, good; if worse, bad. The problem here is deciding whether on balance edits such as those described are a positive rather than negative thing!
I disagree that such edits aren't harmful on the large scale; I'd say it was on the large scale that the negative aspects became more obvious. While they look good on an immediate level, they reduce maintainability, decreasing the chance such links will be fixed if they break again in the future, and increase the amount of work for future editors; they ultimately undo structures that we've agreed are preferable and beneficial. Ubcule (talk) 19:23, 6 December 2016 (UTC)

WP:COSMETICBOT concerns

I am in the process of working on creating a bot that cleans up some of the deprecated parameters used in {{Infobox NFL biography}}. The WP:BRFA (Wikipedia:Bots/Requests for approval/ZackBot 5) has stalled due to a debate over what constitutes a purely cosmetic change. In short, the bot seeks to replace deprecated parameters with their new counterparts:

  • {{{currentteam}}}{{{current_team}}}
  • {{{currentposition}}}{{{position}}}
  • {{{currentpositionplain}}}{{{position}}}
  • {{{currentnumber}}}{{{number}}}

My view is that this is NOT a purely cosmetic change as it seeks to clean up and improve a template. I also feel that User:Monkbot provides a clear precedent. Others, including BU Rob13 (who suggested I post here), have countered that is simply a cosmetic change and thus violates WP:COSMETICBOT. I am looking for some input from others on their interpretation of this policy. Rob13 please chime in to better explain your side of this. --Zackmann08 (Talk to me/What I been doing) 17:45, 6 December 2016 (UTC)

This is very clearly a maintenance issue and not merely a cosmetic issue. Here's the logical argument:
  1. As long as the deprecated parameters are used "in the wild", the template and its documentation must continue to support them (i.e. they are maintenance overhead).
  2. A task that simplifies future maintenance is itself a maintenance task.
  3. Replacing the deprecated parameters would simplify future maintenance.
  4. Therefore, this task is a maintenance task, and not merely cosmetic.
{{Nihiltres |talk |edits}} 19:04, 6 December 2016 (UTC)
@Nihiltres: that was so well said that I would encourage you to add it to WP:COSMETICBOT!! That does an AWESOME job of describing the difference. BU Rob13 had raised a very valid concern about it being a slippery slope but I think your 4 points really lay out a clear distinction and boundary. --Zackmann08 (Talk to me/What I been doing) 19:14, 6 December 2016 (UTC)
I wouldn't support a hard-and-fast change to COSMETICBOT, but I never have any quarrel with consensus for a specific bot task. This is a cosmetic-only task, but that is quite separate from whether it's a useful maintenance task. It can certainly be both. We should be skeptical of cosmetic-only tasks by default until it's clear that there's consensus for them, as most such tasks are entirely unnecessary. COSMETICBOT is not intended to be an absolute that cannot be overridden by community consensus, however. If the community supports this bot task, I'm perfectly fine with that. ~ Rob13Talk 21:37, 6 December 2016 (UTC)
@BU Rob13: you also make awesome points! It seems like this bot is a useful one but I like the case-by-case approach. --Zackmann08 (Talk to me/What I been doing) 22:05, 6 December 2016 (UTC)
@BU Rob13 and Zackmann08: I think we can get more precise: the task here is not cosmetic, but it is "shallow". It's undesirable for article histories or watchlists to be flooded with "shallow" changes, with "cosmetic" changes being a good example of particularly shallow changes. {{Nihiltres |talk |edits}} 00:18, 7 December 2016 (UTC)
@Nihiltres: HEY! Who you calling shallow?! Face-wink.svg No but seriously, I like that! Great description. --Zackmann08 (Talk to me/What I been doing) 00:20, 7 December 2016 (UTC)
Purely cosmetic changes are usually defined as changes that do not alter the visual output of the page. Using that definition, this is most certainly cosmetic. It's equivalent to replacing a template redirect call with the template it redirects to; It cleans up the transclusions, in a sense, but it's also unnecessary to improve the articles themselves. ~ Rob13Talk 00:47, 7 December 2016 (UTC)
I agree that it is good for a bot to remove deprecated parameters, assuming it is likely the parameters will eventually be removed even if in a few years. In addition to the list above, removal is worthwhile because editors often copy a template in an article, treating it as a model for some other article. I often clean {{convert}} templates and am guilty of many cosmetic edits that I justify to myself on the grounds set out here (although I'm not using a bot). Johnuniq (talk) 22:13, 6 December 2016 (UTC)
One consideration that I do not see addressed above: if there is consensus at the template's talk page to deprecate and remove parameters from a template, and there are many articles affected, a bot is likely to be the least disruptive tool to make the changes to affected articles, since many (most?) editors hide bot edits from their watchlists. If we decline bot tasks of this type, and editors choose to make the edits manually, more editors' watchlists will be populated with these changes, and editing errors may also be more likely. – Jonesey95 (talk) 06:39, 7 December 2016 (UTC)

Afd process

Issue: There seems to be a wide variation in how the Afd process works. It seems, the only guidelines that are evaluated are the ones that individuals bring up in the discussion. And, the outcome of the discussion is based upon the input from users, some of whom understand the guidelines and others do not. In addition, the decision-making process is sometimes focused on waiting until there is consensus versus weighing the extent to which the applicable guidelines are correctly assessed.

For example, articles like Alana Lee, where the person is notable only because she won a Miss Nevada contest and only has a few sources is "kept". On the other hand, there are articles like Debra Ruh, where there are numerous secondary sources that has become a protracted discussion. (As an FYI, I worked on Ruh after it was nominated. It's just an example of a case where the subject did not appear to be notable, but may be viable upon further work/review)

Proposal: Using a checklist, similar in concept to the {{DYK checklist}}, and based upon the criteria from deletion reason guideline, will help ensure a thorough evaluation of the guidelines for decision-making.

I have drafted a proposed checklist and it would be great to get your input about this or other solutions that would help make the process more effective and balanced.--CaroleHenson (talk) 18:02, 7 December 2016 (UTC)

AfD is not DYK. When DYK gets it wrong its egg all over our faces on the frontpage. If AfD gets it wrong its fixable. Also there are a number of conflicting policies and the discussion leads to a balance between those policies. Also the discussions at AfD codify what will become policy, or will show unworkable policy to be such. As such I am very uneasy about such a process. Agathoclea (talk) 18:52, 7 December 2016 (UTC)
It may be that AfDs are fixable, but it seems once an article is deleted, it's hard to get past a previous decision to delete. In fact, it's one of the reasons an article can be deleted, right? It doesn't help that there seem to be people who make arbitrary assertions or claims based upon personal bias - and that seems to get equal weight as the ones where people have done an evaluation and make legitimate and thoughtful interpretations of the guidelines.
And, there are cases where beauty contestants with no other notability, for instance, because I've seen a lot of them lately, get renominated but they aren't getting discussed by people that understand the guidelines or have barely get a whisper in terms of feedback. Because of that they stay, even if they've been nominated several times. And, there seems to be a theory that if an article has been on WP for a while, that means it should stay. It seems that it's fixable in theory, but not always in practice.
It's egg on our faces, not on a front page, but by readers who see a lot of very poor articles of non-notable people, which then is an encouragement for other articles of non-notable people. And the fact that we don't have consistent or any where close to thorough review of the deletion criteria, means we're failing. And, probably the biggest issue is that there is such a large backlog, and there are not enough editors to patrol the articles.
Do you have an idea about how to make the process more effective?--CaroleHenson (talk) 19:51, 7 December 2016 (UTC)
I disagree. Frontpage stuff gets shoved into everybodies face. Borderline notability articles do not. One has to be bored (random search) or looking for something specific. If the person finds the article on the subject he is looking for even if I could not care twohoots about beauty contestants then he is a winner. I am not saying we should keep everything - what I do say we should not take away the possibility to evaluate an article from different angles replacing it with a checkboxstyle trafficwarden approach. The process as a whole works - the obvious cases get thrown out with the speedy nominations, the rest should have their day in court. Agathoclea (talk) 21:10, 7 December 2016 (UTC)
Hmmm. I think your point: "If the person finds the article on the subject he is looking for even if I could not care twohoots about beauty contestants then he is a winner" is an interesting one to paraphrase for the borderline cases.
I don't think it hurts to mention the guidelines for deletion per WP:DEL-REASON - and the extent to which the article might pass or fail as an article based upon those points. Perhaps there is an informal way that I can show that I've evaluated the guidelines when I make a posting - and see how that goes, like:
  • <Meets / doesn't meet> _________ of the CSD criteria
  • Article sources are __(RS/SS, exclusively primary, unreliable, nonexistent, etc.)___ and am <able/unable> to find sufficient reliable, secondary sources
  • Find that it is <notable/not notable> according to WP:GNG and _____ because _______
Those seem to be the key issues that come up.--CaroleHenson (talk) 22:55, 7 December 2016 (UTC)
  • No, no, 1000 times no. The AFD process should work like this. 1) someone suggests we delete something. 2) A bunch of people comment with reasons why or why not they think we should or should not delete it. 3) Someone assesses the consensus and acts on it. That's IT. We should never make such judgements based on artificial "checklists" or anything like that. We discuss, we give rationales, we try to convince other's we're right by appealing to reason and sense. THAT is how we should always do it. There's WAY too many variables to short circuit that in any way with checklists. --Jayron32 00:46, 8 December 2016 (UTC)
  • I'm not sure how WP:DEL-REASON is an artificial checklist - but I'm hearing the concerns about using a checklist.--CaroleHenson (talk) 01:24, 8 December 2016 (UTC)

Presidential cabinet members

This concerns the criteria for inclusion for Category:Trump administration cabinet members and Template:Trump cabinet.

One editor removed Ben Carson despite this announcement, setting off a bit of an edit war.

So, what is the criteria for inclusion? When Trump announces a choice? When he submits his choice to congress? When the choice is confirmed? Is is possible to be confirmed before the inauguration, and if so are those confirmed choices excluded from our cat and template until the inauguration?

I would note that on 22 November 2008 Hillary Clinton was placed in Category:Obama administration cabinet members[1] and on 19 December 2008 Ron Kirk was placed in the same cat.[2] I didn't check any other names. --Guy Macon (talk) 04:38, 8 December 2016 (UTC)

Pretty sure no one has been officially nominated, and I suspect the Senate will not entertain any nominations at least until the electoral college makes the vote official. That said, the announcement from Trump is as clear as they get. Either Ben Carson should be in the category and template, or no one should. I do think care needs to be taken not to imply on any page that Ben Carson is a current cabinet member, but there are plenty of ways to accomplish that. Someguy1221 (talk) 04:57, 8 December 2016 (UTC)
I have to wonder why inclusion in Category:Obama administration cabinet members was allowed two months before Obama took office but inclusion in Category:Trump administration cabinet members is not being allowed. --Guy Macon (talk) 05:04, 8 December 2016 (UTC)
That's true, that would be a double standard if that happened. However, more importantly, some or most of these people have to be confirmed by the United States Senate. The electors from Electoral College haven't even voted yet. Let's hope there are not too many surprises at that fateful event on December 19, 2016. Quis separabit? 05:44, 8 December 2016 (UTC)
If that happened? It did happen. Obama's picks were placed in the category long before they were confirmed and long before the electoral college voted. Trump's picks are being kept out of the category. Why the double standard? --Guy Macon (talk) 10:21, 8 December 2016 (UTC)
Eight years is a very long time on wikipedia. We have become much more picky about many things. What you perceive as a double standard may simply be a shifting of standards. ϢereSpielChequers 10:29, 8 December 2016 (UTC)
If it is a new standard, it should be applied equally across all relevant pages. Someguy1221 (talk) 10:30, 8 December 2016 (UTC)
It may well be. A couple of years ago I was reverted over some post because the chap had been announced but wouldn't be in post until his predecessors retirement day. I've seen some sports based deletions because players had been announced for squads but not yet turned out for the team. Can you point to some breaches of WP:Crystal that we currently accept? ϢereSpielChequers 10:39, 8 December 2016 (UTC)
The best recent example that I can think of is the wedding of William and Kate. At 11:20 AM on the day of the wedding Jimmy Wales moved the Kate Middleton article. ϢereSpielChequers 10:48, 8 December 2016 (UTC)

Technical

Wikiget tool

I wrote a tool for myself, found it pretty useful so cleaned it up and posted on GitHub in case anyone might be interested.

It's a unix command-line tool to retrieve lists of article names, such as all pages in a category, backlinks of a template, pages edited by a user during a certain period, etc.. it's generally useful for work with AWB or bots, but probably other things as well in a unix environment. Only dependency is GNU awk and one of wget, curl or lynx.

https://github.com/greencardamom/Wikiget

-- GreenC 01:36, 26 November 2016 (UTC)

Thank you. Right on. Perfect direction with the generation of titles-only query-results. Its easy, and it works fast and flawlessly. AWB nutrition! Your wikiget.awk tool offers Contributions' titles. It offers Categories' titles. It offers backlink titles.
But I'm sure development should proceed with Search titles via the Search API (not just stop with Contributions and Categories APIs). (See T113840 for this Search feature request.)
Also the text post-processing of titles, in your Usage section on GitHub, should mention comm as well as grep. — Cpiral§Cpiral 03:05, 28 November 2016 (UTC)
User:Cpiral, thanks for the interest and glad to hear it works :) Wasn't aware of the Search API. Agree it should be added. Any other ways to retrieve lists of titles? Re: comm it could link to this page which has all the options with pros and cons. Awk is my favorite but I chose grep for brevity, but if working with millions of records comm is best. -- GreenC 18:07, 28 November 2016 (UTC)
@Cpiral:, version 0.4 supports search. -- GreenC 17:38, 29 November 2016 (UTC)
Thanks GreenC. See mw:API_talk:Search#title_search_is_disabled. See ya on Github. — Cpiral§Cpiral 19:35, 29 November 2016 (UTC)
Ah there's a solution for it. Fixed in 0.45 0.46 -- GreenC 03:25, 30 November 2016 (UTC)
0.47 fixed a couple edge case bugs and should be stable now. -- GreenC 17:39, 4 December 2016 (UTC)

Tool request

Hey all, not sure where the best place for this would be, but in my capacity as a gnome admin, I'm interested in some sort of tool that will search for key phrases, say, daily or weekly, then notify me when they appear. Examples:

  • I've been dealing with one or two disruptive editors who keep adding "Background Muppets" sections to articles.
  • Another disruptive editor is a young Indian actor who keeps adding his name, "Prem Khan" to articles.
  • An Iranian IP-hopper keeps adding (unsourced) "Komail Shayan" or "[[Komail]] [[Shayan]]" to articles.
  • "declared as blockbuster" "declared as super-hit" "all-time blockbuster status" are (obviously problematic) phrases some editors from India add to film articles.

Being notified when these things as they pop up would be helpful in combating disruption and it's gotten really hard to remember all the phrases I'm supposed to search for. I'd love to automate that. Thanks in advance for any help. Cyphoidbomb (talk) 17:08, 1 December 2016 (UTC)

Those all sound like something that could be an edit filter, at least a edit filter log. Post over at Wikipedia:Edit filter/Requested. — xaosflux Talk 00:46, 2 December 2016 (UTC)
What about just having some links on your user page like this
This is what I tend to use. See User:Jason Quinn/searches. Wouldn't take long to customize your searches to group them and do whatever you want. Jason Quinn (talk) 19:04, 3 December 2016 (UTC)
@Jason Quinn: Thanks for taking the time to post these. I'll take a closer look and see if I can figure 'em out. :) Thanks! Cyphoidbomb (talk) 17:21, 6 December 2016 (UTC)
Search needs a basic "literal regex" to find non-alphanumerics like square brackets. The other searches don't need insource. Please see Help:Searching/Draft and {{Search link}}. — Cpiral§Cpiral 04:13, 7 December 2016 (UTC)

Previous issues in sending emails from the site

Please help the awesome user:Legoktm test his fix to this hideous problem. If you have had issues in the past sending email messages from your wiki account, please head to https://test.wikipedia.org/wiki/Special:EmailUser/Legoktm and send him a test (or a Thank You!) message. HTH, --Elitre (WMF) (talk) 18:28, 1 December 2016 (UTC)

@Elitre (WMF): Yes, "o"s with umlauts are very hideous. Perhaps you mean phab:T66795? :) --Izno (talk) 18:40, 1 December 2016 (UTC)
I would have noticed that if I were using a visual editor! /runs away --Elitre (WMF) (talk) 18:43, 1 December 2016 (UTC)
  • Note: this will reveal your email address (As with all uses of email user) - I hope Legoktm signs me up for only the finest newsletters! — xaosflux Talk 20:19, 1 December 2016 (UTC)
    • If you will go vote at the m:2016 Community Wishlist Survey, and tell your wiki-friends (especially at smaller/non-English projects) about the best ideas there, then I'm sure that Lego will remove your name from spam-subscription list. 😉 Whatamidoing (WMF) (talk) 17:56, 2 December 2016 (UTC)
Ping @ user:Eddaido, user:Dirtlawyer1, user:AsceticRose - as you had related issues in the past, could you help here? thank you! --Elitre (WMF) (talk) 17:38, 2 December 2016 (UTC)
My WP email problem was solved by opening a new email account (with iCloud) and scrubbing Yahoo. Hope this helps. Eddaido (talk) 20:57, 2 December 2016 (UTC)
Same to me as Eddaido. I opened a new account at g-mail and abandoned Yahoo. The g-mail did not cause any problem. -AsceticRosé 15:22, 4 December 2016 (UTC)

Several technical problems

For the past hour, I have faced several problems, which appear to be related. Pop-ups no longer work. On my Watchlist, edits still appear grouped by page; but I no longer have a drop-down arrow next to each page to expand and look at these. Twinkle has disappeared. I see several other display problems. I have tried clearing my cache, opening Firefox with add-ons disabled, rebooting my PC; but none of this has helped. These all appear to be Java-related issues, but I do not have any problems on other websites, and this just started about an hour ago, for no apparent reason. Are others facing similar problems, or is it just me? And if it is just me, do you have any suggestions about how I can correct the error? RolandR (talk) 23:27, 1 December 2016 (UTC)

Same here, not getting popups, watchlist announcements (such as RFAs) and things. I've had this problem before and usually a refresh or two solves the problem. No such luck this time.--☾Loriendrew☽ (ring-ring) 23:33, 1 December 2016 (UTC)
Iiiiit'ssss Thuuuursdaaaaayyyyy.... --Redrose64 (talk) 00:20, 2 December 2016 (UTC)
Seriously though, several gadgets have stopped working, these include "Display pages on your watchlist that have changed since your last visit in bold (see customizing watchlists for more options)" and "Add two new dropdown boxes below the edit summary box with some useful default summaries". On the latter, see WT:Gadget#Edit summary gadget was working now not working. --Redrose64 (talk) 00:23, 2 December 2016 (UTC)
"Display pages on your watchlist that have changed since your last visit in bold (see customizing watchlists for more options)" had disabled itself for me and one or two others at Wikipedia:Help desk#Bolding of Watchlist items. It worked for us to enable it again. PrimeHunter (talk) 00:44, 2 December 2016 (UTC)
Oh, it isn't just me! I've noticed a slowness in how a page loads, with that little spinning thing happening at the top of the tab on English Wikipedia. I suspect it might be part of a phenomenon I've noticed on Wikisource for the last couple of days. Replication is not always instantaneous the last 18 hours. And while I can purge the cache on the individual pages, the Index of any work has been iffy in that regard (sometimes yes, but mostly not enabled on a purge of Index). And, oh yes, the watchlist changes in bold has disabled itself on mine also. It magically unchecked itself on my Preferences. — Maile (talk) 01:03, 2 December 2016 (UTC)
Hi this problem is being investigated and looks like another api problem today, see https://phabricator.wikimedia.org/T151702 please Paladox (talk) 16:12, 2 December 2016 (UTC)
That is definitely a separate issue, not related. Matma Rex talk 16:26, 2 December 2016 (UTC)

What happened to the bolding on Watchlists?

For quite a while there, unvisited changed pages on my watchlist appeared in bold, and that was quite helpful as I could easily tell how far I needed to scroll down the list and which pages I still needed to look at if I so chose.

Now the bolding has been removed. Can someone tell me why it has been removed, and how I can get the feature back if I desire? Thanks. Softlavender (talk) 05:08, 2 December 2016 (UTC)

See the thread above this one. Certain technical things are awry at the moment. Normal service will be resumed, one hopes... --Tagishsimon (talk) 05:12, 2 December 2016 (UTC)
Oh thank goodness. I had just forlornly accepted my fate. Glad to see that it's an actual issue and not just my browser/machine. AlexEng(TALK) 05:23, 2 December 2016 (UTC)
Thanks all. Appreciate the quick feedback. Softlavender (talk) 05:31, 2 December 2016 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Just to add to this, pages with changes don't have the green marker either (I use good old monobook). Also, I see a flash of bold when the page initially loads. It's almost as if all the pages are being marked as "visited" once the watchlist has finished loading. -- Scjessey (talk) 14:38, 4 December 2016 (UTC)

@Scjessey: At Preferences → Gadgets, check the setting of "Display pages on your watchlist that have changed since your last visit in bold (see customizing watchlists for more options)": whatever it is, flip it and save. If it's now incorrect, flip it again and save again. Then do the same checks on "Display green collapsible arrows and green bullets for changed pages in your watchlist, page history and recent changes". --Redrose64 (talk) 18:31, 4 December 2016 (UTC)
@Redrose64: Ahhhhhh - thank you. Both now work as expected. I wonder what caused it to eff up in the first place? -- Scjessey (talk) 23:17, 4 December 2016 (UTC)

If statements containing several statements don't work anymore in edit filters

In edit filters, it has been possible to use if statements that contain several statements in both the then part and the else part. That has stopped working sometime between 15 November and 2 December, probably sometime during the first few days during this period. A semicolon in the then part or the else part results in a syntax error. That means that edit filters that contain such if statements are not run at all anymore since they contain a syntax error. An example of how such an if statement can look like: if action != "move" then (article_text2 := article_text; article_prefixedtext2 := article_prefixedtext;) else (article_text2 := moved_to_text; article_prefixedtext2 := moved_to_prefixedtext;) end; I hope this newly introduced error soon is corrected, so that the edit filters start working again. (I cannot login to Phabricator, so I mention this error here instead.) Svensson1 (talk) 08:49, 3 December 2016 (UTC)

I've created phab:T152281 now. Nirmos (talk) 10:38, 3 December 2016 (UTC)

Still no Google results

Hey. My article about Irina Nevzlin still has no Google results. Is there any way I could fix it? Thank you in advance. Sllm (talk) 06:35, 4 December 2016 (UTC)

I've submitted it via https://www.google.com/webmasters/tools/submit-url ... we live in hope. --Tagishsimon (talk) 06:49, 4 December 2016 (UTC)

Main Page buttons

Why does the Main Page have a move tab but not a delete tab? Moving is impossible; Special:MovePage/Main_Page gives you a message

You do not have permission to move this page, for the following reason: You cannot delete or move the main page.

This is identical to the message you get at https://en.wikipedia.org/w/index.php?title=Main_Page&action=delete, except of course it says "permission to delete". Since the tech folks have disabled doing both, and disabled the delete tab, why do we need a move tab? Nyttend (talk) 14:33, 4 December 2016 (UTC)

Yes check.svg Done Special:Diff/753005631 removed tab consistent with having the delete tab removed. — xaosflux Talk 17:28, 4 December 2016 (UTC)
@Xaosflux: Maybe the delete rule should also be moved to MediaWiki:Group-sysop.css? --Izno (talk) 17:41, 4 December 2016 (UTC)
These may both be able to be moved, please discuss at MediaWiki talk:Common.css. — xaosflux Talk 17:51, 4 December 2016 (UTC)
@Nyttend: Why do you want it to have a delete tab? --Redrose64 (talk) 18:25, 4 December 2016 (UTC)
So someone will put me on WP:STOCKS :-) I didn't want a delete tab; I was suggesting that we get rid of the move tab. Nyttend (talk) 23:14, 4 December 2016 (UTC)

{{sisterlinks}} not working--possibly due to a comma

Tech News: 2016-49

18:07, 5 December 2016 (UTC)

Substitute partial page name

Long background explanation for why I'm doing this, but basically I have a ton of categories that are called "Category:Pages using TEMPLATE_NAME with unknown parameters". Rather than having to repeatedly type out "This category tracks transclusions of {{TEMPLATE_NAME}} using unknown/unsupported parameters." I wanted to have a subst I could copy and paste that would pull it from the page title... Now I know that {{str right |{{str crop |{{FULLPAGENAME}}|24}}|21}} will give me what I need... but how do I subst that?! --Zackmann08 (Talk to me/What I been doing) 00:02, 6 December 2016 (UTC)

What happens, if you subst only str right or all three templates? --Edgars2007 (talk/contribs) 00:50, 6 December 2016 (UTC)
Yes, all three should work fine: {{subst:str right |{{subst:str crop |{{subst:FULLPAGENAME}}|24}}|21}}. PrimeHunter (talk) 01:07, 6 December 2016 (UTC)
@PrimeHunter: thank you!!! I was lost on the syntax. That worked perfect! --Zackmann08 (Talk to me/What I been doing) 01:11, 6 December 2016 (UTC)

API PERL question.. correct specification of HTTPS connections

Now, let me start off by saying, I'm jet lagged, and probably am missing something obvious.

I did check this--the bot doesn't appear blocked.

I've been running very simple PERL scripts as User:Joe's Null Bot for some years, these work off the PERL MediaWiki API (e.g., [7].)

Since early November (and I was literally on Antarctica away from internets in the meantime), it appears that these scripts have been failing, unable to connect to en.wikipedia.org port 443. Can't connect to that port, I hear it cry, error 500. My only environmental upgrade that likely to be relevant was an upgrade to OSX Sierra. The PERL APIs don't appear to have changed in the last year or more, so whatever is wrong is probably on my end, but as I said, I'm jet lagged and not seeing it. Ideas? --joe deckertalk 01:06, 6 December 2016 (UTC)

Hmmm. Given what 443 is, I have one idea. Back in a few minutes. --joe deckertalk 01:09, 6 December 2016 (UTC)
Okay, what's the correct way to populate the hashref passed to API->new for an HTTPS connection? I take it that simply putting https in the URI is not sufficient. --joe deckertalk 01:13, 6 December 2016 (UTC)
Just a guess, for something to try, I've run into problems before with SSL and expired CA certificates. Maybe in the OS upgrade it lost the certificate. Though there is a status code for that 435 .. 500 is a generic which is more a question than answer. -- GreenC 02:18, 6 December 2016 (UTC)
Hmmm. ENWIKI's cert looks good, the only thing that upgraded was my own box, which is my back-room iMac where the scripts run. Weird. --joe deckertalk 02:37, 6 December 2016 (UTC)
I seem to recall an issue with root CA's and macOS Sierra. Can you check if the cert looks good from your box using Safari? I don't know what browser you normally use, but IIRC Chrome was using its own list of root CA's. Rchard2scout (talk) 08:30, 6 December 2016 (UTC)
Both Chrome and Safari report ENWIKI's certs as valid.
Slightly more caught up on sleep, I'll look into this more in the next few hours. I see that midyear I applied a hack to disable some sort of hostname checking to make SSL work, my guess is that that's breaking now. Have gotten similar results from two machines. (If someone has experience with, or better, an concise example of, all the correct incantations for a login connection to en.wikipedia.org over SSL, I'd appreciate it. --joe deckertalk 23:24, 6 December 2016 (UTC)
Wikipedia:Village_pump_(technical)/Archive_146#MediaWiki::API_and_SSL may provide some background. --joe deckertalk 23:26, 6 December 2016 (UTC)

Normally all you need with the Perl API is the protocol card:

my $bot = MediWiki::Bot->new ({
        assert       => 'bot',
        host         => 'en.wikipedia.org',
        protocol     => 'https',
}) or die "new MediaWiki::Bot failed";

Hawkeye7 (talk) 01:27, 7 December 2016 (UTC)

{{ping}Hawkeye7}} Cool, I was using the lower level interface, but it's probably not that hard to cut over.
That having been said, it still doesn't work.
2: 500 Can't verify SSL peers without knowing which Certificate Authorities to trust : error occurred when accessing https://en.wikipedia.org/w/api.php after 6 attempt(s) at afcpend.pl line 86. --joe deckertalk 16:30, 7 December 2016 (UTC)
Let me try putting the $ENV{PERL_LWP_SSL_VERIFY_HOSTNAME} = 0; fix back in. --joe deckertalk 16:32, 7 December 2016 (UTC)
And nope.
2: 500 Can't connect to en.wikipedia.org:443 : error occurred when accessing https://en.wikipedia.org/w/api.php after 6 attempt(s) at afcpend.pl line 86. --joe deckertalk 16:33, 7 December 2016 (UTC)
Have dumped code to User:Joe_Decker/afcpend.pl so that you can laugh at the kludgery. --joe deckertalk 16:39, 7 December 2016 (UTC)

Showing related articles, at the bottom of the article on mobile

Related pages on mobile English Wikipedia.png

Greetings, the Related Pages feature is currently running on stable mode, on almost all Wikipedias, except English. It has been live on beta for over six months (to review, select beta from the settings page on mobile). The feature allows readers to be exposed to content that is similar to the topic that they are reading, a good way to further engage readers, and allow for more access to knowledge. After reviewing the feature's performance on beta, which displayed very high usage for the feature in mobile and significantly lower usage in desktop, the reading web team, responsible for developing the feature, would like to move the feature to stable on mobile web and potentially discontinue the feature on desktop. If no major concerns are identified, the team will be prepared to apply these changes in early January. Thank you --Melamrawy (WMF) (talk) 09:24, 6 December 2016 (UTC)

Specific range of user contributions

Is it possible to get a specific range of user contributions? I was expecting the &from= parameter to work like it does in recent changes, but it doesn't seem to. The &month= parameter may not be sufficient to narrow it down to the required contributions when dealing with a prolific contributor. SpinningSpark 10:18, 6 December 2016 (UTC)

Click "older" in user contributions to see the url structure like https://en.wikipedia.org/w/index.php?title=Special:Contributions/Spinningspark&offset=20161203012537&target=Spinningspark. You can then edit the date and time in the url directly. The time is UTC. PrimeHunter (talk) 10:37, 6 December 2016 (UTC)
I may as well post this which I wrote before seeing PrimeHunter's answer.
You can use offset=YYYYMMDD with limit=N, for example the following shows 10 contributions older than 1 April 2014:
https://en.wikipedia.org/wiki/Special:Contributions/Spinningspark?offset=20140401&limit=10
A time (HHMM or HHMMSS) can be added:
https://en.wikipedia.org/wiki/Special:Contributions/Spinningspark?offset=201404011400&limit=10
Johnuniq (talk) 10:40, 6 December 2016 (UTC)
Doh! 'click "older"', obvious when you put it like that! SpinningSpark 13:56, 6 December 2016 (UTC)

Easy way to spot user renames?

Hey all, I can't figure out which tool is supposed to indicate the various previous usernames a person has had. For instance, here I see no results for a user name change, here I see no results for a user name change, but from what I can tell from stuff like this and this, the editor has changed names at least three times. I'm sure this is totally an issue of my ignorance. Thanks! Cyphoidbomb (talk) 17:27, 6 December 2016 (UTC)

Standard way I use is to check the page history of the user talk page for moves. When an user is renamed, that page is automatically moved. Jo-Jo Eumerus (talk, contributions) 17:31, 6 December 2016 (UTC)
@Jo-Jo Eumerus: There isn't a log for this? That's bizarre. Also, any idea why nothing shows up when I select Move log? Thanks, Cyphoidbomb (talk) 17:37, 6 December 2016 (UTC)
You need to use the previous username for both logs - it works the same way for normal page moves. This method requires that the user previously had a talk page, or user page, which was moved. Another method is to look at their early talk page signatures. -- zzuuzz (talk) 18:02, 6 December 2016 (UTC)
What links here, show redirects only. -- GreenC 18:10, 6 December 2016 (UTC)
So I would first have to suspect that someone has been renamed in order to think to use one of the methods listed to figure out who they were before? That is so weird. Cyphoidbomb (talk) 19:21, 6 December 2016 (UTC)
The same can be said for all page moves; there's probably an ancient bug report for it. You'd have to suspect a rename in order to look at their previous-names log, if it was there, so there's not a huge extra amount of work involved. Sometimes though, without userpages or signatures, it can be almost impossible to tell. -- zzuuzz (talk) 19:37, 6 December 2016 (UTC)
Yeah it would be a good idea for a User Script to highlight a username when they have backlink redirects from User space. I've never written a user script but it would be similar as User:Theopolisme/Scripts/adminhighlighter.js (highlight admin), User:NuclearWarfare/Mark-blocked script.js (highlight blocked user). -- GreenC 19:46, 6 December 2016 (UTC)
Did you try the global rename log on meta (example)? — xaosflux Talk 19:56, 6 December 2016 (UTC)
Never mind - that is the same direction you don't want. — xaosflux Talk 19:57, 6 December 2016 (UTC)

Nowrap templates

Sometime in the past 24 hours, the nowrap template has stopped working. I use them fairly extensively because I edit from a mobile device for mobile users; they're very helpful in making tables readable. Does anyone know why they have stopped working or how to fix the issue? Prisonermonkeys (talk) 20:36, 6 December 2016 (UTC)

It seems that it's is only non-functional on the mobile site.Tvx1 20:53, 6 December 2016 (UTC)

Weird custom JS/CSS of inactive users

Querying DB I just found these weird custom JS/CSS of some users with only few edits on en.wp. Were they created automatically by some MW engine feature? If so, I'd say it would be better to delete these custom user scripts/styles.

Extended content
Page_title (page_size) // user editcount

--XXN, 21:48, 6 December 2016 (UTC)

It appears to be a dark theme. Considering they're all virtually identical, they're probably copies of each other, possibly from some other source. I also found a copy of that css here. The people who have a dark theme probably really want it. The fact that they don't edit much other than their own css isn't necessarily an incompatible personality characteristic. Also, the users aren't all inactive. Some of them have recent edits. They just don't have a lot of edits. --Unready (talk) 22:24, 6 December 2016 (UTC)
I guess the pages were created by a browser extension, maybe Stylish, shortly after the users created an account or installed the extension. The creations were only around 2011–12 and seem harmless. Maybe not the best use of server space but the space usage is tiny for Wikimedia, and deletions don't actually save space. PrimeHunter (talk) 22:25, 6 December 2016 (UTC)

Login problems in Firefox

During a recent session in which someone reverted a large series of edits I had made after a discussion I wasn't made aware of during the two hours in which it occurred (but that's another story), I found my pages were hanging and shut down Firefox, which I prefer to use for editing.

When I restarted it, I was logged out and couldn't log back on. I keep getting this message above the login box saying "There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again.

I did that and still got the same thing. I restarted the computer. Still happens. But only in Firefox; I'm typing this on Edge.

Can anyone help me with this? Daniel Case (talk) 03:43, 7 December 2016 (UTC)

I've been unable to login using Firefox for months now - again, Edge works perfectly - for me it appears to be related to Norton 360 (Firefox works when Norton isn't installed).Nigel Ish (talk) 19:40, 7 December 2016 (UTC)
I had no problems until yesterday (Chrome also works perfectly as well).

I should add that this applies to all Wikimedia sites, as I have SUL. Daniel Case (talk) 20:27, 7 December 2016 (UTC)

Login error using iPad

Hello, I am Hwy43. I'm trying to login to my account on my iPad but I get the following error message:

"There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again."

I've tried the suggestion on numerous occasions but the problem persists. This began approximately 24 hours ago when I logged myself out after somehow finding myself in annoying mobile mode so that I could log back on in desktop mode, but haven't been able to get back in using my iPad since then. The edits I have made in the past 24 hours were through my laptop where I am not experiencing the same issues.
Also, if an Admin such as Resolute or The Interior could conceal my IP address after posting this I would greatly appreciate it. Cheers, [details removed] 07:58, 7 December 2016 (UTC)

Did you try to explicitly bypass your browser cache? --Malyacko (talk) 12:08, 7 December 2016 (UTC)
No luck. Hwy43 (talk) 14:55, 7 December 2016 (UTC)
This still isn't working for me either. Since I have found I have no problems in other browsers, I suppose the problem is something related to Firefox. Are there any cookies I should check or whatever? Daniel Case (talk) 19:23, 7 December 2016 (UTC)

Rowspan, TBA, and tables

Why didn't this edit work properly? I'm not completely familiar with how templates work, so it's probably quite a simple mistake. Anarchyte (work | talk) 08:21, 7 December 2016 (UTC)

Fixed The documentation at {{TBA}} explains what was wrong. -- John of Reading (talk) 08:27, 7 December 2016 (UTC)

G13 notification issue

Greetings. I do some work over at G13 deletions. In the past, editors were given a warning when a draft had lain dormant for 5 months. This was done by a bot called HasteurBot. Then at the 6 month mark, if no further editing had occurred it appeared on the list. Then it is reviewed and either asked to be deleted, or ask for the deletion to be postponed for another 6 months. When the request for deletion is made, admins can delete the article (or editors/admins can remove the deletion tag), in a relatively short span of time. It appears that HasteurBot is no longer working, so the 5 month warning is no longer being sent out. Any ideas? Onel5969 TT me 22:06, 7 December 2016 (UTC)

Courtesy ping to User:Hasteur who created the bot. Their wiki page says they are retired, but they do seem to come around Wikipedia sometimes and may have helpful input to this discussion. --MelanieN (talk) 22:48, 7 December 2016 (UTC)
The 5 month was simply a curtosey, The bot's process was a nice to have running in advance of the activist G13 editors. I'm not interested in re-upping the process. It's nice for creators of AFC articles to recieve notice before hand, but it's not a requirement. Hasteur (talk) 04:21, 8 December 2016 (UTC)
Thanks for the perspective, Hasteur. And all your efforts here. Onel5969 TT me 11:51, 8 December 2016 (UTC)

"Your notices"

Is it just my setup, or does the "your notices" notification take like five seconds to come up on other people's machines? --jpgordon𝄢𝄆 𝄐𝄇 01:36, 8 December 2016 (UTC)

Creating a related account name

I just encountered a editor with an unusual name, What cat?, and as we chatted I mentioned the awkwardness of the username due to the terminal question mark — it gets left off when you type the URL, so https://en.wikipedia.org/wiki/User:What_cat? goes to the nonexistent User:What cat. I suggested creating a doppelgänger account, "What cat", and the user agreed that it would be a good idea, but I ended up sending him to WP:ACC after he reported that he couldn't create it due to its similarity to the names of two other accounts, including his own. When you're trying to create an account, why would similarity to your existing username be an issue? I was under the impression that the restriction on creating names similar to existing names was imposed to prevent impersonation, and clearly "What cat?" won't be creating "What cat" to impersonate himself. Nyttend (talk) 01:37, 8 December 2016 (UTC)

A sysop or account creator can make this for them for the immediate need. As far as the antispoof here is a quick example why:
  • First existing user User:I love cats
  • Second existing user User:I love cats!
  • Either of them wants to make User:I love cats? - a check could be put in that they are not spoofing themself - but what of the other account? — xaosflux Talk 01:45, 8 December 2016 (UTC)
    • An enhancement may be possible if there is "only one collision" and "collision=me". phab requests are around the corner :D — xaosflux Talk 01:47, 8 December 2016 (UTC)
[ec with your enhancement note] In this case, there was also the unrelated User:Whatcat, so What cat? shouldn't have been able to create What cat. The problem is that the similarity to What cat? was even mentioned — if you're using one account to create another, it should ignore the creating account's name when determining if any existing accounts have too-similar names. Nyttend (talk) 01:49, 8 December 2016 (UTC)

trying to create a toggled script

I'm working on a script to alter the display of an article.

But because I've run into a problem, I took the operational stuff out, in order to test the switch: the script adds an item in the tab menu that alternates between "Hide anno" and "Show anno".

The below script worked fine, until I added this to it:

var orig = cont.clone_node(true);

The words "Hide anno" are supposed to show up in the tab menu, but don't because of the above line.

Why does the creation of this variable cause the script not to work?

Here's the script:

/* anno.js: (Will) add a button to toggle visibility of annotations in lists. 

Currently, the toggle switch is being tested, because it breaks whenever I add most anything useful to the operational portion of the annoShow and annoHide functions, or above those functions.

Function annoHide will hide some text (I removed those lines of code until the toggle is fixed).  Function annoShow will put the text back (removed those lines of code for now).

Based on: https://en.wikipedia.org/w/index.php?title=User:PleaseStand/hide-vector-sidebar.js&oldid=580854231
and https://en.wikipedia.org/wiki/User:Thespaceface/MetricFirst.js  */

( function ( mw, $ ) {
    var annoSwitch; 
    var cont = document.getElementById('mw-content-text');
//  ERROR: the below line causes function annoShow not to work. "Hide anno" does not show up in the tab menu.
    var orig = cont.clone_node(true);
// This problem has me stumped, because I will need to set the content back to the original state, which is what the clone is for.

    function annoHide() {
//      the code to hide stuff will go here. For now, I'm just testing the toggle switch.
        if ( annoSwitch ) {
            annoSwitch.parentNode.removeChild(annoSwitch);
        }
        annoSwitch = mw.util.addPortletLink( 'p-cactions', '#', 'Show anno', 'ca-anno', 'Show the annotations', 'a' );
        $( annoSwitch ).click( function ( e ) {
            e.preventDefault();
            annoShow();
        } );
    }
   
    function annoShow() {
//      the code to show stuff will go here. For now, I'm just testing the toggle switch.
        if ( annoSwitch ) {
            annoSwitch.parentNode.removeChild(annoSwitch);
        }
        annoSwitch = mw.util.addPortletLink( 'p-cactions', '#', 'Hide anno', 'ca-anno', 'Hide the annotations', 'a' );
        $( annoSwitch ).click( function ( e ) {
            e.preventDefault();
            annoHide();
        } );
    }
   
    // Only activate on Vector skin
    if ( mw.config.get( 'skin' ) === 'vector' ) {
        $( function() {
            // Change this if you want to hide annotations by default
            annoShow();
        } );
    }
   
}( mediaWiki, jQuery ) );

I thought variable assignment was non-invasive. Please explain how that line affects the rest of the script.

This problem has me totally stumped. I look forward to your replies. The Transhumanist 08:28, 8 December 2016 (UTC)

I suspect you are running into a JavaScript error, which causes script execution to cease. Some browsers are not very good at reporting JavaScript errors inside anonymous functions. The error would be because the method clone_node doesn't exist in JavaScript; it is called cloneNode. — This, that and the other (talk) 09:01, 8 December 2016 (UTC)
And as a note, you are using mediawiki.util RL module, without guaranteeing that it is loaded. —TheDJ (talkcontribs) 09:27, 8 December 2016 (UTC)
How do I guarantee that it is loaded? The Transhumanist 09:36, 8 December 2016 (UTC)
@This, that and the other: That worked. Thank you! The Transhumanist 09:36, 8 December 2016 (UTC)
By the way, I've been trying to return the content to its previous state, which is what the clone is for.

I added this line:

cont.parentNode.replaceChild(orig, cont);

but it causes the script to cease execution. Can you spot an error in that line? The Transhumanist 09:36, 8 December 2016 (UTC)

Proposals

Access locks: Visual Design RFC

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

What the Visual Design RFC is about

Hi all,

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

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

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

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

A few considerations for accessibility need to be taken into account

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

The current set of locks is

  • Freely accessible / Free registration required / Paid subscription required

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

  • Green (free to read): Freely accessible, Freely accessible
  • Yellow (free, with conditions): Free registration required, Free registration required, Free registration required, Free registration required, Free registration required, Free registration required, Free registration required
  • Blue (free, with conditions): Free registration required, Free registration required, Free registration required, Free registration required, Free registration required, Free registration required, Free registration required
  • Red (not free): Paid subscription required, Paid subscription required

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

In the interest of structuring the possibilities,

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

Visual Design RFC !Vote

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

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

GYR
or
GBR
Freely accessible / Free registration required / Paid subscription required Freely accessible / Free registration required / Paid subscription required
Freely accessible / Free registration required / Paid subscription required Freely accessible / Free registration required / Paid subscription required

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

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

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

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

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

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

Freely accessible / Free registration required / Paid subscription required (DHF) vs Freely accessible / Free registration required / Paid subscription required (EHF) vs Freely accessible / Free registration required / Paid subscription required (EDF)
or, depending on Choice A1
Freely accessible / Free registration required / Paid subscription required (DHF) vs Freely accessible / Free registration required / Paid subscription required (EHF) vs Freely accessible / Free registration required / Paid subscription required (EDF)
Keep in mind the shackles could differ depending on Choice A2.

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

Aspect A4) Just don't do it

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

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

Visual Design RFC discussion

like this

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

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

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

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

The example to the right is much less ambiguous, and someone universal to mean "unlocked". Dennis Brown - 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 - 16:35, 29 October 2016 (UTC)
I'm also against using a picture like this in citation templates: see the discussion in the Behaviour section for typical use scenarios – it's going to be useful for people who are already aware that a link may or may not be behind a paywall, and want to know in advance which of the links is best for them to use – the padlock pic doesn't help for this, while coloured icons make it much easier. ‑‑YodinT 09:11, 30 October 2016 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

That fails the black background requirement.
Trappist the monk (talk) 17:56, 25 November 2016 (UTC)
It sadly does, yes. Trying to wonder what's possible along that vein. Headbomb {talk / contribs / physics / books} 17:58, 25 November 2016 (UTC)
@Trappist the monk: Lock-green.svg / Lock-gray-alt-2.svg / Lock-gray-full-alt.svg 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 Lock-green.svg / Lock-green-gray-alt-5.svg / Lock-gray-full-alt.svg. We could also consider schemes like Lock-green.svg / Lock-gray-alt-2.svg / Lock-red-alt.svg. I really like that last one. Headbomb {talk / contribs / physics / books} 18:15, 25 November 2016 (UTC)
From my staff account: Of the 3 you just suggested I like 1 and 3, but not 2 (mixed color is confusing). These are solid choices you added! Ocaasi (WMF) (talk) 18:56, 29 November 2016 (UTC)

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

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

Access Locks: Citation Template Behaviour RFC

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

What the Citation Template Behaviour RFC is about

Hi all,

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

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

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

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

First aspect

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

That is, do we want to allow all locks anywhere

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

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

Second aspect

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

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

but is ambiguous if more than one link is given:

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

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

Third aspect

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

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

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

or as

or do we remove the autolinking from the PMC identifier?

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

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

Citation Template Behaviour RFC !Vote

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

Aspect B1) Allow all locks vs Restrict locks

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

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

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

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

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

  1. Don't flag by default as it would create an inconsistent look in articles that contain possibly sometimes not-free identifiers which haven't been flagged as not being free. Headbomb {talk / contribs / physics / books} 00:09, 30 October 2016 (UTC)
  2. don't flag by default consistent with my !vote above. these symbols should not be based on assumptions. Jytdog (talk) 21:32, 30 October 2016 (UTC)
    As a point, again, no assumption would be made. Under this proposal, only known-to-be-X would be automatically marked as |id-access=X. Mathematical Reviews links (shown above), always require a subscription to view, exactly like arXiv links are always free. We already automatically flag the always free identifiers. The question is should we automatically flag always non-free identifiers. Headbomb {talk / contribs / physics / books} 22:35, 30 October 2016 (UTC)
  3. Don't flag by default per Headbomb as this could cause confusion, and because I voted for restricting locks above. Kaldari (talk) 17:27, 31 October 2016 (UTC)
  4. Per Headbomb, don't flag by default, though it sure would be nice to avoid needing to set the access state for everything. --Izno (talk) 12:31, 1 November 2016 (UTC)
  5. Flag by default Best to provide as much information as we have available. Inconsistency seems like a very minor issue. Opabinia regalis (talk) 20:35, 4 November 2016 (UTC)
  6. Conditional: Flag by default if/when sometimes not-free identifiers which haven't been flagged as not being free are all (mostly) identified/worked-around/etc. Until then, Don't flag by default.   ~ Tom.Reding (talkdgaf)  13:03, 8 November 2016 (UTC)
  7. Flag by default per "Opabinia regalis". We have to start somewhere, so we should flag sources by default when they are 100% confirmed to be non-free. Tony Tan · talk 02:21, 9 November 2016 (UTC)
  8. Flag by default. I can see the argument that this could be confusing, but if we know what the access level is, we should probably provide that information. NinjaRobotPirate (talk) 08:52, 16 November 2016 (UTC)
  9. Flag by default. Some sources are known to be (and have always been) paywalled, or require registration at least. There's no harm in assuming that an Elsevier link is (unless specified otherwise) paywalled. It's the default behavior of certain (and most) publishers. On the other hand, some publishers are built upon open access, such as PLOS, therefore the links coming from such sources are open access and there's no harm in automatically assigning them the green (un)lock. —Hexafluoride Ping me if you need help, or post on my talk 12:40, 19 November 2016 (UTC)
    Hexafluoride (talk · contribs) That's not quite what's being proposed. This sort of flagging can be done by bots. What we're talking about is the template automatically flagging guaranteed-to-be-non-free identifiers. That is, links like MR 1129886 will always be non-free. Do we want to automatically flag them as such, possibly introducing an inconsistent style? For instance, a source can both have a non-free doi and a non-free MR, but the template would only automatically flag the non-free MR, since the doi can often be free. This would introduce an inconsistency that would need to be resolved by manually flagging the doi with |doi-access=subscription, or by manually suppressing the automatic flag. Headbomb {talk / contribs / physics / books} 13:08, 24 November 2016 (UTC)
  10. Do not auto-flag non-free sources. I presume here that the question refers to cs1|2 identifiers, most of which are not free-to-read. Because that not-free-to-read state is the norm, we should not allow the use of icons that say this normally-not-free-to-read is, yep, you guessed it, not free-to-read. Do not highlight the norm. Redundant; clutter; pointless. If the question is intended to also include non-free sources accessed through |url= and the like, I oppose that because cs1|2, without a very large database of urls, cannot know if this particular url is free-to-read or is restricted.—Trappist the monk (talk) 19:52, 24 November 2016 (UTC)
  11. Do not auto-flag by default. Again from my staff account: Even among the most notorious paywalled publishers such as Elsevier, an increasing number of articles appear in "hybrid" journals which publish both open and closed content under the same publication. This is further complicated by embargoed content that is closed for its first 6-24 months and then becomes open later. We don't yet have the infrastructure to reliably tag closed access by default. It also reduces the effectiveness of the partially and fully open locks as signals of a better experience; they stand out more when they are not in a sea of closed locks, which is what would commonly happen in our highly paywalled world. Lastly, as not-free-to-read is unfortunately still the norm, it makes much less sense to "tag the norm". Ocaasi (WMF) (talk) 18:40, 29 November 2016 (UTC)

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

Deprecate

Supported

Unsupported

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

Supported

Unsupported

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

In call cases, there is currently no error messages being displayed. The ones shown above are mockups of what could be displayed in the next update.

  1. Deprecate. Too many problems with the old system, no sense in supporting it. One system to rule them all is clearer to everyone. Headbomb {talk / contribs / physics / books} 00:09, 30 October 2016 (UTC)
  2. Deprecate: This one is pretty clear cut – if someone's willing to go through and make the necessary changes then this should be reformed to make it clearer and easier to use. ‑‑YodinT 08:59, 30 October 2016 (UTC)
  3. Deprecate, but only once most of the occurrences of the old system have been migrated to the new one, possibly with a bot. − Pintoch (talk) 10:57, 30 October 2016 (UTC)
  4. Deprecate per Headbomb. Nthep (talk) 14:33, 30 October 2016 (UTC)
    @Nthep:, you're aware that to deprecate these parameters we need to allow for all locks to be used, right? Because your vote in B1 would prevent deprecation from happening. Headbomb {talk / contribs / physics / books} 10:38, 4 November 2016 (UTC)
    Sorry, I disagree. There is nothing prevents deprecation of these two parameters if the use of locks is limited to red and amber locks. The green lock is a complete red herring; there is no need to indicate an free access source, only to highlight on-line sources which are not free access. Nthep (talk) 10:47, 4 November 2016 (UTC)
    Are you sure? It is not necessary for the cs1|2 templates to accept |url-access=free or any of the |<id>-access=registration and |<id>-access=subscription parameter values in order to deprecate |registration=yes and |subscription=yes. To deprecate, it is only required that we adopt some oter form of access signalling that can convey the same information, or, while it is outside the scope of thish rfc, that we agree to abandon access signaling in its entirety. All locks for all urls and identifiers is not a requirement for deprecation of |registration= and |subscription=.—Trappist the monk (talk) 11:12, 4 November 2016 (UTC)
    One of Trappist's edit's seems to have deleted my reply but it is the same as Trappist's comment here. It is not necessary to signal all levels of access to deprecate the existing parameters. Nthep (talk) 11:23, 4 November 2016 (UTC)
    You know, MediaWiki, or whatever code it is, is supposed to detect edit conflicts. This has been broken for I don't know how long. I have restored your answer to Editor Headbomb and also fixed the list markup of your most recent post so that the numbering below is correct.—Trappist the monk (talk) 11:32, 4 November 2016 (UTC)
    It definitely is required, otherwise we cannot handle cases like
    Smith, J. (2016). "Fictitious title". Fictitious Journal. 1 (2): 3. doi:10.1234/123456. (registration required (help)) Headbomb {talk / contribs / physics / books} 12:46, 4 November 2016 (UTC)
    Fixed the indent and inserted a missing </span> tags.
    As currently implemented, the convention that has been adopted is that dois and other identifiers are presumed to have access restrictions. As such, the inclusion of |subscription=yes in your example citation is superfluous.—Trappist the monk (talk) 13:43, 4 November 2016 (UTC)
    It is nonetheless how the parameter is currently used in many cases. Deprecating without allowing for yellow/red locks on dois would mean losing that information. Headbomb {talk / contribs / physics / books} 23:25, 4 November 2016 (UTC)
    We should not be perpetuating poor practice. The current convention is correct; adding a paywall signal icon to a specific identifier that is the kind of identifier typically requiring payment is mere redundancy and decoration. That editors have, in the past, added |subscription=yes to templates with these kinds of identifiers is not a reason for us to continue to support what amounts to meaningless decoration. Highlight the exception, do not highlight the norm.—Trappist the monk (talk) 00:19, 5 November 2016 (UTC)
    I suppose marking doi-only works are required subscription could be deprecated as well. After using locks in the wild, I'm coming around to that option myself. Headbomb {talk / contribs / physics / books} 20:12, 7 November 2016 (UTC)
  5. Regardless of the first two aspects, I think this is a clear deprecate |registration=. I think the direction |subscription= goes depends on this entire RFC and so I can't support deprecating that parameter also. --Izno (talk) 12:18, 1 November 2016 (UTC)
    @Izno: how so? What's different about subscriptions than the above examples/votes don't apply to them? Headbomb {talk / contribs / physics / books} 10:39, 4 November 2016 (UTC)
    I... I don't know what I was thinking then. Both registration and subscription presently exist, so that can't have been a reason. --Izno (talk) 14:24, 21 November 2016 (UTC)
  6. Deprecate Opabinia regalis (talk) 20:36, 4 November 2016 (UTC)
  7. Deprecate, per above votes.   ~ Tom.Reding (talkdgaf)  13:07, 8 November 2016 (UTC)
  8. Deprecate if most resulting errors could be fixed quickly. Having two systems would be too confusing to readers and editors alike. Tony Tan · talk 02:25, 9 November 2016 (UTC)
  9. Deprecate. The locks are cleaner and alleviate the problems caused by the old system. —Hexafluoride Ping me if you need help, or post on my talk 12:43, 19 November 2016 (UTC)
  10. Deprecate, presuming that |subscription= and |registration= are replaced with a new more specific system (not necessarily the one being contemplated in this series of RfCs) because these two parameters are non-specific and have been / are used where a cs1|2 template has both a url (perhaps in |url=) and one or more of the named identifiers. When this occurs, it is impossible to determine by inspection, to which the restriction notice applies. —Trappist the monk (talk) 20:24, 24 November 2016 (UTC)
  11. Deprecate. Again from my staff account: I trust the judgement of Trappist and others that it's best not to have to redundant systems. Also, deprecate "fails gracefully" in that it allows for cleanup and informs the user what the new system entails. Ocaasi (WMF) (talk) 18:40, 29 November 2016 (UTC)

Aspect B4) Always autolink titles with free identifiers vs Autolink titles with PMC only vs Never autolink titles

Note we're talking about default behaviour only. If autolinking by default is not desired, title linking could always be done manually in individual articles. If autolinking by default is desired, autolinking could always be suppressed manually in individual articles.

Always autolink titles with free identifiers
Autolink titles with PMC only (current behaviour)
  • Williams, R. O. (6 January 2015). "How Do You Use AAPS PharmSciTech?". AAPS PharmSciTech. 16 (1): 1–2. PMC 4309825 Freely accessible.
  • Dunlop, J. A.; Apanaskevich, D. A.; Lehmann, J.; Hoffmann, R.; Fusseis, F.; Ehlke, M.; Zachow, S.; Xiao, X. (10 October 2016). "Microtomography of the Baltic amber tick Ixodes succineus reveals affinities with the modern Asian disease vector Ixodes ovatus". BMC Evolutionary Biology. 16 (1). doi:10.1186/s12862-016-0777-y Freely accessible.
Never autolink titles
  • Williams, R. O. (6 January 2015). "How Do You Use AAPS PharmSciTech?". AAPS PharmSciTech. 16 (1): 1–2. PMC 4309825 Freely accessible.
  • Dunlop, J. A.; Apanaskevich, D. A.; Lehmann, J.; Hoffmann, R.; Fusseis, F.; Ehlke, M.; Zachow, S.; Xiao, X. (10 October 2016). "Microtomography of the Baltic amber tick Ixodes succineus reveals affinities with the modern Asian disease vector Ixodes ovatus". BMC Evolutionary Biology. 16 (1). doi:10.1186/s12862-016-0777-y Freely accessible.

A green lock could follow the title, depending on choice B1.

  1. Always autolink would be a super useful feature that would also have a side benefit of greatly reducing clutter in the edit window. Headbomb {talk / contribs / physics / books} 00:09, 30 October 2016 (UTC)
  2. Never autolink title, always autolink identifiers, and suggest that |url= only be used for URLs not covered by identifiers. Links for identifiers are generated anyway, but duplicating them on the title adds nothing but a bit more complexity and blue text. If a reader sees a linked title, is it an explicit |url= or a copy from one of the identifiers? If there is more than one identifier, which URL was copied? Let's avoid all that, by not copying. And autolinking also clashes with the possibility of wikilinking the title of a notable work. Kanguole 01:31, 30 October 2016 (UTC)
    And the promised option of manual suppression would mean defining a new parameter for the template, resulting in more clutter in the markup. Kanguole 15:29, 1 November 2016 (UTC)
  3. Always autolink: usability and simplicity for readers should take priority over the complexity of code that this would cause. The ideal situation would be to link the title with the most open URL available (open > registration > subscription). Failing this, we should go with never autolink, and instead change the documentation to encourage editors to add the most open identifier based URL available to |url=. ‑‑YodinT 09:53, 30 October 2016 (UTC)
  4. (Comment: I have removed the green lock on the title in the "current behaviour" case, because this green lock is currently not produced for urls, even when they come from a |pmc=. Feel free to revert, but in that case, the fact that it differs from the current behaviour should be mentioned, I think.)
  5. Always autolink — clear benefit to readers and editors. Carl Fredrik 💌 📧 11:02, 30 October 2016 (UTC)
  6. never autolink title; always autolink pmc parameter - and i will add that i am disturbed that none of the examples above include the pmid parameter which is the single most important parameter for citations used to support content about health (germane because PMC refs will always also have a pmid). the PMC parameter should behave exactly like the PMID parameter. People should be presented with ref examples that include the PMID parameter for consideration as it will always be there. Way more often than the doi parameter will be. Jytdog (talk) 21:22, 30 October 2016 (UTC)
    The examples are minimalistic by design. That specific citation can also be access through doi and pmid, but they don't add anything to the example, or the proposed behaviour. That being said, why restrict this to PMCs only? Why shouldn't say, free bibcodes not autolink? Headbomb {talk / contribs / physics / books} 21:30, 30 October 2016 (UTC)
    The question is about PMC. It is not about bibcodes. People consider a lot of things when answering these questions. It is absolutely misleading to leave out the PMID which is almost always there (and should always be there) whenever a PMC parameter is used and PMC is what this question is about. The PMID gives entirely different information from the doi; i can't believe you are even mentioning them as though they are equivalent. Please fix the examples. Jytdog (talk) 22:49, 30 October 2016 (UTC)
    The question is about all free identifiers. You said you want to autolink pmc, but not autolink free bibcode/doi etc. Why this inconsistency? Headbomb {talk / contribs / physics / books} 23:47, 30 October 2016 (UTC)
    Read the actual question here in B4:Always autolink vs Autolink PMC only vs Never autolink. note that it says PMC. Pose a question about bibcodes and i will answer it. I have added pmid to the examples above in this Section B4. I also noticed that some of the examples above in this section don't even use the PMC parameter but use doi instead. What a mess. Oy. Jytdog (talk) 03:26, 1 November 2016 (UTC)
    Quoting "The question is, do we extend this behaviour to other identifiers which link to full official free versions as well? That is, if we have a free doi, do we want to present this citation as ...[examples]" Always autolinking means "whenever we have a free identifier (e.g. bibcode, doi, pmc, whatever) that links to a free official version, the primary link should be automatically generated". Autolinking PMC only means we'd only automatically generate a primary link if we have a PMC identifier, but not in the case of other free identifiers. Never autolinking means we'd remove the automatic general of URLs when PMCs are specified. The examples above are showing what the options mean in the case of a free doi, and a (free) pmc, but those would equally apply to other free identifiers.Headbomb {talk / contribs / physics / books} 03:36, 1 November 2016 (UTC)
    I can only read what is written at the top of this section which is "Aspect B4) Always autolink vs Autolink PMC only vs Never autolink". i have no idea where you are getting that other stuff. And you removed the PMIDs. Insane. This RfC is bogus. You are asking people to give a judgement that is partly aesthetic without a key parameter present, that will always be there in the real editing environment. bogus. Jytdog (talk) 06:40, 1 November 2016 (UTC)
    @Jytdog: You are arguing over a point (PMID is present with most PMC), which is either irrelevant or at-best tangential, to the question. It's as simple as that. Move along if that's your only concern with this section. --Izno (talk) 12:24, 1 November 2016 (UTC)
    You don't edit much on health content, do you. Jytdog (talk) 15:15, 1 November 2016 (UTC)
    That is irrelevant. The nothing in those examples depend on PMID being there on not. No one is proposing to remove PMIDs from articles, they just aren't needed here. Headbomb {talk / contribs / physics / books} 15:22, 1 November 2016 (UTC)
    word search this page for the word "clutter" and "blue link". people are evaluating things on aesthetics as well as functionality. you are giving poor examples that don't reflect citations as they will appear in practice; people cannot judge clutter when the normal full citation isn't there. the examples include parameters like author and the date of publication that are also not directly relevant to the question being asked. You included them because they are normal and expected and that is what citations have "in the wild". So too is pmid. Jytdog (talk) 15:31, 1 November 2016 (UTC)
    I'm perplexed. You wrote: germane because PMC refs will always also have a pmid. Is that true? Right now, cs1|2 templates with |pmc= are not required to have an accompanying |pmid=. Are you arguing off topic here for a function in the cs1|2 template that would throw an error when a template has |pmc= without a matching |pmid=? You wrote: the PMC parameter should behave exactly like the PMID parameter. At present, the |pmid= parameter causes Module:Citation/CS1 to link the assigned identifier value to PubMed. The Module links the value assigned to |pmc= to PubMed Central and it also links the template's |title= parameter to the same PubMed Central page. On the one hand you write: always autolink pmc parameter and on the other hand you write: the PMC parameter should behave exactly like the PMID parameter. Are these not incompatible statements? —Trappist the monk (talk) 11:03, 1 November 2016 (UTC)
    While the majority of articles with PMCs will have PMIDs, many won't. See e.g. PMC 1122408. So throwing an error here would be inappropriate. Headbomb {talk / contribs / physics / books} 14:42, 7 November 2016 (UTC)
    User:Trappist the monk of course there is no "requirement" to use pmid. What I wrote was that in WP:MED the pmid is the most important parameter in a template and everybody in WP:MED uses it. It is essential in practice and you will find it ubiquitous in articles about health. Yes, the pmid paramater links to the pubmed abstract, like this PMID 18425890. With regard to the pmc parameter - yes, it is the identifier for the free full text article (it is different from the pmid). my answer is that it should act like the pmid parameter - there should be a link only at the pmc parameter. I am well aware that the Wiki-software currently also creates a link at the title as well as at the pmc parameter. I am saying it should not do that (what is the point of having two links to the same webpage in a single ref?) - instead it should create a link only at the pmc parameter. Jytdog (talk) 15:24, 1 November 2016 (UTC)
    I think that the point of having two links to the same webpage in a single ref is to help people who have no idea what "PMC" means or why they might want to click on it. Linking the title to a free (gratis) copy helps people go to the "right" page. WhatamIdoing (talk) 21:14, 11 November 2016 (UTC)
    If that were the case, "PMC" should link to PubMed Central, and any other identifier to their respective Wikipedia page. But the point of citations is not provision of encyclopedic knowledge. That happens in the article body. The citations exist to provide a path to verification. One free link is easiest, all that is required for verification, and can be inserted without any flags. I think most people would expect a free link in a free encyclopedia. If there is no free full-text link, add a constricted (partial/limited text) access link, including to previews, abstracts etc. If that is unavailable, add a link to the next least-restrictive/constricted level of access, and so on. But two or more similar links to the same material are superfluous and potentially confusing (apart from the clutter). Additionally, I think it is obvious that a link to an abstract when there is also a link to full-text, adds exactly nothing as far as verifying sources goes. 72.43.99.138 (talk) 17:25, 20 November 2016 (UTC)
    In cs1|2, PMC (and the other identifier labels) do link to their respective articles.—Trappist the monk (talk) 17:54, 20 November 2016 (UTC)
    Well I was responding to a posting that seemed to justify different links to the same material on the assumption that people might want to know what the background of the identifier is. 64.134.97.60 (talk) 00:00, 21 November 2016 (UTC)
  7. Per Kanguole, "Never autolink title, always autolink identifiers, and suggest that |url= only be used for URLs not covered by identifiers". I see nil reason, if we are highlighting links elsewhere with locks, to provide autolinking anywhere but in the context of the identifiers. The software complexity also isn't worth it. --Izno (talk) 12:24, 1 November 2016 (UTC)
  8. Always autolink It's obviously a usability benefit to have the title always link to a free-to-read source if one is available. All of this stuff about PMIDs seems completely beside the point; the PMID never leads directly to a free-to-read source. Opabinia regalis (talk) 20:38, 4 November 2016 (UTC)
  9. Always autolink identifiers: Linking the title is a good design feature, because it establishes a very simple, user-friendly pattern: follow the title's link to be taken to the best available way to access the source. Using autolinks is a good pattern because it lets us use reliable identifiers for those title links rather than duplicating data (e.g. supplying a URL to dx.doi.org) or using a potentially non-permanent URL when it's ultimately equivalent to the (nominally permanent) DOI. That said, I also think that we should not autolink identifiers that only lead to index entries, e.g. PMIDs—they don't match the pattern of the title linking to the source itself. {{Nihiltres |talk |edits}} 21:44, 4 November 2016 (UTC)
    Yes, autolinking has always been about free official full versions. PMIDs and other non-free identifiers are not up for autolinking. Headbomb {talk / contribs / physics / books} 22:23, 4 November 2016 (UTC)
  10. Always autolink title for better usability if the links always lead to free, official, and full versions according to Headbomb. Tony Tan · talk 02:33, 9 November 2016 (UTC)
  11. Always autolink. It's a design that the user has been accustomed to (click on the title if there's a URL). The link and PMC might be different and don't always lead to the same site. —Hexafluoride Ping me if you need help, or post on my talk 12:48, 19 November 2016 (UTC)
  12. Never autolink. This will require Module:Citation/CS1, the code that underlies the cs1|2 templates, to make judgements that may not accord with an editor's preference. When there is no value assigned to |url= and only one free-to-read identifier, while it will be a pain, it is not too difficult to imagine how the code would accomplish this task. As soon as there are two or more free-to-read identifiers, then somehow, the code must select one or the other to apply to |title=. Which shall it be? What if the code does not choose the one that the editor prefers? Sure, we could add yet more parameters to tell cs1|2 how to resolve the dilema; we could overload |url= so that an editor could tell the Module to create a url for |title= from a particular identifier. There may be other 'solutions'. In the end, if an editor must have |title= linked, it is simplest to simply place the url in |url= and be done. cs1|2 is complex and confusing enough as it is, don't make it worse. —Trappist the monk (talk) 20:55, 24 November 2016 (UTC)
  13. Comment Also from my staff account: My personal opinion is that the correct method is that the title link should be to the paper/version of record, whether it is closed or open. Free-to-read versions may be preprints or another pre-publication manuscript. I don't think we yet live in a world where we can reliably autolink the title, especially as Trappist mentions, if that means deciding which version should be the "primary" one. Ocaasi (WMF) (talk) 18:40, 29 November 2016 (UTC)

Citation Template Behaviour RFC discussion

As described, both choices for the "First aspect" regarding "allowed and disallowed behavior" (also identified as "Aspect B1") seem to confuse rendering with annotation. My personal preference would be for it to be always acceptable for a citation to be annotated "|url-access=free" and "|doi-access=registration / subscription", but the rendering behavior should continue using the current convention that reduces visual clutter by only displaying locks when expectations are broken (i.e. the default expectation is that the main link is free while "doi" doesn't have a free full versions available). I think the correct behavior is a third option for Aspect B1, call it "allow all annotations, but display lock symbols only if annotations differ from the default expectation". In this third option it would always be allowed for an editor to individulaly annotate the subscription status of all parts of the citation, but the citation code would only display the lock symobls if an annotation differs from the default expectation (i.e. if a citation is annotated with "|url-access=free" no green lock should be shown for the title, as that is the expected behavior). —RP88 (talk) 16:35, 29 October 2016 (UTC)

Which option keeps the current status quo unchanged? Hchc2009 (talk) 17:06, 29 October 2016 (UTC)
There's no real 'status quo' since we just rolled out the update and the current behaviour is tentative. The current behaviour is indicated above, however. Headbomb {talk / contribs / physics / books} 17:10, 29 October 2016 (UTC)
Hchc2009, from what I can determine the code what was rolled out today uses the "Restrict locks" option. For example, code rolled out today produces the following...
  • {{cite journal |author=Author |title=Title |year=2010 |url=http://example.com |doi=10.1234/123456}}
Author (2010). "Title". doi:10.1234/123456. 
  • {{cite journal |author=Author |title=Title |year=2010 |url=http://example.com |doi=10.1234/123456 |url-access=free |doi-access=subscription}}
Author (2010). "Title". doi:10.1234/123456.  Invalid |url-access=free (help); Invalid |doi-access=subscription (help)
  • {{cite journal |author=Author |title=Title |year=2010 |url=http://example.com |doi=10.1234/123456 |url-access=subscription |doi-access=free}}
Author (2010). "Title"Paid subscription required. doi:10.1234/123456Freely accessible. 
...while I think it should do the following (which doesn't match either of the two offered options):
  • {{cite journal |author=Author |title=Title |year=2010 |url=http://example.com |doi=10.1234/123456}}
Author. (2010). "Title" . doi: 10.1234/123456.
  • {{cite journal |author=Author |title=Title |year=2010 |url=http://example.com |doi=10.1234/123456 |url-access=free |doi-access=subscription}}
Author. (2010). "Title" . doi: 10.1234/123456.
  • {{cite journal |author=Author |title=Title |year=2010 |url=http://example.com |doi=10.1234/123456 |url-access=subscription |doi-access=free}}
Author. (2010). "Title" Paid subscription required. doi: 10.1234/123456 Freely accessible.
RP88 (talk) 17:43, 29 October 2016 (UTC)

Is there any reason why we're not giving people a choice in the RfC of sticking with the 28 October status quo? I'm not seeing any compelling argument (or indeed consensus) from making any change from that position. Hchc2009 (talk) 17:41, 29 October 2016 (UTC)

I don't see that the limited choices presented here actually represent the best behaviour for readers and inexperienced editors. My belief is that there is little or no value in flagging a link as free. Whom does that benefit? Is the average reader going to think "I'll follow that link because it's free"? Of course not. The only value in having visual indicators is to warn readers when links point to content that is not free, which may save some time for some readers. Secondly, I disagree strongly with having a "mixed bag" of unofficial conventions. There is no use assuming that one type of link is free and another type is non-free. Only those already very familiar with pmid/pmc/doi/arxiv will know which is which type and we're not writing the encyclopedia just for them. Pick one convention and stick to it - I'd recommend always marking all links requiring subscription/registration and never marking links that are free. That benefits readers and is simple enough for inexperienced editors to grasp quickly. Finally, I think the new system of moving to corresponding parameters for |url-access=, |doi-access=, etc. and deprecating the old system of |registration= and |subscription= is an improvement, giving proper flexibility and should be implemented. --RexxS (talk) 18:42, 29 October 2016 (UTC)

  • No locks. I see no compelling reason to clutter citations with little dingbats. The locks are a political statement, not a tool for readers. The reader is not helped in the slightest by their presence. The reader either wants to read the source or doesn't. No reader is going to look at a little icon and say, "I really wanted to read the whole thing, but I can't, so I'm not even going to look for the free abstract or first page that the publisher might provide." And what do you plan to do when a journal changes its access policy? If the journal is important and frequently cited, someone will need to update hundreds, maybe even thousands of citations scattered all over the encyclopedia. I realize that interested editors have invested a lot of effort into this proposal, but I see no way in which it helps the encyclopedia. Ozob (talk) 18:45, 29 October 2016 (UTC)
    What most often happens to me is that I click on a link which is not free (beer)-to-access and end up wasting time in doing so, because my desire is to access the information at low-cost. $40 a paper is decidedly not low-cost. It is most certainly not a political statement. You should review the option above regarding auto-icon-ing sources which are always non-free, since I am unsure you read the proposals to any degree. --Izno (talk) 13:04, 1 November 2016 (UTC)
    If I am reading you correctly, you are claiming that if you read a publisher's website and are provided with a free abstract, then you have "wast[ed] your time" because you cannot "access the information at low-cost." Even for papers that are not free, I can't interpret your claim as anything other than exaggeration.
    To be clear, I did read the whole proposal. It assumed that Wikipedia editors wanted some kind of locks. Well, I don't. For the reasons I gave above, I don't want any locks at all. I still don't see a compelling argument in their favor, and certainly not one that outweighs the clutter they create. Ozob (talk) 23:55, 1 November 2016 (UTC)
  • Comment It looks like you have three images here. File:Lock-red.svg and File:Lock-green.svg are CC0, which is good, but File:Lock-yellow.svg for some reason is CC BY-SA which will give you trouble if someone wants to not have these locks have to be linking to the image description pages. Anomie 18:50, 29 October 2016 (UTC)
    I've marked it as CC0. That was an oversight/misclick. Headbomb {talk / contribs / physics / books} 12:51, 30 October 2016 (UTC)
  • Explanation of the rationale behind this new system. Citation templates often embed one or more identifiers, and possibly a |url=. For scholarly papers, the access restrictions can vary a lot among these sources. While clicking on the |url= seems quite natural (as it spreads on the title of the work), the list of identifiers can look quite cumbersome to readers (not everyone understands what a DOI is, or what is the difference between a PubMed ID and a PubMed Central ID). So, we thought it would be useful if editors had the possibility to indicate which identifiers lead to a free full text, and warn when the |url= is closed, so that readers can avoid going back and forth to try all the links in a citation. As a reader, I do find this very useful! (for instance when I look up a paper in Google Scholar, I crucially need to know which one offer a free full text: I do not want to try all sources). The previous system using |subscription= and |registration= is very ambiguous: in the presence of multiple links in a citation, which link does the access restriction apply to? There are various examples in the wild showing that editors have very different interpretations of these features. It is also quite verbose. Our new system is very compact, it replaces the external link icon with a more informative one. And of course it is optional; editors are free to do what they want. − Pintoch (talk) 22:12, 29 October 2016 (UTC)
  • Keep the locks - I disagree with User:Ozob, as I have found these lock icons very useful in the past. For instance, when completing a research project I have used the locks to determine which journal articles are free to access. One of the five pillars of Wikipedia is "Wikipedia is free content that anyone can use, edit, and distribute" - I believe that in line with this ethos, readers should be able to determine at a glance which references they are able to access. LoudLizard (📞 | contribs | ) 22:15, 29 October 2016 (UTC)
The locks have nothing to do with content. They are an adjunct to a mechanism for content verification. And such verification is needed exactly because most (not all) users can edit most (not all) Wikipedia content freely. 17.255.236.9 (talk) 23:39, 29 October 2016 (UTC)
These locks have nothing to do with editing, and everything to do on whether or not you can access the source in question. Headbomb {talk / contribs / physics / books} 00:06, 30 October 2016 (UTC)
I believe the anon's point is that access to sources is important for verifying the correctness of Wikipedia. This is true, but I don't see it as an argument for (or against) locks. Articles are permitted to cite sources that are not freely available. They are even permitted to cite sources that are not online at all. It may be that some editors are unable to verify the correctness of the citation with a single mouse click, but such convenience is not and has never been the standard set by Wikipedia:Verifiability. The policy says, "Do not reject reliable sources just because they are difficult or costly to access." (WP:PAYWALL). Putting colored locks next to citations encourages editors to think exactly the opposite, and that would be a major and extremely undesirable backdoor change to Wikipedia:Verifiability. Ozob (talk) 03:18, 30 October 2016 (UTC)
There is no such implication of rejection of sources because they aren't free. However, imagine you live in a place where internet access is quite limited. You want to verify something on your phone, but decide against it because the source is probably closed access, since most scientific journals will charge you 40$ to read a paper, and you don't want to waste the bandwidth on something pointless. You miss out on knowledge because that specific article was actually available for free, but you just didn't know and the risk of wasting bandwith wasn't worth it to you. Headbomb {talk / contribs / physics / books} 10:30, 30 October 2016 (UTC)
No, there is such an implication. The different colored locks suggest that Wikipedia views some sources as superior to others. A red, closed lock icon conveys the message, "Wikipedia says this source is no good! Stay away!" while a green open lock icon suggests, "Wikipedia says this source is okay. It's for people like you and me." You might not intend them that way, but they will have that effect nonetheless. For that reason I can't ever see myself supporting lock icons in any form. Ozob (talk) 13:35, 30 October 2016 (UTC)
Do you also consider that adding PDF icons after external links ending in .pdf is a partisan advertisement of PDF files over, say, HTML or DJVU files? Or if you do not oppose using icons, but rather the general principle of flagging access restrictions, would you like to forbid |registration= and |subscription= too? Maybe the locks would be more acceptable if they were all of a neutral color (say blue)? − Pintoch (talk) 13:58, 30 October 2016 (UTC)
Not only is downloading a PDF different than reading a web page, the PDF icon isn't emotional. A red closed lock is. And yes, I do object to |registration= and |subscription=. I don't believe they offer the reader any utility, they are clutter, and they are impossible to maintain.
I would like to note [8], in which Headbomb implicitly agrees with my thesis that a green open lock says, "Go here" and a red closed lock says "Avoid". Ozob (talk) 14:32, 30 October 2016 (UTC)
Green/red doesn't say "go here" and "avoid", it says "You can read this one for free" and "You can read this one, if you have a subscription to the journal, or are willing to pay". The reader decides if they are willing to pay or not. And if they decide they don't want to pay, that is their decision. "Here's a link, but we're not going to tell you if you can read it or not" sends the reader on a wild goose chase. Worse, if they click on DOIs a few times and they happen to be taken to paywalled sources everytime, they may conclude DOIs are always paywalled and will just stop bothering clicking on DOIs in general. Headbomb {talk / contribs / physics / books} 14:41, 30 October 2016 (UTC)
Pardon me while I return to a previous point. I believe the anon's point is that access to sources is important for verifying the correctness of Wikipedia. This is true, but I don't see it as an argument for (or against) locks. Indeed. Imo, LoudLizard was overreaching by implying that the presence of icons in citations is essential to the Wikipedia content the citations verify, or to verification in general, invoking the pillars of Wikipedia etc. which (again imo) makes it sound like a religious argument. However I do believe that readers should know a source has access requirements before they click the link. Whether the proposed scheme is the best way to do that is an open question. Oh, and by the way, pdf icons are useless and possibly redundant. Most browsers have pdf capability, or load pdf plugins in default configuration. 72.43.99.138 (talk) 14:50, 30 October 2016 (UTC)
(ec) I realize that "go here" and "avoid" aren't the intent, but nonetheless that's what they convey. Imagine for a moment that you have not been thinking about journal access for years. You are a high school student who has come to Wikipedia for the first time. How could you possibly interpret a fiery red closed lock except as no? Ozob (talk) 14:56, 30 October 2016 (UTC)

For comparison, Headbomb, when editors on the English Wikipedia cite a source in a non-English language, we often highlight this for the convenience of those whose editors can only read English. For example, I might cite a work like this:

  • Amalvi, Christian. "La Bastille dans l'historiographie républicaine du XIXe siècle", in Dutray-Lecoin and Muzerelle (eds) (2010). (French)

It is, generally, helpful to editors who can't read French. Again, purely for comparison, I find it hard to imagine that citing it like this would encourage editors to click on it:

  • Amalvi, Christian. "La Bastille dans l'historiographie républicaine du XIXe siècle", in Dutray-Lecoin and Muzerelle (eds) (2010). (French) Lock-red.svg

Many normal people would avoid clicking on that. I want readers and editors to click on the links I use for citations, whether to find out and learn more about the subject, or simply to check my work and citations. I don't want to deter them from clicking on links to high quality journals - and automatically putting rather silly big red padlocks on the citations are often going to have just that effect. I'd strongly advise that we take this RfC back a step, and first of all address whether we want coloured padlocks on the Wikipedia - and only then work through the detailed questions here. Hchc2009 (talk) 16:29, 30 October 2016 (UTC)

  • No locks - Adding this in here for clarity (to avoid any potential double-counting, I've made the same point above in the previous section with my justification). Hchc2009 (talk) 07:09, 30 October 2016 (UTC)
  • Keep locks and make changes rather than keeping to some abstract "status quo" – when people who don't use them say "no-one uses them", and others who do say "we do", the argument sort of collapses – thanks to whoever rolled these out, and let's keep tinkering to make sure they're as useful as possible. ‑‑YodinT 09:20, 30 October 2016 (UTC)
  • Conditional support of all locks I think this is a wonderful proposal, and I fully support the intent. However, if implemented it needs to be fully automated with no human intervention required. It needs to support delayed open access. I realize this may be a large issue, but if it doesn't support that I prefer omitting the red lock. Carl Fredrik 💌 📧 10:58, 30 October 2016 (UTC)
Delayed open access can certainly be added to the list. We've been talking of having an icon like Freely available on 20 July 2020 for PMCs, and there's no reason why this couldn't be extended to other identifiers. The color could differ, however. Could you add your opinion under B1?Headbomb {talk / contribs / physics / books} 12:32, 30 October 2016 (UTC)
  • No green lock I'm with RexxS on this. There is no need for an indicator for the preferred (or actual) default of free access and the green lock is a bit of a solution looking for a problem. Nthep (talk) 14:38, 30 October 2016 (UTC)
  • Support locks — on the basis that they are useful for readers and editors. No one in their right mind would think that a source is forbidden because there is a red lock, and we save them time that might be wasted being hit by a paywall. Or we prepare readers to ready their credentials to look up the source — in no way can this scare away readers — the only type of people that are likely to be scared away are those that wouldn't have had access to the source anyway, and are very unlikely to pay for it. In essence we can ignore the idea that anyone would pay to view a source, that just isn't done. (There are studies on this, so vanishingly few access sources like this.) Carl Fredrik 💌 📧 21:54, 30 October 2016 (UTC)
  • No locks. I'm with Ozob. While I am supportive of open access publishing -- my last umpteen papers were all in open access papers -- the point of a citation in Wikipedia is to show evidence for a statement. It has never been Wikipedia policy that such evidence has to be freely available or even online. Bondegezou (talk) 09:52, 31 October 2016 (UTC)
  • No locks. A previous poster stated that the locks mean that readers would "be able to determine at a glance which references they are able to access." They won't do any such thing. They'll be able "at a glance" to tell if the resource appeared free/paid to the editor that added the ref at whatever time/place/other set of circumstances they added it. Whether its free/paid to you, today is a different matter entirely. These things are going to go out of date all the time, so I don't think we should add them in the first place. Chuntuk (talk) 14:55, 31 October 2016 (UTC)
    That is clearly wrong. The locks aren't to be used to flag if it's free to you, they are there to flag if it's free to everyone. If you have a subscription to say Time magazine, you'd need to use the suscription lock because a susbcription was required to access the source. As for things 'changing over time', this is no different than with the current situation. If a journal retroactively changes it access policy from subscription based to free to read (or vice-versa), it is a very simple matter to update the locks accordingly. Headbomb {talk / contribs / physics / books} 15:21, 31 October 2016 (UTC)
    I've heard you say multiple times that bots will make it easy to keep the locks up to date. But Wikipedia:Bots/Requests for approval/OAbot suggests that it's extremely hard to automatically keep locks up to date. There are errors in data sources; publishers and types of citations that need to be blacklisted; and special cases for some sites, like ResearchGate and Academia.edu. OABot's task is difficult even with its limited scope of "only add free locks when absolutely sure". I would not be surprised if there are more lurking problems. Keeping locks current across all citations will be more burdensome and less amenable to automation. Ozob (talk) 02:48, 1 November 2016 (UTC)
    That's mostly because OABot tries to do many things at once, including finding links to (often) non-official sources. Maintaining DOIs and the like based on official journal policy / official databases is much more straightfoward with much fewer cornercases. Headbomb {talk / contribs / physics / books} 03:14, 1 November 2016 (UTC)
    If I understand you correctly, you believe that it would be simple to maintain the lock icons using a bot. Yes? I would like to see this demonstrated. The part where the bot edits articles is easy; but I think the part where the bot disentangles publishers' websites will be hard. Ozob (talk) 23:59, 1 November 2016 (UTC)
  • No locks. I find these dingbats small, hard to visually parse, and the message isn't immediately apparent, at least to me. I guess these would be invisible to visually impaired readers, too. If we must annotate accessibility, make it in clear English rather than inscrutable glyphs. The red also sends a bad message: stop, dangerous link ahead! Also in practice, not all paywalled sites are the same. Some might just display title and author, some add an abstract, and some might display the first page or two of an article. Red stop icons may dissuade readers from otherwise investigating partially available paywalled sources. --Mark viking (talk) 21:53, 31 October 2016 (UTC)
  • No locks. The only justification for icons over text is in a multilingual situation. Fine for the Gent's loo at an airport, but a right pain when you have to spend time searching to find out what the blessed things mean. Those that use them daily may remember, but unless they are documented on the page they just add obfuscation; and if they are documented on the page what is the point of them? Martin of Sheffield (talk) 11:12, 1 November 2016 (UTC)
  • No locks per Ozob, Mark Viking and Martin of Sheffield above. Please don't do this. Doug Weller talk 13:17, 1 November 2016 (UTC)
    No locks isn't an option, really. Green locks have already been deployed, and there's clear consensus to deprecate |registration= and |registration= in favour of this new system because of the issues with the old system. These could probably be hidden via user preferences, however.Headbomb {talk / contribs / physics / books} 13:31, 1 November 2016 (UTC)
    Just looking at this section there have been the following votes:
    • No locks. Ozob
    • Keep the locks LoudLizard
    • No locks Hchc2009
    • Keep locks Yodin
    • [ see below Conditional support of all locks Carl Fredrik]
    • No green lock Nthep
    • Support locks Carl Fredrik
    • No locks. Bondegezou
    • No locks. Chuntuk
    • No locks. Mark viking
    • No locks. Martin of Sheffield
    • No locks Doug Weller
    That is No locks: 7, Keep: 3, No green lock 1. Most of the 64% majority supported text in place of locks, so within this section there is clearly not a "clear consensus to deprecate |registration= and |registration= in favour of this new system". Martin of Sheffield (talk) 13:48, 1 November 2016 (UTC)
    @Martin of Sheffield: Your qualifier "Just looking at this section" is important. Some users who have participated in sections above have not participated in this section, and while it is not definitive what their opinion is regarding having locks at all, I might suggest that they are open to the idea of locks above and beyond "No locks". --Izno (talk) 13:53, 1 November 2016 (UTC)
    "We should have locks" does not follow from "we should deprecate |registration= [in favor of...]". Deprecating |registration= can be done using a text-substitute and the same parameters. The locks are not the only implementation. As for "we've already deployed green locks", I might suggest this RFC is a wider input than that which was had at WT:CS1. --Izno (talk) 13:52, 1 November 2016 (UTC)
    An RFC is not a vote. You need to judge the strength of the arguments, and so far it's pretty much WP:IDONTLIKEIT for those against. The benefits to the reader are clear and obvious, and putting a "(free to read (help))" "(registration required (help))" or "(subscription required (help))" next to each of these links is not viable. Having had zero objections to these locks for more than 2 months shows wide acceptance, and we would would need a viable alternative to deprecate the locks. And there is plenty of support for these locks in other sections (and past discussions). Headbomb {talk / contribs / physics / books} 13:58, 1 November 2016 (UTC)
    Claiming "The benefits to the reader are clear and obvious" is just another way of saying WP:ILIKEIT; I don't see a policy-based reason for lock icons here. Putting a "(free to read (help))" "(registration required (help))" or "(subscription required (help))" next to each of these links is obviously viable in the sense it can be done. Both icons and text equivalents clutter up the references and have the ambiguity problems mentioned above. But the text has the advantage of being immediately understandable and doesn't have the problematic color semantics of the icons. I do appreciate all your work in this and we both want references to be as clear and as helpful as possible for the readers. I just don't think the suggested lock dingbats are the way to go. --Mark viking (talk) 18:26, 1 November 2016 (UTC)
    We live in an icon-based digital world. If you go at Tim Berners-Lee, you'll see a lock on the corner of the article. That it's not immediately clear that you can edit the article if you have an account that's been autoconfirmed isn't an issue, because you can hover the lock and find out that way. Having an explicit "Autoconfirmation required to edit this article" messaged displayed instead of the semi-protection icon would not be an improvement. Likewise, having hundreds of "subscription required" per articles like Quark, often multiple times per citation is not an improvement. That's why we need an icon-based solution. Headbomb {talk / contribs / physics / books} 19:28, 1 November 2016 (UTC)
    You are making many assumptions, starting with the kind of world we live in. Slogans are a turn off. We also don't need any icons; we may or may not agree to use icons as a signal, but nothing is set in stone. Whether icons are an improvement (for the average Wikipedia reader) relative to explicit text is a matter of opinion. I haven't seen the Quark article, but why would anyone use more than one link per citation for the same material (archive links excluded) is a mystery. If there is one or more free links, cite this/these link(s) only, without explanation. If there is one or more non-free links, pick the one(s) that are least onerous (ex. registration instead of limited access instead of subscription), and add the relevant access requirement once. 72.43.99.138 (talk) 00:27, 2 November 2016 (UTC)
    As someone who would prefer icons, No Locks is still definitely an option! That said, the numbers given (No locks: 7, Keep: 3, No green lock 1) miss out Headbomb; taking them into account gives 58% against all icons. Not a clear consensus, but in my opinion it's shown the questions we need to address directly in another RFC, to answer A: do people want consistency (e.g. in Cite Journal, plus Cite News, Cite Web etc. as discussed below, but also Closed access, Subscription & Registration as well as Arxiv, Bibcode & doi), and if so would they be willing to be bound by a !vote B: should we use icons or text. If icons are decided on, the above RFC has pretty strong consensus on the specifics (e.g. visual style, deprecate old parameters, etc.), if not, at least it's decided in a clear cut way, rather than tucked away in the discussion of an RFC that bypasses the question. I don't envy whoever closes this! ‑‑YodinT 09:57, 2 November 2016 (UTC)

There wasn't a consensus to put locks in citation templates, just a bunch of bored editors adding code. KATMAKROFAN (talk) 02:49, 2 November 2016 (UTC)

  • No locks. I'm late to the party, but I agree with Ozob's views about clutter and subtle political statement. Yes, I prefer free sources, but authors and publishers need to make a living, so I'm not bummed by pay sources. I've had to pay DTIC money not because the content is copyrighted but rather somebody had to physically copy the document. I'll probably pay the National Archives $40 to dig another document out of a dusty box in its basement. Most readers are not going to be consulting the references, so the figures would be clutter. Yes, I do consult sources, but I often AGF, too. I spent an hour yesterday trying to track down an obscure 1991 source. Turns out 1993 to present is available online to me for free, but there are only physical copies before 1993. Several nearby libraries carry the journal, but they have unfortunate holes in their collection. That brings me to another point. Isn't there also friction with OpenURL resolvers? Some source may not be free/locked to John, but Sally's institution may have a subscription, so it is free/unlocked to her. Glrx (talk) 17:32, 5 November 2016 (UTC)
OpenURL access is similar to any other subscription/registration access; I don't think that is relevant. However, OpenURL implementations have been indeed inconsistent in my experience, and sometimes result in unexpected access. The latter, though unintentional, may or may not be a copyvio issue. 65.88.88.69 (talk) 20:20, 5 November 2016 (UTC)
  • No Locks. Changing text into icons is making things less clear to the reader - the icons are tiny and much less understandable than the current text. However, from the documentation of the cite templates that the decision has already been made and this has been implemented. So much for consensus.Nigel Ish (talk) 20:36, 5 November 2016 (UTC)
  • [This opinion was previously added to § Visual Design RFC discussion] Withdraw both RFCs. This is way too complicated, and some (non-mutually exclusive) proposed options conflict with each other. For complex proposals such as this I believe the mandate to go either way should be far clearer; but because of this complexity, a fair-to-middling "support" consensus is worth less than a poor-to-fair "oppose" consensus. The onus is on the supporters. Show better cause, and renominate. 72.43.99.138 (talk) 14:46, 9 November 2016 (UTC)
  • No locks: Clutter that does not help with the core task of citation templates, i.e. to locate the sources of cited information. As others have noted, there is no policy-related reason to inform the reader about the (free) availability of sources. In practice, emphasizing availability might contribute to preference of free sources over good sources that have access limitations, which is not a favorable development. – Finnusertop (talkcontribs) 23:05, 12 November 2016 (UTC)
  • No locks: As I said above, use words. All the best: Rich Farmbrough, 00:47, 20 November 2016 (UTC).

Maintenance burden

Can someone speak to the maintenance burden that this creates? Here's a simple example: Articles in Blood are defaultly paywalled for 12 months and gratis (but not libre) after that. So it's October 2016, and I cite something that was published in January 2016. It presumably deserves to be flagged as having a paywall, right? But in January 2017, it's free to read it. So the "costs money" lock is wrong at that point. Who is (realistically) going to update the status? (About 250 such articles from this one journal can be found via Special:LinkSearch on the journal's domain name, but it's probably cited thousands of times with only PMID or DOI links.)

At first glance, if the answer is "the same somebody else that updates every other trivial little maintenance burden", then my first thought is that we should not be posting citation information that we are certain will become wrong/outdated. On the other hand, if the answer is that somebody's got a bot that can search through citations and identify dead URLs, URLs that redirect to paywalls, etc., and update the refs accordingly, then this might be okay. WhatamIdoing (talk) 04:50, 30 October 2016 (UTC)

@WhatamIdoing: the use of locks is optional, and bots will be able do a lot of that maintenance. It'll be relatively straightforward to maintain a list of journals by embargo date. We don't currently have a |doi-embargo-date=, but that could certainly be implemented. We already have that for |PMC=. Headbomb {talk / contribs / physics / books} 10:25, 30 October 2016 (UTC)
@WhatamIdoing and Headbomb: Perhaps just use |access={{show by date|2017|1||subscription|free}} (or whatever the right parameter and value are)? Anomie 16:42, 30 October 2016 (UTC)
  • What about delayed open access journals? If I add a reference to an article published two months ago in a delayed open access journal with a 12-month moving wall and mark it as access=subscription, should I make a note in my diary to change it to access=free in 10 months' time? Or do we need a separate icon, e.g. a lock with a clockface? Or will a bot change the icon for me? If so, do we need a moving-wall=12 months parameter to tell the bot when to act? —Qwfp (talk) 09:14, 30 October 2016 (UTC)
    • Good point: you could also add |url-access-free=date article becomes free here (and |doi-access-free= etc.), with |url-access= as the current, default setting, which would change after |url-access-free= is reached. |url-access-registration= and |url-access-subscription= could be added later if necessary. Editors or bots could then simplify the markup when they noticed, but it would be visible to readers as soon as it becomes free. EDIT: Visually, I would keep the standard icons, but add a clock just after it, with the date as the hover-text, and linking to a page that explains that it's delayed open access. The padlock icons should also link to explanations of what they mean (see CC0 point made above). ‑‑YodinT 09:32, 30 October 2016 (UTC)
      • The problem with access levels that vary over time is not new: it also applies to |subscription= and |registration=. I don't think adding a bazillion of new parameters for embargoes on all identifiers would be very helpful (but |pmc= already supports it though, so it does not sound completely impossible). But as our access parameters are now more precise, this opens the door to automated updates by bots. The task you describe (removing restricted locks when a resource becomes free) is not currently in the scope of action of User:OAbot (currently submitted for approval) but this is typically something we could consider adding. − Pintoch (talk) 10:08, 30 October 2016 (UTC)
  • From my understanding based on what others have mentioned above, using bots, parameters, or both should relieve this maintenance burden. Is this accurate to say? Tony Tan · talk 02:40, 9 November 2016 (UTC)

Phrasing for the last aspect

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

  1. It is confusing to phrase it as whether or not to "autolink". As the example shows, the URL implied by an identifier is always automatically generated and attached to the identifier. The question is the same URL should also be attached to the title if |url= is not set.
  2. The proposal says this is only about default behaviour and that linking the title could be suppressed manually, but this is not possible with anything that has been proposed so far. Are you proposing an additional parameter to control this?

Kanguole 10:51, 30 October 2016 (UTC)

I think the examples make it clear what #1 is about. However, concerning #2, since this isn't implemented and we're trying to see what the community wants, no parameter currently exists. We want to know if this feature is desired, if it is the technical details are fairly easy to sort out.
If autolinking is desired by default, we could have a hierarchy of identifiers (e.g. doi>pmc>bibcode>jstor) and the first free identifier on that hierarchy autogenerates the link, with no need for user input save the flagging of an identifier as free. If a link to an identifier lower on the hierarchy is desired, then the default autolink could be overridden via something like |autolink=bibcode. And in the cases where this isn't desired, it could be suppressed via something like |autolink=no. Whatever is put in |url= would of course take precedence over autolinking.
If autolinking isn't desired by default, then it could always be enabled on a per-citation level via something like |autolink=yes/|autolink=bibcode. Headbomb {talk / contribs / physics / books} 12:25, 30 October 2016 (UTC)
The examples do make the behaviour clear, but this is a long and complex RFC, and people may not read all of it in detail, so headlines matter. I object to the continued description of this feature as "autolinking", because automatic generation of links is not in question. The question is whether these automatically generated links should be duplicated.
The proposal does not include |autolink= or the like, so if it is accepted as is there will be no way to prevent all these duplicated links, unless we later add such a parameter, and then add |autolink=no to all our citations. Kanguole 12:53, 30 October 2016 (UTC)
The RFC is to see if such a feature is desired or not. The exact implementation will come later. Headbomb {talk / contribs / physics / books} 14:48, 30 October 2016 (UTC)
Extra parameters are part of the editing interface, not the implementation, and ought to be mentioned. To return to the lack of clarity, it might help if you replaced each "autolink" with "autolink title". (Adding bullets to the examples woudl also make them clearer.) Kanguole 01:37, 31 October 2016 (UTC)

DOI behavior

An earlier discussion (which I found here) pointed out that DOIs do not correspond to a single URL and hence do not have a well-defined access policy. According to the DOI handbook, a DOI may resolve to multiple URLs. For example, a DOI could resolve to an open access repository in some countries (perhaps due to legal requirements in those countries) and to a closed access repository elsewhere.

Representing this kind of indeterminacy with a single icon is impossible. I am not even sure how easy it is to recognize that such indeterminacy is present. The present proposals seem intended to cover DOIs, but what is supposed to be done about such situations? Ozob (talk) 00:18, 31 October 2016 (UTC)

No doi has ever been shown to resolve to two different levels of access pages. Do you have a real example of such a case? Headbomb {talk / contribs / physics / books} 00:24, 31 October 2016 (UTC)
No. It's a theoretical concern. If others are willing to attest that this does not happen in practice then I would be satisfied. Ozob (talk) 02:31, 31 October 2016 (UTC)
I have never witnessed that in the wild. − Pintoch (talk) 09:39, 31 October 2016 (UTC)
Wonderful! So this is not something to worry about. Ozob (talk) 00:15, 2 November 2016 (UTC)
Doesn't it happen all the time? Researcher publishes journal article that ends up behind publisher's paywall. Journal policy allows author to publish article on website author controls, so author posts free copy. Same document, two URLs, different access. Government employee pens article on government's dime, so the article is public domain. Journal publishes article but keeps it behind publisher's paywall. Anybody can republish the article. Same document, arbitrary number of URLs, different access. Bell Telephone Labs researcher pens article, submits to Bell System Technical Journal and to IEEE rag (which knows it will be published in BSTJ); same text exists in two places; for a time, Lucent made BSTJ open access, same content had free access and available behind IEEE paywall. Nobel Laureate Irving Langmuir publishes his work in the General Electric Journal and in the IEEE during 1914; it's public domain now; Google digitizes and publishes the GE Journal online for free, but PD IEEE article stays behind pay wall. Glrx (talk) 21:27, 5 November 2016 (UTC)
All this is true, but also not pertinent to these RFCs. If I may, what you are describing applies more to the function of the citing contributor. It is up to her/him to find the most accessible source for the material that supports the related claim in wikitext. Readers don't need more than one link. The need one link, or one class of links, (the least onerous) that will help them verify the related claims in the article. Do the present proposals make this task easier? Imo, this also implies that free links should be the expected norm in a freely accessible encyclopedia; any access requirements need be only signaled once if only a single such link or a single such class of links is present. This encyclopedia is supposedly freely editable; if the state of access changes, interested editors can make changes. But that aspect is also not pertinent to these RFCs. 72.43.99.138 (talk) 15:04, 6 November 2016 (UTC)

Scholarly versus popular

Open access has since the inception of the concept in 2002 referred to access to scholarly publications in academic journals. The proposed system above is designed to flag perhaps all citations to academic journals in Wikipedia. The discussion above is framed to invite comment from contributors who use academic citations.

If this system gets adopted in Wikipedia, then soon enough, someone is going to raise the issue of whether the same locks could be used on citations to popular sources. For example, someone might want to know if links to subscription newspapers or magazines are free to read or paywalled. Is there anyone here who is willing to speculate how this likely potential use could play out?

Would people here who support this icon's use for academic content also support its use for popular content? Would anyone here oppose that use, and the application of the "open access" concept to non-scholarly works?

If this concept is something that might be used by people who use any citation, then perhaps all sorts of people should comment on this proposal. If this proposal is something that would restrict non-academic use, then again, perhaps all sorts of people should be invited to comment. I am thinking about what I might say to people who do not use academic citations to explain the extent to which this discussion might be relevant to them. Blue Rasberry (talk) 17:01, 1 November 2016 (UTC)

For 'popular media', the locks would be used pretty much the same way. For example, for a source with subscription required, we'd have something like
This would replace the current (via |subscription=yes)
  • Smith, J. (2010). "Title of article". Time Magazine: 47. Retrieved 2016-11-01. (subscription required (help)). 
or (via placing {{subscription}} at the end of the citation)
  • Smith, J. (2010). "Title of article". Time Magazine: 47. Retrieved 2016-11-01.  (subscription required)
or (via placing {{closed access}} at the end of the citation)
Headbomb {talk / contribs / physics / books} 17:25, 1 November 2016 (UTC)
This would be entirely logical. It was not the intent of the founders of the open access social movement but it seems practical to me. Thanks for mocking this up. Blue Rasberry (talk) 17:51, 1 November 2016 (UTC)
As far as Wikipedia is concerned, I don't think that the distinction between "popular" and "academic" is relevant. The citation system does not exist as a helper to academic research. It is a result of policy (WP:V), which itself is necessitated by the fact that the provenance of wikitext added by Blue Rasberry , for example, or by my IP address signature, is at best, inscrutable. Academic research and publishing involves reputations, careers, and funding; it has its own well-developed verifiability systems and processes, that an anonymous/pseudonymous encyclopedia model cannot and should not match. Especially, because it is geared to a much wider audience. The utility of the proposed schemes have to be judged on that basis, not on the type of reader who is already familiar with citing sources and who uses citation systems as a matter of course. 72.43.99.146 (talk) 14:29, 3 November 2016 (UTC)
More useful, instead, would be some sort of totally different indicator showing that a source is not scholarly, since such sources are typically less reliable; we shouldn't be making it seem that Time or subscription newspapers are comparable to the Journal of American History or the Sociological Quarterly. Nyttend (talk) 23:06, 3 November 2016 (UTC)
While agreeing with that, note that "scholarly" and "not scholarly" should not be taken as synonyms of "good" and "bad". "Scholarly" sources are superior for references specific things, but are not good at all for weighing whether a topic is notable. There are too many "scholarly" looking journals accepting nearly anything, with payment. Time or subscription newspapers are not good sources for surprising things, but they are very good for indicating the topic is of general interest. Very often, Time or subscription newspapers are good as reputable secondary sources, while scholarly journals are good as reliable primary sources (for the facts concluded by their articles). --SmokeyJoe (talk) 23:58, 3 November 2016 (UTC)
However, these RFCs are not about reliability or notability of sources. Let's not complicate things. Being completely agnostic about sources, would the proposed schemes give the average reader proper citation information? or would they be confusing? and, secondly, how do these changes impact editing? if citations are to be encouraged, do the proposals make the task of editors easier or at least more complete? finally, do they make the CS1 programmatic application harder to maintain relative to the supposed merits? Is the increased complexity worth it? Afaic, up to now the RFCs are ambiguous as far as these questions are concerned. 72.43.99.138 (talk) 15:28, 4 November 2016 (UTC)
  • This does raise the question of papers which allow limited access - e.g. 10 articles per day (and use clickbait to make you go over!).. These should be noted too, and hence some kind of indirection is probably in order. E.G. access=open, access=paid subscription, access = New York Times : here New York Times can be a virtual redirect to "(10 free pages per day, then subscription)" which could be changed if the newspaper's policy changes. All the best: Rich Farmbrough, 00:53, 20 November 2016 (UTC).

Proper closure?

Is this a proper closure? I reverted Editor Headbomb's closure of this RFC (and would have reverted the other had not another editor beaten me to it) not for the conclusions that Editor Headbomb reached but because that editor is not an uninvolved editor. My revert was reverted by another with the claim that there is no 'policy' stating that closures can only be done by uninvolved editors. That is probably correct, however, closure of an RfC by the originator seems to me to be much less desirable than the ideal because we presume (I think) that when an uninvolved editor closes an RfC, it is closed without bias. Better, I think, to revert this closure and allow an uninvolved editor to close it. —Trappist the monk (talk) 00:15, 1 December 2016 (UTC)

Just my thoughts as the other editor to undo the close. The policy is here: WP:RFCEND, in particular “It can be formally closed by any uninvolved editor.", with the other possibilities (withdrawn if unlikely to succeed, moved to another venue, closed by agreement) being far more restrictive and not applying here. This seems particularly appropriate here as such a complex and involved discussion – it is the sort of discussion that might be better closed by an admin.--JohnBlackburnewordsdeeds 10:15, 1 December 2016 (UTC)
I think it is not a proper closure. Headbomb should have respected the undo of his first closure and not gone ahead and redone it. That is overruling behaviour. The close is a poor one, since it's based too heavily on vote counts (see WP:RFCEND for that as well), and not on strength of arguments. Headbomb not only created the RFC but also replied to !votes. That's fine, but doing it disqualifies any editor from taking a neutral view of the strength of arguments. Your reversion was fine, Trappist the monk, and I think it would be fine to do it again. --Stfg (talk) 11:56, 1 December 2016 (UTC)
@Stfg: For the record, Editor Headbomb did not revert my revert of the closure; Editor Amaury reverted me.
Trappist the monk (talk) 13:51, 1 December 2016 (UTC)
Trappist the monk: I know. But he did revert JohnBlackburne's original undoing of his first close. --Stfg (talk) 16:22, 1 December 2016 (UTC)
Sorry, but that is just not true. Look at this page's history from 15:45 30 November 2016 onward. Editor Headbomb made two edits: one a 15:45 and the second at 16:18; neither of those edits revert Editor JohnBlackburne's revert.
Trappist the monk (talk) 16:35, 1 December 2016 (UTC)
I stand corrected. The 16:18 was a close of the second RfC, and he may have been typing it and not noticed the revert of the first before saving. --Stfg (talk) 17:50, 1 December 2016 (UTC)
The close is improper and will likely lead to more drama. Better to wait until someone uninvolved closes it. User:Amaury deserves a trout. I will revert the closure if no one else does. — Martin (MSGJ · talk) 12:31, 1 December 2016 (UTC)
Agreed per JohnBlackburne and Stfg. GenQuest "Talk to Me" 13:19, 1 December 2016 (UTC)

RfC: AWB bot ref reordering

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

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

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

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

Survey: AWB bot ref reordering

(no threaded discussion)
  • Comment - Note to closer: I strongly feel that a no-consensus result here should mean no AWB reordering; i.e. the consensus burden is on those who wish to reorder. Consensus should be required to make a controversial change, and that change occurred in 2009. ―Mandruss  21:18, 19 November 2016 (UTC)
  • Comment I don't think a "let's pretend" (as in "Let's pretend it is 2009") RFC is a good idea. I would rather discuss either the substantive issue or a way forward. All the best: Rich Farmbrough, 22:47, 19 November 2016 (UTC).
  • No. There should be no automated re-ordering of refs to retain the chronological appearance of footnote numbers, particularly not over objections. Previous discussion: Nov 2016, Nov 2016, May 2015, Feb 2015, Feb 2014, July 2010, May 2010, April 2010. The feature was added to AWB in 2009 with very little input. It should have been discussed more widely, because editors may add refs in a particular order for editorial reasons. A simple example:
Mary likes cake, but John doesn't.<ref name=Mary/><ref name=John/>
Someone will argue that we could place the Mary ref inside the sentence, but when there are lots of refs and several clauses, it looks cluttered to do that. And there may be other reasons for the order, including that the first ref is a primary source and the second a supporting secondary one; that the first discusses the issue more clearly than the second; or that the first is the source most experts in the field will expect to see.
According to WP:AWBRULES, "If challenged, the onus is on the AWB operator to demonstrate or achieve consensus for changes they wish to make on a large scale". Study 329 is one example of what happens instead: AWB reordered refs on 4 May 2015. I moved them back. A second AWB editor reordered them on 5 May. I added bots deny to stop it. The second AWB editor removed bots deny on 9 May. A third AWB editor reordered the refs again on 9 May. SarahSV (talk) 00:15, 20 November 2016 (UTC)
  • Yes/Reforder Like I said before, refs should be in order. If you have [2][1][14][4], you're telling the reader to jump around a list of reference for no good reason. [1][2][4][14] is the natural way of presenting things. Now if some specific article warrants deviation from this for some obscure reason, then deny AWB on that specific article, but this is a legit fix in 99% of cases. The usual workaround is to use {{R}}, which AWB will leave alone. The <1% of articles that warrants a deviation from this behaviour shouldn't block efforts to improve the presentation on the >99%. I've cleanedup thousands of articles making those fixes for the last 6 or so years, and I've had 2 complaints. A fail rate of 2/10,000+ is more than acceptable. Headbomb {talk / contribs / physics / books} 00:35, 20 November 2016 (UTC)
I wonder, Headbomb, if there is some misunderstanding here as to how cite numbers are used as cites are in order until someone using AWB comes along and changes them. The cite numbers relate to the order the cites were placed in the article as a whole, not necessarily in the sentence in question. When a cite is used more than once, the number remains the same throughout the article, so the numerical order of cites may appear disjointed in places. Sometimes there may be several cites in one sentence, and if placed next to the information they are citing (which is often done) then the sentence may read "Splot was born in Swansea,[13] on 13 March 2000,[7] to parents John Splot, an organ grinder,[5] and Mary Splot, a Suffragette.[14]" This is appropriate usage, and no AWB would change the sequence order, and the reader could check each item they were interested in by clicking on the number, and going to the relevant citation. However, in order not to inhibit reading flow unnecessarily, we encourage editors to place all the cites at the end of the sentence if none of the statements are likely to be contentious. When placing them at the end of the sentence or paragraph we keep them in order per WP:CITEFOOT: "it is usually sufficient to add the citation to the end of the clause, sentence, or paragraph, so long as it's clear which source supports which part of the text." When someone using AWB shuffles the cites, they are no longer logical or natural, and the reader may well end up confused as to which cite belongs to which part of the sentence, because the natural order has been disturbed. It seems that at the moment when cites are grouped at the end of a sentence some well-meaning AWB user will shuffle the order without realising what they are doing. We should either stop AWB reshuffling the cites, or change our guidance on grouping cites at the end of sentences. SilkTork ✔Tea time 13:57, 21 November 2016 (UTC)
[Since SilkTork has repeated this in the #Clarification please section I have moved my reply there.] All the best: Rich Farmbrough, 20:24, 21 November 2016 (UTC).
  • Yes As I said earlier, whatever purpose the non-chronological ref order serves may not be clear to the reader. The benefits of doing so, as stated by headbomb above, are clear. Pppery 00:54, 20 November 2016 (UTC)
Poppery, I have replied to Headbomb's comment, making reference to our existing guidance on how cites are placed at the end of a sentence. Does that make it clearer? SilkTork ✔Tea time 13:57, 21 November 2016 (UTC)
  • Yes per my discussion below, especially noting that article editors (assuming a consensus) can override the reordering. Ultimately there is no harm and having cites in chronological order should be seen as naturally more convenient for the reader. Stevie is the man! TalkWork 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).
  • Supplementary Various editors have said that they arrange reverences in order of: i) relevance, ii) importance, iii) date and iv) the items they support - as well of course as the industry standard v) numerical order. While these schemes may have something to recommend them (except when they are WP:SYNTH) I see no way for a reader to know in advance which of the five applies, or whether it is actually vi) happenstance. Without this the value of these alternative schemes is pretty much moot. All the best: Rich Farmbrough, 19:55, 4 December 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: [9] 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)
  • 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)
  • No Only a human being can determine the priority order of citation placements. At the very least, I can see an automated ordering wreaking havoc at DYK when reviewers start rejecting nominations because a citation is not readily where it should be. Oh, please, let's not go down this road. — Maile (talk) 02:41, 5 December 2016 (UTC)
  • No - there may be reasons for the order, and only a human being has the ability to determine this. עוד מישהו Od Mishehu 15:47, 7 December 2016 (UTC)

Notes

  1. ^ 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! TalkWork 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! TalkWork 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! TalkWork 00:58, 20 November 2016 (UTC)
    Which of the following is incorrect? 1. Highly controversial changes require clear consensus. 2. No clear consensus has ever existed for AWB reordering. 3. A developer with the power to control bot-executed code should be expected to be aware of 1 and 2. 4. The consensus-free code still remains in AWB.
    I cannot escape the logical conclusion that (1) someone has acted in bad faith, or (2) someone should not have control of the AWB code. As I've said elsehwere here, I will gladly retract all such claims if the reordering is removed pending consensus to include it, per item 1. ―Mandruss  01:16, 20 November 2016 (UTC)
  • It would be useful to have some statistics:
  1. How many refs have been reordered by AWB?
  2. How many were out of order due to the refs renumbering, and how many were placed out of order?
  3. How many cases have been documented where the re-ordering was alleged to be wrong?
Secondly it would be useful to understand if people think that, as a matter of style:
Reference numbers should be ascending:
  1. Always
  2. Except where there is clear priority between references
  3. Let them be random
Personally I subscribe to either the first or second, tending toward the first. If the distinction is sufficiently strong to warrant out-of-order numbers then there may well be a better way of handling it.
All the best: Rich Farmbrough, 23:59, 19 November 2016 (UTC).
Like I say above, AWB ref reordering skips refs separated by an HTML comment, so editors (assuming a consensus) can decide to have the footnote numbers out of order to their heart's content. Stevie is the man! TalkWork 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)
@Mr Stephen and Mandruss: This study found that (student) readers assume Wikipedia refs are ordered by importance / quality. Nikkimaria (talk) 00:41, 2 December 2016 (UTC)
I found that article painful to read on a tablet, I will have a look at it on a proper screen or dead tree later. It's obviously related, but seems to a very small study (30 freshers), and doesn't really address the issue under discussion here. At first sight (please correct me) it seems to be that the participants started – reluctantly – at the top of the endnotes, rather than looking for a reference to support a particular viewpoint. Mr Stephen (talk) 18:39, 2 December 2016 (UTC)
@Mandruss and Nikkimaria: I found it an insight into the cohort's inability to read an article (though maybe they simply wanted to finish the task and get a mark) but possibly not much help to us here. Mr Stephen (talk) 20:59, 3 December 2016 (UTC)
  • I think this discussion would go better if a couple of points are sorted out at the outset, so that we are all "on the same page".
First, let's have an understanding of the basic terminology and concepts. E.g., what (I believe) we are talking about is whether instances of (e.g.) [1][2][3][7] are better than [3][1][7][2]. (That is, I believe the issue is about the ordering of consecutive strings of numbered links, not the ordering of such links through the whole article.)
Second, we should be clear that those are not "references", they are HTML links. But not links to references, as what is contained in the the mis-named <ref>...</ref> entities is not necessarily a "reference". (Yes, I know, it seems most of you use them that way, but that is certainly not the only way. Hear me out; such distinctions are necessary to avoid ambiguity, confusion, and conflict.) What the <ref>...</ref> tags create are notes (footnotes, endnotes, whatever). What you use them for (whether "references", "citations", "explanatory notes", etc.) is largely irrelevant for this discussion, but we might avoid getting stuck in conceptual dead-ends if we use the most general term, "notes". And "note-links" (or "footnote-links") for the specific element of concern here.
Third, this RfC would be better formulated as whether having strings of note-links in ascending order is merely preferred, or should be mandatory. If that is resolved one way or the other then appropriate measures can be considered, such as adjusting AWB.
Fourth, "random" is not an alternative to "ascending". Notes, and the links to them, are numbered in the order the s/w finds them. Note-links come out of order where a named ref (the <ref=name ...> entity) has been used to point to another instance. (That is, to "re-use a reference".) Don't use named refs, and I believe the ordering problem goes away.
Which then leads us back to other potential problems that underlie the issue considered here. ~ J. Johnson (JJ) (talk) 02:54, 20 November 2016 (UTC)
J. Johnson, yes, ref name is what causes this problem. But if we don't use it, AWB editors add it. SarahSV (talk) 13:13, 20 November 2016 (UTC)
SV: I think you are referring to this automated merging of notes (<ref>s) deemed to be duplicates, replacing one with a named ref. I think that is a problem that needs to be dealt with. (I often modify my notes so they are not duplicates, to avoid this merging.) But behind that is the challenge of "re-using" entire biblographical entries ("full citations"). In the end I think it comes down to: how do you feel about the use of "short citations"? ~ J. Johnson (JJ) (talk) 23:04, 20 November 2016 (UTC)

Compromise proposal: AWB bot ref reordering

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

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

PROPOSAL:

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

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

Van Halen's Running With The Devil

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

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

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

Actively ask shared IP operators/people related to organization used by shared IP for abuse info?

Should we actively attempt to get abuse info from shared IPs?
I feel like the ability to inform operators or managers related to shared IPs of when someone using it is misbehaving would quickly cause abuse from the shared IPs to become very manageable.
My specific thoughts were asking schools, as we have a large amount of abuse problems from the school IPs and letting the people who work with the students (who are likely the ones doing the abuse) deal with the problems would work out a lot of problems.
However, the current templates mention that the abuse info parameter should only be used if it's requested by the educational facility.
Frankly, I think shared IP blocks, instead of requiring accounts completely, should be:

  1. temporary as the organization is contacted for info on what should be done
  2. permanent for organizations that have refused to give abuse info or have no visible abuse info
  3. temporary but kept until contact info can actually be found (though this second reason should have an option in the block template so if someone there wants to rectify this they know how to)
  4. technically permanent for organizations that do not respond

The only minor issues I have with this way is worries of disproportionate punishment and if we should be involved in their affairs, but I feel that both can and likely would be dealt with by the actual organization, once again. I am curious about how contacting the organization should be done by Wikipedia. My suggestion is that an administrator contacts the school via their abuse info as part of the ARV process.

Thoughts? NOTNOTABLE (talk) 17:39, 1 December 2016 (UTC)

I believe that most orginizations would probably deal with abuse from their computers if they know it's happenning; this would be a gain for both us (as the abuse will stop) and them (as they won't need to worry about blocks onece the issues stop). עוד מישהו Od Mishehu 17:51, 1 December 2016 (UTC)


Most organisations have an abuse@ address listed in their whois. I have dealt with a number of school IT administrators in the last ten years. In my experience the vast majority don't care and will do nothing but ask for a block or block Wikipedia from their schools. We can do the former without them. ISPs, who make money from customers, usually simply don't care. -- zzuuzz (talk) 18:10, 1 December 2016 (UTC)
The vast majority may not care, but the small minority should be considered here. I'm not talking about sending repeated complaints - only enough to allow them to know that there is a problem from their orginization and that we are interested in helping them deal with it. עוד מישהו Od Mishehu 11:51, 7 December 2016 (UTC)

Stand-alone lists being nominated as Good Articles

--Redrose64 (talk) 22:54, 1 December 2016 (UTC)

Note that one of the three proposals in this RfC involves creating a separate "Good Lists" rating and process independent of the GA process. BlueMoonset (talk) 18:15, 5 December 2016 (UTC)
I made a suggestion about good lists a while back and got brushed off. I'm glad somebody started that. White Arabian Filly Neigh 23:45, 6 December 2016 (UTC)

template:TOCleft

Hi – it has always bothered me that the Contents box on every page results in a large whitespace to the right. I have found that the template:TOCleft directly beneath the introduction, (above the first subheading), allows the first sub-paragraph to wrap around the contents box, making for a much neater presentation. Examples are Sibsey Island, Barry Egan (hurler) and Justin Lefkovitch. It does not work in every case for some reason, (the first sub-paragraph occasionally wraps above the contents box). I propose that TOCleft be written into the code of the automatically generated contents box so the Contents box is always wrapped around. MarkDask 13:24, 2 December 2016 (UTC)

Absolutely not. The advice given at Template:TOC left#Cautions and Help:Section#Floating the TOC exists for a reason; floating the TOC wrecks the formatting on narrow screens, on bulleted lists, on articles containing infoboxes which have the potential to display longer than the lead (which is the majority of articles), and in any instance when it causes the TOC to overrun the first section heading. Don't assume that every reader is using the same screen setup as you. Wikipedia's layout rules may appear arbitrary, but they're the product of fifteen years of experimentation. ‑ Iridescent 14:34, 2 December 2016 (UTC)
Oops - I should have read up on the template. Thanks for the info. MarkDask 14:51, 2 December 2016 (UTC)
So would I be correct in assuming that you're withdrawing your original proposal? I'd close it, but I just want to make sure that we're all on the same page before doing anything. Kurtis (talk) 02:55, 6 December 2016 (UTC)

Proposal: Subpages tool in userspace, and possibly other namespaces

In 2013, I made a proposal to add a "subpages" link in the tool section of the Wikipedia sidebar. The idea is that this would allow easier access to subpages created by a given user. It's been almost four years since I made that post, and no such feature has been implemented on the English Wikipedia as of yet. I've decided to resurrect this proposal, which received unanimous support at the time, in the hopes that it actually gains some genuine traction towards becoming a reality. Is there anybody who would object? If not, then how can we get the subpages link added to the toolbox? Kurtis (talk) 02:40, 6 December 2016 (UTC)

@Kurtis: WP:MOREMENU has a subpages link. If you want to add it to your toolbox you can add something like
mw.loader.using( 'mediawiki.util' ).done( function () {
	
	// Subpages of current page
	mw.util.addPortletLink(
		'p-tb',
		mw.util.getUrl( 'Special:PrefixIndex/' ) + mw.util.wikiUrlencode( mw.config.get( 'wgPageName' ) + '/' ),
		'Subpages',
		't-subpages',
		'Subpages of this page',
		null,
		'#t-recentchangeslinked'
	);
	
} );
to your common.js. I can make the above into a user script if desired. — JJMC89(T·C) 05:35, 6 December 2016 (UTC)
But why go through the hassle? Why not just have the subpages link by default? Kurtis (talk) 07:32, 6 December 2016 (UTC)
You just need a link to Special:PrefixIndex/User:Kurtis/. --167.58.90.46 (talk) 19:27, 7 December 2016 (UTC)
And an easy way to get that link is to look at the contributions for a user, and click "Subpages" in the box at the very bottom. That works at enwiki and commons, but may not work at other projects. Johnuniq (talk) 02:11, 8 December 2016 (UTC)

Idea lab

Ping Users

We need some kind of Ping user button. Half the time in a discussion, I have to go through pages upon pages of my contribs to find where I replied on a talk page to see if another person has replied back to me.. and I don't get a notification when they reply to me because they don't use the Ping button. There needs to be some kind of button or easily available way to just hit "Ping" or "reply to user". Or maybe there's an easier way and I am not privy to it. PS please ping me so I see your reply ;) --Jennica talk / contribs 02:28, 22 November 2016 (UTC)

Jennica, that might be a good idea, but even then I don't think the presence of a button is likely to encourage many more editors to use the ping functionality. And there are people who don't like being pinged all the time. A specific solution for your particular case might be to modify your signature so that it says "ping me" or something of the sort. That way anyone replying to your comments will be know that you would like to be pinged. – Uanfala (talk) 14:32, 25 November 2016 (UTC)
@Uanfala: ahh, I didn't think of it like that. I wish we could have a link you could put in your signature where it would insert the ping code. --Jennica talk / contribs 22:46, 25 November 2016 (UTC)
@Jennica: do you mean {{ping|Jennica}}? A button would probably be just as much effort as typing into a template. Icebob99 (talk) 15:54, 25 November 2016 (UTC)
@Jennica:@Icebob99:. A button would be better, I think. It's 1 keystroke instead of 10+ and it prevents typos when pinging people with less-than-simple usernames. Like "Bangabandhu", for example. Yintan  14:44, 26 November 2016 (UTC)

Recent changes page: show count of characters changed, not difference in article size

This may sound like a subtle difference, but as of late while looking at recent changes for vandalism, I've noticed some edits that show as a low numbers of characters changed, sometimes even zero, even though there were clear changes to the article. Here is one recent example; if you view article's history you'll see "0" for the size difference - which is completely accurate, the editor replaced one character with another. Or in another case, some IP vandalism tonight - the article's history page indicates that this edit added one character - again, true, but a significant number of characters were changed.

Would it be possible to have the length of the diff indicated in the summary instead of the difference in article length? --Mr. Vernon (talk) 05:36, 26 November 2016 (UTC)

@Mr. Vernon:Sorry, I don't understand. How is the length of the diff different from the length of the changed article? If a vandal changes "20 july" into "20 june", won't both lengths say 0 characters difference? Yintan  14:26, 27 November 2016 (UTC)
@Yintan: In that case the length of the diff should be four characters (remove "ly" and insert "ne"). --Mr. Vernon (talk) 14:35, 27 November 2016 (UTC)
@Mr. Vernon: What if I changed 21 July to 12 July? Or where words are anagrams of each other, how would the software know that words had changed when characters hadn't? Even more broadly, what if a 24 character sentence is replaced with another, that contains 50% of the same characters? Wouldn't reading that 12 characters have changed be kind of meaningless, compared to reading that the length of the article is the same? Sam Walton (talk) 14:40, 27 November 2016 (UTC)
I think "length" is the wrong word in this case. "Number of changed characters" might be clearer. Yintan  14:49, 27 November 2016 (UTC)
See Delta encoding which explains how source control systems typically store differences between large text files (code in this case but it applies to any form of text.) Diff may give you some more readable output, but that's a specific implementation of delta encoding. I'd propose leveraging, if possible, what already exists in the Wikipedia code base, but that's getting into technical details. I am of course assuming that Wikipedia uses delta encoding; if not then generating a diff on the fly with an agreed-upon algorithm for how to handle "21 July" to "12 July" (which could be anything from "1" - moving a character - to "4" - replacing two characters with two other characters - or more depending on implementation.) --Mr. Vernon (talk) 15:01, 27 November 2016 (UTC)

Automatic 'shared/static IP' template bot

During my vandal hunting I've noticed that, when dealing with vandalizing IPs, adding the {{shared IP}} template to their Talk page usually stops them in their tracks. When they see their WHOIS info pop up about half of them seem to think "O shit, I'm not that anonymous" and stop vandalizing. So, what about a bot that would automatically add the template with WHOIS info on those Talk pages once they've reached (for example) a level 2 warning? Maybe it could be an extra task for ClueBot? Yintan  14:32, 26 November 2016 (UTC)

Disparity

Requirements for deletion: none, you can delete whatever you want and then people need to individually resource and justify everything when they undo your vandalism. Adding something: painstaking process, resource everything, justify everything on the talk page, inevitable edit warring, insults and ad hominems, constant stress.

This is a big, big problem. Some guy deleted a sentence in a wikipedia page which had been there for almost four years, without proof, despite the phrase being factually correct. It took several weeks and edit-warring and someone getting banned to even get it back to how it was before his vandalism. This is ridiculous. EVERY CHANGE, whether deletion or adding, should be discussed on the talk page and justified. UtherPendrogn (talk) 13:11, 27 November 2016 (UTC)

@UtherPendrogn: Discussing every change on a Talkpage first would slow Wikipedia's development down to a crawl. Furthermore, it would generate even more vandal warnings since a lot of editors wouldn't do it anyway. Because where do you draw the line? A simple typo fix can go without discussion? What about changing 1961 into 1962? And why discuss a deletion, or addition, if it's clearly within Wikipedia guidelines? Etcetera. By the way, which article and sentence are you referring to in your message above? Yintan  14:21, 27 November 2016 (UTC)
It's been dealt with, so there's no point. If you want to see an example of it, go on to every single article of this "encyclopaedia". Perfectly valid facts are deleted, yet unsourced lies aren't corrected. Perfectly valid facts can't be added either. Methamphetamine is factually similar to amphetamine, but if I added that fact to the page, it would be deleted within an hour. Hell, let's put that to the test:
https://en.wikipedia.org/w/index.php?title=Methamphetamine&action=history UtherPendrogn (talk) 14:34, 27 November 2016 (UTC)
@UtherPendrogn: No, there is a point, I want to see your previously mentioned example for myself. And adding an important claim without a source, as you did in Methamphetamine just now, is against WP policy. WP:V and all that.... Yintan  14:38, 27 November 2016 (UTC)
It's not a claim, anyone who went to secondary school knows it's true. http://patentimages.storage.googleapis.com/EP0371253A2/imgb0001.png UtherPendrogn (talk) 14:40, 27 November 2016 (UTC)
Oh, it's TRUE? Well, in that case, why do we bother with references and citations at all? Seriously, that's just not how Wikipedia works. Add a reliable source and you can add anything to any article. But without it, you'll be challenged. Quite simple, really. Yintan  14:45, 27 November 2016 (UTC)
And where do you stop?
Methamphetamine[citation needed] (contracted from N-methylamphetamine[citation needed]) is a strong[citation needed] central nervous system (CNS)[citation needed] stimulant[citation needed] that is mainly used as a recreational drug[citation needed] and less commonly as a treatment for attention deficit hyperactivity disorder[citation needed] and obesity[citation needed]. Methamphetamine was discovered in 1893[citation needed] and exists as two enantiomers[citation needed]: levo-methamphetamine[citation needed] and dextro-methamphetamine[citation needed]. Methamphetamine properly refers to a specific chemical[citation needed], the racemic free base[citation needed], which is an equal[citation needed] mixture of levomethamphetamine[citation needed] and dextromethamphetamine[citation needed] in their pure amine forms[citation needed]. It is rarely prescribed[citation needed] due to concerns[citation needed] involving human neurotoxicity[citation needed] and potential for recreational use[citation needed] as an aphrodisiac[citation needed] and euphoriant[citation needed], among other concerns[citation needed], as well as the availability of safer substitute drugs[citation needed] with comparable treatment efficacy[citation needed]. Dextromethamphetamine[citation needed] is a much stronger CNS[citation needed] stimulant than levomethamphetamine[citation needed]. Methamphetamine is similar[citation needed] to amphetamine[citation needed] and the two are sometimes confused for one another[citation needed].
UtherPendrogn (talk) 14:48, 27 November 2016 (UTC)
Don't play dumb and don't edit my replies, thanks. Yintan  14:54, 27 November 2016 (UTC)
I'm not playing dumb. It's ridiculous that idiotic statements go unsourced, yet even the most basic, secondary-school level chemistry facts don't pass without excessively pedantic sources. UtherPendrogn (talk) 14:56, 27 November 2016 (UTC)
Unsourced "idiotic statements" should be removed. Simple, too. Yintan  14:58, 27 November 2016 (UTC)
They aren't. This isn't a utopia, you put far too much trust in "the system". Plenty of glaring mistakes in articles I've seen. UtherPendrogn (talk) 15:04, 27 November 2016 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────@Yintan: A reliable source isn't enough for inclusion. See WP:NPOV. In any case, this is really about a dispute at Fuck and I've blocked the OP for a edit warring. Doug Weller talk 15:26, 27 November 2016 (UTC)

@Doug Weller:Of course, and there are other considerations too, but I didn't want to link to all guidelines here Face-wink.svg. Anyway, I had just about given up on this thread, WP:NOTFORUM, so it's a good thing it ends here. Cheers, Yintan  15:32, 27 November 2016 (UTC)
[citation needed]. You have no proof it was about Fuck, since it isn't. UtherPendrogn (talk) 15:42, 28 November 2016 (UTC)
Earlier you wrote: If you want to see an example of it, go on to every single article of this "encyclopaedia". That is completely false. We have five million articles. Most of them are uncontroversial. There are probably more than a million where no information has ever been removed for any reason. Some articles are controversial and require discussion of many things but it would be an absurd burden on editors to demand that everything on all articles must be discussed on the talk page. Consider for example the tables in 2016 WTA Tour#Schedule. They are updated hundreds of times during a tennis season. Do you really want editors to discuss on the talk page before every time they add the name of a player who won or lost a match? It's all easy to verify on the website of the tournament or WTA, and there are never conflicts about it. PrimeHunter (talk) 20:58, 28 November 2016 (UTC)

Complete Reliability/Factual Accuracy Solution

  • Problem: Wikipedia acknowledges that the encyclopedia should not be used as a primary source for research, either academic or informational. According to Academics [11][12] [13] [14] [15] [16] [17] & Harvard [18] ,Carleton [19],livescience [20] ,forbos [21] ,guardian [22] ,nature [23] wikipedia articles are "not enough RELIABLE" for academic research/study.some educational institutions have banned it as a primary source while others have limited its use to only a pointer to external sources. [24] [25] [26] . And there is "Lack of methodical fact-checking "...Inaccurate information that is not obviously false may persist in Wikipedia for a long time before it is challenged. [27] .. For a list of hoaxes that have occurred on Wikipedia, see Wikipedia:List of hoaxes on Wikipedia .
  1. Accuracy is the biggest problem about Wikipedia . Anyone can add subtle nonsense  or erroneous information to articles that can take weeks, months or years to be detected and removed (which has been happening since at least 2002). Deliberate hoaxes can also be perpetrated.
  2. Even unregistered users are capable of this. For example, some one can just come and edit this very page and put in "khats r four doughs onlee" or add mention of some unrelated topic: ===like how great pineapple pizza is===
  3. Dross can proliferate, rather than become refined, as rhapsodic authors have their articles revised by ignorant editors.
  • Who would benefit: all wiki reader & editor . 18 billion user every month . pageview 18 billion every month.[28][29][30]
  • Proposed solution:I have a five step solution .

1.(Easy reporting): by Making it much easier for people to report "factual accuracy", misinformation faster. google,google news,facebook [31] ,twitter,bing everyone have a interactive reporting & feedback system .We can have a interactive reporting in wikipedia similar to google feedback [32] (with screenshot ; highlight issue in "yellow" & Black out private information private information) for highlighting a specific block/line . In wikipedia articles , we can have a [Report] link in every section ,beside [Edit] link . In reporting , there should have features for adding ,section dispute template & inline dispute template with Citation needed template & Accuracy disputes category., There are several noticeboards (for  inaccurate content  &  factual inaccuracy) at which accuracy disputes may be listed to gain the views of other editors, particularly the Dispute resolution , Fringe theoriesreliable sourcesno original researchneutral point-of-view, Conflict of Interest and biographies of living persons noticeboards.All report should go there or open a request for mediation (RFM) & Requests for Comment . some report should go here and here.In this way, we have a possibility  to get 18 billion "factual accuracy" report in every month  :) . [33][34][35]

2.(Algorithm): Leverage algorithms and artificial intelligence.Stronger detection Algorithm .Facebook already using machine learning—different algorithms than the ones that drive the Trending section—to try and catch misinformation on the platform . We can have a Algorithm similar to google,facebook [36] [37][38] [39] [40] [41] & twitter  [42] fake news algorithm .When a user create a article with Factual Accuracy/misinformation,claim,Fringe theories , original research ; without proper citation ; then the Algorithm should automatically add section dispute template & inline dispute template with Citation needed template & Accuracy disputes category. ...from reliable sources guideline , we can create a algorithm for "cross check ". when a editor insert a citation then it & will automatically start cross-checking the content with other similar reliable source & will create a " reliability meter ".

3.(Third party verification): Over the last several years, fact checking has come into its own. Led by many respected fact checking organizations like the International Fact-Checking Network, rigorous fact checks are now conducted by more than 100 active sites, according to the Duke University Reporter’s Lab. They collectively produce many thousands of fact-checks a year, examining claims around urban legends, politics, health, and the media itself. Google added a fact check tag on Google News in order to display articles that contain factual information next to trending news items.[43].Facebook using snopes [44] .snopes.com is a well-known resource for validating and debunking such stories in American popular culture, receiving 300,000 visits a day. [45] The Reporters’ Lab at Duke University maintains a database managed by Mark Stencel and Bill Adair of fact checking organizations. The database tracks more than 100 non-partisan organizations around the world. Articles are also examined based upon whether the site examines transparency of sources and methods, tracks political promises, examines all parties and sides, and examines discreet claims and reaches conclusions.

4.(User Right): We can have a user right group "Fact Checker". This user group will have some expertise & tools .Or, this right can be added to Admin group. they will get notified , when point 1.(Easy reporting) will happen , mainly for good , A ,GA &  B  articles. They will try to solve Factual Accuracy from these category as much as they can .

5.(reliability meter): in visual editor cite templates , we can add reliability meter . from the help of point 2.(Algorithm) ; every reader will see "reliability meter " , when they click in the "citation " & in "REFERENCES" .there is third party databases [46] [47] [48] [49] or we can create our own . when Reliability/Accuracy 100-81% ; we will see Red dot . when Reliability/Accuracy 80-61% ; we will see Red dot . when Reliability/Accuracy 60-50% ; we will see Red dot . We can have a system that designed to flag all citations to academic journals in Wikipedia, like Green (free to read): Freely accessibleFreely accessible ; Yellow (free, with conditions): Free registration requiredFree registration requiredFree registration requiredFree registration requiredFree registration requiredFree registration requiredFree registration required ; Red (not free): Paid subscription requiredPaid subscription required

  • Proposer:--- md masum (talk) 17:38, 29 November 2016 (UTC)
Here are just a few of the thoughts that this set of proposals has prompted.
  • I am not sure that using services which collectively provide "thousands of fact-checks a year" would be a lot of use on a web site which has hundreds of thousands of edits per day. I am also not sure that those services would be willing or able to take on the task of checking Wikipedia edits, as doing so would swamp them, leaving them unable to do any other fact checking.
  • We have algorithms to detect likely misinformation: they are called edit filters. If you have ideas for specific algorithms which would be better than the existing ones, then by all means suggest them.
  • You say we should make it much easier for people to report factual accuracy. What specific suggestions do you have to do so? How would your proposals make it easier than the existing array of provisions such as Twinkle, Huggle, AIV, ANI, etc?
  • How will it help to have a user right group "Fact Checker"? Will they have some sort of rights to check facts that other editors don't have? If so, what will be the benefit of restricting such rights, rather than letting anyone check facts?
  • If we get 18 billion factual accuracy reports in every month, as you suggest, what will happen to them? Will they get filed away in some archive somewhere? Obviously, there would be no way for the few thousand active Wikipedia editors who try to cope with problematic editing to deal with more than a minute fraction of them, even if they were to dedicate all their time on Wikipedia to the task, and do nothing else. The editor who uses the pseudonym "JamesBWatson" (talk) 14:49, 29 November 2016 (UTC)

Hi JamesBWatson , thank you for your response. firstly,

I think you have some unique idea about "" Complete Reliability/Factual Accuracy Solution."" .what can we do ? . please share it.THANKS. -- md masum (talk) 11:25, 2 December 2016 (UTC)

WP:discussion review

I've been thinking. Perhaps we should have another venue on reviewing closures of non-deletion discussions in general. It can function like WP:DRV or WP:MRV, but the scope should be wide, i.e. it can be anything unrelated to deletion discussions. Someday, when "discussion review" venue comes true, I thought about merging MRV to "discussion review" (DCV?). --George Ho (talk) 23:58, 2 December 2016 (UTC)

What do you think the benefits of this are going to be? Increased visibility/transparency, or maybe keeping discussions of this type off AN? I'm asking because I don't think AN is currently that overwhelmed, although I may be wrong. Enterprisey (talk!) 02:03, 3 December 2016 (UTC)
The discussions at a user talk page prompted me to think about the idea. Now maybe I broadened too much. It should apply to discussions at talk pages, project pages, and project talk pages. WP:arbitration/Requests/Clarification and Amendment already reviews decisions done by ArbCom, so take that out of the scope. Overwhelmed or not, sometimes either administrators might not handle controversy well, or they... I don't see much of discussions yet at AN. --George Ho (talk) 02:51, 3 December 2016 (UTC)

Specific templates

I have been thinking that we used template aimed at something that constantly change. For example, instead of write the new president, we could use some kind of template (for example {{POTUS}}, for President of the US). Sorry for my english. Hddty. (talk) 08:27, 3 December 2016 (UTC)

Could you provide an specific example where this could be used? For the president of the us, either it would be a specific president that did something or it would be a general mention about the office of the president.Brightgalrs (/braɪtˈɡæl.ərˌɛs/)[1] 18:30, 3 December 2016 (UTC)
@Brightgalrs: I mean instead of using this:

| president = [[Barack Obama]] | vice president = [[Joe Biden]]

We could using this:

| president = {{POTUS}} | vice president = {{VPOTUS}} Hddty. (talk) 22:49, 4 December 2016 (UTC)

Hello, I think that Wikidata is meant to allow that kind of data requests. --167.58.90.46 (talk) 19:30, 7 December 2016 (UTC)

signature timezone

We use UTC for signature timezone now. Let's use each users' timezones in Special:Preferences. --ㅂㄱㅇ (talk) (Bieup Giyeok Ieung) 13:06, 4 December 2016 (UTC)

That would probably just make discussions very confusing, and there's already a gadget in user preferences to change timestamps in UTC to be relative to the user's local time. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
13:26, 4 December 2016 (UTC)
Right now, each user can easily see the relative time of any 2 posts (simply see which has a later timestamp, and subtract the times to know how long passded between them); this would no longer work if we each used our own time zone. Additionally, any user can easily check out once which time zone (s)he is in (and probably most of us know anyway) to see how long ago a specific post was made; if each user used his/her own time zone, this would be much more difficult, as the user would need to check out the time zone of the posting user. עוד מישהו Od Mishehu 12:40, 5 December 2016 (UTC)

Bot proposal

If there are x (this can be determined by replies) amount of reverts in a space of x time, then the bot will make a request for page protection. MusikAnimal and I agreed that adding a bot section would be simplest, and CP678 said that it is also easy to incorporate in their bots' code. Thoughts? Dat GuyTalkContribs 16:58, 5 December 2016 (UTC)

I think this needs to be given more thought. Will this only run on mainspace pages? Are good-faith reverts counted? What if the reverts are only for one vandal, shouldn't it report to WP:AIV and not WP:RFPP (since a block would be more appropriate)? If does go to AIV, will the bot know that the user was properly warned first? How would the bot know the reverts are actually vandalism in the first place? What if it is two editors edit warring, shouldn't it go to WP:ANEW instead? Again, how does the bot differentiate vandalism from an edit war, so that it knows what noticeboard to report to? MusikAnimal talk 17:11, 5 December 2016 (UTC)
It runs on every space. Every edit with an edit summary of "revert", "undo", "undid" will be counted. However, it is possible to check if there's good-faith/good faith in the summary (I believe in ruby there's the scan command?). I'm not sure about checking if there's more than two users since also edit wars should be protected as to avoid disruption of the project while attempting to reach consensus. I rarely see users rollbacking/undo-ing edits that aren't vandalism/disruptive in any way. If they do, then they'll be stripped of rollback. I could add it so that it might report to WP:AN/EW. In addition, the bot could check if there are only two editors, both are extended/autoconfirmed, and will request protection of the page to the appropriate level. Dat GuyTalkContribs 17:24, 5 December 2016 (UTC)
If there are only two users, page protection generally is not the answer, blocking is. If it's an edit war, you'd report to ANEW, but the bot has to somehow know it was an edit war and not someone reverting vandalism by a single user. Next, you don't need rollback to "revert", "undo" or "undid". What if I as a new user I wanted to undo my last 10 edits, so I "undid" each of them, one by one? What if I was testing the undo function in my userspace? What if my edit summary said "The Queen of England has undone her decision...", etc. You will need to use regular expressions. Overall I would actually forego reporting to noticeboards entirely, and instead have the bot generate a report in its own userspace, listing pages that have recently experienced numerous reverts. Admins can then refer to it at their leisure, and we don't risk false positives polluting the noticeboards, or having the bot report to the wrong place. With time we'd be able to see how accurate it is, and reconsider if reporting to noticeboards is appropriate MusikAnimal talk 17:58, 5 December 2016 (UTC)
If there is consensus, I will run the bot in my userspace to see how many false positives there are. Dat GuyTalkContribs 06:44, 6 December 2016 (UTC)

Miscellaneous

Need opinions on canvassing vs. notices

I spend almost all my time on-wiki working on featured articles, either writing content or reviewing candidates. There's a MoS discussion, here, that I'd like to post a note about at WT:FAC because a lot of content writers would see it there, and I think it would be good to get more input on this (and other) MoS discussions from experienced content writers. A previous note of mine at WT:FAC on a related MoS discussion was considered by at least one editor, SMcCandlish, to be canvassing, so I asked him how I could leave a neutrally worded notice to let editors at FAC know of the discussion, without running afoul of WP:CANVAS. His response is that any such notice would be canvassing no matter how I worded it: "Quotation formatting is not an intrinsically FA-related subject, so it would be taken as canvassing of a special interest group regardless, by various participants". This doesn't seem to me to be in line with the intent of WP:CANVAS, but I don't want to unilaterally annoy a MoS regular and get into a fight over this. Can I get opinions here on whether it's OK to post the kind of notice I would like to post? Or if in fact SMcCandlish is right that no such notice is possible within the rules? Mike Christie (talk - contribs - library) 13:21, 19 November 2016 (UTC)

Don't be concerned with annoying me in particular. The constant personalized character assassination against me and other MoS regulars by the WP:FAC clique, and the general "screw the MoS, let's start our own anti-MoS" campaigning at WT:FAC, and farcical scapegoating by them of MoS people for things that have nothing at all to do with MoS at all, like infobox disputes (MoS is entirely neutral on infoboxes) has pretty much driven me to the verge of quitting this project. I basically don't respond to anything I don't get an e-mail about, and I may even turn that off. The reason to not try to canvass FAC people to an MoS discussion that has nothing in particular to do with FAC is the same reason to not canvass any other special interest to your preferred side of any discussion on WP. The last time that happened (and at least 3 or 4 people flagged it for canvassing, with me being the last one to do so), about two months ago, the result was predictably a big histrionic, demonizing flamewar from which no consensus resulted on anything, because it was not about the merits of the discussion, but about two camps of conflicting personalities. I repeat what I already said in earlier discussion with you: Doing the same thing again and expecting different results isn't a rational or useful approach. People who actually care about the discussion on its own merits already know about it or will through normal channels like WP:FRS and individual discussion. A particular enclave of anti-MoS pitchfork bearers do not need to recruited again to light yet another witch-burning pyre.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  02:42, 20 November 2016 (UTC)
My reading of WP:APPNOTE suggests that it would be inappropriate to post a message regarding threaded discussions at WT:FAC. FAC people are not 'directly related to the topic under discussion', and from SMcC's response, seem very much more like they might be 'selected on the basis of their opinions'. --Tagishsimon (talk) 03:08, 20 November 2016 (UTC)
It's going to be rare, if ever, that a MoS discussion is going to relate to FAs more than any other area of the encyclopedia. However, FA writers and reviewers are (we hope) experts on how to write and lay out high quality articles. A MoS discussion on how to format a set index article is clearly not of particular interest to FA writers, but a discussion about, say, the structure of article leads is one where they could be expected to have useful opinions. I suspect many at FAC don't watch the MoS pages because there's a lot of tedious (but useful) work that goes on there that doesn't interest them, but I think the input of anyone interested from that group could be helpful. It's not that plenty of good content writers don't already watch MoS pages, but more input tends to lead to longer-lasting consensus. In this particular case I don't plan to post at WT:FAC unless there's a clear consensus here that it would be OK to do so, but I would like to say that I have no idea if anyone who might see such a post would care, or which way they would !vote. I haven't !voted myself and still haven't decided on the issue. Re SMcCandlish's comments about anti-MoS pitchfork bearers; he's right that there are strong feelings and harsh words but that's not a good reason to avoid discussion. Mike Christie (talk - contribs - library) 11:40, 20 November 2016 (UTC)
None of which alters the price of bread w.r.t. WP:APPNOTE. --Tagishsimon (talk) 12:42, 20 November 2016 (UTC)
APPNOTE says the intent must be "to improve the quality of the discussion by broadening participation to more fully achieve consensus", which is the case here; and that notifications are inappropriate if the intention is "influencing the outcome of a discussion in a particular way", which is not the case here. I acknowledge that the phrase you quote, "directly related to the topic under discussion", allows the argument that FAC is not a valid place to leave a notification, but given that MoS issues are mostly about form and not content, wouldn't that reading imply one could almost never notify anyone about MoS discussions? I think that leaves the encyclopedia worse off. We should be trying to get more inclusive on discussions that impact every editor, as the MoS does. Mike Christie (talk - contribs - library) 13:33, 20 November 2016 (UTC)
I have no problem including anyone who will be there to improve MoS rather than undermine it. Meta debates about MoS belong in a separate venue from MoS talk pages, such as, I guess, WP:VPP or WP:VPR. MoS talk pages are for discussion about how to improve MoS, just as article talk pages are about how to improve the respective articles. On MoS talk pages, those meta discussions are equivalent to WP:NOTFORUM violations and should be prohibited. Absent such prohibition, I don't think we need to go out of our way to invite such violations, although we can't prevent people from watching and violating. The bottom line question for me, then, is whether FAC people in fact have tended to engage in that kind of discussion on MoS talk pages, and I don't know the answer since I have no experience in that area. I haven't known McCandlish to distort or misrepresent such things, much. ―Mandruss  19:48, 20 November 2016 (UTC)
Mandruss, if I understand you correctly you're talking about SMcCandlish's comments about some users being anti-MoS. Do you have an opinion about the original question? Is it OK to post notices about MoS discussions to WT:FAC, and by extension to other talk pages that aren't focused on topics (e.g. WT:GAN or WT:PR)? Mike Christie (talk - contribs - library) 16:03, 21 November 2016 (UTC)
@Mike Christie: Perhaps I'm just thick, but I thought his comments were relevant to the original question. If FAC has shown a pattern of bringing MoS opposition to MoS talk pages, my opinion is no. That is not per p&g, but it appears that p&g does not give a clear answer so I'm left to my judgment. Disclaimer: I don't claim to be an expert in this area, but I think I have a handle on the WP political environment. ―Mandruss  17:03, 21 November 2016 (UTC)
OK, now I understand the point you're making. But even if it were true that FAC regulars had such a pattern, surely that's not a reason not to notify them? After all, a proposal at WT:MOS to, say, severely limit the size of sports-related navboxes would be almost certain to attract opposition from the affected Wikiprojects, but that wouldn't be a reason not to notify them. Would someone notifying a sports Wikiproject be canvassing? Mike Christie (talk - contribs - library) 01:21, 22 November 2016 (UTC)
You really don't want to drop this stick, do you, Mike? In your scenario, the sports wikiproject would be 'directly related to the topic under discussion' and so it would, per WP:APPNOTE, be appropriate to notify them. --Tagishsimon (talk) 01:31, 22 November 2016 (UTC)
OK, I'll drop it. I'm surprised by the response, and I wish more people had expressed an opinion, but we can leave it at that. Mike Christie (talk - contribs - library) 01:38, 22 November 2016 (UTC)
I'm kind of underwhelmed by the reasons given here. AFAICT they are:
  • FAC regulars frequently disagree with MOS regulars in style matters (debatable, especially since editors such as Dank, SlimVirgin, and Tony1 have historically been among the most prolific contributors to both pages.)
  • FAC regulars don't have sufficient respect for the MOS (e.g., the "anti-MOS" comments).
  • FAC regulars aren't a subject area, so you can't invite them to anything at all.
    • This is claimed even though changes to the MOS affect them far more than anyone else. They may have to decline candidates and send previously approved articles through FAR as a result of this discussion, but they should not be told that the discussion is happening.
    • In fact, the underlying claim is that no group of people (except perhaps WP:WikiProject Manual of Style) can be invited to any discussion about general style matters (e.g., the best way to handle quotations), because no "general" style matter could be "specific" to any group of editors.
    • Mike, a more appropriate example would have been a proposal at WT:MOS to severely limit the size of all the navboxes, but it happens that the sports navboxes are the ones most affected (because nearly all the others are smaller). Can you notify the sports-related WikiProjects, on the grounds that their work is affected, or must you leave them ignorant of this discussion on the grounds that it's not "specific" to them?
  • FAC shouldn't be informed about this RFC, because if they Truly Cared™, then they'd already be watching the RFC pages or the main MOS page (or all the MOS pages), or would have just known somehow or another.
  • Multiple FAC regulars participated in a previous discussion on an identical(!) topic, but we don't want them back, so don't tell them that we're having this discussion again. It doesn't matter if WP:APPNOTE (heretofore only quoted to claim that the entire guideline militates against letting them know about this discussion) directly says that "Editors who have participated in previous discussions on the same topic (or closely related topics)" can be/should be invited them to this discussion; we don't want them and their disagreeable opinions.
I'm not impressed with these reasons. FAC people are disproportionately affected by changes to the MOS. It is therefore reasonable for them to be informed about what's going on. In fact, I wouldn't consider it unreasonable for some FAC regular to post a weekly update on changes to and discussions about the MOS and all the style-related RFCs so that group knows what's going on. I put this in the same category as transcluding {{cent}} on a WikiProject page (which FAC might also want to do): if a group wants to know what's going on, then there's no rule against them organizing themselves to find out what interests them. And if their "organization" looks like "Mike (or the FAC coordinators, or whoever) regularly tell us about anything that might affect FAs", then that's okay. WhatamIdoing (talk) 22:18, 22 November 2016 (UTC)
To whatever extent your comments refer to mine, mine are quite simple. 1. Anti-MoS sentiments in discussions about improving MoS are off topic, wrong venue, and disruptive. This is a well-known problem. 2. Repeated violators needn't be accommodated. 3. I don't know whether the group in question are repeated violators, but that is the only question in my mind. McC says they are, if I read him correctly. That could be proven to my satisfaction with ten or so diffs. 4. I welcome constructive participation in any discussion, anywhere, on any topic. ―Mandruss  22:51, 22 November 2016 (UTC)
I think that you may have developed an incomplete picture of the relationship between FAC and MOS people. FAC editors follow and enforce the MOS more completely and precisely than any other editors. Multiple FAC regulars are regular, long-time contributors to the MOS. I doubt you would find anyone who regularly engages in the FAC process who would claim to be "anti-MOS" – "anti-stupid-stuff-in-MOS", sure (I hope that sentiment is widespread), but not actually "anti-MOS".
What could easily be demonstrated is that some (not all, probably not even most) FAC editors have disagreed with SMcCandlish at some point over the years on various style guidelines. I've both agreed and disagreed with him myself over the years. But "disagreeing with one person who likes to hang out at WT:MOS", even if it happens consistently, is not actually the same thing as being "anti-MOS".
I am making some assumptions; I'm assuming, for example, that Mike intends to post a note at WT:FAC that is nearly identical to the one that SMcCandlish posted about this same subject at WT:NPOV back in August (and at MOS:ICON, and at IMAGES, and at NOR – I think I'll stop looking now), except instead of saying that, in his opinion, the size of quotation marks was a matter of DUE weight or that it was like an image, it would say something about a change possibly triggering the need to re-check some old FAs. But I'm having a very hard time understanding why such notices would actually be problematic for anyone (except possibly someone who thinks that he'll "lose" an RFC if more experienced editors find out about it).
(Oh, and if you're interested: I'm anti-pull quote myself. If it were up to me, all of those templates would have been deleted long ago and replaced with plain old blockquote tags.) WhatamIdoing (talk) 23:27, 22 November 2016 (UTC)
I don't know how many differemt ways I can say it, or how I can say it any more clearly. I know nothing about FAC-MoS, I have made that fact crystal clear, but I read McC's comments as saying they were a part of the problem I describe. My comments were completely contingent on the accuracy of his comments and my interpretation of them, and I went out of my way to underscore the word If to make sure I wasn't misunderstood. I guess I should have blown it up to 200% and bolded it too, maybe put arrows and stars around it. Can we make text blink, or beep? I commented that I have not known McC to distort such things. ―Mandruss  23:30, 22 November 2016 (UTC)
@WhatamIdoing: Re: '"[D]isagreeing with one person who likes to hang out at WT:MOS", even if it happens consistently, is not actually the same thing as being "anti-MOS".' — That would be true, but a red herring. I'm not talking about people disagreeing with me, I'm talking about at least two distinct proposals at WT:FAC to fork their own style guide against MoS (what could be more anti-MoS that writing an actual Anti-MoS?); demonizing of all the MoS regulars as a group/class by multiple FAC regulars who back each other up in erecting false dichotomies and will brook no disagreement; threats by others in that scene to resign WP editing over not getting their way when wanting to ignore MoS but meeting resistance and/or over those particular editors' continual, escalating fights against those they mischaracterize as MoS editors (who are in fact more often pro-infobox people, infoboxes not being an MoS topic at all); and other patterns of collective and irrational "us versus them", FAC-against-MoS territorial ritualized combat antics, that closely mirror (with considerable individual editorial overlap) similar anti-MoS torch-waving at WT:CITE and (a while back) WT:AT. If I had never even been born, all of this would be continuing exactly as it is now, other than some individual besides me would be the most frequently scapegoated target (probably whoever is next in the stats as the most frequent WP:MOS or WT:MOS editor, or perhaps just whichever one spokes up and didn't still still for being treated like a second-class member of the project by those people).

As for the '"lose" an RfC' comment: just see WP:WINNING, WP:NOTAVOTE, WP:NOT#DEMOCRACY, WP:RFC, etc. The purpose of RfCs is to get input from people who care and have something pertinent to say, after they actually understand whatever is under discussion, with an eye to what is best for the project and its readers; not to rally allies to a cause, to swing a vote based on argument to emotion and reactionary territorialism or proprietary sentiment, which is usually what happens when one pointedly canvasses a wikiproject or other editorial cluster with a known, clearly demonstrated bias with regard to the topic under discussion, especially a bias based on their personal level of control/power over particular pages. Fortunately, this is basically moot, since the discussion in question has archived without resolution. I suggest just forgetting about it. If it re-arises after considerable time has passed, I would trust that everyone's cooled heads will prevail.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  11:53, 2 December 2016 (UTC)

  • It's probably a matter of politeness for someone at MOS talk to ping FAC talk if an important topic is under way. Tony (talk) 08:47, 23 November 2016 (UTC)
  • Mike, yes, it's important to let WT:FAC know about proposals likely to affect them. I would suggest WT:GAN and WT:PR too. SarahSV (talk) 00:49, 28 November 2016 (UTC)
  • When I added the word "directly" to wp:canvass, it was intended to prevent someone from posting a notice to every WikiProject talk page in wikipedia. It wasn't intended to prevent notification of discussion at a collaboration talk page. I've clarified the text. - jc37 23:09, 1 December 2016 (UTC)

Prepare Yourselves

Absolutely nothing useful or interesting to see here ^demon[omg plz] 02:27, 1 December 2016 (UTC)

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

Everyone get ready. A Wikipedia raid is happening Thursday, December 8th by feminists and the BBC. Constantly check your favorite articles; make sure they stay accurate. I'm not saying that feminism is bad or to revert all changes by feminists, I'm just saying that we'll be seeing a large user influx, which could bring many false edits. AA Quantum (talk) 22:34, 29 November 2016 (UTC)

What makes you think that the odd website ageofshitlords.com is a credible source for any claim that such a conspiracy is afoot? -- Hoary (talk) 22:50, 29 November 2016 (UTC)
Come on now, I was just about to remove this under WP:DFTT. --Majora (talk) 22:51, 29 November 2016 (UTC)
You wouldn't meet any resistance from me, Majora. The website does seem to be a mere pile of what we may be in, or may soon enter, the age of. -- Hoary (talk) 00:05, 30 November 2016 (UTC)
A raid by feminist activists would not be a "large user influx".--Jack Upland (talk) 00:12, 30 November 2016 (UTC)
I, for one, welcome our new feminist overladies. AA Quantum refers to the forthcoming BBC 100 Women editathon, to which all are invited. There is a BBC 100 Women redlist up & running, courtesy of the subversives who hang out at WikiProject Women in Red. When will it end, you ask? Well, probably when the ratio of male to female biographies is better than the current 1,421,449 to 237,676, or 83.28% to 16.72% - see WHGI. --Tagishsimon (talk) 02:01, 30 November 2016 (UTC)
  • Let's see... the last two articles OP edited were Ku Klux Klan and Swastika. Now, those edits are innocuous enough by themselves, but combined with panicking over women being out of the kitchen? And citing an alt-right blog as supposed justification for said hissy fit? Ian.thomson (talk) 02:23, 30 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.

The SVG Debate: Inkscape or Not

The template: Template:Noinkscape doesn't give any reasoning for why the otherwise wikipedia-endorsed Inkscape is worse than text-editors. It also doesn't explain how editing Inkscape inhibits future use of text-editors. Can anyone help me understand and solve this issue? I imagine that adapting Inkscape could fix this problem. @Prccy27, Brythones, and Gage: Could people who worked on the 2016 Electoral College map weigh in on this? Thanks! Houdinipeter (talk) 23:38, 29 November 2016 (UTC)

@Sameboat: Do you want to comment on the purpose of {{Noinkscape}} which you created? At any rate, the template appears to only be used at File:SacramentoKings.svg. Johnuniq (talk) 03:34, 30 November 2016 (UTC)
The Commons version of the template is in rather wider use.
I expect it's mostly an objection to the bloat Inkscape adds if you save as an "Inkscape SVG" instead of "Plain SVG". In the case of File:SacramentoKings.svg, it doubled the svg's size. —Cryptic 03:47, 30 November 2016 (UTC)
That makes sense, thanks. I have uploaded a couple of SVGs created using Inkscape and I wondered which of the options should be used—I think I used "Plain SVG". Johnuniq (talk) 04:00, 30 November 2016 (UTC)
I have loads of reasons besides the file size exported from Inkscape being substantially larger and polluted by useless metadata and attributes which define the default value (think of it adding <span style="color:#000000;font-weight:normal;font-size:normal;font-family:Liberation Sans,Arial,Helvetica,sans-serif">Text here</span> for every single section of text, Inkscape is doing something worse than that). For SacramentoKings.svg specifically, Inkscape's default curve tool only supports editing with cubic Bézier curve command. If Inkscape detects other curve commands, namely quadratic Bézier curve and elliptical arc curve, upon editing the path, it will instantly convert them to cubic Bézier curve command. The issue with cubic Bézier curve command is that adjusting its control points for creating a perfect circular arc is extremely cumbersome for all the irrational decimals, even if the angles of the entry and exit points are pointing to the cardinal directions. For example, if I want to draw a circular arc from (0,0) to (100,100) clockwise, turning 90 degree and 100px radius, this is what the elliptical arc curve command will look like: A 100,100 0 0,1 100,100. And this is what cubic Bézier curve command will end up after conversion by Inkscape: C 55.228475,0 100,44.771525 100,100. -- Sameboat - 同舟 (talk · contri.) 02:54, 1 December 2016 (UTC)
Additionally, "no Inkscape" also includes Inkscape's "Plain SVG" format which still contains all the default-value-attribute craps and polluted curve commands issue. -- Sameboat - 同舟 (talk · contri.) 04:21, 30 November 2016 (UTC)
Any suggestions on alternatives? Inkscape is pretty nice to use. Johnuniq (talk) 04:50, 30 November 2016 (UTC)
Just learn writing SVG/XML codes in Notepad. I have absolutely no objection if you're drawing something like this, but for most vector diagrams, text editor is my only answer. -- Sameboat - 同舟 (talk · contri.) 05:01, 30 November 2016 (UTC)
Notepad!! My editor can do this in a single search-and-replace. Johnuniq (talk) 05:09, 30 November 2016 (UTC)
I had no trouble making all these topological diagrams in Notepad++. -- Sameboat - 同舟 (talk · contri.) 05:17, 30 November 2016 (UTC)
I could have done the same in VisualEditor with 2 clicks... --Izno (talk) 13:34, 30 November 2016 (UTC)
Having used Inkscape and other vector programs, I do agree that Inkscape does like to "take over" a saved SVG into its own format since it has a lot of non-standard SVG extensions (good for creation, bad for revisions). I think we should be clear in the language of this template that should explain this issue and to add that it should only be applied to SVG images that were created outside of Inkscape (such that Inkscape editing doesn't screw them up). It should not be taken that we do not accept Inkscape-made SVGs, just that non-IS SVGs should not be edited by IS. (That said, I haven't tested enough to know if a program like Adobe Illustrator has similar "take over" actions on the SVGs it produces) --MASEM (t) 15:37, 30 November 2016 (UTC)
@Masem: The code neatness of SVG exported from Ai is slightly better than Inkscape, but there can still be many issues with these SVG files if the original work wasn't really prepared with SVG specification in mind. Commons:Help:Illustrator details the issues as much as possible. To me personally, the worst offender has to be intentionally not translating text-align setting of "center" and "right" to text-anchor property ("middle" and "end" respectively) but replacing with translating the text position which almost guarantees poorly positioned text after uploaded to Wikimedia. Because of the Creative Cloud barricade, that means most of our Ai contributors still stick with the older versions of the vector application and they will never ever receive any update if Adobe finally has decided to improve its support for SVG. In other words, they will be highly tempted to convert all text to outlines before exporting SVG just for neat presentation on Wikimedia but hell for revision and localization. -- Sameboat - 同舟 (talk · contri.) 01:10, 1 December 2016 (UTC)
Inkscape is the only free general-purpose SVG editor listed at Wikipedia:Graphics Lab. If the general SVG output from Inkscape is not suitable, then Wikipedia/Wikimedia/Commons should describe somewhere (perhaps Wikipedia:Graphics Lab/Resources/SVG) which options should be used to save/export the right kind of SVG. If InkScape is not currently capable of producing the features (or lack of customisations) that we require/would like, then Wikipedia should make a list of what changes we would like, then have someone file a series of bug report/feature requests to InkScape, perhaps with a "Save as Wikimedia-friendly" checkbox. Having InkScape explicitly support Wikipedia and be recommended by Wikipedia should benefit both projects. --Scott Davis Talk 03:42, 3 December 2016 (UTC)
@ScottDavis: The purpose of placing this "no inkscape" banner in some of our SVG files is that we don't rule out Inkscape (actually including all other vector graphic editors/VGE like Adobe Illustrator) but rather to tell our contributors which SVG file can be touched by VGE and which shouldn't be. Generally if an SVG file starts out with text editor, it should not be touched by any VGE at all. There is also the free online SVG optimizer to clean up all the unnecessary metadata and floating points which are generated by VGE so Inkscape contributors are still welcomed but they need to be prepared that once their works are uploaded to Wikimedia, their works will be "optimized" by other contributors at any time. This optimization is usually done for the purpose of allowing easier access in text editor by other contributors when the SVG image is going to be heavily updated by many different users such as this one. If the SVG image is created in VGE and the uploader is the sole contributor of that image, then the image can retain its original state unless it hits the rendering limitation of libRSVG. -- Sameboat - 同舟 (talk · contri.) 04:22, 6 December 2016 (UTC)
My suggestion is to add something in this template as a reference to, say, something on one of the WP:GL pages that explains what's been described above: Inkscape (and technically AI) both are fine for creation of new SVG, but should not be used to edit existing text and/or computer-generated SVG files due to how they mess up meticulous optimizations that the creator/updators have made. You don't need to explain that in full on this template, but just the link to such a discussion so that we don't need to redo this conversation at a later date. --MASEM (t) 17:04, 6 December 2016 (UTC)
@Masem: Of course we should. And links to related Commons help pages are essential a well. -- Sameboat - 同舟 (talk · contri.) 16:03, 7 December 2016 (UTC)

Location-based pages with separate more detailed pages on the same subjects

I hope this is the right place to ask why location based pages (towns, counties etc.) have sections on, for example, "History of Wikiville", "Geography of Wikiville", "Sport of Wikiville" but also separate pages in the encyclopedia on exactly the same subjects?

If you are - as I am - trying to pull one of these sites into shape, the double-page just creates extra work, with a lot of sections having to be edited twice, and decisions made as to what goes in the summary section and what goes on the fuller page.

However the real downside is that, over time, individual editors find one page or the other, and make additions, corrections or deletions without editing the other page. So we end up with conflicting information - sometimes quite factual stuff like figures or dates - that conflict between the two pages.

Surely it would be better to decide, either a) we have a full page on Wikiville with all the detailed information on it (if people don't want to read the history or whatever, they can always minimise the section) or, b) we have all the gripping event-by-event history of Wikiville set out on one page, with a simple link to it from the main Wikiville page? User:IanB2 1 December 2016

Having dug around the site a little, I think this issue will affect a very large number of sites indeed. Nevertheless the way the site is currently set up makes life a lot more difficult for editors, and potentially confusing for users.

See Wikipedia:Summary style. Large articles are broken out into smaller subject based articles when they become to big to manage. The way it is SUPPOSED to work is that the parent article still should have a paragraph or two of overview material, and the child articles have more exhaustive detail. Where it doesn't happen is because people haven't yet made it work right. --Jayron32 12:51, 1 December 2016 (UTC)

Hi - thanks for the quick reply. I can see the logic for a topical page, where you don't want all the minutiae of a detailed sub-subject set out on the main page. But my point is that for subjects like "History of Wikiville" - which is essentially a series of discrete events set out over the full span of human history - the logic doesn't really work very well in practice? User:IanB2 1 December 2016

I don't see a problem with it for an article on the history of a place. Summary style is really there to limit article size; an article on, e.g., New Orleans that included a fully detailed history of the city would be unwieldy. I think a summary of that history in the main article seems like a reasonable approach; what problem do you see with it? Mike Christie (talk - contribs - library) 13:41, 1 December 2016 (UTC)

I think the problems are: a) extra work for someone trying to pull a location page into shape, having to double-edit everything, b) individual editors add or change things to one page or the other, but not both, so the two pages grow apart, and occasionally conflict on basic factual details, c) a history - essentially a sequence of discrete events - is not always easy to summarise User:IanB2 1 December 2016

"Wikiville#History" should more or less match the summary of "History of Wikiville", with some extra phrases. --NaBUru38 (talk) 21:34, 3 December 2016 (UTC)

Has using Wikidata descriptions as page subtitles in mobile view been discussed here?

It seems that this new feature (see phab:T135433) will be "tested" on the French WP during one month starting next Monday, and kept if there is no "major objection". Will there be such a thing here on the English WP or has it been discussed somewhere? The answer could help the French WP know what to do about this "test". Oliv0 (talk) 13:52, 2 December 2016 (UTC)

I thought something like this was already happening? Or perhaps it was just the app. Sam Walton (talk) 15:46, 2 December 2016 (UTC)
This was mentioned in the Technical Village Pump, but it only pointed to a page on mediawikiwiki. Jo-Jo Eumerus (talk, contributions) 16:16, 2 December 2016 (UTC)
Mobile search has used Wikidata descriptions for the English Wikipedia since October 2015. There were no comments to the announcement at Wikipedia:Village pump (technical)/Archive 141#Wikidata descriptions. They are also used for the search box at https://www.wikipedia.org. PrimeHunter (talk) 21:51, 2 December 2016 (UTC)
This new feature is not in the search but is under the title of the article using d:WD:description as a page subtitle. I found the place where it was mentioned in the Technical Village Pump: WP:Village pump (technical)/Archive 148#.5BIdea.5D Wikidata descriptions to help disambiguate article topic on mobile web (with only very little discussion), pointing to mw:Reading/web/Projects/Wikidata Descriptions (with some discussion on the talk page 3 months ago). Oliv0 (talk) 07:05, 3 December 2016 (UTC)
Thanks Oliv0, no this hasn't been discussed here yet, but now I see it is being discussed already :). The feature has been running on all language versions, on stable, except for a very few languages. It could be activated for English Wikipedia soon, as well. Thanks for starting the conversation --Melamrawy (WMF) (talk) 02:50, 5 December 2016 (UTC)

Is Wikidata d:Q42 not an external link?

I am developing infoboxes, using Wikidata. For carbon monoxide, I see

My question is: why is Wikidata presented as an internal link? Is that a web-design choice? To me (and probably most Readers), d:Wikidata is an external site. Can someone clarify? -DePiep (talk) 21:15, 2 December 2016 (UTC)

Wikidata is another wikimedia property, like wikimedia commons, and so can be presented as an internal link. And I'd expect it to be shown as an internal, not an external. YMMV. --Tagishsimon (talk) 21:25, 2 December 2016 (UTC)
Yes, wikilinks are the usual method for Wikimedia sites. See Help:Link#Interwiki links. "Internal link" usually means to the same wiki. Interwiki links have a slightly different color (see Help:Link color) and are neither called internal nor external. PrimeHunter (talk) 21:41, 2 December 2016 (UTC)
I can get this. Now, does King Reader wants it this way too? (not to cause trouble, but I'm interested it the web-design aspects. Readers' perspective). -DePiep (talk) 22:01, 2 December 2016 (UTC)
I doubt there have been any reader surveys and most readers probably don't know what Wikidata is so the result would depend strongly on how the question is formulated. We have always used interwiki links for Wikimedia projects, e.g. in {{Sister project links}} like at Carbon#External links. It's a feature of the Mediawiki software that links made with url's get an external link icon by default (plainlink can suppress it), and interwiki links don't. I like it that way. PrimeHunter (talk) 22:23, 2 December 2016 (UTC)
There has been some research on readers (e.g., m:New Readers), but I don't think that any of it specifically addressed this question. Whatamidoing (WMF) (talk) 23:39, 4 December 2016 (UTC)
Thanks Y'all. -DePiep (talk) 08:08, 5 December 2016 (UTC)
Great stuff, thanks. -DePiep (talk) 00:41, 6 December 2016 (UTC)

RM problem

For starters, I would like to say that I do apologize if this is the wrong place to put this.

Now, I have twice relisted a move discussion at Talk:Aleksandar Jovanović (footballer, born December 1992). However, shortly after I relisted a second time, a user moved the page, but didn't close the discussion. Now another user has commented and requested a new title, even though the RM is technically "over". I am unsure of what to do; can anyone be of assistance (also note that I am not involved with the article except for the relistings). JudgeRM (talk to me) 16:34, 4 December 2016 (UTC)

Can we simply close it right now (after the deed), and move on? After all the RM was open for weeks without contests. Otherwise, reading Wikipedia:Move review gave me some hints on current options in the process. -DePiep (talk) 08:32, 5 December 2016 (UTC)

Unavailability.

I will be unavailable until December 14. Usually, I would ask that the encyclopedia be finished by the time I get back, or at least that all the disambiguation links be fixed, but this time I'll be more modest and suggest getting through the list of missing United States state supreme court justices. Cheers! bd2412 T 04:46, 7 December 2016 (UTC)

Thanks BD2412. We'll give your suggestion serious thought. --Tagishsimon (talk) 04:51, 7 December 2016 (UTC)

findagrave (yet again)

I've tried to follow the old discussion on findagrave.com, but don't see why (assuming it includes a photo of the gravestone) it isn't considered a reliable source—after all, the birth and death dates are literally carved in stone. The written text may not be reliable insofar as it is not a transcription of what's visible on the stone. In terms of value as an external link the site is of inestimable value to genealogists, and also to people interested in visiting the graves of famous people. Peter Flass (talk) 13:42, 7 December 2016 (UTC)

Simply, it is WP:USERGENERATED and as subject to hoaxes as any other website that fits that desciption. MarnetteD|Talk 19:34, 7 December 2016 (UTC)
That's true of many things. Many obituaries are written by family, although I see that has also been discussed. More importantly, much information recorded on "official" death certificates is reported by family members, and is likely to be no more or less accurate than what's inscribed of a gravestone. Any pictures are subject to photoshopping, if someone is so inclined, including most of the photos on Wikipedia. Peter Flass (talk) 20:49, 7 December 2016 (UTC)

Most edited pages by unregistered users

Is there any way to see the most edited pages by unregistered users?Ionutzmovie (talk) 18:58, 7 December 2016 (UTC)

WWA question

(Posting this here because the WWA talk page is inactive and I wouldn't get an answer there, and this touches a bit on how we define "Wikipedian" to begin with.)

I was looking at the page WP:WWA and I noticed Andysch was listed as "Not active". I assumed (given what he's known for) that he had been an active editor on Wikipedia before leaving to found Conservapedia, but if that's the case it must have been under a different username because that account only made a few edits to our article on Conservapedia (i.e., it was created after Conservapedia had already been founded). I then noticed that a number of other "Not active" accounts were also essentially WP:SPAs that had made accounts to comment on or edit their own articles and had not been active since. Some of them actually are active (Arudoudebito, for instance, takes long breaks from editing but he has posted in 2016). This seems like an odd turn of phrase in that light.

There's a control for this. The Larry Sanger account has only made three edits since 2014 and his last edit that wasn't related to Larry Sanger and Citizendium was long before that, but since he was at one time in the past (until February 2003) a normal Wikipedia editor without an article who edited in other topic areas he is not referred to as "Not active" even though the account has been significantly less active than some of the "Not active" accounts.

Wouldn't referring to accounts that post-date their articles and whose only activity has been related to those articles as "single-purpose accounts" be better than describing them as "not active"? I was initially wondering whether single-purpose accounts (especially long-inactive ones) should be described in the present-tense as "Wikipedians", and whether a better name for the page would be "People with Wikipedia articles who also have confirmed Wikipedia accounts" or something (although I recognize that that's too long).

Hijiri 88 (やや) 00:19, 8 December 2016 (UTC)

Meh... --Jayron32 00:43, 8 December 2016 (UTC)

American jazz musicians were mostly African American?

I just noticed that some jazz musicians are lacking any category like "Category:African-American musicians" (for example Eddie Jefferson or Ernie Andrews) and I feel like there are many such articles. Shouldn't they contain such a category? Not all the American jazz musicians were black, and therefore the articles should contain such categories, I think. Is there a better place to raise this question, by the way? —  Ark25  (talk) 00:54, 8 December 2016 (UTC)

Ark25 Thanks for asking about this. There is nothing wrong with being bold and adding them yourself. IMO the important thing, when it comes to these (or any) categories, is to remember the guidelines at WP:CATDEF, especially the fact that there must be verifiable info in the article to support the addition of the category. MarnetteD|Talk 01:19, 8 December 2016 (UTC)
Oh, well, I've just added African-American categories to Charles Miller (musician) for example (not jazz musician), got no written sources but the photos in the first external link really show an African American. —  Ark25  (talk) 01:33, 8 December 2016 (UTC)

The tiles of the Dukes of Alençon

I have a question regarding Jean I, Duke of Alençon and Jean II, Duke of Alençon. The two of them have names that differ from the name used in their intro paragraph: "John" is used in the intro whereas "Jean" is used in the title. Is there a reason for the discrepancy? Reversinator (talk) 04:13, 8 December 2016 (UTC)