Wikipedia:Village pump (all)

From Wikipedia, the free encyclopedia

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

To discuss existing and proposed policies

To discuss technical issues. For wiki software bug reports, use Phabricator

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

Idea lab
To discuss ideas before proposing them to the community and attempt to find solutions to issues

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 using or editing Wikipedia Help desk 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 resolving a specific article edit dispute Requests for comment comment on a specific article Article's talk page view other Wikimedia projects Wikimedia Meta-Wiki learn about citing Wikipedia in a bibliography Citing Wikipedia report sites that copy Wikipedia content Mirrors and forks ask questions or make comments Questions


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


Criteria for inclusion in Births and Deaths sections of Wikipedia date articles

Per previous discussions over at Wikipedia talk:Days of the year, it seems that there is some level of support for some kind of inclusion criteria for what articles to include on the Births and Deaths sections. There are some concerns that these sections are too-Western centric (i.e. people from North America or Europe are over-represented).

The question now is: should we have some kind of guideline for inclusion in Births and Dates articles? Or is the status-quo fine? In my case, my pet proposal is that a proposed inclusion criteria would be similar to what's currently done at WP:DYK, where no more than half of each set can be about US-related topics. Though of course, other editors are free to propose other proposals here. Narutolovehinata5 tccsdnew 03:16, 28 January 2018 (UTC)

  • Just axe these sections. They're useless trivia. KMF (talk) 04:12, 28 January 2018 (UTC)
I agree with KMF that this is trivia. There is no possible way to develop an objective criteria for inclusion, and any volunteer time wasted on this would be better spent actually improving the encyclopedia. Cullen328 Let's discuss it 05:10, 28 January 2018 (UTC)
If you're reading the Wikipedia article about a particular day of the year, I would surmise that probably you are very much in the market for useless trivia! CapitalSasha ~ talk 05:18, 28 January 2018 (UTC)
With the exception of a few incidents which are frequently referred to by their dates (e.g September 11 attacks), or dates which represent holidays on the Gregorian calendar (e.g Storming of the Bastille, which is the source of Bastille Day), all data on date pages are trivia. I see no reason why it's any less trivia that the Titanic sank on April 15 than that the actress Emma Watson was born on this date. עוד מישהו Od Mishehu 07:59, 28 January 2018 (UTC)
  • The best option in my opinion would be to branch out "Born on ..." and "Died on ..." into separate articles (many of these lists online, but lots of misinformation, and none that are verifiable), maintained by bots and linked to on the DoY pages. This would reduce editor time spent to practically zero, does away with arbitrary inclusion criteria, and makes sure the info is still there for people who want it. The only objection that I've come across is that this could be done by category instead, but this makes it a nightmare to sort by year, and prevents the brief summary of what the people were notable for. ‑‑YodinT 12:19, 28 January 2018 (UTC)
  • I think the inclusion could be based on quality of linked articles. For example, limit inclusion to articles that have 500 words of pure prose and have no major clean up tags. Renata (talk) 14:44, 28 January 2018 (UTC)
That makes sense for a internal stuff...but that's not exactly an encyclopaedic inclusion criteria? That's the same problem with Narutolovehinata5's proposal - "than half of each set can be about US-related topics." is fine for internal inclusion, but not for an objective encyclopaedia. Galobtter (pingó mió) 14:50, 28 January 2018 (UTC)
Well, Wikipedia is mature enough that truly notable people generally have bios that are pretty decent. Of course, there are all kinds of exceptions and anomalies. But I think it would be very useful to have some sort of arbitrary criteria based on article quality to avoid lengthy discussions on who is more notable. Renata (talk) 03:56, 29 January 2018 (UTC)
In my view a notability criterion would be relevant, but that may be different from an article quality criterion. Many highly important people from (e.g.) the 18th century have short, underdeveloped articles, while many largely irrelevant sports or music (mainly US and UK) people from today have lengthy well developed articles maintained by fans. So a quality criterion developed along lines of development of article, would not solve the problem raised at the start of this post and in fact may even worsen it. Splitting off list of births and deaths on this date as Yodin suggests would not be perfect, but would at least largely solve the problem. This not in the least because such lists would allow much more entries, without overwhelming the rest of the entries on the day article (thus taking the sting out of discussion there). Arnoutf (talk) 07:11, 29 January 2018 (UTC)
  • It's simple. Include every single individual who was born/died on any given day. The Rambling Man (talk) 07:34, 29 January 2018 (UTC)
@The Rambling Man: Wouldn't such list articles (assuming the sections get split, as proposed above by some users) end up being very long and potentially falling afoul of WP:IINFO? Narutolovehinata5 tccsdnew 13:15, 29 January 2018 (UTC)
Policy has nothing to do with it. It's too unweildy. As a quick Fermi approximation, Wikipedia has 5.5 million articles. If 10% of those were about people (not an unreasonable guess) that'd be 550,000 biographies here at Wikipedia. We'd guess about 1/365 would have any random birth or death date. That's approximately 1500 people per day born, and 1500 people per day die (a bit less, since some of those people haven't died yet). Aproximately 3000 lines of text just to keep track of birthdates and deathdates is unreasonable. --Jayron32 16:11, 31 January 2018 (UTC)
  • I don’t know if this is possible tech-wise, but what would be helpful to the reader would be to group “on this day” entries into sub-lists... non-birthday events that occurred on the day go in one section... birthdays in another (I would even divide the birthday listings up into sub-sub-sections by profession groups: Performing arts, business, politics, etc). This would help readers USE the lists more efficiently... to more easily find the information they are looking for. Blueboar (talk) 11:35, 29 January 2018 (UTC)
  • Could this be better handled by categorifying the data? That way, the category "Born on XXXX" would automagically be populated. Surely there is some better semi-automated way to handle this better than relying on people randomly coming by to add a name to a page. --Jayron32 15:11, 29 January 2018 (UTC)
    • See above: Categories don't allow readers to see a brief summary of each person, or even display which year they were born. Also, if you wanted to try to sort these categories by year it would be problematic and very counterintuitive (even if you add leading zeroes to account for years < 1000), B.C. dates would still be sorted alphabetically (so 1 BC first, 300 BC last), followed by A.D. sorted alphabetically (1 AD first, 2017 last). If not, then you end up with just an unreadable list of names sorted alphabetically, something I doubt any of the readers (for example those mentioned above by CapitalSasha and Od Mishehu) would be interested in. With Wikidata, it should be straightforward to get a bot to maintain these lists as articles, rather than resorting to categories of use to neither man nor bot. What do you reckon? ‑‑YodinT 16:17, 29 January 2018 (UTC)
I'm against this, primary because I fear it would have potential to creep over to the "years" article, in which the inclusion of everyone that has a wikipage is very useful. I also glimpsed at two random dates in January and it did not seem that outrageous, when you consider the attempted scope of the article. (Granted this was on the desktop version) We could include tools to make it easier to navigate however on mobile,but I'm not in favor of limiting the amount of people that could be there. --Deathawk (talk) 22:37, 29 January 2018 (UTC)
I would say that, in line with some others here, we should get rid of these sections; they seem irrelevant to information about the date (so most people on the page for a given date probably won't care about this information) and it's inherently too hard to come up with an objective standard for who should and shouldn't be included. Perhaps a set of categories for people who were born or died on a given date would be an improvement (i.e. Category:People born on January 1, etc.) Every Morning (there's a halo...) 00:34, 30 January 2018 (UTC)
I think much of this debate comes from a fear that these pages will get too long too quickly and will become out of control. This, for the most part, is unfounded, as the pages are edited by humans and most people will not actually have time to edit these in such a way that it gets unmanageable. And if they do, we can split it off into a separate article. I agree with a sentiment explained already in this threat that the people who go into a date article probably are looking for a list of who was born and who died on that day. What I'm saying is, I don't think this is a feature that our readers are annoyed by, so much as editors are, and we should be in service to the reader. --Deathawk (talk) 02:07, 30 January 2018 (UTC)
I agree with Deathawk's position. It is trivia, but the reader looking up a date like January 30 probably is looking for this kind of trivia. Coming up with DYK-like restrictions for it seems to serve editors more than readers, IMHO. Double sharp (talk) 05:56, 30 January 2018 (UTC)
There has to be some way to manage these lists. Right now, Category:1980s births has approximately 15,000 people per year. Given that everyone born will die, and that Wikipedia continues to exist, that's roughly 1,000 new entries per date every ten years. That's untenable. The argument that this won't happen because people won't do it strikes me as flawed because that's not a guarantee that it won't happen, and it wouldn't be hard to write a bot to populate those lists or for one determined editor to do so. The fact that it hasn't happened yet is probably due more to the fact that these lists are currently curated, even though we don't have clear guidelines. Personally, I think it'd be best to create a new article People born on (x date) and leave a tiny subset of the most notable (determined perhaps by restricting it to a certain number per article or by set criteria) on the actual date article itself.
As to the other arguments, I agree that these lists are largely trivia, but that does seem to be the purpose of the DOY articles, and I’m okay with that. I don't think a category suffices because it doesn't include the brief descriptions and because categories are merely alphabetical and not chronological. -- irn (talk) 14:16, 3 February 2018 (UTC)
  • A summary of my opinion:
  1. These sections are of value and are the kind of thing people expect to see in an article about a given year or date.
  2. They should not be allowed to become too long. 100 names in each section should be the absolute limit.
  3. An effort should be made to ensure a spread of nationalities, occupations, and historical period.
There will be a lot of work needed to establish criteria but to me it seems essential that we make the effort. — Preceding unsigned comment added by Deb (talkcontribs)
  • If nothing is done we'll have to put up with seeing the Births and Deaths sections grow to enormous length – I recently saw someone going through methodically adding all the footballers from a particular country, and we have no rule against this. I've estimated potentially 3,000 names under Births for each day. Otherwise we need criteria for "super-notability" to go on these lists. Something on the lines of Deb's suggestion may work if we have subsections for each date with really tight and unarguable eligibility, such as "Monarchs, presidents and prime ministers born on this day", "Nobel prizewinners born on this day", "Olympic gold medallists born on this day" ... then "... died on this day", all chosen to ensure Deb's "spread of nationalities, occupations, and historical period": Noyster (talk), 17:19, 3 February 2018 (UTC)
I like that suggestion a lot. The unarguable eligibility for super-notable subsections seems a little difficult to me, though, when dealing with entertainers and sportspeople. (Michael Jackson and Pelé come immediately to mind as examples.) I think it should be doable, but we might need to elaborate the criteria elsewhere and just label the subsections "Entertainers" and "Athletes", for example. -- irn (talk) 17:42, 3 February 2018 (UTC)
  • Any notability criteria is likely to be subjective and devolve into protracted discussions over personal preference of notability, to the detriment of time spent actually improving the encyclopedia. I suggest adopting the type of standard used at "On this day - born/died" which is (I think) B-class articles or above. This would encourage editors to improve their favourite biographies to B-class to get them included on the day page, and would also be an objective standard. I have seen editors going through the day pages removing names which they personally consider non-notable and it's very subjective of course - "not her, she's a porn star and that's not on" etc etc. It should also be easy to get this automated if it's pulling on the pools of B, A, GA and FA articles only. MurielMary (talk) 09:39, 4 February 2018 (UTC)
B-class isn't exactly a objective criteria..anyone can change ratings.Galobtter (pingó mió) 09:44, 4 February 2018 (UTC)
  • I really like the incentive for editors to improve the articles. While it might not be a perfect solution, I think it would address the concerns of editors who work on DoY articles, in that the lists won't become unmanagable (for at least the next decade or so), and we shouldn't allow the potential fixing mentioned above to prevent a good idea from being implemented. It also seems to follow the pattern of WP:ITN, in that it's not just about "more or less notable", but quality of their coverage on Wikipedia. Would love to help with an improvement drive to address WP:BIAS on this. ‑‑YodinT 12:39, 4 February 2018 (UTC)
  • Just tossing out an idea here... If we really want to base inclusion on article quality, then perhaps the criteria should be “good article” status. “Good article” status is a more defined process which means the article has been reviewed and has achieved a substantive quality standard. The down side is that some notable subjects may not be listed (if the article about them is poorly written) ... the up side is that this would encourage editors to work on these articles, and bring them up to “good article” standards. Blueboar (talk) 13:37, 4 February 2018 (UTC)
    • The snag with this is - what do we do if, for example, "Michael Jackson" has not achieved GA status? Deb (talk) 09:39, 5 February 2018 (UTC)
      • Work on the Michael Jackson article and GET it to “Good article” status? Blueboar (talk) 11:17, 5 February 2018 (UTC)
  • There are 6,490 biographies classified as GA and above,[1] making about 18 per day of the year. No Thomas Jefferson, no Mussolini, no Beethoven, no Mozart ... All these are B's and I'm starting to think we may have to go with B-class and above, recognising the flaws. I'd have preferred to base it on importance of person rather than quality of article, but neither Top-importance nor Vital articles will yield nearly enough names, and the difficulties of establishing any other criterion of importance are obvious: Noyster (talk), 11:10, 5 February 2018 (UTC)
I'm thinking limiting it to B articles might work quite well. Deb (talk) 11:44, 5 February 2018 (UTC)
The problem I see with limiting this to a certain class of article is that it's not exactly user friendly. I imagine that the majority of editors adding content to these pages are relatively inexperienced to Wikipedia, and would be unaware of what a "B class article" means. It would be devastating for them to come and have there edit reverted. I could imagine some editors who might prove useful to the project being turned away from it as a result. It's just too much CREEP. One thing that might work is instead language that encourages the inclusion of "high class" articles as opposed to underdeveloped ones. A good example is how Wikipedia: Unusual Articles, states that the articles should be of "decent quality" but does not further expand on what that means, as a result the editors somewhat police themselves. --Deathawk (talk) 03:41, 6 February 2018 (UTC)
"Decent quality" is rather subjective, and, if editors got together and put a definition on "decent quality" I suspect they would just be re-inventing the wheel - WP already has definitions of quality in the Stub/Start/C/B/A/GA etc scale. I think In The News has a definition of "decent quality" for inclusion in their corner of the main page which is something like "no orange tags, all statements cited, no copy vios of images" but this is a pretty low bar and I think using something this minimal wouldn't go far to reduce the quantity of articles on the day pages. What I've noticed at In The News is that someone nominates an article for inclusion, someone else tags it with an orange tag, then the nominator gets to work fixing up the article, the orange tag is removed and it gets published on the main page. Good for the encyclopedia to have all that effort going into improving articles. MurielMary (talk) 10:48, 6 February 2018 (UTC)

I still maintain that this is problem mostly imagined. Personally I find it a bit ridiculous to have a Wikipedia article for every day of the year, but I don't really see it as problematic and if people find it interesting I don't mind either way. Having said that if you include a list of every date and have a listing of birthdays and death dates for the page, then it stands to reason that you are going to get a lot of listings . However this is the purpose of the page and it is fulfilling that roll. To somehow modify that list, you are now making it actually less useful, and it's falling farther and farther from the purpose. --Deathawk (talk) 20:17, 6 February 2018 (UTC)

@Deathawk: There are over 1.5 million biography articles at the moment, that's more than 4,000 births for each day, plus deaths, with more being added all the time. If we don't attempt to curate them, they would quickly reach article size limits. I would personally agree that complete lists make sense, and aren't a problem, but they would have to be split from the main pages. But either way, we've got three options I suppose:
  1. No births & deaths on the DoY pages (and optionally splitting the lists into separate articles).
  2. Having a list without the names of people that very few readers would have interest in (e.g. a very obscure mid 20th century sportsman compared to, say, Alexander the Great) – again, this could be done in conjunction with separate lists, but doesn't have to be, as at present.
  3. Ignoring the DoY articles, allowing them to fill up, quickly becoming very slow, to the point of being unreadable on mobiles, and eventually reaching the absolute article limit, preventing editing, etc..
A fair number of editors are trying to prevent #3 from happening, but it's a complete pain without guidelines that would make the process easier (and hopefully automated, to free us up to do more positive editing!). I guess you're not actively trying to prevent this from happening, but opposing it on the grounds that it's imagined makes me think you don't do much editing on DoY pages? Either way, it seems that for the first time in a long while we're finally pretty close to reaching a consensus – would be great to reach the point where a clear guideline proposal could be made. ‑‑YodinT 21:53, 7 February 2018 (UTC)
A bit late to the discussion, but the original question was whether the pages were too America-centric. I've been attempting to correct this by deliberately adding people from around the world. A problem that comes up often is that many of these are stubs, or need content from another wiki. Add to that the new requirement that dates of birth and death need good Wikipedia references, and it's a lot more work to edit these pages with quality content.
For the record, I guess I'd go with option 2 above. There's a lot of interest in "born on this day" and "died on this day", so I think births and deaths are relevant. Natalie Bueno Vasquez (talk) 06:23, 8 February 2018 (UTC)

As for the proposals above which suggests that all articles that are mentioned in Births/Deaths sections need to be at least B-class, I'm not sure it would work in filtering out systemic bias; if anything, it could only help worsen it. Some articles on even the most well-known Western people are at C-class or lower, meaning that they'd have to be left out; on the other hand, from experience, articles on non-American or non-European topics tend to be of a lower quality as well, meaning that even very popular names wouldn't be mentioned. So while article quality could potentially work as a standard for inclusion, it also has its drawbacks and might not solve the problem at all. As for the suggestion of simply making separate list articles and listing all births/deaths there, that would be wildly impractical: such articles would be way too long. Narutolovehinata5 tccsdnew 07:37, 8 February 2018 (UTC)

Lists of births & deaths could easily be broken down (either by the people's roles as suggested by another editor above, or by century). ‑‑YodinT 09:58, 8 February 2018 (UTC)
  • Cut births and deaths entirely. This sort of navigation can be done on en-wiki via categories. Searching this sort of question is best done via Wikidata. Chris Troutman (talk) 01:40, 17 February 2018 (UTC)
  • I would support removing those sections completely. Besides the constant stream of non-notable people who get added to them, it's really questionable how useful that trivia is. Make it a category so that people can use cross-cat tools to find whatever intersection they're looking for. If we have to keep these lists, split them off into "List of people born on X" type articles (and then delete them as trivia...) Matt Deres (talk) 18:21, 20 February 2018 (UTC)
  • Please don't axe the "list of people born on this day" sections. Please don't. Keep them the way they are (or split them into a new thing). I strongly, STRONGLY SUPPORT Option #2. This "pointless trivia" is the exact type of thing that someone searching for a page about a given day of the year would want to see. Natalie puts it well above: there's legitimately "a lot of interest in "born on this day" and "died on this day", so I think births and deaths are relevant." Paintspot Infez (talk) 02:51, 1 March 2018 (UTC)
  • Isn't this the sort of thing that WikiData should be able to cover - i.e. queries such as people born on 1st Jan 1900, footballers who died in Feb 1901 etc? DexDor (talk) 06:35, 1 March 2018 (UTC)

Some observations, in part to provide a summing up, & in to offer some :

  • IMHO, the consensus is leaning towards keeping this list. (Disclaimer, I favor keeping it, so YMMV here.)
  • It has been proposed that we limit the number of people in these lists to 100. Or some such number.
  • Assuming we limit the number to 100, this means we would need to compile a list of almost 37,000 more than notable people. (To be precise, between 36,500 & 36,600 depending on how many notable people we wish to include for February 29.) Of course, this list has already been started: take the names of people already in the Days of the year, & add/subtract from that. (From glancing at January 30, the date Double sharp mentioned above, it appears that a lot of professional athletes will be purged from this list.)
  • Any such list of more than notable people would need to be balanced out between the various categories, such as "politicians/royalty", "religious figures", "writers/poets/playwrights", "artists", "sports", "military" & (the inevitable) miscellaneous. IMHO, having set percentages will force people towards adding only the more important figures in these categories. (And might add a little more encouragement to improving articles.)
  • Any such list will need to add a lot more people who are not from Europe & North America. (Glancing at January 30, I only found 3 Japanese people, 1 Brazilian pro athlete I mean 4 Japanese people, 1 Brazilian pro athlete, 1 Vietnamese king, & 1 president of El Savador -- & no other people from Asia/Africa/South America. I would be surprised if no other notable people from those parts of the world were born on that date.)
  • Having worked a lot on historical articles, I can confidently predict that any such list will be heavily weighted towards more recent names. It is difficult to find the years various notable people living before AD 1000 were born or died in; finding the day of birth for one is the equivalent of winning millions in the lottery! (It would be nice to find a way to indicate the approximate year a more than notable person was born or died in, but for whom more precise information is lacking. But that desideratum is tangential to this discussion.) -- llywrch (talk) 18:03, 6 March 2018 (UTC)
  • Suggestion - why don't we have this done by categories, which is what they are for? A bot could add Category:People born on 27 November to everyone with that birthday. A bot could similarly add Category:People who died on 11 June to everyone who died on the 11th of June. It's one or two additional categories per biographical article, but some have hundreds anyway. Then you can just click to that category if what you really want is to see who was born on a particular day. Having 5-6000 articles in a category is not an issue at all. You could have a direct link to the two categories on each date article (so 1 January would have a See Also pointing at Category:People born on 1 January and Category:People who died on 1 January, and so on. Fish+Karate 12:29, 15 March 2018 (UTC)
    • We don't create categories for trivial or anecdotical similarities between articles. Years of birth and death indicate the period in which someone lived: day/month of death indicates nothing. That Farzad Bazoft and Charles Harrelson share the same day and month of death is a meaningless coincidence. Please don't create such categories. Fram (talk) 13:21, 15 March 2018 (UTC)
      • It's just a suggestion. Your view on someone's day/month of birth/death being meaningless is just that: your view. Fish+Karate 14:29, 15 March 2018 (UTC)
        • Well, no, it's not "just my view". Apart from pseudoscience like astrology, there is not really much meaning to be found in the coincidence that people died on the same day (considering that we only have 366 such combinations to start with). Feel free to show me wrong, but please don't dismiss someone else's point as "just" their view when you don't have any actual evidence that it is actually meaningful. Thisis not some random objection, but the essence of categories, which should be, according to Wikipedia:Categorization, about "essential—defining—characteristics of a topic" (and further "A central concept used in categorising articles is that of the defining characteristics of a subject of the article." See WP:TRIVIALCAT for more on this. "Note that this form of overcategorization also applies to grouping people by trivial circumstances of their deaths". Fram (talk) 14:59, 15 March 2018 (UTC)

Quick comment on the numbers here. @Jayron32 and Yodin: the number given by Yodin of "over 1.5 million" is probably from the value given at Wikipedia:Version 1.0 Editorial Team/Biography articles by quality statistics - Jayron32's guess of 550,000 was a bit out, and in any case there is no need to guess, any well-designed website or database would have these statistics available, and with a bit of work it is possible to maintain statistics like "number of biographical articles". The current value at Wikipedia:Version 1.0 Editorial Team/Biography articles by quality statistics of 1,558,032 articles is still only an estimate though as: (a) not all biographical articles are tagged as such on their talk page by the WikiProject Biography template (the number untagged is a bit hard to estimate); and (b) not all the articles tagged by WikiProject Biography are 'single person' biographies - that 1,558,032 figures includes a lot of articles about musical groups, and other 'group biographies'. Another estimate is to do some sort of count over the categories and subcategories of Category:Births by year. Number of living people (again, if tagged correctly) is at Category:Living people, currently 852,728. There may be other ways to do these estimates that are more accurate. (Over time, I think the proportion of biographical articles has remained fairly steady at about 20-30% of the whole encyclopedia, as measured in terms of number of articles. What is more surprising is that living people make up over 50% of those articles.) Carcharoth (talk) 12:34, 16 March 2018 (UTC)

Rfc: Change default <math> to be inline

Unanimous opposition. Primefac (talk) 18:41, 14 March 2018 (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.

Should the "default" <math> be changed to inline in the future?--Debenben (talk) 22:47, 6 February 2018 (UTC)

Background information

Some time ago I did a little survey in the German Wikipedia on how to resolve several problems with the current markup for inline and block equations. The solution with the most support was turning "default" <math> into true inline equations, equivalent to <math display="inline"> or <math>\textstyle and using <math display="block"> or a new shortcut notation like <math block> for block equations, replacing the current :-indented markup.

Since technical limitations of the current math extension prevent several types of block-formulas from using the new notation and/or such a conversion would negatively impact the appearance on certain devices/browsers, this Rfc does not propose to implement such changes immediately. If this Rfc is successful, the intention for such a change should be written into Wikipedia:Manual of Style/Mathematics along with a recommendation: For formulas that are not block equations but still look better with large symbols, editors should specify \displaystyle explicitly instead of relying on <math> being displaystyle by default.

Some problems the proposed solution might solve in the future

Display options in the VisualEditor (here with German descriptions).
  • "default" exists for historic reasons and backwards compatibility. For most purposes "default" without further modifications like : indentation or \textstyle is technically wrong.
  • Using <math display="inline"> or <math>\textstyle for each inline formula makes the source code difficult to read and type.
  • New editors are confused by the "default" layout. They expect one notation for inline and one for block formulas with the inline markup using textstyle by default.
  • Some editors might not be familiar with the textstyle and displaystyle commands since they are used to LaTeX, MathJax etc. choosing it automatically.
  • Some editors do not bother to select textstyle explicitly, especially if there are only marginal differences e.g. vs .
  • Editors using the VisualEditor cannot create block formulas with : indentation and can get frustrated trying to get a comparable layout example
  • : is a definition list that creates invalid HTML and can be annoying for screen readers. It also creates its own paragraph <p> which is technically wrong and leads to inappropriately large separations in some browsers/devices.
  • Having two markups for block formulas, i.e. :-indentation and display="block" parameter creates inconsistent layout. For most browsers/devices the visual appearance of both is only similar in the English Wikipedia due to common.css.
  • The optimal layout of block equations depends on other layout choices such as placement of figures which can be different for mobile devices. Editors should not hard-code those choices manually e.g. by number of :-indentations. Instead, indentation would be with respect to the surrounding text without creating surplus indentation if block equations are chosen to be centered.
  • Some more advanced features such as a referencing/numbering system for block equations and automatic line breaking require a clear distinction between inline and block-equations.

Some alternatives to this solution

Alternatives that were discussed in the survey:

  • creating new HTML-tags or keywords for inline and block equations and <math> retaining its behavior,

a solution which got slightly less support and people indicated that they regard it as the second best choice only. Alternatives that got mostly oppose-votes were:

  • keeping the :-syntax for block formulas and trying to work around some of the issues
  • solutions that involve templates

Some technical problems that hinder implementing the solution

If people are interested I am happy to write and discuss these further. I don't expect much progress here and it is only worth discussing if the general intention of the proposal receives enough support.

And last but not least: I don't have any experience with Rfcs and the conventions here. Feel free to change things I did wrong and notify people that might have some opinion on this matter.--Debenben (talk) 19:56, 5 February 2018 (UTC)

@Debenben: We discussed this topic recently. Please review WP:Village pump (policy)/Archive 138#RfC: Accessibility versus convenience in indentation. --Izno (talk) 20:20, 5 February 2018 (UTC)
And especially, the discussion I started at WP:Village pump (policy)/Archive 138#Math block display. --Izno (talk) 20:22, 5 February 2018 (UTC)
@Izno: You are right, I should have mentioned this previous Rfc. I got a ping from user:Whatamidoing (WMF) because I discussed the issue with him a year ago [2] and I also left a comment. I had the impression that the closing statement "Final note, since much of the opposition was related to the mode of resolving this screen-reader compliance problem, rather than the underlying idea of addressing the problem in the first place, it's of course all right for someone interested in the discussion to formulate a new proposal without waiting for days or months to pass." referred to my comment. Therefore the above focuses on addressing the problem without providing a technical solution. A possible technical solution (also solving other problems) would have been [3] but it did not get enough support. Still, if this proposal gets through it might encourage Media-Wiki developers to do something about it.--Debenben (talk) 20:52, 5 February 2018 (UTC)
I added the Question and RFC-template to the above in order to get more input.--Debenben (talk) 22:47, 6 February 2018 (UTC)

Survey: Change default <math> to be inline

  • Oppose. Surveys of English Wikipedia editors on English Wikipedia policy have no jurisdiction over Wikimedia technical formatting issues. The actual solution is up to the developers, but even if we wanted a survey of readers and editors to suggest better directions for the allocation of the developers' time, the correct place for that would be meta because this affects all Wikimedia sites not just this one. But regardless of all that, this proposal would break the formatting of all displayed (on a line by themselves) equations on Wikipedia. That's a lot of damage in exchange for very intangible benefits. —David Eppstein (talk) 23:42, 6 February 2018 (UTC)
  • Changing is not a good idea, there must be 100000s or more pages that would need to be altered. It would cause such a huge mess, including in the knowledge of the people that use the tag. Graeme Bartlett (talk) 00:47, 7 February 2018 (UTC)
  • Oppose unless benefits are clearer. Xxanthippe (talk) 01:47, 7 February 2018 (UTC).
  • Oppose. In principle this would have been a good idea, but formatting is already entrenched. Among many proposals to do with math formatting that English Wikipedia could decide to approach devs with, this has very minimal benefits. Sławomir Biały (talk) 11:16, 7 February 2018 (UTC)
Some remarks: For the survey in the German Wikipedia I did a rough estimate on the numbers of affected block-formulas: There were in total 237 779 occurences of math tags (in the main namespace), among those roughly 55 435 block-formulas. A simple algorithm similar to the one implemented in the old MathJax rendering mode or the one still existing today on scholarpedia, transforming all : indented math tags on its own line (without anything except for a space or punctuation mark) into a block formula would recognize around 82% of them correctly. The others have different number of indentations, text-elements or labels on the same line. They would get "broken" (meaning that they get an unconventional, less beautiful layout) and need to be marked as block formulas manually or by a bot using a more sophisticated algorithm. I guess there would be a slightly higher percentage of block formulas on the English Wikipedia and the total number would roughly scale with the article count.
For all those oppose votes I would be interested in their preferred solution. As I said, the alternative of introducing new tags (something like <imath> <dmath> <ichem> <dchem>) and avoid breaking the current math formatting had only slightly less supporters. A similar solution that involved creating a new markup for inline formulas was proposed on phabricator around 2012, but blocked due to the lack of community support. The WMF has no view on the issue, currently all development and maintenance of the math extension is done by one volunteer.--Debenben (talk) 14:00, 7 February 2018 (UTC)
I think the ideal solution would be to implement \( \) and \[ \] as math delimiters. This would also solve the most recent problem of the non-accessible way that Wikimedia interprets the colon operator as part of a definition list, when the colon is used for indentation of inline equations. Sławomir Biały (talk) 19:47, 7 February 2018 (UTC)
That is probably the dream of every mathematician and LaTeX fan. It would need an equally strong concensus and I would be concerned that other people don't like it. Like: If you ask for too much you don't get anything.--Debenben (talk) 15:58, 8 February 2018 (UTC)
On the contrary, I think the approach solves a lot of problems we've been having lately. Offer the developers and editors a solution and they might implement it. Think big! Sławomir Biały (talk) 19:41, 8 February 2018 (UTC)
Just as a more "stupid" idea: What you suggested would already work today: \(\sum_{n=0}^\infty \frac{x^n}{n!} \text{this should become inline}\) and \[\sum_{n=0}^\infty \frac{x^n}{n!} \text{this should become block}\] if one would simply write something like
$("head").append("<script type=\"text/x-mathjax-config\">MathJax.Hub.Config({'HTML-CSS': {preferredFont: 'STIX', webFont: 'STIX-Web', mtextFontInherit: true}, 'SVG': {mtextFontInherit: true}});</script>");
$("head").append("<script type=\"text/javascript\" async src=\"\"></script>");
into Mediawiki:Common.js. --Debenben (talk) 21:40, 8 February 2018 (UTC)
Fairly easy in principle to implement, I'll grant. Sławomir Biały (talk) 01:16, 9 February 2018 (UTC)
True. I improved the configuration a little:
$("head").append("<script type=\"text/x-mathjax-config\">MathJax.Ajax.config.path['mhchem'] = ''; MathJax.Hub.Config({TeX: { extensions: ['mediawiki-texvc.js', 'AMSmath.js', 'AMSsymbols.js', '[mhchem]/mhchem.js'], equationNumbers: { autoNumber: 'AMS' }, mhchem: { legacy: false }}, displayAlign: 'left', displayIndent: '2em', 'HTML-CSS': {preferredFont: 'STIX', webFont: 'STIX-Web', mtextFontInherit: true, linebreaks: { automatic: true }}, 'SVG': {mtextFontInherit: true, linebreaks: { automatic: true }}, 'CommonHTML': {mtextFontInherit: true, linebreaks: { automatic: true }}});</script>");
$("head").append("<script type=\"text/javascript\" async src=\"\"></script>");
I think cloudflare wouldn't mind if we use their servers since they get an easy way to track all readers, but it probably violates some guidelines. Does anyone have access to something like a Wikipedia-toolserver that he can spare, so we can have our own cdn? I would be really looking forward to present some of the new features:
  • Working math also for devices like Ipads (In case someone is interested delivering the good news to the poor guy [4])
  • Working textmode, especially for all languages that don't use latin charakters
  • Working mhchem package
  • Copyable formulas, proper HTML
  • Fully editable in the VisualEditor (unfortunately the alpha version is lacking support for the visual formula editor)
  • Support of automatic referencing and numbering, support for linebreaking, support for missing commands like \middle
  • Support for defining macros, linking websites, popups etc. (Some of those features should probably be disabled in production)
  • Great user support, if you find a bug and report it at Github you probably get a patch within days
--Debenben (talk) 18:55, 9 February 2018 (UTC)
Ahh, and I forgot: An excellent accessibility explorer, where you can navigate through the formula with arrow keys and any average screen-reader can read out the generated text piece-by-piece.--Debenben (talk) 19:01, 9 February 2018 (UTC)
@Xxanthippe: I wanted to avoid a lengthy explanation because I was hoping for other peoples comments to highlight some of the current problems. Since this is not the case and you explicitly asked for the benefits to be clearer, I will attempt to illustrate some of the bullet points above:
A lot of inline formulas use the "default" layout, usually because the editor did not bother to specify it or is not familiar with the \textstyle command. For example if I write , then for me, if I use a standard setting in firefox in combination with the svg rendering that most people get, the expression is just a little bit too large to fit into a normally spaced line, therefore the spacing of the lines in the text is not equal but a little bit different. For most people this is only the case for larger operators like . This can be avoided by using the correct inline formatting, either by adding \textstyle or the parameter display="inline", resulting in or . If you happen to have a browser/device where the example already uses a little bit too much space, then for you there will be more inline formulas that would get fixed by the change than those that get broken. Of course adding an additional \textstyle or the parameter display="inline" for all inline formulas would already be possible today. However the wikitext would become increasingly hard to read. In the survey I used the example of w:de:Satz des Pythagoras having three sentences with seven inline formulas each, where you don't want to clutter the source code with \textstyle or display="inline" parameters for each of them. Pythagorean theorem has a similar amount of inline formulas, however they are, probably due to other deficiencies, not using math-tags. That is what I wanted to express with the flawed "slightly higher percentage of block formulas" comment above. If you had a math extension were formulas are copyable, look good etc. for everyone, then you would want to use inline math for each of them. With the proposed change, editors could forget about \textstyle or display="inline", because it would have the correct formatting by default. This is the behavior people outside of Wikipedia would expect and how it works in LaTeX or any other typesetting system. The reason it is different in Wikipedia is, that originally the math extension was not designed for inline formulas, but as a replacement for images and ascii-art block formulas. Because a lot of mathematical expressions cannot easily be obtained with normal HTML-characters, editors also used the math extension for inline formulas, even though it did not have proper size or alignment for the text (and today this is still a problem, at least for a lot of browsers/devices).
Since the original idea behind math was to create images, and you would want to be able to use those images for example in tables etc., it did not have a proper layout for block equations either (and today this is also still a problem). Editors used the : markup because it is the easiest. However it is part of a definition list markup and produces invalid HTML. As far as I know it gets indented in every major browser, but in principle the layout of a definition list can be anything and the behavior of an invalid definition list is undefined. When I select "print this page" in firefox, everything indented with : gets printed with a large font size, which I guess is due to broken definition lists. An average screenreader would tell you for every :-indented block-formula that a definition will follow, which I guess can be annoying, especially in the middle of a sentence. The other thing that is wrong is the paragraph <p> that gets created, which means that there will be a space before and after every block formula that matches the space of a new paragraph in the text and depending on the browser/device can be inappropriately large. It is also semantically wrong, because the whole point of indenting or centering block formulas is to show readers that the early line-break is not a new paragraph, but just for accommodating a large expression that cannot easily wraparound into the next line. With the proposal above, those 82% of block formulas (or whatever the exact percentage on the English Wikipedia is) would get proper HTML like the one you get on websites like math.stackexchange that is not broken, does not abuse definition list markup or create a new paragraph. The others would get proper HTML if they get fixed manually or with a bot.
Another problem concerns editors unfamiliar with the wikitext or LaTeX markup. I cannot tell first-hand, but only from looking at strange edits of new accounts or when they ask for help. Imagine you are unfamiliar with wikitext-markup. Then you would assume that you can use the VisualEditor to edit mathematical articles. You effectively cannot because you can't add :-indentations or change them. However you would not know what those indentations are. You click on an equation that is clearly an inline equation and it will show you that it is "default". Maybe it begins with \textstyle - a command even some mathematicians or physicists don't know because normally it is not needed in LaTeX. If you click on inline - nothing happens. If you click on "block" you generally get a block formula that is centered (and the English Wikipedia uses commons.css to make it indented, solving this issue and creating different problems). If you want to edit another block formula - it is also "default". If you create a "default" formula yourself you cannot get it indented. With the proposal above this would get fixed, because there would only be one inline and one block option to choose from, and if you add a new formula and don't select anything it would be a correct inline formula. If you select block formula, it would become a true block formula. I believe it would especially help people not familiar with LaTeX because they could use the formula editor of the VisualEditor, since the formula is rendered or the error message is shown immediately. They also wouldn't need to search for a formula they want to edit in the source code, where you often rely on searching for generic LaTeX commands or words somewhere next to it.
These are the main points. As you can see from the bullet points above, there are some other (in my view minor issues) that would get solved. There is also a whole bunch of things problematic with current usages of the display="block" parameter which I have not touched. Since this fortunately only concerns 165 pages at the moment I have left this out for now.--Debenben (talk) 15:58, 8 February 2018 (UTC)
  • Oppose anything that would break the formatting in thousands of existing pages. Maproom (talk) 08:07, 9 February 2018 (UTC)
I don't know what I did wrong: I did not expect only support votes, but I expected some comments and discussion on the issue. I'll try to discuss with myself the comments so far:
  • Its a global issue: True. The purpose of this Rfc is to gather feedback directly from editors affected by such a change that can be used (e.g. in a discussion on meta) to supplement the feedback I got from German Wikipedia and Wikisource editors. So far I get the impression that the English Wikipedia editors just don't care.
  • It's up to the developers: As I pointed out, I had a discussion with Whatamidoing. For now it seems, the WMF does not have any resources to spend on working out a solution or fixing some of the problems.
  • The proposal breaks a lot of block formulas: True, although I think "breaking" is a strong word for a less beautiful layout for some equations which is compensated by a more beautiful layout for others. I respect people that do not want the existing articles to change at all. For the math tag this essentially means it cannot get fixed (unless someone can come up with a miracle solution nobody has thought of so far). Consequently this translates into the alternative, which is support for introduction and migration to a new notation.
  • It causes confusion among the editors: I would say this proposal would rather reduce the confusion. The argument of creating even more confusion was the main reason why at the German Wikipedia this solution was preferred to the alternative of creating a new notation. Editors can continue to use "default" in the text and get the proper inline formatting. If one is worried by a solution that would treat the indentation markup as a modifier as opposed to also replacing those 82% with a bot: This is not part of the proposal and (in my view) can be discussed after it is decided if the current <math> notation should be rescued or not.
  • The benefits are unclear: This could be a reason why people don't want to vote on the issue, but please leave a question or comment, this would help others to make up their mind.
  • Introducing \( \) and \[ \] as math delimiters: A great solution. Some background: The two delimiters are the minimal set of LaTeX commands required to get all necessary features. For those that wonder about commands like ref, eqref etc: They can be used inside the delimiters like it is done for align today, which, from a LaTeX (and MathJax) point of view is correct, only a bit more complicated than necessary:
The example
one \label{thefirstlabel}\\ 
two \label{mysecondlabel}
as a fraction 
\frac{\eqref{thefirstlabel}}{\eqref{mysecondlabel}}=\frac{ne}{tw} \label{theresult}
does not make sense. Also, equation \(\ref{theresult}\) does not show that \(\ce{H2O}\) means water.
When adding the javascript above to common.js and removing the syntaxhighlight it already works today. The drawback: This is similar to what was proposed around 2012. I am especially worried that it will be me, having to convince people that mixing the HTML-like wikitext notation with LaTeX commands is worth it and that at the end of the day I have wasted even more time with discussions and achieved nothing.
  • A question which did not come up: What does it have to do with MathJax? In principle nothing, because all the problems mentioned in the bullet points are caused by the notation and don't get solved by a new rendering system. I wanted to show how other websites handle it, that Wikipedia is essentially the only website with these problems and some features necessary for being able to convert all current block-formulas. There is some hope: The Mathjax-Node spin-of currently generating the svg images and MathML in Wikipedia will be eaten up by MathJax version 3.0 in the future, creating the possibility that some developers take the opportunity to get MathJax 3.0 fully implemented in MediaWiki.
--Debenben (talk) 16:14, 12 February 2018 (UTC)
  • Oppose for reasons given. I have not done much (any?) editing along these lines, but would have little or no objection to a new format if it has any clear benefit, even in moderately unusual situations, but not as a new default. It would have to be a newly added facility and would be up to those benefiting, to discover the documentation. JonRichfield (talk) 05:14, 14 February 2018 (UTC)
  • Oppose in favor of helpsheet or templates. As noted above, the users can be advised to insert the "\textstyle" to show an inline, text-styled formula, as could be noted on a helpsheet page. Also, consider creating simple templates for users who search for common templates to format typical table or formula patterns. A template could be written to force inline format of a formula in parameter 1 as in: {{#tag:math|\sum_{i=0}^\infty|display="inline"}} to show: where the limits i=0 to would display after the sigma summation symbol. Templates have enormous power to simplify work for new users, but people keep deleting such smart templates for sketchy reasons. -Wikid77 (talk) 22:47, 28 February 2018 (UTC)
Thanks for your suggestion. I believe you are suggesting to use something like {{tmath}} that sets display="inline" automatically? The main drawback that I see with the solution is that one cannot use the usual LaTeX markup like {{tmath|\frac{1}{\sqrt{|f(x)|}}}}, but instead one has to write {{tmath|\frac{1}{\sqrt{\vert f(x)\vert } } }} to avoid clashing with the template markup, or is there a way to avoid this? There was a similar suggestion some time ago: Wikipedia_talk:WikiProject_Mathematics/Typography#Consequences_of_a_lack_of_consensus_concerning_inline_text_style_mathematical_formulae, but it seems like the initiator has given up on the subject.--Debenben (talk) 16:56, 1 March 2018 (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.

Change to the wording of Wikipedia:No original research

Diff. Comment by @Chris troutman: "While you're probably right, I don't think it's appropriate to change the wording of a policy without consensus.". I didn't think I really changed the meaning, but I can see the point, so lets see if there would be consensus. Alexis Jazz (talk) 04:54, 17 February 2018 (UTC)

  • I'm not opposed to the addition, although I think some wordsmithing might be needed since the following sentence about something being attributable versus being attributed better appears immediately following the point about Paris. I would like to see if there's consensus for this change. Chris Troutman (talk) 04:59, 17 February 2018 (UTC)
    I would oppose it, but for a rather nuanced reason. The "citing the sky is blue" trope is too idiomatic at Wikipedia to carry meaningful policy weight; there's an entrenched, old debate over the specific idiom to the point where we have competing essays, Wikipedia:You don't need to cite that the sky is blue and Wikipedia:You do need to cite that the sky is blue and the nuance is that sometimes you do actually need to cite the obvious and sometimes you don't, and context (not policy) will tell you when. I think the OP made a good-faith clarification, but the Paris, France example is sufficient and unlikely to carry the cultural baggage that the "sky is blue" idiom just does at Wikipedia. --Jayron32 05:05, 17 February 2018 (UTC)
@Jayron32: Okay. I didn't really make the edit to clarify it though, it just seemed like the most sensible way to put WP:BLUESKY in there. Any suggestions to link BLUESKY, or should it not be linked at all in the policy? Or should BLUESKY be changed to FRENCHCAPITAL? Alexis Jazz (talk) 05:11, 17 February 2018 (UTC)
I don't think you should link anything there, the meaning of the sentence is plain and unambiguous and doesn't need further elaboration. --Jayron32 05:13, 17 February 2018 (UTC)
I wouldn’t link to WP:BLUESKY without also linking to WP:NOTBLUE. So best to not link either. Blueboar (talk) 10:56, 17 February 2018 (UTC)
Something else to consider... the reason why "The capitol of France is Paris" is a good example to use in the NOR policy isn't so much that the truth of the statement is obvious... but that (as a statement) it is extremely verifiable. There are literally thousands of sources that could be cited to support it. In other words, it is the fact that the statement isn't original research that is obvious. Now... "the sky is blue" is also quite verifiable (and thus is not OR)... but... the counter argument (that the sky isn't actually blue) is also quite verifiable. So it does not make for a good example to use in our NOR policy. Blueboar (talk) 13:13, 17 February 2018 (UTC)
  • I don't see the addition adding to the policy. In general, the shorter the policy, the better, and any addition that doesn't add context or explain the policy better is superfluous. Making it longer just to add a link WP:BLUE seems pointless since that information page isn't about original research, it is about citations for things that are obvious. Dennis Brown - 13:33, 17 February 2018 (UTC)
  • As for the proposal, I suppose it wasn't the best idea.
As for France, @Blueboar: I am starting to have some doubts. How would you source the fact that the capital of France is Paris? Sure, you could link some maps. But that's not exactly an authoritative source. You could link, that may be slightly better but still not the source. On the Paris article the statement "By the end of the 12th century, Paris had become the political, economic, religious, and cultural capital of France." is backed up by a 2010 city guide. Um. It seems to trace back to "Clovis the Frank, the first king of the Merovingian dynasty, made the city his capital from 508." which looks like an uncited fact. (although I suppose it'll be found in "Paris, des origines à Clovis" cited all the way at the end of the paragraph) I now actually do wonder what a proper source for the statement "The capital of France is Paris" would even look like. My best guess would be it's codified in law somewhere. I wouldn't mind if Wikipedia linked that law, even if only for historical purposes. Alexis Jazz (talk) 15:43, 19 February 2018 (UTC)
Alex... just about any modern atlas could be cited for “the capitol of France is Paris”... it is also mentioned in numerous encyclopedias, dictionaries, almanacs, newspaper articles, tourism guides... etc. etc. etc. this isn’t the kind of controversial fact where we would require a high end scholarly source (but if someone insisted, I am sure there are plenty that could be cited). Blueboar (talk) 18:30, 19 February 2018 (UTC)
How about a source for this statement: "There was no hurricane anywhere in Modesto California yesterday." North8000 (talk) 18:50, 19 February 2018 (UTC)
@North8000: You would probably use something like as a source for that, although that only proves it wasn't that windy. In general you can't prove a negative. A source for "The capital of France is Paris" could be given, but a source for "There is no God" can't be given. Have some tea. Alexis Jazz (talk) 19:27, 19 February 2018 (UTC)
@Alexis Jazz: But that would be O/R / synthesis to derive my statement from that  :-). My example was kind of whimsical, but we had a real life issue like that. An otherwise-RS made an error (or poor choice of words) and called a public figure something that was somewhat negative but obviously in error, so blatantly untrue that (like my hurricane example) that no source is going to cover to say the opposite and refute it. Some POV folks liked the obvious error and used wiki-policy to keep it in. North8000 (talk) 22:44, 19 February 2018 (UTC)
@North8000: Now I'm curious what exactly you are talking about. What is it? Alexis Jazz (talk) 01:34, 20 February 2018 (UTC)
@Alexis Jazz:It was a painful old dispute that was formative in my wiki thought process that I really don't want to go back to, but the statement was that Ron Paul (the guy advocating trade with Cuba) is an isolationist. I think the mis-statement came from him being a non-interventionist. I learned a few things from that. One is that even genuinely wp:"reliable" sources can be unreliable on a particular topic. The second is that sources don't cover implausible statements that practically nobody is making. Such as my hurricane statement. North8000 (talk) 11:51, 20 February 2018 (UTC)
@Blueboar: So citing another encyclopedia for a fact is acceptable? Did not know that. I won't insist on a source, but I wondered what it would look like. I mean, if we were to cite an atlas you could ask the atlas people "so how do you know?", you ask whoever they mention how they know and eventually you should arrive at some actual source. I wondered what that might be. Alexis Jazz (talk) 19:27, 19 February 2018 (UTC)
Well, a lot depends on the specific encyclopedia and the specific fact... but yes... just about any published general encyclopedia would be quite acceptable for verifying which cities are national/regional capitols. As for what the citation of an atlas might look like... it would look something like this:[1]
  1. ^ The Times Comprehensive Atlas of the World (14th ed.). HarperCollins UK;. 2014. p. 23. ISBN 0007551401. 
(note: I don't have an actual copy of the Times Atlas in front of me, so I did make up the page number - just for the sake of giving an example... obviously if I were formatting an actual citation, in an actual article, I would take the time to look up the actual page to cite). Blueboar (talk) 20:41, 19 February 2018 (UTC)
Thanks for your answer and information on citing another encyclopedia. What I actually meant though with "what it would look like" was if you would ask the atlas people how they know, they point (for example) to the map makers and you ask them how they know, they point to some database and you ask the people who made that how they know.. And in the end I guess you will end up with a law or similar I think? And what does that law look like. For "The United States is a nation" for example, I think you'll end up with the United States Declaration of Independence. But I don't know what you would get for "The capital of France is Paris" and that's what I am curious about. Alexis Jazz (talk) 01:34, 20 February 2018 (UTC)
That would be a primary source, which policy says we should avoid when possible WP:PRIMARY. At the time, there wasn't universal acceptance that the Declaration of Independence established the United States as a nation, so it is not irrefutable. Some people might say it is the Constitution or some other document that established the United States as nation, and some might say that the Second Continental Congress had no legal right to declare independence from the Kingdom of Great Britain (the British certainly disputed it at the time). Thus we need WP:SECONDARY WP:RELIABLE sources to verify that the United States is a nation. As for Paris, I'm just not sure. What makes you think that Paris is the capital of France? Right now, the source in the Paris article is Le Parisien and, on the face of it, I can't consider that source to be completely impartial. Jack N. Stock (talk) 01:59, 20 February 2018 (UTC)
@Jacknstock: I can't thank you enough for your response. No seriously, I can't. The thanks system is broken. And you are absolutely right. I think Le Parisien is pulling our leg when they say Paris is the capital of France. Everybody knows Paris is in Denmark. Alexis Jazz (talk) 12:22, 20 February 2018 (UTC)
IMHO, this aversion to citing primary sources sometimes reaches a phobic & impractical extent. If one needs to cite an authority to state that the Athenians (& allies) defeated the Persians at Marathon, why not cite Herodotus directly instead of a secondary source? Those secondary sources will rely on Herodotus for that fact. (As for the consequences of this battle, yes a secondary source should be cited to substantiate an opinion.) As for an authoritative source proving that Paris is the capital of France, has anyone here considered there might be an administrative French law establishing just that? (Which one, I don't know. I would contact a French embassy for that fact. That is, unless anyone reading the article will get cooties because a primary source is being used.) -- llywrch (talk) 18:25, 6 March 2018 (UTC)

Just a reminder: You (the individual editor) should not revert anything unless you personally object to its actual content. Your objection can be quite minor, but it should be an objection that you actually hold. This is actually our formal policy on the subject of updating policies: "you should not remove any change solely on the grounds that there was no formal discussion indicating consensus for the change before it was made. Instead, you should give a substantive reason for challenging it and, if one hasn't already been started, open a discussion to identify the community's current views."

One of the reasons for this is if you revert something because of your guess that some other, hypothetical editor might object (or because you don't think that WP:NOTBURO should be a policy), then the BRD-based resolution process is going to be broken. Those conversations tend to go like this:

Bold editor: So why do you object to this change? How can I improve it?
Reverter: I don't.
Bold editor: So why the heck did you revert it?
Reverter: Aren't you supposed to get written permission first, before making a change?
Bold editor: Not according to WP:POLICY. Not according to WP:NOTBURO. Not even according to WP:CONSENSUS.
Reverter: Well, someone would probably object. I'm sure there's something in every change to a policy that would bother someone.
Bold editor: Well, nobody actually did object, did they?
Reverter: I dunno. But someone told me last year that I had to get consensus for my change, so you have to get consensus for yours.
Bold editor: <screams>

Let's not have that, okay? If you personally don't believe that a change makes a page worse, then please (please!) let the reverter be someone who actually does hold that POV. Then the bold editor actually has a chance at finding out what's wrong with the proposal. WhatamIdoing (talk) 04:39, 24 February 2018 (UTC)

RfC: update to banning policy for repeat sockmasters

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
  • Summary--The proposed policy change has a near-unanimous consensus and the amendment to the policy is thus Approved.
  • Details--
    • It's snowing rampantly over here and given the advertisement of this discussion at multiple prominent venues, there does not seem to be much rationale in keeping this open for any longer span of time.
    • As to the finer nuances of the wording:-
      • The word de facto shalln't be introduced in the policy-write-up.
      • GreenGiant's slightly-tweaked wording also fits nicely.
    • There has been an idea to introduce a parameter at Template:Sockpuppeteer to identify banning under the purview of this policy-change.That may be tried out.
    • To re-iterate two salient themes of the discussion:--
      • The CU evidence must be publicly documented.
      • Socks tagged solely on basis of behavioural evidence will not be considered under the purview of this upgradation.
  • Signed by ~ Winged BladesGodric at 07:19, 9 March 2018 (UTC)

After being pointed out by Newyorkbrad at AN earlier that we might want to find a streamlined way to deal with community bans for repeated sockmasters to avoid what has become a recent trend of seeking formal bans for them at AN, I began workshopping some language with other users, and would like to propose the following additions be made to Wikipedia:Banning policy:

Editors who have been found to have engaged in sockpuppetry on at least two occasions after an initial indefinite block, for whatever reason, are considered de facto banned by the Wikipedia community. Publicly documented CheckUser evidence should typically be involved before a user is considered banned in this way. Users fitting this criteria are subject to the same unban conditions as users banned by community discussion.

Administrators should typically place a notice at Wikipedia:Administrators' Noticeboard alerting the community of such a ban as well as place Template:Banned user to the master's user page and add the user to any relevant Arbitration Committee sanctions enforcement list.

The terms of the proposal would make it so that after three indefinite blocks, a user is considered de facto banned under the banning policy. TonyBallioni (talk) 19:31, 20 February 2018 (UTC)

  • Comment – "this criteria" should be corrected to "this criterion", the correct singular. "Criteria" is plural. Dicklyon (talk) 05:34, 23 February 2018 (UTC)

RfC !votes

  • Support as proposer. Common sense alternative that codifies existing practice on unblocks in these scenarios, and will cut down on the threads at AN. The second paragraph being the standard form of enforcement, but distinct from the core of the proposal which in the first paragraph. TonyBallioni (talk) 19:31, 20 February 2018 (UTC)
  • Support A return to the way it used to be. This used to be codified into policy years ago, something to the effect of "Any user which no admin would unblock is considered de facto banned, and subject to the same restrictions as any banned user". Somewhere along the line, the common sense of that thinking was replaced by stupid worthless bureaucracy. It's time we returned to the notion that we don't have to vote on everything, if someone has been shown the door and can't stay away, they're just not welcome anymore. --Jayron32 19:38, 20 February 2018 (UTC)
  • Support This will end the need for threads at AN and AN/I about these editors. MarnetteD|Talk 19:48, 20 February 2018 (UTC)
  • Support - The AN/ANI threads like this are ridiculous and only serve to give recognition to the trolls. Anyone who is socking to the point of being blocked on sight doesn't need a community discussion for us to know that they shouldn't be here. -- Ajraddatz (talk) 20:29, 20 February 2018 (UTC)
  • Support GMGtalk 20:31, 20 February 2018 (UTC)
  • Comment I would support if that second paragraph were removed. You want administrators to notify the community via AN whenever an editor is found to have engaged in sockpuppetry twice? That wouldn't reduce the number of ban threads, it would greatly increase them. Sro23 (talk) 20:57, 20 February 2018 (UTC)
    • Sro23, it depends on the situation, this was seen as a positive during the brainstorming as a way to keep accountability up. Obviously DENY is in play here, and the second paragraph was tweaked because of that. Looking over the AN threads, the comments I received on my draft of this, and other comments I received off-wiki, people prefer that there be some accountablility here, and that the tagging here fall under admin accountability, even if it is mainly clerical.
      I thought of this earlier today, and I think in practice the implementation would be somewhat like the requirement to notify for ECP or AN/RFC: a transcluded subpage could exist that archived quickly, but allowed for more public viewing of actions here. I don't think this is something that would be necessary for the random trolls and copyvio people who have made less than 100 edits, but would be something we want for vested contributors who later turn out to be sockmasters in order to promote transparency.
      As I said during the drafting, a lot of these concerns are about specifics of implementation that can be dealt with on a more practical level after the RfC by bold edits. The feedback I got was that people wanted a streamlined system that was also accountable. I think this is the best way to accomplish both of those goals, and think that there are ways to address your concerns. TonyBallioni (talk) 21:08, 20 February 2018 (UTC)
    • The WP:AN thread would consist of "I blocked XXXX the sockpuppet of YYYY and put a banned tag on YYYY's page as this is the 3rd instance of socking by this indef blocked editor. Putting here in case anyone wants to review." That is about it. It won't be a long drawn out discussion. Maybe a few editors will say "looks good", or if I have screwed up, they will say so. Tagging like this should be an admin only thing, and subject to WP:ADMINACCT, thus we need reporting. Dennis Brown - 13:48, 21 February 2018 (UTC)
  • Support per the clarification below and subject to it only applying once enacted and not retrospectively. Mjroots (talk) 21:22, 20 February 2018 (UTC)
  • Support per Jayron and applying a sudden outbreak of common sense. And I'd rather see a dozen "Notification" threads then yet another "Let's discuss this but we all know how it's going to happen and then hopefully there will be a snarky close which I will chuckle at" thread. ~ Amory (utc) 21:24, 20 February 2018 (UTC)
  • Support would reduce the number of pointless noticeboard discussions. Hut 8.5 22:16, 20 February 2018 (UTC)
  • Support: Much faster process than opening a discussion at AN or ANI. — MRD2014 Talk 00:47, 21 February 2018 (UTC)
  • Support Considering TonyBallioni's reply to my question below.--Jetstreamer Talk 00:56, 21 February 2018 (UTC)
  • Support, but suggest using a parameter in Template:Sockpuppeteer to indicate banned status, rather than slapping around separate templates. GABgab 02:35, 21 February 2018 (UTC)
  • Support. Time to stop wasting time with these people. ♠PMC(talk) 04:57, 21 February 2018 (UTC)
  • Support The latest 3 or so banning discussions on AN proved that something like this is long overdue, because the pile on support is just symbolic since no reasonable editor can argue against enacting such ban on prolific socks and recidivist vandals (cf. Dysklyver speedily closed ban discussion). I also agree with GAB's suggestion, to add parameter to {{Sockpuppeteer}} to indicate this kind of auto-ban. The traditional {{banned}} then can still be used where the discussion did indeed take place, since this proposal is not proposing abolishment of ban discussions completely. –Ammarpad (talk) 06:33, 21 February 2018 (UTC)
  • Support Avoids the ANI thread of horror. !dave 06:51, 21 February 2018 (UTC)
  • Support It will save a lot of time and frustration. How to deal with articles started by those sockpuppeteers and sockpuppets? The Banner talk 11:07, 21 February 2018 (UTC)
  • Support - time the process was streamlined. Not that banning will stop the socking - like it didn't with Kumioko's WMF ban (Ha! I actually met that guy) - but it will be easier to close the SPIs they cause and range block them. Kudpung กุดผึ้ง (talk) 11:13, 21 February 2018 (UTC)
  • Support - This solves a couple of problems, including the perpetual AN ban discussions for editors who are already banned, as well as answering the question about automatically reverting edits of their socks. Rarely do we really need a de jure ban discussion for prolific sockmasters, so this would reduce the paperwork for what is always blindingly obvious. Dennis Brown - 13:39, 21 February 2018 (UTC)
  • Support - This sounds reasonable and will hopefully free up admin attention to other priority topics. - Knowledgekid87 (talk) 14:55, 21 February 2018 (UTC)
  • Support - Each time a thread is started we're essentially giving recognition to the trolls/socks, Doing it this way is not only quicker but also we're pretty much DENYING any sort of recognition, 110% support. –Davey2010Talk 16:41, 21 February 2018 (UTC)
  • Support per nom and pretty much everything written above. -Ad Orientem (talk) 16:47, 21 February 2018 (UTC)
  • Support for the reasons given above. These come up more than occasionally at Category:Requests for unblock and I believe this proposal will help clarify such cases. I don't particularly see a need to post a nice at WP:AN but I believe we expect such notices would be literally that, a notice where typically nobody needs to comment. So, fine, I can see the value. :) --Yamla (talk) 18:11, 21 February 2018 (UTC)
  • Comment I have been myself treating a couple of sockmasters that they are "on verge of getting sitebanned".[5][6] This proposal will make things easier but I disagree with "CheckUser evidence should typically be involved". Banned editors like Colton Cosmic have been socking with IP [7] and CheckUser won't help you there. D4iNa4 (talk) 18:26, 21 February 2018 (UTC)
  • Oppose. If CU evidence is involved, they should be CU blocked, not community banned. Note that any such community ban would be appealable to ArbCom, as private information (CU evidence) would be involved. ~ Rob13Talk 18:32, 21 February 2018 (UTC)
No, BU Rob13, CU don't make policy, they just provide us with the information we need to help us in our decisions to block and/or ban. A 'CU block' is only where private information, such as linking a name to an IP is not allowed, but in many banning cases, the socks have already done that for themselves. And of course, try as they may, Arbcom do not make policy either - they implement it. Kudpung กุดผึ้ง (talk) 00:09, 22 February 2018 (UTC)
I don't care at all about that, obviously. It doesn't change ArbCom's workflow at all. It does make it impossible for individual CUs to lift blocks on long-term sockmasters without community consultation, but they don't do that anyway. What I do care about is that now almost every CU block ArbCom reviews will also (technically) be a community ban. That's going to cause drama that no-one really wants to deal with. ~ Rob13Talk 02:12, 27 February 2018 (UTC)
Neither group makes policy, but the existing blocking policy allows CheckUsers to make any block based on CU data a CU block. The data they based the block upon is the private information you reference. The Arbitration Policy allows ArbCom to review the appeal of any block or banned user. We choose not to review community bans except in the presence of private information. As noted earlier, CU data is always private information, so any block or ban based on CU data can be appealed to ArbCom. ~ Rob13Talk 01:34, 22 February 2018 (UTC)
I raised the option of making CU blocks effectively bans in an earlier discussion. The RFC takes nothing away from existing CU blocks that involve private date, but is for removing the unnecessary bureaucracy of ban discussions on publicly known sockmasters where a CU Admin has confirmed that 2, or more, accounts are linked. Mixing CU blocks involving private information with this discussion muddies the waters. Blackmane (talk) 03:43, 22 February 2018 (UTC)
@Blackmane: The point of a community ban is to force community review before the editor is unblocked. That is the only purpose of a ban, since our policy treats banned and blocked editors otherwise the same. In the case of CU blocks, those blocks can't be lifted by the community, and so a community ban is pointless. Note that individual CheckUsers essentially never lift CU blocks for reasons other than mistakes; they just let ArbCom handle it. ~ Rob13Talk 16:59, 22 February 2018 (UTC)
Not entirely true: ArbCom does have the capacity to review CU blocks and bans involving private information, nothing would change that. ArbCom already might be involved in the reviews of every CU block that is also reviewed by the community: nothing here would change that either.
You are wrong, however, in saying that it is not normal for the community to review CU blocks. It is relatively standard for a blocked user to make an unblock request via UTRS or even on their talk page, a CU to review it, post results, and then it be brought to the community for discussion. These are all examples of CheckUser blocks reviewed by the community: [8], [9], [10], [11], [12]. This addition has no impact on the ability of ArbCom to review a CheckUser block. What it does do, however, is require that in situations where a user has block evaded multiple times, that short of an appeal to ArbCom, they must have community review.
If this is already standard procedure for non-ArbCom reviewed CU blocks, then all we are doing is codifying it, which is a good thing as it makes sure these reviews are consistent. If it is not already the standard procedure, then it is also something that the community clearly wants as this has near unanimous support. Nothing here impacts ArbCom's abilities to review blocks. All it does from an unblocking angle is make procedures clearer for CUs and admins who are dealing with requests made on user talk pages or via UTRS. If what you say is true that all CU unblock reviews should be handled by ArbCom and people see this as an making it harder to be unblocked short of a direct appeal to ArbCom, then it would also be good for you as it would encourage them to make an appeal there. TonyBallioni (talk) 23:50, 22 February 2018 (UTC)
@BU Rob13: The purpose of the RFC iss to define the practice around editors being indefinitely blocked, but not by a CU. If a CU comes along and makes the call to levy a CU block, that changes the block conditions to those governed by the CU block policy, and would be at the discretion of the CU admin. This RFC has no impact on that. What is being set up here is a process whereby editors who are indefinitely blocked by non-CU admins and who have been caught socking, with the assistance of a CU admin, are considered banned, but not as a CU levied block. The block would remain a non-CU indefinite block just that the conditions around that block would now fall under the banning policy. I'm not sure where the confusion is. Blackmane (talk) 03:17, 23 February 2018 (UTC)
For clarity, CU blocks would fall under this, but the ability of ArbCom to review them would not be impacted. This simply cuts down on the pointless ban discussions and sets a procedure for when a user has not specifically appealed to ArbCom, but has appealed on their talk or via UTRS (which any search of the AN archives shows is not out of the ordinary.) TonyBallioni (talk) 03:37, 23 February 2018 (UTC)
Cuts down on the discussions by initiating a discussion for every single editor blocked twice for socking? This will increase discussions, given the reporting requirement at AN. I'll reiterate that CU blocks should be used if CU evidence conclusively proves socking. Given the requirement for "publicly documented CheckUser evidence" before implementing a ban of this type, that's your whole use case. ~ Rob13Talk 03:39, 25 February 2018 (UTC)
@BU Rob13: there is no requirement to report the ban at AN (and I can see reasons not to). This is about the basics - anyone who is caught twice socking while being indef blocked is deemed community banned. Full stop. No discussion needed, no tagging needed - that is the plain mathematical outcome. Three strikes and you are out. Whoever wants to do the tagging/reporting/recording is fine, but if the sockmaster repents and tries to request an unblock, then the administrator that is considering to pull the trigger should be aware, even if the editor was not tagged, that they are actually community banned (and there may be reasons to actually not make it public (deny the trophy), as there may be reasons to actually hold a community discussion even though this policy applies (award the trophy)). And although CU blocks technically fall under this, 'Publicly documented CheckUser evidence should typically be involved' (my bolding) leaves the possibility open for clear WP:DUCK cases where there is no true CU evidence (needed). If someone returns as a mallard, as a ringed teal, as a common scoter, as a golden cascade, ánd as a hook bill, they are still definitely socking more than two times - and hence would be considered community banned, and a discussion on WP:AN would have the same effect as that: the regular consensus to consider the editor community blocked (and hence would need community consensus or ArbCom to get unblocked). --Dirk Beetstra T C 10:16, 5 March 2018 (UTC)
  • Support Seems like a sensible way of streamlining the process. --Malcolmxl5 (talk) 20:03, 21 February 2018 (UTC)
  • Support — Per nomination, and other support votes, would greatly streamline the process.
    Regards, SshibumXZ (Talk) (Contributions). 20:42, 21 February 2018 (UTC)
  • Support – I've never really understood the need to request a community ban for these kinds of editors. The administrative state of affairs changes only marginally, if at all, before and after the decision to ban. As this proposal is designed to cut back on such proposals at the admin noticeboards, I suppose I support this in principle, though I'm not sure whether even Template:Banned user is necessary per WP:DENY. Mz7 (talk) 21:03, 21 February 2018 (UTC)
  • Support I cannot understand BU Rob13's opposition (as in, I'm reading his words but can't make out the meaning). Anything that closes the door on ne'er-do-wells is a good thing, private information be damned. Chris Troutman (talk) 02:04, 22 February 2018 (UTC)
    • @Chris troutman: I'm saying that CU blocks already close the door. You're building a second door and then shutting that one. If the original door were to open, the fact the new door is closed would be irrelevant. Perhaps I'm straining the analogy, but I think it actually works fairly well; if ArbCom accepted an appeal of a CU block, we would also lift the community ban. This is adding a bunch of process wonkery that is completely irrelevant to any end results. It has no effect but to increase bureaucracy, make a bunch of pointless threads at AN, and waste the time of editors who could do good elsewhere. ~ Rob13Talk 17:02, 22 February 2018 (UTC) Fixing ping: Chris troutman ~ Rob13Talk 17:03, 22 February 2018 (UTC)
BU Rob13, this is beginning to divert from the essence of the proposal. As I read it, the RfC not intended to endanger the 'power' vested in you (or others) in giving you the CU bit or you being an Arbcom member. Kudpung กุดผึ้ง (talk) 18:34, 26 February 2018 (UTC)
  • Support As I was involved in a small way with the drafting of the RFC, my support is obvious. Blackmane (talk) 03:45, 22 February 2018 (UTC)
  • Support - I'm one of those editors who almost always !votes in favor of a formal ban for such editors, feeling that an understood de facto ban was just not enough, and a formal ban give a little more protection to those deleting the contributions of those editors. I'm happier with this, although I don't think the phrase "de facto" needs to be in there, as what is being proposed is essentially a formal ban under X circumstances. Nevertheless, I support this, as the formalization of a de facto ban in policy makes it a formal ban, and therfore no longer de facto. (I hope that wascomprehensible.) Beyond My Ken (talk) 05:13, 22 February 2018 (UTC)
    @Beyond My Ken: Perhaps I understand you. "De facto" should not be in this proposal and should be removed now. Because what usually happens is that a repeat sockpuppeteer (Like Dysklever example above) is usually de facto banned once they accumulate like 2-3 entries at SPI and that's why discussion to turn the ban into de jure is usually closed speedily as enacted. Now if this proposal passes, then it will effectively triggers de jure ban automatically at second instance of socking which is as effective as any ban enacted after AN discussion. Therefore since ban enacted after AN discussion is not de facto but formal this one too is not de facto but formal. But if the proposer is aware of this and still meant it to be de facto then still we need to discuss the real formal ban at AN. And from the impressions of everyone above and the intent of the proposal (as I understand it) is to stop the needless and largely symbolic ban discussions at AN which are time waste and even dignifying to the recidivist sockmasters whom we should WP:DENY. –Ammarpad (talk) 07:39, 22 February 2018 (UTC)
    @Beyond My Ken and Ammarpad: to borrow a line from BMK's talk page, this is a crowdsourced horse. I mainly drafted it and got feedback on certain points in order to craft language that I thought would be a consensus version that everyone could get behind when put to an RfC, even if they had minor quibbles. The de facto language was wanted by some because it made clear that there had not been a discussion. I don't think it necessary, but I also don't see the harm. The language is clear that WP:UNBAN applies to these cases, which is the only functional difference between an indef block and a ban. Because that is the case, the distinction between de jure and de facto ban is no existent in terms of actual impact. The only difference is whether a discussion has been held. TonyBallioni (talk) 14:19, 22 February 2018 (UTC)
    I can live with it, I was just pointing out a logical inconsistency. Better to have it than not. Beyond My Ken (talk) 00:56, 23 February 2018 (UTC)
    Agree too, it is an improvement, though not as I expected. So under the current system, a repeat sockpuppetter is usually seen by the community as banned both through despising their actions and how they respond in banning or unblocking discussion about them. But this practice is not codified and not written anywhere, and that's the essence of this proposal to codify and give written recognition to this accepted practice. –Ammarpad (talk) 06:40, 23 February 2018 (UTC)
  • Support proposal in spite of believing its verbiage can be improved. It is sufficiently sound and no time limits prevent improvements from coming about later; over time.--John Cline (talk) 20:51, 22 February 2018 (UTC)
  • Support - The less long and useless threads, the better. RileyBugz私に叫ぼう私の編集 00:07, 23 February 2018 (UTC)
  • Support with minor tweak. "De facto" means that it's not codified; that's like saying "When someone's found to have gotten three indef blocks for sockpuppetry, he's officially been unofficially banned." But the point of the proposal is great. Almost never do we need to have those ban discussions, because such users are almost guaranteed never to be unblocked without a long and careful discussion. And in the situations where we do need those discussions, it's because the user's somehow less obvious (e.g. making appeals on UTRS) and might get unblocked by someone not aware of the situation. Such users should never be unblocked without a discussion, so let's make it official that they are to be considered banned and that we can place a template indicating "banned user" onto the userpage, to ward off ignorant unblocks. Nyttend (talk) 05:02, 23 February 2018 (UTC)
    • I'm fine with the tweak removing de facto I think there has been enough feedback on that point here to suggest it isn't necessary, and the wording at the end about facing the same unban conditions as those banned by community discussion makes it clear that there wasn't a discussion. Also, agreed, on all your points. TonyBallioni (talk) 15:02, 28 February 2018 (UTC)
  • Support wording and implementation can always be tweaked, but the idea is right - avoid unneeded ban discussions and show baby-sockmasters that they are sitting on the ejection seat. Agathoclea (talk) 15:19, 23 February 2018 (UTC)
  • Easy support Makes perfectly reasonable sense. Doc James (talk · contribs · email) 11:50, 24 February 2018 (UTC)
  • Support per TonyBallioni and further it saves time to avoid Ani discussions and clearly a way to steamline the process.Pharaoh of the Wizards (talk) 16:37, 24 February 2018 (UTC)
  • Support I was actually thinking about this the other day; it makes it easier to go to sites like Fiverr, Upwork etc. and go "this user is indefinitely community banned on Wikipedia, please remove their paid editing services from your site". jcc (tea and biscuits) 19:11, 26 February 2018 (UTC)
  • Support. This strikes the right balance between protecting the project and allowing for mistakes by users acting in good faith. Thryduulf (talk) 13:03, 28 February 2018 (UTC)
  • Support per Nyttend. --NeilN talk to me 14:57, 28 February 2018 (UTC)
  • Comments. I didn't know this existed until now, hence my belated comments. First, the language. Simpler: "Editors who have created two new socks after an initial indefinite ..." I don't know what exactly "publicly documented CheckUser evidence" means. I assume that a CU has to be involved in the blocking of the two new socks, but does the finding have to be confirmed or "technically indistinguishable"? Can it be likely? Possilikely? Seems fairly ambiguous to me and likely to lead to interpretation issues. Finally, there are two uses of "typically" in the language. Both strike me as weasely-problematic. When should a CU not be involved? When should admins not place a notice at AN?
  • Second, problems other than language. If the community decides to unban a sockmaster who was CU-blocked, at least one CU has to consent, and the community cannot "force" consent. Also, many cases are created where the master is stale from the outset. That means the puppets can never be connected technically to the master. How would that work with the CU requirement?--Bbb23 (talk) 15:20, 28 February 2018 (UTC)
  • A CU does not have to consent. A CU needs to be consulted to provide evidence that the blocked user has abided by WP:SO or whatever terms the community feels should have been met to qualify for being unblocked. Checkusers, like admins and ALL other users with advanced permissions, are servants of the community and do not hold power over the community. They have extra tools so they can be useful, they do not hold extra powers so they can override community decisions. --Jayron32 15:25, 28 February 2018 (UTC)
  • The community would first have to change policy. See WP:CUBL. Right now, the community cannot unblock a CU-blocked account without CU permission. Otherwise, all CU blocks would be subject to review by the community. Besides contravening policy, it also alters fairly long-standing practice. I have of course seen on a few occasions the community give advice, particularly in the case of WP:SO.--Bbb23 (talk) 16:10, 28 February 2018 (UTC)
  • Nope. That policy does not say that the community cannot override a checkuser. That policy says that a single administrator acting alone should not undo a checkuser block without first consulting with that checkuser. Nowhere does that policy grant checkusers the superpowers you say that it does. It also does not say that checkusers must consent to the unblock, merely that they are consulted. We do this all the time with WP:SO discussions. I can bring up a hundred such discussions at AN, where a blocked user requests an unblock claiming they have been good, someone pings a checkuser, the checkuser gives their input based on their CU tool, and then the community discusses unblocking. They don't need permission or consent to unblock. Just information the checkuser is able to give them. Again, you have stated something which is neither backed up by written policy or practice. If YOU want to give checkusers more power than the rest of the community, YOU'LL have to change that policy. Because that policy at once both confirms what I said, AND contradicts your assertion that the community is somehow beholden to the whims of a checkuser when they make decisions. --Jayron32 18:28, 28 February 2018 (UTC)
  • Bbb23, these are very good questions, and I'll try to answer them: Re: publicly documented CheckUser evidence, that just means that it has to be on-wiki and stated that the master is confirmed (or very likely). Admins should not go around putting banned templates on users just because they see a CU block template in a block log. Re: your unblocking concerns, nothing here would give the community the ability to undo a CU block. The language would require that someone who has block evaded twice and is seeking a SO go through community review after a CU has consented to an unblock.
    The most practical impact here outside of CU blocks would be for users that CU has confirmed or has come back as very {{likely}} for but the CU has not blocked and requested behavioral evaluation: these would not be CU blocks.
    The typically language re: AN would be for DENY situations, similar to tagging. I also anticipate that For cases such as mass use of throwaway accounts or the copyvio socks with less than 100 edits we frequently get there wouldn't be a community demand for it. What the language is intended to do is provide oversight of the process and allow comment if an admin has applied the policy wrong in situations where an unblock/unban is likely to be potentially controversial: users who have good faith somewhat significant contributions, are likely to make an unblock request, and where the community would like to be consulted before an unblock is made. This would also impact users who are indefinitely blocked before hand, are confirmed to be socking, but the indef is not converted to a CU block (different CUs have different practice on reblocking in these cases).
    In terms of the typically in front of CU evidence, the only situations I could think of would be ones like DisuseKid, where the master was stale, but they eventually admitted it and we had CU evidence to tie his other socking together. I think I answered all of your questions there, sorry if I missed any. TonyBallioni (talk) 16:36, 28 February 2018 (UTC)
  • Tony, thanks very much for your responses. The only two concerns I have left are probably in the minor category. First, it sounds like even if there are a bunch of accounts that are CU-blocked for socking and tagged, if there's no SPI, there's no "banning". Sounds a bit inconsistent with the intent of the policy change. Second, although your clarifications are great, it would be better to make changes to the wording so there's no ambiguity. At the same time, maybe it's only me being too picky, and I do understand that any substantive changes to the wording are problematic in terms of the previous voting, which has been going on for a while. As for wordsmithing tweaks, I think Green Giant's below are excellent.--Bbb23 (talk) 18:10, 28 February 2018 (UTC)
  • @TonyBallioni: read my comment above. I had also raised the issues with this proposal. I had also mentioned that there are banned editors who are using IP address for sock puppetry and CU won't help you there. This proposal can potentially encourage meat puppetry as well. I think you need to modify your proposal and just ping all involved editors after you have modified it. I am sure they will support it. Sock puppetry violations must fall under violation of WP:SOCK, not heavily depending on the circumstance that is "confirmed" abuse by CU. D4iNa4 (talk) 18:13, 28 February 2018 (UTC)
  • @Bbb23:I agree with your points, and think that they could probably be addressed with a footnote as to what publicly documented means (I would consider a CU tagging a master as confirmed ad public documentation as it is on-wiki, and was actually thinking of when I had seen you confirming masters in unblock declines when I used that wording. The point is to prevent admins from playing guessing games or tagging solely based on behavioral evidence)/ Same goes for wordsmithing and minor tweaks for clarity: that normally happens after a major policy RfC close to take into account the feedback from the discussion. As I mentioned to BMK above, I shopped this around to a lot of people to get a consensus version, and things written by committee tend to have clunky wording. I appreciate your feedback on this a lot.
    @D4iNa4: the point of this proposal isn't to document every type of user we want banned or even to necessarily discourage sockpuppetry. The people who it applies to are likely going to sock anyway. The purpose here is to clarify a current ambiguity in the unblock policy and to cut down on the pointless AN ban discussions for LTAs that have become a trend of late. I think the wording works fine for that, and the tweaks that we are talking about are pretty minor and can be worked out in practice. I don't see a need to change and reping everyone at this point. TonyBallioni (talk) 19:02, 28 February 2018 (UTC)
  • @TonyBallioni: Sounds right to me. Thanks for your patience!--Bbb23 (talk) 19:09, 28 February 2018 (UTC)
  • Support but I would suggest tweaks of the wording (underlined and struck out solely for highlighting the changes):
Users who have been found to have engaged in sockpuppetry on at least two occasions after an initial indefinite block, for any reason, are considered effectively banned by the Wikipedia community. Publicly documented CheckUser evidence should typically be involved before a user is considered banned in this way. Users fitting this criteria are subject to the same unban conditions as users banned by community discussion.
Administrators should normally place a notice at the Wikipedia:Administrators' Noticeboard alerting the community of such a ban, as well as place Template:Banned user on the master's user page, and add the user to any relevant Arbitration Committee sanctions enforcement list.
Green Giant (talk) 17:15, 28 February 2018 (UTC)
  • Support - Way back when I first started editing, this was standard practice. For repeat sockmasters with few if any positive contributions, you didn't need a formal ban discussion; you could just add a "banned user" template to their user page and be done with it. Sometimes the formalities are a waste of time. Kurtis (talk) 18:25, 28 February 2018 (UTC)
  • Oppose. Looking above I know I'm probably swimming against the tide here.. I share some concerns about the wooly nature of the language being proposed ("found ... after an initial indefinite block...", "...CheckUser evidence..."). I am concerned that this imposes bureaucratic obligations on admins ("Administrators should typically place..."). However I am also concerned by the additional bureaucracy that a blocked user must be paraded in front of an admin noticeboard, before unblocking, where they will typically be condemned to wait "two years" or similar by a permanently angry mob. I prefer the previous situation that Jayron32, Kurtis and others mention above, that a user is banned unless an admin is willing to lift the block. Sometimes admins acting almost unilaterally, using their good judgment in line with policy, is a good thing. I have no problem with getting rid of the banning requests posted to admin noticeboards, but requiring discussions on the admin noticeboards either at the time the block or in order to unblock is not an improvement, IMO. -- zzuuzz (talk) 18:57, 28 February 2018 (UTC)
  • Pile on support. At the moment editors can go on socking until they lose enough patience of editors that we finally (after 20+ socks or so) get a rather useless formal AN banning discussion. If you want to return to editing, get your main account unblocked before we get this far. --Dirk Beetstra T C 08:30, 1 March 2018 (UTC)
  • Support the first paragraph per WP:DENY, not so much the bureaucracy creep in the second. Bishonen | talk 10:06, 1 March 2018 (UTC).
  • Support. -- Iazyges Consermonor Opus meum 03:28, 2 March 2018 (UTC)
  • (Summoned by bot) Support. Makes perfect sense. Bellezzasolo Discuss 11:14, 2 March 2018 (UTC)
  • Support: CU indefinitely block and/or even global lock is already banned for them, it is ridiculous and waste of time to give them the AN/ANI threads attention on the discussions, for unban as per WP:SO need to via their talk page and AN/ANI threads on the discussions, as IMO. SA 13 Bro (talk) 11:44, 2 March 2018 (UTC)
  • Support the principle. The wording is a little ambiguous here and there and I'll post a Q about this below. Ben MacDui 18:55, 2 March 2018 (UTC)
  • Support mainly for the WP:DENY factor. A discussion at a drama board for such cases is unlikely to be helpful, and the issue should be dealt with in a cool and semi-automated fashion. Johnuniq (talk) 21:56, 2 March 2018 (UTC)
  • Support This is a good idea: it will turn the longstanding convention of such editors essentially being de-facto banned into a more formal ban. Nick-D (talk) 22:04, 2 March 2018 (UTC)
  • 'Support Seems sensible, and not WP:CREEP when it merely strengthens existing practice. Hawkeye7 (discuss) 23:59, 2 March 2018 (UTC)
  • Support. Of course. - CorbieV 19:57, 3 March 2018 (UTC)
  • Oppose Users like Slowking4 who have only evaded their block on good faith should not be considered "banned", and a block is a preventative measure, if an evading editor doesn't repeat the behaviour that lead to the block this is a punitive measure that doesn't help improve the encyclopedia. This entire proposal is punitive and only serves as instruction creep. --Donald Trung (No fake news (Articles Respect mobile users. 00:18, 6 March 2018 (UTC)
    • It is impossible to block evade in good faith, as this is explicitly against one of the strongest community consensuses, and ignoring it is essentially saying “Fuck you” to the community. TonyBallioni (talk) 00:34, 6 March 2018 (UTC)

RfC discussion

  • Question "The terms of the proposal would make it so that after three indefinite blocks, a user is considered de facto banned under the banning policy" - this applies only to sockmasters yes? If an editor had three indefs for other reasons, they would not fall foul of this, would they? Mjroots (talk) 21:16, 20 February 2018 (UTC)
    • Mjroots: No, they would not. That was my simplifying the wording to surmise the impact it would have re: socking and block evasion, not part of the actual proposal (which is in green). The simpler and more precise way of putting it would be: any user who socks twice after being indefinitely blocked is de facto banned. Thanks for the question. TonyBallioni (talk) 21:20, 20 February 2018 (UTC)
  • Question I'd tend to support, but why there should be two occasions after an indef block? Wouldn't it be enough with just one? Sockmasters are warned about their behaviour, especially after a CU.--Jetstreamer Talk 23:10, 20 February 2018 (UTC)
    • Jetstreamer, well for one, I don't think we could get consensus for de facto ban on the first occurrence of socking for block evasion, and so I wrote the proposal for what I thought would pass, but on top of that, we recognize that users fuck up. There are users like DrStrauss, who got CU blocked, and then tried to clean start, and got blocked again. He made a mistake, and I know for a fact that there are many admins and functionaries, and likely some ArbCom members who would probably be willing to unblock him after a CU gave the all clear without needing the whole ceremony of an AN appeal (and I say this as the editor who filed the SPI on him), and if you opened up a ban conversation on him now, it would likely fail at AN.
      Nothing in the proposal prohibits admins for taking blocks to AN for review, nor does it prohibit users from asking for a ban at AN if there circumstances that would warrant it before two occasions of using socks to block evade. It just sets a clear criteria for when the conversation isn't needed. TonyBallioni (talk) 00:08, 21 February 2018 (UTC)
    • Furthermore, in some cases users forget to log on and get blocked because it is believe they are socking. It's bit harsh to drop the banhammer in that case. Others may lose their password and create a new one account but neglect to create the link between the two. Various permutations on these sorts of things will happen, especially to new users. The proposal allows for some level of AGF. Blackmane (talk) 03:48, 22 February 2018 (UTC)
  • Comment - while I support the merits of this proposal, I do believe that where it says "... to have engaged in sockpuppetry ...", sockpuppetry should be piped from Wikipedia:Sock puppetry#Inappropriate uses of alternative accounts as: "sockpuppetry", to remove any confusion as to whether or not Wikipedia:Sock puppetry#Legitimate uses are meant to be part of the cumulative threshold for banning; perhaps they are?--John Cline (talk) 06:09, 21 February 2018 (UTC)
    Can you come up with a single legitimate reason to use a sockpuppet to dodge a valid block? --Jayron32 13:39, 21 February 2018 (UTC)
    By definition, if you use a 2nd account for legitimate reasons, it isn't a sock puppet, it is an alternative account. The term sock puppet is only used (or should only be used) when describing the use of an alternative account for abusive purposes. No further explanation should be needed. Dennis Brown - 13:42, 21 February 2018 (UTC)
    yep, that is what i was going to say. nonissue. Jytdog (talk) 16:54, 21 February 2018 (UTC)
    No Jayron32, I can not. Was there something in my comment that led you to ask such a question? Dennis Brown If the term sock puppet should only be used to describe the use of an alternative account for abusive purposes, why does our policy on sock puppetry have an entire section on legitimate uses? I merely suggested, in light of the policy oxymoron, that the raw term has the potential of being confused whereas piping the term, as described, allayed that potential at the cost of added clarity. If it's a nonissue, it's a nonissue raised in good faith. I'll rest on that.--John Cline (talk) 18:16, 21 February 2018 (UTC)
    Yes, John. In a discussion about people using a second account to dodge a block on a first account, you brought up the point that are legitimate uses of second accounts. I was questioning the relevance of your point, since I have not, in 12ish years at Wikipedia, ever seen a situation where a person who was blocked on a first account ever had a legitimate excuse for then using a second account. So, I get that there ARE legitimate uses of second accounts. None of them are relevent to this discussion, which involves someone first being blocked, THEN using a second account, THEN being blocked again for that and THEN using yet ANOTHER account. I was struggling to understand a scenario where that qualified as, "any confusion" over "legitimate uses". --Jayron32 18:27, 21 February 2018 (UTC)
    Thank you Jayron32. I understand your dismay in the context described. I disagree, however, that such context ought be intuitively gleaned from the proposal as written. Found to have engaged in sockpuppetry on at least two occasions after an initial indefinite block does not unequivocally mean the engagement in sockpuppetry occurred while the indefinite block was active. It could as easily mean sockpuppetry that commenced after the initial indefinite block had been successfully appealed; I would argue that the ban provision is best served by allowing for both eventualities, as it is written. I assure you that if the proposal had said: found to have engaged in sockpuppetry on at least two occasions, circumventing an active block (or something similar) I'd not have commented as I did. Cheers.--John Cline (talk) 20:40, 21 February 2018 (UTC)
    Actually it seems to me John Cline has hit on an important point here. Isn't this policy only intended to cover editors who sock while indefed blocked? I mean if someone gets indefed and then is unblocked, and then later, perhaps much later, is socks twice for reasons unrelated to ban evasion is this policy intended to cover that? As worded it seems it does but I'm not sure if that's the intention. After all it excludes people who sock twice but have never been indefed. Nil Einne (talk) 00:00, 22 February 2018 (UTC)
    If someone block evades twice involving CU data, it is highly unlikely they will not be indef'd. This doesn't cover people who haven't been indef'd, as well, they aren't indef'd, so it makes no sense to go to unblocked to banned immediately. This is focused on block evasion after an indefinite block. TonyBallioni (talk) 00:08, 22 February 2018 (UTC)
    To follow on, Jayron32's reply also asserts, if I may paraphrase, that this proposal intends only to weigh on indefinitely blocked sockmasters who are subsequently indefed again for socking anew to evade their initial block, and then found evading sanctions once again from yet another sock still. While I believe this is the requisite criteria intended for triggering a ban under this proposal, you can not expect ambiguous verbiage like editors who have been found to have engaged in sockpuppetry on at least two occasions after an initial indefinite block to adequately convey that premise.
    Unless you expect users downstream to refer to this discussion for understanding, IIMO that the proposal's text ought to be reworked to reduce confusion and improve clarity. "At least two occasions" does not exclusively mean "two unique sock accounts", one account can certainly be found to have engaged in sockpuppetry on two distinct occasions and nothing currently written suggests the occasions (or sock accounts) must emerge sequentially, as given in Jayron's reply, with the first sock evading and being blocked before the second sock publishes its first evasive edit. Thank you all for considering my regards, or for ignoring them with civility and kind manners. I am beholden either way. Cheers.--John Cline (talk) 20:41, 22 February 2018 (UTC)

    @TonyBallioni: But that's precisely my point. The proposal may intend to cover only those situations, but it doesn't as worded. An indef as we all know (or should know), does not have to be permanent.

    For example, as worded if an editor is indefed, perhaps due to WP:competence as a 13 year old who shows behaviours not atypical of 13 year olds, and then 4 years later makes a standard offer request and is unblocked. And then 5 years later, with a clean block log since the standard offer, gets angry over something and gets blocked, foolishly socks in a very obvious fashion a single time and then stops and after their (we can presume extended) block expired comes back. And after another clean 8 year history they get angry and get blocked again and again foolishly sock again in an obvious fashion, they are basically community banned per this proposal.

    However there is a strong chance this user hasn't been indefed in 13 years (half their lives) in such a situation. So they're community banned without an indef block during the socking. And despite the fact they've actually been in good standing for a substantial portion of their editing history (or their lives). And their socking was 8 years apart, with nearly all of that time the user being in good standing. Our only saving grace here is that the proposal does say that CU evidence is normally needed and I imagine CUs will often not bother with either socking but that seems unnecessarily complicated. (Especially since you don't really have to change the story that much so that CUs may have been involved.)

    The proposal doesn't say the indef block has to be concurrent to the socking. Or that it has to be active. It just says the editor has to have been indefed before the socking. Even if we exclude cases where the indef is considered unjustified, I don't see how it's clear from the proposal that it excludes cases where the editor was rightfully indefed before, but is no longer indefed when the socking occurs.

    An indef block doesn't magically disappear when the block is removed. They indef block may no longer be active, but I'm fairly sure most people would agree that the editor was indefinitely blocked. (To give another example, if editor A is running for admin or whatever and another editor asks about their previous indef block and editor A says they were never indefed because they were unblocked after 4 years, editor A's RFA is liable to crash and burn.) I mean they don't have to have even been blocked during either socking incident. The only reason I included blocks in my example was because socking (i.e. abusively using multiple accounts) while not blocked tends to be worse.

    Nil Einne (talk) 12:48, 28 February 2018 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────I think we have to rely on admins who are dealing with SPI and unblock requests having common sense. The natural understanding would be that the indefinite block on the master account needs to still be active. TonyBallioni (talk) 13:43, 28 February 2018 (UTC)

It's not common sense that you're speaking of, it's specialized experience and knowledge. Or perhaps I haven't got a lick of common sense because I frankly can not comprehend the angst over saying what you mean. Why in the wiki-world would you prefer saying "on at least two occasions" if in fact you mean from at least two additional socks? Because the beautiful people will understand; really? I apologize for being a bit comely, and do regret commenting as I did. I should have just jumped on the bandwagon, and come across like I had common sense too. You won't read another stupid comment from me. Cheers.--John Cline (talk) 15:07, 28 February 2018 (UTC)
There was no intention of calling anyone stupid, it's just that most admins who handle unblock requests aren't going view it in a hyperliteral way. The reason for the choice of wording was because this isn't sock three times, it's indef+two occurrences block evasion. The first block does not need to be for socking, and the wording of two additional socks is problematic as it relies on the number of accounts, not the instances of it happening. TonyBallioni (talk) 19:05, 28 February 2018 (UTC)
And at the very top of that section, it points to the two main Categories for legitimate alternate accounts, and goes on to say why it ISN'T sock puppetry to use accounts for the following reasons, ie: "These accounts are not considered sockpuppets." (emphasis mine) So it couldn't be more plain. It is logical to explain what is (top section) and what isn't (bottom section) in the same article, since people throw the term "sock puppet" around. I go into greater detail in the essay Wikipedia:Dealing with sock puppets, which I started after working at SPI for a year. To call multiple accounts "socking" requires a showing of ABUSE. Dennis Brown - 18:23, 21 February 2018 (UTC)
Thank you Dennis Brown. I acquiesce to your expertise in this regard. Cheers.--John Cline (talk) 20:40, 21 February 2018 (UTC)
  • Question: What do we mean by "CheckUser evidence should typically be involved"? Is it enough if it is involved at one stage in the process (in which case the ban could be enacted for a final infringment without CU involvement) or does it mean that CU evidence must be involved for every accusation of sockpuppetry? Or what? Apologies if this is dealt with somewhere above. Ben MacDui 18:55, 2 March 2018 (UTC)
    • @Ben MacDui:: this was brought up during the brainstorming. It is worded this way because SPIs don't always involve CU data every time. A frequent pattern is "Behavioral case #1, behavioral case #2, CU case on #3 to check for sleepers and an underlying range", where a CU may tie new socks to the ones in the original reports. I get a lot of the ambiguity concerns, but part of the reason for that is to try to allow admins and CUs a small bit of flexibility here in cases where WikiLawyering is going to be likely if there is ever an unblock appeal. TonyBallioni (talk) 00:38, 3 March 2018 (UTC)
      • @TonyBallioni: Thanks for your reply. I am aware that SPIs don't always involve CU data and what I am concerned about here is not so much wikilawyering by the mad and bad as the potential impact on an SPI behavioural investigation. Let's say an editor is indef blocked for non-socking behaviour some years ago. They return and are caught out by CU for some naughty but fairly minor socking infringment. Time passes, they make productive contributions and then are accused of having socked again but the clerks can't offer CU because one or other of the accounts is stale. Behavioural cases are sometimes not at all clear cut so I am assuming a possible advantage of the vague language is that if an admin finds this additional socking proven that they are at liberty to block, but not ban the editor on the grounds that "Administrators should typically place a notice..." does not mean that "Administrators are instructed to place a notice..." and that leeway exists in cases where the balance of the editors contributions might weigh against the likelihood but not certainty of socking abuse. (I can offer you an example of something like the above if you wish.) If this flexibility is intended then I am fully supportive. Ben MacDui 12:51, 3 March 2018 (UTC)
      • @TonyBallioni: I get the impression from the comment below by Dirk Beetstra that such flexibility is intended. On the other hand, if it isn't, I'd appreciate a reply. Ben MacDui 19:14, 7 March 2018 (UTC)
        • Sorry I missed this. Yes, flexibility is intended. We don't always need bureaucracy and while the clarity here is good for unambiguous cases, the principles in the banning policy that already exist In the event an indefinitely blocked editor has continued to be disruptive and no administrator is willing to unblock, they are considered de facto banned, this proposal, and IAR show cases where an administrator could use their judgement to determine that the conditions are met. I expect in these cases, if it is an established user, the notification at AN would be important for review. I hope that makes sense. TonyBallioni (talk) 19:18, 7 March 2018 (UTC)
  • Question: What do we mean by "Publicly documented CheckUser evidence"? Doesn't WP:CHECKUSER say even if the user is committing abuse, personal information should if possible not be revealed? Hawkeye7 (discuss) 23:59, 2 March 2018 (UTC)
    • @Hawkeye7:: see my response to Bbb23 above. There was concern by some that this could lead to people going around banning users just by seeing a CU block and without the evidence presented on-wiki. Basically, a CheckUser should make a public connection between, via an SPI, by tagging a page, or confirming on a user talk or other public forum. It was worded as "publicly documented" to allow for it to include cases outside of SPIs (CUs will often comment at AN or on user talks if pinged for a block review). As I said to Bbb23, I think this can be handled via a footnote. TonyBallioni (talk) 00:38, 3 March 2018 (UTC)
  • Early Close? I think we are getting pretty close to the point where this could be closed w/o controversy given the extremely lopsided consensus and the fact that it has been open for over a week. I'm involved so I'm not going to do it, but I honestly see no realistic likelihood of a dramatic shift in consensus. -Ad Orientem (talk) 01:08, 4 March 2018 (UTC)

Question/test case

I would rather this stay open because I have some questions, specifically about needing CU results. For an example, see Category:Wikipedia sockpuppets of Masoom.bilal73. This sockpupeteer is extremely obvious. In short, they suck at block evasion, every one of these is a  It sounds like a duck quacking into a megaphone to me situation. That being the case, I’ve never bothered to CU them. So, they wouldn’t be banned even thought they’ve been blocked about 15 times under as many identities? Beeblebrox (talk) 21:46, 6 March 2018 (UTC)

  • They wouldn't be impacted by this, but briefly going over their unblock requests, I also find it very unlikely that any admin would ever consider unblocking or even taking an unblock request to AN as I haven't seen a half serious unblock request from them once. This isn't meant to outline every situation where someone should be banned, just a narrow set of circumstances where the community has decided that a ban conversation is not necessary. Dennis Brown was the one who proposed the CU requirement if I recall correctly, and it was meant to make this conservative so we don't have good faith editors subject to unban requests based solely on one admin's behavioral judgement call.
    Consider the scenario of an indef'd user who does not block evade, but has two socks blocked solely on behavioral evidence: this could reasonably be addressed in an on-wiki unblock or UTRS appeal without the need to go to AN, especially if there was evidence against socking that UTRS would be better to handle than AN. The CU part is a bit of a safety net in those cases. Reasonably where this makes the most practical difference (other than cutting down on the AN discussions) is for the users who have been blocked with a mix of good and disruptive contributions, and continue to block evade. This would require an unblock discussion in addition to consulting with a CU, which is already common practice, but just formalizing that. TonyBallioni (talk) 22:17, 6 March 2018 (UTC)
I should have explicitly mentioned this as well: to be clear, I am definently in favor of the overall concept and the idea behind it, ending unecessary ban discussions. I’m just not wholly convinced that CU needs to be involved every time. Beeblebrox (talk) 00:45, 7 March 2018 (UTC)
Yeah, I get that, and it's something I struggled with when drafting and taking feedback into account. Like I said to Bbb23 above, I think there are some cases like DisuseKid or others where we don't necessarily need a CU on the original master, and this is why the wording is a bit fuzzy (and requires posting to AN for review). I was trying for a step forward that could get very broad consensus rather than a controversial but might pass proposal. I agree there could be tweaks as we get more experience with it, but think this is a step in the right direction. TonyBallioni (talk) 00:51, 7 March 2018 (UTC)
And I would argue that is the function of the word 'typical' in the description. I would say that if we would bring this editor to AN for a CBAN discussion, the !vote would likely be just as anonymous as for any other where there is proper technical evidence to link the editors (and CUs sometimes don't have technical evidence, but go for the same duck-test), and that we would want to avoid said AN discussion. I don't think that we should hook the proposal too strict to checkuser evidence. I would consider that any editor who gets an indef block, and then evidently socks two times in evasion of their initial block are plainly CBANned. I would however imagine that on weaker ducks the number of socks would possibly increase, to the discretion of the tagging admin. --Dirk Beetstra T C 09:48, 7 March 2018 (UTC)

The above discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

RfC: Coverage of mass shootings in firearms articles

Should articles about firearms include information about mass shootings?–dlthewave 17:11, 21 February 2018 (UTC)


After several recent mass shooting events, edit warring has taken place over whether or not an article about a specific firearm model should cover the weapon's use in mass shootings. This has been centered around various AR-15 style rifles, but the argument could apply to any firearm used to commit a crime.

There is also disagreement over whether or not AR-15 style rifle should include information about the category's prevalence in mass shootings, which has received significant RS coverage.

Relevant WikiProject Firearms essay

"In order for a criminal use to be notable enough for inclusion in the article on the gun used, it must meet some criteria. For instance, legislation being passed as a result of the gun's usage (ex. ban on mail-order of firearms after use of the Carcano in JFK's assassination would qualify). Similarly, if its notoriety greatly increased (ex. the Intratec TEC-DC9 became infamous as a direct result of Columbine). As per WP:UNDUE, "Neutrality requires that each article or other page in the mainspace fairly represent all significant viewpoints that have been published by reliable sources, in proportion to the prominence of each viewpoint in the published, reliable sources.". Therefore, the addition of said information should be limited to a simple link in the "See also" section."

Relevant talk page discussions

The first three discussions were consolidated to Wikipedia talk:WikiProject Firearms#Use of AR-15 Style Rifles in Mass Shootings. The centralized discussion has developed significant support for an RfC outside of WikiProject Firearms.


Editors should be aware that there is some confusion surrounding the AR-15 name. "AR-15" is a trademark of Colt and technically only applies to the Colt AR-15. However, many manufacturers produce their own generic versions based on the same design, and these are often referred to as "AR-15" by the media and general public. Within Wikipedia, AR-15 style rifle covers the general category of weapons that use the AR-15 design. The article was recently moved from Modern sporting rifle and the two terms are used somewhat interchangeably. Efforts to reduce this confusion is outside the scope of this RfC.

Survey Questions

Two questions, pick one answer for each:

  • 1. Should an article about a specific firearm model include information about its use in mass shootings?
    • A. Do not include
    • B. Include links to notable shootings in the "See Also" section (Current WikiProject Firearms essay)
    • C. Include a paragraph-style section
    • D. Evaluate how much to include on a case-by-case basis
  • 2. Should AR-15 style rifle include information about the category's prevalence in mass shootings?
    • A. Do not include
    • B. Include only statistical data
    • C. Include a paragraph-style section
    • D. Discuss at Talk:AR-15 style rifle Option added 27 Feb 18

Straw-poll: Coverage of mass shootings in firearms articles

  • Situational: 1. C | 2. C - In the case of the AR-15, I am convinced that a neutral paragraph can be forged. These paragraphs should only be added if the school shooting in question has had an impact on the gun, or new regulations have been put forward as a result. - Knowledgekid87 (talk) 17:19, 21 February 2018 (UTC)
  • Oppose. The current guidelines are sufficient. If a particular instance changes it, then we decide then. For example, the Douglas High shooting may, in fact, lead to legislative changes that result in the use being particularly notable. Currently, it has not. So the rush to make this change is premature. Slow down. Many editors I see trying to put this everywhere (dare I say spam it) seem to be more driven by something other than a desire for accuracy. And whether or not well-intentioned people incorrectly use the term AR15, using a Ruger AR-556 doesn't belong in the article about the Colt AR15. Niteshift36 (talk) 17:27, 21 February 2018 (UTC)
  • Depends (1D and 2C). More specifically:
    Please ping me if anyone has any questions about my comments here; I won't be watching this discussion. ansh666 18:10, 21 February 2018 (UTC)
    (Changed 1C to 1D, since we're using that now. ansh666 03:14, 23 February 2018 (UTC))
  • 1C if indeed that coverage is there. (Impugning others' motives, not a good thing.) If someone holds up a bank with a gun of a certain type, or shoots their neighbor with it in some dispute, that's never going to deliver the coverage necessary: that coverage needs to specifically address the weapon, and political discussion about the weapon will help--et cetera. This is nothing new.2C but duh, we're going to need a bigger paragraph. And, as I indicated below, the Colt AR-15 article should already include a brief summary of what weapons based on it have been used for. Drmies (talk) 18:21, 21 February 2018 (UTC)
  • 1C/2C Assuming that sufficient reliable sources exist to craft NPOV text then Wikipedia needs to address the issues brought up by the sources. I would not consider lots of articles consisting of mere mentions that a given weapon/class of weapons were used to be 'sufficient' in this context. - Mere mentions in sources are sufficient for mentioning and linking the weapon/type from the event article but we should avoid back linking that would result in "this weapon was used in list of events" sections. Jbh Talk 18:31, 21 February 2018 (UTC)
    I guess this is the same as the 'D' options that are being discussed. What I am against is any wiki-project guideline that relegates reference to criminal acts to a 'See also' if there are sufficient, detailed sources to support more. I also am opposed to laundry lists of crimes being placed in the articles. In other words - follow the sources per Wikipedia's content policies, not per some wiki-project local consensus. Jbh Talk 15:04, 28 February 2018 (UTC)
  • 1 = A...2 = A Oppose addition of crime and mass shooting content --RAF910 (talk) 18:36, 21 February 2018 (UTC)
    Its no secret that guns are used in crimes and mass shootings though. If for example an AR-15 is modified due to an event then it would be notable enough for inclusion as an effect on how the gun is used going forward. - Knowledgekid87 (talk) 18:40, 21 February 2018 (UTC)
    Yes..."Its no secret that guns are used in crimes and mass shootings though." In fact it's such common knowledge that there is absolutely no reason to even mention it in these articles. Like knives, we all know that they are used in crimes. In fact, world wide knives are the weapon of choice for criminals and killers, but we don't mention it in every knife article, do we.--RAF910 (talk) 19:32, 21 February 2018 (UTC)
    If a type of knife is modified or banned as a result of a deadly event then yes of course we would mention it per WP:N. - Knowledgekid87 (talk) 21:59, 21 February 2018 (UTC)
    OK, since were going down the rabbit hole anyway...I recommend that this policy be applied to all knife, weapons, vehicle, aircraft, anaimal and anything else that could possibly be used to commit crimes and kill people pages. We can call it "WP:Murder, Death, Kill". for short--RAF910 (talk) 22:14, 21 February 2018 (UTC)
    We already do that... under aircraft types we have accidents and notable incidents, under car types we have recall mentions. The point is when people are killed and the killing device is changed to make improvements then it is noted. - Knowledgekid87 (talk) 23:39, 21 February 2018 (UTC)
  • 1A 1D - 2B 2D - But it all depends, if a shooting took place and the specific model of AR used is important it should be mentioned on that models page. If it is general that an AR was used but the model is not mentioned or notable it should be on the AR-15 style rifle article. More specifically for individual models eg. Colt AR-15 and the like information should only be included if it lead to legislation or similar. An example would be Port Arthur massacre (Australia) where the Colt AR-15 was used and kicked off the legislation to ban guns. PackMecEng (talk) 18:49, 21 February 2018 (UTC) Updated vote to 1D & 2D after discussions PackMecEng (talk) 16:37, 14 March 2018 (UTC)
  • 1C iff the sources warrant it for the specific model, otherwise 1B, or at least a link the use of AR-15 style rifles in mass shootings (rather than individual shootings). 2C should most definitely be done. Headbomb {t · c · p · b} 18:52, 21 February 2018 (UTC)
  • 1C and 2C. Especially 2C. The amount of coverage that the AR-15 has gotten in relation to mass shootings (whether rightly or wrongly) is way too extensive to ignore. It'd actually be a WP:NPOV and WP:DUE violation NOT to include it.Volunteer Marek (talk) 18:56, 21 February 2018 (UTC)
  • Oppose - any changes to the current policy (noted as "1B". This !vote is not based in any political ideology, (not "anti-gun" or "pro-gun") but simply the projects guidelines, such as WP:NPOV. If we start adding "paragraph-sized entries" to the articles of any firearm, or firearm type, brand or maker involved, these articles will quickly fill up with huge "mass-shooting and other related incidents" (or "Controversy") sections that will outweigh the remainder of the entire article. I'm not seeking to suppress this info in any way. These mass-shootings and other types of firearms-related incidents almost always have their own articles here already. Lengthy, detailed articles that always include extensive information about the firearm(s) used and links to the related pages of the firearm, it's type, brand and/or manufacturer. That is sufficient. (most of this I've already posted elsewhere, but I will add; there is nothing stopping anyone here from writing an article about "the use of "AR-15 style rifles" in mass-shootings", and linking it to every related article; mass-shootings and other related incidents, and articles about the firearms, related firearm types, brands and makers, etc. Just a thought. - theWOLFchild 19:13, 21 February 2018 (UTC)
  • 1A, 2A (usually) These events are not related to the specific gun models. If an event impact sales, regulation of the specific gun model, or variant gun design (as in TEC9) - then that would ge a reason to cover it in the model. We do not usually document individual use cases in weapon articles - it would become an unmanageable list for some.Icewhiz (talk) 19:29, 21 February 2018 (UTC)
  • Oppose as existing guidelines are sufficient, and this should be decided on the article talk page. We can't foresee every possibility, so to set a hard policy or guideline that dictates the content of an article is wrong minded. This is an issue of CONTENT, and guidelines shouldn't be getting this specific on what to include. That is what editors are for. Dennis Brown - 19:59, 21 February 2018 (UTC)
  • Oppose. Existing guidelines (1B) are sufficient. What will be notable a year from now is hardly discernible today. See: WP:CrystalBall. Meanwhile, we should not conflate all firearms. Besides, a decade ago, every rifle used criminally was an AK47. Even if it wasn't. Now, every rifle used criminally is an AR-15, even if it isn't. The Firearms Project guidelines are sufficient. And, when something becomes notable, then more than a mention becomes important. Miguel Escopeta (talk) 21:27, 21 February 2018 (UTC)
  • 1-D This seems like an obvious case-by-case basis and any hard rules are just going to create poor articles. Let the editors decide through talk page consensus whether it needs to be mentioned and how much to mention. As an aside the current guideline (1-B) is the worst option. See alsos should not be used to shoehorn links into articles. AIRcorn (talk) 21:54, 21 February 2018 (UTC)
  • Generally opposed to making sweeping editorial decisions on an untold (and many as yet unwritten surely) number of articles. This should probably be decided on a case-by-case basis. GMGtalk 21:58, 21 February 2018 (UTC)
  • Oppose. Existing guidelines are sufficient. Regards, TransporterMan (TALK) 22:47, 21 February 2018 (UTC) Clarify: General policies and guidelines, i.e. those unrelated to this specific topic area, are sufficient. - TransporterMan (TALK) 02:01, 22 February 2018 (UTC)
  • Comment Currently, these decisions are not being made on a case-by-case basis. When attempts are made to add mass shooting information to an article, the WikiProject Firearms guideline essay is often cited as a "policy" that prohibits anything beyond a "See also" link. –dlthewave 23:11, 21 February 2018 (UTC)
  • The guideline needs to be looked at by the community then, remember that this isn't confined to just the United States in terms of English speaking scope. - Knowledgekid87 (talk) 23:32, 21 February 2018 (UTC)
  • Oppose as I also feel the existing guidelines are sufficient. Springee (talk) 01:06, 22 February 2018 (UTC)
  • 1A, 2A per COATRACK. Please leave your politics on your end of the keyboard. Chris Troutman (talk) 02:06, 22 February 2018 (UTC)
  • Exactly, and how do you reconcile disallowing a particular aspect of a subject irrespective of how much coverage that aspect receives with Wikipedia policy and guidelines. IAR "because politics"? — Rhododendrites talk \\ 06:27, 22 February 2018 (UTC)
  • 1C and 2C according to notability. Articles on firearms such as Carcano Rifle, AR-15, Röhm RG-14, etc. that have been used in significant crimes should WP:DUE-ly contain coverage of those crimes. (How is including a couple sentences about the crime - in an article about a type of weapon that was used in a famous crime - being "political"?????) - LuckyLouie (talk) 04:13, 22 February 2018 (UTC)
  • 1A, 2A. I agree with Chris Troutman. These articles should remain Apolitical.--Limpscash (talk) 05:17, 22 February 2018 (UTC)
  • The beauty of Wikipedia's policies and guidelines is that they are apolitical (actually, it's fraught to say that, so let's say they try to be apolitical). We cover a subject according to how reliable sources cover a subject, without imposing our own opinions (political or not) about what aspects of the subject must be covered or must not be covered. — Rhododendrites talk \\ 06:29, 22 February 2018 (UTC)
  • Oppose (1A/2A) - I am, personally, an extremely strong gun-control advocate, but I don't see where it serves any encyclopedic purpose to list in every firearm article what mass shootings it was used in. However, a specific article about "Mass shootings using X firearm" would be a different matter, and I would support the encyclopedic value of such articles, which would then reasonably be listed in the firearm article's "See also" section. Beyond My Ken (talk) 05:19, 22 February 2018 (UTC)
  • 1C/2C' - After further consideration, changing my vote. Beyond My Ken (talk) 01:31, 14 March 2018 (UTC)
  • 1A under the assumption the individual manufacturer's execution of the generic design did not impart any particular advantage or disadvantage in the event(s) described. & 2C If the rifle truly fits within the definition (given the potential problems of using a prototype designation to describe a forked spectrum of improvements which may not be evident to many writers focusing on casualties rather than causes.) The truly important part of the description would be why executioners have chosen this rifle as opposed to a different method of killing (vehicle ramming attack, fire, poison, pressure-cooker bombs, blades, arrows, clubs, etc.) or a different type of firearm (shotgun, handgun, machinegun, semi-automatic rifle, lever-action rifle, bolt-action rifle, pump-action rifle, mortar, etc.) The paragraph should focus on features (sales volume, distribution of ammunition, ease of concealment, weight, range, accuracy, cartridge energy, bullet design, magazine capacity, reloading method, etc.) making this firearm more effective than other firearms (or merely more available than more effective firearms) and the factors making the targets uniquely vulnerable to attack by firearms, as opposed to alternative killing methods, unless firearms are simply more widely portrayed in the popular press as the preferred method for mass killing. Since an appropriately meaningful description might be interpreted as a how-to article on mass murder, we might better keep the description in the event articles to avoid identifying inappropriate uses of inanimate objects. Thewellman (talk) 07:01, 22 February 2018 (UTC)
  • 1D - ????????????????? How is this not the !vote of every experienced editor in this thread? Coverage of aspects of a subject is based on the weight/prevalence of those aspects in the literature about the subject. Simply because a gun was used in a particular event doesn't mean it should be included. If a great deal of coverage of the subject/gun is about particular ways in which it has been used, that should be included. And everything in between. Both 1A and 1C (and to a lesser extent 1B) are blanket rules that have no connection with the rest of Wikipedia policies and guidelines. We don't ban a particular aspect of a subject when that aspect comprises a major amount of the subject's coverage, and we don't include specific instances of a subject['s use] just because they exist or because it's true. That it was used obviously doesn't need anything more than a mention, if that, but in some cases there's in-depth coverage of the particular weapon used, analysis of a weapon used in multiple attacks, etc. As such 2C is clear in that instance given the incredible amount of sourcing on that aspect of the subject, but that doesn't mean it should be included in all cases. — Rhododendrites talk \\ 06:17, 22 February 2018 (UTC)
  • To be clear, regarding "How is this not..", I see that some have objected to this RfC and/or expressed opinions along the lines of 1D -- I'm just surprised to see so many 1As in general, and 1Cs without heavy qualification (the sort that basically turns it into 1D). — Rhododendrites talk \\ 07:21, 22 February 2018 (UTC)
Because 1D effectively says "this whole debate must be repeated in every mass shooting talk page". This is a poor use of editors' time. Maproom (talk) 07:33, 24 February 2018 (UTC)
This is a debate about a general rule, not a specific instance. Each case needs to take the sourcing into account, and saying exclude vs. link vs. paragraph ahead of time is problematic. That said, to be clear, implied in my 1D is that sometimes it will call for 1C and sometimes it will call for 1A. I'm reading some of the 1C arguments, however, as perhaps operating under the assumption that if 1C is not selected, each individual case will be swarmed by people who don't acknowledge 1C is even a possibility. I don't have enough experience to know if that's true, but based on the fact that anyone at all has voted for 1A for a general rule lends some credibility to that idea. Still, I'm not going to build an assumption of bad faith into my !vote. — Rhododendrites talk \\ 23:49, 28 February 2018 (UTC)
  • Oppose any prescriptive outcome of this RFC. Complete WP:UNDUE consolidation of ill-defined information used in an attempt to draw a conclusion via WP:SYNTHESIS or make some kind of political point. Who decides which incidents get listed? Why stop at the model of rifle... why not go to gun and make a section of all shooting deaths? Do you see the inherent absurdity that this proposal can be extrapolated to? I get that people are in the midst of a bit of hysteria on this topic, but wikipedia is not here to "right great wrongs". We're here to be informative, not influential. -- Netoholic @ 08:17, 22 February 2018 (UTC)
  • 1D I do not see why there must be a general guideline, nor why a project-based essay must be treated as such. Mass killings should be covered in a specific article if they are given significant mention in literature about that topic. That's all. Obviously, for a good many gun types, that means a paragraph; for a good many others, it means nothing at all. Vanamonde (talk) 08:47, 22 February 2018 (UTC)
    • I agree with Vanamonde. There should not be a specific rule at all, it is already covered under existing policy and guidelines such as WP:DUE and WP:RS. This is WP:CREEP, and could create a temptation to WP:BITE. Naturally, people will be curious about a firearm that is used in a mass shooting, and it seems reasonable that they will expect to see some mention in the article. If they don't see it, they might add it. If such an addition is not WP:UNDUE and is well-sourced, there's no reason to remove it. On the other hand, there's no need to impose a formula so that every firearm article has an identical prescribed section on its use in crime. How can we ignore all rules when there are so many of them? Jack N. Stock (talk) 09:07, 22 February 2018 (UTC)
  • Support 1 C - When RS coverage of the weapons used exists, it belongs in the article.E.M.Gregory (talk) 12:48, 22 February 2018 (UTC)
  • Oppose as I really do not see why this is relevant. It may well be verifiable, but seems to me we are making a special case with guns (after all do we do this with makes of knives or swords?). In fact I do not think (as I imply) that I do not see why this is ever relevant to a make of gun.Slatersteven (talk) 16:25, 22 February 2018 (UTC)
  • 1D, 2C this should be determined on a case-by-case basis, depending on the coverage and sourcing for particular weapons and particular incidents. In general, I think if many of the sources about the weapon draw attention to its use in an event then this should push towards including a brief description of the event in the article. On the other hand, if the only sources making the link are descriptions of the event that merely mention the type of gun used, then the event shouldn't be brought up in the gun model's article. In the case of AR-15 style rifles, I think the number of sources specifically about them and their use in mass shootings has probably reached the point where this connection should be mentioned in the article itself. Red Rock Canyon (talk) 16:48, 22 February 2018 (UTC)
  • 1C, 2C The fact that civilian access to AR-15 pattern rifles is politically controversial is just that, a fact. That controversy doesn't wash away when you spin off daughter articles dedicated to specific brands. The Colt AR-15, is clearly an AR-15, it's a progenitor of the design. Yet some are arguing that policy issues around AR-15s generally shouldn't be mentioned in the Colt AR-15 article if the sources never specify a brand. This is not NPOV. Geogene (talk) 17:08, 22 February 2018 (UTC)
  • 1A, 2C (with limited discretion on individual articles) We shouldn't mention that John Wesley Hardin or Billy the Kid used a .44 Colt, we shouldn't mention the Dirty Harry quote on .44 Magnum, and we shouldn't mention mass shooters on page about that specific brand of firearm. For lack of a better term, it's "negative promotion", and we should avoid it the same way we would avoid including normal promotion. I do feel it's absolutely necessary to talk about the general trend on AR-15 style rifle. power~enwiki (π, ν) 17:24, 22 February 2018 (UTC)
  • Unless the incident had relevance to the gun (i.e. legislation, design changes, etc.), it is generally well-intentioned WP:Coatracky to gather individual criminal events in the gun article. According to Gun_violence_in_the_United_States, Approximately 1.4 million people have been killed using firearms in the U.S. between 1968 and 2011. Even if you try to limit it to events with 'major news coverage', it's just a permanently growing craplist. Just because the gun is important to the criminal-event topic doesn't mean the criminal-event is important to the gun topic. Alsee (talk) 22:46, 22 February 2018 (UTC)
  • 1D, 2C. AR-15 style rifle in fact redirects to modern sporting rifle. If the category is broad like that, then discussion of the use of modern sporting rifles in mass shootings is appropriate, as Assault weapon (but not Assault rifle, for good reason) contains political and legal information about the previous ban. The use of AR-15 style rifles in mass shootings is a subject gaining substantial RS coverage and it should be mentioned. For 1, however, I think the decision should be made on a case-by-case basis. For example, Charleston shooting mentions the Glock 41 but the Glock article does not. Carcano mentions the Kennedy assassination and probably always will. Roches (talk) 00:08, 23 February 2018 (UTC)
  • Do like everything else and require coverage in reliable secondary sources. Do the secondary sources deem a specific shooting an important incident in the history of the firearm? Remember that news reports are primary sources, and most journalists are not reliable sources for this subject: reliable secondary sources in this field are scholars publishing well after the fact and relying on primary sources like news reports. This will weed out the political/coatracky type stuff without excluding the occasional momentous incident. Nyttend (talk) 04:56, 23 February 2018 (UTC)
  • Please clarify "C. Include a paragraph-style section", do you mean a simple reference to each such crime in paragraph form such as is currently the the case in Modern sporting rifle or do you intend that a paragraph be added per crime, or somewhere in the middle? Cavalryman V31 (talk) 06:53, 23 February 2018 (UTC)
Dlthewave, as the nominator please can you clarify the above? Cavalryman V31 (talk) 11:17, 26 February 2018 (UTC).
The format used at AR-15 style rifle and SIG MCX is what I had in mind for most firearms: List the most notable shootings and briefly discuss legislative changes or other significant effects, with links to more in-depth coverage. However, AR-15 style rifle could include a longer Cultural Impact section similar to AK-47. –dlthewave 13:27, 26 February 2018 (UTC)
1C & 2D. A discussion about a specific page's content belongs on that page's talk page. Cavalryman V31 (talk) 14:26, 26 February 2018 (UTC).
  • Our existing polices are not broken and do not need fixing. The particular policy that applies here is WP:UNDUE, and this particular situation is described in WP:COATRACK. --Guy Macon (talk) 16:47, 23 February 2018 (UTC)
  • WRONGLY POSED QUESTION: There cannot be a general solution to this question, since the sources about the weapon in each case will have to determine whether the coverage of use in specific events is notable enough to include. It is completely wrong to seek to get a general across the board solution for this. Policy very clearly tells us that the SOURCES are what guides us in determining what is sufficiently relevant to include in the article. We do not need a general decision on this.·maunus · snunɐɯ· 16:46, 23 February 2018 (UTC)
  • 1D but the option feel for 2 is not there. In general, just because X was part of a crime does not necessarily make X notable, nor does it need to be the case to call out the crime on the article about X if it is already notable. X here can be anything - a firearm, a vehicle, software, whatever. However, if it is the case that X is specifically talked about after the crime where people are calling for legislation, regulation, or if the manufacturer takes steps specifically in response, etc. then the event can be named. A good example, Discord (software) was called out for harboring alt/far-right servers which were use to organize the "Unite the Right" rallys that became violent. In direct response, the developers affirmed new TOS and kicked out those servers. Same logic applied to guns. As for the second question, this is where we need sources that discuss broadly the number of crimes that the specific weapon has been linked to and if that has become a point of contention for the weapon. Just because the gun has been named as the weapon in numerous crimes, it is SYNTH to argue for a paragraph about that unless we have reliable secondary sources making that criticism about the gun. This is a case-by-case decision, and not listed among the options. --Masem (t) 16:57, 23 February 2018 (UTC)
  • 1C / 2C , based on existing guidelines. I would also recommend specifically rejecting the current WP:GUNS section on the topic which has been used in the past to specifically exclude such material from articles based on project-specific consensus, including in very notable cases. For example, the use of Colt AR-15 semi-automatic rifle in the Port Arthur massacre led to the enactment of the National Firearms Programme Implementation Act 1996. Under the present WP:GUNS content guide, this would only warrant a "See also" link. Other samples:
  • added a "See also" link per Wikipedia:WikiProject Firearms (while removing material), in SIG MCX.
  • per Wikipedia:WikiProject Firearms and talk page discussions, as well as discussions on Colt AR-15 talk page. Where consensus agreed that this type info was best suited as a "See Also" link, in Bushmaster XM-15.
  • We have a 9 to 1 consensus on Wikipedia:WikiProject Firearms to list crimes as bullet points in the "See also" section. Also in Bushmaster. Etc.
In contrast, here are two prior RfC which concluded with "Include":
I see such a project-specific consensus to be not conducive to building a neutral encyclopedia. K.e.coffman (talk) 08:11, 24 February 2018 (UTC)
  • In as much as this question has an answer, it's clearly 1D/2C, but it's rather disappointing that this is being presented as if it's some kind of overall question about inclusion of trivia, when actually it's all about trying to play down the role of assault weapons modern sporting rifles in mass shootings. That might be what the NRA want, but we are a neutral encyclopaedia and right now the main reason people are interested in that article is that it is the weapon of choice of American mass shootings. Which is to say: mass shootings, since almost all of them happen in America. If anyone is looking up the article on the AR15 right now it is almost certainly to answer the question: why is this weapon front and centre in the current debate over gun control in America. It's kind of hard to answer that question without discussing it, which is of course precisely why the NRA came up with its always-too-soon narrative on discussing gun control. We should have a policy page: Wikipedia:Wikipedia is not NewspeakGuy (Help!) 09:00, 24 February 2018 (UTC)
    • We must take care to avoid the narrative of the gun control lobby as well as the narrative of the NRA. For example, we know that some terrorists/mass murderers use guns, we know that some terrorists/mass murderers use bombs, and we know that some terrorists/mass murderers use trucks. Yet our article on Mercedes Benz doesn't mention the many times that brand of truck was used in an attack, and our article on Vehicle-ramming attack and our articles on individual vehicle-ramming attacks don't appear to mention what kind of truck was used. Nor do we ephasise what kind of explosive was used in the making of the bombs. Yes, some guns are better or worse choices for shooting up a school, but it is also true that some trucks are better or worse choices for plowing into a crowd. The ASR15 is front and center in the current debate over gun control in America because the gun control advocates want to make that particular weapon illegal even though other weapons are just as capable of being used in a school shooting (for example, a sawed off semi-automatic shotgun would be far more effective at such close ranges). If we are to be a neutral encyclopaedia, we should not let the pro-gun or anti-gun lobbies decide what the narrative is. --Guy Macon (talk) 09:37, 24 February 2018 (UTC)
      • I agree with all of this but would throw in a consideration of WP:RECENTISM. If just now the debate is above banning the ASR15 due only to the recent school shooting, it might be too soon to consider including it because of the nearness of the event. If in a month that debate is still going, then that issue has legs and inclusion is reasonable per Guy's logic related to UNDUE/WEIGHT and staying neutral. But if this debate evaporates in a few weeks, it might not be appropriate to include. On the other hand, if the ASR15 has a history of people wanting to ban it after shooting events like this, then its reasonable to discuss that as a whole. (I just had to do similar with video games after Trump's statement this week; games have been attributed in several past shootings including Sandy Hook - though here, no specific games, just the form in general). --Masem (t) 14:31, 24 February 2018 (UTC)
  • 1C or 1D (which probably amount to the same thing, because use in a mass shooting is likely to have attracted a lot of RS about the gun) and 2C. These articles are subject to the content policies like any other. Therefore, if a gun is used in a mass shooting and there is coverage in RS about the gun as a result of that, it belongs in the article, preferably in its own sub-section. If there's a lot of coverage it belongs in the lead too, per WP:LEAD: "It should ... summarize the most important points, including any prominent controversies." Wikipedia:WikiProject Firearms#Criminal use should be rewritten to reflect policy. SarahSV (talk) 19:08, 24 February 2018 (UTC)
  • 1C/1D I would surmise by extrapolation reading Derringer perma-link, and the prominent picture concerning its most famous killing. As for question 2, go to the article talk page where all the sources can be discussed and have consensus decide based on those. Alanscottwalker (talk) 19:52, 24 February 2018 (UTC)
  • 1C, 2C - we include exhaustive lists of notable incidents for aircraft, I don't see why notable incidents involving specific firearms should be treated any differently. Ivanvector (Talk/Edits) 12:16, 26 February 2018 (UTC)
  • Case by case. The key point is how much was the specific model discussed by reliable sources in reference to the shooting. If reliable sources merely mention that shooter happened to use this model, but didn't go into detail, and imply it might as well have been any other of a dozen models, we probably do not want to mention it at all; they might as well mention the kind of car the shooter drove up in. If reliable sources say the impact that the shooting had on the company or sales of the model, we might want to have a sentence. If reliable sources state or imply that the specific item was an important factor in the event (like the bump stocks in the Las Vegas shooting), then we want a paragraph or more. --GRuban (talk) 17:06, 26 February 2018 (UTC)
  • 1C, 2C - Mass shootings are highly notable, and the weapons used are highly noteworthy. There may be rare exceptions to 1C, for example where a firearm is so generic and common (e.g. Glock n) or several firearms are involved, but some did not have a significant role in the shooting. Notably, some of these firearms articles read like product brochures and are overly-dependent on primary sources from the manufacturer. Adding information about how products are used (or misused) would tend to make the articles more well-rounded and compliant with WP:NPOV.- MrX 🖋 22:38, 26 February 2018 (UTC)
  • 1D, 2D Both depend and should be on a case by case basis. Emir of Wikipedia (talk) 22:51, 26 February 2018 (UTC)
  • 1D but that will often lead to 1C: If the weapon is an unremarkable part of mass shootings, and is indeed not remarked upon then lesser levels of coverage are warranted, but if RS either highlight the fact that the weapon is either a common part of said crimes, or an enabling factor in their commission, then we should have in-text coverage of that fact. With regard to the AR-15, 2C is probably the lower limit of coverage, given the abundant RS coverage of both the weapon's role in shootings, emerging coverage of effects of its shooting velocity on mortality, and the need to also cover legislative initiatives to control it specifically. In any case, the notion that societally important products should be discussed on Wikipedia primarily in the way they are sold, marketed, and collected, and not based on their larger social impact belies the purpose of a general encyclopedia.--Carwil (talk) 16:44, 28 February 2018 (UTC)
  • 1D, 2C Each should be evaluated on its own merits, but it's clearly justified in the AR-15 style rifle case.--Pharos (talk) 23:36, 28 February 2018 (UTC)
  • 1D, 2C There is no policy or guideline that constitutes a blanket ban or restriction on including this information. Even the oft-cited essay at Wikiproject Firearms includes a caveat: "In general, WikiProject Firearms goals are to work on improving the quality of project-tagged articles without imposing WikiProject Firearms guidelines as mandates." Inclusion and level of coverage should be considered on a true case-by-case basis, regardless of any local consensus that has formed at another article. Edit 3/3/2018: Additionally, Wikipedia:WikiProject Firearms#Criminal use should be changed to reflect the outcome of this RfC.
"AR-15 style rifle" would benefit from a Cultural Influence section similar to AK-47, as well as a mass Shootings section. This is a relatively undeveloped article with plenty of room to discuss its characteristics and the reasons for its popularity along with its use in mass shootings. If this is referred to as "America's rifle" and one of the "most beloved and most vilified rifles", not to mention its role as a "sporting" weapon, then surely there's a story to be told here. That said, our coverage of mass shootings should reflect the significant weight given by reliable sources. The prevalence of AR-15 style rifles in mass shootings has received significant coverage, and this is the appropriate place to include it. –dlthewave 01:42, 1 March 2018 (UTC)
  • 1D, 2C Generally, a case-by-case decision is preferred. In the specific case of the AR-15, I think there is definite cause to include it, with RS such as this NYT article clearly emphasizing that this gun in particular is a preferred weapon of mass shooters in the US. Regards SoWhy 11:24, 1 March 2018 (UTC)
  • Generally not - 1A, 2A, the existing guidance (and firearms essay shown above)seems generally sufficient. The article on any mass killing should list the weapons in the infobox as a key part of the event detail and how it happened. But it would be WP:OFFTOPIC at the weapon article as that is not information about the weapon and is not actually specific to the weapon where the killings could just as easily have taken place with some other make/model. Las Vegas used AR-15; Orlando used Sig-Sauer and Glock 17; Aurora used S&W, Remington shotgun, and Glock 22; Columbine used TEC-DC9, High-point carbine, and a couple of shotguns. The assault-gun ban was for features of weapons and not specific models. I could perhaps see the firearms essay being tweaked to add that if there is some unique feature about the weapon such that only it could have been used, or if the weapon is specifically singled out in a law just for that weapon then it should be mentioned. But to put in a mention at the weapons seems more advocacy than encyclopedic. Cheers Markbassett (talk) 04:40, 2 March 2018 (UTC)
  • 1A, 2A. The specific weapon used in a shooting is unimportant trivia. Go ahead and add it to the article on the shooting, but unless there is something very special about the weapon used (e.g. the shooter used a 3D printed gun because no other was available) there is no reason to keep a list of when the weapon was used. It could just as easily been substituted for any other gun. Natureium (talk) 15:42, 2 March 2018 (UTC)
  • 1D/2D - Anything other than a !vote for case by case decision is probably motivated by POV. (Invited randomly by a bot) Jojalozzo (talk) 03:14, 3 March 2018 (UTC)
  • 1C/2C. Various specific models or types of weapons have been characteristically used in specific types of crimes--not exclusively, but either as a usual element , or as what is in popular opinion --or popular imagination-- a usual element, just as in military service specific models or types are typically used for various purposes. The use of the model name cannot be understood by the reader without knowing such connotations. Guns are normally intended for use, and the use is part of any article about them. DGG ( talk ) 05:16, 3 March 2018 (UTC)
  • 1C/2C. This seems the most sensible solution to me. Guns are used in crimes may be "common knowledge" but actors act in movies is common knowledge too and we'd never have an objection to listing an actor's filmography, no matter how small the role. Step away from the whole gun argument. If some person, place, or thing, kept appearing on the national news for various incidents, would there be a strong argument for ignoring those incidents? The Boeing 757 article mentions it was one of the models used in the 9/11 attacks. It's not an indictment of the plane, it's not political. I think by the same token notable crimes where this gun is used should be included, in a neutral, but intellectually honest manner. — Preceding unsigned comment added by ForeverZero (talkcontribs) 09:20, 7 March 2018 (UTC)
  • 1C/2C. Special interest projects should not be able to dictate the tone of coverage for the entire encyclopedia. An encyclopedia article about anything, a toy, a gun, an appliance, a movie, should include the cultural and historical context or else it is just a Wikia fan page. Gamaliel (talk) 17:24, 7 March 2018 (UTC)
  • 1.C / 2.C, or as a second choice any other option but A, provided of course that reliable sources of sufficient depth exist for such content. The use of certain types of firearms in mass shootings (or other high-profile crimes) is an important element in what I understand to be the current discussion about gun regulation in the US, as covered by many reliable sources, and as such is part and parcel of a complete article about the topic. I see certain parallels to our policy WP:WAF concerning fiction: we want to cover our topics from the perspective of the real world, and not only from a "fan interest" / "in-universe" perspective. Sandstein 13:12, 9 March 2018 (UTC)
  • 1A / 2C. Rationale:
    1A per WP:NOT#INDISCRIMINATE, WP:NOT#ADVOCACY, WP:NPOV, WP:NOR, etc. The principal, obvious reason some people want to include this stuff on a per-model basis is anti-gun advocacy and to lead the reader to an opinion against the firearm in question. Shall we also include statistics on how frequently the model is used for hunting of particular game? How frequently it is used by private citizens to thwart crimes? How many police departments use it on a per jurisdiction basis? How frequently it is implicated in accidental injuries? How often it is used by suicides? (etc., etc.) If you answer is "no", then thank you for confirming that the mass-shootings thing is just PoV pushing. 1D could also work, but the answer is going to almost always come down to 1A anyway. Exceptions would be rare, e.g. the Uzi was the subject of intense public debate in and of itself, but this is quite rare.
    2C because we "teach the controversy": as a general (though poorly understood) class of firearm, there is noteworthy public policy debate, in multiple countries, about restrictions on AR-15s or even banning them entirely (though much of it is pointless and unrealistic – manufacturers would simply develop a similar modular platform; the appeal of the AR-15 is its modularity, its adaptability, which has nothing to do with "assaultness", an emotive nonsense concept made up by the anti-gun crowd to scare people).
    — SMcCandlish ¢ 😼 11:53, 10 March 2018 (UTC)
  • 1D 2C - It would be ridiculous to remove this information when there is so much press coverage and proposed legislation specifically mentioning certain gun types. However, including that a certain weapon was used by Charles Manson in the weapon's article seems like trivia to me, to just pull an example out of my butt. Nessie (talk) 15:03, 15 March 2018 (UTC)
  • 1C / 2C - A neutral, extremely well-sourced, SENTENCE has been forged and rejected with a spurious edit summary, and the deletion has been identified by an admin as tendentious editing. DS warnings have been issued. That edit should be restored.
Our existing policies are sufficient to deal with this matter, if the stonewalling on the article is broken by topic banning several tendentious editors. Otherwise it's a battle zone and time sink.
The lack of mention has already caught the attention of the media, to the embarrassment of Wikipedia:
  • How gun buffs took over Wikipedia’s AR-15 page. After Parkland, gun control information was strangely hard to find. The Verge
  • Pro-gun Group Edited AR-15 Wikipedia Page to Hide Mass Shootings, Newsweek
False requirement: "These paragraphs should only be added if the school shooting in question has had an impact on the gun, or new regulations have been put forward" is not a policy-based requirement, but one created by Wikipedia:WikiProject Firearms, and as such has no legitimacy as it violates several policies. Tendentious editors have created that ad hoc rule. They have no right to use it in article space, and even thinking that way is wrong. -- BullRangifer (talk) PingMe 05:07, 16 March 2018 (UTC)
The Verge article and the NW article which simply says "The Verge said..." are simply poor articles. The Verge writer gets basic facts wrong and mischaracterizes many events and takes quotes out of context. The article's speak to the poor reporting standards of the author more than anything else. Springee (talk) 11:41, 16 March 2018 (UTC)
  • 1C / 2C - The discussion of the use of particular firearms in mass shootings is absolutely appropriate, as it speaks to their technical capabilities. For example, in the Las Vegas shooting, we learned a great deal about the characteristics of rifles when used in conjunction with bump stocks. Further, remember that future mass murderers rely upon Wikipedia too. If you remove information about mass shootings from firearms articles, how will they be able to make an informed choice of weaponry? Cinteotl (talk) 06:41, 16 March 2018 (UTC)
  • 1A/B and 2C - Pretty much WP:MNA. A lot of this content comes from recent events, and political opinions around gun control. So we don't have the gun control argument on every single gun talk page we should keep the bulk of the content on these incidents on articles dedicated to them, and at most post a link that directs us to the incident. The generalized article should only contain generalized information on the subject. --Kyohyi (talk) 13:58, 16 March 2018 (UTC)

poll update

Collapsed per request. Discussion has been moved to Wikipedia talk:Village pump (policy)#Firearms/Mass shootings RfC: Poll update discrepancies until discrepancies are resolved.

Threaded Discussion: Coverage of mass shootings in firearms articles

Just a quick question on item 1. Is it asking if information should be included on say the Colt AR-15 article even if it was not a Colt AR-15 used but another AR type rifle? PackMecEng (talk) 17:24, 21 February 2018 (UTC)

No, I would consider that to be a separate discussion –dlthewave 17:57, 21 February 2018 (UTC)
On second thought, I would consider that to be part of item 2.
  • It would be undue to include the complete list of murders and massacres committed with AR-15 type rifles. But it would be disingenuous to not have a single mention of the ubiquity of the AR-15 type rifle in the Colt AR-15 article. And the whole Kleenex/paper tissue argument is just a red herring: you can't have an AR-15 type rifle without the original AR-15; not mentioning it (prominently, in the lead, since it is that well-sourced and that important) does no service to the reader and is intellectually dishonest. We do not need to defend Colt, and including a neutrally written paragraph is no attack on Colt, who I am sure are well aware of this matter. It is our job to inform the reader about where these guns come from and what their relation is to the "original". Drmies (talk) 18:16, 21 February 2018 (UTC)
  • I just want to state for the record that I oppose the idea of putting a list of school shootings in the "See also" section for gun articles. The event in question either had an impact on the gun or it didn't. - Knowledgekid87 (talk) 18:33, 21 February 2018 (UTC)
  • Didn't we have this discussion at some time in the past? What was the results of that discussion? I'm sure there's an old RFC out there that was about this exact issue. If someone remembers it as well, and knows where to find it, reading it may give some insight into the existing community consensus on this. --Jayron32 18:54, 21 February 2018 (UTC)
That is a significant part of the problem here. Every now and then, a small groups of editors have discussions on various talk pages which often result in a "local consensus", that they then try to rely on when making edits to other pages. Edits that often come in conflict with the "local consensus" established by yet another small group from a different talk page. We need a one-time, centralized discussion with a solid community-wide consensus that can also be written into the guideline (or policy), so that going forward, we can actually rely on that guideline or policy, and not another local consensus cooked up by a yet another small group of editors. At least 3 such discussions started on 3 different pages. They were closed and directed to the talk page of the project that the articles fell under the scope of. There was a discussion going there, but suddenly, it seems we're having it here now. - theWOLFchild 19:38, 21 February 2018 (UTC)
@Jayron32: Here's a relevant RfC that was held on a Talk page of a firearm article: Talk:Ruger_Mini-14#Rfc:_Add_major_incidents_to_article?. The result was "Include". K.e.coffman (talk) 23:39, 21 February 2018 (UTC)
I recall that one, it was close. Here is another recent RfC. The result was exclude. The results were also close. [[13]]. Here is a related RfC about adding use in crimes to automotive pages. Interesting that since it was about automobiles instead of guns, the results were strongly against inclusion.[[14]] In that RfC, claims of censorship were made as were WP:NOTE. Both are effectively addressed by the idea that not everything has to go in every article. No material is being excluded as it appears in the articles about the topic. Springee (talk) 01:05, 22 February 2018 (UTC)
These two RfCs mentioned directly above (by K.e.coffman & Springee) completely validate my previous comments about conflicting local consensuses. Any group of 5 or 6 pro-gun guys can put together a pro-gun consensus on a particular issue on one page, while at the exact same time, 5 or 6 anti-gun guys can put together an anti-gun consensus on another page, about the same issue. This is one of the reasons we have projects, and the appalling lack of faith and baseless accusations of bias have basically negated the very project that covers this topic and now we're having debates all over the place. What's next? - theWOLFchild 01:54, 22 February 2018 (UTC)
  • If it wasn't a Colt AR-15 then no, it shouldn't be mentioned. We have a parent article about AR-15s (which seems to be changing names quite often) then we have this article about one particular model. If the crime didn't involve this model why would we even consider linking the two. It's like linking James Dean to the Mustang he didn't drive to his death. Springee (talk) 19:24, 21 February 2018 (UTC)
  • To me, trying to pin people down would go against our WP:Editing policy by imposing a global rule where it should depend on the circumstances and the consensus of editors. Thus I would stick with my original opposition. Dennis Brown - 00:23, 22 February 2018 (UTC)
  • @Masem: the reason question 2 doesn't have a "maybe" option is that it deals with only one article (which currently, but not for much longer, resides at modern sporting rifle). ansh666 02:25, 24 February 2018 (UTC)
  • If the information to be included in the generic firearm article doesn't describe the why as explained above, I would change my response to 2B since mere identification seems comparatively trivial. I am concerned about the preponderance of reliable sources treating mass murder as a macabre competition by describing events as a US record or annual record. Professional and amateur contenders are differentiated by exclusion of events like the My Lai Massacre and the Waco siege. Perhaps the next step will differentiate individual achievement from team participation events like the Columbine High School massacre or the 2015 San Bernardino attack. This competitive focus may encourage individuals with self-esteem issues to seek recognition by achieving a higher body count using similar methods. Thewellman (talk) 20:11, 24 February 2018 (UTC)
Why? Why do we discuss jello shots in Jell-o, it's something people do with it that RS talk about. Alanscottwalker (talk) 21:12, 24 February 2018 (UTC)
I don't understand the basis for comparison. I suppose we discuss jello shots in the Jell-o article because there does not appear to be a separate article for jello shots, while this discussion involves potential duplication in the event article and the firearm article. Thewellman (talk) 00:24, 25 February 2018 (UTC)
No. We also discuss jello shots in Gelatin dessert -- we discuss many (most?) things in more than one article because that's how encyclopedic topics work. And really, you don't understand, it's something people do with it that RS talk about. Alanscottwalker (talk) 00:41, 25 February 2018 (UTC)
Some may not understand the value of links to avoid a duplicated description at every mention of an unfamiliar term, and separated sources without Wikipedia's spectrum of information may require independent discussion because of a lack of linking options. I acknowledge the benefit of a separate description if sources describe firearm characteristics significant in the context of that event, but I consider a simple tabular link adequate if sources merely identify the firearm. Thewellman (talk) 22:39, 25 February 2018 (UTC)

  • FWIW I have closed an RfD on a number of AR-15-related redirects. ~ Amory (utc) 22:24, 5 March 2018 (UTC)
@Amorymeltzer: I think you meant to post this in the AR-15 discussion below. –dlthewave 21:29, 6 March 2018 (UTC)
Indeed. Moved. ~ Amory (utc) 21:38, 6 March 2018 (UTC)

Coverage of mass shootings: RfC wording & prior RfC

  • Comment -- I have concerns about the structure of this RfC and the language used, which can lead to misunderstandings. For example, [[Relevant WikiProject Firearms [[Wikipedia:WikiProject Firearms#Criminal use|guideline]] is presented as a guideline. This is, in fact, a project-specific essay and does not supersede actual policies and guidelines, such as WP:NPOV or WP:NOT. This language has been included in the RfC and several !votes (emphasis mine):
  1. B. Include links to notable shootings in the "See Also" section (Current WikiProject Firearms guideline) (language in the RfC)
  2. Oppose - any changes to the current policy (noted as "1B")
  3. Oppose. Existing guidelines (1B) are sufficient.
Some of the resulting votes are therefore subject to varying interpretations. For example:
  • Oppose: as existing guidelines are sufficient, and this should be decided on the article talk page.
this could be read as "Oppose, use WP:NPOV instead" or "Oppose, use WikiProject Firearms guideline" (I think it's the former, but if you look at vote #3 above, it's also an oppose based on a "guideline". ping @Dennis Brown: for clarification.
The selection of prior discussions also appears to be limited. I therefore suggest that:
a. the language in the RfC be changed to [[Relevant WikiProject Firearms [[Wikipedia:WikiProject Firearms#Criminal use|essay]] & "B. Include links to notable shootings in the "See Also" section (per Current WikiProject Firearms essay)"
b. this past page-specific RfC be added to the section on "Relevant talk page discussions": Talk:Ruger_Mini-14#Rfc:_Add_major_incidents_to_article? permalink. I believe that the RfC is relevant since it addressed the same question.
Ping @Dlthewave: as the author of the RfC to see if these two changes can be made. I don't think we should be conflating project-specific recommendations with community policies and guidelines. K.e.coffman (talk) 23:25, 21 February 2018 (UTC)
Thanks for the suggestion, I've made the requested changes. –dlthewave 23:53, 21 February 2018 (UTC)
So, after numerous editors have posted !votes with attached comments in the RfC straw-poll, the wording of the RfC is now going to be changed? wow... - theWOLFchild 01:59, 22 February 2018 (UTC)
    • I've already clarified above. This kind of hamstringing goes against WP:Editing policy, which is a policy. Let editors decide on a case by case basis. Twice I've been asked to explain, but my objection is much simpler than it is being made out to be. Dennis Brown - 02:31, 24 February 2018 (UTC)

Possible Wikipedia:Canvassing

K.e.coffman added this notice to the Wikipedia:Fringe theories/Noticeboard.

RfC notice: Coverage of mass shootings in firearms articles

An RfC relevant to this project has been opened at:

Interested editors are invited to participate. --K.e.coffman (talk) 01:23, 22 February 2018 (UTC)

Thanks, but... how does this relate to fringe theories, which are the focus of this noticeboard? Shock Brigade Harvester Boris (talk) 01:25, 22 February 2018 (UTC)

I too wonder..."how does this relate to fringe theories, which are the focus of this noticeboard?"--RAF910 (talk) 02:16, 22 February 2018 (UTC)

@Shock Brigade Harvester Boris: I've been advised by a WikiProject Firearms member in this discussion that nothing stopping you from posting notifications on the "WP:NPOVN or WP:VP" talk pages, or anywhere else for that matter, to involve as much of the community as possible. I assume various noticeboards qualify as "as much community as possible". However, I'd be happy to remove the notice if there's a concern. K.e.coffman (talk) 02:24, 22 February 2018 (UTC)
No concern at all. My first thought was that there might be some kind of fringe/conspiracy angle to the RfC that I had missed. So I was a bit puzzled but now see that you simply were casting the net as wide as possible. In any event accusations of canvassing are off the mark. I can't see how participating at WP:FTN implies a view one way or the other on issues like gun control, or favored firearm brands, or anything else related to the RFC. Shock Brigade Harvester Boris (talk) 02:36, 22 February 2018 (UTC)
I was the one that made that comment. That was of course, in support of having the discussion on the project talk page where it belongs in the first place, and where it had been moved to once already, (3 times actually), and where it had already begun, and where several editors had already contributed. I made that comment in response to your claims that editors from the Firearms Project were "biased" and that it wouldn't be possible to have a fair discussion there. But the discussion has since been moved (yet again) to this page, (though I'm not entirely sure why, possibly to quiet your concerns and accusations I suppose). So now that that the discussion (and RfC) is on "neutral ground", your multiple notifications are needless and indeed bordering on canvassing. You've also posted notices at Wikipedia talk:WikiProject Crime and Criminal Biography and Wikipedia talk:WikiProject Death. Where else are you going to post notices? "WikiProject:Mothers Against Guns"? At what point could one be considered "getting carried away" with all this? - theWOLFchild 03:28, 22 February 2018 (UTC)
I have not participated at all in this little kerfluffle but it's hard to imagine those notifications as canvassing. Why would participants at either of those two projects be biased one way or the other on the subject of this RFC? Shock Brigade Harvester Boris (talk) 04:22, 22 February 2018 (UTC)

If you suspect canvassing, you should follow the process at WP:CANVASS. Bring it up on the user's talk page and take it to ANI if it continues. This is not the appropriate place to discuss.–dlthewave 04:31, 22 February 2018 (UTC)

User:K.e.coffmans notice to the Wikipedia talk:WikiProject Crime and Criminal Biography is appropriate, because we are talking about crime. His notice to the Wikipedia talk:WikiProject United States seems reasonable, because this is a major issue in the U.S. right now. His notice to the Wikipedia talk:WikiProject Death is a stretch, but I can see it. His notice to the Wikipedia:Fringe theories/Noticeboard, I wonder about that one myself. Also, there’s nothing wrong with shining light on this matter here and asking involved editors for their opinions. That's what we're suppose do here.--Limpscash (talk) 05:51, 22 February 2018 (UTC)
  • Posting to the Fringe and Paranormal noticeboards can be a form of canvassing. For example, Wikipedia:Articles for deletion/John Traynor (Royal Marine) was posted at Wikipedia:WikiProject Deletion sorting/Paranorma. Traynor was a Lourdes pilgrim, an ex-soldier from Liverpool crippled by a wound during WWI who announced that he had been miraculously cured at Lourdes in 1923, an era when pilgrimage to Lourdes was a mass phenomenon; a mainstream Catholic religious practice. The Traynor story turned out to be unusually well sourced; SIGCOV in both popular and academic books and in major newspapers ongoing for over a century. Yet when I began to clean up and source the page, I was assailed by accusations of "adding sources written by believers into the article that support fringe claims. This is a problem for WP:Fringe." Similar attacks on Young Earth creationism, a religious beliefs that is mainstream in some Muslim and Christian circles, but Wikipedia:Articles for deletion/Is Genesis History?, about a film supporting Young Earth creationism, was posted at fringe. It is, of course, an "theory," with no support among scientists. The problem is that the debate was not an evaluation of notability. After it was posted at Fringe theories/Noticeboard, editors arrived who treated the AfD as a debate about ""A fringe subject... inside the creationist universe.", asserting that "The fact that it is a film promoting a fringe theory and not an article about the theory itself doesn't really change anything." which as closing editor said, shifted the discussion to the question of "do we apply the notability standards for fringe theories (which require sources independent from those associated with the theory), or for other subjects like films (which just require reliably sourced coverage independent from the subject itself, i.e., the film)?" As with the current AfD Wikipedia:Articles for deletion/The Spark: A Mother's Story of Nurturing Genius, the point of posting an article about a film, a book or a Lourdes pilgrim to the fringe or paranormal' boards appears to be to draw the attention of true believers who take up the cudgels, against Young Earth creationism, against ways of conceptualizing autism, against Lourdes water, against the lack of effective gun control. In other words, for a certain range of issues, posting at fringe and/or paranormal is effectively a type of canvassing that brings out holy warriors to join the crusade against... whatever is intensely disliked. They rush to articles posted at these boards and iVote delete without - as is very clear at Wikipedia:Articles for deletion/The Spark: A Mother's Story of Nurturing Genius - arguing that editors should IGNORE ALL RULES, in comments that too often show that they have not read the policies or the sources that they cite. E.M.Gregory (talk) 11:11, 22 February 2018 (UTC)
In this case, however, the post at FTN was NOT canvassing. It was a simple notification, phrased in neutral language. Blueboar (talk) 11:34, 22 February 2018 (UTC)
  • Posting on a noticeboard unconnected with the topic of the AfD can be a form of canvassing if the point of posting there is to attract a group of editors likely to share the posting editor's perspective. User:K.e.coffman has responded that there is no bar on posting to noticeboards, but has not explained his reasons for posting to this particular noticeboard, and, as I explain above, it such postings can skew discussions.E.M.Gregory (talk) 14:04, 22 February 2018 (UTC)
In order for requesting outside input to be canvassing, it has to be done with the intent to selectively recruit participants to sway the result one way. Maybe on some subjects simply alerting the fringe noticeboard could be canvassing, but I can't for the life of me guess what bias regulars on the fringe noticeboard would bring to this particular discussion. The topic is completely unrelated. That certainly makes the decision to request input there odd, but it was a completely neutral notification that the discussion exists. Unless you have an argument about how this particular instance constituted a deliberate attempt to fill the debate with anti-gun editors, calling it canvassing would really be assuming bad faith on K.e.coffman's part. Your argument amounts to: "It happened before, so it's also happening now. He hasn't explained himself, therefore he's clearly up to no good." Red Rock Canyon (talk) 20:32, 22 February 2018 (UTC)
I have been volunteering at the Fringe Theories Noticeboard for several years. Can someone please tell me what my political position should be, and what things I should "intensely dislike", because I didn't get any instruction in that regard. - LuckyLouie (talk) 23:35, 22 February 2018 (UTC)
I think you are expected to be against fringe weapons, and in favor of mainstream ones. So no mention of mass murders in any article about Tesla’s “death ray” (or even “Tesla style death rays”). ;) Blueboar (talk) 02:58, 23 February 2018 (UTC)

Page move request notice

User K.e.coffman has moved Modern sporting rifle to "AR-15 style rifle" without first seeking consensus. As a controversial and contested page move, made while related discussions were actively taking place (including here, hence this notice), the page has been moved back and a proper page move request has now been posted. Please see Talk:Modern sporting rifle#Requested move 22 February 2018 for more information, and if you wish to participate in the page move discussion. - theWOLFchild 03:03, 22 February 2018 (UTC)

@K.e.coffman: - You should take some time to cool down, this is the second thing I have seen you involved in here. Just hope the editing isn't getting to you is all. - Knowledgekid87 (talk) 03:09, 22 February 2018 (UTC)
I agree this is a controversial move, as were the edits to change the article scope without consensus. These should be reverted pending a full consensus discussion. These are not the same topic; a sporting rifle is a rifle used for sporting. AR-15 is a specific firearm platform, used for sporting, hunting, defense, military, police, and other rifle types. Also "AR-15 style rifle" is ungrammatical (missing hyphen from compound modifier "AR-15-style"), but such a modifier is potentially confusing, since it has two different kinds of hyphens in it, the first being part of a model name. It also doesn't make any sense, and strongly implies to the reader "rifles styled to look like AR-15s but which are not". — SMcCandlish ¢ 😼 12:08, 10 March 2018 (UTC)
@SMcCandlish: This been discussed and resolved at Talk:AR-15 style rifle/Archive 1#Article Title. Consensus was to move to AR-15 style rifle. This is outside the scope of the RfC, so please bring any concerns to the article talk page. –dlthewave 16:13, 10 March 2018 (UTC)
If it's quite recently been argued over, I won't re-open it so soon. I suspect others will realize the rename was a bad idea and do a re-RM at some point anyway. — SMcCandlish ¢ 😼 22:29, 10 March 2018 (UTC)

Two Roads, One Path: COI Edit Request System vs. WP:AFC

Background information:

  • In 2011 the Pat O'Keefe article was created. The article concerns the life and times of a boxer who lived during the roaring twenties. The article was created by an editor who placed very general information upon it, such as the birthdate, name, etc. Very general claim statements. Over the years, the article never grew beyond a few sentences at most.
  • Fast forward to today, where a relative of the boxer (who has an announced and recognized COI) has written a brand new article (which I'll call the draft version). They would like this draft version to supercede the current article (which I'll call the LS, or long standing version). They have been using the COI edit request system in the attempt to place the information from the draft version into the LS version. I have two questions here:
  1. The LS version, since the day it was activated, has never undergone any kind of formal review process, such as WP:AFC. Its texts have never been examined in detail, nor has any other details, large and small, been vetted through the lense of the AFC process. With this new draft version, isn't now the best time to place this draft in front of that process, in order that it might receive all those benefits, carried out by editors experienced in the AFC process?
  2. Is submitting the draft version for COI edit requests an appropriate use of the COI system? I had thought that edit requests were to be actionable directives placed before the community in order to quicky review and approve information into already well established and functioning articles where a COI presence was indicated. It is rare for a COI edit request to involve the entire article. Is the proposal to re-write the article within the intended scope of the COI edit request system?

Thank you for your attention, and I look forward to reading your responses. Spintendo      19:13, 2 March 2018 (UTC)

  • As there is an existing article, it should not go through AfC. We would have to delete the existing article, and move over (which we won't do), or delete the existing article, and then undelete it, to have a history merge so that we can have the history of the article in case someone want to revert the changes. I'll save you my rant on the issues that are involved with AfC and COI (tl;dr, it is a system that has structural advantages to being a COI editor rather than a non-COI editor.), but there would certainly be more eyes on it in mainspace, and it doesn't fuck up the article history. It should be done through the COI system, and changes be proposed incrementally (as I highly doubt the entire draft is ready for publication). TonyBallioni (talk) 19:21, 2 March 2018 (UTC)
Thank you for the information Tony. Spintendo      20:53, 8 March 2018 (UTC)
Some kind of process/system would be useful. Many CoI editing requests are not for creation but for modification, and it can take significant work on the part of editors willing to get involved. See for recent example. When there's not such a neutral, experienced editor available, what usually happens is either: A) permissible changes by a conscientious CoI editor doing it right are rejected out-of-hand by a drive-by respondent to the edit request, usually on the vague basis of "no consensus to make the changes". This is actually problematic under WP:EDITING policy; no one has to get permission first to improve an article here. Or, B) non-neutral edits which should not be made, and were written by a PoV-pushing CoI editor who is not doing it right, get approved willy-nilly by someone who didn't bother to read them carefully, and this is of course a problem under WP:NPOV policy.  — SMcCandlish ¢ 😼  12:15, 10 March 2018 (UTC)

Discussion about the phrase "manned mission" and weight of sources

Talk:Human mission to Mars#Requested move 5 March 2018

Is "manned mission" a gender-neutral term, and how much weight do we give to NASA's style guide? -- Netoholic @ 03:03, 6 March 2018 (UTC)

Predicting the outcome of US Elections

Please join the discussion of how NOTCRYSTALBALL should be applied to predictions of US election outcomes. NewsAndEventsGuy (talk) 14:50, 6 March 2018 (UTC)

Discussion about replacing CSD G6

There is currently a discussion at Wikipedia_talk:Criteria_for_speedy_deletion#Proposal:_Replace_G6_with_explicit_finite_criteria about replacing CSD G6 with more defined criteria. All are invited to participate. TonyBallioni (talk) 00:35, 8 March 2018 (UTC)

External links from talk pages to potentially infringing content

It recently came to my attention (thanks to Fram) that the common practice of linking to YouTube videos and similar user-generated content from talk pages, where the copyright status of the linked content isn't 100% clear, may be disallowed by WP:COPYVIOEL and WP:COPYLINK. I think the policy is heavy-handed and deserves to be reevaluated, and in my view should narrowed to apply only to article space. If this requires WMF's consent then sobeit, but getting the community's reaction would at least be a good place to start, if for no other reason than to get WMF's attention.

At least as applied to good-faith links from talk pages, the policy is extreme and reflects an outdated analysis of copyright law. It's settled law at this point that linking to infringing content does not create liability, except potentially in very narrow circumstances that don't apply to Wikipedia (i.e. profit-driven encouragement of copying, a la Piratebay). WP:COPYLINK cites a single court decision from 1999 that's widely viewed as an outlier. And the sentence in WP:COPYVIOEL, "Knowingly directing others to material that violates copyright might be considered contributory copyright infringement," is outdated. The ALA article the sentence relies on, which the ALA has actually taken down, didn't take into account any court decisions after 2000, when Internet law was still in its infancy. The law in this area has come a long way since 1999-2000 and our policies should be adjusted to reflect that.

Beyond the legal issue, restricting links on talk pages in this way is simply extreme and unnecessarily inhibits discussion and the development of the encyclopedia. I can't count the number of times I've used external links from talk pages to unvetted content to assist in research efforts or to advance an argument. We can't reasonably be expected to assess potential copyright issues every time we link to something for internal discussion. --Dr. Fleischman (talk) 19:31, 8 March 2018 (UTC)

Where there is possible fair use involved, I could agree that we should not be strict on links. But regardless of the question of linking, we can enforce stronger than US rules to, for example, disallow any links to a clearly non-fair use video (eg a full upload of a copyrighted movie without any transformative elements by the uploader). From the video games project, we have to be viligant against pirate bay-type sites, illicit key generation sites, etc. that we take away from articles and talk pages all the time but we don't want WP to be seen as complicit on the copyright vio. That may be stronger than case law, but it is a good reason to be stronger than case law. But when you get to things like research papers published on by the authors, despite the fact they had seemingly given copyright to the journal, that's a gray area - wouldn't use as an EL in an article but would be reasonable to help on a talk page since one can argue the fair use there by the researcher. --Masem (t) 19:54, 8 March 2018 (UTC)
Fair use isn't really an issue. Linking is legal, so there's no need or reason to invoke a legal defense, especially one as squishy and misunderstood as fair use. Of course our policies can be stricter than the law requires; what I'm saying is that in this case it serves little purpose and is detrimental to the project. If talk pages are being used as Piratebay-style clearinghouses for infringing works, then certainly that can and should be forbidden, though I'd think that would be sufficiently covered by WP:NOTHERE. I'm talking here about links included in comments permitted by our talk page guidelines. --Dr. Fleischman (talk) 20:26, 8 March 2018 (UTC)

@DrFleischman: the title of this section is misleading. No-one is prohibiting links to user ‘’’generated’’’ content. This is linking to data on, e.g., youtube that is not user generated, but to material that is hosted on, e.g., youtube in violation of copyright. I would ask you to make that clear in the title.

Bringing in a fair-use argument is a red herring. If the material that we link to is fair use on the external site, it is not a copyright violation on that site. In that case we are not prohibited to link to that (at least, if we put it in a fair use context).

Youtube however carries material in violation of copyright. Youtube takes such material down. That is material that is not fair use on youtube, and hence it is also not fair use for us to link to it - we link, like The Pirate Bay, to material provided by someone who is not providing the material under a fair use rationale, but is providing material in violation of the owner’s copyrighted. Whether ‘’we’’ would discuss it in context and could claim that through our discussion of the material is fair use, the material we link to is not fair use but a plain copyright violation.

Linking however to the original would be fair use, and that is ‘’always’’ the existing solution. That will result sometimes in ‘linking’ to material that is not available online. Although I can see that that is inconvenient, unfortunately it is a fact of life that we have to live with some inconveniences - we will have to load the DVD, sit through the first 45 minutes of Frozen until she finally sings ‘let it go’. —Dirk Beetstra T C 12:15, 9 March 2018 (UTC)

I fixed the heading; it wasn’t my intention to mislead. In any case, no offense, but your understanding of copyright law is way off the mark here. The main point is that good-faith linking from Wikipedia to potentially infringing content is perfectly legal regardless of whether the linked content might be protected by fair use or any other copyright defense. So there is no reason or need to perform a fair use analysis. It’s unreasonable and unnecessary to expect editors to conduct a fair use analysis before linking to other websites. And no I’m not just talking about YouTube. I’m also talking about things like copies of research papers, paywall newspaper articles that are re-posted to discussion forums or blogs, etc. That sort of content is infringing and not fair use, but linking to it for the purpose of improving Wikipedia is beneficial and perfectly legal. We should allow it. ————— Preceding unsigned comment added by DrFleischman (talkcontribs)
@DrFfleischman: But that is not what is discussed in that policy. What is discussed there is linking to material that plainly violates copyright, not cases that may or may not, or may be fair use. If I rip a DVD of a current movie, and upload that on YouTube, I am infringing the copyright. I am not allowed to link to that copy from Wikipedia, and YouTube will take it down. It is not your responsibility to check whether what I uploaded is a copyright violation, but if you notice, or if someone tells you that it is a copyright violation, then you should remove the link, and you should not add that link again. All the other cases that you mention have nothing to do with infringing copyrights and are legal to link to. Question is whether it is ethical to do so in some of the cases, and I will continue the argument that it is in all cases not necessary to link to material that violates copyright, so why specifically bother.
I do think that WMF has reasons to have that policy more restricted than maybe needed, and that this should first be consulted with WMF, as I doubt that any consensus here could trump WMF legal (again, I could bring an ad absurdum argument here). --Dirk Beetstra T C 16:24, 9 March 2018 (UTC)
Ah, I think I see the cause of our disagreement here. WP:COPYLINK and WP:COPYVIOEL have key differences. WP:COPYLINK only says not to link "if you know or reasonably suspect" that the linked content is infringing. WP:COPYVIOEL has much stricter language and says that when linking to sites like Scribd, WikiLeaks, and YouTube, "due care" should be taken. But as I look more closely, it appears that WP:COPYVIOEL, which is part of WP:EL, is just about external links from article space, not about links from talk pages. So maybe this is a non-issue. --Dr. Fleischman (talk) 18:10, 9 March 2018 (UTC)
There is a bolded part in WP:ELNEVER .. though the guideline applies in general only to content, that part applies throughout wikipedia, per the underlying policy.
I don’t understand why you, Dr. Fleischman, are so insisting about this after you linked to wat is very likely a copyright violation in such a frivolous way - there was nothing even remotely fair use in that link, and you could have easily given credit to the original, and I think that user:Fram rightfully removed that use. This has nothing, absolutely nothing to do with what is maybe not illegal for you to do, I hope you understand that. I am waiting for the first editor that agrees with you. If this subject is so important to you, then please have the curtosy to watchlist the pages where the discussion is going on, at least while the discussion is running. —Dirk Beetstra T C 19:29, 9 March 2018 (UTC)
You are poisoning the well and personalizing a good faith discussion. You are actively misrepresenting WP:ELNEVER, which doesn't say anything about "throughout Wikipedia." You are also using your misunderstanding of the law as some sort of cudgel to attack me personally. I do not appreciate this one bit. Have a nice day. --Dr. Fleischman (talk) 00:47, 10 March 2018 (UTC)
ELNEVER says without exception, WP:COPYLINK is specifically stating not to link to works in violation of copyright. I am not misrepresenting anything. But seen some recent discussions the issue seems to be that we want to be allowed to anything outside of mainspace, for whatever reason. I have early on said that thisis notgoing to change unless WMF changes it, we cannot do anything without that, it is moot. —Dirk Beetstra T C 05:40, 10 March 2018 (UTC)

I think we all agree that we can't set a local policy that violates WMF policy or the law. As there are several court rulings regarding linking to copyrighted content and the possible contributory infringement by the linker, I think we should get WMF Legal to opine on the matter. If they say "never" than that rather curtails the discussion. Likely the answer will be what it typically is with copyright questions: "it depends", after which we can then discuss how we want policy to reflect that; rather than going back and forth about what is or isn't fair use, we can focus on what does or doesn't fit with NFC as it pertains to ELs. CrowCaw 22:38, 9 March 2018 (UTC)

First off, this is not about NFC; NFC explicitly says, "Note that citation sources and external links raise other copyright concerns that are addressed in other policies." And the answer to the legal question is not "it depends." Other than someone subverting Wikipedia talk space and by turning it into a clearinghouse for pirated works (which is clearly prohibited by WP:NOTHERE), linking to infringing content is perfectly legal. But that's something WMF Legal will decide for itself. How does one ask them to opine? (I am not watching this page, so please ping me if you want my attention.) --Dr. Fleischman (talk) 00:33, 10 March 2018 (UTC)
It may be legal, but should we do it? NFC is an example of a policy where we go far beyond what "legally" is allowed because we want to make freely available content. Since that all of WP can be copied, thus making the presence of al link to purely copyvio material, it seems in the same vein to steer away from such links so that the text can be used by anyone. (The legality of linking to copyvio material is not universal around the globe) --Masem (t) 05:44, 10 March 2018 (UTC)
That is actually what I think is the reason behind the more strict 'legal rules' that WMF set in this respect, than what is 'in real life' legal/illegal. --Dirk Beetstra T C 07:01, 10 March 2018 (UTC)
It doesn’t matter if it’s legal. What matters is what our policy says, which is pretty clear: we don’t link to copyvios. Full stop. The legalities are something for lawyers to figure out. The advantage of our policies (which on copyright are often stricter than required) is that you don’t have to be a lawyer; you just have to follow the policy. We are free to prohibit linking to possibly copyvio works, and we do. What courts would say if someone brought a suit doesn’t matter: we don’t allow it. TonyBallioni (talk) 13:35, 10 March 2018 (UTC)
While I agree with this stance, there is a concern I have that we don't want WP editors being arbitrators of determined "possible copyvio" works. We can easily tell a link to a full copyrighted movie posted by a random user on YT is a copyvio link and remove it, but on the other hand, a user's review that includes clips of a movie is a grey area for both copyright and our use. We do want users to be vigilant and remove links that are to true copyvios, but not those that are in the grey area. --Masem (t) 14:26, 10 March 2018 (UTC)
I get your point, but I typically prefer the precautionary principle in use on Commons, and think it makes sense here as well. Perhaps a better way to phrase than possible copyvio is “reasonable odds of copyvio” or something of the sort. We don’t want our editors being IP lawyers, which is one of the reasons our policies are so strict: it’s easier to follow clear policy than the nuances of intellectual property law, and we want to discourage editors from attempting to play copyright lawyer. TonyBallioni (talk) 14:37, 10 March 2018 (UTC)
Its pretty clear if you look as a whole WP:PRJC "Editors may not violate copyrights or harass anywhere on Wikipedia. " - Wikipedia:Copyright violations "Copyright infringing material should also not be linked to." - WP:ELNEVER "Knowingly directing others to material that violates copyright might be considered contributory copyright infringement.This is particularly relevant when linking to sites such as Scribd, WikiLeaks, or YouTube, where due care should be taken to avoid linking to material that violates copyright. " - WP:ADMINH "Editors are entrusted with the responsibility of upholding the integrity of Wikipedia while adhering to intellectual property rights, such as avoiding plagiarism, respecting copyright laws", pls read over Contributory Infringement--Moxy (talk) 13:19, 10 March 2018 (UTC)

One thing I will add that recently came up was this Feb 2018 result in a NY District court, that rules that embedding tweets could be considered copyright infringement. No, it's not US case law yet, but it would definitely impact how we treat ELs (since we have full control over them). --Masem (t) 14:26, 10 March 2018 (UTC)

Legally speaking there's a world of difference between embedding content and simply adding hyperlinks. Recent court decisions are split on whether embedding content can constitute copyright infringement. They are not split on hyperlinks (again, with the exception of PirateBay-style profit-driven encouragement of pirating). (I am not watching this page, so please ping me if you want my attention.) --Dr. Fleischman (talk) 17:15, 12 March 2018 (UTC)
"Europe's Court of Justice rules that hyperlinking can infringe on copyright". The Verge. Retrieved 12 September 2016. . —Dirk Beetstra T C 04:35, 13 March 2018 (UTC)

While this was ongoing I ran into Copyright aspects of hyperlinking and framing. To me, that appear to be very similar cases as linking to a possibly/likely copyvio (and there it is in a context of news, here it is sometimes even frivolous use). (But I likely don’t understand ...). The part that I cannot get my head around is why it is even needed to link to a possible/likely, if not plainly clear, copyright violation. To me the whole question whether it is not illegal is completely moot, it is plainly unneccesary (avoiding stronger words). As linking to (possibly/likely) copyright violating material is simply disallowed by policy, I would suggest that such material gets blacklisted on sight if it gets mis/abused (also to avoid it accidentily appearing in content space). —Dirk Beetstra T C 19:57, 10 March 2018 (UTC)

Allow some categorization in disambiguation pages (or within redirects to them)

I would like policy and/or style guidelines to be changed or clarified to be allowed to categorize disambiguation pages (or redirects to them), in certain cases.

Perhaps the problem is that some of these disambiguation pages could/should be WP:Disambiguation#Broad-concept articles, and perhaps one solution is to indicate that via {{dabprimary}}.

First case

Brainless is a WP:disambiguation page, nevertheless I wanted to add the following categories:

  1. Category:Nothing - no brain
  2. Category:Pejorative terms for people - see wikt:brainless

Alternatively, I could a) create a redirect (with the categories) named Brainless (pejorative) and b) redirect it to a disambiguation page, then c) add the redirect (to self) as an entry in the disambiguation page.

My attempt was reverted here, because "this is a dab page". It was not helpful - hence this policy request.

There are several preliminary questions. As a WikiGnome, I try to populate both preexisting categories with words already used in titles of Wikipedia articles. How important is it that such words are placed in those categories, especially as Wikipedia is not a dictionary?

The ideal solution is to write up an actual Brainless (pejorative) article, rather than a redirect, but I'm a poor article editor (for now) which is why I prefer to remain a gnome - perhaps simply indicating it as a broad scope article would do. I thought my solution (categorizing in a disambiguation page as it didn't belong in any actual article) was a good example of WP:Ignore all rules for improving Wikipedia, but it doesn't help against "prickly" editors - hence this request. See also WP:Manual of Style/Disambiguation pages#When to break Wikipedia rules.

Note that if the disambiguation page had a "(disambiguation)" in its title (because the main article was about another primary use, I would either need the redirect form, or the original article should have a section stating that the naked word happens to be a pejorative. This is certainly the case for many songs with one word titles, e.g., Mindless used to redirect to Mindless (film) but I turned it into a dab - that is not always possible. PS. I'm drafting a broad-scope article to replace the mindless dab.

Second case

Disambiguation pages are not articles, but they do complement categories and list articles - they are a recognized source of (non-article) navigation, e.g., WP:Disambiguations are cheap. Sometimes, it is useful to treat them as lists of names. For example, in an article (&category) about various ways of grouping/labeling things, I have

Kinds of Groupings - weak Equivalence classes
Category Class Kind Group Type Tier Level

Each header of the table is a category, while all the entries are dabs. However, I wish to categorize these dabs under the header category, e.g., under Category:Category (grouping)

Now these dabs would not be of wide scope, but can I categorize them? I haven't read anything specifically prohibiting this, but more experienced editors have used this as an excuse to revert.


My categorizations and redirects are currently being questioned and/or reverted, so please invite User:DexDor and User:Marcocapelle to comment on this proposal. I believe the question of whether a new category that I had created should remain, is independent of whether some dabs can be categorized (often into prexisting categories that I had no involvement in). Dpleibovitz (talk) 20:00, 9 March 2018 (UTC)


  • I'm entirely confused by what you're asking. Natureium (talk) 20:46, 9 March 2018 (UTC)
    Can I categorize DABs? Some editors don't allow this. Policy is not clear. Dpleibovitz (talk) 21:20, 9 March 2018 (UTC)
    WP:DBC is pretty clear to me: Disambiguation pages are not articles and should not be categorized as such. Maybe you are referring to some other policy? --Izno (talk) 21:29, 9 March 2018 (UTC)
We categorize articles by the topic of the article - i.e. a category is a list (or set, if you prefer) of articles about a particular topic (plus there are maintenance categories - either hidden or on talk pages etc). Dab pages, by definition, are not about a particular topic so shouldn't be in article categories.
The OP of this thread has been doing some categorization edits that are strange (to say the least) - some non-dab examples where he appears to be categorizing a page based on a completely different meaning of the title are [this] and [this]. Quite frankly he should stop being a nuisance and take some time to learn how things work in Wikipedia. DexDor (talk) 21:47, 9 March 2018 (UTC)
(ec) I agree with DexDor that a disambiguation page is "about" an ambiguous term rather than a topic. Sometimes all the entries happen to have a common theme, but often they do not. For example, it's tempting to add Symphony No. 1 to Category:Lists of symphonies. However, the term has other uses. That dab page quite properly contains a ballet, an orchestra, a play and two albums and is hence not a list of symphonies. It's even more tempting to add Symphony No. 2, which today happens to be a list of symphonies. However, that's not its purpose, and the categorisation will quietly become incorrect if Symphony No. 2 (book) ever becomes a best seller. Certes (talk) 21:59, 9 March 2018 (UTC)
Oppose categorizing disambiguation pages other than as disambiguation pages. If, by their contents, they are susceptible to further categorization, then they may be candidates to be converted to set index pages or broad concept articles. bd2412 T 22:25, 9 March 2018 (UTC)
While this is correct, if we want to allow readers to access symphonies by number, the alternative is to have a List of Symphonies No. 2 which either replicates substantially all of the dab page, or is transcluded thereon, or is a redirect to a section. I think this is what the OP is getting at. All the best: Rich Farmbrough, 12:51, 14 March 2018 (UTC).

I understand the policy. I was giving two examples where I believe that exceptions to the policy can be made and to update that policy accordingly. This discussion is whether the exceptions make sense. Moreover, if there is a better way to accomplish my improvements to Wikipedia, I am all ears. DexDor is generalizing and cherry picking. I will present a broader picture. The following DABs (which he recently reverted) had been categorized under Category:Pejorative terms for people and some also under Category:Nothing: Fuckwit, Dull, Dork, Daydreamer, Buzzkill, Brainless, Bore, Bonehead, Blockhead, Bad Seed, Absurd, Careless, Drab, Dingbat (disambiguation), and Airhead. Some of these clearly indicate that the term is slang/pejorative, but had not been so categorized. In others, I added such an entry. Note that most are single word entries and that single word (or two word phrase) is known to be pejorative.

Personally, I think that in these cases, categorizing these DABs by WP:Ignore all rules is better then not. That is the question in this policy request - ideally the rules can be improved. DexDor, seeing all of these, he could have been more WP:CIVIL and suggested alternative solutions. I do agree with his Airhead revert (a primary topic) as Airhead (slang) is properly categorized and redirected to Airhead (disambiguation). The other cases don't have a (disambiguation) page - they are one. Cold fish doesn't exist, and I could create it as a DAB with one entry to Cold Fish, but perhaps this last one is a good example where a section in the Cold Fish article could be added stating the the term 'Cold fish' can be used as a pejorative - perhaps in a see also section with a link to wiktionary? Ultimately, are these categorizations useful, and rather than telling me what I cannot do, I would like to know how to go about doing so properly?

One of my first suggestions might meet most objections.

  1. Create "phrase (pejorative)" and redirect it to dab "phrase" or "phrase (disambiguation)" if it exists. Categorize the redirect, but not the dab it points to.
  2. Update the dab with an entry for this new redirect. Note that this would be circular.

This solution is imperfect for Cold Fish. Dpleibovitz (talk) 22:56, 9 March 2018 (UTC)

If you want to make all these "Foo (pejorative)" redirects, the disambiguation pages would be inappropriate targets for them. We don't redirect unambiguous terms to disambiguation pages. We have Lists of pejorative terms for people, and probably have specific individual lists hosting the intended meaning of these terms. Compare how Frontal (anatomy), Anterior (anatomy), Posterior (anatomy), and Dorsal (anatomy) all redirect to Anatomical terms of location. bd2412 T 23:40, 9 March 2018 (UTC)
Dullard is in Category:Pejorative terms for people. Dull, quite correctly, isn't. There is an argument for creating Dull (pejorative) as a redirect to an article (not to a dab), putting it in the category, and listing it on dab Dull, though I don't think we should do that because this is an encyclopedia rather than a dictionary. But Dull itself is a navigation page listing things with the spelling D-u-l-l, such as a Scottish town and a musician, and is not about the insult. Certes (talk) 00:06, 10 March 2018 (UTC)
  • Oppose, it is already obvious in the above discussion that this proposal is going to lead nowhere, but let me add that I think the fundamental problem is that proposer has lost sight of the purpose of the categorization system as a tool that connects related content with each other. With a particular emphasis on the word "related" (discussions with proposer about this aspect, see e.g. here and here) - and on the word "content" (i.e. no dab pages, no redirects) - which is subject to discussion here. Marcocapelle (talk) 11:35, 10 March 2018 (UTC)
  • Oppose cases like Brainless, where the categorization is with other articles and based on a WP:DICTDEF (in this case one not included in the article). I'm neutral on categories intended primarily for DAB pages. power~enwiki (π, ν) 01:22, 14 March 2018 (UTC)
  • For the article Cold Fish I have added a hat-note, pointing to Wiktionary. For the disambiguation page Brainless I have added a Wiktionary tag. A short definition could be added to the top of the dab page, this is often done. All the best: Rich Farmbrough, 13:00, 14 March 2018 (UTC).

RfC: Is it encouraged to have references for key or complex plot points in plot sections?

Wikipedia talk:Manual of Style/Writing about fiction

Is it encouraged to have references for key or complex plot points in plot sections? Bright☀ 12:58, 10 March 2018 (UTC)

Spam on talk pages

I'm not sure why this is the first time I've noticed this, but I have found some spam on a talk page. I'd like to remove it but thought I would ask for advice here first. I searched the archives and have not found this question. Thank you ahead of time for your answer(s). Please ping. Best Regards, Barbara (WVS)    07:19, 11 March 2018 (UTC)

User talk pages and article talk pages are different. If the spam is on an article talk page then you can remove it per WP:NOTAFORUM. If it's on a user talk page, you should ask the user to remove it. But if you are fairly sure the person who placed the spam is evading a block you can remove it per WP:EVADE. If the spam is horribly disruptive you can ask an administrator to exercise a Wikipedia:Revision deletion. If you can be more specific, I might be able to help further, Barbara (WVS). Binksternet (talk) 07:43, 11 March 2018 (UTC)
Thank you for the quick answer. The spammy content is on the talk page of Vulvar cancer. Barbara (WVS)    07:46, 11 March 2018 (UTC)
The comments at Talk:Vulvar cancer are not a problem. They could be regarded as spammy but they are good-faith attempts to promote a related cause without any disruption. Yes, that's a misuse of a talk page but it's very inconsequential. I could archive them if wanted. Re user talk pages, often spammers post stuff and are not seen again. If the user is not active, just blank any user page with spam. Johnuniq (talk) 07:59, 11 March 2018 (UTC)

ACTRIAL Post-trial Research Report posted

The Autoconfirmed article creation trial (also known as "ACTRIAL") has been running on English Wikipedia for the last six months, starting in mid September 2017. During the trial, article creation was limited to users with autoconfirmed status, meaning they had made at least ten edits and the account was at least four days old. Non-autoconfirmed users who tried to create a new page were redirected to a landing page, which encouraged them to create the article in the Draft namespace.

There's been a long-standing desire in the English Wikipedia community to run ACTRIAL since 2011, and last year, the Wikimedia Foundation Community Tech team worked on fulfilling this request.

The Community Tech team worked in partnership with community members from English Wikipedia to set up ACTRIAL as a research project, measuring the impact of the trial on three key areas: new editor activity and retention, the quality control processes (particularly New Page Patrol and Articles for Creation), and content quality.

Researcher Morten Warncke-Wang designed the study, collected and analysed data, and has just published the ACTRIAL Post-trial Research Report on English Wikipedia. The report presents the key findings, and makes suggestions for both the Enwiki community and the Wikimedia Foundation to consider. We hope that this report is a productive contribution to the ongoing discussions about new users and quality control.

We're looking forward to seeing what people think about the findings, and having lots more conversations about these issues. Please feel free to comment on the report's talk page, or ping us in the on-wiki conversations, wherever they emerge. :) Thanks! signed for User:DannyH (WMF), User:Kaldari & User:Nettrom. -- DannyH (WMF) (talk) 00:10, 14 March 2018 (UTC)

  • First, a thanks to DannyH (WMF), Nettrom, and Kaldari, all of whom did excellent work and navigated a sometimes tense relationship with volunteers. I think the results are overwhelmingly positive, and suggest that we should make the trial permanent. I've started drafting an RfC, that I plan to take to the community within the coming weeks so that we can discuss the results of ACTRIAL and come to a consensus on how to move forward.
    As Primefac and I have talked about the changes seen at AfC and NPP offline, something that he and I both have said (in private) that I don't think is captured here is that even with the shift to AfC, we see a net positive for the encyclopedia: NPP and AfC now are running very low on the backlog of newly created pages that are very old: this is the numeric point that we both use in looking at the respective NPP and AfC backlogs, rather than raw numbers. Thanks to the work of new page patrollers we now have successfully cleared the backlog past the Google index point, and the AfC backlog of very old drafts is also sitting very low. For the first time in a long time, the community has successfully achieved a state where all new content has been reviewed before hitting Google. This is something we should be proud of as a community, as it moves us forward to our strategic goal of being the most trusted source of knowledge. A big thanks to everyone who helped make ACTRIAL successful, both on the community side, and the foundation side. TonyBallioni (talk) 00:22, 14 March 2018 (UTC)
    +1 ✅ Atsme📞📧 17:14, 15 March 2018 (UTC)
  • As one of the pioneers of ACTRIAL way back in 2011 and having relentlessly campaigned for it to be carried out ever since, I would also like to join TonyBallioni in thanking DannyH (WMF), Nettrom, and Kaldari and their team. With regard to the en.Wiki community, and its users who are active in maintaining a clean encyclopedia, this has been the most important, objective, and helpful piece of research provided by the WMF in recent years. I echo TonyBallioni's comments and look forward to a closer collaboration with the Foundation in the future. Thanks also to everyone in the community who supported this trial. Kudpung กุดผึ้ง (talk) 17:24, 15 March 2018 (UTC)
Kudpung, TonyBallioni and Atsme: Thank you, that means a lot to us. :) -- DannyH (WMF) (talk) 17:29, 15 March 2018 (UTC)
Thanks! I'm glad we got to show that it's actually possible for the WMF and the community to collaborate and learn from each other. Also we can't forget to thank MusikAnimal for doing a lot of the preliminary research, MaxSem for doing the development work on ArticleCreationWorkflow, and TonyBallioni for helping to mediate the more contentious discussions. And thank you Kudpung for shepherding this whole process. Kaldari (talk) 20:30, 15 March 2018 (UTC)
I too am very pleased with the way this project has now worked out, and I hope it is an indication of things to come. Well done everyone concerned! All the best: Rich Farmbrough, 11:28, 16 March 2018 (UTC).

Why are Paralympians less notable the Olympians?

Why is it that every person who has ever competed at any Olympics winter or summer is entitled to an article; even if they only competed in one event and were only at the Olympics to make up the numbers. Some Olympians are selected by national authorities and get a place through filling of a continental quota. This is hardly the best way to become notable. Simply entering the Olympics should not be notable if the same is not extended to the Paralympics. I cannot see how notability can be granted for all Olympians ever no matter what. Where as Paralympains are only notable if they are a medalist.

This is not a paper encyclopedia and there should not be an arbitrary distinction between Olympians and Paralympians everyone should have an article or the rules should apply equally across both. What is the reasoning behind the rule that Paralympians must be medalists to be notable? This seems to be a distinction without a reason and purely arbitrary. The rules should be consistent across Olympic and Paralympic athletes. WTKitty (talk) 00:13, 14 March 2018 (UTC)

It essentially comes down to what is covered by sources. A LOT of sources (be they sports media covering the current games, or historians covering past games) cover the “regular” Olympic Games in depth... and all but ignore the Paralympic Games. We base our coverage (Notability) on that coverage. In other words, if there were more sources writing about Paralympic games and athletes, wikipedia would have more articles on Paralympic games and athletes. Blueboar (talk) 00:48, 14 March 2018 (UTC)
There sources are there and are ample. A great deal of work has been done over the last decade, and historians and media now produce ample resources. The Paralympics are not ignored. Notability is not an issue. The distinction is purely arbitrary and there is no reason for it; it is just a historical quirk, like the fact that porn stars have a special status on Wikipedia. Wikimedia supports the creation of articles on Paralympic athletes. Note that it only means that Paralympic athletes are presumed notable only if they have won a medal; WP:GNG still applies, and there is no restriction on creating articles on worthy Paralympians. So WTKitty, if you want to create an article go right ahead. Hawkeye7 (discuss) 01:18, 14 March 2018 (UTC)
For the majority of Paralympians before 1976 or so (and many in the 1980s as well), you will be hard-pressed to find good sources. The same goes for early Olympians (pre-1920), and the push should not be to lower the bar for Paralympians, but to raise the bar for Olympians. And even now, Paralympians routinely get a lot less coverage than Olympians, just like ijn many countries, the Paralympic Games as a whole get a lot less coverage than the Olympics. And of course, getting a medal in Paralympics is relatively easier than getting one in the reular Olympics, as the number of participants per discipline is generally a lot less. As an example, Austria at the 1980 Summer Paralympics: 48 participants, 45 medals. We have for example an "M. Petschnig" winning a silver medal (Advanced metric round open medalists). According to NSPORTS, he may get an article and is presumed notable. I haven't been able to find any further information on him though (well, he presumably is named Manfred, or at least there is a para-archer Manfred Petschnig listed in one other database). For any medalist at the 1980 Summer Olympics, finding sources is easy enough (the equivalent archer from the regular Olympics is Boris Isachenko). But for Paralympics this kind of even basic coverage is still missing, even for ones generously but mistakenly "presumed notable" at NSPORTS. Fram (talk) 11:29, 14 March 2018 (UTC)
It does not mean that articles cannot be written about paralympians, just that notability must be established through coverage in reliable sources. Olympians on the other hand are assumed to be notable, that is, the assumption is that sufficient sources exist to write an article. TFD (talk) 02:13, 14 March 2018 (UTC)
It’s actually a half step below that. Yes, we do start with the assumption that sources covering Olympians are extremely likely to exist... but on occasion, a diligent search for sources does turn up empty. On the rare occasions when that happens we admit that the Olympian is not in fact Notable enough. We have deleted articles on Olympians... not many, but a few. Blueboar (talk) 10:47, 14 March 2018 (UTC)
Eh... that may be giving a little to much credit. It'd be probably a little more accurate to say that the WP:NSPORT is overall one of the worst offenders as far as setting a standard that is often well below WP:GNG, and probably many thousands of such articles should therefore be rightfully deleted if we were to perfectly harmonize our policies. However, most people who have a strong opinion about it (like yours truly), also realize that it was a fait accompli a long time ago, and it's not worth the time trying to fight back the ocean, when you could be doing literally anything else that improves the project more than deleting a bunch of one line stubs with tremendous effort, mixed results, and tons of resistance. GMGtalk 11:11, 14 March 2018 (UTC)
Which I guess is what Notability is a guideline, not a policy. TFD (talk) 11:29, 14 March 2018 (UTC)
Well, SNGs are supposed to be a useful heuristic for whether a subject is likely to meet GNG. Some time ago we forgot that bit, and just decided to make them a replacement for GNG in special cases. It doesn't help any that NSPORT outright contradicts itself on the matter when comparing the lead there to the "Applicable policies and guidelines" section. Either way, lots of "articles" for which no actual article can be written, and not much to do about it in any practical sense. GMGtalk 12:53, 14 March 2018 (UTC)
Same reason they get less TV time.. it's sad, but it is what it is. Also we are FAR FAR away from having articles on all Olympians. Usually only if they have won medals in the olympics themselves, or in world/continental championships or multiple medals in national championships are you likely to be guaranteed to find an article on olympians. —TheDJ (talkcontribs) 11:23, 14 March 2018 (UTC)

Request for comment

Re: Template_talk:Infobox_officeholder#Religion=_restoration_and_guideline_for_usage In short, restore Religion= tag, as it seems improper to simply remove it, and instead of leaving its usage to random form, construct a guideline for the tag's proper usage. -Inowen (talk) 08:54, 15 March 2018 (UTC)

Another RFC? Didn’t we just have one? Blueboar (talk) 12:11, 15 March 2018 (UTC)

Ben Shapiro

Is an American firebrand whose page has existed since 2004 - he's 33 years old! His page includes more text than Einstein and his infobox includes this link - [{{]Conservatism US[}}], which itself is an entire library of Conservative history and proselytiseing. Is this not politicization of Wikipedia? Ben Shapiro is a noisy young man with an opinion - not a library of Republican conscience. Why does the "Conservatism US" category exist at all? I have deleted the link on the Ben Shapiro page but anticipate fierce reaction. Are we an encyclopedia or a political platform? Support needed on the Shapiro page. MarkDask 18:36, 15 March 2018 (UTC)

What's your question? Natureium (talk) 18:38, 15 March 2018 (UTC)
There is some irony in your calling him a noisy man with an opinion in what seems to be a rant you've posted on a Village Pump page. Killiondude (talk) 22:02, 15 March 2018 (UTC)
The fact that Wikipedia covers individuals of various political persuasions does not make Wikipedia politicized. Given his politics, and their significance to his biography, that article is clearly going to focus on conservative content. We have Category:Conservatism_in_the_United_States for the same reason we have other categories, to aid anyone in finding articles on almost any theme. The length is likely a result of enthusiastic authors, possibly over-enthusiastic authors. Making improvements is a routine matter of editing. If there is a dispute then a policy question might arise. Alsee (talk) 10:33, 17 March 2018 (UTC)


Thanks not working

Hi, Not sure if it's just me but my thanks doesn't seem to be working?
I go to thank someone (it then says thanked as it should) but then when I thank someone else on the same page it doesn't do anything and then when I reload the page the edit I thanked no longer says "thanked" (I just have the option to rethank basically),
Thanks, –Davey2010Talk 00:15, 20 February 2018 (UTC)

Davey, see if the thanks you tried to send are in your log. I don't know why it doesn't seem to work twice for you on the same page, but I do know that "thanked" reverting to "thank" when you come back to a page is an annoying issue that has irritated me for a while, but I've just kind of put up with it. If you want me to check if I get the same issue, reply to this, and I'll see if I can thank you for both edits from the page history. -- Begoon 01:13, 20 February 2018 (UTC)
I thanked Davey2010 for his edit here, and it now says I thank Begoon. I'm going to file a bug MusikAnimal talk 01:25, 20 February 2018 (UTC)
The system tells me you thanked me twice, MA, according to my "notices"... -- Begoon 01:28, 20 February 2018 (UTC)
Yep, I tried a second time and it thanked you for your other edit. It's thanking whatever the most recent non-thanked revision is. I created a bug at phab:T187757 MusikAnimal talk 01:30, 20 February 2018 (UTC)
Well, just to maybe add to the confusion, I thanked you both, from the page history, and each time I got the expected message, and "thank" said "thanked" for both edits on the page history after the second one. My log has 2 entries, one for MA, one for Davey... -- Begoon 01:35, 20 February 2018 (UTC)
Maybe you thanked before intermediate edits were made? Because that would mean Davey and I's edits are the most recent ones that aren't yours, if that makes sense. Either that or it is magically working for you but not others. @Begoon and Davey2010: What browser/OS/skin are you using? MusikAnimal talk 01:39, 20 February 2018 (UTC)
Vector, FF 58.0.2, Win 7. And yes, you could be right, looking at the times of the edits/thanks they could well have been the last 2 edits that weren't mine (Nagual edited in the same minute, I don't have seconds to compare.) -- Begoon 01:47, 20 February 2018 (UTC)
Hi Begoon, I've never had an issue before but got your thanks (thanks! :) ),
MusikAnimal - My thank log now shows as
"01:01, 20 February 2018 Davey2010 (talk | contribs) thanked My name is not dave (talk | contribs)
00:59, 20 February 2018 Davey2010 (talk | contribs) thanked Tacyarg (talk | contribs)
00:10, 20 February 2018 Davey2010 (talk | contribs) thanked Casliber (talk | contribs)
00:09, 20 February 2018 Davey2010 (talk | contribs) thanked Dodger67 (talk | contribs)
00:09, 20 February 2018 Davey2010 (talk | contribs) thanked Callanecc (talk | contribs)"
All of which I've never thanked (I tried thanking Ritchie333, SoWhy and Lourdes on Lourdes's RFA),
I'm currently using Vector skin, Chrome, OS is Windows 7, Thanks, –Davey2010Talk 01:51, 20 February 2018 (UTC)
I get the same error and added an example with screenshots to phab:T187757. This is serious. I suggest we hide thanks links until it's fixed. We can do it by placing the below in MediaWiki:Common.css. PrimeHunter (talk) 02:11, 20 February 2018 (UTC)
.mw-thanks-thank-link {display: none;}
@PrimeHunter: I was about to suggest the same. I'm going to up the task to Unbreak Now, but there's a chance it won't get fixed until tomorrow. So yeah, let's hide it. I don't think we can hide it on mobile too, can we? MusikAnimal talk 02:22, 20 February 2018 (UTC)
I don't know a way we can hide it in mobile but I suspect the vast majority of thanks are from desktop. Pages with thanks links are harder to find in mobile and most editors are in desktop. PrimeHunter (talk) 02:31, 20 February 2018 (UTC)
I agree. I've gone ahead and hidden it with Special:Diff/826612112 MusikAnimal talk 02:32, 20 February 2018 (UTC)
Similarly for mobile. —TheDJ (talkcontribs) 11:20, 20 February 2018 (UTC)
Despite MusikAnimal's edit of 02:30 today, thanks are still happening. --Redrose64 🌹 (talk) 13:04, 20 February 2018 (UTC)
Redrose64, those edits are done through mobile. Trizek (WMF) (talk) 13:07, 20 February 2018 (UTC)
Even those thanks that were made after TheDJ amended MediaWiki:Minerva.css at 11:20? --Redrose64 🌹 (talk) 13:19, 20 February 2018 (UTC)
@Redrose64: yeah, but we still have caching, the mobile apps, maybe a userscript and anything else that uses the api (possibly including troll bots). :) —TheDJ (talkcontribs) 13:29, 20 February 2018 (UTC)
Judging by the patch, I'm guessing the mobile version is unaffected. We might as well leave it hidden until the ticket is resolved, though. Thanks for figuring that out. Now I know where the mobile CSS is :) Which go figure is the SkinName.css MusikAnimal talk 16:31, 20 February 2018 (UTC)

"thanked" link reverting to "thank"

I've put this in a subsection so as not to pollute the discussion of the above serious error, but I'd still be interested in an eventual answer to this, which was touched on above. While the thanks "links" on this page history for the thanks I just made today, above, still show as an unlinked "thanked" no matter how many times I refresh or purge, if I revisit the page histories for the thanks I sent yesterday the link has reverted to a blue-linked "thank", with the opportunity to do it again. Is this how it's supposed to work (ie the links revert after a period of time)? -- Begoon 02:27, 20 February 2018 (UTC)

I think you probably had the same issue. When you thank in the interface, it looks like it goes through, but if you refresh, it ends up having thanked the most recent revision. The ones you did today were probably the most recent revisions, hence why they worked. MusikAnimal talk 02:36, 20 February 2018 (UTC)
No, I think it's separate. The edits which have reverted to "thank" are correctly shown as thanked in the log. Also, at least one of them was definitely the last revision when I thanked it (and still is, as I type). Also, also, this has done this, like this, for some time (weeks, maybe months), I've just never asked or "complained" till Davey mentioned something similar. -- Begoon 02:41, 20 February 2018 (UTC)
For as long as I can remember, any time I would log out and log back in, it would reset any edits I had thanked and allow me to thank them again. They remained in the log properly. Home Lander (talk) 02:49, 20 February 2018 (UTC)
Yeah, actually I do recall seeing that as well -- where the Thanks did go through but still reverted back to a Thanks link. For me it would revert back after a few days, not immediately, if I remember correctly. Anyway I agree this is probably an unrelated issue. I don't see a bug for it in Phabricator, so let's revisit it after the above bug is fixed.

Unrelated, I love that Nihlus just Thanked me for removing Thanks =p MusikAnimal talk 02:51, 20 February 2018 (UTC)

I was testing out the Mobile to see if there were any issues. :P Nihlus 02:52, 20 February 2018 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── I'm guessing this issue arose today; all my thanks in the log from yesterday and earlier appear to be correct. Guess I'm glad I didn't try to thank anyone today. Home Lander (talk) 02:59, 20 February 2018 (UTC)

@MusikAnimal: There is a phab ticket at Notifications: Getting multiple "Thank"s from one user for the same edit is possible (double/duplicate), this may cover it. --Redrose64 🌹 (talk) 13:10, 20 February 2018 (UTC)
That's it! Thanks :) MusikAnimal talk 16:31, 20 February 2018 (UTC)

Thanks not appearing

I'm presenting problems with the thanks feature too. In the article's history the thank option disappeared from the edits, and reads as (undo | ). Only those edits I have thanked before appear as (undo | thanked). I noticed that in the Spanish Wikipedia my option is shown normally. --Jamez42 (talk) 03:24, 20 February 2018 (UTC)

@Jamez42: That's because MusikAnimal removed it for now; see above thread. Home Lander (talk) 03:29, 20 February 2018 (UTC)
I added a watchliist notice for this outage, pointing to this thread. — xaosflux Talk 04:14, 20 February 2018 (UTC)
Thanks for the watchlist notice! I thought it was just me for a moment. Alex Shih (talk) 05:28, 20 February 2018 (UTC)
@Xaosflux: I just thanked you on your watchlist notice edit and I notice the action is logged both in my thanks log and your received thanks log. Did you receive notification for this or is it just not going despite the logs showing so?–Ammarpad (talk) 06:17, 20 February 2018 (UTC)
The problem appears to be that the thanks function is thanking the last unthanked edit in the page, regardless of which edit is chosen, so in many cases it is thanking the wrong edit/user. If the edit you thanked happened to be the last unthanked revision you were possibly "lucky" and it will possibly have worked "ok", by chance. The logs seem to be correct, but the feedback you receive at the time of thanking may not be. Don't rely on it at all until it's fixed would be my advice, though. I'm guessing you must have done it from mobile though, and I don't think anyone has confirmed exactly what that is doing, or if there is any difference. -- Begoon 06:36, 20 February 2018 (UTC)
...and I received your thanks for this edit, which, from my log, does appear to have been the most recent revision at the time you thanked me... -- Begoon 07:08, 20 February 2018 (UTC)
Yes, I am trying to figure it out because from the above, it seems to me like people are also not seeing the button at all. But I understand this edit now hid it, so I am now not seeing the button on desktop version, but still it appears and works in mobile. –Ammarpad (talk) 09:33, 20 February 2018 (UTC)
Yes I got it, no we don't have it disabled on mobile. See the phab ticket for some more details. — xaosflux Talk 12:37, 20 February 2018 (UTC)
It should be disabled on mobile view now as well. (Not necessarily the mobile APP). — xaosflux Talk 14:47, 20 February 2018 (UTC)
I just discovered it had disappeared from sight on my PC so came here to find that others have the same problem. I can no longer thank people. Doug Weller talk 13:52, 20 February 2018 (UTC)
Yes, I too discovered that I can see only the parenthesis(), but the Thanks word is absent.SouravDas1998[email protected] to me? 19:05, 20 February 2018 (UTC)

Thanks is fixed

  • Thanks to everyone who helped on this. — xaosflux Talk 23:17, 20 February 2018 (UTC)

Thanks isn't fixed

Fixing bugs in math rendering

Is there some standard forum for reporting bugs with the Wikipedia software itself? Specifically, I'm looking for a place to report the bug described at Wikipedia talk:WikiProject Mathematics/Typography#Apparent_bug_in_rendering_\operatorname* -- The Anome (talk) 19:31, 21 February 2018 (UTC)

@The Anome: Here is usually the correct first stop. If you are comfortable, you can report the bug yourself on Phabricator. --Izno (talk) 19:41, 21 February 2018 (UTC)
As Izno said, bugs ideally get reported on phab:Phabricator by someone. It might also be useful to leave a note at mw:Extension talk:Math, but I don't know how closely that page is watched.
Support for math rendering has historically been an area where volunteer devs such as User:Physikerwelt have contributed more than WMF staff. User:Debenben had a proposal up for the most recent m:Community Wishlist to make some substantial improvements in rendering, but it didn't get enough votes to win. The WMF is working on the plans for the upcoming fiscal year right now, and I've not heard anyone talk about math as a key area for improvements (which isn't proof that they're not). Whatamidoing (WMF) (talk) 19:52, 21 February 2018 (UTC)
See also here for a similar issue. I added a phab task for something similar, but no one seems to have really paid attention to it. –Deacon Vorbis (carbon • videos) 20:31, 21 February 2018 (UTC)
For some reason the input \operatorname* is replaced with \operatorname {*} by the texvc "validation". My suggested fix is to get rid of the broken validation. @Whatamidoing (WMF): Is there a way to influence the plans to include math as an area for improvements?--Debenben (talk) 22:53, 21 February 2018 (UTC)
I believe that most of the changes you've outlined belong to the Reading team (because most of them are about how the formulas display to the readers), and probably User:Jkatz (WMF) knows the most about that team's plan. Eventually, the drafts will be posted on Meta, and any interested person can comment. Whatamidoing (WMF) (talk) 18:50, 23 February 2018 (UTC)
Thanks! Actually, I should let @OVasileva (WMF): speak to this, as she is closer to the plan than I am. Apologies for the delay. Jkatz (WMF) (talk) 19:41, 28 February 2018 (UTC)
@OVasileva (WMF): Any updates?
I think investing some time into improving the math rendering now would save the reading team a lot of work in the future. Currently there are various different incompatible workarounds used by the editors, each with its own set of problems affecting the readers: The svg and png images usually look bad (unreadably small on iPad1, broken image icons on android 2...), unable to handle languages with non-latin characters, uncopyable... The templates are difficult to use, non-standard, inaccessible to screenreaders and can't handle everything. All of these workarounds have to be maintained only due to the lack of a working rendering system like MathJax, which is what other websites use.
Also, I don't think any volunteer developer would help to re-integrate MathJax or enable client side, HTML-based rendering if it will not become default. As an opt-in via MathML-capable browsers, plug-ins or user-scripts it is already possible today and an alternative system for hiding rendering problems of average readers from the editors is not useful. This situation will not change until the problem that kept the MathJax rendering option from becoming default is resolved: Providing servers (or using a third party cdn?) capable of delivering web-fonts to readers that don't have any suitable math-fonts installed on their device. I believe the additional traffic should not be an issue anymore.
Finally, bad software that is completely useless will not attract volunteer developers. For example, I currently don't see the \operatorname* problem this thread started with ever getting fixed. I created a ticket for my proposed fix: phab:T188879, it would already help if it gets discussed and agreed on.
--Debenben (talk) 19:23, 9 March 2018 (UTC)

Refill Mr

Hi I wanted refill on Marathi Wikipedia but I don't find the way out for it. I requested for it's translation on it's Transifex page yet no response. Can anyone create a version of it for Marathi Wikipedia? I and the community is ready to help in translation and templates needed. --✝iѵɛɳ२२४०†ลℓк †๏ мэ 05:51, 7 March 2018 (UTC)

Have you tried doing this in the visual editor? The Marathi Wikipedia already has the citoid service installed, and the visual editor offers a "convert" button for bare URLs. Open the page (in the visual editor; you may need to enable that in your preferences), select the blue ref tag, and then click the "convert" button that will pop up. Whatamidoing (WMF) (talk) 18:29, 7 March 2018 (UTC)
@Whatamidoing (WMF) and MusikAnimal: While citoid is concerned we have just installed it few days ago and it's not working fine. I've seen the convert button there and it fills one reference at a time (currently not working). Marathi Wikipedia has a lot of bare urls so I needed this tool to convert them on a large scale. Any developer that can make the same type of tool? --✝iѵɛɳ२२४०†ลℓк †๏ мэ 00:58, 8 March 2018 (UTC)
@Tiven2240: Hi, the reason it's not working is because the citation templates added to the message are missing the required TemplateData. I have temporarily disabled the message until this can be fixed. So for instance, the template संकेतस्थळ स्रोत, जर्नल स्रोत, and स्रोत पुस्तक didn't have template data. See'citoid'_maps_value_for_each_Cite_template. Once this template data is added, we can re-enable the message. Mvolz (WMF) (talk) 08:07, 9 March 2018 (UTC)
I certainly don't have time to work on it, sorry :( User:Dispenser has a similar tool, maybe he could assist with adding support for mrwiki? Otherwise, as I said ok my talk page, I would ask for help at User talk:Zhaofeng Li/reFill. According to the FAQ this is the means to request that new wikis be added. Best MusikAnimal talk 06:18, 8 March 2018 (UTC)
User:Mvolz (WMF), can you take a look at the citoid situation at w:mr:? This article looks like it has a couple of bare URLs, and citoid is no longer visible there (doubtless due to the 'hide if broken' feature that went out today). Whatamidoing (WMF) (talk) 22:47, 8 March 2018 (UTC)

@Mvolz (WMF) and Whatamidoing (WMF): I have prepared the template data and seen that the templates are working fine. Hope y'all make the further necessary changes for citoid. --✝iѵɛɳ२२४०†ลℓк †๏ мэ 09:56, 9 March 2018 (UTC)

I did a very quick test, and it looks like it's working now. Do you see any other problems with it? Whatamidoing (WMF) (talk) 21:42, 14 March 2018 (UTC)
Citoid is working all fine. --✝iѵɛɳ२२४०†ลℓк †๏ мэ 23:13, 14 March 2018 (UTC)

Apparent problems with STiki

Hi. I started using STiki today. Apparently, despite me attempting to revert only one edit, it is reverting the edit I intend to revert and the edit after that without my agreement. I had to go back and undo these changes. It seems strange for STiki not to work. I pressed Vandalism when I found vandalism and it reverted that edit and the edit after that. Why is this happening? I had to stop using this tool as I can't continue if it is blindly reverting without my agreement. Pkbwcgs (talk) 21:25, 7 March 2018 (UTC)

Hi, this sounds like a serious bug. I would ask about it at WT:STiki, and be sure to include what operating system you're using (Windows 10, MacOS Sierra, etc.). Best MusikAnimal talk 06:30, 8 March 2018 (UTC)

Watchlist adding and removing fails intermittently

Has anyone else been having problems today adding pages to, and removing pages from, their watchlist? It started happening to me for no apparent reason at around 21:00 UTC, 7 March 2018 (I don't often have the need to do this regularly, so it's been probably at least a week since I've have to change my watchlist before today). I tried to add about 10 pages in a row (opened in different tabs) to my watchlist via the star-click method and the vast majority failed, giving a "An error occurred while changing your watchlist setting…" pop-up message. Retried, and all or almost all failed again. I tried using the Alt-Shift-w keyboard shortcut, same thing. Tried logging out and logging back in, same thing. Occasionally one attempt would work, but the majority of times failed with the same error message. Since the problem was intermittent (in particular, sometimes working), I figured it wasn't just a problem with the configuration of my browser (FF 52.4.0 on Gentoo Linux) or my particular wiki account, so I reported the issue at the Phabricator (phab:T189160); more details can be found there. Given that no one seems to be talking about this here at VPT or at VPM, it doesn't appear to be a widespread problem, but I figured I'd post about it here, anyway. It's still happening as I post this, although the failure rate is way down (looks like waiting just a few seconds after a failed attempt is enough now to allow for a success; that wasn't true even a few hours ago). - dcljr (talk) 05:17, 8 March 2018 (UTC)

Infobox title is not center-aligned on mobile

I don't know if this was brought up before, but the title of certain infoboxes is not center-aligned on mobile. It seems to break depending on which {{Infobox}} parameter is used to make the title. When you use "above", like in {{Infobox person}}, it's fine (see Albert Camusscreenshot), but when you use "title", like in {{Infobox company}}, the software seems to think it's a regular table caption and it applies text-align: left; to it (see Blizzard Entertainmentscreenshot). – Srdjan m (talk) 08:22, 8 March 2018 (UTC)

The one is a header cell, and the other is a table caption. Due to the way table captions work, if they are too long, they overflow unhelpfully. If they are wider than the table, you would see the 'middle' part of the title, and not the start of the title. There aren't very simple fixes for that problem that could be found, so it was decided to keep them left aligned instead. —TheDJ (talkcontribs) 08:58, 8 March 2018 (UTC)
I'll see if I can find the ticket on this problem, maybe some things have changed for the better since we last looked at it. —TheDJ (talkcontribs) 09:05, 8 March 2018 (UTC)

Documentation on the int: construct

I was tipped to use this: {{button|{{int:publishchanges}}}}, to show Publish changes all right. Could someone give a link to int: documentation (help, WP, mw, ...). Likely it will also lead to the available options (like this 'publishchanges'). -DePiep (talk) 10:19, 8 March 2018 (UTC)

@DePiep: See mw:Help:Magic_words#Localization. It basically give the translated version of a MediaWiki: translation key. —TheDJ (talkcontribs) 11:07, 8 March 2018 (UTC)
(edit conflict) See mw:Help:Magic words#Localization. {{int:publishchanges}} displays MediaWiki:publishchanges in the reader's interface language, e.g. MediaWiki:publishchanges/de if you select "de - Deutsch" at Special:Preferences. Any pagename in the MediaWiki namespace can be used. PrimeHunter (talk) 11:09, 8 March 2018 (UTC)
Oh and Special:AllMessages lists all predefined translation keys (used by the software) and opening a page with language code qqx shows you the names of the keys being used on that page. —TheDJ (talkcontribs) 11:16, 8 March 2018 (UTC)
Thanks TheDJ, PrimeHunter. Helpful. -DePiep (talk) 00:21, 9 March 2018 (UTC)
Also, it's been in Help:Magic words#Other for four years (as of tomorrow). --Redrose64 🌹 (talk) 14:17, 8 March 2018 (UTC)
Redrose64, what are you trying to say? You think I did not search it? Or try WP:int:? To me, magic words look like __TOC__, and anything like {{#if: is a parser function (quote from there, lede: "* Parser functions: these take parameters and are either of the form {{foo:...}} or {{#foo:...}}, e.g. {{#invoke:}}. See also Help:Extension:ParserFunctions"). So far for mw consistency and documentation clarity. - DePiep (talk) 15:25, 8 March 2018 (UTC)
A search on help:int would have found information. I have added a hatnote to WP:INT. There are three types of magic words at mw:Help:Magic words#Localization. The term is most commonly used about behavior switches of form __TOC__, but built in parser functions of form {{int:}} with no # are also sometimes called magic words. Extensions like mw:Help:Extension:ParserFunctions can add more parser functions with # like {{#if:}}. Such added parser functions are not called magic words. PrimeHunter (talk) 17:38, 8 March 2018 (UTC)
This all may be OK, but: I did not find it. "You searched the wrong word spelling [stupid]" is not a reply I expect (yes, this is tough re good editors, but can one disagree?). Already above I pointed out (with links): mw help etc. is inconsistent. - DePiep (talk) 00:29, 9 March 2018 (UTC)
I didn't in any way imply you are stupid. I merely showed that searching the help namespace may be useful. I thought it was a helpful tip and didn't expect it to offend you. I don't know which inconsistency you refer to. Your only link was to mw:Help:Extension:ParserFunctions. It's a help page for a specific extension. {{int:}} is not part of the extension so it's not listed there, but the opening sentence links mw:Help:Magic words#Parser functions where it's listed. If there is a page incorrectly claiming that magic words can only look like __TOC__ and not {{int:}} then please identify it. PrimeHunter (talk) 10:56, 10 March 2018 (UTC)
I encountered int a while ago at Commons and for anyone noticing it there, they have an interesting trick. By convention (at Commons), [[MediaWiki:Lang/XX]], where XX is a language code, contains XX. That means {{int|lang}} is replaced with XX, where XX is the language code for the current user. For example, if your user language preference is French (or if ?uselang=fr is used in the URL), {{int|lang}} would be fr. That happens because c:MediaWiki:Lang/fr contains fr so lang is translated to fr for French. phab:T4085 is relevant. Johnuniq (talk) 22:10, 8 March 2018 (UTC)
BTW, this int is from "interface", not "i18n" nor "integer". -DePiep (talk) 00:29, 9 March 2018 (UTC)
"int" can be short for "interface", but it could also be short for "internationalise". The {{int:...}} function at Commons is exactly the same as it is here, at meta, wiktionary and all the others. At none of them does it mean integer; and I don't know where that i18n comes from. --Redrose64 🌹 (talk) 11:45, 10 March 2018 (UTC)
internationalization (i, 18 characters, n) - Internationalization and localization#Naming - but I don't really follow DePiep either... I see int: used a lot at Commons, as Johnuniq describes, and in multilingual file description templates, like: == {{int:filedesc}} == -- Begoon 11:54, 10 March 2018 (UTC)

Historical block records erased — bug or Ministry of Truth?

Bishzilla was admin in 2008 and 2009, perform some blocks, compare AN thread. See also example of block of specific user. Used to be log of these blocks! Now gone![15] How that happen? Where is block log? Pre-September 2009 block log by other admins also apparently erased. Why history erased? Especially considering old blocks still logged under blocked user. Is bug? Now look like Jimbo Wales never blocked Bishonen.[16] (He did, in 2009.) Disgraceful! bishzilla ROARR!! 10:33, 8 March 2018 (UTC).

Joking aside, it does indeed seem as if all blocks performed before ca. 20 September 2009 have been removed from the block log for all admins, which is probably not a good thing. Has this been communicated or discussed before? Fram (talk) 10:39, 8 March 2018 (UTC)
Hmm...This definitely do look like a bug.Any phab ticket opened somewhere?~ Winged BladesGodric 11:59, 8 March 2018 (UTC)
Not all of them are missing. The block log has plenty of entries for September 2009 and earlier, going right back to 23 December 2004 - those entries dated before 04:53 that day seem to be testing of a new feature. --Redrose64 🌹 (talk) 14:37, 8 March 2018 (UTC)
That's not what this is about, Redrose64. When I try to look at the blocks by an individual admin, such as Bishzilla or Jimbo Wales, it shows nothing earlier than September 2009. I know those blocks show up when you look in other ways: for instance, at the blocks of an individual user (example), or at the whole block log, as exemplified by you. Phabricator now says it's been fixed[17] and the fix is "being deployed" — I suppose not deployed yet, because the problem persists when I look. Bishonen | talk 16:23, 8 March 2018 (UTC).
None of the previous comments state that it is only the blocks by an individual admin that are affected. Indeed, Fram wrote "all blocks performed before ca. 20 September 2009 have been removed from the block log for all admins". So I looked at the block log for all admins - and found thousands of entries. --Redrose64 🌹 (talk) 16:45, 8 March 2018 (UTC)

The problem is fixed. Fram (talk) 09:05, 9 March 2018 (UTC)

Authority control

I think it could be useful there was a template like the {{Authority control}} template that included {{IMDb name}} (IMDb), {{Find a Grave}} (Find a Grave), {{MusicBrainz artist}} (MusicBrainz), {{Discogs artist}} (Discogs) and {{Wikidata entity link}} (Wikidata) identifiers.

As I see it the authority control is a kind of navigation bar to other websites, specifically those that catalogue people, books and the like. It is clearly intended to assist identification of the subject. For various reasons related to reliability a number of indexes have been excluded, possibly due to reliability, although ORCID is also user-generated and is included.

Imdb is listed at the bottom of almost every article about an actor, it would make sense to have a template similar to Authority control but for biographies of people in the entertainment industry. I also don't see why there are links to all the library databases except ours, adding wikidata seems completely logical, especially as that is where the data is coming from. By having a set template, it would be easier to stop the proliferation of external links (often used as a store for promotional material), because the section would not be needed to link to IMDb/etc. It would also be easier to add the same template to all actors/musicians, and display better for people that are both. Prince of Thieves (talk) 10:39, 8 March 2018 (UTC)

All these sources are unreliable ones. Musicbrainz is already included in Authority control anyway (but should be removed from it as it is a wiki where the main text is just a reproduction of our article anyway), and Wikidata is linked from the left side panel. Adding Findagrave and the like to more articles, or institutionalizing it in a template, is the wrong way to go. Removing them from many more articles is what needs to be done. Fram (talk) 10:43, 8 March 2018 (UTC)
There is this big difference: {{Authority control}} ({AC}) only cross-links external identifiers, not additional information ("what is this article named in library system Xyz?"). Accordingly, {AC} is not part of the article content (same as navboxes). So if you want to link to WP:EXTERNALLINKS (that do have extra info and are within article content), that would require a different template. One can not use {AC} for this.
That said, by information approach: I think such an {AC}-like, and an MOS:EL-defined template is useful and needed. Today {{Chembox}} (an infobox), is overloaded with EL's in the identifiers section (e.g. Carbon monoxide). - DePiep (talk) 11:00, 8 March 2018 (UTC)
User:DePiep, you might consider using Template:Medical resources as a model. Those links were previously handled in infoboxes. WhatamIdoing (talk) 23:04, 8 March 2018 (UTC)
  • To be clear I am looking for a new template like Authority control, not to add imdb to the existing Authority control template, this would then be used instead of existing imdb, musicbrainz, discogs and fa grave templates. It would be used purely as an external link template, and would not allow people to cite imdb any more than they do already. Prince of Thieves (talk) 11:07, 8 March 2018 (UTC)
@Fram: I can't see Musicbrainz in the Authority control template documentation, for sme reason it's implementation has not been made clear. It is in Module:Authority control, but I cannot not I can't see why it should be in that template. Prince of Thieves (talk) 12:12, 8 March 2018 (UTC)
There are many more resources included in Authority control than there are listed in its documentation. Who decides about which numbers are included is not really clear, I suppose the handful of people reading the template talk page? A thorough discussion about which IDs should be included (or which ones should be included in some cases but not in others), and how to display this (removing the actual numbers and keeping only the database names would reduce the "heaviness" of the template significantly), is needed, but I'm not the one who is going to start it. Fram (talk) 09:10, 9 March 2018 (UTC)

Visual Editor freezing at 'Publish Changes'

Hi - I'm experiencing severe problems demonstrating Visual Editor during an editathon event in which we're seeing VE freeze at the 'Publish changes' stage. It will not allow me to switch back from VE to source editing, either.

We have reproduced this issue on two separate Windows machines, and in both Chrome and Firefox. In the latter instance I logged out as me and tried to edit as another autoconfirmed user here who, unlike me, has never changed any of their default settings or installed scripts or activated any beta functions. A third editor also recreated the problem via their account. There was no difference in what we experienced - VE froze. The accounts we edited from were mine, User:Jonxennialuk and User:Mainlymazza.

To reproduce the fault we edited Buxton & Leek College in VE, we tried to copy, cut and then repaste an entire section with its heading into a different part of the article. At times a few letters that we had not typed ourselves also appeared, and we deleted these. At times we lost formatting of the Heading without any user input. On hitting Publish changes the process froze, so we were unable to enter an edit summary. On trying to switch to Source editor we got as far as the 'confirm' you want to switch stage and could go no further; we had to close the programme. The same fault was recreated whilst editing another article in exactly the same manner.

Any ideas? Regards from Derby University's IWD Editathon. Nick Moyes (talk) 13:38, 8 March 2018 (UTC)

@Nick Moyes: Not sure if mw:VisualEditor/Debugging offers any ideas. The "Network" tab of your web browser's Developer Tools might also show you where things get stuck. --Malyacko (talk) 13:43, 8 March 2018 (UTC)
@Malyacko: Thanks. I'm afraid I'm not sufficiently technical to be able to understand/investigate this further myself. I will have to 'leave this here' and hope others can attempt to reproduce the issue or advise whether this might be some local issue as a result of half a dozen editors at max logged on to the IP network accessing Wikipedia at once. I've advised fellow hosts at the WP:TH that I'm experiencing this issue in case other new editors do too. Nick Moyes (talk) 13:52, 8 March 2018 (UTC)
I also had some trouble there. I copied a section, and then pasted it just before the "References" section and VE magically added "Refer" between my paste and the references section. I then tried to click the publish button and the console reported: "TypeError: null is not an object (evaluating 'parentDomElement.lastOuterPost')". Might be something specific to that page ? —TheDJ (talkcontribs) 13:54, 8 March 2018 (UTC)
Pretty sure this is T187690TheDJ (talkcontribs) 14:21, 8 March 2018 (UTC)
Yes, that looks like it. Thanks for linking to my report here. Nick Moyes (talk) 15:25, 8 March 2018 (UTC)

Edit conflict with myself

NeilN edit conflict.jpg

For the second time in as many weeks, I've edit conflicted with myself on ANI. The edit goes through but I get an edit conflict message. Very strange. --NeilN talk to me 18:05, 8 March 2018 (UTC)

I get this too sometimes when I accidentally double click publish changes. I don't suppose there is a remedy to this? Alex Shih (talk) 18:28, 8 March 2018 (UTC)
I get this occasionally. My mouse is old and sometimes the left button bounces, so that an intended single click goes through as two clicks. --Redrose64 🌹 (talk) 19:08, 8 March 2018 (UTC)

NOTICE: EducationProgram extension is being deprecated

Please help translate to your language. Thank you!.

Over the years many issues have been discovered from our engineering colleagues regarding the Education Extension, including security concerns. For this reason, and with a viable alternative platform available, we are starting the process to deprecate the extension and having it uninstalled where it has been activated. This includes this wiki Special:Courses.

This means that the following steps will be taken:

  1. New programs are discouraged from using the extension and encouraged to use the Programs and Events Dashboard.
  2. Current ongoing programs will be supported, until the month of June, 2018.
  3. On June 30, 2018, the Education Extension will be shut down.
  4. If you are still running an education program that uses the Education Extension, please take the appropriate measures and also reach out to your colleagues and communities so they are also aware.

It should be noted that data of previous programs that ran on the Education Extension will remain safe, and we are working on documenting how to access that data.

Thus, we invite all Education Program Leaders (and users of the Education Extension) to take the online training for the dashboard so that you can benefit from this tool and make your work easier.

Did you know you can also use the P&E Dashboard at edit-a-thons, writing competitions, and other Wiki-based activities? More training courses for the dashboard are available here, so take a look!

Do you need to communicate with us about this?

  • If you have comments or questions, please reach out to the Education Team at educationAt, or the Programs and Events Dashboard group at dashboardAt
  • If you use Phabricator, you can also go to:
  • You are also welcome to share questions and comments on

-- On behalf of the Education Team 19:56, 8 March 2018 (UTC)

This is just a dummy reply that contains a signature with a link to a user page so this thread will be archived. Graham87 12:14, 9 March 2018 (UTC)

Article creation date

A researcher wrote to Wikimedia asking for help identifying the creation date of an article.

I responded that we typically equate the creation date to the date of the first edit.

I was slightly surprised I didn't find anything formally stating this.

I can think of a couple things to be concerned about if one adopted this is a rule (the intention, I believe, is to do a statistical analysis of the entire set of articles).

  1. Some of the edits of the very oldest articles are missing, so that the first edit one can find in the existing database is slightly more recent than the original creation edit.
  2. There may be some issues when a redirect is converted to an article. For example, if someone created a redirect 2010, and someone else converted it into a proper article in 2015, what is the creation date of the article? Depending on the nature of the study, one could make an argument for both dates and given that they might be separated by years, this is worth thinking about.

Are there other important classes of articles that could be an issue? In the case of deleted and restored articles typically the history is preserved so I don't see an issue there.

I would also urge the researcher to think about the definition of an article. For example, I believe we have more redirects than articles, and deciding to count redirects as articles would have major implications on average edits per article, for example.S Philbrick(Talk) 21:26, 8 March 2018 (UTC)

If a draft is moved to mainspace then it can be discussed whether the first edit or the move is the creation date. Sometimes the first edit is from a sandbox used for other purposes. PrimeHunter (talk) 00:37, 9 March 2018 (UTC)
The Did You Know? project's criteria for a newly created article is the date on which it first appeared in mainspace. As PrimeHunter suggests, an article can be worked on by one or more people in Draftspace or user sandbox for a very long time - years even - prior to being moved into mainspace. Sometimes moving a draft from a sandbox is a simple copy/paste job into mainspace or to WP:AFC, thus losing every scrap of prior editing history. I'm not sure I'd ever consider that creating a redirect is the same as creating an article - in what circumstances might that seem to apply? Nick Moyes (talk) 09:58, 9 March 2018 (UTC)

Please test pings in edit summary

1. Read this:

"You can notify users in edit summaries. They will get a ping just as if they had been mentioned on a wiki page. phab:T32750"-- meta:Tech/News/2018/10

2. Sign up at using a different user name and password (not the one you use here). You may create multiple accounts if you like, just put a note on their user pages.

3. Edit a page and put a username link in edit summary. Confirm that you are receiving the notification correctly.

4. Test at different pages and in different ways.

5. Report bugs to Phabricator.

6. Share this comment with other people on other wikis, in different languages.

--Gryllida (talk) 23:33, 8 March 2018 (UTC)

Please see mw:How to report a bug and use this Phabricator link instead (as follow-up bug fixes were nothing that was voted on in the Community Wishlist Survey 2017). Thanks. --AKlapper (WMF) (talk) 11:48, 9 March 2018 (UTC)

Searching user contributions

We used to be able to go to an account and look at all contribs in a certain year. Now we have to fiddle with a calendar and add start and end year, month and day. Does anyone know why this was changed, and is it possible to get the old interface back? SarahSV (talk) 04:33, 9 March 2018 (UTC)

2015 Community Wishlist Survey, coming in 15th place overall. No, you cannot revert back to the old interface, but I agree the calendars don't really help your use case. Perhaps it's easier to type in the dates (YYYY-MM-DD format)? You shouldn't have to put in an end date MusikAnimal talk 05:33, 9 March 2018 (UTC)
There's always tradeoffs :) —TheDJ (talkcontribs) 07:59, 9 March 2018 (UTC)
I guess it would help if you could just type "2008" in that field and it would automatically interpret that as 2008-01-01... It seems more strict on that fields validation now, than it has to be really. —TheDJ (talkcontribs) 08:01, 9 March 2018 (UTC)
@TheDJ: yes, that would help a lot. It does require an end date, by the way, but I've just discovered that it doesn't require a start date. SarahSV (talk) 02:13, 12 March 2018 (UTC)
The old query string parameters still work, try these out:
I guess somebody could write some JavaScript that adds the appropriate <input /> or <select>...</select> elements to the existing form. --Redrose64 🌹 (talk) 10:04, 9 March 2018 (UTC)
@Redrose64: thanks, that's good to know. Pinging Kaldari too. Can the interface be changed to allow us to enter the year only, so that we have access to that year and everything before and after it as needed? That is, the way it worked before. The new interface is fiddly. It would be nice if we could easily bypass it. SarahSV (talk) 02:13, 12 March 2018 (UTC)

Teahouse Ask-A-Question form fails to function in iOS

Screenshot of Teahouse's "Ask a Question" form on iPhone 5 showing overlapping text and no acccess to the question box itself.

Over the last few months we've seen a number of reports at the Teahouse that our page does not display properly in iOS, and especially that our "Ask a Question" tool doesn't work on iOS devices. See here, and here. I can certainly confirm this to be the case, having first reported it myself in December 2017. The screenshot shown here was taken today, and is no different from how it displayed back then.

On clicking the blue "Ask a Question" form, it's possible to enter text into the "Subject" line, but there is no access to the box to complete the question text itself, and, as can be seen, other elements of the page overlap one another. - a real mess. I can also confirm that if I log in from my alternative account User:NM Demo (which uses only the default settings any newly signed up person would have), the problem is also seen there, too.

The issue is of special concern because new users who want to ask a question simply won't have sufficient knowledge to know what to do once the Teahouse's own form fails them. I'd really appreciate it if this could be investigated. Regards from the Teahouse, Nick Moyes (talk) 10:51, 9 March 2018 (UTC)

@Nick Moyes: which version of iOS ? —TheDJ (talkcontribs) 10:56, 9 March 2018 (UTC)
Oops, sorry. I can only speak for myself: iOS 10 (10.3.3 - if I'm reading my phone correctly). I've intentionally not updated to iOS11 as I understood that version 11 now saves image files in a format that renders them unreadable to Windows users. Please correct me if I'm wrong on that. Nick Moyes (talk) 11:02, 9 March 2018 (UTC)
@TheDJ: It's worth adding that I've just tried the similar-looking "Ask a Question" form at WP:CQ and I don't have any problem accessing the form's subject line, the main text entry box,or the Publish changes button, whereas that's not possible with the Teahouse's question box. Nick Moyes (talk) 11:07, 9 March 2018 (UTC)
Hmm, that's MediaWiki:Gadget-teahouse/content.js and it's about as broken on desktop as it's on mobile really. Really needs to be rewritten from scratch with OOui or something. Maybe if we look very nicely at MusikAnimal he might be willing to take it on as part of community tech ? :) —TheDJ (talkcontribs) 11:50, 9 March 2018 (UTC)
I've disabled it for now as this is just obstructive and prohibitive right now I think. —TheDJ (talkcontribs) 12:12, 9 March 2018 (UTC)
@TheDJ: - thank you. I've just made a couple of test posts from a desktop PC and from my iPhone 5, and both post published OK. It's great when disabling something makes something else work properly. Regards, Nick Moyes (talk) 15:09, 9 March 2018 (UTC)
It does seem like a fairly important script. However it probably won't be trivial to rewrite it, at least if we use OOJS =p. I can't say if Community Tech would be able to work on this but feel free to create a phab task. You'd need to find something else to tag it with other than just community-tech, though :) MusikAnimal talk 21:43, 9 March 2018 (UTC)

User talk namespace template message for updating accessdate

Is there a user talk namespace template message to notify editors to update the |access-date= parameter in citing templates, such as {{cite web}}? -- AlexTW 11:57, 9 March 2018 (UTC)

Why would we need to do this? --Redrose64 🌹 (talk) 12:12, 9 March 2018 (UTC)
It's a common thing, I've noticed, for an editor to update the statistics for websites like Rotten Tomatoes and Metacritic, especially for films and television series, and not update the access-date parameter when they do so. Per the documentation of {{cite web}} for |access-date=: Full date when the content pointed to by url was last verified to support the text in the article [...] Note that access-date is the date that the URL was found to be working and to support the text being cited. This means that the parameter needs to be updated whenever the statistics are as well. For editors that do not do this, a user talk namespace template message would be handy; I was wondering if anything like this already existed. If it didn't, I was planning to create it. -- AlexTW 12:23, 9 March 2018 (UTC)
I also see this often in box office numbers, sports statistics and other changing data with a fixed source. An addition to Wikipedia:Template messages/User talk namespace sounds fine. PrimeHunter (talk) 12:36, 9 March 2018 (UTC)
Okay, great. Just wanted to make sure that they didn't exist before I created them. -- AlexTW 03:21, 10 March 2018 (UTC)
 Done Now at {{uw-accessdate1}} and {{uw-accessdate2}}. -- AlexTW 04:32, 10 March 2018 (UTC)

Shortcuts (Ctrl+I, Ctrl+B etc.) don't work any more in source code editor

Hi, I recently discovered that these shortcuts don't work in source code editor. I remembered them to work before. The weirder is, if you turned on syntax highlighting, upon pressing, say, ctrl+I, you can visually see the selected text became italic and then immediately changed back to normal.

I'm using Google Chrome. I have this problem on Chinese Wikipedia as well, tested logged in and logged out (to make sure it's not caused by non-default gadgets). --fireattack (talk) 15:23, 9 March 2018 (UTC)

Hello, fireattack, and thank you for this note. Which of the mw:editors are you using? Whatamidoing (WMF) (talk) 21:54, 14 March 2018 (UTC)
@Whatamidoing (WMF):: I believe it's mw:Extension:WikiEditor one (2010). --fireattack (talk) 22:40, 14 March 2018 (UTC)
Thanks for this. I haven't been able to reproduce this in Safari or Firefox on my Mac, but the flash for syntax highlighting happens in Chrome. Are you running Windows (version?)?
Also, I wanted to say thanks for your thoroughness in testing (logged in and out, more than one wiki). I really appreciate it. Whatamidoing (WMF) (talk) 19:06, 16 March 2018 (UTC)
@Whatamidoing (WMF):: I'm on Win 10/7. I tested with Firefox, these shortcuts are overridden by Firefox's own features (both Ctrl+B and Ctrl+I will just toggle Firefox's bookmark sidebar), so I doubt it even gets registered by the web page (needless to say, no flashing since they straighly up don't do anything). -fireattack (talk) 19:22, 16 March 2018 (UTC)

Parse Template:Location map entries

Dear Wikipedians,

I'm looking for a solution to parse the {{Location map~}} templates. So from

{{Location map+|England|width=300|caption=Example.|float=right |places=
  {{Location map~ |England |label=[[Battle of Blore Heath|Blore Heath]] |label_size=86 |position=top |lat=52.913611 |long=-2.424722 |mark=Battle_icon_(crossed_swords).svg |marksize=16 }}
  {{Location map~ |England |label=[[Battle of Tewkesbury|Tewkesbury]] |label_size=86 |position=top |lat=51.986389 |long=-2.161389 |mark=Battle_icon_(crossed_swords).svg |marksize=16 }}

I would like to get out all label=, lat= and long= tags. Do you know any linux commandline tool, which could do this? Sorry if that's not obvious to me.--Lazy Eight (talk) 07:22, 10 March 2018 (UTC)

I was able to do this partially with:
grep lat|sed '/lat/s/.*| *lat *= *\([^}|]*\).*$/lat=\1/g' |grep lat=
grep long|sed '/lat/s/.*| *long *= *\([^}|]*\).*$/long=\1/g' |grep long=

But label broke due to the pipes in the link Graeme Bartlett (talk) 10:17, 10 March 2018 (UTC)

I think it was just solved on Stackoverflow. @Graeme Bartlett: How should your code be run?--Intl Railways (talk) 11:03, 10 March 2018 (UTC)
This is part of a pipe. You can add <filename to the grep. or use something like wget -O- "URL" to launch it into the pipe. Graeme Bartlett (talk) 12:14, 10 March 2018 (UTC)
This is why we should move all this into wikidata :) —TheDJ (talkcontribs) 16:13, 12 March 2018 (UTC)

Broken template

Template:USS seems to have suddenly broke. For example, see USS Enterprise (CVN-65) Is there a template editor or knowledgeable admin than can take a look? This is affecting every ship article right now. - theWOLFchild 19:08, 10 March 2018 (UTC)

I undid the last edit to the template, which seems to have fixed the problem for now. Honestly, I have no idea what that edit was trying to accomplish so I'm not sure if there would be a better way to do it. Paging DePiep, who made the edit. --R'n'B (call me Russ) 19:19, 10 March 2018 (UTC)
Thanks for getting to that to that so quickly. List of current ships of the United States Navy was a ghastly red mess! Cheers - theWOLFchild 19:23, 10 March 2018 (UTC)
My mistake. Did the edit again, without it. - DePiep (talk) 19:24, 10 March 2018 (UTC)

Visual editor - discard "unsaved changes"

Is there any way to discard the "unsaved changes" of the visual editor. It's all very well that it saves them, but here am I, using VE for the automatic citation filler, then copyediting in source to use LDRs. Then, VE wants to revert those changes because they weren't made under VE. This is a problem, and could catch out somebody who discarded changes for a reason. Bellezzasolo Discuss 19:56, 10 March 2018 (UTC)

You might want to try VisualEditor's wikitext mode, which you can enable in Special:Preferences#mw-prefsection-betafeatures. (I recommend turning the "syntax highlighting" beta feature off, as the two sometimes don't play well together.) Then you'll get the visual editor's toolbar, with the mw:citoid button, but you'll be working in wikitext the whole time and not need to switch at all (except perhaps for table editing, because everyone agrees that deleting columns from tables is much easier in the visual mode  ;-). Whatamidoing (WMF) (talk) 21:27, 14 March 2018 (UTC)

How to test that a date/time string is in "yyyy-mm-dd hh:mm:ss" format?

Need an explanation, or perhaps a pointer elsewhere. How can I check that a supplied date/time string is in yyyy-mm-dd hh:mm:ss format? Presumably with a suitable regex, but I can't find any parser functions for that. Do I have to dip into Lua? Is there a module for that? (I know regex, but having trying to avoid having to learn Lua.) ~ J. Johnson (JJ) (talk) 00:46, 11 March 2018 (UTC)

@J. Johnson: What is your purpose? Does the time parserfunction help the overall purpose, or no? If it does not, there are similar functions in Lua. --Izno (talk) 01:01, 11 March 2018 (UTC)
If you decide to go with Lua, I wrote a simple function dateFormat() that returns the format (dmy, mdy, iso, ymd) of a given date. In Module:Webarchive - it would need expansion to parse hh:mm:ss -- GreenC 01:11, 11 March 2018 (UTC)
Does {{#ifeq:{{#time:Y-m-d H:i:s|TIME}}|TIME|yes|no}} work. {{3x|p}}ery (talk) 01:30, 11 March 2018 (UTC)
As others have said, please explain the purpose, preferably with an example of what would go in an article and what the wanted result would be. Module:Date can parse dates, see the examples in the documentation at {{extract}}. That template can tell you what format was used, but it only returns dmy, mdy or ymd.
  • {{extract|2001-2-1 14:30:25|show=format}} → ymd
Johnuniq (talk) 02:07, 11 March 2018 (UTC)

If you use anything other than a plain regular expression, there is a danger the function will have limitations you didn't think about, like failing for dates before AD 100, regarding 29 February 1900 as invalid, etc. A full statement of the requirements is called for. Jc3s5h (talk) 02:24, 11 March 2018 (UTC)

Thank you all, those look like good ideas. The key element is that I want to check the format, not validate or return a date/time. Which I think I can work out now. ~ J. Johnson (JJ) (talk) 21:06, 11 March 2018 (UTC)

Abusefilter conditions

OK. Thanks. --Horus (talk) 15:07, 11 March 2018 (UTC)

Lead section [edit] link

When we go to Preferences → Gadgets and scroll down to Appearance, the first checkbox is "Add an [edit] link for the lead section of a page". When this is checked, and when the "Move section [edit] links to the right side of the screen" preference is also checked, the edit link appears low enough to be sliced by the horizontal line that underscores the page title. This is unlike all the other edit links for later sections of an article. Those edit links are above the horizontal line that underscores section titles. Is it possible to raise the lead-section edit link so it appears above the line like the other edit links? (Note that if the "Move section [edit] links to the right side of the screen" preference is not checked, then the [edit] link comes right after the title and is positioned correctly above the horizontal line.) I use Windows 10 and have checked this in IE v11 and Chrome v65.  Paine Ellsworth  put'r there  15:33, 11 March 2018 (UTC)

It looks normal for me in Win10 and Chrome (vector skin). What skin do you use? Ruslik_Zero 16:25, 11 March 2018 (UTC)
I use the vector skin, too.  Paine Ellsworth  put'r there  17:13, 11 March 2018 (UTC)
(You should consider upgrading to Edge from IE11.) --Izno (talk) 16:48, 11 March 2018 (UTC)
I have Edge. eeyechhhh!  Paine Ellsworth  put'r there  17:13, 11 March 2018 (UTC)
PS I just checked it with Edge v41 and have the same problem. PS left by  Paine Ellsworth  put'r there  17:22, 11 March 2018 (UTC)
PPS I just checked it with Firefox v57 – same problem. PPS added by  Paine Ellsworth  put'r there  17:44, 11 March 2018 (UTC)
What screen resolution do you use? Ruslik_Zero 00:04, 14 March 2018 (UTC)
My Windows 10 setting is 1280 x 1024, and in IE and Chrome the text size is set to "largest" with 100% zoom. In Edge and Firefox the text size is set to normal.  Paine Ellsworth  put'r there  12:30, 15 March 2018 (UTC)
It may be an interference from another gadget or script. Try to disable them one by one. Ruslik_Zero 18:26, 15 March 2018 (UTC)
If you have more than a couple, then a binary search pattern is faster: disable half, and see if it's still a problem. If it's still broken, then disable half of what's left and check again. If it isn't, then put half of the removed ones back in, and check those. You may also want to see mw:Help:Locating broken scripts. Whatamidoing (WMF) (talk) 21:16, 15 March 2018 (UTC)
Thank you Ruslik_Zero and Whatamidoing (WMF)! The gadget that makes the difference is under "Appearance" called "Vector classic typography (use only sans-serif in Vector skin)". I started using that when titles and section headers were changed by the software. I find that when it's not checked, not only is the lead section edit link high enough to clear the horizontal line, all the section header edit links appear visibly higher than when it's checked, as well. This looks like something that can and should be fixed by the software, doesn't it?  Paine Ellsworth  put'r there  15:15, 18 March 2018 (UTC)

Lopadotemachoselachogaleokra etc...

There is a rendering problem with this article, basically the title carries on way off the screen breaking the format and creating a bottom scrollbar where there would not be one normally, but the rest of the page stops short at it's normal breakpoint, leaving the title projecting on it's own. Prince of Thieves (talk) 01:15, 12 March 2018 (UTC) ~

@Prince of Thieves: it is wrapping at the display end for me, with both Firefox and Chrome, logged in and logged out. What browser and conditions are you viewing it under? — xaosflux Talk 01:42, 12 March 2018 (UTC)
Looks fine to me. Firefox 58 on Mac OS. – Jonesey95 (talk) 01:42, 12 March 2018 (UTC)
The reported version is [18] which doesn't wrap the title for me in Firefox. I fixed the DISPLAYTITLE with word breaks to match the article name so the name can wrap at top of the article. It cannot wrap in other places like categories and search results. PrimeHunter (talk) 01:44, 12 March 2018 (UTC)
What PrimeHunter did fixed it, it wraps fine now. Prince of Thieves (talk) 01:51, 12 March 2018 (UTC)

updated since my last visit ???

I see updated since my last visit in a lot of edit summeries. What does that mean? Is there some piece of automated software that's inserting that? It's a pretty useless edit summary, since it doesn't give somebody scanning the history any clue what changed, or why. -- RoySmith (talk) 14:51, 12 March 2018 (UTC)

It isn't an edit summary, it's an automated message after the edit summary that tells you that this edit was done after the last time you checked the page. Jo-Jo Eumerus (talk, contributions) 15:02, 12 March 2018 (UTC)
Ah, thanks. -- RoySmith (talk) 16:17, 12 March 2018 (UTC)
You can hide it with this in your CSS:
.updatedmarker {display: none;}
PrimeHunter (talk) 19:58, 12 March 2018 (UTC)

Tech News: 2018-11

19:43, 12 March 2018 (UTC)

Notification from edit summary

  • The English Wikipedia should be good to go as far as modifications to scripts are concerned, what hasn't been updated yet will be by Thursday. Keegan (WMF) (talk) 21:41, 12 March 2018 (UTC)
This is cool. Thanks for implementing Keegan (WMF) (and all those involved) --TheSandDoctor (talk) 15:13, 17 March 2018 (UTC)

Enlarging text

Sorrowfully, I can't seem to find instructions for enlarging text in the edit window. I'll appreciate any help that comes in that regard. Thank you.--John Cline (talk) 05:55, 13 March 2018 (UTC)

On my browser I can do ctrl-mouse wheel rotation to enlarge or shrink all text. ctrl-shift-+ also enlarges. There would be a style sheet change that should change it too. Graeme Bartlett (talk) 06:01, 13 March 2018 (UTC)
OK style sheet change in User:John Cline/common.css: .mw-editfont-monospace {font-size: 200% !important;}
will double the size. Change 200 to get a size you like. (I am finding its a bit too big for me!) Graeme Bartlett (talk) 06:08, 13 March 2018 (UTC)
(I also note you are trying to include the deleted page: MediaWiki:Gadget-textareasansserif.css in your vector.css.) (this originally said textarea { font-family: sans-serif; } Graeme Bartlett (talk) 06:18, 13 March 2018 (UTC)
Thank you very much!--John Cline (talk) 08:59, 13 March 2018 (UTC)

Gender research on deleted articles

Hi all

I've been thinking a lot about the gender gap on Wikipedia recently and would like to understand if there is a relationship between the gender of a biography articleand article deletions. Is there a way to know the gender of the subject of deleted biography articles?

The question I'd most like to understand is are biographies about women more or less likely to get deleted? and if there is a large difference, why does this happen.

Also related questions:

  • Are articles about women more or less likely to be nominated for deletion than articles about men and in general?
  • Are articles about women that are nominated for deletion more or less likely to be deleted than articles about men and in general?

Is the data to do this research available? And if so how ould it be collected?

Thanks very much

John Cummings (talk) 14:29, 13 March 2018 (UTC) (@Victuallers: who may be interested.) John Cummings (talk) 08:32, 14 March 2018 (UTC)

@John Cummings: your edit that tried to ping Victuallers didn't work because you didn't add a signature while making it. Graham87 07:00, 14 March 2018 (UTC)
Thanks @Graham87:, fixed. John Cummings (talk) 08:32, 14 March 2018 (UTC)
Hi John (thx Graham) I'm not sure this is a technical question yet, as to my mind the major problem is to just phrase the experimental query that may lead to a convincing answer. There may be more notable male footballers than there are women who have played professionally. There are I guess more notable Crimean female nurses than there were Victorian male nurses. Some will seize on the results to feed the idea that the reason why there are so few women biogs is because of wiki admin discrimination. I'm not saying that the latter might not exist (can you prove it) but with (maybe) 100,000 plus missing notable women biographies already listed then it would just be misleading to highlight an article that was deleted as being the "poster girl" cause for systemic bias. (There are instances where female editors have been bullied off Wikipedia, but these are anecdotes.) So if I had to suggest an experiment then I would apply ORES scores to a month of newly written articles. I would see what percentage were deleted as just "rubbish" within a day. I would take a sample of those that were PRODed and those that were AFD'd and then those that were deleted. And then I would look at whether any of those groups contained a higher percent of females (adjusted for ORES score) than the original population. Or something like that. I suspect you may just discover systemic bias (which feeds a lot of twitter anger). Good luck!! Roger aka Victuallers (talk) 09:11, 14 March 2018 (UTC)
Oooo! I just thought of a counter experiment. Let us presume that the AFD system is absolutely biased and corrupt and all the female articles that were deleted were deleted unfairly. So if we put ALL of those back into our new 'Wikipedia .... then what effect would that have on the percentage of women on the new 'Wikipedia? How about if we also halved, quartered or decimated (divide by ten) all the male biogs that were successful .... then would that make a substantial difference? I think that answer might be quite revealing. Victuallers (talk) 09:37, 14 March 2018 (UTC)
Just FYI, in many cases "gender" of the article subjects is recorded at their WikiData entry, so it should be able to be looked up even if the page is removed. — xaosflux Talk 15:25, 14 March 2018 (UTC)
Gender is not consistently recorded for deleted articles, a number of which are deleted before wikidata entries are completed or the articles are categorized, and categorization does not always include gender, in any event. I do find that at least for the last several years that inclusion on deletion sorting lists is fairly common for individuals. Men are usually included at Wikipedia:WikiProject Deletion sorting/People, whereas women are usually included at Wikipedia:WikiProject Deletion sorting/Women and sometimes Wikipedia:WikiProject Deletion sorting/People. I'd be tempted to say that the implications of this linguistic decision are an exercise left to the reader but that would truly be unfair as, in my experience, women are included on the specialized list by the hardworking volunteers who do sorting so as to facilitate review by editors particularly interested in women's biographies. This does not include articles deleted via WP:PROD or WP:SPEEDY but might be a place to start gathering data. Caveats about taking into account all the potential inappropriate comparisons assumed. (talk) 16:04, 14 March 2018 (UTC)

Labels and data are misaligned in Infobox film

Just dropping by to let y'all know that there's an issue relating to line-height that might be of interest to anyone watching this page. – Srdjan m (talk) 15:38, 13 March 2018 (UTC)

Mysteriously-watched pages

Normally, I only watch pages that I have edited. Occasionally, something will show up on my watchlist and I have no recollection of why I might be interested in the page, but after checking the history of the page, its talk page, and their logs, an explanation surfaces. So, it's something of a puzzle as to why this edit has shown on my watchlist. I can't find evidence of me editing the page. Insects aren't my thing either - they creep me out. This is not the first page that is watched w/o explanation. Any ideas? --Redrose64 🌹 (talk) 19:24, 13 March 2018 (UTC)

You could just have accidentally clicked the watch tab while viewing the image. You reviewed Template talk:FPCresult#Adding noinclude 28 January 2013. The template was on Wikipedia:Featured picture candidates/Acrocinus longimanus MHNT femelle.jpg, while Wikipedia:Featured picture candidates/Harlequin beetle was open and got the template two days later. Maybe you looked for uses of the template and also clicked the image. I have no recollection of random pages I came by five years ago. PrimeHunter (talk) 19:57, 13 March 2018 (UTC)
You also might want to check your settings in preferences. One of them is "Add pages I create and files I upload to my watchlist", and another is "Add pages and files I edit to my watchlist". This may not account for the beetle pic, but it might be the source of links you haven't seen in a long while.     — The Transhumanist    22:24, 13 March 2018 (UTC)
I've had both of those enabled since forever; but I have no edits or uploads scored against that page. --Redrose64 🌹 (talk) 22:26, 13 March 2018 (UTC)

Double move

Does anybody have any idea why I seem to have moved the same pair of pages twice within the same minute? --Redrose64 🌹 (talk) 22:24, 13 March 2018 (UTC)

I don't have an idea but this query along with your above query suggests that something might be up with your account. --Emir of Wikipedia (talk) 22:38, 13 March 2018 (UTC)
I found another pair of double log entries from twenty minutes earlier. What do you think might be up with my account? --Redrose64 🌹 (talk) 00:42, 14 March 2018 (UTC)
When you move some page the related talk page also gets moved, hence the "talk" part in them. Sjoerd de Bruin (talk) 09:25, 14 March 2018 (UTC)
@Sjoerddebruin: I know that; my question is not about why the talk pages are logged, but about why there are two log entries for each category page and for each category talk page. That is to say, the log at 20:45, 13 March 2018 shows two instances of "moved page Category talk:NA-Class Finance articles to Category talk:NA-Class Finance & Investment articles" together with two of "moved page Category:NA-Class Finance articles to Category:NA-Class Finance & Investment articles" when I should expect only one of each. Similarly, the log at 20:26, 13 March 2018 shows two instances of "moved page Category talk:Start-Class Finance articles to Category talk:Start-Class Finance & Investment articles" together with two of "moved page Category:Start-Class Finance articles to Category:Start-Class Finance & Investment articles" when I should expect only one of each. Other page moves that I carried out in that timeframe log only one entry for each category page, and one for each category talk page. --Redrose64 🌹 (talk) 17:23, 14 March 2018 (UTC)
My best guess at the moment is that if you accidentally click "Move page" twice, the two submissions might both get past the "valid move?" checks before either gets to actually performing the move so both wind up doing the move. The second mostly does no-op updates like setting the page's title to the already-set new title, but it does create an extra log entry and null revision in the moved page's history. Spot checking a few date ranges, I see this has happened for other users' moves too and goes back at least a few years (e.g. Nishonoseki stable (1935) was supposedly moved twice at 2015-01-01 18:54). Anomie 12:15, 14 March 2018 (UTC)
Can double-clicks really do that? Since a number of people are unclear as to when a single click is sufficient and may use double-click "just in case", it sounds like something we should guard against, like not firing another event when there's already an identical one pending. --Redrose64 🌹 (talk) 17:23, 14 March 2018 (UTC)

A technical question regarding warning users before submitting potential copyright violations

First, this is not a proposal; do not !vote on it. This is a question for anyone who has a good idea how the Wikimedia software works regarding whether something would be technically possible, as well as the difficulty level required.

Would it be possible to put a system in place which does the following:

  • Whenever a new article is created, prior to 'publishing' going through, the article is automatically run through the copyvios detector.
  • If the submission has a confidence of 50% or higher, a warning message pops up warning the user that they might be submitting a copyright violation (link to the copyvios report) and giving a bit of information on what is ok to copy and what isn't (i.e. you can't copy from your own website unless the content there is under a suitable licence).
  • The warning asks the submitting user if they want to proceed or not, and if they do, it publishes the article but also flags the article for New Page Patrol as a potential copyright violation needing review.

Some information if there are any technical or legal roadblocks to the implementation of such a system would be great. Thanks. — Insertcleverphrasehere (or here) 09:14, 14 March 2018 (UTC)

No, this would not be possible as things currently stand. You'd need to either A) port the copyvio tool to be a MediaWiki extension outright, or B) have the tool expose an API of sorts that a MediaWiki extension could call and then use the results from. Either way, you'd need a new extension. FACE WITH TEARS OF JOY [u+1F602] 17:51, 14 March 2018 (UTC)
There is an extension request for images (that's phab:T31793). A similar phab task could be filed.
It sounds like a pretty good idea, generally, and it is definitely something which could be implemented. We do have ORES today (ORES documentation), so deeper integration there (ORES supports edit filters I think--but definitely has an API which a bot could use) might be a good idea. --Izno (talk) 18:07, 14 March 2018 (UTC)
From a tech standpoint, your use case is trivially subverted (a) create the page (b) edit it to include the "copyvio" stuff. So instead you'd need to score each edit - which could be computationally expensive if you wanted it to be real time (the current tool says Running a full check can take up to a minute if other websites are slow or if the tool is under heavy use. Please be patient. If you get a timeout, wait a moment and refresh the page.. Other tech challenges - putting such a tool in the way of production editing would mean that it would have to be well supported, 24/365 by paid staff. The other, much more serious problem is that those automated tools are horribly prone to false positives. For example I pulled up a Featured Article (Acrocanthosaurus) and ran that check on it - it got a 98% copyvio score. So either its a huge FP, or we are doing a poor job maintaining FA's.... (or the editor published elsewhere, etc,etc etc) - they are also bad with public domain text. — xaosflux Talk 19:49, 14 March 2018 (UTC)
I would assume in this case the Detector is detecting pages out on the web which are copies of our Acrocanthosaurus article, as it has been a featured article for quite a while. Presumably, it would have less trouble with newly created articles. - dcljr (talk) 05:42, 15 March 2018 (UTC)
[interpolated comment] Actually, xaosflux, come to think of it, the results of your test could be seen as a complete success, since anyone creating a new article that's an exact copy of the Acrocanthosaurus one would indeed be submitting a copyvio. [grin] - dcljr (talk) 05:54, 15 March 2018 (UTC)
It is trivially easy to circumvent but that doesn't mean it couldn't be useful to stop copyvios, even if it only checked when a new page is created. Most people adding those copyvios are not of the malicious sort. Galobtter (pingó mió) 05:49, 15 March 2018 (UTC)

JavaScript exploit at fawiki

Paraphrased from wikitech-l and a couple of other posts: On 14 March 2018, cryptocurrency mining software was discovered on fawiki. It was removed and the user responsible globally locked soon after. It appears (from here) that fawiki was configured so that anyone with the template editor right could also edit the MediaWiki namespace, including fa:MediaWiki:Common.js. Any website (particularly those with adverts) could attack users browsing with scripting enabled, and at enwiki, a compromised admin account could attack individuals or everyone with js exploits. Johnuniq (talk) 04:07, 15 March 2018 (UTC)

It is interesting why that revision was fully suppressed after that? Ruslik_Zero 18:33, 15 March 2018 (UTC)
For WP:BEANS reasons mostly I presume. —TheDJ (talkcontribs) 08:01, 16 March 2018 (UTC)
This kind of exploit has been possible in MediaWiki for over a decade. Discussions to solve this exploit start again every year or so, but typically the same solutions are proposed as in previous discussions, and the same arguments for and against the solutions are rehashed each time. --Deskana (talk) 11:26, 16 March 2018 (UTC)
Yeah this is nothing new that it is possible, but it is one of the more atrocious occurrences of it having actually been exploited by a 'trusted' user (possibly boosted by the crypto hype making people more aware of the seriousness of such incidents). We've been discussing ways to fix this hole without pissing off users for several years. As I've stated many times before, if we were to have started MediaWiki in the late 2000s, early 2010s, then this whole feature would have never existed and neither would user scripts. But since it does, it will take many many years to get rid of it. Some day... either it will be abused so terribly that we have to shut it down completely, or we find a solution that works and piss off some people :) —TheDJ (talkcontribs) 12:16, 16 March 2018 (UTC)
I am not sure that it would not be a solution in search of a problem - this is incident actually proved that it is impossible to insert any malicious code in the MediaWiki namespace scripts. Ruslik_Zero 20:02, 17 March 2018 (UTC)

/a/ in IPA

Hi. Im trying to add pronunciation help to an article, in the form of a phonemic transcription using IPA, like this: (/ˈkɒns.tənˌt[invalid input: 'a']ɪn/). It all works, except the a -- whether I use the cheat-sheet or copy the character from another good source. Where am I going wrong, please? I'm using Safari 11.0.3. Thanks --Frans Fowler (talk) 02:29, 16 March 2018 (UTC)

Sorry, found it myself. Use aɪ as a 'single' character - (/ˈkɒns.tənˌtn/) --Frans Fowler (talk) 02:42, 16 March 2018 (UTC)

Help needed on French Wikipedia

I am needing the help of a French speaking Wikipedian. On French Wikipedia, user Angela Criss is an obvious sockpuppet of Jack Gaines (talk · contribs). As I do not speak French, could someone please inform any French Wikipedia admins as to the user's doings, and ask them to protect any articles pertaining to Alan Jackson? Ten Pound Hammer(What did I screw up now?) 23:48, 16 March 2018 (UTC)

Pintoch (talk · contribs), one for you perhaps? Merci bien. --Redrose64 🌹 (talk) 23:50, 16 March 2018 (UTC)
@Redrose64: sure! but it looks like it was done and dusted before I arrived. − Pintoch (talk) 05:40, 17 March 2018 (UTC)

Editing edit summaries

Like these nested dolls, putting things in things gets complex. If you edit the edit summary and leave an edit summary for your edit summary, then that edit summary for the edit summary could need to be edited, in which case there would be an edit summary for the edit summary of the edit summary of the edit, which could in turn need to be edited. This can go on ad infinitum and be a distracting mind game, or a interesting film plot. -- Prince of Thieves (talk) 19:27, 17 March 2018 (UTC)

I know there must have been plenty of people who have proposed this before, but I would like to know if the interface could be modified to allow editors to change their edit summaries after they have saved the edit, rather than having to make a new edit where they don't do anything (or as it is sometimes called, a "null edit") just to modify their last edit summary. On a project otherwise defined by an almost complete ability to modify content after it has been posted, it seems odd that no one can change their own edit summaries (but of course you shouldn't be able to change others', just your own). Every morning (there's a halo...) 03:55, 17 March 2018 (UTC)

See e.g. the declined phab:T12105 and phab:T15937. PrimeHunter (talk) 12:17, 17 March 2018 (UTC)
There would have to be a history of changes to each summary, and the ability for people to patrol changes to summaries to watch for vandalism or personal attacks or the like, and so on. That sort of thing quickly gets rather complicated. Anomie 13:35, 17 March 2018 (UTC)
As Anomie implied, building a miniwiki for edit summary content would not be particularly productive. It's not too hard to make another empty edit, but it's super easy to preview your edit summary before hitting save/publish. We can edit content, but not history; same goes for the edit summary. ~ Amory (utc) 14:59, 17 March 2018 (UTC)
If I were to edit a prior edit summary, there should be somewhere for me to provide a description of the edit too, hmm that one might need to be adjusted to, it will be summaries all the way down. — xaosflux Talk 15:06, 17 March 2018 (UTC)
This sounds like corrections would become recursive, and that would cause really weird situations when trying to quote a diff. There would also be the issue of how to view the past revisions of edit summaries. Prince of Thieves (talk) 19:27, 17 March 2018 (UTC) (added image Prince of Thieves (talk) 19:27, 17 March 2018 (UTC))

Bug adding lines of blank text

Hi all, per instructions at Phabricator, I'm stopping to inquire here first; I'm well out of my depth on this and would be grateful for guidance.

I appear to be encountering a bug that is now repeatedly adding extra blank lines to the same spot in one entry (1, 2, 3). I'm editing in browser Firefox Quantum 58.0.2. If I'm tracking this correctly, it's only when I use the Visual Editor, although I was working on the same entry earlier in the day and this had not been happening, even on Visual Editor.

Might someone be willing, firstly, to cast a second set of eyes to make sure there's not some straightforward issue I'm overlooking, and if not, then assist me in properly reporting the matter (whether that's at Phabricator or wherever the appropriate place might be)? Much obliged! Innisfree987 (talk) 00:50, 18 March 2018 (UTC)

File restore error

Hello. I tried to perform a WP:HISTSPLIT on Wikipedia:Files_for_discussion/2018_March_10#File:Taisekiji_Hoanden.JPG. Everything worked fine, except the last stage - restoring. I want to restore these revisions, but depending on which revisions I select, I am either faced with this or this error. Any clue what's going on? I've done file splits many times on Commons. But I think this is the first time I've tried on enwiki. Cheers, Rehman 02:00, 18 March 2018 (UTC)

This sounds like a MediaWiki bug. You'd be advised to file it in Phabricator: mw:How to report a bug. — This, that and the other (talk) 08:17, 18 March 2018 (UTC)
File:Enwiki restore error 2.png is now filed as phab:T189985. I don't know about the other screenshots. BJorsch (WMF) (talk) 14:45, 18 March 2018 (UTC)

JavaScriptWikiBrowser interface text: where is it?

There's a script called JWB.js that is a partial port of AWB to JavaScript. I've been looking over its source code, and I can't find the interface text. There are phrases included on the screen when the program runs, but a search of the source code does not reveal them. For example: "Enter list of pages:" is part of the interface, but it's nowhere in the source code. The same goes for the other text displayed in the program's various frames. None of it seems to be in the source code, or in the program's css page. It's got to be coming from somewhere. But where?     — The Transhumanist    07:09, 18 March 2018 (UTC)

@The Transhumanist: I think it loads them from User:Joeytje50/JWB.js/i18n.js -- John of Reading (talk) 07:26, 18 March 2018 (UTC)
There it is! Thank you.     — The Transhumanist    07:40, 18 March 2018 (UTC)


An update of the default introduction & tutorial to Help:Introduction

Wikipedia's default introduction (WP:I) and tutorial (WP:T) for newcomers has changed little in the last decade. Yet the introduction of visual editor has made much of its advice confusing for newcomers (e.g. the advise to manually insert references using <ref>Your Source</ref>). Nevertheless, it is in a prime location, with multiple welcome messages and help pages funnelling new users to it.

Over the last two years, a group of users from the Help Wikiproject, have put together an updated version. The main menu, Help:Introduction:

  • Clearly separates the VisualEditor and WikiMarkup versions of each help page
  • Is more up to date
  • Has an easier-to-read layout pioneered by the original Help:Introduction to referencing

Replace WP:introduction and WP:tutorial with Help:Introduction. Overall, I think it is a marked improvement over the current default. Edits can be made if there are any elements of the old tutorial that are felt to be missing from Help:Introduction. T.Shafee(Evo&Evo)talk 11:42, 17 February 2018 (UTC)

'Oppose replace - have both as we do.....much more info in the tutorial that the help project keeps up to date dispite the assertion above (only 3 of us there really making updates and were not involved in these so called new pages about the wikitext portion). Like I indicated above no problem with having two different how to styles for this info. But the help project does recognize that these "Next Pages" things don't work out all too well as view count drops dramatically on the next page. The Wiki text links are old how-to pages the peoject has not update in a long time. I am concerned with the assertion made above that the project endorses the changes....some of the linked stuff is very old. Most automated post send our new editors to WP:Contributing to Wikipedia in hopes they find what they need on the first page with links etc. I hope this request is not because you can't edit the other templates. If you need help with them just need to replace. --Moxy (talk) 03:14, 18 February 2018 (UTC)
@Moxy: The proposal is because I think that help:intro series provides better learning materials for new editors than WP:I and WP:T. A large proportion of new editors get sent to WP:I and of WP:T. WP:I gets approx 100x more traffic, and the basic editing section WP:T gets approx 10x more traffic than their Help:intro equivalents. I think that the main options are:
  • Redirecting WP:T and WP:I to Help:intro equivalents, in my opinion the simplest solution.
  • Reduce the direction of new users to WP:T and instead direct to Help:intro in the various welcome messages, templates, help pages.
  • Overhauling and modernising the existing WP:T, but I think it would end up looking extremely similar to the Help:intro equivalents, at which point it'd be much of a duplication.
Apologies if I seemed to be speaking for the whole of WP:WPHELP - I was attempting to not take credit for the work of multiple people on the help:intro series. My application for templateeditor status was largely to be able to edit the {{Intro_to}} template. T.Shafee(Evo&Evo)talk 05:05, 18 February 2018 (UTC)
I do not belive Help:Introduction sub wiki introductions that have not been updated in a long time look better. They provide less readable text because of the sandwiched text beside the side tabs.... by omitting top tabs text is less readable especially in mobile view. Your asking to redirect two tutorials and the sub pages (Including Wikipedia:Tutorial/Editing/sandbox that is used daily) that are linked in many templates and automated messages to a list of links in a fancy format. This is a huge change that even omits a link to the projects main help pages. I am more them willing to help update what you think is missing in our long standing intros.--Moxy (talk) 06:21, 18 February 2018 (UTC)
  • Oppose: I'm not at all sure it is a good idea to show Visual Editing as the first option on "Help:Introduction". To become an effective editor, newcomers need to adopt the traditional approach using Wikicode. I note, btw, that "Help:Introduction" is linked with explanations from the Wrap-up page of WP:T. If WP:I and WP:T are not as "up-to-date" as Help:Introduction, they should be improved asap. Any important new features from Help:Introduction could also be incorporated.--Ipigott (talk) 11:14, 18 February 2018 (UTC)
Can someone explain what needs updating? So far those of us that work for the help project cant figure out what is not up to date.--Moxy (talk) 16:23, 18 February 2018 (UTC)
I've put some examples of things that I think would be worth updaing or replacing in some comments below. I really don't hthink that newcomers need to adopt the traditional approach using Wikicode. Plenty can be done without using it, and many users who just want to add a few paragraphs and references find the MS-word-like nature of VE easier to pick up than the html-like nature of WikiMarkup. Markup is certainly still more flexible, butVE is easier for first steps. T.Shafee(Evo&Evo)talk 12:18, 22 February 2018 (UTC)
  • Support in principle, though I haven't had a full read through the new pages yet. Attitudes like "newcomers need to adopt the traditional approach using Wikicode" are going to be the death of Wikipedia. It's painfully obvious that the visual editor is a vastly better way of introducing new editors to Wikipedia and a set of updated introduction pages which reflect this is a sensible idea. Sam Walton (talk) 13:11, 18 February 2018 (UTC)
The reason it's not used more is because there is so many problems Wikipedia:VisualEditor#Limitations. Need to learn some wiki code it they want to use talk pages. Files etc. We have a request to redirect 2 tutorials of 10 pages that covers both editing versions to a tutorial that separates the two and directs editors to a tutorial that has over 30 pages. The project stopped this formate years ago because....first page 5500+ views.....But...50% loss by 4th page. We have trouble keeping new editors reading 7 tabs.....not sure how 30+ tabs will help that. It's why we direct editors to WP:Contributing to Wikipedia an article style with all the info on one link runaround. Moxy (talk) 16:16, 18 February 2018 (UTC)
However, we'd need eye-tracking studies to know how much of the content on the one page is getting read. It's possible that many people aren't scrolling down to the later content, which could mean the multi-page approach still reaches more people. isaacl (talk) 17:08, 18 February 2018 (UTC)
100 percent correct....we use 2 styles of intros one has 7 tabs the other is in the article style (and the adventure that also has a completion problem) We direct most to the article style because some research seems to indicate that people get serviceable information out of the contents eye tracking and Which_parts_of_an_article_do_readers_read. Things are done in certain manners for a reason at the project. This request is a big change that the data we have tells us is not the way to go. Having more and being more stylish is not always the best way to go.KISS -Moxy (talk) 17:21, 18 February 2018 (UTC)
  • Oppose from what I can see this is a proposal to delete both Wikipedia:Tutorial and Wikipedia:Introduction, and basically replace them with Help:Introduction and a yet unfinished Help:Introduction to Wikipedia. Well I oppose these changes. The format of the pages, as well as missing a lot of detail, is a lot less user friendly in my opinion. While Wikipedia:Introduction doesn't contain a lot of information, Wikipedia:Tutorial does but in a far more user friendly format. Help:Introduction to Wikipedia hasn't even been completed yet, which makes me really question why this has even brought forward yet. Replacing a lot of advice in Wikipedia:Tutorial and replacing them mostly with a series of links is in my opinion a big mistake. Update them to include more VE info if necessary, but their basic format is a lot more favorable. Even the naming of the pages is poor and confusing. --Jules (Mrjulesd) 20:57, 18 February 2018 (UTC)
Just as a minor note, Help:Introduction to Wikipedia is only meant to be one page long. T.Shafee(Evo&Evo)talk 12:18, 22 February 2018 (UTC)
  • Oppose but with some sympathy I rarely look at either of the three pages, but I couldn´t support replacing the old with the unfinished. The old pages are clumsy written in a overcomplex form of English and jam too much on to each page and need severe pruning. The new page is focussed on how wonderful visually editor is and how there are equivalent functions in two disparate editing systems that the neophyte hasn't yet encountered.
Instead we need to function on the 'user of the page' and present what we need to tell him- in a language that is appropriate to his position on the learning curve. So at level one we want to say. A wikipedia edit has three parts- you type in an interesting fact- you say where you found the information- you write in the edit summary what you have done so you can find it later. When I am teaching wikipedia editing, my students start by writing me a message on my talk page, before they make a correction in an article. Failing that they write a short message on the article talk page, asking for forgiveness for any errors they are about to make. This blows out of the water, Visually Editor, which doesn't do talk pages- and kills stone cold the new suggested Help:Introduction. The next level one learning point is that wikipedia is not a free-for-all but has rules. This is targetted not only at the neophyte but the journalist passing by with the intention to to show anyone one can introduce a false fact so had to be prominent.
Now we get to level two skills and basic markup- student have little difficulty in understanding our markup, but we relish in failing to explain the obvious. Everyone seems to try and do a worse job than his predecessor. The difference between exposition and tutorial becomes more obvious. However remember the user will probably be very experienced in his own field, but may not have English as his first language. Put less text on each page. Avoid compound sentences, remove the nuances and put them in footnotes with {{efn}} or float individual level three pages where these can be discussed with all their options.
There are some tutorial booklet on my training page, that folk are welcome to customise for classroom use. User:ClemRutter/training * ClemRutter (talk) 01:15, 19 February 2018 (UTC)

@ClemRutter can you fix the dead links at User:ClemRutter/training would love to see what your using .--Moxy (talk) 14:52, 19 February 2018 (UTC)

@Moxy: So what happened there! Could it have something to do with MS buying Dropbox, and resetting permissions to make it more Linux unfriendly! So I have removed the links and am starting to rebuild them. Thanks for caring. ClemRutter (talk) 19:31, 19 February 2018 (UTC)
I think the links are all working- I have tested them on a third machine, as an ip logged into a new account- on a different brower-to get round the nest of cookies that were trying to be helpful. All the same the pdfs on Commons continue to work. Please let me know if you have any fresh ideas- or if I can be helpful getting the online help sorted.
  • Support (but keep the other pages around for now, and seek more input). As I learned while working on my help pages fellowship a few years ago, it's near impossible to write a perfect introduction to editing Wikipedia since users' aims and existing knowledge levels vary so much. The new pages could use more work, and better navigation between them would be helpful. However I believe they are improvements over the older pages in a number of respects:
  • The modular "Introduction to X" format was generally well received by new and experienced editors alike when I was working on the help pages, and it's great to see how these have been extended. From my research then it seemed these simpler "bitesize" introductions were a good structure. These should be backed up by easily findable more detailed help pages for topics people might be interested in, and also more personal interactive methods like the Wikipedia:Help desk.
  • The old pages attempt to cover too much for newbies. For example Wikipedia:Tutorial/Editing contains a section on Renaming articles. Not only would doing this require quite a lot of familiarity with Wikipedia:Article titles policy, but new users can't even move pages or see the relevant tab until they are autoconfirmed! And how often do you need subscript and superscript that it's one of the first things you're taught about editing? (and there are buttons for it in the toolbar if you do happen to need it).
  • While VisualEditor is not suitable for every type of edit, it does provide a better experience for many of the simple edits new users will be making at first. The new pages at least provide users with a clear choice between the editing methods, while the old pages (especially Wikipedia:Introduction) have mostly added VisualEditor as an afterthought.
  • The old pages are quite reliant on videos. Not everyone likes these as a learning method, and they are significantly harder to keep up to date with changes (the one about creating articles is from 2010!)
Since most of us commenting here are old hands and way beyond needing these kinds of introductions, perhaps we should ask for input from some actual new users on which of the pages they find more helpful? the wub "?!" 19:54, 19 February 2018 (UTC)
In writing a support, you have used almost all the same arguments I used for writing an oppose! I do hate the way that the way that sensible consensual discussion is converted into a binary edit war. So now the topic is open, I will add a few unsupported POVs to the soup, supported only by grey hair that is. There is a difference between an Introduction, Help, Tutorials, Learning materials and Marketing material- trying to do all five in the same format does not work. Taking a Support/Oppose vote to instruct writers to do so doesn't change reality.
People who have grown up with mobile phones are comfortable with that type of interface (which we need to provide for our readers) but it remains an obstacle to the keyboard generation. This applies to standard markup code keyed in with a texteditor which is familiar to anyone who has typed in his PhD or paid their way through college doing other folks typing. Visual Editor is the youngsters toy. It is a toy that every dev and coder loves- but it is too slow and it doesn't work. Older new Wikipedians spend more time hunting and pecking than being productive. It is not suitable for early work as most of that will be done on talk pages. When you are up to speed, on a fast internet connection on a fast computer (like a dev) and typing in content it has its place.
I like bitesized chunks. I agree the old pages attempt to cover too much for newbies- they were a product of their time and have dated. I have never found the need to rename a page- wikignomes do that for me (and correct my typos). I don't like comic stick figures and videos leave me cold but my grandchildren are spellbound by them (ours though are not that good) we need more not fewer but more professional in standard.
Yes to comment here you will be an old hand- but do not stereotype our newbies as being different to us. I am targetting some new potential editors- but they are all retired use pencils not phones and meetup at the archives centre under the banner of a Local History Society. People who are sent by their managers to our training sessions and editathons rarely contribute but are too polite to say why.
It would be good if a user wanted help was directed instantly to the level and type of help he needed- written in the most appropriate register of English- or at least got an instant choice on whether he was seeking an example, an introduction to the topic, a tutorial or copy for the newspaper article he was writing.
As I have said above if I can be any assistance. I don't believe that WP direction should be imposed or be the result of a binary vote- and people should have a track record in the area and have something they can offer for others to improve.ClemRutter (talk) 12:55, 20 February 2018 (UTC)
 Done removed Renaming articles and Subscript as per above from tutorial .--Moxy (talk) 16:43, 25 February 2018 (UTC)
We use the videos because data tells us people view them more then clicking to the next page ....Data. More will see the video's over click next 30 times. --Moxy (talk) 19:20, 25 February 2018 (UTC)
  • Support The new tutorial is much improved. For many users, it's much easier to start with Visual Editor for editing. The hardest part for new editors is making the first edit, which should be as easy as possible. Later on they can return to the tutorial to learn more about source editing. It seems like a great compromise and it's more focused than the general introduction. Rachel Helps (BYU) (talk) 18:31, 21 February 2018 (UTC)
  • Support per Sam Walton and Rachel Helps: the newer tutorials are much more friendly, share the right kind of information, and really focus folks on the new tools appropriate to the current editing environment. Other language wikis, have translated the Help:Introduction with success (including for example from Spanish Wikipedia for the visual editors, Sadads (talk) 22:16, 21 February 2018 (UTC)
We already use both Help:Getting started not sure why there is this plan to delete one of them.--Moxy (talk) 21:43, 25 February 2018 (UTC)
  •  Comment: I see some comments about keeping or replacing pages. On French Wikipedia, we had pages like Wikipedia:Tutorial and Wikipedia:Introduction. They were equally read. So we have decided not to merge or replace them, but to create a new simple launch page that would give choices to the user. That page is now linked from quite everywhere (sidebar, welcome messages...) as the unique starting page and has a lot of views with an acceptable ratio of people going to each pages. HTH, Trizek from fr: 08:25, 22 February 2018 (UTC)
  • Support — The visual editor is much better than the wikitext editor for most of the basic things, I still use it for minutiates. The new tutorial too, is much better for a beginner than the old ones. However, the old tutorials should still be kept in some shape or form, but as far as this RfC is concerned, they should absolutely be replaced by Help: Introduction.
    Regards, SshibumXZ (Talk) (Contributions). 21:11, 22 February 2018 (UTC)
 Done add VE stuff to all tutorial pages. --Moxy (talk) 21:43, 25 February 2018 (UTC)
  • Support but I also have some comments. Avoid deleting the old pages or even marking them as deprecated, but I do favor replacing links from the old pages with the newer tutorial. Also I think the old pages could me marked to recommend the newer tutorial. For a more complete deprecation, I would like to either see some time pass with the old ones referring to the new ones or anyone publishing a comparison of the old with the new. At a glance, the old ones look quite outdated and the new one looks quite better, but I am not seeing any description of the details or any evidence that there is not some great dependence on the old tutorial. I do trust that the team at Wikipedia:Help Project has done a good job in developing this but do not now see a reason to make an immediate switch, instead of perhaps making some changes now and proposing a full switch in 3-6 months. I am unaware of how many policy or tutorial links go anywhere, so I do not know how much of an undertaking it is to manage the traffic to tutorials. Also, I am aware of another new and up-to-date training program for which there is a lot of evidence of uptake and use at [30], described on meta at meta:Programs & Events Dashboard. I know that site is off-wiki but it is in the Wikimedia network and has advantages including tracking when a user completes the training and of being part of an interface which wiki event organizers present to 1000s of new users a year with a suggestion that they complete it. I am not saying that this off-ENWP training should replace on-ENWP resources, but probably over the past few years it has been the training with the most use and uptake, and also competes with other options for what content experienced Wiki editors present to new users. I would like to stay flexible about what wiki training means, because we have no consensus on what is best for new users. I am persuaded that we should start the wind-down process for these older tutorials. Blue Rasberry (talk) 21:59, 23 February 2018 (UTC)
We already use both Help:Getting started for new editors....this request is basically a delete request.--Moxy (talk) 21:46, 25 February 2018 (UTC)

Some comments on the points above In the interests of consensus building, I thought I should clarify what I think are some of the limitations of WP:I and WP:T. Whether WP:I and WP:T are updated or replaced, I think that these would be useful to address.

  1. Line length should be narrower to aid readability. This is optimally <75 characters, but certainly narrower than the average screen. Can be achieved through CSS max-width parameter in template. Although I'm not advocating style over substance, bits of Wikipedia can look pretty dated, and a style update may improve this corner a bit.
  2. are overused in the headings.
  3. If both Markup and VE are taught together, I think that introducing VE first in each page makes more sense for new users.
  4. The first tab of WP:I is pretty good. I think that the intro should be pitched at a reader who is considering editing but still unsure. It should therefore emphasise how Wikipedia works and
  5. The second tab of WP:I largely overlaps with the final wrap-up, and could sensibly be merged there.
  6. Similarly, the third tab of WP:I includes info on how to navigate Wikipedia, and could be left until later in the series, probably merged into the Wrapup. The final two links of "Find out more" don't need to be in a separate style (italic sentence).
  7. The final tab of WP:I redirects to the first tab of WP:T, but tab is still titled "Introduction". Content ok, but a little verbose?
  8. WP:Tutorial/Editing introduces VE briefly in the first section, then almost repeats itself in the final section. These could be merged. If both systems are presented together, there should be some info on how to switch between. It also uses "Main page:", "For more information" and "For more details" in its links to other pages.
  9. WP:Tutorial/Formatting includes how to use HTML to custom format paragraphs. This is pretty uncommon, and probably not something for a new editor. The markup toolbar is explained in detail but the VE toolbar omitted.
  10. WP:Tutorial/Wikipedia links doesn't mention VE at all in this case, but otherwise ok
  11. WP:Tutorial/Citing_sources demonstrates how to add plain references inside <ref> tags before . In reality most references are encouraged to be CS1 these days. Explaining {{Reflist}} or <references/> is also a bit unnecessary since even if they are omitted, references are still shown, and adding them is better left to wikignomes.
  12. WP:Tutorial/Talk pages is ok, though perhaps a bit long. Three-tilde and five-tilde don't really need to be explained here. Example markup is better shown side-by-side (e.g. here).
  13. WP:Tutorial/Registration is probably too long. This is already mentioned way back on the third tab of WP:I and could probably be left at that initial detail level with a link for people interested in the pros and cons.

These are only my opinions, and perhaps people will agree with some of these and not others, but I hope they can help the discussion. They can also be copied to a relevant talk page if necessary. T.Shafee(Evo&Evo)talk 12:12, 22 February 2018 (UTC)

OK I will work on these....because I don't have the time to fix the new pages. Really wish we has more experienced help people looking at this.--Moxy (talk) 22:47, 22 February 2018 (UTC)
 Done have made changes to WP:Tutorial as per above ...but not number 13 as the intro and tutorial are seen separately. The intro and tutorial are not the same..they are automated links for 2 sets of bots for different readers. .--Moxy (talk) 16:19, 25 February 2018 (UTC)
Pinging User:MKramer (WMF) and the ever-awesome User:John Broughton. Whatamidoing (WMF) (talk) 19:37, 23 February 2018 (UTC)
I'm happy to help out with updates to the wp:t series. I'll try to incorporate the sentiments and opinions voiced in this thread and try to implement what I think are some of the strengths of the help:intro series. Anyone still following this discussion: Let me know if there are any elements in the list of suggestions that I made above that you particularly disagree with! I agree that keeping it short is important, and as well as ensuring that it's mobile-friendly, and I acknowledge that those are limitations of help:intro. T.Shafee(Evo&Evo)talk 08:06, 28 February 2018 (UTC)
  • Really consider here that the proposal takes us from 7 tabs to all this . Not a good way to keep readers Why people online don’t read to the end..--Moxy (talk) 16:53, 25 February 2018 (UTC)
  • Oppose per above. Visual Editor is still not ready for prime time, in my opinion, and shouldn't be the default editor for anyone. I don't think learning wiki markup is that high of a bar for anyone. Changing up or removing the help files hardly seems worthwhile. You could always create new pages for VE and route editors according to their editor preference. Dennis Brown - 01:53, 2 March 2018 (UTC)
I don't know if I'd go so far as to call it unready for prime time. I think it's pretty functional for most new editors, especially those looking to contribute content, references and images. The only thing in the tutorial that it clearly fails on is talk page editing. T.Shafee(Evo&Evo)talk 02:30, 2 March 2018 (UTC)
For newcomers, VisualEditor is far superior to the classic wikitext editor. Its limitations are only relevant to editors trying to do more complicated things, and at least 90% of new contributors [a conservative estimate] aren't ever going to get to those complicated things. (Here's a thought experiment: use the wikitext editor to open an article with an infobox, and put yourself in the mind of someone who has never worked with raw HTML - are you going to be sufficiently intimidated to simply quit trying to edit? I'd say "clearly yes" for - again - at least 90% of those who are inclined to contribute.)
That means that when a newcomer looks for help, that help should assume that the newcomer is using VisualEditor. It's fine to provide links to relevant pages for those using the wikitext editor (hatnotes are good), but help/information pages for the wikitext editor shouldn't be the default.-- John Broughton (♫♫) 18:31, 3 March 2018 (UTC)
@John Broughton: Here is a little thought experiment:- if VisualEditor is far superior to the classic wikitext editor- get a new editor to post a message on my talk page using VE. To me that is a severe limitation that justifies saying that VE is in beta. VE is prefered by users who have come to WP through the mobile phone route- but gets in the way of the editing process (Type in a fact, type in where you found it, now tell others what you have done) for those who were computer active pre-iphone. --ClemRutter (talk) 19:44, 3 March 2018 (UTC)
I own only a car; it's not capable of hauling large packages or materials, like a truck. I'm not going to replace it with a truck just because once or twice a year I'd prefer to have a truck. Most newcomers to Wikipedia don't post to talk pages, whether they edit with VE or the wikitext editor; in fact, most experienced editors don't post to article talk pages very often. So no, I don't support newcomers using a difficult-to-learn UI for most of their work because it avoids their having to use a different UI for occasional posting. (And, to be blunt, it's not that difficult to learn how to post to a talk page: click "New section", type, add four tildes, add an explanation, save. And yes, inserting a comment into an existing section is a little more difficult, but so is understanding the right way to use a talk page.) -- John Broughton (♫♫) 21:01, 3 March 2018 (UTC)
What is more serious is the changing UI, that prevents us from writing tutorials and documentation. VE needs to become stable. --ClemRutter (talk) 19:44, 3 March 2018 (UTC)
VE is stable. It can't currently be used to edit pages in the Talk or Wikipedia namespaces (but it works for Help namespace pages). It's too bad that more of the experienced editors of Wikipedia don't use VE for editing articles - it's faster and easier, though there is a small amount of learning for the new UI; so yes, there aren't enough people who know VE well enough to write and update tutorials and documentation, though I'm sure I could point to lots of tutorials and documentation involving the wikitext editor which are seriously out of date. -- John Broughton (♫♫) 21:01, 3 March 2018 (UTC)
  • Support using it just the other day to improve an article, it struck me how much visual editor had improved, and there was only one small issue that forced me to use the wikitext editor when moving sections of text about. The new proposed pages are a lot more user friendly and simpler, which is better. jcc (tea and biscuits) 14:10, 11 March 2018 (UTC)

A Bot for Creating Arthropod Stubs, Trial

There is consensus to implement this. Some of the conditional supports would like to see the bot without auto patrolled which is part of the bot permission. There are other conditional supports which would like to see the bot throttled. Since there's a good amount of unconditional supports, the bot should start slow and work up in speed as it runs, to ensure that the stubs are not full of errors.—CYBERPOWER (Chat) 15:54, 12 March 2018 (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.

The bot to make stub articles for arthropod species is coming along. It even has a name: Qbugbot. I've made a couple of thousand stub articles and manually posted them. Thanks for all the suggestions and edits! The articles now include Speciesbox and Automatic Taxobox, CS1 citation templates, and a taxonbar.

The first online trial was done today for the BRFA, creating and uploading the twenty random articles below. Everything worked fine, except for a minor bug that has been fixed (talk pages were blank for pages with images). Comments, questions, suggestions, and criticisms are welcome.

Bob Webster (talk) 03:22, 26 February 2018 (UTC)
Note: please see the original VPP discussion (now archived) for background.   ~ Tom.Reding (talkdgaf)  04:33, 26 February 2018 (UTC)
The bug in the template on the talk page can easily be eliminated if "needs-image=yes" is replaced by "needs-photo=yes". JoJan (talk) 15:38, 26 February 2018 (UTC)
JoJan, is this the correct location for your post? Feel free to remove this (my cmt) if so.   ~ Tom.Reding (talkdgaf)  14:58, 27 February 2018 (UTC)
  • Strongest possible oppose No, we should not become like the Cebuano Wikipedia and allow a bot to create up to 15,000 new articles. That is to be blunt, absolutely crazy and will prove next to impossible to quality control. We either grant the bot autopatrolled, which means that it doesn't flood the new pages feed, but means that there is no one reviewing the articles to see if there are issues that can be caused by an automated process (which will exists), or we don't grant it autopatrolled, meaning the new pages feed is flooded with new articles, and articles that might be much more problematic can't be found quickly because of these stubs. I also hate the precedent that this would set for bots to create other types of articles, maybe about living people (I'm sure you could write code for footballers or other sports people?). That the trial went well does not impact the major disruption that 15,000 bot created articles could cause to the English Wikipedia. As I'm saying in my edit summary, under no circumstances should this BFRA be approved. TonyBallioni (talk) 03:32, 26 February 2018 (UTC)
  • Conditional support Look, I can't support granting the bot autopatrolled (which is unnacceptable without explicit community approval, which I have not seen), and I also cannot countenance flooding the newpage feed with new arthropod stubs (NPP is struggling as it is). However, this bot is capable of creating quite good stub articles and I do want to find a way of accommodating them into the wiki if possible. At the moment I would say that the maximum number that NPP could deal with would be about 50 of these stubs a day. This would slowly release the stubs over almost a year or so, which is reasonable. Logistically it would be better if all the 50 articles for each day were posted at the same time (i.e. in one large block). If they don't have major issues, this should make patrolling them relatively trivial. Spacing them out evenly over the day would be bad, as it wouldn't make it as easy for a reviewer to get 'in the zone' of reviewing a particular type of article (which speeds things up a lot). Edibobb You have to coordinate with new page patrol on this as we are the group of editors impacted the most. So far you have managed to get on Tony's bad side by pushing ahead with this without reaching out to us. I'd suggest changing your approach by asking for suggestions at WT:NPR before moving ahead with anything else. My support is conditional on this bot project working closely with NPP, otherwise I am firmly in TonyBallioni's camp. — Insertcleverphrasehere (or here) 04:16, 26 February 2018 (UTC)
  • 50 a day would also be overwhelming. Mass articles about sports teams seasons or elections by years or villages in remote parts of the Middle East also flood the feed on occasion, and make it difficult to deal with, but at least those are done by people who we can eventually grant the autopatrolled flag to because we don't have to worry about some glitch creating a completely malformed article that no one will ever see (and even if they did, they would immediately recognize and fix it). Those also usually stop after a week or so, and are typically done 10-20 at a time, not 50 at a time. I know we have had automated creations in the past, but have we ever had anything on the scale of 15,000 stubs created by a bot that will eventually have no human review as to it's output (and from the proposal I see at BRFA, the suggestion is that the operator will review at least one article a day to make sure the bot isn't messing up, which is nothing).
    In terms of getting on my bad side, I don't mind not being reached out to, I just honestly find this idea terrifying as to the future implications it could have for Wikipedia. This could easily be replicated for BLPs as I mentioned above, and there are likely almost as many notable living footballers out there as there are bugs. This is a slippery slope argument, I'm aware, but I don't think people have a problem imagining how that could turn into a disaster fast. We have less risk with these stubs, but we're currently living in an environment re: bots where people get mad about a bot making whitespace edits because it shows up on a watchlist.
    That's just an annoyance thing. Do we really want to think about the large scale disruption and damage to the reputation of Wikipedia that could happen if somehow the bot started messing up the articles and they hit Google without someone catching them? Look at KolbertBot for a good bot that serves a much needed purpose to see how many people are mad about a bot that just changes http to https in links. An article creation bot could do so much more damage and would be likely to create articles that would never be expanded. I know I'm getting into tl;dr mode here, but the sheer potential for disruption here is huge on many different fronts. TonyBallioni (talk) 04:36, 26 February 2018 (UTC)
  • As far as whether this has happened before - this reminds me of User:ProteinBoxBot which created 10,000 or more gene stubs several years back (and appears to still be running). I'm sure the folks who run that bot would be happy to advise, both on technical issues they've encountered and on outreach issues with various editor groups they've encountered. Ajpolino (talk) 06:28, 26 February 2018 (UTC)
  • Thanks for that, much appreciated. It currently at a rate of a less than 10 on any given day that it runs. I would be fine with a bot that created 5-10 articles a day, max, which is what the protein bot seems to be doing now (though it used to create hundreds a day). I have no confidence in the ability to maintain the 2-4 volunteers mentioned below to review even 50 articles a day.
    I suspect this goes one of two ways: it either creates inordinate amounts of disruption that requires the bot to be blocked and not unblocked at some point, or it creates a major mess that no one wants to clean up so everyone just ignores because no one really visits one line bug stubs, and we already have backlogs in the six figures in article space, so no reason to focus on these (mostly high quality), stubs. I don't see either as being good for Wikipedia. TonyBallioni (talk) 06:45, 26 February 2018 (UTC)
  • Continued support for the creation of a large number of high quality stubs. I don't see that the quality checking issue is anything to flip out over. We certainly want to avoid the two cases of a) either flooding NPP, or b) having a huge number of auto-patrolled stubs come in which have only been spot-checked. But a limited number of articles per day is perfectly realistic to deal with; specifically since it will amount to format and consistency verification only (no notability, COI, or copyright issues with these...). I'm positive that, for example, 50 articles a day could be handled without the least problem by 2-4 interested people who commit to checking these daily (for which I do volunteer). A committed small task force could be combined with auto-patrolled status so that the stubs don't add to the NPP lists. - As for axing a promising idea because it sets a "bad precedent", that way lays stagnation. Bug Stub Creation is not a suicide pact. --Elmidae (talk · contribs) 06:13, 26 February 2018 (UTC)
One technical comment: how much "Further reading" is desirable? Nothing inherently wrong with having lots of general bug books suggested for the reader's further perusal, it's just that I have rarely seen such large reading lists as in Kuschelina jacobiana in anything but particularly well-developed full-length articles. Actually, when encountering this in a random stub, I would assume indiscriminatory ref spamming, and trim it down (not that that's a suspicion here :). Is there a suggested limit to the length of that section? --Elmidae (talk · contribs) 06:15, 26 February 2018 (UTC)
I agree, there's a bit too much further reading in some pages, especially some of the Beetles. I did cut it a little, but it needs more reduction. I'll weed out some of the less important references.
I would also volunteer for stub verification, and I see no problem with a limit of 50 per day.
Bob Webster (talk) 07:01, 26 February 2018 (UTC)
Strong support at a reasonable pace. עוד מישהו Od Mishehu 08:34, 26 February 2018 (UTC)
  • If this bot is implemented, it needs an addition, or a companion bot, to create incoming redirects from common names (sometimes several per article). I see that there is now a redirect from Virgata toothpick grasshopper to Paropomala virgata, but it should have been created at the same time as the target stub (it's the common name, bolded in the stub). I also see that the same editor (@William Avery:) who added the necessary redirect also added Category:Insects described in 1899, which presumably could have been created automatically by using the date in the source in the infobox. If this bot is going to go ahead it needs to be as good as it can be - checking the edits made to all those 20 articles might be a useful source of enhancements to consider. PamD 08:46, 26 February 2018 (UTC)
  • Strong Oppose mass creation of bug stubs by a brainless bot is as bad as mass creation of sports bio stubs by human editors that don't use their brains. We already can't handle the normal creations at NPP. How about bot creating these into Draft space at a reasonable rate and then once a qualified human has checked them the human moves them to mainspace. By qualified human I mean someone who understands the topic and has NPP and pagemover flags to both approve the page and remove the redirect in Draft space. That way disinterested reviewers never see these pages in the feed. There is no good reason to saddle NPP generalist with Thousands of bot created bug pages. They will quit! Legacypac (talk) 08:57, 26 February 2018 (UTC)
I mean if it is approved the pages will obviously be autopatrolled Galobtter (pingó mió) 09:05, 26 February 2018 (UTC)
Legacypac, would you please read at least some of the preceeding material regarding NPP/autopatrolled etc. in this and the previous discussion? People are well aware of that issue, and no one is proposing bombing the NPP queues. --Elmidae (talk · contribs) 09:17, 26 February 2018 (UTC)
I read all the discussion and thought through the issues before posting. Sorry you think so poorly of me. I'm pretty familiar with NPP, AfC, Draft management, and dealing with mass created pages (I handled more Neelix creations than any other editor), and I've done huge cleanup in Draft and Userspace. I oppose putting these directly in mainspace without a qualified human checking them. I oppose any plan that puts thousands of bug stubs anywhere the NPP feed. I offer a constructive suggestion that allows the bot to run and satisfies the concerns I and others have. Perhaps a bot could even do batches of page moves after a human checks the batch? What is wrong with running them by a real human's eyes for a quick check? Legacypac (talk) 09:28, 26 February 2018 (UTC)
Also 15000 pages at 10 a day is over 4 years worth that NPP will need to deal with. Legacypac (talk) 09:34, 26 February 2018 (UTC)
Okay, sorry if that came off as thinking poorly of you (I certainly don't). Your comments seemed to start from a position of "this bot will dump 15k stubs into NPP", which I hope no one is advocating - multiple editors have identified that as insupportable. - Creating stubs into draft space at a certain rate and human-checking them before moving sounds good; indeed I wanted to suggest that as an alternative to "autopatrolled + task team", but didn't want to muddy the waters too much. --Elmidae (talk · contribs) 09:52, 26 February 2018 (UTC)
Many sportspeople are non-notable, which us the reason we don't want mass creation of sports bio stubs by human editors that don't use their brains; on the other hand, according to Wikipedia:Articles for deletion/Common outcomes, All species that have a correct name (botany) or valid name (zoology) are inherently notable. Their names and at least a brief description must have been published in a reliable academic publication to be recognized as correct or valid. This means that the bot's output is articles which are inherently notable, while the mindless humans would be outputting articles most of which are on non-notable topics. עוד מישהו Od Mishehu 12:45, 26 February 2018 (UTC)
Every footballer who has ever set foot in a fully professional league is notable. The slippery slope argument here is not nonsense, despite what has been claimed by a BAG member. This process could easily be replicated for the footballer stubs we see if someone wanted to. We need a reasonable review process for this, just as we would for the footballer scenario. BLPs are much more delicate, but any article not created by a human needs human review. TonyBallioni (talk) 13:41, 26 February 2018 (UTC)
  • Support Articles appear to be of reasonably good quality for stubs. Darylgolden(talk) Ping when replying 11:33, 26 February 2018 (UTC)
  • BAG note: The slippery slope 'Footballer's BLP stubs' argument is nonsense. Any bot that wants to create articles on a large scale needs to follow WP:MASSCREATION. If you oppose a bot creating BLP stubs on footballers, then oppose that bot, don't transfer your opposition to a bot that creates non-BLPs stubs about species of bugs. Headbomb {t · c · p · b} 11:36, 26 February 2018 (UTC)
  • Strong support Issues are taken care of. Agathoclea (talk) 12:04, 26 February 2018 (UTC)
  • Conditional support as long as throttling controls are in place to not overwhelm quality control processes, I'm fine with allowing an automated process to handle these. --Jayron32 12:50, 26 February 2018 (UTC)
  • Support Legacypac’s alternative I would support Legacypac’s alternative of allowing the bot to create these in draft space as an alternative to the suggested 50/day+task force model, which I think would not be sustainable in the long run (the bot will keep running, but people will stop reviewing, and the task force will review far less than 50 a day even at the beginning when no one has burned out.)
    @Elmidae and Edibobb: does a throttled draftspace bot make any sense to you all? This also has the advantage over autopatrolled because we could grant the bot/reviewers autopatrolled or NPR do these don’t overwhelm the feed. Granting autopatrolled for mainspace would be a concern as it would instantly Google index these without human review. Granting it for drafts would not have this concern. TonyBallioni (talk) 13:41, 26 February 2018 (UTC)
Seems workable; provided I understand from the above (not quite clear to me) that there is a way to shortcut the process of "check + move + review" by chopping off the review bit, or rather the ending-up-in-NPP-queue bit. I actually don't know whether moving out of draft space un-reviews - if so, then that could not be solved by just AP'ing the bot, and it would have to be AP for the reviewers? --Elmidae (talk · contribs) 14:05, 26 February 2018 (UTC)
Moving out of draftspace to mainspace adds it to the feed, but I'm not clear on the details as to if it is the status of the creator or the reviewer that marks it unpatrolled (Xaosflux might know sorry for the ping it's one of the few technical areas of NPP that I'm unsure of). Either way, it's easy to sort out. The software does not prevent a reviewer from marking something they have moved to mainspace as reviewed, so worse case scenario, we just give the NPR flag, and they manually mark as reviewed in mainspace. It'll be easy to do once we figure out exactly what marks something coming from draft as unreviewed. TonyBallioni (talk) 14:11, 26 February 2018 (UTC)
Elmidae see this thread on my talk by Xaosflux. All we'd have to do in this scenario would be to grant the reviewers autopatrolled (which if they are experienced editors who are working on this project, I'm sure we would). Also (as I just learned all bots get autopatrolled, which I Was not aware until talking with him), I really think the draft space plan is the way to go here: it is the only way that will ensure human review of the articles before they are indexed. TonyBallioni (talk) 15:04, 26 February 2018 (UTC)
I think a throttled draftspace would make some people more comfortable with this project. As you point out, it would definitely reduce the impact of any mistakes generated by the bot. A consideration is the human time involved moving articles from draftspace to mainspace. One way to do this efficiently is for the bot to periodically move any articles that have been human-verified from draftspace to mainspace. If the bot has autopatrol status, all would be finished when the article is moved. This would not impact the NPP queue, but would still require each article to be checked by a human. Bob Webster (talk) 15:49, 26 February 2018 (UTC)
Thanks Tony; that does indeed sound promising. Bob, as for the effort involved in moving: it's like three clicks, I think, possibly less if by Twinkle or similar - I doubt there would be any big savings in having some kind of alternative "verify" mechanism (which would also require some kind of logging action on part of the reviewer, presumably more complex) followed by bot move. Or so I assume. --Elmidae (talk · contribs) 16:36, 26 February 2018 (UTC)
@Elmidae and TonyBallioni: Yes. I had also forgotten about the bots having a-pat status. The "bot > draftspace - a-pat reviewr > mainspace" seems to be our best option yet. But I wonder how many of our editors are familiar with bugs. I have rudimentary knowledge of entomology (it was me who nominate Bob for A-PAT), the only reason I dont study/read entomology is that most of the photos give me heebie-jeebies. Face-grin.svg To the point: we need volunteers who could be trusted with A-PAT, and are willing to perform this reviewing/moving thing. —usernamekiran(talk) 00:21, 27 February 2018 (UTC)
I don't think that draft space is a good idea. It will be more work to move them from draft than to simply have the bot slowly drop 30-50 of them in the New page feed each day (non-autopatrolled). There is WP:NODEADLINE to how fast the bot needs to create them all (it doesn't matter if it takes a year or two to get them all into mainspace), and perhaps in a few months if the bot becomes polished enough that no errors are found, we could give it autopatrolled. — Insertcleverphrasehere (or here) 00:13, 7 March 2018 (UTC)
  • Conditionally support Every species is notable and deserves its own article. The stub articles created by this bot have a certain quality and should be accepted in NPPP. However their large number creates an understandable problem for NPP. The solution is to find a way to accept them as autopatrolled AND keep them from appearing in the New Pages. There is however another problem that hasn't been raised yet: the taxonomy in every branch of the Tree of Life is changing rapidly: new species are discovered all the time and also many species become synonyms. These changes happen in such a fast succession, that it is almost impossible for anyone to keep up. Therefore this bot actually needs a second bot to list all these changes in a list that the collaborators, working on the beetles and other families, can use to redirect the existing articles of species to their new names. This way, the bot-created articles can remain up-to-date. JoJan (talk) 16:09, 26 February 2018 (UTC)
  • Conditionally support The blocker on this seems to be getting them patrolled. Is there a way to tag those which are patrolled, and throttling the bot to allow only a limited number of unpatrolled articles?, maybe 50 unpatrolled stops the bot, and it starts again when the number drops below 40. That way there can be as many created as the patrollers choose to check, and if they stop, so does creation of articles until they start again. There would never be more than a specified number of unpatrolled articles.
  • I would also request that the bot creates Wikipedia:Short description for all articles too, as they will need them, and this should be a trivial addition, · · · Peter (Southwood) (talk): 18:40, 26 February 2018 (UTC)
  • @Pbsouthwood: "bots" include the autopatrol permission, all pages created by bots are already patrolled. — xaosflux Talk 19:35, 26 February 2018 (UTC)
  • Perhaps I used the wrong terminology. There seems to be a concern that the articles should be checked by a human editor, which is what I was trying to express. A template identifying the article as human-verified with default as not verified (F) could do this. By using an F or T it would be very quick to verify after checking, and could bypass the NPP completely. I am in favour of stubs for all species, as there have been many occasions that I would have added a bit to an existing article, but did not have the time or inclination to create the article first.
  • JoJan also makes a good point about names changing and using a bot to keep them updated. · · · Peter (Southwood) (talk): 19:49, 26 February 2018 (UTC)
  • Support I think this is fine; I followed the earlier VPP discussion and am satisfied by the quality of the articles. I am of the belief that stubs will eventually get expanded. I find the comparison with the Cebuano Wikipedia to be disingenuous; 95% of their articles are autogenerated stubs on living organisms, I don't believe this trial is aiming to make 95% of our articles Arthropod stubs. jcc (tea and biscuits) 18:47, 26 February 2018 (UTC)

So if the autopatroled bot creates the page in mainspace it does not hit the NPP list and we have no way to know if a human looked at it and it will be immediately indexed? Too scary. If the autopatroled bot creats in Draft and an autopatrolled human moves it to mainspace we know a human checked it and its indexed only on move to mainspace. Much better. Moves are easy - not harder thsn reviewing the pages and somehow recording that page is human reviewed. Legacypac (talk) 19:47, 26 February 2018 (UTC)

@Legacypac: it only marks it as patrolled, it does not hide it from the feed - now yes, most people don't re-review patrolled new pages, but they could if they wanted to. An example of another bot that is creating new pages directly as articles is User:ProteinBoxBot (see Its created pages). — xaosflux Talk 20:03, 26 February 2018 (UTC)
  • Support - I think the examples are more than stubs (though labeling them as stubs will push them towards expansion). I sympathize with the page patrollers getting overworked. perhaps the page creations by the bot can be throttled to an acceptable level? or can there be a 'semi-patrolled' status set up so these articles take a lower priority from the standard page creations, but aren't completely autopatrolled? Nessie (talk) 20:35, 26 February 2018 (UTC)
  •  Comment: I think NPP/R folks should be given a little time (at least 72 hours) to discuss this issue before the bot is given a green signal. The community should wait for a official statement from NPP/R, as they are the (only?) ones who are working with deadlines related to external search engines. This incident would impact on their activity directly, as it is their task to make sure if an article is good enough for mainspace. On a completely different note: a lot of photos from entemology give me heebie-jeebies. —usernamekiran(talk) 00:05, 27 February 2018 (UTC)
  • Continued conditional support - Bob Webster, I had to perform author enumeration on 12/20 (60%) of the test articles (1 2 3 4 5 6 7 8 9 10 11 12). Also worth noting that on my 12th edit, I noticed |author8=Prendini, L., Ra, which seems like it chopped off the next author name? Can you incorporate these changes (not just with these authors, but all potential sources)? I recall you linked me to your 'master reference list' of sorts - would it help if I corrected that?   ~ Tom.Reding (talkdgaf)  14:54, 27 February 2018 (UTC)
Thanks for pointing that out. I'll take care of that, hopefully today. There are currently 162 out of 2000+ references without enumerated authors. These are the ones that got kicked out of the conversion from freeform for inconsistent or ambiguous format. I guess if you average 8-10 references per article, one of these should show up in the neighborhood of 60% of the time. I'll also do some validity checking to find incorrect names. These are all in a database, so it probably wouldn't be worthwhile to edit the list I put online. Bob Webster (talk) 15:32, 27 February 2018 (UTC)
  • Oppose mass creation outside of draftspace - To me creating these as drafts and having a human move them over makes the most sense - there are no articles that have not had a human touch them finding their way to Google, a quality control check is being done by people who presumably would notice if something is off with the content, and assuming the moves were done by someone with Autopatrolled, NPP would not be flooded. From a human factors point of view there would be no throttling required as the moves to mainspace could happen at whatever rate the people working on it wished to go. PGWG (talk) 19:15, 27 February 2018 (UTC)
  • Support running the bot and giving it the autopatrolled flag. This is a sensible use of a bot and I think the stubs it creates will be a net improvement to the encyclopaedia. I understand the concerns of my fellow new page patrollers, but I'm willing to trust the bot operator to do their own quality control, as outlined in their earlier village pump proposal. If it screws up, the bot can presumably mass-fix or mass-delete the articles just as easily as it created them. – Joe (talk) 09:39, 28 February 2018 (UTC)
  • Conditional support My gut feeling was 'no way', but as long as the bot is throttled and/or puts it in draft space. !dave 13:02, 28 February 2018 (UTC)
  • Strong support would be great improvement to Wikipedia. As an Inclusionist, I believe stubs are better than nothing, and that over time they will be improved. Whoever searches these articles will be happy to find something, even a stub. I also suppot giving the bot the autopatrolled flag. L293D () 15:18, 28 February 2018 (UTC)
  • Strong support: I see no problem with the created content, let's get coverage of these missing subjects. The concerns about crappy stub mass creation are overblown--this is clearly good work. FACE WITH TEARS OF JOY [u+1F602] 15:46, 28 February 2018 (UTC)
  •  Administrator note: All bots are already "autopatrolled" - it is built in to their access bundle. If these pages are created in (Main/Article) the pages will already be "patrolled" - if it is created in Draft it will also already be patrolled. When a page is moved from Draft to Main its patrol status as an article is inherited from the person who moves it. — xaosflux Talk 16:26, 28 February 2018 (UTC)
  • Support the bug bot, provided it takes it nice and slow. My spidey NPP senses say it will be alright L3X1 ◊distænt write◊ 20:43, 28 February 2018 (UTC)
  • Support I don't see any problem with these articles, and concerns about flooding Wikipedia with bot-created articles are overblown given the sheer number of articles we have already. It doesn't make any sense not to give it the autopatrolled flag, that would only waste NPP time and unlike humans we do have a reasonable guarantee that the bot won't create anything inappropriate. Hut 8.5 21:34, 28 February 2018 (UTC)
  • Support I don't quite understand the argument against auto-patrolled, but I think that NPP could handle 50-100 of these per day. It can't be worse than the stream of articles on football players we already get. There's no dispute regarding their notability, and most of the difficult cases in NPP involve assessing notability. power~enwiki (π, ν) 22:30, 28 February 2018 (UTC)
  • User:Edibobb This is really cool! How are the further reading lists generated? (Thinking about copyright issues here...) Thanks, Calliopejen1 (talk) 23:23, 28 February 2018 (UTC)
There is a big list of citations, and a few of these are applied to each article based on the scientific name of the bug. For example, Cerotainiops abdominalis is a robber fly, so the article "Robber flies of the world" is used for that (and other robber flies). The list of citations came from a number of sources such as ITIS, Google Scholar, Zookeys, and Bob Webster (talk) 23:47, 28 February 2018 (UTC)
  • Support including autopatrolled. These stubs seem like an excellent addition to the encyclopedia, and IMO it is better to build standardized scaffolding for human editors to build on. Assuming this process occurs at a reasonable rate that allows for human spot-checking, these articles seem significantly less likely to contain errors than stubs created by human editors. Calliopejen1 (talk) 00:08, 1 March 2018 (UTC)
  • Support. The proposer appears to be handling this very carefully, has discussed the proposal widely with subject-matter specialists, is very responsive to feedback, and has provided high-quality examples. We should be going beyond the knee-jerk reaction 'all bot-created articles are by definition bad', and encouraging well-thought-out projects of this type. MichaelMaggs (talk) 13:08, 1 March 2018 (UTC)
  • Support creating these directly in the mainspace. I oppose dumping them in draftspace, and double-extra-oppose putting them there for the purpose of protecting the NPPers at the direct expense of the already-struggling AFC folks. We do not serve our mission by hiding decent content in the draftspace, and we do not help the community by letting one group of volunteers shift work onto another group of volunteers. These should be auto-patrolled when created, because all of them already pass the NPP threshold: they are 100% about notable subjects, they do not qualify for any form of deletion, speedy or otherwise. Sure, it'd be nice to glance at them to make sure that there isn't a stray typo mangling the wikitext formatting, but (a) that's what normal editing is for, and (b) there is no reason for this to end up in anybody's backlog. WhatamIdoing (talk) 04:41, 2 March 2018 (UTC)
    @WhatamIdoing: I don't think anyone is suggesting that they be submitted to AfC. If they're created in draftspace, the idea is that Edibobb and/or other editors interested in this subject check and move them themselves. – Joe (talk) 13:31, 2 March 2018 (UTC)
    ...which they could do if the articles were created directly in mainspace, too, with the added advantage that no "disinterested" volunteers (the people proposing this approach have specified that only "disinterested" editors with both multiple advanced user rights and knowledge of the subject matter should be able review these articles and move them to the mainspace) would risk carpal tunnel problems from manually moving thousands of articles.
    BTW, I believe that if you check, you'll see that very little leaves draftspace without the involvement of AFC folks. The idea that there are a bunch of volunteers who regularly check the draftspace for promising articles is a myth. The research shows that draftspace is where articles go to die: fewer readers, fewer editors, less attention, and fewer improvements. WhatamIdoing (talk) 23:52, 2 March 2018 (UTC)
    Let's be clear about what is being recommended here. Even if we actually find this hypothetical volunteer – someone who is simultaneously disinterested but still well-informed, and who has the specified combination of user rights – we are talking about an enormous amount of tedious work. If that volunteer only spends a mere 10 seconds to both review and move each article, we're talking about asking this person to spend more than 40 hours of very tedious work. The alleged payoff is that there might be some problem that a person whose brain is fried by hours of tedious work might catch, and which normal editing somehow wouldn't catch (or wouldn't catch as quickly). I think that everything we know about occupational psychology tells us that our hypothetical volunteer won't catch any such hypothetical errors (but who will probably accidentally introduce the occasional typo into the article titles or click the wrong namespace; humans do that kind of thing), and everything we know from looking at the sample articles indicates that every single one of them will instantly meet all of the criteria for being moved out of draftspace (the criteria are all about deletion-worthiness), including any that, by some unfortunate chance, happen to contain a problem. So from where I sit, this is more than 40 hours of pointless make-work for no discernible benefit and with no realistic chance of actually improving the articles. WhatamIdoing (talk) 01:07, 3 March 2018 (UTC)
    @WhatamIdoing: Unless somebody puts an AfC template on the drafts, AfC will have nothing to do with this, full stop. I'm also in favour of putting these straight into mainspace as autopatrolled, but if the consensus is that a manual review is required, creating them in draftspace at least makes those reviews an optional task with no time limit, rather than adding to a critical project backlog (NPP). – Joe (talk) 20:00, 3 March 2018 (UTC)
    I am confident that NPPers would figure out very quickly how to ignore these, or that they would just start clicking the patrol button to dump them back out of their collective queue (which is much faster than making someone WP:MOVE the page out of draftspace). I agree that there is no need for NPP to be involved, as we already know that none of the articles will meet NPP's core requirements (=delete-able, especially speedy delete-able). Draftspace means that average readers can't find the pages – unless and until some dedicated person manually changes its status. Dumping the articles in the NPP queue means that their numbers will artificially increase (as will the percentage of good articles that they see), but after 90 days, it has no effect at all, except to keep them listed in the NPP queue. So for me, the question is: How do we get this bit of the "the sum of all human knowledge" actually "available to every person in the world", e.g., a student who's supposed to write a paper for school? The answer to my question is not "dump it in draftspace until someone volunteers to spend days and days and days manually moving them back out". WhatamIdoing (talk) 22:21, 4 March 2018 (UTC)
  • Neutral Support: I don't care if its humans, bots, or monkeys on typewriters that create articles as long as the topics are notable and core content policies are followed. But since we are dealing with a bot and not monkeys, we are able to program it to produce the best possible result, every time. I have observed the following shortcomings:
  1. General references: some of these include sources in the reference section that are not footnoted, so it remains entirely ambigious as to what (if anything) they support in the article. (e.g. Acmaeodera decipiens)
  2. Unreferenced infobox fields: out of the infobox fields, synonyms and status have parameters for references (see template doc). These are intended to be used (high quality taxa articles do), so why isn't that the case here? (e.g. Acmaeodera decipiens, Cannaphila insularis)
  3. The Species, Subspecies, and Genera sections: I think you should include all the relevant information you have in these sections, and not just in the lead. This contributes towards an actual article body/lead distinction and lets you have references where they should be. (e.g. Cerotainiops, see suggestion)
  4. Images: I suppose there is no way of guaranteeing that the images added by the bot are actually variable enough to add anything of use. I notice some missing captions though. Perhaps make the bot repeat the article title if all else fails. (e.g. Amblytylus nasutus)
  5. Box-type Commons templates should be "at the beginning of the last section of the article [...] so that boxes will appear next to, rather than below, the list items". Yours are neither. Because these articles tend to have long infoboxes, you could place the Commons template in the External links section and use the inline version, as recommended by the linked guideline. (e.g. Acmaeodera decipiens)
Bob Webster, can you look into these issues and I might switch to support. By the way, I think you have done an incredible job with responding to questions and suggestions. I think, thanks to your effort, this bot has more "brains" than some human (monkey?) stub-creators that I have been unable to communicate with. Cheers. – Finnusertop (talkcontribs) 17:32, 2 March 2018 (UTC)
I'm not convinced that including captions that repeat the title of the article is worthwhile. Template:Taxobox#Images says "A caption need not be provided if it would just repeat the title of the article." In organisms without a common name, the binomial already shows up at the top of the infobox, in abbreviated form in the species line, and again in the binomial line. Plantdrew (talk) 20:00, 2 March 2018 (UTC)
On point #1, Wikipedia:General references are not banned, nor even discouraged (especially for very short articles), so that's not actually a problem. WhatamIdoing (talk) 01:17, 3 March 2018 (UTC)
Thanks for the good suggestions. These have now been implemented, number 4 partially. See Nitidulinae, Paragnetina, Tabanus americanus. There will be a photo caption if the bug has a common name (except in the infobox), and a photo caption on all photos in genus or higher pages. Number 1 was already done. Even though general references are allowed, two or three people had recommended getting rid of them so I moved them to Further Reading. Bob Webster (talk) 07:11, 3 March 2018 (UTC)
Great, Bob Webster, I'm very happy to support this bot. I think we are very close to the best result we can get from an article creation bot of this kind. – Finnusertop (talkcontribs) 16:29, 3 March 2018 (UTC)
  • Support - actually a very cool concept. Let's make it happen. Swarm 12:23, 3 March 2018 (UTC)
  • Support As long as the bot paces itself, this seems like a worthwhile project to fill in gaps in our content. I don't think NPP is going to get flooded by 50-100 more articles a day, especially since these are likely going to be easy articles to review. TheCatalyst31 ReactionCreation 17:33, 4 March 2018 (UTC)
  • Support giving the bot autopatrolled, and allowing the bot to create it's ~15,000 pages directly into mainspace without throttling for NPP. In the unlikely case that the bot's articles have widespread errors, the articles can be mass deleted/fixed, and we can try again. As a second choice, have the bot create into draft space without throttling, spot check a high percentage of the articles manually (~10% selected randomly should be sufficient and doable), and then batch move them all into mainspace. Oppose throttling the bot anywhere near as severely as suggested above, which will stretch out this process to many months. Oppose any solution that would dump these pages into the NPP queue unreviewed - pulling a generalist reviewer out of the NPP queue to review one of these is not the best outcome for the article (where the reviewer might not know what he's looking at) or the reviewer (whose talents are better served looking for vandalism, copyvios, and UPE) Tazerdadog (talk) 07:55, 6 March 2018 (UTC)
  • Conditional Support These stubs are far better than some manually created ones I've seen going through WP:NPP, and it's great to see synonyms included. I really like the approach being taken. My comments on this matter are as follows:
  1. I see no comparison between new stub pages on 15,000 different species being created from rigorously created and authoritative checklists/databases and the objections over BLP sportmen and the like. Two utterly different things; the latter relates to notable or non-notable individual creatures within a single species.
  2. Rather than flood NPP or releasing all in one go, I'd be happy to see batches published (c.100 to 500 per week at first) to allow time for sampling and reporting back on any issue. I only think that sampling a few at regular intervals in the release would be necessary. Happy to help with that.
  3. Photos: I'm not at all happy to see 'photo needed' on every stub. Because many taxa are hard to identify, and because there's b*gger-all quality checking of images uploaded to commons, this is just inviting trouble. (Even the page for Paropomala captions an image of Paropomala wyomingensis uploaded by the bot creator, but flagged as only having 88% confidence in identification. Kudos, though, for declaring uncertainty.) Let other editors add 'image needed' manually. All pages without a photo obviously need a photo - it's self-evident. Templating to this effect should be an assessment made by a competent hominid.
  4. References. I don't like seeing the very first citation being to a community-developed website (BugGuides). The existence of the taxon should be proven with a reliable link to an established, authoritative source. (The equivalent of IPNI in the plant world, or GBIF). So I propose you move the ITIS link first, and most definitely not start with one whose homepage says: We are an online community of naturalists who enjoy learning about and sharing our observations of insects, spiders, and other related creatures. That doesn't instil me with as much confidence as a definitive checklist proving the taxon name is valid, current and really exists.
  5. The sample batch listed above still have too many 'further reading' entries. Unless each species is actually figured in these works, I would be concerned at the inclusion of most or all of them.
  6. There's nothing to clearly show each stub article is bot-generated in the sample above. I assume the bot will have its own name. But I suggest a Talk page entry is added on each new page, summarising or linking back to information on the automated origin of the article, all metadatasets accessed, links to these project discussion, and especially inviting content concerns to be reported back. Because I assume habitat, range and description are beyond the abilities of the bot to insert, these are three headings that editors could be explicitly invited to add manually.
  7. Categories: Would a new Category that puts these bot-created pages all together be of use in the early stages of roll-out? Rather than having to browse the bot's history pages, a category listing would allow any concerned citizens to collectively view these pages, be it alphabetically or by Order. I agree with PamD on the merits of automatically adding categories for the year of publication (naming).
  8. Range: Are all the new pages only for taxa exclusively found in North America? If not, what steps have been taken to ensure that any distributional data that goes in relating to N America doesn't accidentally imply a purely N American range by the omission of other world regions?  
  9. English names - how are these derived? Over the last 25 years I've witnessed in the UK this awful desire to giving the obscurest taxon a so called 'common' name, whether it has or deserves one or not. Field guides to various arthropod groups and fungi have been published here in which the author has been required to make up so-called 'common' names. A link to a reliable source (which can subsequently be challenged, if needs be) to show where that name has derived from might be valuable. So I am a little concerned about seeing redirects from English names unless they really are genuinely valid and in common use.
  10. There are now only 16,999 pages that need working on. I've added what I could find online to the first one in the demo list above. Is there a new batch of pages we can now review with all the above recommendations incorporated? Nick Moyes (talk) 16:38, 10 March 2018 (UTC)
    1. I agree.
    2. That should be no problem. The creation rate can easily be adjusted.
    3. That's a good point. "Needs-photo=yes" has been removed.
    4. ITIS is now the first reference, followed by Catalogue of Life (when applicable).
    5. I've been reviewing the further reading lists. I've removed a lot of references and restricted others to the higher taxonomic ranks. Hopfully all the references now contain relevant information on the species. I am also trying to move toward more specialized references. This will never be close to perfect, due to the number of species, but it has definitely improved and will continue to be.
    6. That's a good idea. I've gotten a start on the info page, and a referral message is in the talk page of all new stubs now.
    7. The new stubs are now in Category:Articles begun by Qbugbot. I'm looking into the taxon year-of-publication categories.
    8. Almost all the new pages are on species found in North America, because the pages are for species found in both ITIS and, and Bugguide restricts its pages to those arthropods found in North America. The range for most species comes from ITIS, which gives a general worldwide range, more or less by continent.
    9. The common names were selected from a variety of sources, reduced, corrected, and slightly standardized. They come from ITIS, Bugguide, EOL, and a few papers and catalogues. The names definitely have a North American slant, but not intentionally. Sometimes there are different common names used for the same bug in the U.K, Australia, and the U.S., and some times the same common name will be used for different bugs in those three areas.
    10. Most of these recommendations can be found in these pages (randomly selected and manually posted). I'll add to this list tomorrow. Thank you for the comments!
Bob Webster (talk) 07:15, 12 March 2018 (UTC)
  • Comment on redirects Repeating a point I made on 26 Feb, perhaps a bit inconspicuously, on which no-one commented: could the bot please create redirects from bolded common names where these are present? In the set of 20 examples there are two to which this would apply: Bledius annularis and Paropomala virgata (redirects now created from Ringed borrow rove beetle and Virgata toothpick grasshopper respectively). The bot clearly identifies that these are common names, because it bolds them. It should be possible to create the redirect automatically or, in cases where there is already something (article, redirect, dab page) at that name, to add some sort of flag which will add it to a list of "ambiguous common names" (possibly by adding Category:Arthropods with ambiguous common names?), for later human intervention. @Edibobb: Any thoughts on this? PamD 17:27, 10 March 2018 (UTC)
It would be fairly easy to add the common name redirects to the bot, but the quality of the result may be a consideration.
In that case, is it not a very bad idea to do that? @Edibobb: you've seen my observation above. In contrast to PamD (on whose comment I was indirectly responding), I am concerned that unless there's a source to where that so-called 'common' name comes from, this automated and rigorous process could potentially be undermined by 17,000 poorly sourced redirects from English names used in one region of the country or world. (I admit I manually inserted the 'common name' to Bledius annularis, gave it a source, but had absolutely idea whatsoever if it is the most appropriate name to apply, or if it's a regional variation. In fact, having just looked again, it's clear from p.25 the source I cited suggests they made up some names for convenience viz: For some species groups, widely used common names were not available. Common names were developed for this report or for the national report with the help of experts in each species group, based on the scientific names and the species’ ecology and distribution.) If we want human editors to be involved here, then 'common' name is the perfect area in which to get them to create redirects if they're genuinely warranted. Let's face it: without this project, up till now, no-one would be finding these insects under any name, and many minor taxa probably don't have them unless someone publishes a list and makes one up to meet modern consumer needs. Keep it rigorous and academic please. Then the project can't be criticised for introducing errors. The omission of uncited common names for obscure insects arthropods is trivial, and the benefits of leaving them out (or popping them as a mention in the talk page, as per my suggestion 6. above) far outweigh the potential reputational risk to future bot-related projects that could ensue if it's done poorly. Provided these English names come from one nationally or internationally recognised source, published monographs or major national/regional ID guide, I might be less concerned. But at present we do not know what these source are. Just because it's in bold doesn't mean it's correct. Wikipedia is mirrored everywhere on the internet, and people blindly assume it is correct, so promulgating potentially made-up 'common' names (a.k.a. convenience names) en masse doesn't seem to be the thing that anyone would wish Wikipedia to be accused of doing. Do we want to see a paper in Nature or SciAm criticising our promotion and use of 'convenience names'? That said, this project - assuming it sticks to rigour - still has my support and best wishes. Regards from the UK,  Nick Moyes (talk) 12:19, 11 March 2018 (UTC)
  • There is a many-to-many relationship between common names and species. Many species have more than one common name, and a number of common names are used for multiple species. Like you mentioned, this could be handled with an ambiguous category.
  • It's difficult to tell which vernacular names are in common use. For example, the names "hairy spider beetle" and "thickclaw porcelain crab" are rarely used and probably would not deserve a redirect. On the other hand, "spider beetle" and "porcelain crab" each are used to refer to a number of species, but are not listed under any single species.
  • The best way to get a quality set redirects for common names would for some humans familiar with the names of an area (butterflies, leaf beetles, etc.) to select the names in common use. Then the redirects can be easily made from the lists.
  • There are already pages for around 25% of the common names. Some of these are applicable to the species, some to the genus or family, some are completely different topics, and some are redirects or DAB pages. These would need to be skipped and/or added to a list for human processing.
There are around 9,000 species in the project with common names, and more than 2,000 of these have multiple common names. If redirects are automatically made for them all, there is some benefit. Most commonly used names would have redirects, but the majority of the redirects would be rarely or never used.
I don't feel strongly about this one way or another. I am happy to add this feature to the bot, but I hesitate to add something this late in the approval process that might generate opposition. Maybe this could be considered separately as an additional function.
That would be the wisest approach. It seems there's enough opposition to this brilliant scheme already. See my response above. Nick Moyes (talk) 12:19, 11 March 2018 (UTC)
I'd support stepping very carefully with the common names. I think many people are not aware that coining common names is entirely within the ambit of whicherever author requires one first. I myself have made up a couple that now "officially" stick to obscure Brasilian fish as presented in a book; doesn't mean they are "in common use" and should go into the encyclopedia. If there is no way for the bot to source these from a truly authoritative source, it would be better if they were left out. --Elmidae (talk · contribs) 17:05, 11 March 2018 (UTC)
Here's a fairly random sample of some common names.
  • Pacific coast tick
  • thickclaw porcelain crab
  • southern pygmy clubtail
  • plateau dragonlet
  • Carolina saddlebags
  • cherry bluet
  • embossed stonefly
  • Hampshire needlefly
  • striped slant-face grasshopper
  • spotted-winged grasshopper
  • Fox's short-wing grasshopper
  • crowned grasshopper
  • great crested grasshopper
  • Davis's conehead
  • glassy-winged sharpshooter
  • clover leafhopper
  • variegated cactus dodger
  • Fitch's elephanthopper
  • buckeye lace bug
  • firebug
  • blackcurrant-sowthistle aphid
  • podocarpus aphid
  • tristania psyllid
  • black caterpillar hunter
  • dark saltflat tiger beetle
  • variable tiger beetle
  • red hills unique whirligig beetle
  • fifteen-spotted lady beetle
  • square-necked grain beetle
  • antelope brush girdler
  • saltbush borer
  • spotted apple tree borer
  • cowpea weevil
  • air potato leaf beetle
  • imbricated snout beetle
  • obscure root weevil
  • red elm bark weevil
  • banded elm bark beetle
  • poplar ambrosia beetle
  • Doll's tooth-tipped buprestid
  • hardwood heartwood buprestid
  • lantern click beetle
  • beaver nest beetle
  • hairy spider beetle
  • western rose chafer
  • delta flower scarab
  • honeysuckle sawfly
  • violet sawfly
  • European alder leafminer
  • woolly catkin gall wasp
  • velvet ant
  • double-banded scoliid
  • Rocky Mountain aerial yellowjacket
  • Duponchel's sphinx
  • alberta lutestring
  • eastern pine catkin borer
  • Thelma's agonopterix
  • spotted dichomeris
  • circumscript mompha moth
  • common lytrosis
  • blueberry gray
  • Nevada tiger moth
  • mournful underwing
  • southern focillidia moth
  • powdered gabara moth
  • smeared dagger moth
  • clouded crimson
  • rice worm moth
  • mottled rustic
  • purple arches
  • Reed's dart moth
  • signate pinion
  • ashy pleromelloida
  • small heterocampa
  • glossy prominent
  • drusius cloudywing
  • Columbian skipper
  • ursus giant skipper
  • lilac-bordered copper
  • cranberry blue
  • gold-bordered hairstreak
  • zerene fritillary
  • three-tailed swallowtail
  • cranberry girdler
  • sod webworm
  • hollow-spotted blepharomastix
  • celery leaftier
  • western pine moth
  • sunflower moth
  • common bagworm moth
  • douglas-fir cone moth
  • lodgepole pinecone borer moth
  • sapodilla pod borer
  • banded olethreutes
  • phalonidia campicolana
  • red-crossed button slug
  • Mexican fruit fly
  • bull thistle gall fly

Bob Webster (talk) 02:18, 11 March 2018 (UTC)

  • Oppose Wikipedia does not benefit from stubs. Wikipedia needs well-written, sourced articles. We have humans that want to do that work; you're just screwing them out of four awards with a bot. Chris Troutman (talk) 23:20, 10 March 2018 (UTC)
Oh, silly me. I thought we were building a great encyclopaedia the best way we can, not creating a forum for editors to win prizes. Nick Moyes (talk) 12:19, 11 March 2018 (UTC)
Sentence 1: what??? Sentence 2: fair enough, but non-sequitur. Sentence 3: what??? - Averaged, that's not a well-reasoned oppose. --Elmidae (talk · contribs) 16:58, 11 March 2018 (UTC)
Think about it. You claim that you want to do this to build an encyclopedia but that you don't mind removing the incentive for editors to write those articles. If the reader can get the information they want and it doesn't involve me, they can find some other website. Wikipedia, it seems to me, is a haven for under-employed know-it-alls. Our participation is driven by incentives. If you remove incentives, you'll remove editors. Perhaps you don't want the editors to be here; perhaps you think the efforts to research and write are a drudgery better left to machines. But perhaps I like digging this ditch; I don't desire your new-fangled contraption to remove my outlet. Writing articles is not factory-line machine-process; it's an art. Your effort to have bots belch out text to "inform" the reader will only shut down this guild of researchers and writers. Chris Troutman (talk) 17:15, 11 March 2018 (UTC)
Unless you think that creating a stub is an enjoyable creative task, but expanding a stub is thankless and boring (and based on your opinion of stubs stated above, that seems unlikely), I don't see how this bot is taking bread from the mouth of editors, really. --Elmidae (talk · contribs) 17:22, 11 March 2018 (UTC)
Chris troutman, An interesting objection. At the current rate of human creation of articles on arthropods, roughly when could we expect the full set of taxa to each have an article? I assume they are actually being given articles faster than new species are being described, but there are a lot of them. · · · Peter (Southwood) (talk): 18:36, 11 March 2018 (UTC)
Error in Template:Reply to: Username not given. You can, for example google "Fitch's elephanthopper" to find out what one is. A machine-generated stub is of marginal benefit to the reader (it only gets them to Wikipedia so Jimmy can ask for money). If we wait ten years for a Wikipedian to assemble an article the reader finds benefit and the Wikipedian is able to perform their craft. There's no benefit to having a stub article today. I might be swayed if we allowed summary deletion of stubs to make way for well-written versions. Chris Troutman (talk) 15:34, 12 March 2018 (UTC)
@Pbsouthwood: Your assumption is incorrect. Neither nor Wikispecies is adding articles more quickly than new species are being described. More than 15,000 species are described each year. I can post a more detailed analysis to your talk page if you'd like. Plantdrew (talk) 15:47, 12 March 2018 (UTC)
  • Support – Automated stub creation can be awful. This effort, on the contrary, produces extremely nice articles, and deserves to be cited as a model for future bots. Yes, humans love to edit, but humans also love to be assisted. — JFG talk 02:34, 11 March 2018 (UTC)
  • Oppose While I understand the noble reson behind the proposal, in practice this will blow out the number of stubs with little informative content, contributing to the backlog that we already have. Stubs already constitute about 37% of all articles, more than one quarter. And many of these bot-created arthropod articles are (and will be) WP:ORPHAN, requiring human input, while their content is little beyond what an ordinary person can google. At least, when a stub is created by a human, it's more likely that it will be improved by the creator. I think we should focus on creating and improving less esotheric and more significant articles. Brandmeistertalk 17:48, 11 March 2018 (UTC)
None of the stubs in the above list of 20 test pages are orphans. For each species, the bot creates a genus page (containing a species list, among other things) if it does not already exist, and so on up the taxonomical hierarchy. Some human editing is required if a genus page exists and has omitted a species in its list, but this can be handled easily enough. I don't know of any orphans remaining in the 2,000 or so test pages that have been created. After the article creation, all the stubs will be checked to make sure there are no orphans or walled gardens left by this project. Bob Webster (talk) 21:07, 11 March 2018 (UTC)
I see, however, some have been tagged with Template:Underlinked and indeed their overall linking potential in other articles looks limited due to very specific scope. Brandmeistertalk 00:03, 12 March 2018 (UTC)
All the Underlinked tags on these pages were incorrectly added by AWB because it does not currently count the links in Speciesboxes and Automatic Taxoboxes (as opposed to those in Taxoboxes).

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.

Turn off extended edit summaries

Today the edit summary limit was extended from 250ish to 1000. Apparently this was a request from dewiki on the Community Wishlist. See phab:T6714 for one of the many phab requests about it. This is a prime example of the potential problems with this. It will do nothing more than cause massive disruption in the histories of numerous pages. For that reason I'm putting this to the community.

Should enwiki request that the old edit summary limit be put back on this project? --Majora (talk) 23:51, 1 March 2018 (UTC)


  • Support as proposer --Majora (talk) 23:51, 1 March 2018 (UTC)
  • Support. Yes, please turn it off. --SmokeyJoe (talk) 23:55, 1 March 2018 (UTC) Maybe not turn it off, but make it adjustable by the user.
  • Support somebody must not have thought this change through. Lepricavark (talk) 23:59, 1 March 2018 (UTC)
  • Support I really need this part? But I'll add a comment in Discussion. ―Mandruss  00:08, 2 March 2018 (UTC)
  • Support but it would be nice if the limit applied only to characters that actually display in watchlists, rather than the source of the edit summary. When you're adding extra text to an auto-generated summary that includes pipes, you can run out of space pretty fast. Whether that's technically feasible I wouldn't know. --Trovatore (talk) 00:27, 2 March 2018 (UTC)
  • Support 1000 is too much; if the limit is tuneable I wouldn't be opposed to something around the 400-500 range due to IPv6-related concerns. power~enwiki (π, ν) 00:48, 2 March 2018 (UTC)
    @Power~enwiki: The proposal above that you're supporting is to reduce it back to 255 characters, so your vote should actually be "oppose". -- intgr [talk] 10:24, 2 March 2018 (UTC)
  • Support: You don't need 1,000 characters for an edit summary. 255 is sufficient. — MRD2014 Talk 01:37, 2 March 2018 (UTC)
  • Support: The old limit was sufficient. It was also useful. Very occasionally the situation seems to require a summary longer than the normal 5 or 6 words. On these occasions the limit prevented me from using an over-long summary by "forcing" me to pare it down to something appropriately concise. If there is still a need to say more I should be using the summary to point to a talk page discussion. Summaries should be concise and not bloat the history/watchlist entries. -- Begoon 02:45, 2 March 2018 (UTC)
Noting I'd also be happy with Legoktm's solution. -- Begoon 09:33, 2 March 2018 (UTC)
  • Support Don't solve something that was never a problem.--v/r - TP 02:46, 2 March 2018 (UTC)
  • Support TonyBallioni (talk) 02:48, 2 March 2018 (UTC)
  • Support If you can't say it in 255 characters you should be pointing to a talk page. However, sometimes the preloaded stuff doesn't leave you enough space. Britmax (talk) 12:02, 2 March 2018 (UTC)
  • I prefer edit summaries longer than 255 character being available; often with section edits, a lot of space is taken up by the section heading, and when reverting edits from IPv6 editors, a lot of space is taken up by the boilerplate text. (I appreciate some suggest deleting this text to make room; I prefer keeping the standard text as an aid to those who are accustomed to it, and adding a brief summary afterwards.) A lower limit than 1000 would probably be suitable, though. isaacl (talk) 03:19, 2 March 2018 (UTC)
  • Oppose. Between unicode characters and IPv6 it's clearly a net improvement. The diffs provided indicate that the auto-summaries need tweaking to not include the full length of what was written. Something like "cut at the end of the first sentence" would solve this easily. FACE WITH TEARS OF JOY [u+1F602] 03:49, 2 March 2018 (UTC)
    • These aren't autosummaries. That's the problem. Some people are used to copying their entire comment into the edit summary on the assumption that it gets cut off. TonyBallioni (talk) 03:54, 2 March 2018 (UTC)
      • Ah gotcha, understood. Still: I think a few examples from before people were aware of the new behavior are not a big deal. People adapt when their environment changes :) FACE WITH TEARS OF JOY [u+1F602] 03:58, 2 March 2018 (UTC)
        • A "few" in the span of a few hours being turned on will turn into a massive mess as time goes on. These are, for all intents and purposes, permanent in page histories. While temporary, they also completely disrupt watchlists. This is nonsensical. I can understand that the Germans wanted this, you can have some crazy long sentences in German, but we didn't ask for this. We didn't ask for a 1,000 byte limit. --Majora (talk) 04:01, 2 March 2018 (UTC)
          • This is *NOT* a request just from the German community. If you look at phab:T6714 it goes all the way back to 2006! Even English Wikipedians wanted (and still want this). Legoktm (talk) 04:08, 2 March 2018 (UTC)
          • (ec) This has nothing to do with Germans, really...plenty of folks have commented on these tasks over quite a few years (including some enwiki users). Issues with poor display on watchlists and so forth can be cleaned up as time goes on (like a "expand full summary ->" link?). Nothing is perfect the first time, and I think the underlying change will ultimately be beneficial to folks. FACE WITH TEARS OF JOY [u+1F602] 04:12, 2 March 2018 (UTC)
  • Support We're barraged with text everywhere else, this is one place to the point writing is enforced. -- GreenC 03:51, 2 March 2018 (UTC)
  • Oppose There are plenty of places where the old limit was entirely problematic. Protection logs getting trimmed, rollbacks having broken links, and so on. Maybe we need a better way of displaying these, but lets not throw the baby out with the bathwater here. Legoktm (talk) 03:53, 2 March 2018 (UTC)
  • I'd agree with you for log entries and the like. Is there a way to adjust a setting locally so we can limit user generated edit summaries specifically? Killiondude (talk) 03:58, 2 March 2018 (UTC)
    No, that's not really a setting. It's still a problem when you undo an IPv6 user's (or someone with a longer username) edit and want to leave a rationale after it though. I put a proposal in the discussion section about how we could do truncation without losing the benefits of this change which I hope is a workable compromise. Legoktm (talk) 04:06, 2 March 2018 (UTC)
  • Oppose in favour of Legoktm/😂's proposal (see below), which is to truncate the display and add a clickable "..." (or similar) to reveal the rest of the summary. For this see phab:T6717. I don't know how long this would take to implement, but it's only JavaScript, so it can't be that hard.[citation needed] Worse comes to worse we can implement something ourselves here, but my bet is other Latin wikis will want the same. I wouldn't stress over it. A solution will be found. MusikAnimal talk 04:27, 2 March 2018 (UTC)
  • Oppose cutting the limit back down - my god I'm glad that when reverting an IP edit, the entire span isn't taken up any more with monster-IPv6 user name + link to said monster-IPv6 talk page! Having a higher character limit is entirely welcome from my point of view. Implementing some dynamic truncation with option to reveal more content, as discussed below, might be a good option though. --Elmidae (talk · contribs) 06:58, 2 March 2018 (UTC)
  • Oppose cutting back to 255 per Legoktm, Elmidae et al. 1000 may be beyond reasonable needs, I prefer a reasonable number plus section name or username/talk page automatically generated content etc. Old length was often too short to put in a useful comment on top of the automatic stuff. A warning should come up when exceeding 255 characters and additional text could go on a highlighted background, or one could click to extend the summary box by say 255 characters at a time, yellow highlighting the first time, then orange, then red.· · · Peter (Southwood) (talk): 08:40, 2 March 2018 (UTC)
  • Oppose Long edit summaries can be truncated, per the above suggestion. Need to do something with IPv6 addresses as they may cause problems with being able to write a full comment. !dave 08:56, 2 March 2018 (UTC)
  • Oppose per above. Benefits clearly outweigh the drawbacks. Broken links in rollback summaries or log entries are confusing even to experienced users. -FASTILY 09:20, 2 March 2018 (UTC)
  • Oppose 255 characters is not enough for a summary when reverting a long IPv6 address edit. It doesn't need to be 1000 chars either though, maybe somethig in between. -- intgr [talk] 10:24, 2 March 2018 (UTC)
  • Oppose. Firstly, the opening statement in this RfC has obviously incorrect statements in it. This is not the result of "a request from dewiki", it was the #2 item from the 2016 Community Wishlist, and in fact had many users from the English Wikipedia voting in support of it. Secondly, the opening statement fails to actually describe the damage that is being caused by these longer edit summaries, other than that page histories can now be longer due to the longer edit summaries, which is merely different and is not actually damaging. Continued change aversion serves nobody. Let's wait and see how it works out, rather than rushing to turn the new things off simply because they're new. --Deskana (talk) 10:54, 2 March 2018 (UTC)
    • Comment: this was maybe the intent of developers, but it has no relation to #2 item from the 2016 Community Wishlist. We asked for 255 Cyrillic and other non-Latin symbols to be treated as 255 ASCII symbols, we got 7x increase in edit summary length. stjn[ru] 11:14, 2 March 2018 (UTC)
  • Oppose — Although, 1,000 characters may be more than one wants, 255 characters are in no shape or form enough. Also, per rationale provided by Deskana (talk · contribs) and 😂 (talk · contribs). No prejudice towards making the limit a bit reasonable — to say, 500-600 characters — though.
    Regards, SshibumXZ (Talk) (Contributions). 11:09, 2 March 2018 (UTC)
  • Oppose. I occasionally have to deal with copyright violations from multiple URLs and I find 255 characters goes pretty quickly. I support Legotm's solution. I'd also try to change editor behavior, but that's hard. MER-C 11:23, 2 March 2018 (UTC)
  • Oppose - looks like a useful change, having to shorten edit summaries to fit under the previous limit has been annoying on occasion. Thanks. Mike Peel (talk) 11:26, 2 March 2018 (UTC)
  • Cut the baby and make it 300-400 per SshibumXZ. Not too disruptive, not too limiting for long section headers. ~ Amory (utc) 11:30, 2 March 2018 (UTC)
    Just to add, it's not clear to me why this happened. The "#2 on the request list" argument pretty clearly supports our Russian friend here that the request was for 255 characters. I get that with some characters taking 3 bytes, a byte limit of 750-1000 was likely the easiest solution, but it does seem to be counter to what was actually proposed and supported. ~ Amory (utc) 15:37, 2 March 2018 (UTC)
  • Oppose. There's a common pattern here. WMF does something that improves experience for a substantial part of the movement (in this case, non-Latin-character-using projects). Someone notices this has a marginal impact on their personal experience. That person goes "OMG THIS IS AWFUL WHY WAS I NOT CONSULTED" and starts some kind of demand for the WMF to undo what they've just done. Then there is an unproductive conversation about whether this change is a good or bad idea, usually started without reference to the WMF's rationale for doing something in the first place, and with an unrealistic insistence that the WMF only do things when they have crafted something that works in an ideal way for everyone who might possibly have an opinion on the matter. Looking at the cost-benefit, I am quite happy to have longer edit summaries and more cluttered edit histories here, if that means the Russian Wikipedia and others can have edit summaries at a reasonable length. But maybe we should also look at the cost-benefit of the number of RFCs we seem to have saying "WMF please undo whatever it is you've just done", as well... The Land (talk) 11:43, 2 March 2018 (UTC)
    No opinion on your general point, but it's not hard to see how this, multiplied many times, will be a serious disruption, far from a marginal impact on personal experience. You can tell folks not to do that until you're blue in the face and many will do it anyway, either because they are unaware of your guidance or because they don't care about silly old guidance. It's clear that something needs to change, the question under discussion is what. ―Mandruss  11:52, 2 March 2018 (UTC)
    @The Land: Improving experience of Russian Wikipedia and other communities was not intent of this change. This was a complete decision mystery from WMF, we and others were asking only for increasing 255 bytes to 255 symbols across the Wikimedia projects, what we got is the same 1000 characters out-of-nowhere as you do. We are frankly as surprised about this change as your community is. stjn[ru] 11:55, 2 March 2018 (UTC)
    Well it's pretty clear that this is the WMF's chosen method of implementing that request. I'm not claiming it's a perfect implementation, but then, the reality is that the WMF does not have the tech resources to do everything perfectly. The Land (talk) 20:54, 2 March 2018 (UTC)
    There's very little mystery, the goal was to increase the edit summary length, very specifically to accommodate Russian and other non-latin langages, seemeta:Community Tech/Edit summary length for non-Latin languages in particular. Headbomb {t · c · p · b} 01:01, 3 March 2018 (UTC)
    The specific wording of the proposal is as follows: Should enwiki request that the old edit summary limit be put back on this project? This proposal is for our project and does not impact the Russian Wikipedia at all. Given that you only edit here very rarely, and apparently don't even have enough time to actually read the proposal before !voting, you should not be so dismissive of the opinions of those who are actively contributing to the encyclopedia. This change may not affect you, but it most certainly does affect us. Lepricavark (talk) 19:35, 2 March 2018 (UTC)
    lol, once you've been contributing to the Wikimedia movement for 14 years, then come back and tell me I don't understand Wikipedia! The Land (talk) 20:54, 2 March 2018 (UTC)
    I never said you don't understand Wikipedia. I said you didn't understand this proposal. But hey, you've been around longer than I have (with far fewer edits), so you must be right! Lepricavark (talk) 22:58, 2 March 2018 (UTC)
  • Oppose. If there is an actual problem here (and I'm struggling to see one), then the way to solve it is to get consensus for a local guideline about edit summary length and educate people about it. Thryduulf (talk) 11:48, 2 March 2018 (UTC)
  • Support Allowing scope to place long diatribes in edit summaries (whether displayed or not) will hasten the demise of the talk page. We do, however, need to shorten lengthy auto summaries like "Undid revision ***** by *****": Noyster (talk), 11:54, 2 March 2018 (UTC)
  • Oppose per Thryduulf and The Land, but it would definitely be useful to have some way to truncate the display of long summaries. ​—DoRD (talk)​ 12:50, 2 March 2018 (UTC)
  • Oppose I have no problem with the new edit summary length. If people are using it to be disruptive, then deal with that on its own. --Jayron32 13:28, 2 March 2018 (UTC)
    Do we not have enough disruption to deal with on its own without creating new opportunities for it? There are already alternative solutions on the table that do not. ―Mandruss  13:32, 2 March 2018 (UTC)
All communication is not disruptive. Edit summary space has eminently constructive uses. Bus stop (talk) 12:48, 10 March 2018 (UTC)
  • Oppose clearly a net improvement for the community per The Land, Sadads (talk) 14:58, 2 March 2018 (UTC)
  • Oppose clearly this is a net improvement. However, I very much support a 255 displayed-character "soft" truncation with a clickable [...] to expand to the full summary. Or any other reasonable limit to displayed character if 255 is deemed too much.Headbomb {t · c · p · b} 15:05, 2 March 2018 (UTC)
  • support This is not an improvement and just invites people to write yet more things that they cannot redact or edit. And no I do not want my watchlist crammed with overlong rants. And as noted above. people already treat edit notes like tweets (some history pages look like my twitter feed with fake dialogue) and longer edit notes will only encourage that, and the edit warring that goes on underneath it. Dramatic changes like this to user experience should have a prior RfC in any case. Jytdog (talk) 15:27, 2 March 2018 (UTC)
    • As this day has gone on my watchlist has become an un-useable jumble of clutter. Jytdog (talk) 20:03, 2 March 2018 (UTC)
  • Oppose There are often times I have to shorten or remove details in an edit summary just fit it in the limit. Would rather be able to explain things without being limited. I would be fine with a lower limit if the character limit was limited to only displayed characters, as often wikilinks(to ip/user+talk) can take up a significant portion when reverting. Other cases are when I want to link to a talk page discussion with section, but there isn't enough space to link it and give a detailed edit summary, and you are forced to just simply say see this linked discussion with short summary, or give more detailed summary and refer them to go to talk page, where they have to find discussion on their own there or in archives. If there seems to be a high level of abuse/disruptions, limiting it to extended confirmed users could be an option. WikiVirusC(talk) 15:37, 2 March 2018 (UTC)
  • Oppose grandstanding tends to be a bad look for people --Guerillero | Parlez Moi 15:54, 2 March 2018 (UTC)
  • Support Overly long edit summaries clutter the history page, watchlist, and are unnecessary. If the argument is for IPv6 addresses, extend it to 300 characters. If you need more than that, use the talk page. Natureium (talk) 16:48, 2 March 2018 (UTC)
  • Oppose – large edit summaries would likely indicate a bigger issue or problem being dealt with, something that should probably attract more attention. If I see a huge edit summary on my watchlist, I will likely pay more attention to that edit. This feature may also encourage editors to speak to each other more, right on the front lines where editing is taking place. Better communication leads to better results. A well-explained edit is less likely to be reverted. A big problem we are likely to face with this feature is spamming, and so there will be an inevitable increase in deletions of entries from edit histories. Hopefully we have enough people available with the right tools to handle the shift in problems that this feature will create. Not more or bigger problems, necessarily, but different ones. And of course, we will need new guidelines for edit summaries. Like not repeating huge summaries for multiple edits on the same page. Posting the explanation once should suffice. Huge edit summaries for mass edits over many pages should also be discouraged, with a preference for a pointer to a notice on a talk page, rather than such a notice being repeated over and over in watchlists. The biggest outcry will likely be from editors monitoring things via watchlists. It will be interesting to see how the community adapts this new feature into its culture, and I am confident that it will. Let's try this new feature out for awhile and see how it goes.     — The Transhumanist    17:09, 2 March 2018 (UTC)
  • Oppose Longer edit summaries are useful. We should have a way to truncate. I also endorse Legoktm's comment: when there's a feature change, we should try not to just shout "turn it off!" but talk to the developers calmly about how the change affects us so it can be improved. A bit more "Yes, and..." and a bit less blow it up and start over. —Tom Morris (talk) 17:27, 2 March 2018 (UTC)
  • Partial oppose: 1000 is overkill for legitimate usage. I'd recommend 512 with an option for truncation in the view, and that a filter be implemented for overly long edit summaries so that they may be monitored for abuse. ViperSnake151  Talk  17:31, 2 March 2018 (UTC)
  • Oppose. Smallchief (talk) 17:35, 2 March 2018 (UTC)
  • Support per Jytdog and Noyster - perhaps till 400 char but not more than that really Galobtter (pingó mió) 17:39, 2 March 2018 (UTC)
  • Oppose, per Unicode, IPv6, etc. There should probably be a watchlist option to only show the first n characters, though. Support Lego's solution now that I've actually found it. --SarekOfVulcan (talk) 17:41, 2 March 2018 (UTC)
  • Oppose does not matter. Alanscottwalker (talk) 17:49, 2 March 2018 (UTC)
What does this mean? Are you just voting without a reason to vote? — Preceding unsigned comment added by Natureium (talkcontribs)
Explanation: We call that a !!vote—pronounced not-not-vote—aka vote. ―Mandruss  19:13, 2 March 2018 (UTC)
Was I unclear, sorry -- the objections are silly (too much space! we don't want to read! I can't handle change! Other people will act bad!, I was not consulted! People play! etc.) and the expansion of space is fine. Alanscottwalker (talk) 19:18, 2 March 2018 (UTC)
No, objections include opening up abuse of watchlists, obfuscating issues that would normally be picked up, making admins and those who try to detect vandalism lives' more difficult. But hey. The Rambling Man (talk) 20:42, 2 March 2018 (UTC)
Come on, now. Apart from those trying to make a rhetorical, uhm, point, there has not even been a breakout of all these suppossed "problems" in this very discussion. Alanscottwalker (talk) 16:30, 3 March 2018 (UTC)
  • Support - What plank actually thought this was a great idea ? ....., 250(ish) was absolutely fine ..... Bumping it up to 1000 means more dumbass edit summaries like mine[31] (Text copied from Jesus)(Diff), If you want to post longer comments then use the bloody talkpage, I'm all for change and improvement but this improves nothing (if anything it gives trolls/vandals more opportunity to clog up my entire watchlist!). –Davey2010Talk 19:37, 2 March 2018 (UTC)(Added attribution at 22:32, 5 March 2018 (UTC))
I feel I should add I didn't abuse the feature for the fun of it - I abused it to show how easy it is for it too be abused, I don't in any way, shape or form condone anyone following suit and I would hope for this specific case my edit summary isn't revdelled, Thanks, –Davey2010Talk 20:35, 2 March 2018 (UTC).
Davey2010, I've revdel'd your edit summary since it was copied without attribution and is thus a violation of policy. Primefac (talk) 18:47, 5 March 2018 (UTC) (please ping on reply)
  • Support they are edit summaries, made specifically to include in a brief way the changes made. I’d be happy with a small increase, but as demonstrated this has major potential for abuse. In a rare occasion there’s not enough room, use the talk page to explain, where character usage is unlimited. Aiken D 19:43, 2 March 2018 (UTC)
  • Oppose: It's preferable to be able to paste the full url of the source for a copyvio edit removal into my edit summary, but sometimes with the old limit I have run out of space, particularly when I want to remove from multiple sources in one edit. See for example today's work at 2017 Mumbai stampede, where it was possible to include full urls and get the work done quicker in fewer edits while still leaving a good audit trail. Running out of space means I have to perform more edits to do the same amount of work (which is slower and also clutters up watch-lists), or leave a cut-off url (which makes later review of what I did difficult to impossible). 500 characters is prolly enough for 3-4 urls though. — Diannaa 🍁 (talk) 19:47, 2 March 2018 (UTC)
  • Support (a) if you can't _summarise_ your edit in 200 characters, something's wrong and (b) this is perfect for vandals to flood watchlists. Mine is already overwhelmed by people just trying it out. It's a joke and completely unnecessary. Just because Twitter doubled up, it doesn't mean we need this crap in our lives. REMOVE, allow me to demonstrate. Minor change. Another minor change. The Rambling Man (talk) 20:18, 2 March 2018 (UTC)
    Now then, hopefully no-one will block me, but the point is, now look at the edit history and try to work out what I did. This is a complete joke, a failure, a fad that needs checking. Perhaps those who are opposing this restriction in characters don't do a lot of work behind the scenes where quickly assimilating information from an edit summary is essential. Not to mention how easy it's going to be to destroy the ability to easily parse ones' watchlists. REMOVE. The Rambling Man (talk) 20:21, 2 March 2018 (UTC)
    Revdeled the second two as disruptive. Once was more than enough. --SarekOfVulcan (talk) 20:24, 2 March 2018 (UTC)
    That's bollocks. You're deliberately obfuscating the issue. We need to see what two or three edit summaries of this type look like back to back. But you've hidden it now. The Rambling Man (talk) 20:27, 2 March 2018 (UTC)
    If you want that iridiscent's talk history has enough of that Galobtter (pingó mió) 20:31, 2 March 2018 (UTC)
    Not at all, TRM. They have helpfully demonstrated the extra workload this will add for already-overworked admins. ―Mandruss  20:32, 2 March 2018 (UTC)
    It's not just admins, the rest of us who care about the integrity of Wikipedia are now concerned that we can't work out what the fuck people are doing. The Rambling Man (talk) 20:35, 2 March 2018 (UTC)
    That too. Don't worry, if this sticks it won't stick for long. Many of those !voting Oppose will be at the head of the line complaining about it, mark my words. ―Mandruss  20:37, 2 March 2018 (UTC)
  • Support turning it off. Yes, there are some potential benefits; yes, they're hugely outweighed by the disruption watchlist-flooding will cause. ‑ Iridescent 20:23, 2 March 2018 (UTC)
    So, because you don't want people being abusive with the new edit summaries, you used it abusively. If you didn't want them to be used that way, maybe you shouldn't have. --Jayron32 20:26, 2 March 2018 (UTC)
    Um, to demonstrate the problem, which is perfectly reasonable. Bonkers. The Rambling Man (talk) 20:40, 2 March 2018 (UTC)
    (edit conflict)If you want to demonstrate the problem, do it in your own sandbox and link to it, not a major discussion venue. --SarekOfVulcan (talk) 20:44, 2 March 2018 (UTC)
    I think the point is that this disruption can and will be caused on ANY WIKIPEDIA PAGE that's not fully protected. Demonstrating it in a sandbox is great, but it misses the salient point, which you are working so hard to obfuscate. Noted. The Rambling Man (talk) 20:47, 2 March 2018 (UTC)
    WP:POINT+WP:IAR. ―Mandruss  20:43, 2 March 2018 (UTC)
    ... = WP:lulz. Kurtis (talk) 09:35, 9 March 2018 (UTC)
  • Oppose - While I agree that 1000 is too many quite often 255 was not enough. A compromise at 500 would be useful. BTW as I see it the real problem is those editors who copy paste their post into the edit summary line. Perhaps they could learn to type something that is a brief description summing up what they posted. MarnetteD|Talk 20:35, 2 March 2018 (UTC)
  • Support - Progress is great, and I think 1000, or even 10,000 character edit summaries might be OK, but only if their display is truncated by default. This should have been submitted to the community for discussion before being phabricated into our workflow. It has the potential to be quite disruptive unless implemented with finesse.- MrX 🖋 20:57, 2 March 2018 (UTC)
  • Support It's a summary. It's supposed to be brief. Learn to be brief. PaleCloudedWhite (talk) 21:00, 2 March 2018 (UTC)
  • Comment it's ironic that an admin has deemed two of my lengthy edit summaries to be so disruptive that they need to be rev-del'ed, and I was simply demonstrating the problem. So once the general population of vandals get to know this, how much time is going to be spent rev-del'ing such "disruptive" summaries? Although the principle I was demonstrating has been incorrectly obfuscated by this admin, it proves another very important point in favour of returning to shorter summaries. The Rambling Man (talk) 21:05, 2 March 2018 (UTC)
    Here is a great example of what this admin was trying to hide from you all. The Rambling Man (talk) 21:23, 2 March 2018 (UTC)
  • Support Long summaries discourage talk page discussion and, thus, interferes with dispute resolution. All main forms of dispute resolution — Third Opinion, Dispute Resolution Noticeboard, and Formal Mediation — have a prerequisite that they will not accept a case which has not had substantial talk page discussion and that they will not consider edit summaries in determining whether that discussion has occurred. Long edit summaries will cause more cases to be declined. — TransporterMan (TALK) 21:27, 2 March 2018 (UTC)
  • Oppose I think there's a real need for a longer edit summary field. That said, it is easy to imagine that problems can occur if people accidentally post a long edit summary. Can that be handled with an edit filter which would warn an editor that there edit summary exceeded say, 500 characters, and give them a chance to edit?--S Philbrick(Talk) 21:47, 2 March 2018 (UTC)
  • Oppose I don't see the examples cited as disruptive. They are on an order or magnitude less problematic than walls of text I see on discussion pages. Cas Liber (talk · contribs) 23:41, 2 March 2018 (UTC)
But that's what talk pages are for. The edit summary is meant to be a quick summary of what change you made. Natureium (talk) 23:43, 2 March 2018 (UTC)
  • Support 1000 is too much, even for IPv6 and things like that, noone needs more than 500 signs in any case. Furthermore, I don't think making the summaries much longer isn't what's needed here, but making the autogenerated parts of the summary machine-readable is. This solves the problem without causing this mess, and is a way better solution in general, as it is localizable as well. --MGChecker (talk) 00:02, 3 March 2018 (UTC)
  • Oppose (tho I support legotm's suggestion) --Terra (talk) 00:15, 3 March 2018 (UTC)
  • Support - it was a terrible idea in the first place, and has done nothing but harm from the beginning. --Orange Mike | Talk 00:42, 3 March 2018 (UTC)
  • Oppose Nobody needs to use an edit summary at all, but any number of characters is an arbitrary limit. Why not err on the high side? — Malik Shabazz Talk/Stalk 02:16, 3 March 2018 (UTC)
  • Oppose. We'll get used to it soon enough. – Joe (talk) 03:00, 3 March 2018 (UTC)
  • Oppose There is no evidence yet of real trouble. Remember admins can hide edit summaries if there are serious problems (eg this is now big enough for copyvio, and not just for outing and harrassment). We also have the option of edit filters if you want to get a handle on stupid things happening. Graeme Bartlett (talk) 03:19, 3 March 2018 (UTC)
  • Oppose in light of alternative solutions, such as truncation. My main concern with lengthy edit summaries is that it might enable more editors to "discuss" things via the edit summary, which invites more edit warring behavior. However, I also think reverting all the way back to the previous limit is an oversimplified solution. More space in the edit summary in general is an improvement, especially considering how internal links and IPv6 addresses can sometimes clog it up. Mz7 (talk) 03:39, 3 March 2018 (UTC)
  • Support 1000 is too many. ~Awilley (talk) 04:31, 3 March 2018 (UTC)
  • Support 1000 is too many, and as someone else said: 'If you can't say it in 255 characters you should be pointing to a talk page'. Edit summaries are supposed to be just that: an edit summary. Turning edit summaries into yet another form of dialog is nonsense. In my experience, ES are hardly ever read anyway (due the number of clicks needed to get to them). Many less experienced users probably still don't even know what an ES is. Kudpung กุดผึ้ง (talk) 05:23, 3 March 2018 (UTC)
  • Oppose per MarnetteD. Double sharp (talk) 05:42, 3 March 2018 (UTC)
  • Oppose – The previous edit summaries limit was too restrictive, in my opinion. I do like the idea of having particularly long edit summaries auto-collapse, though. Master of Time (talk) 06:28, 3 March 2018 (UTC)
  • Strong Oppose - Say, for example, one wants to link to this discussion in an edit summary. Wikipedia:Village pump (proposals)#Turn off extended edit summaries takes up 71 characters, but with piping it may only display as a few, e.g. "see here". This change is extremely beneficial both for those who like to provide links to specific policies and guidelines that are being implemented within their edits and due to the fact that section headings without shortcut(s) (or those with only obscure, unknown ones) can take up a lot of space. Sure, some will leave 1000 displayed character edit summaries, but the benefit outweighs what is a small downside. If people are being foolish with edit summaries, leave them a kind note; if people are abusing edit summaries, leave them a warning. I can envision even a 1000 displayed character edit summary that is purely descriptive of a large copyedit; in other words, something due within an edit summary that would not be necessary or appropriate for a talk page. — Godsy (TALKCONT) 08:41, 3 March 2018 (UTC)
  • Support 1000 characters is far too long- if you need that much detail on an edit/revert, then there's a talkpage for that (as others have highlighted). Maybe 1000 characters is needed in German where individual words are much longer, but here on English wiki it's ridiculously excessive. Joseph2302 (talk) 11:28, 3 March 2018 (UTC)
  • Oppose 1000 is too long but 250 is too short. 500 would be nice. Or make it so only EC30/500 can use the full mount, nonEC and IPs have to stick with 250. L3X1 ◊distænt write◊ 12:28, 3 March 2018 (UTC)
  • Support I do not see the need to replace the talkpage by an edit summary The Banner talk 13:04, 3 March 2018 (UTC)
  • Oppose: 500 characters for experinced editors is enough, IP/newbies should be stuck with 250. KGirl (Wanna chat?) 15:46, 3 March 2018 (UTC)
  • Oppose I sometimes want more than 250. Agree it was too short before. Doc James (talk · contribs · email) 16:25, 3 March 2018 (UTC)
  • Support The community wishlist proposal was intended to benefit users of non-English languages who could only use about 30% of the available space because each of their text characters counted as 2-4 as compared to English. I do not remember the proposal being about a demand to make more text possible for English writing, or for writing in any language being longer than the equivalent amount of text and information as compared to English. The proposer highlighted what to me is obviously a major problem - the change has broken the status quo of English Wikipedia edit logs and this major disruptive change has happened without discussion. The solution is to put things back to the way they were before then start a conversation about the extent to which we should change the status quo. Many of the oppose votes here are out of order, because when anyone makes a major change to user experience in wiki and there is not community consensus for that, the start of the discussion is status quo, and not claiming to negotiate with the change as the new way and negotiating back to the established norm from that. WP:BRD applies here - the change was bold but challenged so now we revert and discuss from there. I agree that we need the ability to post links in the edit summary but exposing human readers to long URLs should never be allowed anyway. Expanding the edit summary for the sake of making humans read computer code in the edit summary is not a solution. Blue Rasberry (talk) 16:27, 3 March 2018 (UTC)
Actually, no. By policy software changes fall outside BRD. Alanscottwalker (talk) 16:53, 3 March 2018 (UTC)
@Alanscottwalker: Yes, in usual cases project wide software changes are not subject to BRD. I still claim that it applies in this case because WMF decisions beyond community review are valid when they make some attempt to acknowledge major problems which they would cause. The problematic outcome we are experiencing was never a consideration so reverting and talking it thought is more reasonable than alternatives. Obviously someone would have raised the issue if anyone imagined it; no one did. This problem is an oversight and not intentional. Also this action was supposed to benefit the community at the community's own request. The community has stake in the outcome of its own requests so enforcing this experimental new way of doing things is not an urgent indisputable need. Blue Rasberry (talk) 15:13, 4 March 2018 (UTC)
Urgent, what? It's clear the "community" went to the devs and said we do not like this arbitrary limit, so they, wholly within our policy, changed it to another arbitrary limit -- now, another part of the community is saying we like the old arbitrary limit and yet another part of the community is saying, the old arbitrary limit sucked, but there is and remains a limit. The arguments against the new limit all center around 'people act in bad faith' (which is generally not in fact, the case, and we, at any rate assume that it's not) or the peculiar case of the few who regularly pasted their entire comments instead of ever providing a summary (which, if that bothers the community, the community knows how to regulate, or practice will just change - or the community will just ignore it and go on) -- either way, as years of practice has seen (and common sense and human nature would expect), almost all people do not want to write more than they have to (which is a much greater controller than any arbitrary limit) -- as seen, if they write edits summaries, at all, they have either done a short summary or a very few have pasted what they already wrote. Alanscottwalker (talk) 16:00, 4 March 2018 (UTC)
The arguments against the new limit all center around 'people act in bad faith'... Simply not true. Poor judgment is not bad faith, and there is no WP:AGJ. ―Mandruss  16:04, 4 March 2018 (UTC)
So, we should now assume you have bad judgement, is your argument, or you oddly claim to know how to rescue people from their bad judgement. But no, the arguments are, people will abuse (bad faith) people will vandalize (bad faith) people can't control themselves (bad faith) -- they all center around bad faith - as for the people who can't improve their judgment to community standards, there have always been some, and the remedies for that have not changed, one iota. Alanscottwalker (talk) 16:15, 4 March 2018 (UTC)
So, we should now assume you have bad judgement, is your argument. Simply not true. You should not assume I have bad judgment, nor should you assume I have good judgment. Regardless, the AGF concept applies to how we regard each other individually; it does not mean that we have to apply a general "people are good" worldview in decisions like this. To whatever extent the Support arguments do consider that bad faith exists (far less than all, which is what you hyperbolically stated), I think we need to live in the environment that exists, not the environment that we wish existed. Anybody who says bad faith is too rare to factor into this decision needs to extract their head out of the sand. ―Mandruss  16:29, 4 March 2018 (UTC)
Get your head out of the sand of the imaginary world where you pretend to protect people from their bad judgment, (Wikipedia has a whole ethos on not doing that, called ROPE). No, there is actually no reason why half the people discussing here, should defer to your judgement. AGF is not a 'rule of social space' because it's imaginary, it's actually because people 'try to do the right thing' -- if people did not try to do the right thing, Wikipedia cannot exist. -- Alanscottwalker (talk) 16:49, 4 March 2018 (UTC)
  • Support. Discussion is for talk pages; edit summaries need only contain a very brief summary of what the edit does. If other languages need more space, then limit this change to the wikis in those languages. Kablammo (talk) 17:11, 3 March 2018 (UTC)
  • Support. Unlike projects with non-Latin writing, we have no need for so many characters in general; a 1000-Latin-character summary causes problems because of its length (it's 2/3 long enough for a WP:DYK article!), and it's virtually never necessary. I understand that there can be exceptions, but people like Doc James can use the gadget that expands the maximum length of the edit summary. Nyttend (talk) 20:27, 3 March 2018 (UTC)
  • Support per this edit summary. Unless rules are developed to punish prevent abuse and only specific needs for overrun are allowed, longer edit summaries are bad for the project. Chris Troutman (talk) 21:56, 3 March 2018 (UTC)
  • I don't think using an edit summary made by someone deliberately being WP:POINTy is good qualification for supporting the reinstatement of the very restrictive edit summary limit. Master of Time (talk) 23:26, 3 March 2018 (UTC)
I kinda disagree that is was POINTY behavior, as it was my own talk page, and rather than typing gibberish or unicode I wrote something constructive. For those who didn't click I wrote believes that rules should be written so that serial abusers who post hundreds of unicode characters and nonsense, and who specifically disrupt the histories, should receive sanctions ranging from receiving a personal limit of 250 characters to indefinite blocks for NOTHERE/CIR/trollish behavior. Another thing the I wish to note, if making it so EC30/500s get the 1000max is hard, make it so admins get access to the longer ES function, as Diaanna pointed out in the survey, URLs for copyright violations can be long themselves, and when you through multiple attack locations, you can run out of room quickly. In the TP use/abuse policies, clarify that communication is to take place on TP, not in the histories, and that NPA/CIVIL…. And Chris troutman, do I correctly interpret your above vote as "Until technical restrictions as to who gets to use long ES and/or polices are enacted, the edit summary length for the should returned to its prior max of 250"? Thanks, L3X1 ◊distænt write◊ 22:02, 4 March 2018 (UTC)
@L3X1: Yes, that's it exactly. Chris Troutman (talk) 22:15, 4 March 2018 (UTC)
  • Oppose. How about 500? Kevin (aka L235 · t · c) 00:05, 4 March 2018 (UTC)
  • Support. Please turn this off. It's making a mess of watchlists and contribution histories. Frankly, it's annoying enough when people routinely used the full 255 limit. If there's a need to say more, "see talk" and a brief note there is better than filling up watchlists. SarahSV (talk) 00:12, 4 March 2018 (UTC)
    • Odd, I have thousands of pages on my watchlist and it looks absolutely fine. Master of Time (talk) 00:40, 4 March 2018 (UTC)
  • Oppose (well partially anyway). I think it should be truncated a bit to 500 characters, as there's no way the full 1000 character summary is needed. But long summaries (such as undo of IPv6 users) will get chopped off if this is reverted completely. epicgenius (talk) 00:54, 4 March 2018 (UTC)
  • Oppose because the higher limit is useful for things like copyvio cleanup and reverting Ipv6 editors. I tend to be wordy in edit summaries because I like to explain what I did and why and having that extra limit (which I very much doubt I'd ever reach) is good for me. With respect to editors who copy their entire edit into the edit summary field, I found this practice to be annoying even before the increased character limit, as in this case the edit summary isn't actually a summary of the edit. I also don't need to see the same text twice (once in the edit summary and again on the page). I do support truncating the display of edit summaries in watchlists, etc, as discussed below. Ca2james (talk) 04:28, 4 March 2018 (UTC)
  • Oppose we should just be stricter about people misusing longer edit summaries eg. [32] [33] [34] [35] [36] [37] ·addshore· talk to me! 17:55, 4 March 2018 (UTC)
  • Oppose/leaning conditional Support As a page mover, I often come around when the 240ish limit is not enough. I generally pipe the links in summary so it becomes readable/accessible later while being seen in page history, and watchlist. An example would be special:diff/827568706. On a few instances, I had to use edit summary "moved per consensus on talkpage", as the link (without being piped) was taking a lot of characters. If there could be a workaround that, then I would support it completely. —usernamekiran(talk) 18:11, 4 March 2018 (UTC)
  • Support. By definition it is an edit summary. Surely those who call themselves "editors" should be able to summarize something in roughly 250 words. Readers can be directed to the talk page for longer explanations. [Which, I believe, is the function of talk pages]. Sunray (talk) 20:08, 4 March 2018 (UTC)
  • Oppose Actually, it is bytes not unicode characters. A UTF-8 character may contain up to four bytes. I've frequently been frustrated by the short edit summary limit, especially when much of it is taken up by auto-generated text. Hawkeye7 (discuss) 20:23, 4 March 2018 (UTC)
  • Support trimming it back to 255 or something like that. As noted above, long edit summaries enable editors to think that they have engaged in discussion when they have not. Robert McClenon (talk) 20:27, 4 March 2018 (UTC)
  • Oppose, since there's a JS fix below. Enterprisey (talk!) 21:47, 4 March 2018 (UTC)
  • Oppose a return to 255. I might support a limit of ~400 or 500, but 255 was often too short. --BrownHairedGirl (talk) • (contribs) 22:24, 4 March 2018 (UTC)
  • Oppose. There are a variety of situations where the capability of having a longer edit summary is useful, and all the disruption seems to be coming from the small number of metapedian editors who've developed the habit of copying the entire content of their post to a discussion page into the edit summary. Once these editors become aware of the issue, I don't think the issues are likely to continue. – Uanfala (talk) 23:53, 4 March 2018 (UTC)
  • Support—it's an edit summary, not an edit recapitulation. The unilateral, unsolicited change is a solution to a mispercieved problem. Including IVP6 twice in IP edit listings is the problem—solvable by a short place-holder link (an IP address summary). That is a task suitable to a simple algorithm. Condensing an edit summary is not easily done by Wikipedia software—it is a task for editors. If an editor can not summarize an edit enough enough for easy identification and justification, then perhaps the edit should be reconsidered. — Neonorange (talk) 00:21, 5 March 2018 (UTC)
  • Oppose More space can be useful for many tasks, as it has been noted by several editors. If clutter is a problem, just truncate at 255 the display, with a link to show the full comment, as it has been suggested above.--cyclopiaspeak! 00:27, 5 March 2018 (UTC)
  • Support This will make histories and watch lists unmanageable. Even here Rambling Man’s demo long edit summary had to be revdeleted. Summarize and take the tl;dr stuff to the talk page. This would allow verbose edit summary arguments.Edison (talk) 03:02, 5 March 2018 (UTC)
  • Support: This is the wrong way to solve the problem. The right way is to give the user 255 characters (characters, not bytes) to write a summary and then to have the software tack on any canned edit summaries such as Undid revision 000000000 by User:0000:0000:0000:0000:0000:0000:0000:000 (User talk:0000:0000:0000:0000:0000:0000:0000:000). 255 characters is plenty. Just stop using them up with IPV6 addresses and by having the` limit smaller for Unicode character. — Preceding unsigned comment added by Guy Macon (talkcontribs)
    • @Guy Macon: MediaWiki:Undo-summary already cuts back the user's contributions link and removes the talk page link for users with over 25 characters in their usernames. So it would be [[Special:Contributions/0000:0000:0000:0000:0000:0000:0000:0000]] instead of [[Special:Contributions/0000:0000:0000:0000:0000:0000:0000:0000|0000:0000:0000:0000:0000:0000:0000:0000]] ([[User talk:0000:0000:0000:0000:0000:0000:0000:0000|0000:0000:0000:0000:0000:0000:0000:0000|talk]]), which is much longer. Just wanted to point that out. epicgenius (talk) 18:02, 9 March 2018 (UTC)
  • Oppose. I can see why the higher limit helps with some real cases, and it's silly for the English Wikipedia to campaign against a feature that affects every project (or try to be a special exception to that feature) just because of our own habits. rspεεr (talk) 08:06, 5 March 2018 (UTC)
  • Strong oppose. I fail to see the problem here. Even on my small screen I have no problems reading longer edit summaries. See Uanfala's comment above as well.--Jasper Deng (talk) 10:57, 5 March 2018 (UTC)
  • Oppose, the old limit has caused problems here (undo autosummaries that can't be annotated etc.) The new length results in new potential problems, but it is up to us as a community to make those rare (tell off people who use edit summaries to discuss instead of summarising the edit). Users can also be asked by technical means to use short edit summaries where possible. —Kusma (t·c) 12:01, 5 March 2018 (UTC)
  • Oppose, per opposing rationales above. I also think it is a big improvement because it gives the opportunity to good-faith editors to express in detail their position, when needed. Sure, like many functions on Wikipedia, it can also be abused, but this is not a reason to disallow it. Disruption can be handled whenever it arises. I also think this feature will save editing time. From my own experience, I was caught many times trying to delete characters from my edit-summary to accommodate the previous shorter length requirements. That editing procedure took a long time sometimes. With the new length, this vetting will be a thing of the past and it will save time. Dr. K. 19:42, 5 March 2018 (UTC)
  • Oppose. If you don't want to read a long edit summary, don't read it. --Tryptofish (talk) 21:13, 5 March 2018 (UTC)
  • Weak support - Hate to be a party-pooper, but the new character limit is way too easy to abuse. It doesn't appear to have been implemented very well either. Maybe trim it down to 300 characters per edit summary. Kurtis (talk) 21:42, 5 March 2018 (UTC)
    Changed to oppose. Then arguments in favor of longer edit summaries have swayed me. Kurtis (talk) 09:45, 9 March 2018 (UTC)
  • Oppose. On the whole, I think there are more positive aspects than negative aspects in extending the character limit from 250 to 1,000 characters. Regards, AzureCitizen (talk) 22:59, 5 March 2018 (UTC)
  • Support. As with other undiscussed changes, revert to the former state and hold a proper discussion. If there's then a consensus to implement it, wait to do so until a method of hiding the more ridiculous results is also ready for implementation. Meanwhile, people can continue to replace the IPv6 addresses with "IPv6 editor", and use "please see talk" if they run out of space. Justlettersandnumbers (talk) 14:15, 6 March 2018 (UTC)
  • Oppose Proposal has no basis. Saying problems like "these" doesn't make it a real problem. One more usage case, in addition to the above presented reasons would be bots; edit summaries by bots often include a descriptive edit summary, a release version number, a link to the bot OP's page and some have their unique edit ID, reverting it back to 250 will need to cut back on atleast some of the factors required to make a proper edit summary to assist people. --QEDK ( 🌸 ) 17:41, 6 March 2018 (UTC)
  • Exceptionally Strong Oppose. To be honest, I was unaware that this feature had launched, but I applaud the implementation of this long-overdue tweak. The previous limit was a frequent and needless limitation and holdover from a simpler era in our editorial processes. I'll be plain: I don't think the strong majority of edits require nearly so many characters. Indeed, I don't think the majority have ever needed as many as the 200 or so previously allowed. But for certain work in certain areas--including but not nearly limited to those where it is useful to retain details regarding reversions and to explain one's quasi-administrative actions in detail. For example, I volunteer as a pending changes reviewer, and I feel compelled when rejecting an edit on a protected page to provide an explanation which is clear and gives both the proposing/novice editor good information on why their edit was found problematic and gives the other local editors a clear notion of what is going on when they look at the revision history. That's a tall order before you even add inthe fact that you lose space identifying the edit as a pending changes reversion, and probably the party as well, before you get into the substance of the issue. That's just one of many cases that I can think of off the top of my head where one is likely to run up against the previous character limit, and I'm sure others have notions from their own idiosyncratic experiences that I wouldn't even think of.
Addressing some of the reasoning for rolling back this change, the concern I find most credible is that there's a lot of potential for abuse here. Well, that's true with regard to edit summaries in general, but this change does not substantially alter the equation with regard to those problems. We have plenty of administrative tools to restrain or block those who will fill the field with trolling, just as we did before. The same goes for those who cannot grasp that the purpose of the edit summary has not itself changed and constrain their comments accordingly. There might be an adjustment period, maybe even a need to tighten some policy language here and there, but I see no reason to assume that this will not be a massive net positive in the long run. I've also seen some editors make some more specious claims, like "they just want an increase here, because they saw it happen on Twitter". I would propose to anyone making an argument such as this that if you are ready to jump to an analysis of your fellow editors' !votes that assumes said editors are borderline idiots operating on a "monkey see, monkey do" level (rather than making a good faith assumption that said editors are speaking from their own idiosyncratic experiences working in disparate parts of the project) that this is a red flag that you may be prone to cognitive biases (my side bias and the availability heuristic in particular) that could be colouring your interpretation of this issue. All of that said, there may be a reasonable compromise here (500-750 is probably more than sufficient for even most complex edit summaries, afterall), but I strongly oppose a return to the old limit. Snow let's rap 21:25, 6 March 2018 (UTC)
  • Oppose clearly see more positives than negatives.Pharaoh of the Wizards (talk) 03:11, 7 March 2018 (UTC)
  • Oppose - More than once, I wanted to use an edit summary along the lines of rm [[:Category:Foo]] per [[Wikipedia:Categories for discussion/Log/20$$ $$$$ $$#Category:Foo]], or even rename [[:Category:Foo]] to [[Category:Bar]] per [[Wikipedia:Categories for discussion/Log/20$$ $$$$ $$#Category:Foo]] for long category names, but couldn't do so. עוד מישהו Od Mishehu 14:59, 7 March 2018 (UTC)
  • Oppose—I just came across this official action whose edit summary was apparently truncated according to the old limit. The new limit of 1000 must have been arrived at in consideration of the impact on the system made by longer edit summaries, and so the longer limit should stand, although I see the likelihood of a compromise limit. Having the ES display adjustable according to individual preferences seems to be something that is easily implemented and is the answer to those who find longer displays distracting . Dhtwiki (talk) 23:22, 7 March 2018 (UTC)
  • Oppose There have been a few times I have found the old limit restricting. See this as a net positive. AIRcorn (talk) 00:06, 8 March 2018 (UTC)
  • Partial Oppose General consensus is that 1000 limit is too long and 250 is too short, so reverting back isn't ideal. I support alternate solutions discussed here.   —  Hei Liebrecht 18:52, 8 March 2018 (UTC)
  • Oppose per above. Jjjjjjdddddd (talk) 15:42, 9 March 2018 (UTC)
  • Oppose - Every once in a while I get cut off when I'm running a long link into an edit summary to footnote something that doesn't need a footnote in the piece (say, a nickname in the lead). This expansion of characters is no problem until it proves itself a problem. Carrite (talk) 21:31, 9 March 2018 (UTC)
  • Oppose. Edit summaries serve more than one purpose. For many edit summaries there is more than enough space. But sometimes you want to explain your reasoning from the outset, rather than engage in the more tedious process of Talk page discussion. Edit summaries not only say what you've done but allow you to respond to anticipated objections. Let us not forget that "orangutans are skeptical of changes in their cages". The additional space allows one the opportunity to explain oneself. Yes, this additional space can be misused. Misuse of edit summaries should result in stern warnings and blocks. Bus stop (talk) 12:19, 10 March 2018 (UTC)
  • Oppose - I'd rather have "too much" space than not enough space. The latter is objectively a problem when it arises. "Too much" space? I'm inclined to agree with the many users above who so delicately suggest that this is a made up "problem". Swarm 19:31, 10 March 2018 (UTC)
  • Oppose, but I would not object to a limit of 500 bytes, or of 255 characters plus automatic stuff (section headers and undid notes). I have never understood people copying their replies into the edit summary, and the problem with them doing it under a 1000 byte limit is not the limit but the user (even if it was an acceptable practice before and the user is acting in good faith, they should adapt to better practices now). I would also support truncating the comment at some smaller limit (150 or 255 characters, for example) by default when viewed in watchlists. The biggest problem I see is vandals spamming 1000 byte comments – though I wonder how likely this is as I can't recall many 255 byte comments on vandalism edits (maybe LTAs would catch on and cause quite a mess). Bilorv(c)(talk) 07:37, 11 March 2018 (UTC)
  • Oppose, it's harmless. Stifle's non-admin account (talk) 14:27, 12 March 2018 (UTC)
  • Split the difference, make it 500. I tend to make big edits encompassing a number of changes, and I also like to explain my rationale, so I've appreciated the countdown of how many characters I have left, and I like having more. This is an example of an edit that I suspect some won't like, so I appreciated being able to explain in detail. After seeing the fun at Iridescent's talk page (and not being able to see many of the symbols, and having my usual problem not being able to make out most emojis at text size and not knowing how to blow them up), I agree that 1,000 is way too big because it will be misused. But I have found the old limit problematic. Yngvadottir (talk) 20:43, 12 March 2018 (UTC)
  • Support – This really encourages lengthy debate via edit summaries, and discourages talk page threads; will inevitably lead to drama, and probably already contributes to weaker understanding between editors and lost productivity. At first I didn't want to comment because I was swayed by arguments saying that's just an issue of individual behaviour. But then I kept seeing plenty of examples in my routine watchlist, i.e. just now this one on German Empire. I am now convinced this tool is influencing behaviour, and therefore should be restrained to the usual 250-ish character field. If that's a problem for some languages, it's a debate for their own wikis to change their settings according to what works best for them, not for the English-language Wikipedia. — JFG talk 21:14, 12 March 2018 (UTC)
  • Oppose The benefits of this are much greater than the downside. If a user abuses this function then discuss it with them, but don't let them ruin it for us all. Emir of Wikipedia (talk) 20:48, 13 March 2018 (UTC)
  • Strong oppose Artificial restrictions from software are silly. Using a clickable [...]-to-expand button, as suggested by several people, would fix this. Personally, I'd get rid of the limitations entirely, and allow unlimited-length, automatically paginated edit summaries, but at a certain point the effort to implement that would get a bit silly, so 1000 bytes seems like a reasonable compromise ;) —{{u|Goldenshimmer}}|✝️|they/their|😹|T/C|☮️|John 15:12|🍂 22:05, 13 March 2018 (UTC)
  • Oppose As stated above, gets a bit short with IPV6. Icarosaurvus (talk) 18:18, 14 March 2018 (UTC)
  • Support Summaries should be concise and lengthy explanations and discussions posted in Talk pages; we should not be encouraging extended discussions in such an extremely limited medium as edit summaries. However, I am extremely pessimistic that even if there were overwhelming support for this requested change - and there clearly isn't - that the developers would make the change given the long history of changes being made with little consultation, testing with editors, or responses to feedback. ElKevbo (talk) 03:45, 15 March 2018 (UTC)
  • Oppose per Legoktm. Allowing longer edit summaries is an improvement. feminist (talk) 05:17, 15 March 2018 (UTC)
  • Oppose, but... In some cases, it is very practical to have more than 250 characters to summarize one's edit. That being said, I do agree with the problems enumerated, but I reckon finding a middle ground (like 500-600 as people above have suggested) is reasonable, considering there must be other solutions to the issues below. In short, don't go back to 250, do reduce the limit to an in-between number as per concesus, and do open a new discussion to fix the problems related to this. Thank you. Double Plus Ungood (talk) 14:39, 15 March 2018 (UTC)
  • Oppose Maybe 1000 is a bit long but I agree the previous 255 was a bit short. As others have said, one particular example would be reverting IPv6 edits where you get very little room to explain any changes. Also with long section headings where you're prefer to keep the heading. While it's true there are more avenues for abuse, misuse and poor use with longer edit summaries, it's not likely there aren't serious possible problems already hence why removing edit summaries isn't unheard of. For the problems, we just deal with them as we always do. So overall a net positive. I'm fine with clickable long summaries etc but think the longer summaries should stay until this is implemented. Nil Einne (talk) 20:02, 15 March 2018 (UTC)
  • Comment Can we just put it to something like 500? 1000 is a bit big, but 255 was so small that undoing an IPV6 meant that almost the whole edit summary was taken up by just the links to the contributions and the talk page, a stopgap measure was made by removing the piping, but it made it ugly. With the 1000 character limit, it's easy to make disruptive summaries that stretch the page, and admins have better things to do than revision deleting those. Just imagine if we had this in the time of Grawp. *shudder* Gatemansgc (TɅ̊LK) 01:02, 18 March 2018 (UTC)

Identified problems

The whole discussion is conflating many, many potential issues, so I figured we should keep a list here of real and/or potential problems with the new limits:

  1. People being nitwits / vandals abusing this feature to create edit summaries near the 1000 limit for no useful reason (vandalism or WP:POINTY)
  2. People who used to rely on shortening of edit summaries when pasting their reply to a comment into the editsummary (a habit)
  3. Automatic edit summaries like MediaWiki:Autosumm-replace and MediaWiki:Autosumm-new which add the entire wiki text content into the edit summary. This happens for new pages, file uploads and with people replacing the entire content of a page (technical issue?)
  4. People might use edit summaries as the discussion platform instead of talk pages (especially for newbies, this is likely to be a problem I suspect) (a UX issue)
  5. When edit summaries ARE long, they take up a lot of space in the views of the page history, logs and recentchanges/watchlist feeds. This makes it harder to look at multiple entries at the same time, potential making vandal fighting more cumbersome, but also just overflowing the pages with information. (a UX issue)

Each of these issues might have one or more potential solutions. Please keep discussion with regard to solutions etc, in the Discussion section. If you have identified additional problems, you may add them here. —TheDJ (talkcontribs) 10:02, 5 March 2018 (UTC)

Autosumm-replace and autosumm-new still truncate at 200 bytes minus the byte-length of the messages themselves. See testwiki:Special:Diff/349059 and testwiki:Special:Diff/349060 for examples. Uploads, on the other hand, do not do their own truncation and so reach the 1000-character limit. Anomie 13:19, 5 March 2018 (UTC)
A good example of the "people using long edit summaries instead of Talk" problem can be seen in the current edit war occurring at Columbia University. ElKevbo (talk) 22:07, 15 March 2018 (UTC)
OTOH, that assumes they wouldn't just use less verbose summaries if the limit were shorter. Anomie 11:22, 16 March 2018 (UTC)


  • For an example of what how potentially disruptive this could be, see Special:Diff/828335644. I'm not calling out the editor who made that post, since it's likely they didn't know about the change in limit, it was just what brought the issue to my attention. Primefac (talk) 23:53, 1 March 2018 (UTC)
  • You can name me. I am somewhat embarrassed, but no, I had not idea. I like to copy my entire post into the clipboard, in case of edit conflict or browser crash, but I see there will now be a big problem. Until today, the edit summary was limited to two lines. --SmokeyJoe (talk) 23:57, 1 March 2018 (UTC)
    Wow! I used to do this as well, until an editor complained about it. –xenotalk 18:53, 2 March 2018 (UTC)
  • Bad solution, but status quo ante sucks almost as much. Take for example the case of an undo of an edit made by an IPv6 editor. You have to remove the talk page link to have much room at all, and often even that's not enough to explain your revert adequately. Ideal solution would be a length that is variable depending on what's already there, always allowing for x number of additional characters. Surely that's do-able? ―Mandruss  00:08, 2 March 2018 (UTC)
  • I can see that this solution is going to be a problem at times, but I've been running into the too-short summary limit since we started seeing IPv6 addresses. By the time an automated summary links to both the IP address and the IP's talk page there isn't all that much room left over. Even just getting rid of the talk page link would be an improvement. Meters (talk) 00:17, 2 March 2018 (UTC)
    If you use tools like Twinkle for such things then the request can be made at WT:Twinkle or if you have a github account on their respective pages. If you are talking about the automatic "undo" summary then perhaps MediaWiki:Undo-summary is the change you are looking for? --Majora (talk) 00:22, 2 March 2018 (UTC)
    If one is more interested in the overall project than their own needs, they prefer site-wide solutions over single-user ones. (I don't use Twinkle for reverts.) ―Mandruss  00:37, 2 March 2018 (UTC)
    Changes to the tools people use and the site settings that dictate things would be site-wide. Now that I look at it more, it appears that the automated edit summary on undos was already changed to accommodate IPv6 address as well as long usernames. This change seems like a gross over correction. I'm of the opinion that it needs to go back to the drawing board and a more adequate solution needs to be worked out by the devs as to not hammer in a solution, globally, that could cause such problems like filling up histories and watchlists. --Majora (talk) 00:46, 2 March 2018 (UTC)
    For "undo" summaries I often just highlight and delete the "talk page link" portion if I need more room - occasionally I might just remove the whole "autogenerated" portion and replace with my own summary, but the need to do this has been very rare. -- Begoon 02:49, 2 March 2018 (UTC)
  • Just as a note, there's various Phab tasks related to the change. phab:T185948 is probably the most specific task, and phab:T6714 and phab:T6715 are also relevant. --AntiCompositeNumber (talk) 00:41, 2 March 2018 (UTC)
  • My edit summaries are annoying me everywhere I look. How about an edit summary checkbox "allow expanded summary", with its default state set in your preferences? --SmokeyJoe (talk) 00:48, 2 March 2018 (UTC)
    • Seems useful, so as to not break workflows of people like you who paste in their comments.. Galobtter (pingó mió) 07:23, 2 March 2018 (UTC)
      • There used to be such a feature, but then edit summaries were increased to 255 characters for all users. oknazevad (talk) 19:00, 2 March 2018 (UTC)
  • The change probably cannot turned off in any meaningful sense. I would rather put something in WP:Edit summaries that people should tend toward shorter rather than longer summaries. SmokeyJoe (Headbomb does it too) probably shouldn't copy and paste entire messages into the edit summary box anymore but instead actually summarize his comment. --Izno (talk) 01:09, 2 March 2018 (UTC)
    I'm guessing that would have about as much effect as WP:SIGAPP - a Wikipedia policy. ―Mandruss  01:17, 2 March 2018 (UTC)
    I have seen SIGAPP required of persons (and blocks provided until compliance). --Izno (talk) 01:57, 2 March 2018 (UTC)
    Too rare to be significant. ―Mandruss  11:14, 2 March 2018 (UTC)
  • A possible solution would be after a certain length, that a dialog box prompt you that it's considered longer than average. I doubt most of the editors who appear to be abusing this are aware of the issue. A prompt, in these cases, would cause editors to be aware of the situation, and thus would prevent long summaries in most cases. I also like the idea of manually having to check a box to allow an extended summary. That said it probably should just disappear all together. --Deathawk (talk) 02:24, 2 March 2018 (UTC)
  • We need to stop approaching every change with "ugh this is bad lets turn it off" and "clearly no one thought this through". This has been in the works for YEARS and is one of the most wanted requests from the global Wikimedia Community. Here's my proposal: Allow people to save the full length of edit summaries in the database. On places where vertical room is limited (history/watchlist/etc.), do truncation based on the visual length (not wikitext length), add a clickable "..." to the end that will do full expansion. That allows complex characters and fixes IPv6, etc, while hopefully preventing the problem of longer summaries. Legoktm (talk) 04:02, 2 March 2018 (UTC)
    Saying we should stop saying "no one thought this through" while simultaneously stating a potential fix that would have solved all of this before it started seems a tad ironic. --Majora (talk) 04:05, 2 March 2018 (UTC)
    I was referring to the rhetoric being used. Given the complexity required by this change I'm not surprised something got missed. And I wish people took a moment to think about how there might actually be a good rationale behind the change before immediately jumping on it for being bad. Legoktm (talk) 04:15, 2 March 2018 (UTC)
    I'm all for the truncated version. I also understand the rationale for doing it. I'm also still on the side of undoing the change until the fix you mentioned above is deployable at the same time for the reasons I started this RfC. --Majora (talk) 04:22, 2 March 2018 (UTC)
    • Support Truncating the display, with a clickable "..." to reveal the rest of it, I think is a fantastic idea. Then everyone wins :) Because it's true even on enwiki we do run into issues with the summary being too short, such as page protections and reverting IPv6. For the record, I'm not sure everyone is simply adverse to change, or questioning the merit of this feature. Rather, it was clear there could be problems with display like the example diff, and that it's possible the edit summary would become some new unwarranted venue for discussion, especially when edit warring. If the display is truncated, that'd be enough to discourage misuse, and we still get all the benefits. MusikAnimal talk 04:18, 2 March 2018 (UTC)
    • I suggested this above (or similar) as well, so obviously support FACE WITH TEARS OF JOY [u+1F602] 11:14 pm, Today (UTC−5)
    • I'd support this, but I think the current rollout should be disabled until this can be fixed. It has too much potential for disruption (and not just with watchlists. The potential for fights when in content disputes are also a factor). I don't think the positives of the untruncated version outweigh the negatives at this time. TonyBallioni (talk) 04:17, 2 March 2018 (UTC)
    • Hmm, I think IPv6 thing could be more elegantly fixed with a limit to visual length or if not, then a limit of 400 characters or something should be enough, not sure we should encourage/allow over-long edit summaries, I could see them being annoying even if hidden. Any problems with summary length usually from links personally Galobtter (pingó mió) 07:08, 2 March 2018 (UTC)
      • I can't think of any genuine needs for edit summary visually longer than 255 chars or with a total length > 400 Galobtter (pingó mió) 07:11, 2 March 2018 (UTC)
      • I'm also wondering if long edit summaries will break any tools like huggle/stiki, or at-least not work well for them Galobtter (pingó mió) 07:11, 2 March 2018 (UTC)
      • I also support atleast temporarily disabling until this is fixed; also wondering if forcing short edit summaries may force people to the talk page atleast occassionally.. Galobtter (pingó mió) 07:19, 2 March 2018 (UTC)
    • FYI, Allow people to save the full length of edit summaries in the database is 65535 bytes. ;) Anomie 12:25, 2 March 2018 (UTC)

I have problems with this.

1. Some section names are long. This would clip the meaningful part of the edit summary, eg

/* Question about using your image in my article about bananas */ replied to Longtailedlemur and Chad

2. This could be confusing for new users. I would recommend to have this as an opt-in (or at least opt-out) feature.

3. People who abuse long edit summaries would abuse short edit summaries too.

4. This needs to use JavaScript, so it would need to be written as a gadget. Without checking whether the user is viewing a relevant page (such as recent changes or diff preview etc), my codes are included below.

Like this (truncates to 300px width, does not look well with diff previews)

// Shorten all edit summaries to 300px
$('.comment').prop('style','text-overflow: ellipsis;width:300px !important;overflow:hidden !important;display:block;white-space: nowrap;')

// Unshorten the edit summary when clicked

Or like this (truncates to n characters).

var n = 80;
	var original = $(this).text();
	var shortText = original.length > n ? $.trim(original).substring(0, n).trim(this) + " [...]" : original

5. When expanded, is it necessary to collapse the edit summary back on a second click? That's something I did not write above.

--Gryllida (talk) 05:19, 2 March 2018 (UTC)

  • I am not a member of English Wikipedia community, but since there is inherently more chance that they would listen to you than to other Wikimedia communities on this matter, I want to completely support this proposal (of reverting this change globally, to be completely sure) here. Seems like Russian Wikipedia community voted in 2016 on a good proposal to get our edit summaries up to your limit (since in Russian you could enter only 128 symbols in edit summary before), but it was turned into a complete travesty on global level. There was no consensus on 1000 symbol edit summaries, there is no consensus on 1000 symbol edit summaries, the fact that they did this is atrocious. Any hacks that are proposed here (hiding some parts of edit summary etc.) are just hacks to curb Wikimedia community opinion after not asking one (since Community Wishlist proposal was explicitly about non-Latin communities and their database-imposed limits to edit summary length). Saint Johann (ru) 10:53, 2 March 2018 (UTC)
  • Question for Legoktm, MusikAnimal, and others supporting the proposed solution — at the risk of spilling the WP:BEANS, wouldn't such a solution be the perfect place for vandalism? Make an edit, have a longish edit summary, but just beyond the cutoff for "show more" you can insert whatever insults. I suppose the answer is that folks will have it unhidden by default, but seems like it could make for a lot of extra clicking when checking diffs. Fixed pings, I need my tea ~ Amory (utc) 11:27, 2 March 2018 (UTC)
    Hidden vandalism is better than not hidden, right? ;) I'd hope most of it would get caught by patrollers, but yes a simple user script/gadget could make it always show the full edit summary for those who want to. I doubt we'll introduce a preference, too many of those as it is. MusikAnimal talk 16:35, 2 March 2018 (UTC)
  • @Majora: The phab ticket you mention in the suggestion (phab:T6714) was outdated (apologies for that). Although this was in the German-speaking 2013 survey, we have not been part in this change (be it good or bad). The reasoning behind the change seems to be explained here. Would it be possible to update the intro accordingly? Thanks, Lea Voget (WMDE) (talk) 12:49, 2 March 2018 (UTC)
    Please accept my apologies Lea Voget (WMDE). That was the phab ticket that I saw and the header stating that it was on the top 20 German Wikipedia wishlist along with a link to a dewiki thread caused me to jump to an incorrect conclusion. I do apologize for that and I have struck the part of the RfC that stated that it was a dewiki proposal. --Majora (talk) 21:17, 2 March 2018 (UTC)
  • By all means invite people to debate via edit summaries rather than the talk page and fill up watchlists as a result of this "solution". But if the result is my having to read through pages of waffle because this has left room for about half a dozen changes to the page on a perfectly reasonable laptop screen I, for one, will be finding another way to spend my time. Britmax (talk) 14:42, 2 March 2018 (UTC)
  • I cannot understand what the people who implemented this were thinking. Why in the world would they make such a dramatic change to the user experience and not get prior buy-in? Jytdog (talk) 15:49, 2 March 2018 (UTC)
  • This RfC is not neutral, nor does it attempt to express the situation in an even manner. Leading with declarations such as, "It will do nothing more than cause massive disruption in the histories of numerous pages." is not exactly assuming good faith. :) I really think we can, and should, do better in framing the situation so that all participants can have a clear and equal understanding of the facts before asking for community feedback. I suggest the creator work with interested parties to provide more context for the reason for the change (with references to existing discussions) and try again. As it stands now I can't in good conscious participate in such one-sided propaganda. Ckoerner (talk) 16:36, 2 March 2018 (UTC)
    • Addendum, as I wrote this I think I understand what people mean when they say the RfC process is broken. It's not necessary broken (nor is it perfect) but the glib way in which they are written leads to an oppositional argument easier than a congenial discussion. Ckoerner (talk) 16:39, 2 March 2018 (UTC)
    • Maybe WMF should try to explain their decisions beforehand, especially the decision to stump through from the original standpoint of ‘non-Latin communities want the same length of edit summaries as other communities’ right to ‘1000 characters for everyone, let’s write essays in edit summaries’. I feel like decision-makers in individual communities have a lot more responsibility and accountability in their communities than Wikimedia Foundation has in entire movement. And it really shouldn’t be like this. I was made more accountable over changing one template through a discussion in my home project than entire team that made this change without any discussion was made accountable over this. Something is entirely wrong not in the way communities respond to non-discussed changes, but in the way WMF is being dishonest and not upfront to their communities (not only English one, I want everyone to remember that, English Wikipedia gets it easy relative to others). stjn[ru] 17:45, 2 March 2018 (UTC)
      • I think part of the problem is that the WMF is outnumbered in the many voices of representation. It's entirely plausible that the folks who enacted this change were following the desires of a community - that of the folks who participated in the wishlist proposal. That group said please do this for us. The team went and did that work. Which I think is healthy and how most folks would like to operate. Now they turned it on, and part of another community, with some obvious overlap, is upset. This comes through in the tone and framing of the RfC and comments like one one succeeding yours. In this situation the folks from the WMF (obviously not the entire WMF as we are not monolithic as some might think) is stuck in a position of damned if we do, damned if we don't. I think there's an opportunity to learn how to make our relationship healthier - in both directions. My suggestion, if we continue the RfC process as a means to understand community consensus - particularly around software changes/updates/configs - is that said proposals should be drafted together, not as one side in opposition to the other. We're all on the same side. Ckoerner (talk) 21:06, 2 March 2018 (UTC)
        • @Ckoerner: the matter of the fact is, you can find my own vote in your link under #34. But the thing is, I am more than sure that both the proposer and the voters didn’t give the Foundation and its developers the opportunity to do whatever the hell they like by their vote. The people there wanted to have parity with English-speaking colleagues in the number of characters, no one was talking about increasing limit up to thousand characters.
          WMF even understood this as we see in ‘We don't want to encourage Latin languages to post 3x longer edit summaries, because edit summaries aren't intended to be a primary communication method’. But someone clicked along the way, someone thought it was good idea to seek consensus where there is none, and someone did this their own way instead of implementing wishes of communities that you are talking about. At this point it is pretty hypocritical to talk about the tone of discussion, because there was none prior.
          And the less discussions are happening, the less of the same side we are on. I want to believe in all the good work the Foundation does, but frankly WMF developers get to stump through with any changes they like without any hesitation or need to at least ask at some point in time. If we are on the same side, we both should act like we are on the same side. And the main responsibility for this is on the side of powerful, not on the side of weak (which, in this case, is the Wikimedia community). stjn[ru] 21:29, 2 March 2018 (UTC)
          • I'm sorry my attempt to have a conversation with regards to how we can all improve is met with more finger pointing and stress than I care to engage with. I appreciate your feedback, but am ending my part in this conversation. Thank you. Ckoerner (talk) 23:10, 2 March 2018 (UTC)
            • Sorry my attempts to get information out of people who defend making change this way were perceived that way. Of course, you are in your own right to not respond to WMF-related criticism over this situation, but the fact is that someone should. stjn[ru] 10:21, 3 March 2018 (UTC)
      • User:Ckoerner what is fucking broken is the way the WMF interacts with the editing communities. Jytdog (talk) 19:43, 2 March 2018 (UTC)
        WMF interacts with the editing communities? [citation needed]. Kablammo (talk) 00:46, 3 March 2018 (UTC)
        • @Jytdog: - cause getting irrationally angry and all up in someones face like that with swearing is gonna help. Seddon talk 22:45, 2 March 2018 (UTC)
          • Yes anger is irrational. So is relentless fuckwittery from the WMF. Are you aware that Ckoerner is their fucking liaison person? Their comment above is probably the most incompetent piece of liaisoning I have ever seen. wtf. really. Jytdog (talk) 22:55, 2 March 2018 (UTC)
            • Yikes. Yeah, that was quite a tone deaf response for a liaison. Lepricavark (talk) 23:02, 2 March 2018 (UTC)
              • My comments here are in my role as a volunteer. If anyone has an issue with my performance as a staff member you are welcome to bring it to the attention of my supervisor. I'm stepping away from this...well, not quite a conversation, to enjoy my weekend. I hope you enjoy yours as well. Ckoerner (talk) 23:10, 2 March 2018 (UTC)
              • @Lepricavark:Ckoerner made his post under his personal account, something that is perfectly reasonable and fine. So is calling for rational discussion and debate. What is not reasonable and fine is Jytdog's reaction. Our policies dictate that one remain respectful, even when one is upset. I would hope that you don't think that is behavior to be emulated. Keegan (talk) 23:18, 2 March 2018 (UTC)
                • Yes, it's fair point to point out that Ckoerner was posting under his personal account. As he has walked away from the discussion, I'll leave it at that. Lepricavark (talk) 23:32, 2 March 2018 (UTC)
                  • I think WMF employees should be more aware that most people aren't going to see the distinction, and that it can cause frustrations with community members, but I also think that Legoktm's proposal to fix is a good one, and I understand Keegan's frustrations about how they are sometimes treated by the community (as one of the people most involved in implementing ACTRIAL from a community perspective, I am well aware that the WMF actually does want to do their best to help support the projects, and I appreciate that dealing with volunteers who think the worst of them can be frustrating and make them not even want to engage).
                    I think this was a bad idea to rollout in the current form on, but I get why it was done, and I am grateful that we have people thinking about other language groups who also should have access to a free content encyclopedia in their language of choice. They should be treated with respect in all circumstances, even when there is disagreement with actions of the foundation. TonyBallioni (talk) 01:10, 3 March 2018 (UTC)
                    • As a prominent critic of the WMF's community engagement, and as someone currently angry about the WMF battling a Commons consensus to uninstall Flow, I have to say the hostility and profanity doesn't belong on this one. This started as an absolutely legitimate task to fix edit summaries for other languages. When the technical-limit of 255 bytes went away it was an unfortunate but understandable mistake to "generously" raise the limit to 1000. And most importantly, the WMF is clearly eager to fix this. Let's reserve the hostility for cases where the WMF isn't willing to work with us. Alsee (talk) 11:37, 5 March 2018 (UTC)
  • What would be helpful is an option to subdivide the edit summary and have 200 bytes for the edit summary you are writing in addition to the generated edit summary that lists the section name (which really should not be too long). But with long IP names reverting edits by one long IP name to another long IP name can generate a lot of bytes. The ability to add up to 200 bytes to such a generated edit summary would occasionally be useful. ϢereSpielChequers 20:31, 2 March 2018 (UTC)
  • Question: I've seen a couple of folks mention "this will be confusing for new users." Can you please elaborate? Why would allowing extra text in a box be confusing? If they're new, they're not used to the old limits, so what about the new limit is surprising? I'm genuinely curious. FACE WITH TEARS OF JOY [u+1F602] 05:39, 5 March 2018 (UTC)
  • Copyright violation within the edit comment is a risk, such as possibly this edit's comment being taken from here (in this example the source may be out of copyright). Batternut (talk) 10:17, 7 March 2018 (UTC)

Community Wishlist team response

Hi everyone — I’m Trevor, a product manager at the Wikimedia Foundation with the Wishlist team. I’ve just read up on this entire thread and have conferred with some colleagues about this change. I’d like to start off with an apology — we’re sorry this caught you by surprise and we’re sorry for the interruptions it’s causing. We knew that this has been a big problem for non-Latin languages. We should have communicated more about the trade-off for English.
We agree that edit summaries should be brief updates to inform others about what an edit contains. It’s not an appropriate place to rant, converse, or ramble. We want to help alleviate potential abuse. The current suggestions we find most promising are:
  • Lego and 😂’s idea to truncate long summaries on Recent Changes, history, and other log pages with an an ellipsis that expands on click. This is very quick for us to build, test, and release.
  • Truncate long summaries on Recent Changes, history, and other log pages with an ellipsis that does not expand. To view the full summary, the diff page must be viewed.
  • Deathawk’s idea of displaying a warning when an edit summary is longer than average. This is a larger amount of work to support in all major editing tools and will take more time to build, test, and release.
  • ViperSnake’s idea of setting up an edit filter to monitor summaries so we can all gain a better understanding of how these long summaries are actually used in the wild.
  • Any others?
We propose truncating the summaries on history pages, etc. and exploring an edit filter to monitor the situation. We believe these will address the most common problems highlighted in the survey and discussion above. What do you think? — Trevor Bolliger, WMF Product Manager (t) 23:40, 2 March 2018 (UTC)

@TBolliger (WMF): I think there's a very strong consensus to truncate everywhere. There's somewhat of a debate between expandable or non-expandable, but if the information is stored, then it has to be accessible in someway, so expandable seems to make the most sense. No opinion on the edit filter, but that doesn't sound silly, so why not? Headbomb {t · c · p · b} 01:08, 3 March 2018 (UTC)

Hi Headbomb. Thanks for suggesting that expanding ellipsis is better. I agree. Do you want to test the expandable ellipsis JavaScript code I gave above? I believe if you put it in Special:MyPage/common.js then it would work. (I have also put it to User:Gryllida/js/truncateEditSummaryWithClickableEllipsis.js.) --Gryllida (talk) 01:22, 3 March 2018 (UTC)
@Gryllida: This is great, thanks for making this and sharing with us! When our team explores phab:T6717 next week we'll look into your script. I think the ellipsis could potentially be visually differentiated so it doesn't look like it's part of the summary. Also, on hover the cursor should be a clicky-hand so it's apparent an action occurs on click. — Trevor Bolliger, WMF Product Manager (t) 18:05, 3 March 2018 (UTC)
Added. --Gryllida (talk) 01:44, 5 March 2018 (UTC)
@Gryllida: Nice! — Trevor Bolliger, WMF Product Manager (t) 23:09, 5 March 2018 (UTC)
Hi Trevor Bolliger, WMF Product Manager. My opinions:
1. "truncate long summaries on Recent Changes, history, and other log pages with an an ellipsis that expands on click" COULD be opt-in: any interested contributor can enable this, and only for wikis which request this feature.
2. "Truncate long summaries on Recent Changes, history, and other log pages with an ellipsis that does not expand. To view the full summary, the diff page must be viewed." MUST be opt-in. A contributor making a long and legitimate edit summary probably wants it to be visible to others straight away.
3. You said, "Deathawk’s idea of displaying a warning when an edit summary is longer than average. This is a larger amount of work to support in all major editing tools". What are these major editing tools? Visual Editor already clips the edit summary to 255 characters anyway. (This is inconsistent, I would probably fix it?)
Codes for Wiki Editor, or users of no enhanced editing toolbars, with a threshold of 10 characters as this makes testing the code easier and quicker (you may adjust the threshold as needed):
shows long edit summary warnings from a javascript
Version 1: shows the warning as a text below the edit summary: [38]
Version 2: marks the counter in orange: [39]
Version 3: marks the counter in orange and draws an orange border around the edit summary box: [40]
Version 4: marks the counter in orange and draws an orange border around the edit summary box and shows a warning as a text below the edit summary: [41]
4. "setting up an edit filter to monitor summaries so we can all gain a better understanding of how these long summaries are actually used in the wild." this MIGHT be interesting. I do not find this terribly useful, but I do not mind this as long as it does not prevent the editor from saving the page. I would say such filters should vary per-wiki rather than being global.
--Gryllida (talk) 01:17, 3 March 2018 (UTC)
@Gryllida: Oh, correct. VisualEditor (and the 2017 Wikitext editor) already truncate at 250. In this case, we'd just need to change the behavior of the 2010 wikitext editor. On my first (Saturday morning) glance, I think I prefer version 1, but they could all be viable treatments. Another option would be like Twitter, where all characters after 140 (280?) are marked in red as a warning. — Trevor Bolliger, WMF Product Manager (t) 18:05, 3 March 2018 (UTC)
FYI, VE is still applying the old limit because the update for VE didn't make it into 1.31.0-wmf.23. It should be coming this week in 1.31.0-wmf.24; you should be able to test it now on the Beta Cluster. As for "highlighting in red like Twitter", might that confuse Twitter-using Wikipedians into thinking the summary can't be submitted? Anomie 05:29, 4 March 2018 (UTC)
@Anomie: Good catch, thank you. — Trevor Bolliger, WMF Product Manager (t) 23:09, 5 March 2018 (UTC)
I know this would be more complex, but I still support a solution that doesn't care about byte limits and such stuff. In my opinion, there should be a limit of characters, and not of bytes, in the summary, that could be at something like 400. This resembles the spirit of the summary more as it isn't alphabet dependent anymore (except for east-asian languages with their exterme information per symbol ratio), and links wouldn't take away summary space anymore, while still the summary a summary instead of half an essay. Trunctating in the frontend at around 250 characters would still be useful in this case. Furthermore, in the long-term the IPv6-revert-like problems should be solved in my opinion by not prepending this to the saved summary anymore. This information should be stored in machine readable format (so it can be localized as well). I think this proposal would provide a solution for most of the problems outlined here, while I can't find any downsides right now except for its complexity.
However, I want to point out my disagreement to Legoktms point of view about the nature of this change. There was never any discussion how the additional database space should be used after it was provided. What's happening now wasn't really planned by anyone, it just happened. And it it's neither really elegant nor prepared. --MGChecker (talk) 02:28, 3 March 2018 (UTC)

@TBolliger (WMF):, thanks for these suggestions. One of the major concerns expressed by those preferring a longer edit summary limit is that IPv6 addresses can take up much of the previous limit. Is it technically possible to exclude the username (or IP for anons) from the character limit? This would let us specify a reasonable but concise limit for the actual content. Shock Brigade Harvester Boris (talk) 04:13, 3 March 2018 (UTC)

If the truncation can be done on displayed characters, that shouldn't much of an issue. Headbomb {t · c · p · b} 04:39, 3 March 2018 (UTC)
Maybe, but I'm not convinced truncation is a solution. The important part of the edit summary may or may not be within the non-truncated portion. It would be better to prevent people from writing essay-length edit summaries (by removing the opportunity to do so) than to truncate them arbitrarily. But I understand that may not be possible. Shock Brigade Harvester Boris (talk) 05:04, 3 March 2018 (UTC)
@Shock Brigade Harvester Boris: We would have to spend some time to determine the best way to design and implement this idea, but it would be possible to exclude usernames (and potentially other links) from the the edit summary length. I think we can find a simpler solution as an alternative, though. I'm really curious to see what the results of the edit filter are to understand which types are surpassing the 255. — Trevor Bolliger, WMF Product Manager (t) 18:05, 3 March 2018 (UTC)
  • No matter what angle we view this issue from, I think a filter to track long edit summary usage is helpful. I've created one at Special:AbuseFilter/904. MusikAnimal talk 07:38, 3 March 2018 (UTC)
    • @MusikAnimal: Thank you! Let's keep an eye on it and perform some analysis on Monday. — Trevor Bolliger, WMF Product Manager (t) 18:05, 3 March 2018 (UTC)
    • Several editors have pointed out that long IP addresses can fill up much of the edit summary box, making it difficult to fit in anything else within a limited character field. My approach to this, when it occurs, is to manually delete the auto-generated bit of the summary, and replace it with something like "reverted previous IP edit/s", which is very readable and short enough to allow quite a lot of explanation afterwards, should that be necessary. PaleCloudedWhite (talk) 08:46, 3 March 2018 (UTC)
      • @PaleCloudedWhite: The revert and undo auto-generated messages are easily customizable via MediaWiki message. I think it'd be valid to have a separate discussion outside this RFC (there's already a lot going on here) if you wanted to propose such changes. — Trevor Bolliger, WMF Product Manager (t) 18:05, 3 March 2018 (UTC)
I don't understand what you're saying, as I haven't proposed any changes. I only said that my way of dealing with overly long auto-generated edit summaries is to manually remove them, and add my own instead. PaleCloudedWhite (talk) 18:15, 3 March 2018 (UTC)

@TBolliger (WMF): the thing is, are these suggestions permanent or temporary? You don’t say anything about this in your comment. If they are permanent, then sure there is no convenience at all in having some parts of edit summary cut off by default and not displayed until you click on it. But if they are temporary, then it doesn’t matter and we can put any bandaid to it. This is an important distinction, since we can’t discuss this without acknowledging first and foremost whether or not this 1000 characters long edit summary stays or not. stjn[ru] 10:21, 3 March 2018 (UTC)

@TBolliger (WMF): It'd be better if edit summaries were capable of being expanded and viewed no matter what page you're on, rather than truncating them on some pages without the possibility of viewing the full summary. Viewing lots of edit summaries is a common action for administrators, checkusers, and oversighters, and having to load a diff page to view the full summaries will make that job considerably more tedious. There's quite a bit of mental overhead if you have to load an entirely new page to view the longer edit summary, especially if you need to see a lot of summaries. There's also the literal bandwidth overhead, since the longer edit summaries on those pages represents only a few kB of extra data, whereas loading the diff page is several orders of magnitude more than that; this is exacerbated if the truncation is performed on the client, since all the data would be transmitted anyway. I remain thoroughly unconvinced that the longer summaries can cause "massive disruption", but collapsing longer summaries seems to be a good improvement to the user experience regardless. --Deskana (talk) 20:03, 3 March 2018 (UTC)

  • I'd support an expandable summary on all pages - but the diff page should probably show the full summary by default. Bellezzasolo Discuss 20:15, 3 March 2018 (UTC)
  • Yeah, that makes sense. It could be collapsible everywhere with it expanded by default on the diff page and collapsed by default everywhere else, or maybe just not collapsible at all on the diff page but collapsible everywhere else. The former is probably a more consistent experience. I don't really know what I'd prefer. Either would be fine. --Deskana (talk) 20:29, 3 March 2018 (UTC)
  • This change makes the code apply only outside of diff viewers. --Gryllida (talk) 03:43, 4 March 2018 (UTC)
  • I'd prefer along with truncating, reducing the level to 6 or 700 for non admins, and 1000 for admins. Also, I'd suggest a policy implemented to the tune of Any editor who makes what would generally be accepted as an useless, POINTY, or otherwise excessively long ES regardless of content or length will be warned and if they continue, blocked for disruption. Exceptions are for those who have made 3 or less long ES, even if they are all gibberish {because not everyone will have discovered it, or known that policy was enacted, and through Good Faith may we wanting to test it out}, or for anyoen who copies and pastes their edit into the ES box, whether it is for a TP or any other page. While the practice of copy/pasting your edit into the dit summary box is discouraged and frowned upon, the ban of the practice would be impractical and despotic. Any non AC account typing MORE THAN 250b of gibberish to accompany a blank or so-so edit may be blocked per admins discretion for disruption. Howzaboudat? L3X1 ◊distænt write◊ 22:16, 4 March 2018 (UTC)
Also the word be spread regarding RD policy:
  • users may request oversized summaries to be redacted on their UP and TPs,
  • for normal articles and talk pages, they may be redacted at admin discretion IF there a plethora of them, ill intent is SUSPECTED (I know I know, but AGF is not a suicide pact), or they are mere gibberish/otherwise obviously unconstructive,
  • same for the Wikispace, and on the userspaces of banned of blocked users.
  • I do not recommend action to be taken against anyone who may have abused or otherwise experimented with the bug/feature, as some of it was very much POINTY, to illustrate a point to the WMF. The WMF, not being either a Living Person, not part of the, is not protected under POINT. :)
TLDR If Iridescent wished to revdel all the huge ES on her page, she could. Basically re-iterating that RD3 and RD6 apply, because my read through of them doesn't convince me that they apply. L3X1 ◊distænt write◊ 22:26, 4 March 2018 (UTC)
I'd say that sanctions for these edit summaries fall under disrruptive editing, we don't need a new policy (perhaps just comment on DISRUPT that this includes edit summaries). POINT is about disrupting WP to make a point. It clearly doesn't matter that the recipient of the point is the WMF. Bellezzasolo Discuss 23:13, 4 March 2018 (UTC)
Trevor Bolliger, WMF Product Manager I'm not thrilled with the options you listed. The long summaries are even worse on diff screens because they're half-width and double-height. I think it's a bad idea to invite wall-of-text summaries in the first place. I'd strongly suggest trying to return to the original Wishlist task. Cap edit summaries at 255 (or maybe 300) characters, and count those characters in whatever way makes technical-sense while providing approximate equivalence for other languages. I don't know if that means "codepoints" or what, but I doubt they are going to nitpick the counting. Alsee (talk) 11:55, 5 March 2018 (UTC)

Community Wishlist Team proposed change

Hi all. The WMF’s Community Wishlist team just had a meeting to look over edits longer than 255 characters and to discuss next steps for this issue. Our team generally agrees with most of the discussions above and believes that 255 bytes is too short and 1,000 characters is too long. We want to land on a sane and agreeable number. We propose 500 characters (technically code points).

Our current plan is to leave the underlying database change in place (making changes to the database is possible, but requires much more time and work and affects all wikis) but change the ‘edit summary’ text input box in all supported editors (e.g. VisualEditor, wikitext editor, new wikitext editor, mobile editor) enforce the 500 character limit. Additionally, we want to help build a gadget or user JS/CSS script that visually truncates long edit summaries where they might clutter the interface. (Gryllida already has a script functioning.)

I’d like to thank TheDJ for summarizing this RFC into a list of problems. We think setting the edit summary limit to 500 characters and sharing an opt-in script to visually truncate longer summaries will address the problems raised.

What do you think? — Trevor Bolliger, WMF Product Manager (t) 23:43, 5 March 2018 (UTC)

That works for me. Sounds like a reasonable compromise for all sides. Now, if you'll excuse me, I'm going to go install that truncation script. Thanks Gryllida! --Majora (talk) 23:48, 5 March 2018 (UTC)

I've gone over the past ~200 edits where the edit summary is over 255 characters (using the edit filter log), and broken down usage into these categories:

  • 38% - Constructive / overly verbose. These are well-intentioned summaries, but they might be just a bit too wordy. Some were only marginally over 255 characters.
  • 28% - Old school practice of copy/pasting the content you're adding, along with users who add <ref>{{cite web... (etc.) in support of their edit, which is surprisingly common.
  • 16% - Constructive summaries from bots, user scripts, and IPv6 reverts. For some of these, it might be good to update the code to truncate after a certain length.
  • 15% - Communication where the talk page would be better, including edit warring.
  • 2% - Constructively including URLs the summary, such as indicating where copyright violations came from.
  • 1% - Outright, unambiguous abuse.
I like to think I have a fair judgment of determining good from bad edit summary usage, but it should be clear this data is strictly based on my own opinion. You of course can go through the logs yourself and draw your own conclusions.
Hope this helps! MusikAnimal talk 23:56, 5 March 2018 (UTC)
@MusikAnimal: So, what is your opinion on what the limit should be? Jack who built the house (talk) 02:56, 6 March 2018 (UTC)
I think 500 as proposed would be a nice compromise. Eventually, I think it'd be better to implement the "collapse" feature, where full edit summaries are allowed, but hidden from view unless you click to expand them. MusikAnimal talk 20:25, 6 March 2018 (UTC)
What about 512, because it's twice as many as 256? Natureium (talk) 20:51, 6 March 2018 (UTC)
511, more likely, but I'll add that it's probably more user friendly to have a "normal people" round number like 500 than a "computer internet tech people" round number like 511/512. ~ Amory (utc) 21:02, 6 March 2018 (UTC)
Yeah, I think here with the proposed change to the frontend we're counting characters not bytes, so 512 wouldn't necessarily translate to anything meaningful in terms of storage. Also, I've just updated Special:AbuseFilter/904 to look for summaries with over 500 characters, so that we can see what we'd be preventing. MusikAnimal talk 21:28, 6 March 2018 (UTC)
Seems reasonable. ~ Amory (utc) 02:55, 6 March 2018 (UTC)

Update: There have only been a handful of people who responded to the Wishlist team proposal I posted on Monday (to set the limit to 500 characters) so I want to check in here to make our team's plans are clear: we will not change the edit summary length from 1,000 characters to any other amount unless there is a clear consensus to do so. The simplest (and our preferred) solution is to leave the edit summary length at 1,000 characters.

The larger survey above is split on opinions between 255 and 1,000 and the discussion here has considerably slowed since this feature released last week. The edit summary is currently set to 1,000 characters and data shows that only 0.33% of all edit summaries have been longer than the previous maximum of 255 characters (and only 0.05% are longer than 500 characters). We've also been keeping an eye on the Edit Filter log for long summaries (which is now only logging summaries over 500 characters) and we (unscientifically) find that most long summaries are actually constructive or are from cut and paste summaries. As many people above have pointed out, there are already policies (e.g. WP:POINT) against abusing any part of the wiki software to be a nuisance.

What do you think? — Trevor Bolliger, WMF Product Manager (t) 01:37, 8 March 2018 (UTC)

@TBolliger (WMF): "we will not change the edit summary length from 1,000 characters to any other amount unless there is a clear consensus to do so" Did you seek ENWP consensus to make the change in the first place? If not, and your policy is to seek consensus before changes, then why not revert to the status quo pending consensus? Blue Rasberry (talk) 01:58, 8 March 2018 (UTC)
We're addressing this discussion based on the current status, data gathered so far, and the information provided in the discussion and survey above. Yes, the planning and announcement of this change should have been more clear (that's on us.) There's support for keeping it at 1,000 characters and we want to avoid whiplash caused by rapidly and repetitively changing this number. — Trevor Bolliger, WMF Product Manager (t) 02:07, 8 March 2018 (UTC)
  • Support changing to any smaller number. 500 is definitely better than 1000 (and seems supported by Trevor's stats above). Kaldari (talk) 02:26, 8 March 2018 (UTC)
  • Support 500 is a good middle ground. More than 255 isn't necessary in english most of the time, but is occasionally for technical reasons (rollback on long IPs). 1000, is too long. — Insertcleverphrasehere (or here) 02:42, 8 March 2018 (UTC)
  • Support and in the original !voting section I counted 17 editors – distributed between the "Support" and "Oppose" sides – who would prefer an intermediate figure, often specifically stating 500 or a range including 500. They shouldn't all have to come back again before you declare a "clear consensus". If you still don't implement a reduction from 1,000 you should certainly respond to the calls for shortening what is displayed: Noyster (talk), 09:36, 8 March 2018 (UTC)
  • Support 500-or-less. The giant edit summaries are too much of a mess on the page, and I think it's counterproductive to invite people to make wall-of-text posts in summaries. Alsee (talk) 11:38, 8 March 2018 (UTC)
  • Comment/Question @TBolliger (WMF): I've suggested elsewhere that one possible workable approach would be to leave the technical limit in the backend at 1000 characters (is it bytes or characters btw?) but to make the actual limit on input configurable per project. That would get the developers out of the decision process within that overall technical limit, and would let the community on enwp decide, using their usual processes, to have, for example, 500 characters; Wikidata could decide to have 100 characters; and ruwp and dewp decide to have 255 characters. All projects and numbers are here of course just examples picked out of thin air: the point is that each project could decide their own limits within the upper maximum bound given by the backend. This requires actual support in the software (Gadgets and Common.js hacks would be way to kludgy for this purpose), but would subsequently be handled by the local community without requiring expending developer resources. And, almost equally crucially, it would make the decision to adjust the limit after some time to gather practical experience a much more lightweight one. After, say, a year of running with 500 characters as the limit, enwp could decide that this was too much or too small and adjust their policy, without having to go by way of the developers or run a cross-project RfC to find a limit that suits ruwp and dewp (as random examples). As best I can tell, apart from initial implementation cost, this approach would be able to satisfy all interested parties. Is there some problem with this approach that I'm not seeing? --Xover (talk) 12:10, 8 March 2018 (UTC)
    • The limit is 1000 Unicode codepoints. Which roughly means 1000 characters, but for example combining characters count separately even though the base character plus any combining characters display as one "character". Also, BTW, would you be satisfied your lower limit for the frontend input did not apply to things like imported edits or edits via the API (or edits by people who use a gadget or user script to override the frontend limit)? BJorsch (WMF) (talk) 13:09, 8 March 2018 (UTC)
      • @BJorsch (WMF): Imported edits are not really a problem as best I can tell (they are an exception, and the ability to import revisions is limited to editors with particular bits). But this is (one reason) why there should be built-in support for this: imported edits with very long edit summaries probably needs progressive disclosure (click to view characters beoynd the configured per-project limit, or something like that). For the API, I think it boils down to whether it provides an easily exploitable way to avoid the configured limit. The solution doesn't have to be perfect, but it needs to be tight enough that only defined permitted exceptions (e.g. a particular Gadget is allowed to exceed the limit, and the decision is made when deciding whether to allow the Gadget) and people who circumvent it in such a way that they can be policed by the admin corps (lets say someone polices the edits that hit an edit filter and can crack down on people who maliciously or in bad faith avoid the limit). The way I read the discussions above, nobody thinks the sky will fall if there are the occasional exceptions; it's the length of the vast majority of edit summaries they are concerned about. Personally I have a vague preference for around 250 net characters (that is, when boilerplate, links, and IP adresses are not counted towards the limit), but don't really care all that much about the specific number. I'm mostly concerned with avoiding the needless drama this has caused, and seems set to cause in the future, and placing the decision about this issue where it belongs. Because I don't imagine the developers really care whether enwp allows 250 or 500 characters, but in the status quo they're forced to effectively be the ones that decide that number, with all the attendant grief from those who don't feel like they've been heard or that they've had a real say in the decision. I'm also quite sympathetic to Anomie's point below. --Xover (talk) 14:21, 8 March 2018 (UTC)
        • As a developer, I don't much care what the specific limit is, although with IPv6 255 characters has proven too small. I do care that imports don't have surprise truncation that might cut off important attribution. And I think it'd be useful if cross-wiki bots and scripts didn't have to worry about arbitrary differences in allowed comment length. I also note that omitting boilerplate and the targets of piped links from the count could run into the 65535-byte limit at the database level if someone is piping a lot of particularly long page names, and would mean that no one could edit or delete the boilerplate if it's applicable to their edit. BJorsch (WMF) (talk) 15:06, 8 March 2018 (UTC)
  • Support. Sure. MER-C 12:46, 8 March 2018 (UTC)
  • Oppose Leave it alone for a while and reevaluate once people have had a chance to get over their change aversion. Let's not reward the small fraction of people who immediately break out the torches and pitchforks any time anything changes here. Anomie 13:18, 8 March 2018 (UTC)
  • Support this and solutions discussed --> here   —  Hei Liebrecht 18:34, 8 March 2018 (UTC)
  • I can live with 500 bytes, thanks for being willing to compromise. ϢereSpielChequers 18:46, 8 March 2018 (UTC)
  • Support: I think 1000 was far too high and 500 is much more sensible, though I like the idea provided by Guy Macon below too. EdChem (talk) 10:37, 9 March 2018 (UTC)
  • Oppose. This is premature. Let's keep gathering data, see what problems actually occur, and think about the best solutions to them. Rushing to decrease the limit based on guesses about what problems might happen is a bad way to operate. (This comment is without prejudice to the change to collapse edit summaries, which I believe to be a good change, and is proceeding ahead regardless of whether this happens or not.) --Deskana (talk) 11:31, 9 March 2018 (UTC)
  • Oppose Reiterating already at this stage but this seems to be one of those ideas people can get against with pitchforks and banners but with no real basis. I've only seen "seems too long", "doesn't look okay", "clutter" type of arguments and arguably those are some pretty unreasonble counters to an arguably good change (evidence as presented). --QEDK ( 🌸 ) 19:30, 9 March 2018 (UTC)
  • Support 500, per points by TheDJ in #Identified problems, and by MusikAnimal at the top of this section.   ~ Tom.Reding (talkdgaf)  21:47, 9 March 2018 (UTC)
  • Support 500 as a nice compromise between too long and too short. MarnetteD|Talk 21:50, 9 March 2018 (UTC)
  • Support500 L3X1 ◊distænt write◊ 12:43, 11 March 2018 (UTC)
  • Support 500 jcc (tea and biscuits) 15:44, 11 March 2018 (UTC)
  • Support 500 (as I mentioned in the previous section). Kevin (aka L235 · t · c) 05:55, 12 March 2018 (UTC)
  • Oppose changing the limit again. Just hurry up with the truncation fix. I've seen practically none of the foretold abuse from IPs that I keep hearing about. Master of Time (talk) 06:23, 12 March 2018 (UTC)
  • Support 500. Good compromise. Truncation also sounds good. Edison (talk) 20:16, 13 March 2018 (UTC)
  • Support 500 - I think this is a good compromise as 1000 was very long to say the least. –Davey2010Talk 21:09, 13 March 2018 (UTC)
  • Support 500 or (ideally) less. Do we really need stuff like this? Shock Brigade Harvester Boris (talk) 23:33, 13 March 2018 (UTC)

Update, March 14: Thank you for the comments and sharing your feedback on edit summaries, it's been incredibly helpful! The WMF's Community Wishlist team will be changing the edit summary length to 500 characters in phab:T188798, and the change will release to all wikis in the coming weeks. — Trevor Bolliger, WMF Product Manager (t) 17:31, 14 March 2018 (UTC)

Proposed alternative solution

In my opinion, setting the limit to 1000 bytes is the wrong way to solve the problem. The right way is to:

  • Give the user 255 characters (characters, not bytes) to write a summary.
  • Have the software tack on any canned edit summaries such as "Undid revision 000000000 by User:0000:0000:0000:0000:0000:0000:0000:000 (User talk:0000:0000:0000:0000:0000:0000:0000:000)" up to some reasonable limit.
  • Make one Unicode character count the same as one ASCII character when enforcing the 255-character limit.
  • Count a wikilink or external link according to how many characters the reader of the edit summary sees. Thus [[WP:1AM|1AM]] and [ 1AM] would count as three and four characters (1AM and 1AM).

Professionally-written software should meet the needs of the user, not the convenience of the coder. --Guy Macon (talk) 06:29, 5 March 2018 (UTC)

  • Support: as proposer. --Guy Macon (talk) 06:29, 5 March 2018 (UTC)
    • Comment I agree that "bytes" is the wrong way to measure Unicode strings. But "characters" is problematic — it's not clear exactly what "Unicode character" means, when you take things like combining characters into account. You could try to count graphemes maybe, but this is not necessarily trivial, and it doesn't take into account piped links. Ideally I would have the limit based on the actual amount of space the summary takes up, rather than a rule based directly on the source text. --Trovatore (talk) 07:04, 5 March 2018 (UTC)
      • If I read the ticket correctly, the limit is now a 1000 unicode codepoints, not a 1000 bytes. Still not the same as a 1000 characters, but indeed, figuring out what counts as a character is almost impossible. —TheDJ (talkcontribs) 09:01, 5 March 2018 (UTC)
        • You did read it correctly. I note there's also a database limit of 65535 bytes on the entire comment, which might come into play if we were to try to not count various things. Anomie 13:30, 5 March 2018 (UTC)
  • Yes It would be great if Wiki markup for internal and external links would function within edit summaries: Noyster (talk), 08:07, 5 March 2018 (UTC)
    • Edit summaries are not wiki text though. They only support a very limited subset for a reason. Adding external links, would require us to start policing those external links (to potential dangerous locations) as we need to do for articles. I'm not sure if that is a good idea. —TheDJ (talkcontribs) 09:17, 5 March 2018 (UTC)
  • Oppose. There are useful situations where one might want to override an automated summary, such as when said edit is by a suppressible username. This seems needlessly complicated to me.--Jasper Deng (talk) 11:00, 5 March 2018 (UTC)
    • Who said that you couldn't override an automated summary? Properly written software would of course allow that, giving you a total of 255 characters for your comment plus the modified automated summary. Only untouched automated summaries would not count against your 255-chaaracter limit. --Guy Macon (talk) 10:16, 9 March 2018 (UTC)
  • Support/Comment I think larger space for stored information was long due, just some rules are needed to avoid long-displayed messages such as those of just regular English words. Internal and external links, tags (if that functionality was better integrated), user names, and ips can be displayed in a more compact format, so the limit should be set based on the approximate calculated display width, not characters, bytes or unicode codepoints. For example, allow only for 250 "m" symbols in width (which should take 250 bytes) or 250 emojis -if that was an ok summary, in practice it would be something like CJK characters (which will take 1000 bytes) -but with the above "tokens/special contructions", allow to push for larger amount of bytes as long as the display size is not too long. As a temporary measure, until that can be reliably implemented and agreed by the community, "hide" on display overflows on places like recentchanges, contributors list and watchlist. --jynus (talk) 15:00, 5 March 2018 (UTC)
  • Oppose. Collapsing the summaries, as proposed above, is sufficient. This solution complicates things with little benefit. --Deskana (talk) 17:43, 5 March 2018 (UTC)
    • With all due respect, the "this solution complicates things" mentality is one of the main reasons we all go through life dealing with shitty software. You write the software once. It gets used thousands of times per day. Making the software meet the needs of the users is far more important than making the software easy to write. --Guy Macon (talk) 16:18, 7 March 2018 (UTC)
      • I wasn't talking about code complexity. You've explained your solution well, and I think it's easy to understand. I also think a fixed summary length is even easier to understand. Given that I believe there's no harm being caused by the longer summaries, I favour the easier to understand solution. --Deskana (talk) 16:54, 7 March 2018 (UTC)
  • Support - this deals with the many issues relating to the need to lengthen the edit summary. In the case I described above, with a long category being deleted/renamed/merged per CFD discussion, the viewer doesn't actually need to see the link target - telling them "CFD" and linking them to the discussion is enough. עוד מישהו Od Mishehu 15:51, 7 March 2018 (UTC)
  • Comment - This is a decent idea, but would require some time to implement and might end up being confusing to folks. Personally, I favor the simpler idea of just changing to 500 characters. Kaldari (talk) 02:21, 8 March 2018 (UTC)
  • It would indeed require some time to implement, but if designed properly would be invisible to the user. The user would see an unlabeled number (don't get me started on not labeling things...) on the right indicating how many characters she has left. Instead of 1000 the number would be 255 -- and it would be 255 even if Wikipedia helpfully used up 122 of those characters with by prefilling the edit summary with "Undid revision 000000000 by User:0000:0000:0000:0000:0000:0000:0000:000 (User talk:0000:0000:0000:0000:0000:0000:0000:000)". Totally invisible unless someone is looking for it. --Guy Macon (talk) 10:11, 9 March 2018 (UTC)

List of arguably useful long edit summaries

I think collapsing edit summaries in change lists is a good idea, and I started work on an implementation here. I think the discussion has focused too much on people being stupid and not enough on allowing people to be smart if they want to be. Here is a list of arguably useful edit summaries longer than 500 bytes. I say arguably because you can always say "that should have been on the talk page". The big difference between the talk page and the history is its visibility. I'd just like to put a good word in for people writing useful things in places that are visible. -- Tim Starling (talk) 10:22, 9 March 2018 (UTC)

  • /* Veganism by country */ filled out citations; no HTTPS page for or Gallup; used in Reuters and Atlantic citations because Internet Archive's archive was automatically redirecting to a broken page despite saving (Reuters) and failing to go through (Atlantic), no clear reason why, so this will do; perhaps the Internet Archive will cooperate for someone else; no clue why the wikitext diffs look like that, but my guess is too many changes; also punctuation; if the quotes are excessive, despite being recommended, then just remove them rather than revert the edit
  • Rving these edits - This article had major reworking done to it to deal with multiple issues and problems in article needed resolving as follows: Lead Rewritten; History deleted, some information moved to Lead; Presenters deleted - this information is not clear on what it means and seems unneccesary; Infobox amended - co-presenters moved to "Presenters" and one location put into HIDDEN TXT until 16th series begins broadcast; Spin-Off episode table amended - it was quite big than needed; Opening Titles, End of Series Special, and Starting Games deleted - these are unreferenced and two sections feature information that is excessive and unnotable; Multiple Issue template on Marketing - issues are what are stated
  • Undid revision 828599997 by Stevo1000 (talk) it’s not out of place, if you look at articles about major European cities they all have a similar content. Just because it’s a featured article doesn’t mean it can’t be expanded, especially when Manchester is going through a construction boom. Please stop deleting it, instead you could help improving it. It’s your opinion to think it’s not necessary but Wikipedia isn’t a place ruled by your opinions. Please next time you decide to remove someone’s work, discuss it first.
  • /* Official languages */ In Russian language the word "of" is represented by the genitive case, and subsequent case endings. in this case a masculine word takes on the vowel ending "a" in genitive case. this is a common mistake in Russian language even often being wrong in translates such as google translate. In the case of "Republic of Dagestan," Респу́блика Дагеста́н is incorrect and translates as "Republic Dagestan." To correct this we must change the word Dagestan into genitive case to represent the word "of", or in this instance Респу́блика Дагеста́нa
  • Additional instances of text which were insufficiently paraphrased from the source material have been removed. Research paper and Refimprove maintenance templates added. These two templates make notice of the article's need to incorporate sources which are of a secondary or tertiary nature, in order to better provide context to the reader. The dense subject matter necessitated the second template, which addresses the need to limit direct usage of scientific journal entries as the only type of sourcing available for this article. Scientific journals may be excellent references for articles, but the readership of those publications are markedly different than those of Wikipedia, and this ought to be reflected in the sources used.
  • Correcting links as per example of 884 Priamus. Replacing the direct citations for the inline data with links that actually point to the data rather than the related (but individually useless) journal articles, preserving links to said articles by moving them into the External Links section. There's less metadata in the latter case of course, but there should be more than enough information to preserve accessibility under any realistic sub-apocalyptic circumstance where Wikipedia itself still operates (and author names etc are present within the articles themselves), and the original metadata has been kept as HTML comments just in case. Also, as no (accessible) data could be found associated with the (in any case obsolete) WISE preliminary release (written here to 2dp), and the NEOWISE data only displays to 2dp (but has been written here to an excessive 3dp), the latter has been removed, but its citation tied to the former instead. Also adding km/mi conversion & updating size estimates [truncated at 1000 characters]
  • Archiving closed XfDs (errors?): Wikipedia:Articles for deletion/Slavko Dedić career record Wikipedia:Articles for deletion/John M. Puente Wikipedia:Articles for deletion/Vincent LaCrocq Wikipedia:Articles for deletion/Panayiotis Diamadis Wikipedia:Articles for deletion/Jorge Alberto Rodríguez (2nd nomination) Wikipedia:Articles for deletion/David Cowan (journalist) Wikipedia:Articles for deletion/Grant Russell Wikipedia:Articles for deletion/Elmer Stewart Rhodes Wikipedia:Articles for deletion/Moderator of the Sutlej Reformed Church of Pakistan

All but the last one of those could/should be on the talk page rather than in an edit summary. Natureium (talk) 17:03, 9 March 2018 (UTC)

Actually, I disagree. Justifying one's edit directly is most useful in an edit summary; talk pages are useful for discussing prospective edits or working out disputes, but these edit summaries are all doing what edit summaries are supposed to: explaining why you are doing what you are doing. --Jayron32 17:12, 9 March 2018 (UTC)
Your idea of what should be in an edit summary is very subjective and in my opinion, a wrong opinion - the editor above me gives some insight why. --QEDK ( 🌸 ) 19:28, 9 March 2018 (UTC)
You believe that editors should not explain what they are doing in an edit summary? If so, you're going to have to change the text of WP:ES, which states, and I quote "It is good practice to fill in the edit summary this helps others to understand the intention of your edit" If you believe that the main purpose of an edit summary is something other than explaining your intentions, then I posit that you are the one with an idiosyncratic opinion. I have said nothing that is not long established policy. --Jayron32 19:32, 9 March 2018 (UTC)
But these long-winded edit summaries could have been made more brief and still stated what was changed in the edit. E.g. compare "I added a sentence and reference about the age of onset of this condition because there wasn't any information about that, and moved the section on diagnosis to be above the section on treatment to be consistent with the WP:MED guidelines" with "age of onset; organization per WP:MED". Natureium (talk) 19:39, 9 March 2018 (UTC)
@Jayron32: You've gotten me awfully wrong, I was merely concurring with what you said and replying to the OP. --QEDK ( 🌸 ) 07:36, 10 March 2018 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────An other useful one, by AnomieBOT: (BOT) Close discussions for deleted/nonexistent files: [[:File:Tuperware.jpg]], [[:File:Kmchugh.jpg]], [[:File:Carchi Flag.png]], [[:File:Sucumbios Flag.png]], [[:File:Madaba map.JPG]], [[:File:Tena Flag.png]], [[:File:Azuay.gif]], [[:File:EsmeraldasPRVFlag.png]], [[:File:737px-StaffordshireSouthGraph.png]], [[:File:Manabi Flag.png]], [[:File:Satapliasaurus claw fossil.jpg]], [[:File:Pristine-logo2.jpg]], [[:File:TTCL Customer Care.jpg]], [[:File:El Oro.png]], [[:File:TumeloHomeLetterHead.jpg]], [[:File:Turpen.JPG]], [[:File:Napo Flag.png]], [[:File:Orellana Flag.png]], [[:File:Klein Asian Society At KleinISD.jpg]], [[:File:TTP-Logo.jpg]], [[:File:Tulcan Flag.png]], [[:File:Los Rios.png]], [[:File:Tt egyptPuzzl.jpg]] Errors? [[User:AnomieBOT/shutoff/IFDCloser]] עוד מישהו Od Mishehu 09:24, 11 March 2018 (UTC)

Public Domain 2018 Russia

Dear colleagues, please comment on CentralNotice banner proposal for Public Domain 2018 Russia uploads & article contest. (18 March - 30 June, all IPs from Russia, Wp/Ws/Commons, 1 banner impression per two weeks). Thank you.--Frhdkazan (talk) 17:41, 8 March 2018 (UTC)

Bot to tell people "you're using too broad of categories for your article"?

One of my occasional hobbies is going to the nation-level overcategories like Category:Countries in Africa and seeing which individual country pages, like Category:Namibia, have more than 5 or so articles right in the main category itself. In those cases it's almost definite that people are filing a page in *way* to broad a category, either as the sole cat for the country, or as as duplicate cat. So for example filing a politician under "Category:Namibia" and "Category:Politicians" rather than "Category:Namibian politicians", or all three.

I would submit it's be useful to create a bot which notes when an article (new or current) is assigned to a very large category, like a full country, or "Category:Philosophy", "Category:Drugs", "Category:Animals", etc. Nothing bitey, just a bot saying

Hey, I see you put an article in a very large category. Are you aware that categories should be as narrow as possible? [EXAMPLES HERE] Please see WP:Categories and see if your article belongs in narrower sub-categories than what you are currently using.

I don't know if this would be a bridge too far, but could either the same bot or a different one be nuanced enough to say:

I see you used "Category:Namibia" and "Category:Politicians", since categories should be as narrow as possible, I think you probably would be best to use "Category:Namibian politicians"

I know some cats are non-disseminating, but those tend to be somewhat narrower cats anyway, and I'm proposing this mainly for 190-some countries, and then for maybe tops a couple hundred really huge cats beyond that, rather than trying to track down every single example.

Thoughts? MatthewVanitas (talk) 22:53, 10 March 2018 (UTC)

I doubt it's feasible, we need a bot to intelligently identify if the category is too broad, separate it from good edits (+ false positives) and I'd rather have broad categories than wrong/missing ones anyday. --QEDK ( 🌸 ) 18:15, 11 March 2018 (UTC)
I'd be satisfied having it just for the 190 countries at this point. And it wouldn't be a bot to remove cats, but a notification bot to tell people that they (almost definitely) improperly filed a Nigerian musician under Category:Nigeria. MatthewVanitas (talk)

An option to toggle on or off the new other language interwiki list format?

I've noticed that the list of interwikis has been butchered. It's now not a list per se, it only includes a few arbitrarily (?) chosen interwikis, and to see more, you have to click to open an awkwardly small and difficult-to-navigate window.
I'm not asking to revert this terrible change, European Wikipedias have transitioned to it a long while ago, but could there be an option to show all the interwikis at once like before? Even for logged out users, please? There's already a wheel near the word "Languages," it could have this option.--Adûnâi (talk) 15:48, 11 March 2018 (UTC)

It's "Use a compact language list, with languages relevant to you" at Special:Preferences#mw-prefsection-rendering. Adding the option at the actual feature could be nice. PrimeHunter (talk) 16:04, 11 March 2018 (UTC)

Changing the 2FA permission

NOTE: 2FA = Two-factor authentication. Please define acronyms on first use. --Guy Macon (talk) 10:49, 12 March 2018 (UTC)

My proposal is the following currently 2FA is currently only available to staff but what i would like to see is that all users get to be able to use 2FA and that it would also be added to preferences under basic information below the password field this would allow all users to have additional security to their account and would make wikipedia a safer place — Preceding unsigned comment added by Lars.Dormans (talkcontribs) 16:51, 11 March 2018 (UTC)

@Lars.Dormans: that is the overall plan, but there are a lot of things that need to be worked on first, see here for most of them, feel free to comment or contribute on any of those tasks. — xaosflux Talk 18:26, 11 March 2018 (UTC)
Merged the duplicated discussion you started at the other forum here. — xaosflux Talk 22:29, 11 March 2018 (UTC)
  • Maybe we should make 2FA required for certain actions as well, such as deletion templates (prod, afd, csd) and article creation? Kirbanzo (talk) 21:26, 11 March 2018 (UTC)
    • We don’t even require it if functionaries or admins (and an RfC to do so would fail massively). We aren’t going to require it to make a basic edit, and I say that as a sysop who does use 2FA. TonyBallioni (talk) 22:01, 11 March 2018 (UTC)
  • @Lars.Dormans: It may be worth noting that anyone can request to be added to the OATH group at Steward requests/Global permissions on Meta (a la this request) - TNT 21:41, 11 March 2018 (UTC)
  • Comment: I find it to be annoying when people start talking about an acronym like 2FA without defining it. Please don't do that. See meta:Help:Two-factor authentication. --Guy Macon (talk) 23:13, 11 March 2018 (UTC)
Thank you. I genuinely spent a couple minutes trying to figure it out before noticing your comment. (talk) 07:17, 12 March 2018 (UTC)
  • The current process for 2FA is clunky and prone to completely locking out accounts (which can't be recovered without help from the devs); I say this as someone that just reset his phone and had to be absolutely sure I handled the scratch codes correctly. Increasing its availability for those who aren't currently given it by means of advanced permissions will most likely cause these problems to increase in number and be a further needless strain on the devs. I think it would be best to wait for the 2FA planned improvements before moving it out to everyone. Nihlus 07:26, 12 March 2018 (UTC)
  • No. 2FA is not ready for prime time. I've been involved with a couple of admin who have had to get the devs to unprotect their account, and I'm sure there were plenty more. At best, it is a beta system and not ready for the masses in its current form. Dennis Brown - 00:35, 16 March 2018 (UTC)
  • Per Dennis. But Dennis it is really unlikely to ever be useable by huge amounts of users (editors) because of the basic fact the WMF does not want to keep any personal information on editors. Has nothing to do with it being a beta version. There will always be a barrier when 2FA goes wrong as its very difficult to authenticate people and reset 2FA (in general) without some form of identity confirmation. This isnt a problem for most service industries because they are already storing private information about the user. The amount of hoops that have to be jumped through now when someone who has it locks themselves out is time-consuming far beyond necessary. With thousands more people with 2FA enabled? The WMF would need to hire customer service advisors just to deal with the reset requests. Only in death does duty end (talk) 01:28, 16 March 2018 (UTC)
    • Simple answer: Tell anyone who locks themselves out to pound sand, combined with very strong warnings and a couple of "ARE YOU REALLY SURE? TYPE 'YES I AM REALLY SURE' prompts when turning on 2FA. In fact, design it with strong encryption so that the account cannot be unlocked by anyone at the WMF, even if they are bribed, threatened, or are given a court order. Then make it easy to save multiple backups of the authentication keys to [A] thumb drives and [B] printed sheets of paper. --Guy Macon (talk) 05:23, 16 March 2018 (UTC)
  • Plus one to Nihlus. Practical 2FA generally has at least a couple layers of backup — phone-as-device, phone as phone number (text or voice messages), U2F keys (of which you can register more than one), scratch codes, time-based apps or hardware tokens, sometimes e-mail, sometimes proving who you are IRL (in real life).
    E-mail is admittedly bad unless you put 2FA on it as well, but that's in your control. IRL is a bit at variance with the anon-friendly ethos here, but I don't see why it can't be an option for those who want it (it already exists for people who want to use names of well-known living persons as their user name).
    Even without those two, limiting the only recovery option to be scratch codes seems pretty harsh. Adding a couple of the others would make it a lot less scary, and could improve adoption rates. --Trovatore (talk) 06:16, 16 March 2018 (UTC) As U2F works with Google Chrome but not with some other popular browsers, in this context I should disclose that I work for Google. Now that I've done that I feel free to say that I hope Wikipedia will adopt U2F; it's very nice to have a single token that works on multiple sites, rather than one for each. --Trovatore (talk) 06:31, 16 March 2018 (UTC)
    @Trovatore: I and other volunteers started several times on U2F support, but neither of us got far beyond the experimental phase. Part of the problem is that the extension and it's UI need to be changed from a single 2FA flow to a multi-auth 2FA flow and that's often when it becomes too much work to finish the experiment :) I again have this as my hackathon goal in May, but honestly it's the 3rd hackathon that I've had it on my list in 2 years. Its a long list of potential projects :) —TheDJ (talkcontribs) 09:22, 16 March 2018 (UTC)

Community review for new article topics of WikiEd classes?

As a NPP reviewer, I've noticed that WikiEd classes somewhat regularly create articles on topics that aren't reasonable encyclopedia articles. For example, the lists at Wikipedia:Wiki Ed/York University/Resistance and Subversion on the Internet (Fall-Winter) and Wikipedia:Wiki Ed/Carleton University/COMS4407 Critical Data Studies (Fall 2017) are filled with red-links, neologisms of questionable notability, and terms which inherently promote a point of view.

Is there any way that the community can help guide these students towards selecting better topics, or towards improving/re-writing articles on existing topics? I don't have a specific proposal just yet, but I'm envisioning some kind of noticeboard for discussing proposed article topics. power~enwiki (π, ν) 17:45, 16 March 2018 (UTC)

There is already the Wikipedia:Education noticeboard, where concerns about specific classes can be and are brought up. When this happens it seems the Wiki Ed staff are helpful in resolving the issues. I can't really comment further as I'm not familiar with the scheme. BethNaught (talk) 19:04, 16 March 2018 (UTC)
There is a perennial problem with class projects creating all sorts of bad content, including starting new pages as well as messing up existing pages (and made worse by the fact that large numbers of student edits all show up at once). Wiki Ed staff are excellent when the classes are in the US or Canada, but they are not involved in any other parts of the world. BethNaught is right that issues should be brought to the Education noticeboard. Having a new noticeboard for discussions of appropriateness of topics probably would be a waste of time, because students typically dump the content here and then disappear once they get course credit, so they won't be around to see any advice from experienced editors. Waiting a few days, and then using WP:PROD, is a perfectly reasonable approach instead. Using WP:AfC can be helpful, but it can also take too long for class projects. WP:ASSIGN is a good source of guidance. --Tryptofish (talk) 21:07, 16 March 2018 (UTC)
I don't think that "Wiki Ed staff are excellent when the classes are in the US or Canada" actually, although since anything they do seems to be hidden from us mere ordinary Wikipedians on course pages, it's hard to tell. In my area a rather larger problem is students choosing/being assigned articles that are already well-developed and attracting many views, and which many new students are frankly incapable of improving. They would be far better off working on shorter, less high visibility subjects. It is very difficult to communicate with the courses - I've only once found an instructor responsive via talk. Messing up an established popular article is a worse problem in rthe big scheme of things than creating a new article no one will ever see. But I suppose these are 2 sides of the same coin. Johnbod (talk) 21:55, 16 March 2018 (UTC)
I wish you had not said that about Wiki Ed. All one has to do is to follow the Ed Noticeboard and communicate with Wiki Ed staff on their talk pages: it's not hidden at all. --Tryptofish (talk) 22:05, 16 March 2018 (UTC)

Observe MOS:FONTSIZE in infobox templates

For clarity, this is about infobox templates, not their transclusions. It will not address how editors use infobox templates in articles. Please limit the scope of discussion accordingly.

Some (or many, depending on your definition) infobox templates contain code that reduces font size for some text elements below the minimum recommended in the last paragraph at MOS:FONTSIZE—85% of the page default size. Unlike most MoS, this is an accessibility issue. At Template talk:Infobox scientist#Font size reduction violates accessibility MOS, I'm advised that explicit community consensus is required to deprecate this usage by the infobox templates.

If the conclusion at Wikipedia:Village pump (technical)/Archive 159#Infobox font size is correct, the default size for normal infobox text is 88% of the page default. Therefore any further reduction below 97% would fall below the 85% minimum (0.88 x 0.96 = 0.845). As {{small}} is a further reduction to 85% (74.8% of page default), and {{smaller}} is a further reduction to 90% (79.2% of page default), this would include deprecation of both of those templates in infobox templates. Finally, according to Template:Small, <small>...</small> is equivalent to {{small}}, so it would also be deprecated.


Per MOS:FONTSIZE and MOS:ACCESS, deprecate font size reductions by infobox templates to below 85% of the page default size, including the use of {{small}}, {{smaller}}, and <small>...</small>. This will also apply to all templates that are used primarily or exclusively in infobox transclusions, as they inherit the reduction to 88%.


Wikipedia talk:Manual of Style
Wikipedia talk:Manual of Style/Accessibility
Wikipedia talk:Manual of Style/Infoboxes
Wikipedia talk:WikiProject Accessibility
Wikipedia talk:WikiProject Templates

Survey: Observe MOS:FONTSIZE in infobox templates

  • Support as proposer. Per the lead at MOS:ACCESS, WMF takes accessibility seriously, and the 85% recommended minimum indicated on that page has been in place for years. I see no reason to deviate. ―Mandruss  23:14, 16 March 2018 (UTC)
  • Support as per above. --Emir of Wikipedia (talk) 23:29, 16 March 2018 (UTC)
    @Emir of Wikipedia: Please affirm or change your !vote after addition of the last sentence of PROPOSAL. ―Mandruss  23:47, 16 March 2018 (UTC)
    Still support, but I think that the templates mentioned originally are the main issue. --Emir of Wikipedia (talk) 23:49, 16 March 2018 (UTC)
  • Support I have been manually modifying small in infoboxes for about nine months. Walter Görlitz (talk) 00:37, 17 March 2018 (UTC)
  • Support As someone who struggles to read text that's less than 85% of normal page font size, I wholeheartedly support this. Although this discussion should be no more than a re-affirmation of a MOS guideline that is already well established. There should already be no impediment to the removal of styles in infoboxes that reduce the font size. --RexxS (talk) 00:47, 17 March 2018 (UTC)
  • Support. There is no lack of space for normal sized fonts, and we should not use "smaller" fonts that are harder to read. I don't think even 85% is justifiable - the infobox text can just be set at 100%. — Carl (CBM · talk) 00:48, 17 March 2018 (UTC)
  • Support mostly but {{small}} etc can be used in titles and in |above= without the size getting below 85%. So shouldn't be deprecated there Galobtter (pingó mió) 06:48, 17 March 2018 (UTC)
    Given the purpose of the proposal, I hope we can assume that per common sense, rather than turn the proposal into a legalistic string of hereto's and wherefore's. ―Mandruss  06:58, 17 March 2018 (UTC)
  • Support no excuses for smalling the text. --Redrose64 🌹 (talk) 07:51, 17 March 2018 (UTC)
  • Support. It's a no-brainer. Wikipedia takes accessibility seriously; if we are the free encyclopedia that anyone can edit, we should also be one that anyone can read. As noted in the discussion below by others, it's not a healthy habit to think that we need consensus to implement guidelines that already testify of consensus on the matter. – Finnusertop (talkcontribs) 13:57, 17 March 2018 (UTC)
  • Support Clearly. Don't think we need a full-fledged discussion here, Wikipedia:JUSTDOIT. ~ Amory (utc) 15:03, 17 March 2018 (UTC)

Discussion: Observe MOS:FONTSIZE in infobox templates

With the use of AWB I have been using the find and replace for <small>, </small> and a regex expression for the templates. I have been using the edit summary ""Avoid using smaller font sizes in elements that already use a smaller font size, such as infoboxes, navboxes and reference sections." MOS:ACCESS#Text/MOS:FONTSIZE" --Emir of Wikipedia (talk) 23:27, 16 March 2018 (UTC)

You're speaking of transclusions in articles, I presume. As stated this is not about that, but I appreciate your work in that area. ―Mandruss  23:29, 16 March 2018 (UTC)

I've found in the past that some WikiProjects have created infobox templates that produce text that is too small, often because they "have always done it that way". Usually, explaining the accessibility problem leads to those problems being fixed, and another group of people helping to make Wikipedia more accessible. If one of the reasons for this discussion is a reluctance of some WikiProjects to change their infoboxes, then it would be worth advertising the discussion at those WikiProjects (if not done already), so that they can have their say and see the other editors' opinions expressed here. --RexxS (talk) 01:15, 17 March 2018 (UTC)

@RexxS: I don't know which WikiProjects you're talking about, but anybody is welcome to advertise anywhere and update the list above. My sole reason for starting this is the advice I referred to above, and I was not entirely surprised to hear that a community consensus is required to get folks to observe a long-standing guideline. It's far from the first time we've been required to get consensus for a guideline, and then another consensus to enforce the guideline. It defies logic, but that's Wikipedia. ―Mandruss  01:19, 17 March 2018 (UTC)
You had bad advice then. A guideline carries all the weight of the community and an individual editor needs to demonstrate a very good reason why the MOS should not apply to their edits. Primefac has all his facts wrong in that discussion, although I see that Frietjes has fixed the problem for Template:Infobox scientist now. If it's any help to you, there's a way of determining the absolute value of the fraction that any piece of text has relative to normal page font size. If you use the 'inspect' function in a browser like Chrome, you can check the computed value of font-size for a given piece of text. In Monobook skin, normal page font size is 12.7px, and in Vector it is 14px. A quick calculation shows that any text with a computed font-size less than 10.8px in Monobook or 11.9px in Vector will breach MOS:FONTSIZE. --RexxS (talk) 01:49, 17 March 2018 (UTC)
No Chrome. browser like Chrome undefined. Firefox. Anyway, a clear consensus here should eliminate 97% of the problem without need for 'inspect'ing anything. ―Mandruss  02:09, 17 March 2018 (UTC)
"Browsers like Chrome": Chrome uses the Blink engine as does Opera. That was a fork of Webkit used in Safari, which in turn was a fork of KHTML, used by Konqueror. That may give you an idea of what I meant. All of the major modern browsers have the ability to inspect text on a webpage, For Firefox, right-click followed by 'Q' opens the inspector. You'll find that the ability to ascertain font-size in a given place is vital because you'll simply have folks telling you the text you're trying to fix is more than the 85% limit – as happened to you already. This discussion is irrelevant because nobody's contesting the consensus at MOS:FONTSIZE, but they will contest your ability to identify which text actually breaches it unless you can definitively show that they are mistaken. --RexxS (talk) 13:30, 17 March 2018 (UTC)

Just WP:BEBOLD and do it unilaterally, as I did here and here. --Redrose64 🌹 (talk) 07:50, 17 March 2018 (UTC)

  • Just a quick comment on the “long standing guideline” argument... remember that guidelines reflect consensus, and that consensus can change over time. That means that we should periodically check to see WHETHER a given guideline still reflects consensus or not (and IF consensus has changed, amend the guideline accordingly).
    Not saying that the consensus regarding font size has changed. Just saying that it is never wrong to double check. Blueboar (talk) 12:20, 17 March 2018 (UTC)
    Accessibility is basically mandated by the WMF--so whether WP:Accessibility has a "guideline" tag on it rather than a "policy" tag is immaterial. --Izno (talk) 12:59, 17 March 2018 (UTC)
    I'm pretty sure that we shouldn't strawpoll each and every guideline once every few months just to see if consensus has changed. Instead, if someone thinks that consensus regarding some guideline has changed, they can propose amending it. If consensus has truly changed, their proposal should pass easily in absence of opposition. – Finnusertop (talkcontribs) 14:06, 17 March 2018 (UTC)
    Yes, that approach appeals to both logic and efficiency. Speaking of logic and efficiency, the larger and more important issue is that there is any significant disagreement among experienced editors, on such a foundational question, 17 years after inception. ―Mandruss  19:13, 17 March 2018 (UTC)
  • There is another alternative to removal, which is to set CSS rules for where small (or one of its variants) when small is used inside an infobox. --Izno (talk) 12:55, 17 March 2018 (UTC)
  • On a somewhat tangent, navbox and sidebar also sets a smaller font size, and so small should also be deprecated in those places. --Izno (talk) 12:57, 17 March 2018 (UTC)
    • It already is: "Avoid using smaller font sizes in elements that already use a smaller font size, such as infoboxes, navboxes and reference sections."MOS:FONTSIZE. --RexxS (talk) 13:30, 17 March 2018 (UTC)
      • Deprecated? Removed? Fixed as I suggested as an alternative? Take your pick. :^) --Izno (talk) 13:37, 17 March 2018 (UTC)

Idea lab

Hover highlighting

If you have a look in Template:Cheatsheet and el:Πρότυπο:Εργαλειοθήκη to compare, you will see a difference while hovering above the text of collapsible headers. By highlighting on hover, the reader gets a hint to click. For another demonstration, check el:Πρότυπο:Συγγραφή λήμματος (also in Greek) which is a collapsible help with sub-levels. There is no hint to click the collapsible, if hover highlighting is absent. And what about building a collapsible help, where click is done upon collapsible headers that reveal videos of 15 seconds each, to immediately assist an editor giving specific editing instructions? (coming soon)

This feature is to be primarily used in collapsible assistive boxes, not in articles, although one could find such a functionality useful to build collapsible serial map boxes for metro lines, where hide/show clickables, if used instead, would mess the box and annoy as the only clickable area to do expand/contract.

Hover highlighting is useful (or needed) in Template:user sandbox+ (granted) tool which renders like this User:ManosHacker/sandbox in English and like this el:Χρήστης:ManosHacker/πρόχειρο in Greek. There is quite a difference between the two, to catch the eye and the will to play.

Hover highlighting code, used in Greek Wikipedia, is placed in Mediawiki:Common.js and is given below.

$('.hover-bgc').hover( function() {
        $(this).attr("data-hover-bgc-original", $(this).css("background-color"))
        var parentSpec = $(this).parent('.hover-bgc-parent').attr('data-hover-bgc-child');
    $(this).css({ "background-color" : ((typeof parentSpec !== typeof undefined) && (parentSpec !== false)) ? parentSpec : $(this).attr('data-hover-bgc') });
}, function() {
    $(this).css({ "background-color" : $(this).attr('data-hover-bgc-original') });

I think it would be assistive to implement it in English.   ManosHacker talk 11:26, 25 February 2018 (UTC)

It would be great if an admin could add this, it is a feature that manos has been working on for a long time, it has been already implemented on greek wikipedia and soon is going to be added in couple of more Mardetanha (talk) 07:39, 1 March 2018 (UTC)

Ideas Wiki

I'm very nervous about posting here, as I know everyone is much more used to the space than I am. I hope this is the right place to post?

I work in a company that has a big investment in patents. There's a strong culture for staff to create and apply for patents and contribute to the portfolio. Given that patents are intended to offer a creative and fiscal monopoly to the company to recoup and profit from from the initial investment, one might expect the ideas to surface in products for the benefit of consumers/users and the company. This is mostly not how it works. The huge corporations can easily overcome the significant cost of entry to accrue huge portfolios, which are then used like currency to access other huge corporation's patents, where they agree to cross-authorise the use of large bundles of patents. The initial cost of patenting locks individuals and smaller companies out of the process and lack of utilisation of patents effectively locks everyone out of the opportunity to benefit from the bulk of patents, except at the largess of the patent holder. The result, in my opinion is a sclerotic system that mitigates 'the greater good' for the benefit of only the wealthy few.

The structure of Wikipedia, with articles and contributors with 'reputations' to grow/at-stake could be a good model for people with ideas and a philosophy that the greater good is far more important than concentration of wealth. Creating an ideas publication wiki would allow free access to all, allow creative sparking of new - yet related ideas and importantly, help stop corporations from land-grabbing and ring-fencing whole areas of creative endeavour and stifling innovation. One additional idea, that I'm not sure Wikipedia has that might be useful, is the software source control notion of 'forking' - as exemplified in Git.

Does anyone else out there think there's a case for creating a new Wikipedia wiki - perhaps 'Wikidea' ;oP to be a repository of the worlds good ideas, ready for free exploitation and perhaps protected by an appropriate open license or copyleft.

Thanks for listening

G — Preceding unsigned comment added by Noh.Jose (talkcontribs) 11:35, 27 February 2018 (UTC)

Wikipedia is a wiki, but far from the only one. This is an encyclopedia, so original research such as you suggest wouldn't work here, but if you want to create a website called Wikidea and have it hosted on something like Wikia or any of the other free websites, you're welcome to do so - you don't need permission from Wikipedia. Matt Deres (talk) 14:42, 2 March 2018 (UTC)
Hello, Noh.Jose! You may be interested in learning about Creative Commons and the Free Software Foundation. Good luck! --NaBUru38 (talk) 14:14, 14 March 2018 (UTC)

writing articles

hi I have a idea I want to say an article on the microphone and write on Wikipedia example I want creating article about Nintendo I say article on microphone and in Wikipedia type — Preceding unsigned comment added by Amirh123 (talkcontribs) 13:02, 28 February 2018 (UTC)

Not sure I understand what you mean. L3X1 ◊distænt write◊ 13:15, 28 February 2018 (UTC)
@Amirh123: we have an article called Microphone already, but it can always be updated. — xaosflux Talk 14:16, 28 February 2018 (UTC)
List of speech recognition software is probably what you're after. That said, unless your level of spoken English is reasonably fluent, trying to edit via voice is unlikely to be a happy event for anyone. ~Hydronium~Hydroxide~(Talk)~ 14:21, 28 February 2018 (UTC)
The people at WT:WikiProject Accessibility may be able to help - some of them use screen reader software which performs the reverse action. --Redrose64 🌹 (talk) 16:36, 8 March 2018 (UTC)

Infoboxes RFC

Arbcom is very likely to close a case in the next couple of weeks with a recommendation for a community discussion on infoboxes. I'm throwing out a rough draft of a comprehensive infobox RFC for the communities feedback.

Infobox RFC rough draft
2018 Infobox RFC

Infoboxes have been a heated topic on Wikipedia for at least a decade [42], and have included at least two arbcom cases. The most recent is likely to close with the following remedy:

Community discussion recommended

The Arbitration Committee recommends that well-publicized community discussions be held to address whether to adopt a policy or guideline addressing what factors should weigh in favor of or against including an infobox in a given article.

This is intended to be that discussion. Currently, the policy at WP:INFOBOX provides the following guidance:

The use of infoboxes is neither required nor prohibited for any article. Whether to include an infobox, which infobox to include, and which parts of the infobox to use, is determined through discussion and consensus among the editors at each individual article.

In practice, this guidance has proven to be insufficient, and has resulted in a large quantity of very similar discussions taking place at every article where a dispute is present.

The current arbcom case is likey to improve the climate of infobox related discussions significantly, but remand the substantive question of "Which articles should have infoboxes" back to the community. Therefore, we need to decide the following:

What guidance should be provided for infoboxes in stub articles?
  • A) The majority of stubs should ideally have an infobox. A compelling reason specific to the stub is needed to deliberately exclude an infobox.
  • B) No project-wide guidance is given on infoboxes in stubs. If a discussion on an infobox reaches a "No Consensus" outcome, it should default to including the infobox.
  • C) No project-wide guidance is given on infoboxes in stubs. If a discussion on an infobox reaches a "No Consensus" outcome, it should default to excluding the infobox.
  • D) The majority of stubs should ideally not have an infobox. A compelling reason specific to the stub is needed to deliberately include an infobox. Editors that are hellbent on including an infobox should first expand the article beyond a stub.
What guidance should be provided for infoboxes in non-stub biographies?
  • A) The majority of non-stub biographies should ideally have an infobox. A compelling reason specific to the article is needed to deliberately exclude an infobox.
  • B) No project-wide guidance is given on infoboxes in non-stub biographies. If a discussion on an infobox reaches a "No Consensus" outcome, it should default to including the infobox.
  • C) No project-wide guidance is given on infoboxes in non-stub biographies. If a discussion on an infobox reaches a "No Consensus" outcome, it should default to excluding the infobox.
  • D) The majority of non-stub biographies should ideally not have an infobox. A compelling reason specific to the article is needed to deliberately include an infobox.

What guidance should be provided for infoboxes in non-stub articles on a species or subspecies?
  • A) The majority of non-stub articles on a species or subspecies should ideally have an infobox. A compelling reason specific to the article is needed to deliberately exclude an infobox.
  • B) No project-wide guidance is given on infoboxes in non-stub articles on a species or subspecies. If a discussion on an infobox reaches a "No Consensus" outcome, it should default to including the infobox.
  • C) No project-wide guidance is given on infoboxes in non-stub articles on a species or subspecies. If a discussion on an infobox reaches a "No Consensus" outcome, it should default to excluding the infobox.
  • D) The majority of non-stub articles on a species or subspecies should ideally not have an infobox. A compelling reason specific to the article is needed to deliberately include an infobox.
What guidance should be provided for infoboxes in articles on a chemical substance
  • A) The majority of non-stub articles on a chemical substance should ideally have an infobox. A compelling reason specific to the article is needed to deliberately exclude an infobox.
  • B) No project-wide guidance is given on infoboxes in non-stub articles on a chemical substance. If a discussion on an infobox reaches a "No Consensus" outcome, it should default to including the infobox.
  • C) No project-wide guidance is given on infoboxes in non-stub articles on a chemical substance. If a discussion on an infobox reaches a "No Consensus" outcome, it should default to excluding the infobox.
  • D) The majority of non-stub articles on a chemical substance should ideally not have an infobox. A compelling reason specific to the article is needed to deliberately include an infobox.
What guidance should be provided for infoboxes in articles not explicitly addressed above
  • A) The majority of other articles should ideally have an infobox. A compelling reason specific to the article is needed to deliberately exclude an infobox.
  • B) No project-wide guidance is given on infoboxes in other articles. If a discussion on an infobox reaches a "No Consensus" outcome, it should default to including the infobox.
  • C) No project-wide guidance is given on infoboxes in other articles. If a discussion on an infobox reaches a "No Consensus" outcome, it should default to excluding the infobox.
  • D) The majority of other articles should ideally not have an infobox. A compelling reason specific to the article is needed to deliberately include an infobox.
Article level templates

After a discussion concludes regarding infoboxes at an article, should a template, providing a link to the most recent discussion, and a summary of the result be placed at the top of that article?

Discussion Moratoriums

After a discussion on infoboxes in an article concludes, should there be a mandatory waiting period before reopening the same discussion at the same article. If the answer to this question is yes, a follow-up RFC will determine an appropriate duration.

Cheers, Tazerdadog (talk) 11:58, 10 March 2018 (UTC)

I think its unecessary to discuss chemical substances out of all things you could select when its completely and utterly uncontroversial there. I think rather than having a comprehensive infoboxes rfc it may be more useful to have a biographical infoboxes rfc, where a guideline can be drafted and be put forward to gain consensus, because that's where the controversy is most. Galobtter (pingó mió) 12:06, 10 March 2018 (UTC)
So could we discuss stubs, Nonstub biographies, and everything else and remove the chemical substance and species/subspecies cases and still come out with a useful consensus? Tazerdadog (talk) 12:13, 10 March 2018 (UTC)
In many, or even most domains, infoboxes are clearly uncontroversial. Why have an RFC on uncontroversial matter? --Izno (talk) 15:26, 10 March 2018 (UTC)
Yes, there is no need to waste time on non-controversial cases, where infoboxes should be, and mostly are used already. For some kinds of topic there may be no infobox, and for some others there may be a template that is seldom used. I suspect that biographies are the only real troublesome area. Graeme Bartlett (talk) 22:06, 10 March 2018 (UTC)
  • Sharing my opinion with the full disclose that I haven't been involved in any infobox dramas. I don't think any proposal for simple and specific criteria for which articles should have an infobox is likely to pass. Take stubs for example: generally, there are reasons to avoid placing infoboxes on such small articles (e.g. clutter in mobile view, nothing in the article to summarise etc.), but there are large numbers of cases where the infobox is the main (or the only) place where certain kinds of information are usually displayed (for species, or for populated places, or for railway stations), so an infobox there will be desirable regardless of the size of the article. I think that any acceptable explicit criteria will be either extremely complicated (and hence difficult to accept in the first place and once accepted, easy to ignore), or they will have to be couched in a very loose way, and so leaving room for long discussions in every individual case.
    However, what I see as practical is the proposal of some rules for deciding on a default option in cases where an individual discussion hasn't achieved a clear consensus. I'm thinking of something in the same general direction as MOS:RETAIN or WP:NOCON for the case of page titles, to quote from the latter: "If it has never been stable, or it has been unstable for a long time, and no consensus can be reached on what the title should be, default to the title used by the first major contributor after the article ceased to be a stub."
    There ought to be a way to steer clear of WP:OWN, but at the same follow the common sense approach to matters of style and simply respect the choices and preferences of those who have contributed the most to the given article. – Uanfala (talk) 01:09, 11 March 2018 (UTC)
  • Any Infobox that is a NavBoxes in disguise should be converted to a NavBox. It is adding unnecessarily clutter to the lead section. See, for example, {{Politics}}. The exception would be for list articles. Praemonitus (talk) 20:40, 16 March 2018 (UTC)

ML-based image classification

Writing to announce a proposal we have posted for a machine learning based image categorisation tool for the Wikimedia Commons.

We have already attracted some useful feedback from the Commons App and also discussed cooperation with the Commons: Structured Data project, however, we would be keen to get more feedback on the project.

Please drop us a line if you have ideas or if you would like to help.

Thanks! — Preceding unsigned comment added by Linasv (talkcontribs) 19:03, 10 March 2018 (UTC)

The status of WP:MEDCOM

Perhaps I'm wrong, but Wikipedia:Mediation Committee doesn't appear to get many (if any) cases, anymore. Though its existent isn't a problem, perhaps due to its mostly inactivity, the committee should be abolished. GoodDay (talk) 20:15, 11 March 2018 (UTC)

Unlike ArbCom, MedCom specifically deals with "Content Dispute" - and indeed is rarely used. @GoodDay: should this be dissolved, do you think it should somehow be replaced or merged in to something else? — xaosflux Talk 20:20, 11 March 2018 (UTC)
Seeing as we've got the Wikipedia:Dispute resolution noticeboard (created within the last 5 years), Medcom may well been somewhat replaced. GoodDay (talk) 20:33, 11 March 2018 (UTC)

Using photo requested template on articles

Have you ever written or stumbled across an article about a subject that you know can be illustrated, but no image you can find on the Internet is freely licensed? You could send an email to someone who does own an image of the subject and politely ask them to freely license their work, but they could say no. Alternatively, we have a template {{photo requested}} which goes on article talk pages, but our editing community might not have a photo of the subject. However, a reader might, but readers don't normally look at talk pages.

What if we created a version of {{photo requested}} that goes on the articles themselves instead of talk pages? This would engage our readers directly and let them know that if they have a picture, they can upload it and have it appear on Wikipedia, one of the most highly read websites in the world, immediately. It doesn't have to be a huge banner; I've created a proof of concept at User:Mz7/sandbox/article photo requested, which I've transcluded to the right. Is this a good idea? Pinging AntiCompositeNumber and Anna Frodesiak, whom I initially spoke to on IRC about this. Mz7 (talk) 10:08, 12 March 2018 (UTC)

It does actually look pretty good, plus it's small. I think Koko would want it in her article. That might encourage the Gorilla Foundation people to finally pony-up a darn photo. Do it for Koko. Anna Frodesiak (talk)
WP:PLACEHOLDERs (and the consensus which arrived at the today-state which is Wikipedia:Centralized discussion/Image placeholders). While it might be old, I would guess it enjoys broad consensus even still. An imperfect article is an imperfect article. --Izno (talk) 12:27, 12 March 2018 (UTC)
Ah shoot. I wasn't familiar with that old consensus. I would just say that I think my proposal is slightly different. The discussion seems to be about placeholder images like File:Replace this image (building).svg that go directly where an image would be in an article, whereas this would be a message box template. However, the two implementations result in the same functionality, so I would agree a broader discussion is needed to overturn the past consensus. Mz7 (talk) 19:31, 12 March 2018 (UTC)
@Mz7: I like the idea in general - but don't want to see a million copies of that either, would need some guidelines for use. The only problem I have is that the "call to action" on that template (to commons:Commons:First_steps) seems to bulky for a non-wikimedian that wants to just donate 1 picture for the article they are reading "now". — xaosflux Talk 13:12, 12 March 2018 (UTC)
I was definitely thinking there should be guidelines for its usage. It shouldn't be on just any article that lacks a photo, but articles where a Wikipedia reader likely has a photo and no free image can be found elsewhere. For example, readers probably wouldn't have a photo for an article about an obscure person who has been dead for some time, but an image might be produced for a notable building in a country that has freedom of panorama. The reasoning behind commons:Commons:First steps was that Wikimedia has rather strict requirements on licensing, so to avoid having users upload photos that don't strictly belong to them and possibly getting bitten for it, I thought it would be beneficial to link to some page that explains clearly what kinds of images are and are not acceptable. commons:Commons:First steps seemed as good as any, though I would welcome alternative suggestions. Mz7 (talk) 19:31, 12 March 2018 (UTC)
Could always send them to OTRS. is specifically designed for this purpose. Not a whole lot of people know about that queue and requests that don't have additional issues are usually processed pretty quickly. It might even be beneficial to list that email in more places. The only place I know it exists is buried in Wikipedia:Contact us - Licensing. --Majora (talk) 04:25, 15 March 2018 (UTC)
That's brilliant, Mz7! I always thought we needed something like that, since I consider major, non-photographed articles to be a real problem, especially when it comes to things like endagered species. Sadly I can't offer much help; the editors above me seem to know a lot more what they're doing. Double Plus Ungood (talk) 14:48, 15 March 2018 (UTC)



It is March 2018. Wikipedia is blocked in Turkey. This marks 10 months of people in Turkey having no access to the world’s free knowledge, and people around the world not learning from Turkish citizens. We want to re-energize the conversation around Wikipedia in Turkey and galvanize public opinion to support unblocking the site. To do this, the Wikimedia community are running a week-long social media push to express why #WeMissTurkey. Following from this initial push we would like to run a CentralNotice campaign to further energize the conversation. The campaign will be only be show to users a maximum of two times to limit disruption and show, to between 10-50% of traffic. Banners will be low profile based on the community template with added functionality to expand revealing social sharing options on twitter and facebook for mobile with the possibility of a generic template on desktop. Seddon (WMF) (talk) 20:32, 7 March 2018 (UTC)

If the lack of Wikipedia was really an issue, somebody else would've setup a censored fork—even proxy edits back with OAuth. China's been blocking us for 5+ years now? — Dispenser 00:22, 12 March 2018 (UTC)
I didn't read our article closely enough the first time, so there is what appears to be a live proxy mirror. — Dispenser 00:37, 12 March 2018 (UTC)

Languages section on side of articles now truncated?

I just noticed this today, and am hoping it's all part of some temporary A/B test that I've had the misfortune of being in the wrong group for, but apparently the Languages section over on the left of any article is now limited to like 10 or so languages, with the rest hidden behind a "N more" link. I hate this for a variety of reasons: 1) can't see at a glance if my desired language is there / can't ctrl-F either, 2) the choices for which languages to display seem to be a mystery, and I think this inconsistency across pages makes for a bad user experience, 3) there seems to be no way of disabling this (or at least not w/o logging in, which I don't want to do), 4) the pop-up behind the "N more" link is easy to misclick and close while trying to scroll down it, 5) the links in the pop-up seem to override normal ctrl-click behavior so that instead of just opening the link in a new tab, it also opens the clicked link in the current tab. I was trying to remember the Chilean term for zucchini (it's zapallo italiano, BTW), but the list in the pop-up is terrible, because (aside from not having Español, which I realize is a separate issue), 6) the first category is just a repeat of the languages already listed, but 7) with the Korean link inexplicably on its own separate line within that section, 8) the next section being some vague "Worldwide" section (who decides what's worldwide?), 9) the next section being "America" which I find horribly vague (I'm guessing by its content they meant "Americas") and confusing since Nederlands is there (though I guess that's my fault for not realizing there are a few Dutch-speaking places near the Caribbean). Portuguese is repeated in like every freaking section. God, that layout is hard to scan.

Anyway, I clearly dislike this feature/bug, but when trying to look for something about this change, all my Google searches for things like "wikipedia user interface languages" of course just result in things like the WP user interface article. (If anybody has helpful hints for how to do things like "meta" searches for stuff about WP itself, that would be super helpful!) Given the difficulty of finding meta-information about WP, I'm not even sure I'm posting this in the right place, so my apologies if this should be elsewhere. If someone could point me to more information about this change and/or a better channel for expressing my dissatisfaction with it (unless I'm already at the right place?), that would be great. Thanks! 2601:141:2:8644:5CBA:7EA3:23ED:3A67 (talk) 06:44, 9 March 2018 (UTC)

This is Compact Language Links. "New Wikipedia feature gives you the power to choose whatever language you want" — JJMC89(T·C) 06:55, 9 March 2018 (UTC)
The ctrl-click issue is indeed a bug. Thanks for pointing it out. It will be fixed soon. See .
Spanish is not there because there simply isn't a version of Zucchini in Spanish. And that is, indeed, a separate issue. Only one article in another language can be fixed because of how Wikidata works, and Cucurbita pepo is already linked to Spanish.
Scanning the whole list is not really necessary because you can use the search box on top of the panel to find the language you need. --Amir E. Aharoni (talk) 12:57, 13 March 2018 (UTC)

Referencing: "passim"

I recently found myself using the word passim in a reference.[43][1] Is this an acceptable form? (I have not seen this used anywhere else in Wikipedia.) My intent was to differentiate the reference from one where the editor had not bothered to consider page numbers. In this case the subject is covered extensively throughout the book and any attempt to give individual or blocks of page numbers would be a mess.

Incidentally, the italicisation of passim does not occur in the article where I used it and I cannot make that change at present as the page is currently protected as it has attracted a lot (!!) of editing in another section.
ThoughtIdRetired (talk) 08:51, 13 March 2018 (UTC)


  1. ^ Hellwinkel, Lars (2014). Hitler's Gateway to the Atlantic: German Naval Bases in France 1940-1945 (Kindle ed.). Barnsley: Seaforth Publishing. p. passim. ISBN 9781848321991. 
Mentioned at Template:Cite book nopp. This insource search finds quite a few uses of the word.
Trappist the monk (talk) 12:51, 13 March 2018 (UTC)
I'm not sure about the situation in other English dialects but in my experience it's definitely obsolete in American English. Most American writers are trained to identify and cite specific page ranges, which makes it much easier for a reader or cite-checker to verify the accuracy of a citation. --Coolcaesar (talk) 10:44, 16 March 2018 (UTC)
I'd have thought (as a Brit) that bits of Latin unfamiliar to many general readers should be avoided if possible. Can't you say "various pages" or, better, give a couple of the locations that best support your point and say "p. 245–250, 387–389 and other pages"?: Noyster (talk), 11:04, 16 March 2018 (UTC)

I am sorry to bother you but I need all your help

Hi I am Jasonnn, from the chinese version of wikipedia. I tried to translate pages like List of Germans and List_of_Danes and same other pages into chinese. From time to time there are people put these pages into "Wikipedia:Articles for deletion", and two administrators @AT: and @Lanwi1: keep deleting these pages. So far they have deleted the chinese version of List_of_Thai_people, List of Portuguese people, Lists of New Zealanders, List of Swiss people, List of French people and 4 more, they are about to delete the chinese version of List_of_Germans and 24 other pages[44].

I made a post about List_of_Thai_people and 4 other pages to "Wikipedia:Deletion review" in 2018.1.31 [45], so far no result. Then I made another post about asking to remove those two administrators[46], cause i think they are being unreasonable and delete my pages on purpose, i @ all the chinese administrators, about 76 people, only two replyed and they are not on my side.

This leaves me no choice, so i post here ask for all your help. I am hoping you could put some pressure on some chinese administrators, so someone could come slove this. Thank you for your help.--Jasonnn~zhwiki (talk) 13:42, 15 March 2018 (UTC)

  • The different language versions of WP are all independent projects that each have different sets of rules... so we can not help. Sorry. Blueboar (talk) 14:16, 15 March 2018 (UTC)
Please stop doing something like this. Your actions is completely useless as here is English Wikipedia, which is independent from Chinese Wikipedia. The only reason of you "@ all the chinese administrators, about 76 people, only two replyed and they are not on my side" is that your thoughts has problems. In fact, as I could see, nearly no one is on your side. Don't you think that it's your problem? Let me said it one more time in Chinese to make sure no misunderstanding: 請停止這樣的行為,這樣的行為是完全沒有用的。這裡是英語維基百科,其與中文維基百科是兩個獨立的項目,造成你「@ all the chinese administrators, about 76 people, only two replyed and they are not on my side」的原因只有一個,就是你的想法有問題,其實以我所見,幾乎沒有人同意你的觀點,你何不想想這是否是你的問題?--【wopingzisoeng】💬📝 09:56, 16 March 2018 (UTC)
There is a WP:LISTPEOPLE guideline in English Wikipedia, while there is no such guideline in Chinese Wikipedia. As a contributor to both projects, my suggestion is to contribute to pages in category "Lists of people by nationality" here. Did you know... that you can talk to Dingruogu? 18:08, 16 March 2018 (UTC)
In zhwiki,Our guideline is the list should not be simply replaced by categories,provide other information such as comparable information--Zest (Zh-n,En-read-2,En-write-1.5) 01:05, 17 March 2018 (UTC)
@Blueboar: I am sorry that Jasonnn~zhwiki had bothered you with a useless question. Please ignore the dispute happened in the Chinese Wikipedia, thank you. — Sanmosa 01:51, 17 March 2018 (UTC)

Simple guide to uploading a photo taken by yourself

I am thinking of writing to a few serving politicians to suggest that they organise the upload of photos of themselves. (These are all cases where we have either no existing photo of the person, or only poor photos).

I was looking for a simple, concise how-to-guide on this, and the Commons:Special:UploadWizard seems reasonably simple.

Has anyone done a sort of pro-forma letter to use in such cases?

Something along the lines of:

  1. the article about you will be better with a decent pic etc blah
  2. the whole copyright thing is simplest if the pic is uploaded by the copyright owner, who in most cases will be the person who took the photo
  3. Any picture which is uploaded to Commons has to be released under a license which allows reuse. The default license is [[Creative Commons Attribution-Share Alike 4.0 International license (, which requires that any reuse be attributed to the author.
  4. The upload form is at
  5. Choose a meaningful filename for the uploaded image
  6. thank you etc

--BrownHairedGirl (talk) • (contribs) 16:44, 15 March 2018 (UTC)

Pictures in Wikipedia are from Wikimedia Commons. This is at which is where they should be uploaded.
No need going into the complex question of categorization and I guess we can rely on Upload Wizard to guide photographers or someone on the politician's staff. Oh, they must make an account. Jim.henderson (talk) 17:55, 15 March 2018 (UTC)
There are some OTRS templates for people who inquire about getting a picture on their article. You might ping someone on OTRS to see what they have written out. Killiondude (talk) 22:49, 15 March 2018 (UTC)

Wiki Loves Emirates

Next month (April 2018), we will be organising first ever Wikipedia photo campaign in the UAE to get free licensed photos related to country. We will be running a CN banner to publicise the event which will be only be show to users (both registered and unregistered) inside the country. Any concerns? --Saqib (talk) 05:41, 16 March 2018 (UTC)

Retrieved from ""
This content was retrieved from Wikipedia :
This page is based on the copyrighted Wikipedia article "Wikipedia:Village pump (all)"; it is used under the Creative Commons Attribution-ShareAlike 3.0 Unported License (CC-BY-SA). You may redistribute it, verbatim or modified, providing that you comply with the terms of the CC-BY-SA