This page uses content from Wikipedia and is licensed under CC BY-SA.

Wikipedia:Village pump (all)

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)

  • Yes, I believe used those figures. There were a number of lists, books, categories, disambigs, templates, files and redirects etc., but they amounted to a small fraction of the total articles. Hadn't considered untagged articles or group bios, but I think between 1 and 2 million articles seems a pretty reasonably estimate. But even if was only half a million, it's more than the DoY articles could handle. ‑‑YodinT 10:30, 20 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.

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:
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 Newspeak. Guy (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:
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)
  • Oppose as existing guidelines are sufficient. –Davey2010Talk 00:13, 20 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 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
  • 1, 2, 3, ...
  • A, B, C, ...
  • I, V, X, ...
  • 1, 2, 3, ...
  • A, B, C, ...
  • I, V, X, ...
  • 1, 2, 3, ...
  • A, B, C, ...
  • I, V, X, ...
  • 1, 2, 3, ...
  • A, B, C, ...
  • I, V, X, ...

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)
  • It's worth pointing out that Markdask is (probably) talking about this revision of the article. And I'd agree that his individual lectures shouldn't be covered with so much detail, and should be rolled into "Political views" and "Criticism" sections. Brightgalrs (/braɪtˈɡæl.ərˌɛs/)[ᴛ] 13:35, 19 March 2018 (UTC)

RfC on permanent implementation of ACTRIAL

There is currently a request for comment at Wikipedia:Autoconfirmed article creation trial/Request for comment on permanent implementation about whether or not autoconfirmed status should be required to create an article in the main space. This is a follow up to the recently ended autoconfirmed article creation trial (ACTRIAL). All are invited to participate. TonyBallioni (talk) 13:40, 19 March 2018 (UTC)

Quotes (statements)

Hello, does the copyright violation the quote Summer All Stars music group? The statement has 42 words and is on the [] in the second paragraph. --Patriccck (talk) 14:36, 19 March 2018 (UTC)

Patriccck you can include short quotations in articles, if that's what you are asking. In terms of length the 42-word quote seems alright. See MOS:QUOTE for how to do this. – Finnusertop (talkcontribs)
Finnusertop Thank you for your answer.--Patriccck (talk) 15:03, 20 March 2018 (UTC)
Finnusertop Here is the quote: Léto_lásky#Music_video --Patriccck (talk) 15:22, 20 March 2018 (UTC)
Yeah, Patriccck, it's (almost) properly formatted (you have to choose: blockquotes don't have quotations marks; quotes with quotation marks aren't indented). Perhaps add an introductory sentence before it also. Something like "Summer All Stars members commented on the content of the music video: " ... – Finnusertop (talkcontribs) 16:00, 20 March 2018 (UTC)

Homework, and no intention to publish

I'm troubled by a WikiEd student's declaration at WikiEd content advisor Shalor's talk page, that they "have no intention of publishing [their]article....". They follow that with a caveat that might lead to publication, but I wonder if that's sufficient to mitigate what seems to me a clear indication of WP:NOTHERE, and a possible violation of WP:NOTHOSTING.

I'm actually not particularly worried about this one case and would be willing to let it go; it's merely symptomatic of my underlying concern. What I'm actually concerned about is policy regarding the limits of editing behavior of students enrolled in WikiEd courses, some, perhaps most, of whom seem to fit the description in WP:NOTHERE to a tee[a] as they are here solely to use WP as a drive-by homework assignment hosting service, never to be seen again once their brownie points letter grade is received, and leaving regular editors to clean up any messes encountered. To some extent, the behavior of such students is similar to any new editor, but differs in that they are essentially required by their instructor to post content in order to succeed in their course, which is very different than the motivations and pressures other newbies experience. So far, I haven't encountered students who are posting on Draft or Talk pages with no intention to publish at all, so maybe that's a new trend.

The outcome I'd like to see, if others agree, is some mention at WP:NOTHERE and/or at WP:NOT of the proper use of Wikipedia by students, with the word "homework" in their somewhere (or maybe as a shortcut[b]) so I can find it again if I need it. I'm content to leave the OP to continue hosting their project here, especially since I assume nobody told them they couldn't, but a policy clarification going forward would seem desirable. Mathglot (talk) 04:29, 20 March 2018 (UTC)

  • Shalor replied appropriately. It's OK in sandbox, test edits and learning how to use Wikipedia is what sandbox is for. Of course, although the quality of articles and edits by students is often disappointing, I would prefer they be WP:BOLD and publish their work (assuming they chose a verifiable and notable topic). Yes, there's clean-up to do, but that's not exclusive to WikiEd students. Jack N. Stock (talk) 04:45, 20 March 2018 (UTC)


  1. ^ WP:NOTHERE: Trying to score brownie points outside of Wikipedia: Edits intended for the sole purpose of impressing or amusing third parties outside of Wikipedia, without expecting the edit to remain in place or caring if it doesn't.
  2. ^ Unfortunately, the shortcut WP:HOMEWORK is already taken for something else.

I patrol a lot of draft amd userspace and I've found quite a bit of this homework. It's hard to get rid of it too because, while not suitable for mainspace, it's usually on notable topics and not readily CSDable. We don't need some kid's take on the civil war though, and I'm not here to grade their paper. It's not that the homework is "bad" but it makes it harder to find the bad pages we need to eliminate. Legacypac (talk) 04:47, 20 March 2018 (UTC)

Forgot to mention another outcome I'd like to see, which is some kind of restriction, or at least careful advice to students a priori, of student editors working on articles under Arbcom Discretionary Sanctions. These areas are difficult for any new editor, but when your grade depends upon it, that seems particularly delicate. This would affect a lot of students enrolled in gender-related courses, but that's an area I also work in, and so I'm familiar with some of the problems it creates. Mathglot (talk) 04:54, 20 March 2018 (UTC)
@Mathglot: WP:NOTHOMEWORK...? —SerialNumber54129...speculates 09:46, 20 March 2018 (UTC)
Nice. Mathglot (talk) 11:58, 20 March 2018 (UTC)
  • Not sure that I fully understand what the underlying issue is... what specific problem are we trying to resolve? Blueboar (talk) 12:58, 20 March 2018 (UTC)
@Blueboar: Using WP as a webhost I believe. —SerialNumber54129...speculates 14:37, 20 March 2018 (UTC)
Hmm... I’m not sure that this sort of thing falls under WP:NOTWEBHOST. There is at least the POTENTIAL for an article (or article improvement) in situations like this. Sure, the student has said he/she does not intend to publish, but that could change. I don’t see any harm in keeping a draft article in userspace, and I see at least the POTENTIAL for some benefit in doing so. Blueboar (talk) 16:00, 20 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

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 []. 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)

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)

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)

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 [15] 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)
It could be interesting to log watchlist changes somewhere. Added phab:T190003 which may or may not be a duplicate as I haven't checked. Please check its status in the coming days. Gryllida (talk) 02:28, 19 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)
I think this could make copyvios harder to detect as the users would start rewording the plagiarised text until the copyvio detector stops complaining (but the copyvio issue would remain simply by putting words in different order). I would personally favour making more adequate use of edit intros and interactive wizards which encourage users to copy/paste quotes from sources into a dedicated text area so that they do not have to switch tabs back and forth, and have an opportunity to rewrite them in their own words in the article. Gryllida (talk) 02:24, 19 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)
TheDJ, mediawiki without user scripts would be difficult to use, no? How do you think that would be implemented? Experienced editors would perhaps have to rely on desktop apps instead of using the web site. There is just so many routine tasks which need to be customized by the user that I do not know how that ecosystem would even work. For instance I started reviewing drafts recently and I find I often need to mark things and add comments ('wonderful professor(biased, rephrase or remove)' kind of thing inline). If not for user scripts then doing this would become rather laborious and time consuming. Gryllida (talk) 02:20, 19 March 2018 (UTC)
JavaScript is wonderful but it can produce problems. Paraphrased from wikimedia-l, a recent snafu resulted in JavaScript from Facebook being used for a certain central banner. The result was that Facebook received data about who viewed any page displaying the banner (no click required). The banner was only displayed for IPs, so only they were affected, and only for a short time. Johnuniq (talk) 06:07, 19 March 2018 (UTC)
I didn't say "without Javascript". I said without user scripts and site scripts. We would likely only have (global) gadgets. —TheDJ (talkcontribs) 08:26, 19 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)

Huh. Error no longer reproducing today. ¯\_(ツ)_/¯ Nope, jinxed it. Appears only to be happening when I edit the section nearest the error. Innisfree987 (talk) 20:13, 18 March 2018 (UTC)
Thanks for this bug report! I wish we knew how to reproduce it reliably, because a third-party MediaWiki site was asking about this recently (they really want to add extra blank lines/whitespace on their pages). I think I can trigger it by adding a single space at the very end of the paragraph that begins "After layoffs at MTV News". Does that work for you? Or do you have any other ideas about how to reproduce this? Whatamidoing (WMF) (talk) 19:21, 20 March 2018 (UTC)
Ha, yes I would gladly hand off the bug to someone who has a use for it! Let me tinker a bit and see if I can pin it down more precisely for you. More TK. Innisfree987 (talk) 19:30, 20 March 2018 (UTC)
Ok, looking more closely: one thing I can tell you is the bug appears to have moved (or, the text moved around the bug, who can say?) In the first three instances I cited, it came above the paragraph you mention; the most recent time, it came afterward. Will now go test-edit more systematically, more shortly. Innisfree987 (talk) 23:09, 20 March 2018 (UTC)
Hi there, so I've played around with it and I do think any edit--addition or subtraction--to the paragraph you mention triggers the additional lines. I now don't find the same thing happening with any other paragraph in that section, even though, as I mention above, previously the bug had added lines elsewhere. I did move big chunks of text around though (e.g. here), and I have not closely examined whether the bug followed those moves. What I can tell you is that if in perusing revisions, you see extra lines where they don't belong, it was almost definitely the bug--of course an errant click on the return key that I just overlooked is possible, but I didn't have any instances, e.g. where I know hit "save" sooner than I meant to and accidentally left in extra lines I had meant to clean up.
Does that help? Let me know if there's anything else I can do! Innisfree987 (talk) 23:32, 20 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)
Thanks User:This, that and the other and User:BJorsch (WMF). Rehman 04:10, 19 March 2018 (UTC)
@Rehman: The error in File:Enwiki restore error 2.png should be fixed now. The other error may or may not still remain; if so, please file a separate task in Phabricator about it. BJorsch (WMF) (talk) 22:17, 19 March 2018 (UTC)
Thank you BJorsch (WMF). The errors no longer exist. Best regards, Rehman 03:30, 20 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)

Getting a bot to run of WMF servers

After a long period of sleep I wanted to reactivate my bot for Teahouse archival notification (see Wikipedia:Bots/Requests_for_approval/Tigraan-testbot for details) to get it run on WMF servers as a cron job. However, the documentation to getting a bot run on the servers is quite hard to decipher. If someone could give me a step-by-step guide (either here or on my TP) it would be nice. (I already have the source code I want to run, and it would probably pass BRFA easily since it is just a refactoring of the previously-approved task, but I do not have any account on the WMF servers or OAuth key or whatever else is needed to technically run the thing). TigraanClick here to contact me 20:57, 18 March 2018 (UTC)

Hi thank you for asking. :-) This should hopefully be relatively easy. [] says
1. Create an LDAP account (you must have an LDAP account to access the Toolforge project) []
2. Add a public SSH key (you will need this to access Toolforge servers using SSH) []
3. Request access to the Toolforge project (Join us!) []
4. Create a new Tool []
Once you are in the system via your username, use 'become toolname' to log in under the tool's account, 'jsub script' to submit your job to the cluster queue. wikitech:Help:Toolforge/Grid#Submitting_simple_one-off_jobs_using_'jsub'.
Use #wikimedia-cloud connect to ask for help on live chat. Gryllida (talk) 02:14, 19 March 2018 (UTC)
Thank you Gryllida. I just requested toolforge access. I cannot ssh into right now (access denied even though I am pretty sure of my SSH footwork) but this could be because I do not have the credentials yet. TigraanClick here to contact me 18:36, 19 March 2018 (UTC)
Tigraan gerrit is a code review tool for mediawiki developers you do not need to log in there. Try logging in to instead using a username that is all lowercase. I see your username is in the system as "id tigraan" returns me "uid=19061(tigraan) gid=500(wikidev) groups=500(wikidev)" so I am not sure of its status but at least it is there. --Gryllida (talk) 22:33, 19 March 2018 (UTC)
I think you need to wait for step 3 to finish as I am in a user group called 'project-tools' which you are not. Perhaps give it several hours or days but it should be a quick process I think. --Gryllida (talk) 22:35, 19 March 2018 (UTC)

Line breaks don't appear in edit summaries without spaces in watchlists / contrib pages

This diff page shows my long edit summary wrapping so as to not run way off the end of the page. However, this permalink page shows that same edit summary running way off the end of the page, and the same occurs when viewing this edit in my watchlist or contributions page. Is this a bug (and if so, has a Phabricator report already been filed)? Has this always been the case and I just didn't notice because I don't normally use long edit summaries without spaces? Regardless, it is an issue that needs fixing. Master of Time (talk) 23:31, 18 March 2018 (UTC)

For me at the permalink the edit summary does not exceed screen width. Gryllida (talk) 02:10, 19 March 2018 (UTC)
This is how it displays for me. Master of Time (talk) 02:18, 19 March 2018 (UTC)
@Gryllida: Does the edit summary just cut off? Or does it actually display as multiple lines? Do you have a very wide monitor perhaps? Master of Time (talk) 02:18, 19 March 2018 (UTC)
Confirm with monobook, vector, not with timeless skin. Gryllida (talk) 02:30, 19 March 2018 (UTC)
The timeless skin technically just 'covers up' the right side. If I click my middle mouse in the center part of the page, it still lets me drag way off to the right. The very end of the edit summary is a lowercase v. With that being the case, every skin has the problem where the edit summary won't break into multiple lines despite not fitting on the page. Master of Time (talk) 02:40, 19 March 2018 (UTC)
No, the timeless skin wraps. It does not cut off.
It has "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXY" on the first line and "ZabcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyzABCDEF" on the next line (and a few more lines to follow).
Add "#mw-revision-info .comment { word-wrap: break-word; display: block; }" to your common.css (Special:MyPage/common.css) to fix it, I think that's what it does. Gryllida (talk) 03:13, 19 March 2018 (UTC)
That didn't do anything, unfortunately. My edit summaries still won't wrap properly. Master of Time (talk) 03:55, 19 March 2018 (UTC)
This is due to en.wp's use of mbox tables of the the mw-revision-info. Leave a comment at MediaWiki_talk:Common.css and when I or someone else has some time, we can probably fix it. (Or maybe it's time to finally rewrite our mboxes to get rid of those tables...) —TheDJ (talkcontribs) 08:32, 19 March 2018 (UTC)
Whatever it is, it is working for me with the CSS applied when I use the ?useskin=monobook or vector parameter. I apologize for misleading commentary about my suggested css code fixing the issue, perhaps someone who uses monobook as their main skin may be able to resolve the problem further. --Gryllida (talk) 22:37, 19 March 2018 (UTC)

Please volunteer to document mw:Extension:Graph, update it to use Vega 3?

Hi all! mw:Extension:Graph allows to draw graphs and charts and variously sized and colored points on maps. Documentation appears to be lacking using Vega 2 library. Vega version 3.0 documentation is not very introductory level. :-) Do we have volunteers who could expand the extension documentation to include an explanation of how its features work, starting from hello world and gradually increasing complexity? And or volunteers to update the extension to Vega 3?

Specifically what interests me is the ability to create timelines spanning across several days with events with hours and minutes. I had tried this at mw:User:Gryllida/sandbox (starting from mw:Extension:Graph/Demo#Timeline_/_lifeline) but could not figure out how it should work. No error message has been produced. --Gryllida (talk) 02:08, 19 March 2018 (UTC)

To clarify, what I expect to make or use is a template that takes a set of timestamps and strings as argument and outputs a timeline, for instance,
|2018-03-01 12:04:I had lunch {{fixed}}
|2018-03-02 08:01:Someone had [[breakfast]] in a hall.}}
Would output a timeline with these times set (and 20% at each side of the earliest and latest event for readability). The annotations need to be able to contain clickable links and images. --Gryllida (talk) 03:22, 19 March 2018 (UTC)
Gryllida there's {{Simple_Horizontal_timeline}} and mw:Extension:EasyTimeline either of which would be simpler for this case, I assume Galobtter (pingó mió) 09:14, 19 March 2018 (UTC)
from and to cannot be nil or equal.? -Gryllida (talk) 11:00, 19 March 2018 (UTC)
Hmm, simple horizontal timeline only supports individual years. Galobtter (pingó mió) 13:19, 19 March 2018 (UTC)
Please don't use EasyTimeline anymore. It has a lot of bugs and display issues that are virtually impossible to fix, not to mention that its timelines look terrible. (Having said that, I don't know what the current state of the art is for timelines and the like. Presumably it is Graph, if anyone can work out how to use it.) — This, that and the other (talk) 11:06, 19 March 2018 (UTC)
If we can eliminate its usage on all current pages perhaps it is worth uninstalling it. --Gryllida (talk) 00:47, 20 March 2018 (UTC)

Tech News: 2018-12

15:03, 19 March 2018 (UTC)

Message sent by User:Trizek (WMF)@metawiki using the list at []

No mention of edit summary pings being deployed...? Are they live now or what? Thought that'd go into tech news issue. --Gryllida (talk) 22:39, 19 March 2018 (UTC)
It was mentioned last week, see #Tech News: 2018-11 above. Anomie 00:42, 20 March 2018 (UTC)
Oh, thanks, I think I missed that issue. Sorry. Thanks again. :-) Gryllida (talk) 00:48, 20 March 2018 (UTC)
Gryllida, I sometime miss things from Tech News as well, so I sometimes thing about a "Previously in Tech News" section on any new issue... :D (And thank you for the reply, Anomie!) Trizek (WMF) (talk) 15:28, 20 March 2018 (UTC)
Great thanks. :) (Please do not comment the last line as it shows which person delivered the message.) Gryllida (talk) 17:52, 20 March 2018 (UTC)
The line is appended by MediaWiki:Massmessage-hidden-comment with source: <!-- Message sent by User:[email protected]$2 using the list at $3 -->. It's designed to be a hidden comment as the message name says. I see no good reason to unhide it here. The post already says: "Tech news prepared by Tech News writers and posted by bot". PrimeHunter (talk) 18:33, 20 March 2018 (UTC)

Problem with thumbnail derived from xcf file

The_Immortal_Ten has a thumbnail in the top right of the page with obviously reversed colors. The original file at [30] looks fine, and there is a thumbnail on the image page that looks fine. I'm not sure if this is a Wikimedia bug, or if the thumbnail needs to be regenerated, but I'm not seeing an obvious way to fix this myself. Wingedsubmariner (talk) 16:51, 19 March 2018 (UTC)

@Wingedsubmariner: the thumbnail on that page for File:Immortal10WP.xcf looks fine to me, try clearing your cache and checking again? — xaosflux Talk 15:44, 20 March 2018 (UTC)
Note, it does appear to render 'darker' (more contrast - but not "reversed") in IE compared to FF and Chrome. — xaosflux Talk 15:47, 20 March 2018 (UTC)
@Xaosflux:Strange, it looks fine for me too now. Should have taken a screenshot. Wingedsubmariner (talk) 17:02, 20 March 2018 (UTC)

Template to test whether string is a decade?


Is there any template which will test whether a string is a decade? Or parser code to do the same job?

I want something which will return a true/non-null for a valid decade (e.g. "1830s", "560s") but return a false/null value for a non-decade (e.g. "1741", "1920x", "sdsjjdh").

Any suggestions? --BrownHairedGirl (talk) • (contribs) 17:28, 19 March 2018 (UTC)

Ah I found I can do it with Module:String:
--BrownHairedGirl (talk) • (contribs) 17:51, 19 March 2018 (UTC)
That won't work for "560s". That'd be {{#invoke:String|match|{{{DateWhichMayBeaDecade|}}}|^%d?%d?%d?0s$|ignore_errors=true}} Galobtter (pingó mió) 17:58, 19 March 2018 (UTC)
Thanks, @Galobtter.
I know it won't work before the 1000s, which suits this use. I should have noted that I am using it in Template:Infobox GAA club, and since GAA clubs date from the 19th cent, I only needed to validate 4-digit decades.
Your search pttern will be useful for anyone seeking to do this for decades which may precede the 2nd millennium. --BrownHairedGirl (talk) • (contribs) 22:39, 19 March 2018 (UTC)
You might want to check for [12]%d%d0s$ to catch transposition errors like "9180s". – Jonesey95 (talk) 01:50, 20 March 2018 (UTC)
9180s is a valid decade, in the 10th millenium. {{3x|p}}ery (talk) 01:57, 20 March 2018 (UTC)
@Jonesey95: I'm not worried about that. Any 9180s-type errors will make the template try to populate several non-existent categories, so the error will be visible. Keep it simple. --BrownHairedGirl (talk) • (contribs) 13:11, 20 March 2018 (UTC)

Events calendar


For Wikimédia France, 0x010C developed the tool Events calendar. The Events calendar is a common calendar, that can be used by anyone to share events having some connection with the Wikimedia movement. The central calendar, displayed on m:Events calendar contain all the events, while each project page can display his own, through a filter system.

The events calendar can be used on any other pages, with location or tag filters enabled. For example, it can be used to display all events of a given user-group, taking place in a city (Paris) or linked with a given subject (Wikisource).

It is possible to export a set of events in the iCalendar file format.

The event calendar can be viewed and used directly by anybody, connected or not, but its functionalities are limited to the features described in the template's documentation. To unlock the ability to navigate between months, to dynamically change the view or filter the events, and the easily manage events (add new ones, edit or delete existing), you will have to copy-paste those two lines in your common.js:

importScript( 'User:0x010C/Events-calendar-editor.js' );
importScript( 'User:0x010C/Events-calendar-navigation.js' );

Pyb (talk) 21:05, 19 March 2018 (UTC)

"each project page can display his own, through a filter system." how is this achieved? Via {{Events calendar}}? What are the steps to import this template to another wiki? --Gryllida (talk) 22:42, 19 March 2018 (UTC)
@Gryllida: the pages are meta-local at meta:User:0x010C/Events-calendar-editor.js and meta:User:0x010C/Events-calendar-navigation.js - you could review these and localize them if you want them on a local project. — xaosflux Talk 04:12, 20 March 2018 (UTC)
Where they could become a gadget if there was community support. — xaosflux Talk 04:12, 20 March 2018 (UTC)
Hi Xaosflux and thanks for your advice :-) I just put the importScript lines from the message above into my global.js and they allow me to view the calendar but I do not think they fully resolve the problem, I would like to define my own set of events on a local wiki and I do not know where to store them in a way that they do not show on your calendar. I can understand this is all open source but I am busy this month as I have a lot of homework so I think it should be possible to obtain documentation of this from the contributors who already are familiar with this tool. Gryllida (talk) 04:33, 20 March 2018 (UTC)
@0x010C: may be able to answer you. — xaosflux Talk 04:36, 20 March 2018 (UTC)
You can create a specific calendar on meta. It is not intended to be used outside of meta. But if you want, you'll need to copy-paste the script in Lua, templates, javascript fils, json files, etc. Pyb (talk) 07:48, 20 March 2018 (UTC)
Hi thanks. Would you most kindly please be interested in documenting the list of files that would need to be copied? I think it would be nice to have the calendar feature at other sister projects locally so that they can organize meetups and similar events without visiting meta wiki. These events are only in one language and do not necessarily need translation or exposure to other regions.
This would also allow the calendar tool to be used outside of Wikimedia wikis, i.e. at a wiki that is run for a non-profit organization on their own wiki. Gryllida (talk) 09:37, 20 March 2018 (UTC)
Hi @Gryllida:,
The initial goal of this calendar was to gather in one place (on meta) all events in relation with the Wikimedia movement (to be able to see Wikipedia, Wiktionary, Wikisource,... related events for example, without having to go on each project individually), while allowing people to create their own subsets using tags and/or location filters.
So you can add your events to the global calendar, and put on another page (on meta) a template like {{Events calendar|tags=1Lib1Ref|locations=Greece}} for exemple, to show only 1Lib1Ref events in Greece. As others also filters their calendar, it won't show up on the calendar of people looking for events in France. It won't appear either on the Wikisource UserGroup's calendar, as they filter to show only Wikisource-related events in all countries (meta:Wikisource Community User Group/Events). See meta:Template:Events calendar for other examples.
Currently the main drawback is that to add new locations or tags, you will have to edit manually a json file, I'll work on that point next week-end.
As you are not the first to ask to import this on an other Wikimedia wiki, I'll look in some weeks to allow import on other wiki, while keeping the data centralized.
Regards — 0x010C ~discuter~ 09:51, 20 March 2018 (UTC)
Thanks and I would also like to use it on a non-commercial wiki which is not a part of Wikimedia movement - so please consider making it possible to store data locally. Gryllida (talk) 17:42, 20 March 2018 (UTC)

Archiving community Good Article reassessments

Hi all. I used to work on community Good Article reassessments area years ago and have recently returned. Old community reassessments are archived by Veblenbot. When I was involved I would have to manually update the category listing to open up the next archive. However I am unable to do so now. CBM (talk · contribs) gave control of the GAR archiving function of Veblenbot to Ruhrfisch, who is no longer able to maintain it (see User talk:Ruhrfisch#WP:GAR needs category list updating.). I found two relevant discussions at the Bot noticeboard (Wikipedia:Bots/Noticeboard/Archive 8#New operator needed for VeblenBot and PeerReviewBot and Wikipedia:Bots/Noticeboard/Archive 10#User:VeblenBot) The last good article reassessment that was successfully archived was in April 2015 (Wikipedia:Good article reassessment/Archive 59).

This is obviously a long term problem that may affect other processes (peer review has been mentioned in a few threads). Is it possible to archive these reviews in a different way that doesn't require the manual updating of a bot? @GamerPro64, BlueMoonset, and Geometry guy: as editors familiar with the problem. AIRcorn (talk) 02:17, 20 March 2018 (UTC)

I originally took over Veblenbot thinking it would be for a short time, and I could hand it over to someone who knew how to run and maintain it far better than I. No one has ever come forward to take over the bot and I am not able to maintain it now. Sorry, Ruhrfisch ><>°° 13:13, 20 March 2018 (UTC)

The problem with hiding bot edits in watchlist

There's an option to hide bots edits from your watchlist in your preferences, and I believe it's on by default. It makes sense; approved bots pretty much always make uncontroversial changes mostly involving maintenance tasks, so you don't want your watchlist to clutter up with those.

But let's imagine a scenario where user A watchlists article P, and user B comes along, adds a maintenance template (like {{refimprove}}) to the article without the |date= parameter. And in subsequent edits (or even in the same edit), B also makes some pretty controversial changes. Now MaintenanceBot notices the missing date parameter and adds it.

Problem is, anyone who checks their watchlist after MaintenanceBot made the most recent edit will not see any changes to article P, and user B will (at least for a while) get away with their controversial changes.

One solution is to show the last human edit made since the page was viewed by the watcher, disregarding the most recent edit if it was made by a bot. This seems ideal, but it might be technically hard to implement without breaking something: the rollback button can no longer be displayed on only specific pages on your watchlist.

Another solution is to show bot edits where a human also made changes before the bot edit and after the watcher last saw the page. This is obviously less-than-ideal, but at least it draws attention. Smtchahal (talk) 04:13, 20 March 2018 (UTC)

Welcome to the 9th+ year of people wanting phab:T11790 to happen @Smtchahal:. — xaosflux Talk 04:15, 20 March 2018 (UTC)
Wasn't aware of that, guess I should've looked first, thanks! Smtchahal (talk) 04:22, 20 March 2018 (UTC)
This only applies if people are grouping recent changes by page, but not otherwise? --Gryllida (talk) 04:36, 20 March 2018 (UTC)
@Gryllida: This applies to your watchlist, I don't know about recent changes. Smtchahal (talk) 05:05, 20 March 2018 (UTC)
Gryllida: It applies if "Expand watchlist to show all changes, not just the most recent" is disabled at Special:Preferences#mw-prefsection-watchlist. Disabled is the default. It's mentioned at Help:Watchlist#Options with a reference to phab:T11790. PrimeHunter (talk) 11:49, 20 March 2018 (UTC)
The bot-edit-hiding option is not on by default. Graham87 09:54, 20 March 2018 (UTC)

Bot for infobox image cleanup

Hello, I have done many cleanups in which image was being used in infobox inappropriately like this. Can such tasks be performed across wiki by a bot? Capankajsmilyo (talk) 04:46, 20 March 2018 (UTC)

To answer your question yes it can be done, but based on my own experience of doing it I would say its better being done with WP:AWB because there's no accounting for the numerous wonderful ways editors managed to format the code for fields like that. - X201 (talk) 10:02, 20 March 2018 (UTC)
AWB is tedious and this is a recurring issue. Another important fact is that the image does not display at all in such pages. Capankajsmilyo (talk) 15:38, 20 March 2018 (UTC)
If you find it tedious, that sort of editing might not be for you. Some of us find it relaxing. As for the image, it was displaying just fine before your edit. – Jonesey95 (talk) 19:45, 20 March 2018 (UTC)

Failed login attempt info

Would it be possible to receive details about failed login attempts beyond "this happened"...?

It'd be useful to know what password they tried to use. For example, if you can tell they're just trying common passwords (e.g. password, 123456, etc), then you shouldn't have much to worry about. If they're using your older passwords, then you need to change your password immediately.

It'd also be useful for at least CUs (if not others) to know what IP address was used in the attempt.

Ian.thomson (talk) 14:00, 20 March 2018 (UTC)

That's a fairly atrocious idea. What happens if you typo your own password? You've just exposed yourself to anyone who can see what you tried. --SarekOfVulcan (talk) 14:02, 20 March 2018 (UTC)
I would assume that the info would only be shared with people who can see that there was a failed login attempt anyway. This should only be the user in question and the few folks who can see anyone's password anyway. Ian.thomson (talk) 14:54, 20 March 2018 (UTC)
Passwords aren't stored anywhere so nobody can see them. Only a hash of the password is stored. Many people use the same password at multiple sites and somebody with access to their email should absolutely not be able to see the password even if they can use the email access to request a new password and hack the Wikimedia account. And good faith users who mistype their username at login but enter their right password also shouldn't have the password revealed to a user with the mistyped name who may be able to guess who mistyped it. As xaosflux said, this is never going to happen for all sorts of reasons. PrimeHunter (talk) 15:18, 20 March 2018 (UTC)
@Ian.thomson: The "what password was used" is never going to happen for all sorts of reasons. The CU stuff has already happened, and there are additional changes being considered now. See phab:T174388 and its linked tasks for more information. — xaosflux Talk 14:29, 20 March 2018 (UTC)

Doubled-up overlapping coordinate links

In Upper Twin Falls Bridge, there are two overlapping and slightly offset coordinates links in the upper-right corner (Firefox 52.6.0 on CentOS 7, vector skin). {{coord}} is in {{Infobox NRHP}} which is embedded in {{Infobox bridge}}. Since the coords are repeated in both infoboxes, would that be part of the cause? Chris857 (talk) 16:06, 20 March 2018 (UTC)

I moved the coords from the NRHP infobox out to the Bridge infobox, and that fixed it in this case. I'm not sure what the general-case fix should be. --SarekOfVulcan (talk) 16:12, 20 March 2018 (UTC)
Checking the history, it looks like the edit that's currently causing the problem was here, where the individual NRHP coordinate parameters were combined into the coord template. I don't know if the double display started happening then, or if there was a later change to coord that caused it. --SarekOfVulcan (talk) 16:29, 20 March 2018 (UTC)
Template:Infobox bridge was changed in January to pull coordinates from Wikidata if they were not present in the infobox. Coordinates embedded in the NRHP sub-template were displayed along with the Wikidata coordinates. Moving the coordinates from the NRHP template to the bridge template made the infobox stop looking in Wikidata for the coordinates. It looks like there is not any sort of error tracking built into the template to detect this condition. – Jonesey95 (talk) 19:51, 20 March 2018 (UTC)

My own username

How do I obtain my own logged in username? The userspace linking templates require you to manually enter a username. Three tildes will get me my signature, but how can I automatically get just my logged in username? Thanks,  Buaidh  22:50, 20 March 2018 (UTC)

4 tildes. Natureium (talk) 22:55, 20 March 2018 (UTC)
Nope. That gets me my signature and the date, but not just my username. This ought to be simple, but I haven't found it yet.  Buaidh  23:07, 20 March 2018 (UTC)
{{subst:REVISIONUSER}} will produce it when you save. For what purpose? PrimeHunter (talk) 23:20, 20 March 2018 (UTC)
I would like to produce a version of Template:User that does not require the user to enter their own username (or a falsified username.) Ideally the template would produce the user's signature with a link to their talk page, a link to their contributions page, the time, and the date. e.g.,  Buaidh  (talk · contribs) 23:48, 20 March 2018 (UTC)
Such a template can only work if it's substituted so the documentation must specify to write {{subst:User}}. You need someting to keep the right code on the template page itself, e.g. {{sub<noinclude></noinclude>st:REVISIONUSER}}. PrimeHunter (talk) 23:56, 20 March 2018 (UTC)
Thanks,  Buaidh  (talk · contribs) 00:14, 21 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)
  • Support but maybe a decrease to 400 characters (to allow putting the full edit summary for reverting a very long IP Address. Anchorvale (talk · contribs) 06:09, 19 March 2018 (UTC)
@Anchorvale: It seems as if you meant to !vote Oppose but... here, rather than Support but..., given the actual content of your comments. The way this RfC has been structured, a support !vote indicates backing for returning the limit to 255 characters, not support for the new limit. Though of course, like a lot of us, you're clearly amenable to a middle ground solution. Snow let's rap 19:25, 20 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)

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)
      • Well yes, but the end result of that, as every service industry can tell you, is people just do not use it. Granted if we want to make sure 2FA is not used, the current shitty implementation of it is the right way to go. But the entire point of 2FA is to benefit users, not punish them. And making what is a common and widely used security precaution so offputting no one uses it is counter-productive. Only in death does duty end (talk) 21:57, 18 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)
I speak as I find. It's difficult to communicate with courses, as some of your own comments above show. Johnbod (talk) 17:56, 20 March 2018 (UTC)

After reading the Education noticeboard archives, I still don't have any specific proposal, other than adding a note somewhere in the WP:NPP docs to look at that page when moving unacceptable drafts from a class out of mainspace. I'll try to post there the next time I see an issue, hopefully soon enough that the community can engage with the instructor and students in the class. power~enwiki (π, ν) 17:30, 19 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)
  • Support. Accessibility is important and, as Mandruss says in the first comment here, I see no argument for doing anything differently in this case. —David Eppstein (talk) 01:33, 20 March 2018 (UTC)
  • Support per nom. But wouldn't it be simpler to modify the software so that no text smaller than the minimum can be displayed, not just in infoboxes but throughout the project? Justlettersandnumbers (talk) 10:42, 20 March 2018 (UTC)
  • Support and broaden as necessary - We have nav templates, notices, and other things that have this same problem. -- Netoholic @ 13:25, 20 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)

Proposal: Reduce scope of "open proxy" policy; soften colocationwebhost blocks; let people who have accounts use VPNs to edit

The "open proxy" policy is way too broad. Why are hardblocks (using templates like {{colocationwebhost}} and its cousins) almost always used for VPNs, instead of the softblocks given to other shared IPs? My proposal would change this:

  1. The open proxy policy would be changed, so that softblocks are applied to offending IPs.
  2. An adminbot would be created to change all openproxy, colocationwebhost, etc. hardblocks to softblocks (using the {{anonblock}} template).
  3. After the adminbot was finished, the openproxy, colocationwebhost, etc. templates would be gradually deprecated over the course of 3 to 6 months, and then redirected to the anonblock template.

KMF (talk) 20:20, 18 March 2018 (UTC)

General discussion

  • What does the encyclopedia win with this proposal? The Banner talk 21:50, 18 March 2018 (UTC)
  • This proposal fails to recognise the tremendous amount of abuse we get from vandals, sockpuppets, spambots, paid editor farms, LTAs, outright nutters, and others who abuse VPNs and anonymising proxies. If you want to know why they're usually hardblocked, that's the reason. We have the IPBE policy for users who want to edit through hard blocks. Meanwhile, neither the blocking policy nor the open proxy policy prescribe either hard or soft blocks, nor should they. -- zzuuzz (talk) 08:25, 19 March 2018 (UTC)
  • People are entitled to use proxies to protect their privacy, and Wikipedia is entitled to protect itself from abuse. Proxies generate a lot of abuse so, sorry, but no, you will have to use other websites. Johnuniq (talk) 08:44, 19 March 2018 (UTC)
  • Oppose meta:No open proxies is a global policy. Our local policy may be more restrictive than it, but it cannot be more liberal than it. Requiring soft blocks instead of leaving it to admin discretion appears to go against Publicly available proxies (including paid proxies) may be blocked for any period at any time. which leaves the type of block to be used as open. We could require hardblocks, as this would be more restrictive than the global policy, but we cannot exclude them from being used.TonyBallioni (talk) 17:26, 19 March 2018 (UTC)
    • I don't think that logic holds up. It says they "may be blocked", but does not require this to be at admin discretion. The admins are subject to the community, and I do not see any language preventing the community from restricting the admins in this way. --Trovatore (talk) 17:46, 19 March 2018 (UTC)
      • Yes, the global policy grants this entirely to admin discretion as what to block. The local communities can make stricter requirements (i.e. not allowing soft blocks), but cannot require more lenient actions against open proxies. TonyBallioni (talk) 18:11, 19 March 2018 (UTC)
        • Can you point me to that language? I don't see it. --Trovatore (talk) 18:21, 19 March 2018 (UTC)
          Here's my point more explicitly: The language Tony is calling out says that proxies "may be blocked", but does not give any special grant of decision-making authority to admins. The ultimate decision maker, when not overruled by the Foundation, is the community. Admin authority flows from the community, not from the Foundation, and the community is free to restrict it.
          I suppose the Foundation could, if it chose, give a direct grant of authority to admins to make that call. But I do not see that it has done so here. --Trovatore (talk) 20:08, 19 March 2018 (UTC)
          • It's more an issue of scope. The NOP policy on Meta is a global policy established by the global community at the time. There are few global policies, but those that do exist tend to allow for local policies to be more restrictive but not less (best example of this are the CU/OS policies). The NOP policy is somewhat unique in that it informs but does not require action. I don't imagine anything would be done if a local community overrode the global policy in this case, since there is no specified authority for enforcing it. But it would make more sense to try to change the global policy if there are factors that make it outdated or less useful than when it was originally implemented, rather than individual projects making exemptions or new rules. -- Ajraddatz (talk) 20:15, 19 March 2018 (UTC)
            • I still don't see, though, where it gives any grant of decision-making authority to individual admins. That's actually my main concern here. A lot of admins have an exaggerated understanding of the decisional (as opposed to technical) aspect of their role, and I think that needs to be challenged when it comes up. --Trovatore (talk) 21:11, 19 March 2018 (UTC)
              • The global policy above explicitly states that open proxies may be blocked for any period of time without specifying what type of block. This is both an explicit and implicit grant of discretion to admins (and our local policy does the same). Explicit in that we can block them for as long as we want, on our own discretion, and implicit in that when admin action is authorized but the exact nature of it is left unclear, it is up to the individual admins on how to use it in line with other policies. Most admins hard block open proxies to the point where it has become a de facto policy, but they are also free to soft block if there is good reason. TonyBallioni (talk) 21:15, 19 March 2018 (UTC)
                • Admin actions are subject to appeal to the community, so no, you cannot do it for as long as you want subject (only) to your own discretion. --Trovatore (talk) 21:20, 19 March 2018 (UTC) And again, you're conflating technical ability with decisional authority. --Trovatore (talk) 21:22, 19 March 2018 (UTC)
                  • And the global community and the local community have empowered us to do so through the local and global policies. TonyBallioni (talk) 21:27, 19 March 2018 (UTC)
                    • We can override that by a decision of the local community. --Trovatore (talk) 21:30, 19 March 2018 (UTC)
            • (edit conflict) Yes, I think what you say makes sense. We have a local policy on this too (Wikipedia:Open proxies), but it is specifically based on the meta policy. It doesn't make sense IMO, for us to make a more lenient local policy on this than the existing global policy on meta. If there are to be changes, it would be best to happen on meta first, followed by a local RfC to change it (which I suspect would not be succesful if it were widely advertised. We specifically hard block IPs here that have already been global blocked because the enforcement of the open proxy policy/our granting of IPBE is stricter than the global enforcement.) TonyBallioni (talk) 21:12, 19 March 2018 (UTC)
              • Well, that's a different argument. Before, you were claiming that the community was not empowered to choose a more lenient standard. I don't think that's true. --Trovatore (talk) 21:19, 19 March 2018 (UTC)
                • As Ajraddatz noted, we typically don't allow more lenient standards for global policies (the standard being the global CU/OS policy): the local community cannot adopt a more lenient standard than the global community (global policies are written by the community as well, not the WMF, though I am unclear on the exact origins of this one.) From a practical standpoint, there's a question of what would be done if our policy was more lenient, which I agree with ajr is likely nothing, but that doesn't mean that we should do something that arguably going to make us more lenient than the global policy on this. Additionally, like I said, there's a snowball's chance in hell of this actually passing if it were well advertised. has one of the strongest enforcements of this, and I don't see that changing. Also, pinging @Slakr and SQL: two other local admins who are heavily involved with dealing with local open proxy blocks. TonyBallioni (talk) 21:26, 19 March 2018 (UTC)
                  • I think you are wrong that the local community "cannot" allow a more lenient standard. Your first sentence says that "we typically" do not, which may well be true. But that is a different claim. You have not yet given any convincing argument why we "cannot". --Trovatore (talk) 21:30, 19 March 2018 (UTC)
                    • You are simply wrong on this point, and I see no reason to further engage in discussion. Local policy cannot override global policy. TonyBallioni (talk) 21:31, 19 March 2018 (UTC)
                      • You have not supported your claims. --Trovatore (talk) 21:32, 19 March 2018 (UTC)
                      • More specifically, even if we grant that the local community cannot override the "global community", the language you pointed to still does not empower local admins to impose blocks contrary to the wishes of the local community. --Trovatore (talk) 21:36, 19 March 2018 (UTC)
  • Oppose Echoing the above by The Banner, what do we "gain"? zzuuzz and Johnuniq touch on important points about the sheer unending abuse these open proxies enable. I see very little benefit versus a lot of possible negatives if this were to be enacted - TNT 21:44, 19 March 2018 (UTC)
  • Oppose based on my current understanding of the situation. IBPE has been liberalized via an RFC so that it should be available to "trusted users" who want to edit via VPN. That seems like an adequate accommodation for the good use cases. Opinion subject to revision if there's something I don't understand. --Trovatore (talk) 21:58, 19 March 2018 (UTC)
  • As above, I see a lot of cost, and not a lot of benefit for the project. IPBE is available to editors that meet it's requirements. SQLQuery me! 22:02, 19 March 2018 (UTC)
    • I should disclose that I recently edited the IBPE policy to bring a couple of small pieces of language into line with the outcome of the RFC. It was last edited for that purpose last fall, but I think there were a couple of points missed, and I addressed them. I said what I was doing on the talk page, so I feel I was transparent about it, but for further transparency I'll mention it here too. --Trovatore (talk) 22:05, 19 March 2018 (UTC)
  • Oppose - we have already liberalized the IPBE policy to allow good-faith editors to edit from proxies if they so wish. The amount of potential abuse coming from open proxies still outweighs the benefit of allowing unrestricted editing from them, though this might change in the future with better targetted blocking options. -- Ajraddatz (talk) 22:29, 19 March 2018 (UTC)
    • Unfortunately it seems that it is not clear that the policy now allows this. That was the outcome of the RFC, but it seems that there is resistance to implementing it. --Trovatore (talk) 23:49, 19 March 2018 (UTC)
  • Strike earlier oppose. I was basing my opinion on the outcome of the RFC about IBPE. It appears that this is under dispute. I still don't really think this proposal is a good idea; liberalizing IBPE is much better. But it needs to actually get done. --Trovatore (talk) 23:49, 19 March 2018 (UTC)

RfC on permanent implementation of ACTRIAL

There is currently a request for comment at Wikipedia:Autoconfirmed article creation trial/Request for comment on permanent implementation about whether or not autoconfirmed status should be required to create an article in the main space. This is a follow up to the recently ended autoconfirmed article creation trial (ACTRIAL). All are invited to participate. TonyBallioni (talk) 13:40, 19 March 2018 (UTC)

TonyBallioni, just to confirm, the trial did end when the original proposal said it would, right? I ask because we have had problems in the past where everybody agreed upon a limited-time trial and the WMF arbitrarily decided to make the limited-time-trial permanent without asking. --Guy Macon (talk) 20:00, 19 March 2018 (UTC)
Guy Macon, yes. The trial ended on 14 March 2018. TonyBallioni (talk) 20:03, 19 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 (talk • contribs) 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 (talk • contribs) 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 (talk • contribs) 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)

Main page header: redesign

I was thinking about how the main page can be improved without bringing in extensions, javascript, too much css etc. Though I was not able to create a plan on redesigning the main page I was able to create a rough draft of a better looking header here. I would appreciate constructive feedback and would like to know if it could actually replace the main page header( after quite a lot of polishing actually) — FR+ 08:01, 20 March 2018 (UTC)

I'm sorry, but despite the obvious hard work that has gone into your design I still prefer the original. I don't see how increasing the amount of space taken up by the basic header will improve the design, it will just push the information sections further down the page. You've also lost the links to the portals and I would question why we need to see Jimmy's quote every time that the front page is viewed. IMHO there needs to be a minimum of fixed text, just enough to identify (and through clenched teeth I'll accept "brand") the site. More space is then available for useful and/or interesting facts which keep the reader's interest. I suspect that this is not what you had in mind when you asked for "constructive feedback", but I really think you need to reconsider your approach, sorry. Martin of Sheffield (talk) 15:09, 20 March 2018 (UTC)
Something to think about - is a full mainpage (similar to the current one) better or worse (by whatever criteria) for readers than an uniform one (such as the proposal)? I am sure there should be research out there. Jo-Jo Eumerus (talk, contributions) 15:20, 20 March 2018 (UTC)
Ow ow ow, is that #FFFFFF on #EAF3FF, contrast ratio of 1.12:1, too hard to read. — xaosflux Talk 15:25, 20 March 2018 (UTC)
Martin of Sheffield-Jo-Jo Eumerus-Xaosflux: I have again reworked the design, could you take a look — FR+ 06:01, 21 March 2018 (UTC)
Martin of Sheffield-Jo-Jo Eumerus-Xaosflux:Repinging — FR+ 06:01, 21 March 2018 (UTC)
My question is unchanged. Jo-Jo Eumerus (talk, contributions) 08:36, 21 March 2018 (UTC)

Hi FR. I would like to link Wikipedia:Main page redesign proposals, in case you haven't seen it. FYI only. Kind regards, Rehman 06:22, 21 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'd agree with this suggestion. If the whole book sources some statement, then just cite the book without any page numbers at all. If not, cites ranges, chapters etc. I'd tend to avoid passim as non-academic readers, including non-native English speakers, are unlikely to understand it, and there are usually better ways to handle this situation that avoid the whole problem. —Tom Morris (talk) 12:03, 20 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)

There is no Freedom of Panorama in the UAE.©Geni (talk) 07:44, 20 March 2018 (UTC)
@Geni: Yes I am aware of that but we're only going to ask people to upload photos of ancient, archaeology and historical sites. Will make it clear that people should not upload photos of modern architecture and of artworks because of restrictions. --Saqib (talk) 13:43, 20 March 2018 (UTC)

From redlink to deletion logs

So, it used to be that you clicked a redlink of a deleted page and a message appeared saying that a page with that name had been deleted and pointing to the deletion log. Now, it just suggests creating the page, and I can't find any way to get to the deletion log. This has happened to me several times for pages that I knew had been deleted, but I couldn't find the deletion log. To make things worse, is every page has a link on the left said that says "page information". But, bafflingly, page information apparently doesn't include any logs, whether deletion, move, patrol, protection, or any kind of log really. Why doesn't page information provide a link to logs? Oiyarbepsy (talk) 23:40, 19 March 2018 (UTC)

What article are you looking for? ~ GB fan 23:53, 19 March 2018 (UTC)
  • This doesn't really answer my question which is about how, in general, to get to these pages - not to mention that we no longer alert people that stuff has already been deleted. I know that I can go to Special:Log/delete (but not, apparently Special:Deletion log) to find it the ridiculously long and difficult way - but I don't understand why it isn't easy, and why it isn't shoved in people's face before they recreate something they shouldn't recreate. Oiyarbepsy (talk) 23:55, 19 March 2018 (UTC)
    I believe he's looking for a specific instance of this happening. To answer your original problem, I believe some links are formatted so that you end up directly at the editing side and don't see the log. I couldn't reproduce it right now, however. To easily see logs, click the history link and "View logs for this page". Killiondude (talk) 00:04, 20 March 2018 (UTC)
It wasn't meant to answer your question, it was meant to try to understand the problem by looking at one of the articles you believe are a problem. To me EPB6 gives me the deletion log when I click it. ~ GB fan 00:05, 20 March 2018 (UTC)
  • Killiondude, unfortunately, deleted pages don't have a history button. GB fan, I've never once been presented the deletion log when clicking a red link (at least since they changed the editor), so maybe there is something in user settings that give different results? Oiyarbepsy (talk) 01:30, 20 March 2018 (UTC)
Oiyarbepsy when you click EPB6, you don't see that it has been deleted? ~ GB fan 01:54, 20 March 2018 (UTC)
Ah, you don't use the default source editor. You have enabled "Automatically enable all new beta features" or "New wikitext mode" at Special:Preferences#mw-prefsection-betafeatures. That does make it difficult to find a deletion log. The easiest method I found was removing &action=edit&redlink=1 from the end of the url, e.g. changing EPB6 to []. phab:T176070 is about it. PrimeHunter (talk) 01:59, 20 March 2018 (UTC)

Meh, at least someone is working on fixing it. Oiyarbepsy (talk) 02:43, 20 March 2018 (UTC)

Global picture-changer Aavindraa

Is Aavindraa authorized to do it? Russian translator (talk) 11:58, 20 March 2018 (UTC)

Information about the Wikimedia Foundation global survey starting soon

14:05, 20 March 2018 (UTC)