Jump to content

Wikipedia:Village pump (idea lab)/Archive 21

Add links
From Wikipedia, the free encyclopedia
Village pump (idea lab) archive  

This page contains discussions that have been archived from Village pump (idea lab). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62

Replacement for the DYK process

Based on the ongoing concerns and problems faced with the DYK project, I have drafted a proposal to replace DYK at User:SSTflyer/DYK replacement. My proposal is designed to use as much of DYK as possible. What are your thoughts on it? Would such a proposal be feasible? How could it be improved? SSTflyer 07:06, 8 July 2016 (UTC)

@SSTflyer: An interesting idea. You listed "Solves accuracy and interest concerns about hooks" as one of the advantages of this proposal. Honestly though, I'm not sure how much this is going to solve. There will still inevitably be disputes about whether or not information is correct, because this is just like DYK, but instead of hooks needing to be cited, blurbs need to be cited. The other problem I see with this is that by implementing this you lose the interesting facts which are normally provided by the DYK section, and instead the information presented will most likely be a little boring, and not really eye-catching or to the point. Omni Flames (talk) 08:11, 8 July 2016 (UTC)
Thanks for your input. Blurbs don't need to be cited, just as how lead sections don't need to be cited. It just needs to be accurate. I have updated my proposal to reflect this. SSTflyer 08:39, 8 July 2016 (UTC)
Perhaps instead of replacing the "Did you know..." section, the recently created/expanded requirement from DYK could be dropped. This would free it up to cover a broader range of articles with interesting hooks, and your proposed "Recent additions" sections would cover new/expanded articles. isaacl (talk) 12:54, 8 July 2016 (UTC)
A blurb format might be a little dull, as Omni Flames said, since it would basically be a short summary instead of a short, weird fact. Then again, a lot of DYK hooks seem boring to me because I don't pay attention to pop culture.
I would second dropping the new/expanded/GA requirement as a way to improve DYK. I created a lot of articles before I ever attempted DYK, and then wished I could do DYK on those articles when it was too late. I also often come across neat facts while editing other articles. White Arabian Filly Neigh 22:02, 11 July 2016 (UTC)
I don't think the recency-requirement thing is a bad thing, but I think the window of opportunity is far too brief. I've often thought of DYKing some of my work only to discover that I was already outside of that overly tight window. It's hard enough doing the hard work of creating/expanding/GAing, and to have to immediately turn around and file a DYK is exhausting. Additionally, there is a group of editors who file so many DYKs they almost have a lockdown on it. Expanding the window of opportunity would encourage a lot of editors who haven't tried it before. Softlavender (talk) 18:42, 14 July 2016 (UTC)

Include common abbreviations for cities/states/regions/countries etc.

Most cities/states/regions/countries have a 2- or 3-letter abbreviation. For example, the city of Phoenix, Arizona is abbreviated "PHX". It's useful information that non-residents might not know. It should be listed in the article for Phoenix. Similarly, common 2- or 3-letter abbreviations should be listed where applicable. — Preceding unsigned comment added by 174.79.47.243 (talk) 19:21, 12 July 2016 (UTC)

I don't think I fully understand this. Abbreviations for countries and US states are shown in the infoboxes of their articles (though, as an aside, I think it'd be good to show ISO 3166-1 alpha-3 country codes as well as two-letter codes). But city abbreviations? NYC, certainly; but is PHX really used as an abbreviation for the city of Phoenix, Arizona? It's the IATA code for Phoenix Sky Harbor International Airport. Many IATA codes for US airports indicate the names of the cities they serve, but not all, and they're still airport codes, not city codes. — Stanning (talk) 07:23, 13 July 2016 (UTC)
It probably is used, at least by people who travel a lot or like airplanes. There are some older abbreviation systems that were in general use (e.g., initials for any city that had more than one word, an X to replace "Cross" in any city whose name begins with Cross). There are also official abbreviations for some places. CalTrans has assigned an abbreviation to every county and some other places in California, for example. WhatamIdoing (talk) 01:44, 14 July 2016 (UTC)
They appear to have spread beyond the flying context for some cities, especially in URLs, hashtags, and the like, where an abbreviation is wanted (and presumably for places with only one international airport). I’ve certainly seen usage of YEG (not always in caps) around here in recent years by organizations & campaigns with no obvious connection to travel or tourism. I‘d expect the codes to appear somewhere in the Transportation section of major-city articles, but I‘m not sure they generally deserve any more prominence unless they‘re actually (citably) used as nicknames. WT:WikiProject Cities, or maybe Template talk:Infobox settlement, might be a better place to bring this up.—Odysseus1479 05:29, 14 July 2016 (UTC)
PDX for Portland, Oregon also. --Izno (talk) 11:40, 14 July 2016 (UTC)
Sounds very locally specific. I can't see why this would be useful for cities- what does the code LGW or LHR add to London? The TLA for railway stations is used in texting, as in 'At CST, all cancelled will walk top STP' but the codes are already in the station infobox. Still irrelevant to a settlement article. --ClemRutter (talk) 18:44, 14 July 2016 (UTC)

There are common city abbreviations used for sports teams. Perhaps a "List of abbreviations of sports teams in North America"? --NaBUru38 (talk) 15:11, 17 July 2016 (UTC)

This may not be for everyone, but it seems like it would be productive to have links like Selwyn Wright (presently a red link which I just saw mentioned at the Science Refdesk as an article that 'might be started') show up as yellow rather than red if Draft:Selwyn Wright exists. That way, if for example you are looking at a genus page with fifty different species listed, you would immediately see the one yellow link among that sea of red and say great, let's see if we can get that article whipped into shape! This might not be for everyone, needing a user setting and hence only being available to editors rather than casual readers, depending on how freaked out people get by the alleged horrors that someone will write libelous things about Mr. Wright in Draft space - I'd prefer to have it for everyone and just ignore this risk as nothing much to get bothered over, but I remember there were people dead-set against Draft space, and the compromise would not really be a terrible bar when accounts are had for free. I imagine this could be done in user javascript using some API feature to check for existence of Draft:anything in the page, but that would be a terrible waste of resources if many people used it, compared to having a varnished version sitting on the server you don't need a script for. How would people feel about it? Wnt (talk) 16:42, 14 July 2016 (UTC)

I've never seen yellow type show up well anywhere. What about green? Or instead of font color, some other indication? Softlavender (talk) 16:51, 14 July 2016 (UTC)
This should work as a user script that adds a CSS class, similar to Anomie's linkclassifier. SiBr4 (talk) 17:59, 14 July 2016 (UTC)
Hmmm, it does look like it would fit in there; I wasn't familiar with that script. But I don't understand how that script can access all that information without putting a huge performance hit on both the user and the server. Wnt (talk) 02:42, 15 July 2016 (UTC)
Nearly all the rules look at nothing but the names of the categories the page is in; the exceptions are needs-review, nonimage, redirect and its children, and the protection-related. עוד מישהו Od Mishehu 04:00, 15 July 2016 (UTC)
I added code to have it check mainspace links for a corresponding Draft-namespace page, and set the has-draft class on them. I didn't add any default CSS rule for this, though, largely because I couldn't think of what styling to use. Anyone using the script can, of course, add a rule for .has-draft (or .new.has-draft if they only want to target redlinks) to their personal CSS. Anomie⚔ 19:22, 18 July 2016 (UTC)
The color of the link could be orange or something else - I didn't think yellow looked all that bad, but orange would work. I assume it would be as easy to check if Draft:X is in a category as X? Wnt (talk) 11:51, 18 July 2016 (UTC)

Wikipedia needs a "social icon" - and a safe place to land them

I was reading a (Note, link not safe for some workplaces. Prominently features photo of topless woman. <- Note that is not my text, see below, but as long as we're at it, let's continue... -> Unlike an image of Muhammad, which a person would have to belong to some stupid wrong religion to object to, or the word "fuck" that you'd have to be silly to object to anywhere on wiki because it doesn't bother the Guy In Charge, a link to an activist organization with important things to say is just too pretty to be given without a big bold stupid warning. So says User:TenOfAllTrades, who takes personal responsibility for proclaiming a policy (that isn't a policy) that prohibits people from having anything in their comments that would astonish HIM, and only him, and exerts final editorial control over all our work here on Wikipedia as the official Self Appointed Censor of the Wiki. Note also that he has claimed that posting to a picture of male breasts is also "astonishing", so if you see any news links to shirtless guys, please forward them to him so that he can go after their posters threatening AN/I. Man typing stuff in bold in the middle of a post is stupid, isn't it? I should do it some more. ) typical news article that has a bunch of icons for its presence on Facebook, Instagram, Pinterest, Twitter, and YouTube ... not Wikipedia. And obviously there's a reason why, which is not just the lack of an icon. For a group to want to have an icon, they would have to land at a site for them, i.e. a site where they can build up a list of useful resources and direct their followers as they see fit. Now I understand that Wikipedia has had a standoffish policy toward "social media" functions, not unreasonably since there are a lot of worms in that particular can. Nonetheless, I think it would make sense for us to allow this one particular kind of social media function in order to draw readers into the site and provide people with a place where they can address wikipedia-specific issues - indeed, the standard format provided for such spaces could ask groups setting them up to answer questions that every Wikipedia editor wants to know, like whether all those lovely pictures are CC-BY or something. And so I think that not only could we draw in readers, but we could draw in content with it.

Now yes, most companies would want to abuse this space terribly. But they already want to abuse our articles. If we could see free to allow them latitude to use their social media space pretty much as they wish, at least this would give them a choice - do we want more data stuffed in an article that might get deleted or be subject to stupid rules against directory information, or can we put it on our Wikipedia social media page? So it might not draw as much COI to the encyclopedia as we think.

Now yes, we'd want this "wikipedia social media" to be far from the articles. Not so far that a Wikipedia login wouldn't work, but probably a separate domain name would be sensible. It's conceivable that some neglected but loosely defined project like Wikiversity might actually be open to it, though I think it would make more sense to start from scratch.

The landing sites I'm picturing should not be in any sense user pages, but much more closely resemble Wikiprojects. We have a rule against company accounts; our users are individuals. This has always been in part so that we don't have to settle which of two co-owners holds the right to the company account after they have a falling out. That said, nobody is going to build their pages with a Wikipedia icon that is equally under the control of haters of their organization. This is where the philosophy comes in - we want to create a neutral and respectful structure that gives no privilege to any one point of view, yet allows each point of view to claim its own space. This is the same core problem as say arranging for protests at a political convention, so it is a hard problem, but we can address it much better than those who don't try to do so honestly. My thinking is that we allow any user to start a social media landing site with a given core name, but we append a bit of random fluff to the end so there can be many different ones, each no more expected than the other. Going to the core name without the fluff gets a directory of all the possible extensions, ranked by incoming page requests (but discounting abusive traffic). They then link each other as they see fit.

Typical valid content for a social media landing site would be personal bios, company products, addresses, phone numbers, basically anything in WP:NOT, plus anything the less friendly editors would boot from the article, plus discussions of how to build Wikipedia pages and collaborate to get better content. Sometimes this would be unpleasant to see, but it will happen whether we see it or not, so if we lure some of it out into the open that is not a bad thing at all. We would want the site as free as achievable under current legal conditions, and as independent as achievable in case something goes wrong. Its administration would be independent of Wikipedia and (as much as possible) WMF, perhaps outsourced to whoever makes the stupid decisions social media providers make to cover their asses. Obviously I would prefer to just leave it free entirely, but I recognize that there are severe risks in a less than free society. To summarize: it should be "user content". One obvious practicality is that the total size is limited, though the number of subpages it is distributed among should not be. (Why shouldn't a Wikipedia icon link to a social media entry for a particular event?)

The cost could be substantial but could be compensated in multiple ways. One would be ads, since it's not Wikipedia. Another would be subscriptions, for people with no interest in the encyclopedia. Perhaps the coolest way would be to allow it as a privilege for long term users in good standing; as such it would be a sort of in-kind payment for editing. I would not even want to prohibit users entitled to have such pages from offering to set them up for companies in exchange for money - the usual paid editing restrictions shouldn't apply to this social-media otherworld. I think though that trying to make it revenue neutral would be a mistake, because the goal is to get a stream of users to pass through the sites into Wikipedia. So I'm thinking something very mild, like hitting users with ads (with strict privacy limitations!) only if they use the social media site without using WMF projects proper - no more than a chiding for them to edit, really. And of course visitors to those sites should get a harsher dose of WMF fundraising appeals than the usual reader. Wnt (talk) 14:12, 29 June 2016 (UTC)

WP:TPO bullet 4. OT about NSFW warnings. ―Mandruss ☎ 07:00, 19 July 2016 (UTC)
Dude, not cool to link to an article with a large photo of a topless woman above the fold as a "typical news article", especially when there's no hint about the content in the link URL. TenOfAllTrades(talk) 15:15, 29 June 2016 (UTC)
@TenOfAllTrades: Don't put silly disclaimers in my comments. If we as a site expect Muslims all over the world, living under the most abhorrent regimes, to access articles about Islam that contain paintings of Muhammad without so much as a disclaimer first, then you have no call to be putting some special disclaimer on my link because it happens to include a lovely woman who isn't wearing a niqab or a bra. And do note that FEMEN is no porn site, but a serious nonprofit organization striving for the ascendancy of Western culture, and their news releases are even more interesting to read than to look at. Last but not least, if you really care that much, you should read your links first oh, wait, you said you did, you just don't recognize FEMEN... well, that's a misfortune. Wnt (talk) 20:53, 29 June 2016 (UTC)
Don't post links to content that's not workplace appropriate under deceptive link text, if you don't want warnings placed next to your links. You're being silly if you're trying to compare me accurately describing the contents of your link (note: not deleting it, not censoring it—just describing it) to a murdering theocratic dictatorship. I have nothing against female (or male) breasts, but I also respect my work colleagues enough not to wish to make them uncomfortable by displaying large images of them (the breasts, not my colleagues) unasked-for—I would hope you would be willing to extend the same courtesy to your colleagues on Wikipedia.
And you're barking up the wrong tree if you're trying to paint me as a moralistic crusader. My position with respect to all content on Wikipedia – images, links, text – has been a consistent adherence to the Principle of Least Astonishment: briefly, readers can be offended by stuff they encounter on Wikipedia, but they shouldn't ever be surprised to be offended. (In a remarkable coincidence, tomorrow is the tenth anniversary of one of my posts at the Village Pump saying exactly that: [1]). That is to say, we should never compromise the quality of our work for fear of giving offense, but neither should we give offense when doing so is not necessary to maintain the quality of our work. Images, links, and text that may be appropriate, educational, informative and expected in List of sex positions or Fuck will be different from the content appropriate for Potato or Minnesota—or the Village Pump. I'm rather surprised that an editor with so much experience would feign ignorance or indifference to this concept.
You can leave the content description there, or you can change the link to something that isn't needlessly offensive or provocative. (Please resist the urge to try to play with the line.) Or, we can take this to AN/I. It's up to you. TenOfAllTrades(talk) 00:26, 30 June 2016 (UTC)
@TenOfAllTrades: Here's what you don't get - an idea that apparently is utterly alien to you. There are workplaces in Muslim countries. And in countries with brutal dictators or stupid laws against information about how to induce an abortion and so on. When you say something is "workplace safe", you mean safe for your particular workplace with your particular prat in charge who for some reason lets you read Wikipedia yet would turn on you because you clicked a link that had a photo of some activists. And you can't seem to conceive that your "astonishment" is not an absolute moral law of the universe! We have the right idea on the Muhammad pictures, but we should not kid ourselves - we're imposing a risk that some of the readers are going to be in really deep shit over them. We do that because it's not our job to be collaborators in censorship. And it's not my job to be a collaborator in censorship. Wnt (talk) 11:57, 18 July 2016 (UTC)
Seriously though, describing an article by an activist group as a "typical news article" borders on WP:POINTY behavior. You could have posted an article from an actual news outlet which would not distract editors. SSTflyer 08:44, 8 July 2016 (UTC)
Seriously though, I wasn't even thinking about the boobs specifically when I posted this. I was just looking to see what FEMEN was up to, and I saw seven different social media buttons all next to each other rather than the usual obligatory two, which made me think we should have one especially as their format left an empty space that looked like it wanted to be filled with something. And seriously, I will NOT be assisting you people in denigrating certain content, especially as I think it is utter and absolute bullshit that @TenOfAllTrades: really would treat male breasts the same way. I will not be a party to regulations that are sexist on their face, and I do not accept that ten years of arguing this bogusness as policy actually makes it policy; "least astonishment" is, to the contrary, a meaningless phrase that can only be filled in with personal prejudice. Wnt (talk) 11:46, 18 July 2016 (UTC)
I'm reading this as "we should set up a social media button to draw in readers and content", and "the button should lead to a separate site that tolerates spammy and/or POV behaviour". Not only do I not like the second part of that, but I think it's fundamentally incompatible with the first. If we set up a "social media site" where organizations can control their content, many of them will simply park their usual ads there and ignore us. Worse, we'd have to manage such a site, diverting volunteers, WMF staff, and effort from our real goals, with no guarantee that this would do anything to lessen the effect of spam on our existing articles (In fact, I'd wager the opposite…). That's a side-show I'd rather not attend.
Social media buttons are advertisements for the "social" site they represent. They say, implicitly: "this social site is more important than the site you're currently on". Including them gives the host site a chance at a smidgen of extra traffic in exchange for giving the social site ongoing free advertising and, if hosted centrally, the opportunity to track users around the rest of the web (!). They're a remarkable con. Wikipedia is not a "social platform" in the same sense. Our purpose doesn't include "sharing" random external sites, and in fact for many sites "sharing" them on Wikipedia would be disruptive to us. I do think that a "cite this article" social button could be interesting for news, academic (journals etc.), and GLAM sites—that would promote more or less behaviour we like, while filling the usual "social media" tradeoff. The catch for us being that the "cite this on Wikipedia" button would probably quickly appear on press releases and random blogs. {{Nihiltres |talk |edits}} 15:33, 29 June 2016 (UTC)
This is a reasonable criticism, but I still think that's more the site's issue than our own. The direct "share this link on Wikipedia" seems too specialized to me. Wnt (talk) 11:59, 18 July 2016 (UTC)

Social media buttons exist to drive content to the social media site and to the site which is linked to by a kind of mutual linking. This is great for small blogs which might otherwise have trouble getting noticed, but Wikipedia is almost always in the first page of search engine hits, so we don't need it, and we have no reason to want to drive content to social media sites. We anyway get featured on Facebook as the default page on any topic which doesn't yet have a Facebook presence, and people link to Wikipedia articles on social media all the time without social media buttons. I therefore strongly oppose this proposal. --Slashme (talk) 06:34, 19 July 2016 (UTC)

So, I'm reading a news story "Man bites Dog" on the Daily News website, and I see that it has a wikipedia icon on it. Where does clicking on that icon take me? The wiki page for "Man"?, the wiki page for "Dog"?, the wiki page for "Daily News"?, some completely new "Wikipedia social network" page? If it goes to some existing page, who decides which one? If you're proposing building a completely new social media site, why? There's not exactly a shortage of them. Chuntuk (talk) 14:05, 19 July 2016 (UTC)
@Chuntuk: Since it's on the Daily News' page, it's their choice. My strong presumption is that they would lead people to a Daily News Wikipedia fanpage, where some of their people would presumably try to encourage readers to cite their articles on various relevant pages, while readers would talk about what CC-licensed photos are available, debate the publication's quality, etc. Now all of this would have an alarming propensity to be misused by commercial interests -- but Wikipedia has done nothing to crack down on WP:WikiProject Square Enix and its featuring of an article on the Main Page every six months like clockwork, so we already have the worst end result of that so far as I see, minus the social media button. The social media button is to bring in readers, and companies corralling their fans into the works might actually dilute the commercialism of the process. In any case, they would be at least bringing in individuals who ought to become more independent-minded editors over time. Wnt (talk) 17:18, 19 July 2016 (UTC)

Maintenance collaboration

In 2005, Maurreen started the Wikipedia:Maintenance collaboration of the week which later became inactive. I've been trying to revive it. Recently, I came upon the Backlog of the Week, which is apparently updated automatically by AnomieBOT. This would make the MCW somewhat redundant. Would it be feasible for the MCW to use the Backlog of the Week for their collaboration? Is anything like this already in existence, and would anyone be interested? Chickadee46 (talk|contribs) (WP:MCW) 17:33, 21 July 2016 (UTC) I can't find much on Wikipedia about the Backlog of the week, and it seems to be a pretty standard {{AnomieBOT/RandomPage}}. I'll go ahead and use AnomieBOT's random page function for the MCW if it can be restarted. (This might have not been quite the place for this anyway) Chickadee46 (talk|contribs) (WP:MCW) 01:16, 23 July 2016 (UTC)

Self edit conflicts

Moved to WP:VPT

23:07, 11 July 2016 (UTC)

Deprecate use of abbreviations such as "e.g.", "i.e."

The British government recently changed its online style guides to deprecate use of the abbreviations "e.g.", "i.e.", and "etc". Some screen readers may not read these terms correctly (i.e. pronouncing them as words rather than abbreviations), meaning that it is hard for the visually-impaired to correctly understand what exactly is being read. It recommends that phrases such as "for example", "such as", and "including", among others, be used instead to improve the clarity of writing. Do you think we should perform a similar change?

They have a point in what they're doing, and it also makes sense for Wikipedia in my personal opinion, because we have a full manual of style section devoted to accessibility, which means that we have committed to ensuring that our content is accessible to all users.

Or does this feel like something that would make more sense on Simple English Wikipedia? ViperSnake151  Talk  16:05, 27 July 2016 (UTC)

The British government says nothing of the kind. They've deprecated the use of "ie" and "eg" without punctuation, as it confuses screen readers. Since Wikipedia has had the punctuated forms as the prescribed format since 2006—and any use of the unpunctuated forms is usually removed fairly quickly since it's one of WP:AWB's general fixes—what is actually happening is that the British government has chosen to come into line with Wikipedia. ‑ Iridescent 16:22, 27 July 2016 (UTC)
Besides which, HTML has provided the <abbr>...</abbr> element since HTML 4.0, that is, <abbr title="that is">i.e.</abbr> → i.e. - hover your mouse over that, see what shows in the tooltip. To make it easier to construct that, we have the {{abbr}} template, that is, {{abbr|i.e.|that is}} → i.e. which is semantically identical to the HTML just demonstrated. --Redrose64 (talk) 20:18, 27 July 2016 (UTC)
"e.g." and "i.e." are extremely confusing, as they are Latin phrases no longer used, so I agree to remove them. However, "etcetera" is an common word in English and many other languages. --NaBUru38 (talk) 19:39, 1 August 2016 (UTC)
Here is a chart of "e.g.,i.e." on Google Ngram Viewer.—Wavelength (talk) 20:09, 1 August 2016 (UTC)
@NaBUru38:It's not "etcetera", but "et cetera". People do say it in full, but rarely write it as such. It's virtually always written "etc." although sometimes mispunctuated as "e.t.c." as though it were three words - it's two, and the first one isn't abbreviated or contracted, although in the archaic form "&c." it is. --Redrose64 (talk) 08:37, 2 August 2016 (UTC)
All these are commonly used, especially in scholarly writing. They are only as confusing as a google search, or for that matter, a Wikipedia search. TimothyJosephWood 10:47, 2 August 2016 (UTC)
An amazing number of people -- who are otherwise fluent in English -- are unable to distinguish between "there", "their", & "they're" in their writing. Should we also dispense with those words because they find them confusing? -- llywrch (talk) 05:11, 3 August 2016 (UTC)

Hello, I wrote "etcetera" because that's the Spanish spelling, I didn't bother to check the English spelling. Anyway, it's a common word in regular speech, unlike "e.g." and "i.e." (how would you pronounce them?), which are used only in formal writing and many people aren't familiar with it. --NaBUru38 (talk) 20:06, 2 August 2016 (UTC)

We either say the letters "ee jee" or "eye ee", or we say the phrase that they represent - "for example" or "that is", the latter being no slower. --Redrose64 (talk) 20:36, 2 August 2016 (UTC)

Iridescent is very wrong. The UK gov guidelines linked to by the OP suggest "Instead use ‘for example’ or ‘such as’ or 'like' or ‘including’... Try using ‘for example’ or ‘such as’ or ‘including’... Try (re)writing sentences to avoid the need to use [ie]. If that isn’t possible, use an alternative such as ‘meaning’ or ‘that is’.. They do not say "instead of ‘eg’ use ‘e.g.’". I support the adoption of a similar guideline here. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:32, 2 August 2016 (UTC)

Add categories to warning templates

I think that it would be useful if all the warning templates had categories that the user talk pages they are on would be included in. The categories could go by warning level and type. So {{uw-vandalism1}} would put the talk page in Category:Users with level 1 vandalism warnings and so on. I also think that only warnings should do this and not advisories or notices. -- MorbidEntree - (Talk to me! (っ◕‿◕)っ♥)(Contribs)(please reply using {{ping}}) 22:08, 2 August 2016 (UTC)

Could you explain why you think this would be useful? Personally, it doesn't make a whole lot of sense to me. The templates can just be removed and warnings are not a black mark and they aren't designed to label editors in any way. They are just...warnings. --Majora (talk) 22:12, 2 August 2016 (UTC)
Like Majora, I don't see this as useful. Also, it is trivially easy - and permitted - to remove warning messages, so decategorization under such a policy would likewise be trivially easy. Resolute 15:42, 3 August 2016 (UTC)
The category pages would be pretty useless on a project with as many warnings as us. And warned users would have more motivation to remove warnings, so it would often become harder and not easier to see previous warnings. Sections with warnings can be archived so there should maybe also be conditional code to not add a category on subpages, but warnings are usually substituted with no remaining transclusions or template-like code. I don't see a good reason for this proposal. PrimeHunter (talk) 15:51, 3 August 2016 (UTC)
+1. ―Mandruss ☎ 18:05, 3 August 2016 (UTC)
It could be useful for editor who would like to fix issues flagged up by specific templates. In the end, templates that stay up for a long time deface the article they are on. So we should get rid of templates ASAP. This proposal could help. But on the other hand, when I do such maintenance, I usually go to the template page and use the "what links here" tool which will also give you all pages it is on. So I am not sure this really solves a problem (while implementing it would require some massive effort). Arnoutf (talk) 18:44, 3 August 2016 (UTC)
The proposal is about templates used on user talk pages to warn a specific user about their edits. Article maintenance templates already add categories but they are hidden so you must enable "Show hidden categories" at Special:Preferences#mw-prefsection-rendering to see them. PrimeHunter (talk) 21:41, 3 August 2016 (UTC)

After thinking some more on this and reading the comments above, I too think that this isn't that great of an idea now. I was looking for a way to perhaps make the warnings have an organisation system (like how userboxes do), but I now see that it wouldn't work and would be pointless even if it did. -- MorbidEntree - (Talk to me! (っ◕‿◕)っ♥)(please reply using {{ping}}) 04:23, 4 August 2016 (UTC)

More precise use of date fields of sources and have a field for time

"Searches for missing parameters (including URL), then adds them if available. This is especially convenient when only an identifier is included within the template

  • The bot uses a range of databases including Google Books API, PubMed, CrossRef, AdsAbs and the JSTOR API"
  • "date=" is one parameter/field of a cited source. I don't know whether bots (such as the cited Citation bot) can automatically add or verify the "date=" field in a source, whether it is missing or not (specifically, I'm talking about cite web references and cite news references? But if it can not, I would argue it would obviously be very handy if a bot could crawl for dates in all cited on-line resources, and add the dates automatically.
  • These days, a more and more precisely measured and reported world, should allow wikipedia to crawl for the "date=" more accurately. I am talking about the problem here which currently arises when users manually enter the "date=" of different sources, due to sources using different time zones. I argue that even a field such as "time=" would be of importance (this would record the exact time, up to hours and minutes and seconds, according to how specific the information is recorded by the news source). Analogue, "access-time=" could supplement "access-date=".
  • As for "date=" and "time=", I think it would be handy if there would be an on-line automatically communicating international standard established; which can be used between on-line sources. That would enable sources to "upload" this standard to their servers (where they thus can specify the exact date and time, as well as their time-zone). One can argue that there already exists such "date", "time", and "time zone designator" formats to be included as meta-information into the HTML of websites. Wikipedia could advocate for websites to use this more heavily, for example by creating a list of websites which factually use a certain standard. On those sites, Wikipedia bots could crawl automatically for this information (according to the international standard; or standards; which it has learned to crawl), and adds this information as "parameters/fields" of cited resources.
  • It would be nice, if according to the time-zone which the Wikipedia viewer chooses, all of the instances of "date=" and "time=" are automatically changed and updated to be viewed according to her/his time-zone. — Preceding unsigned comment added by Verheyen Vincent (talk • contribs) 15:56, 21 July 2016 (UTC)
How often is it important to identify the exact moment that an article was published? If we're citing an article published in the NYT on 1st August, does anybody really care that it hit the Times website at 02:37 EDT? Would people in New Zealand really want to see the publication date of the article changed to 2nd August, because that's what day it was in Auckland at the moment it was published? I'd have thought that was more confusing than helpful. I'm sure there are cases where a precise minute-by-minute identification of source timings is important, but I don't think they're very common. I certainly don't think we should be making blanket changes to citations on the basis of this rather niche use case.
I'd also be very wary of automatically changing articles' citation dates based on the metadata of the page they're hosted on. It's not at all unusual for a website to be redesigned and to report the date of each page as the date of the redesign instead of the original date of publication. Chuntuk (talk) 14:45, 3 August 2016 (UTC)
  • Oppose We do not need to know the exact time something was posted. Besides, this would only cite web or maybe cite news as there's no way to know the exact minute that a book, magazine or other print item was published. The only times where this is useful is when some recent news topics have a fight over citations and that's a very rare occurrence. Otherwise no one is going to care the exact minute in time when a newspaper story from a year ago was published, and the exact date is rarely going to be affected. It's enough to get the title, location and date so we can find the source, adding more for this minor reason is not necessary. -- Ricky81682 (talk) 00:08, 7 August 2016 (UTC)
    @Ricky81682: This is Idea Lab: we don't support/oppose ideas on this page - we develop an idea until it becomes a clear proposal which can then be sent to WP:VPR (or elsewhere) for the actual voting. --Redrose64 (talk) 10:15, 7 August 2016 (UTC)
    Sorry, I messed up where I was. Ok, I see it's possible use in either cite web or cite news but online sources regularly provide updates as well. -- Ricky81682 (talk) 17:29, 7 August 2016 (UTC)

Promotional spam in page histories

An idea occurred to me and I thought I'd bring it here to maybe hash out a proposal to better defeat promotional spam in page histories. I noted a recent edit and reversion to the English Wikipedia article. In the spam edit the user had added several spam items with phone numbers to the lead. That was promptly reverted with this edit; however, the spam remains in the page history. So what's to stop me (if I were the spammer) from using the history link on my website with something like LOOK, SEE, Our stuff has even been on Wikipedia! Now, that might not be the best example; however, I think it gives a pretty good idea of what I'm talking about. To fight this, we would need to remove the spam from the page history much like we can remove certain edits from BLP histories and such. Just wondered if this is a concern, and should we work to fight it – or maybe we're already working to fight it?  Temporal Sunshine Paine  16:19, 4 August 2016 (UTC)

I don't think it's a concern. Spam is done to promote oneself, few people read page histories so that isn't as much of a problem to us and spammers know that few people read them. What you are describing is more akin to trolling or vandalism, but it's also not common for the same reasons. If people are bragging about vandalism in page histories, the offending revisions can be deleted under WP:RD#5-WP:CSD#G3 but that's not a common thing (again). Jo-Jo Eumerus (talk, contributions) 16:29, 4 August 2016 (UTC)
That makes me wonder if anybody is actually checking to see how our history pages are being used? It's vandalism, yes, and I come across similar spam edits frequently to the pages on my watchlist; but, someone coming to my website and clicking on that link just as likely wouldn't know it's vandalism to Wikipedia and would just see where my stuff actually has been on Wikipedia. With respect and thanks, I don't see where that's specifically addressed in either of the links you gave. Do we really have a handle on how widely this might be being done? There are companies who would love something like this and who might devise much better spam/vandal edits for later promotion on their websites.  Temporal Sunshine Paine  16:41, 4 August 2016 (UTC)
(edit conflict) Yes, the spam in the example I gave was probably just one person promoting themselves. Spam, however, is much more than that – many links outside Wikipedia are not allowed in reference citations and external links sections simply because they are spam links. Those are not just one person promoting oneself, those are companies putting ads on other websites and paying for them either with money or with reciprocal ads on their websites. Spam is such an infiltrating thing that we have pretty much grown complacent to it, at least where we ourselves are concerned. On Wikipedia, we are still asked to be diligent and not allow spam into our articles. Now say a company devises a much more professional grouping of spam edits, far more slick than the poor example I gave above. It may linger for a time before being reverted depending upon factors like how slick the spam is, how well the article is watched by editors, and so on. Then after it's reverted, the company devises a way to link to their Wikipedia spam history to further promote themselves on their website. All that has to be done to squelch this would be to remove the spam pages from page histories. But how do we even assess how or where such promotional techniques are used? Can we truly say that it's not common? How would we know if people or companies are "bragging" about their vandalism in Wikipedia page histories? Has spam become so insidious and alluring that the harm it does is no longer considered to be injurious and damaging?  Temporal Sunshine Paine  02:24, 5 August 2016 (UTC)
This example is known as Tech Support Spam, and it's an increasing problem. Another known problem is the escort phone number spammers. Between you and me Paine, admins (and not just me) have been known to delete this stuff under RD3, especially when it litters the edit summary histories. It can even get oversighted when it involves phone numbers. But generally it's only the most egregious stuff that's deleted. There are some examples at the histories of Antivirus software and Talk:List of Internet forums. -- zzuuzz (talk) 02:45, 5 August 2016 (UTC)
Okay, that's pretty cool and thank you! If I read you correctly, this is a growing problem/challenge, and yet it hasn't grown to a large enough size to have generated specific policy/guideline counsel for us, yet. And when we run across what we subjectively consider to be particularly egregious spam, we just find a willing admin to wipe it off the historic face of Wikipedia. "Tech support spam" and "escort phone number spam", huh? So for now, I guess all we can do is keep an eye out for it. After reading recently about the two companies that stole that photog's donated work and then accused her and others of infringement, I wouldn't put anything past the CEOs and boards of even some of the larger companies. Going to spam in a handbasket, I'd guess.  Temporal Sunshine Paine  14:02, 5 August 2016 (UTC)
These are the two main types of spammer who currently do this. See [2] for more examples. There is another spambot, handled by Special:AbuseFilter/271, which is no longer allowed to edit, but it too will fill the history with spam. Then there's the magic lover astrology spambot (Special:AbuseFilter/425). RD3 specifically excludes normal spam, but I don't see this as normal spam - I interpret RD3 as covering this by mentioning links to scams, dangerous things, etc, which are not useful and added for nefarious reasons only. It might be possible to extend RD3 to explicitly cover this, but I'm not sure it's necessary. So yes, find an admin when there's egregious spamming, we already often delete this stuff (but also notice that a lot of this hasn't been deleted). -- zzuuzz (talk) 15:31, 5 August 2016 (UTC)
  • Just a few hours ago I saw an example of this by Special:Contributions/Bobysharma97. I cannot even recall seeing such a deliberate attempt to use the page histories for spam. In this case, the user's spam included phone numbers and was revdeleted, including redacting the spammed edit summaries. I fully support this. The timing between me seeing those edits and me seeing this thread is so oddly coincidental that I suspect there is a deliberate campaign by one or more parties to do this kind of spamming. Hopefully it will turn out for them that it's not worth the effort and they will just go away. BUT the possibility that there is some motivating reason for this type of spam is significant. Perhaps it does game the system somehow for some search engines. Jason Quinn (talk) 19:24, 5 August 2016 (UTC)
    I really don't read that as a deliberate attempt to spam page histories, just ineffectual moronity. It is quite similar to other escort phone number spam I have seen, long before this thread. At any rate, it's nothing to get exercised over IMO - revert, RD5+G11, block, move on.
    OTOH, I wonder if it would be worthwhile to create a tag/category system (or perhaps a noticeboard) to report this? Like we have {{copyvio-revdel}} and Category:Requested RD1 redactions, we could make {{spam-revdel}} and Category:Requested spam redactions. BethNaught (talk) 19:40, 5 August 2016 (UTC)
  • Short of WP:DISRUPTION, it is not a problem, and WP:BEANS applies. --SmokeyJoe (talk) 06:39, 6 August 2016 (UTC)
To editors SmokeyJoe and Ricky81682: It would be interesting to find out how you came to the beans conclusion. Is it based on experience? research? gut feeling? Please keep in mind the rising level of complacency-thinking proportional to the growing level of spam since Usenet.  Temporal Sunshine Paine  10:20, 6 August 2016 (UTC)
When you start with "An idea came to me" and can't point to an example, I don't see that this is actually an issue. In theory, edit histories could be used for disputes over prior versions of articles now redirected but we don't see that. We see people just copying those pages and creating their own versions. That's why I think this is a BEANS issue. And again, if there is a specific example, then we can get rid of the spamming but to ask that our very limited admin corp waste mountains of time removing old revisions of pages all over the page for this minute chance is an odd suggestion. We do delete old revisions for copyright violations and in theory, people could link to those but we don't keep them around. -- Ricky81682 (talk) 21:53, 6 August 2016 (UTC)
Okay, fair enough; however, since this is an "idea lab" page, I thought it best to begin with "An idea came to me..." for the very reason that the extent of the challenge was unknown to me at that time. It does appear that there are two or three areas where this is being dealt with, and so it seems to be a bit more than a beans issue, and in fact calling it such could very well be an example of engrained complacency where even harmful spam may be concerned. I could be wrong.  Temporal Sunshine Paine  06:28, 7 August 2016 (UTC)
I think the answer then is Od Mishehu's point, that if an example is seen, it can be requested and it will be removed (I'd remove it for one) so I guess in the end, your actual idea is accurate and supported. Do you think it should be more explicitly stated in the WP:REVDEL reasons? Is that your concern? -- Ricky81682 (talk) 17:32, 7 August 2016 (UTC)
Best answer is probably "I don't know". The opinions of all here are important, highly valued and respected. If the spam is already believed to have escalated to the point where an explicit REVDEL addition is necessary, then yes, that's a good idea. I'll have to leave that up to those who have a much better handle on it than I do. Heartfelt gratitude to all who have responded to this thread!  Paine  17:57, 7 August 2016 (UTC)
Any admin is autherized (but not required) to revdel any edit content which adds nothing but spam (once the edit has been reverted), or any edit summary which contains such spam, under RD 5/CSD G11. Any other user can request it, according to the instructions at Wikipedia:Revision deletion#How to request Revision Deletion. עוד מישהו Od Mishehu 10:06, 7 August 2016 (UTC)

Counter category to introductions

As part of the RFC on languages (please join there if you can), Uanfala seemed to like the idea of putting constructed languages at least into the Category:Introductions by century categories (part of Category:Debuts and then Category:First events). However there is no equivalent in Category:Last events other than the disstablishments categories which seems disfavored for languages. Category:Obsolescence was suggested by I think that's too awkward. Any other ideas?

Main Page redesigning discussion

Moved from Talk:Main Page
 – --George Ho (talk) 07:06, 12 August 2016 (UTC)

I don't see or know the appeal of redesigning the Main Page other than trying to modernize the Main Page. However, there have been too many sections about the same thing at Talk:Main Page. Also, many proposals have been attempted without avail. Therefore, I decide to have another discussion about the same thing here, so many editors involved will get organized and come up an organized proposal. Also, the "Talk:Main Page" would not be cluttered with bunch of failed Main Page proposals there. Pinging Dr. Blofeld, Mathmensch, Jackiespeel, Jayron32, Amakuru, Khajidha, 331dot... There are so many editors, so I could not ping all of them. --George Ho (talk) 07:06, 12 August 2016 (UTC)

Maybe creating a page Wikipedia:Main Page/Design as a centralized board for such discussions might help, akin to Wikipedia:Main Page/Errors for errors. Jo-Jo Eumerus (talk, contributions) 07:54, 12 August 2016 (UTC)

I think if we could just tweak it for starters it would start to improve. The first thing I think, and I know a lot of people agree with this, I think the Featured Article should have a larger picture and the FA feature cover the width of the page at the top.♦ Dr. Blofeld 08:40, 12 August 2016 (UTC)

I do not agree with this idea, because then the news section is only available after scrolling, contradicting optimal usability. --Mathmensch (talk) 14:52, 12 August 2016 (UTC)
I agree with what is being summarized above (as my name is there) - but there will be some occasions when it will be relevant to discuss 'change X' on the MP. ('The 25 different ways of constructing layouts have been discussed and these are the most viable options' or similar). Jackiespeel (talk) 09:34, 12 August 2016 (UTC)

I think that no all-in-one-go change will ever get enough support. Especially if the main thrust of the proposal is a vague "we need to update the Main Page because it looks dated". Phrased that way, it is a pure aesthetic question and no two people are likely to agree 100%. Tell us something that is objectively non-functional or poorly functional or done in a "got to go all around Robin Hood's barn to do it" way and how to fix it. When the actual problems are corrected, then more aesthetic changes could be decided on. But only one thing at a time. --Khajidha (talk) 14:16, 12 August 2016 (UTC)

I agree with the above fully. Let's eat the elephant one bite at a time, and lets focus on functionality over mere aesthetics (like color schemes). What is one specific design change we should make, and what can we do about it. --Jayron32 14:52, 12 August 2016 (UTC)
But we do need aesthetic changes. Everyone who is an expert or pro on website design will agree unanimously that the Wikipedia main page looks horribly dated. It's not subjective. It's a fact. 128.227.142.245 (talk) 15:17, 12 August 2016 (UTC)
But for those of us who are not experts/website designers (probably the vast majority of WP users) #that is the way the Wikipedia Main Page looks# and many will actually want the current brand image. Most of this group (who wish merely to increase the benefits of WP find the repeated utterings of 'look at my new reworking of the MP' slightly tedious. Jackiespeel (talk) 15:47, 12 August 2016 (UTC)
(the above was not me)"It looks dated" is ALWAYS a subjective statement. If you mean "other websites don't do things this way", SAY SO. --Khajidha (talk) 16:21, 12 August 2016 (UTC)

Technical changes improving the working of the Main Page/Wikipedia in general should be excluded from this discussion - and there are improvements which can be discussed on the MP/do get adopted (linking the picture with the relevant text on a list). Jackiespeel (talk) 15:47, 12 August 2016 (UTC)

Then how is this different from "let's paint the bikeshed BLUE! No, let's paint the bikeshed RED!" --Khajidha (talk) 16:23, 12 August 2016 (UTC)

Tell me then Khajidha, is there anything about wikipedia you think is less than perfect? It must be a nice feeling to feel that you're in an internet heaven on here.♦ Dr. Blofeld 19:34, 12 August 2016 (UTC)

There's lots of things I find less than perfect here, I just don't see why people make such a big deal out of how the page LOOKS. But, then again, THIS is my main page: https://en.wikipedia.org/wiki/Wikipedia:Main_Page_alternative_%28Khajidha%29 --Khajidha (talk) 14:13, 13 August 2016 (UTC)

Suggestion for this discussion - put the reply as a block rather than interlacing or the discussion will get too confusing.

Basically - Wikipedia has a brand image which is of a certain age - which a proportion of users think needs to be updated. However - the vast majority of people do not think enough 'one way or another' to put in their halfpenny'sworth requesting it be changed. A proportion of people think the Main Page should be changed - but there are a wide range of proposals as to the manner in which it should be rearranged (carrying on the motif - if today is (date) then the bike shed will be (colour for 24 hours). WP is not perfect - but 'it works reasonably well' - and while there will be room for improvements and/or changes to reflect current best practice/how the rest of the Wikiverse changes etc, the users and contributors in general should not be alienated. (We all know of rebrands which annoy the customer or which have minimal impact on the target audience despite 'much time and money being put into the effort.') Jackiespeel (talk) 21:20, 12 August 2016 (UTC)

THIS. --Khajidha (talk) 22:23, 12 August 2016 (UTC)

Idea Lab Mentor

Hello :) This is my proposal about mentoring new users, so bullying / harassment phenomenon be eliminated. I' ll be happy to hear your comments. Thank you! --Ανώνυμος Βικιπαιδιστής (talk) 12:09, 7 August 2016 (UTC)

We already have adopt a user, how would this be different? Iazyges (talk) 23:47, 15 August 2016 (UTC)

What feelings, emotions and ideas does this image bring to you? --Felipe (talk) 16:00, 12 August 2016 (UTC)

Curiosity ("I feel lucky"?), "isn't this how Google does it already?" and I wonder if there was a way to shrink all the various boxes that fill the current mainpage - or replace them with links. And the thought that it would need a miracle for this design to be adopted on the main page. Jo-Jo Eumerus (talk, contributions) 16:03, 12 August 2016 (UTC)
Wow, I JUST noticed that there is a discussion about redesigning the main page just above my post! Pure coincidence, I swear, lol. I posted this image because I was playing with an idea for a Wikipedia Reader, did a home page design based completely on Google, and found it so disturbing that I wanted to hear some reactions hah. It isn't meant as a suggestion for redesigning the main page at all. --Felipe (talk) 16:36, 12 August 2016 (UTC)
Clean, concise, modern, effective - an excellent design. Leagues ahead of what we currently have.128.227.142.245 (talk) 16:41, 12 August 2016 (UTC)
Certainly looks more professional though a bit search enginey. Remove the feeling lucky and add some important links at the bottom to things like News, Featured Articles and Good Article and I think it would be good!♦ Dr. Blofeld 19:31, 12 August 2016 (UTC)
Seriously? Resentment, frustration, anger. We aren't just a search box for answers. We aren't monolithic. Wikipedia is about collaboration and creativity and bringing knowledge to the world. A search-only portal is a faceless gateway to ephemeral, transactional knowledge. We can and should show living knowledge, and the Main Page "clutter" is a step in that direction. We shouldn't abandon that just because minimalism is pretty. {{Nihiltres |talk |edits}} 22:57, 12 August 2016 (UTC)
The new page has much less functions. The more clicks the user needs to get to a topic, the worse. If this design was implemented, the user would need lots of clicks. Therefore, I am against that, or even to reduce the current boxes to links. Let alone the legal argument we'd get with Google.
However, to place the search function more centrally may be a good idea, although this may rather be a general design proposal; the search bar currently is on the far right but should be roughly in the center (as so many things). --Mathmensch (talk) 09:13, 13 August 2016 (UTC)
Howdy Felipe. Your design looks a little familiar. :) I don't know if you had a look at some of the updates the portal team has been making, but if you're interested, please take a look. We have another update slated for the near future that brings the portal even more inline with your proposal. Cheers! CKoerner (WMF) (talk) 15:24, 16 August 2016 (UTC)

developing proposal for research-based approach for countering harassment

As part of the Wikimedia:Meta:Project Grants process, we've been developing a proposal for gathering research and motivating development of tools and processes for countering harassment: I School Challenge for Countering Online Harassment.

As English Wikipedia is a key platform that we'd like to investigate and benefit through this project, we'd especially appreciate the feedback of this community. Very briefly, we plan to:

  • organize a conference to collect research and assess needs;
  • issue a Challenge for projects that counter online harassment; and,
  • develop a "research commons" to support ongoing collaboration on this topic.

General feedback, comments, questions, or endorsements are all welcome. In particular, we could benefit from advice on:

  • who to contact among Wikipedia users or researchers, particularly those outside the United States
  • particular areas where harassment has been a problem you've identified on Wikipedia and how that might vary from other platforms
  • what format/tool would be most useful for gathering relevant research and tools for addressing online harassment

Thanks -- Npdoty (talk) 00:44, 18 August 2016 (UTC)

Combining rollback and pending changes reviewer

Maybe this has been discussed before, but is there any particular reason we don't combine rollback and pending changes reviewer as a user right? The criteria for granting are highly similar and neither user right is a big deal. Twinkle's rollback functionality more-or-less reduces the utility of rollback to its Huggle access, and pending changes reviewer has never been a big deal to grant, as far as I'm aware. Given that they're both related to counter-vandalism, this seems like an opportunity to combine two user rights and reduce our administrative overhead at WP:PERM. Is there any good reason not to do this? Pinging a few "regulars" at PERM for their thoughts: @Kudpung, Widr, and NeilN: (feel free to ping anyone else you think might be interested). ~ Rob13Talk 20:12, 16 August 2016 (UTC)

Pending changes is more content focused. Vandalism is easy to spot. Pending changes is more asking, "does this edit meet policies and guidelines and any consensus and does it improve the article?" --NeilN talk to me 20:45, 16 August 2016 (UTC)
Our guidelines for granting seem to indicate a relatively higher threshold for vandalism than reviewer at the moment, though. That doesn't make much sense to me either, but it is what it is. ~ Rob13Talk 02:05, 17 August 2016 (UTC)
The sysop load at PERM is nothing to what it was a couple of years ago. I ran the pages at PERM almost single handed in those days because no one else was much interested. Nowadays we hane MusicAnimal's excellent bot to help us. I don't see PERM as being particularly backlogged these days. It just needs to keep the occasional non-admin away from trying to clerk it, and to keep the answers to requests as simple as possible and not let each request be turned into a long thread. Reviewer and Rollbacker have different functions and different entry thresholds. I don't think it would be a good idea to merge them. Kudpung กุดผึ้ง (talk) 23:18, 16 August 2016 (UTC)
I have reviewer but not rollbacker, and I don't think combining them would be a good idea. As others have said, the tasks and thus the skills required, are different. Rollbacker is a pure vandalism cleanup permission for hig-speed editors whereas reviewer is a content patrolling permission and often requires slow, careful work such as checking sources or POV. It also puts you in contact with well-meaning newbies. While there are many editors who do both, there are also many, such as me, who don't. I work in new page patrol, AfC along with a bit of AfD and newbie-welcoming. I work slowly and carefully and generally screw up whenever I go fast. I got reviewer no problem but no-one in their right mind would give me rollbacker. Similarly, there are editors who specialise in counter-vandalism work but lack the patience to deal with the well-meaning but clueless newbies who crop up in pending changes review. Happy Squirrel (talk) 03:37, 17 August 2016 (UTC)
Yeah, I don't want Rollback (I'm paranoid enough to have preemptively loaded Java code to block most Rollback displays even though I haven't even asked for it! because I've heard too many horror stories about people "accidentally clicking" Rollback). Twinkle basically gives you Rollback in a way where it's a lot less likely to be used "accidentally clicked" (and gives it to you in a way that's easier to use). And I was "manually Rollbacking" edits long before I knew what Rollback even was. To me, Reviewer is less about "vandalism control" and more about "content managing" and "article quality control", while Rollback is pure "vandalism patrolling" – I'm not sure they're all that related... --IJBall (contribs • talk) 06:52, 17 August 2016 (UTC)
Agreeing with above. I don't see any good reason to combine the two. Widr (talk) 06:58, 17 August 2016 (UTC)
@Kudpung: It's MusikAnimal with a 'k', not a 'c' :) Anyway I agree with the above that the two rights serve different purposes and should not be combined. I don't think the bar for rollback is necessarily higher than PC, just that the guidelines for granting PC are not as well defined and vary by admin. I only look for a general understanding of essential policies and guidelines, in particular BLP policy (BLP edit counter may help), and a decent tenure (perhaps a month of active editing). Other admins want to see counter-vandalism work in particular before granting PC, while I don't find that necessary. Basically it boils down to "is this edit appropriate?", so anyone who's got the policies and guidelines down should surely be able to identify vandalism or an otherwise unconstructive change — MusikAnimal talk 15:50, 17 August 2016 (UTC)
I've mentioned this in the past, but I think we need to have a community discussion or an RfC about the requisite qualifications for pending changes Reviewer rights – I've thought for a while that the bar for being granted Reviewer is too low/too vague, and it would be good if we could come up with a more concrete "qualification level" for Reviewer, as we already do for Rollback, Autopatrolled, Page mover, etc. --IJBall (contribs • talk) 20:03, 17 August 2016 (UTC)
The threshold for Reviewer is so low that when the right was first created it was accorded to thousands of users by a bot. The problem with doing that kind of thing is that it makes it almost impossible (without a thorough knowledge of IT) to extract any stats of who is actually active, how many reverts they have made, how effective the system is, and a typical user profile. We have the same problem with NPP, which as our only firewall against unwanted new pages ironically and totally paradoxically does not require any competency at all and is almost completely impossible to control. Kudpung กุดผึ้ง (talk) 02:04, 18 August 2016 (UTC)

Adding restrictions on maintenance and tracking category creation

There is currently a bit of a "Wild West" aspect related to maintenance and tracking categories as Category talk:Pages using deprecated coordinates format, this RfC, and general experience with them suggests. This category has long been in the back of my mind and made me wonder if stricter oversight is needed. My initial impression is that we should have a few standards regarding tracking and maintenance categories to prevent situations where editors are encouraged to "fix" problems that haven't had proper discussion. (This category is an example and there are at least a handful of others I've stumbled across that raise serious questions about their existence.) What do people think of the following ideas:

B1) All maintenance categories require a proper self-description regarding how pages land there and what, if anything, can or should be done to remove them (answers the question what the category is for)
B2) A quick public discussion or RfC (along with consensus) regarding the category before it goes "live"
B3) creators of the categories are required to provide links on the category page to prior discussions regarding the category creation/purpose/etc. (answers the question why the category exists)

These are all very reasonable (and I'm only presented them in rough sketch form) but I think they require low-investment by category creators but give high return to editors. It seems almost foolish for us not to require at least B1 and B2. It'd be good to have a place to consolidate this discussion too, perhaps at something like Wikipedia:Categories Approvals Group. There's other category issues too that need to be addressed. For instance some tracking categories are created "temporarily" but just forgotten about. There needs to be some onus on the creators to let editors know they are still being used for something or for them to remove categories no longer in use (or at least provide instructions to others about when and how it'd be okay for them to remove it). Comments on these ideas? (moved from RfC discussion) Jason Quinn (talk) 06:37, 16 August 2016 (UTC)

  • B1 seems unequivocally good. B2 and B3 I question per WP:BOLD. Regarding "1 time" tracking categories: There could probably be a custom dated db- template or otherwise which puts the category into CFD, afterwhich the reviewing admin could either choose to delete the category or extend the date. --Izno (talk) 11:44, 16 August 2016 (UTC)
  • I also like B1, which I try to do with every "unsupported template parameter" category that I create. I don't think that B2 is necessary for hidden categories; my experience has been that the cats almost always make sense, and they can be undone easily with a discussion, a change to the template code, and speedy deletion of the category. B3 is a good idea, but the link should probably go on the category's Talk page. – Jonesey95 (talk) 12:46, 16 August 2016 (UTC)
  • I would differentiate sharply between hidden categories and templates at the top of articles. One is very invasive and should only be done if we were seriously thinking of blanking the article, the other is harmless and invisible to mobile users. So Hidden cats we can leave to people's good judgment and only step in when we find people creating them for Reptilians and other alleged extraterrestrials. Templates at the top of articles we should delete unless useful enough to merit turning into a hidden category, very few should be kept as templates. ϢereSpielChequers 13:13, 16 August 2016 (UTC)
  • Jason, is B3 meant to imply "The existence of some prior discussions is required, and if there weren't any, then you oughtn't be creating it" or "If any discussions happen to have existed, it'd be convenient if you linked them, in case people are interested in the history"? I can imagine that rough phrasing being interpreted both ways, and that's not likely to be good for a proposal. WhatamIdoing (talk) 20:53, 18 August 2016 (UTC)
The latter interpretation is what I had in mind: If any discussions happen to have existed, it'd be convenient if you linked them. If B2 were also required, then that discussion would count as a discussion to be linked. The point of this requirement would be so that editors who stumble across the category can convince themselves that the category is tracking a problem that really ought to be fixed so that they can decide whether to invent the time to fix those issues. What's undesirable is for categories to pop into existence ex-nihilo with only the category creator as a contact for follow-up information. I've had experience with category creators who are unwilling to answer questions or hostile to questions about the categories they've created and this requirement would avoid such scenarios. Jason Quinn (talk) 21:13, 18 August 2016 (UTC)

Expanding Listed Movie Producer Credits

When TV shows are listed on Wikipedia, the Producer credits are listed in the entries, including all of the Co-Producers, Producers, and Executive Producers - each of whom are listed by name. However with movies this is not the case, for reasons I don't quite understand.

Co-Producers and Executive Producers do a significant bulk of the producing duties (if not most of them) in producing a movie, and are eligible to be part of the Producers Guild of America (PGA). Again, one doesn't need full Producer credits to be recognized by the PGA - Co-P and EP credits suffice.

Co-Producers and Executive Producers are frequently the people generating the concept for the movie, finding the source material upon which the movie is based, and/or identifying the screenwriter, director, or actor who has conceived the concept for the movie and bringing them into the production company and/or into the movie studio or financiers who commission the production of the movie - i.e. they often play a key role in generating the movie.

From there they're often the ones developing the screenplays, overseeing the casting and crewing up of the movie, the production of the movie (rendering services on set from start to finish), and the post-production movie (again rendering services - this time in the editing room). They also weigh in creatively on the marketing of the movie - in terms of giving feedback on the one sheets/posters and trailers.

They might not qualify for a full Producer credit yet - but they're often integral in getting the movie made, and are a core part of the creative process.

Why does Wikipedia limit the listing of credits to just Producers for films, whereas there's no such constraint placed on TV show entries?

Is this something that the community would support changing? — Preceding unsigned comment added by WikiGrifter (talk • contribs) 12:25, 24 August 2016 (UTC)

You should first read Template:Infobox film which states 'producers only' in the directions for adding to the producer credits. Then try WP:WikiProject Film for additional information about the style and organization of Wikopedia articles related to films. You will also find a list of editors you could contact for further discussion of your suggestion. — Neonorange (talk) 19:39, 24 August 2016 (UTC)
There are far too many producers these days. I think I counted fifteen in one episode of a TV drama. Really only one is needed - traditionally it was the person who signed the cheques. --Redrose64 (talk) 23:18, 24 August 2016 (UTC)

One way communication in block appeals is a broken or flawed system. The block appeal system should have two way communication

I think that anyone who is familiar with the block appeal system can readily understand that the one way communication model is utterly unsuitable for block appeals. To explain, when doing a talk page block appeal or a utrs block appeal, the appellant typically has the block message and maybe a little more background to work with. Based on that, they write an appeal with no way of knowing who will review their appeal and no way of communicating with them, and no way of knowing what they think about the situation, or what their specific concerns are. The utrs appeal system is fairly similar. So an appellant will post one appeal, then that will probably be denied with a message. They'll then have the original block message and the first appeal denial to work on, and they'll make another appeal request. This process can continue for a while. Sometimes appellants who do this are seen as disruptive for lodging several appeals. This system seems to be entirely broken. Maybe there could be some sort of appeal noticeboard with a bot that transcludes parts of a blocked user's talk page? Or a bot that copies replies posted on ab appellant's talk page on the block appeal noticeboard? Generally, any way for there to be any kind of two way communication between the appellant and the person reviewing the appeal would be a step in the right direction in my opinion.TeeTylerToe (talk) 23:17, 28 August 2016 (UTC)

There is one, it's at CAT:RFU. Blackmane (talk) 13:21, 1 September 2016 (UTC)

"Unbundling" the patrol ability by namespace

Moved from Wikipedia:New pages patrol/RfC for patroller right#Comments

Moving this here Andy M. Wang. —Godsy(TALKCONT) 03:50, 31 August 2016 (UTC)

  • This proposal focuses on patrolling newly created articles. It conflates the process we've established for patrolling pages in the article namespace and patrolling itself. A page in any namespace can be patrolled. Would it be feasible to separate the patrol ability based on namespace? If so: I think a better way of implementing this would be to remove patrolling articles from the 'patrol' right, thus leaving the ability to patrol other namespaces with autoconfirmed and confirmed users, while creating an "'article patrol'" right to be granted with the user right by the name suggested here. This would allow new users to gain familiarity with patrolling without the negative affects it currently has on the the encyclopedia proper. Pages in other namespaces aren't as actively patrolled.—Godsy(TALKCONT) 00:45, 29 August 2016 (UTC)
    • @Godsy: I think it makes sense, so long as the patrolling mechanism works on titles, not pages, which I believe is correct...? If that's not the case, then a user could move an article to another namespace, patrol it there, and move it back. If it is the case, the scenario I just mentioned can't happen as far as I know (since the article title is not patrollable) — Andy W. (talk · ctb) 20:00, 29 August 2016 (UTC)
  • Gaining experience is an incremental process, as is clearly demonstrated by comparing all the minor rights - WP:PERM best illustrates this. If a user is already an established editor, there it would not be a problem to take 30seconds to apply for the right to patrol new pages. Users with less experience can get theier feet wet at Recent Changes, and Rollback. It's not a good idea to unleash inexperieced uses immediately on NPP where there is no effective supervision or mechanism to catch errors. The tutorials and videos are excellent but nobody bothers to read them; there is also a school, but no one avails of it. Kudpung กุดผึ้ง (talk) 23:30, 1 September 2016 (UTC)

People mistakenly check to treat signature as wiki markup

I just replied at the Help desk, telling the poster to uncheck "Treat the above as wiki markup" in the Signature section of Preferences. People check that box mistakenly often enough that it seems to me that it might be a good idea to automate the choice. Maybe remove the check box, and treat changes to the signature as wiki markup if and only if it contains a link to the user's user page and/or user talk page. —teb728 t c 09:57, 4 September 2016 (UTC)

WP:SIGLINK also allows to only have a contributions link, and the section is not marked policy so it officially only has guideline status. Preferences other than gadgets are controlled by the MediaWiki software so developers would have to make code for English Wikipedia signature guidelines. I also think it would create confusion for many users who have wiki markup in the box but miss one of the required links, for example after a user rename or when testing signature code. If I use your signature without wiki markup checked then it produces: [[User:teb728|teb728]] [[User talk:teb728|t]] [[Special:Contributions/teb728|c]] (talk). Another option working at all wikis would be a warning (or maybe a disallowing error message) if you check "Treat the above as wiki markup" but have no wiki markup at all when you try to save. It would need a precise definition of what is considered wiki markup. PrimeHunter (talk) 11:17, 4 September 2016 (UTC)
I see no reason for the change it very clearly says
If unchecked, the contents of the box above will be treated as your nickname and link automatically to your user page.
If checked, signing with ~~~ or ~~~~ will insert the above markup in place of your username, including any wikicode or formatting. Custom signatures should link to your user page or your user talk page. and has a bold link to Wiki Markup page. So why is a change needed? VarunFEB2003 11:44, 4 September 2016 (UTC)
That's only the case if you have your language set to "en - English" (it comes from MediaWiki:Tog-fancysig). If you have another language set at Preferences, you have a significantly shorter message: "en-CA - Canadian English" produces "Treat signature as wikitext (without an automatic link)" (see MediaWiki:Tog-fancysig/en-CA), and "en-GB - British English" produces "Treat signature as wikitext (without an automatic link)" (see MediaWiki:Tog-fancysig/en-GB). Neither of these has a link in it. These differences are among the reasons that we discourage the use of those two langauge settings, yet people still use them. --Redrose64 (talk) 12:21, 4 September 2016 (UTC)
I have fixed the other English messages. עוד מישהו Od Mishehu 03:44, 6 September 2016 (UTC)

Discouraging and eventually phasing out cryptic template redirects (shortcuts)

Tracked in Phabricator
Task T145067

During a recent AWB discussion, we came to consider the pros and cons of template shortcuts, for example {{bda}} for {{birth date and age}}. Several people there made good points about abbreviated template redirects being cryptic to new editors, and I certainly agree that on collaborative code projects such as Wikipedia, code readability should be a top priority. So that made me wonder whether there is a place for these kinds of template redirects. They are handy for seasoned editors because they type faster, but if they are to be discouraged because they make things harder for new editors, and if AWB is going to expand those abbreviations anyway, I believe the creations and use of these template redirects should be abandoned entirely. Certainly by recommendation, and eventually perhaps by removing them one by one as the very creation of them should be discouraged.

This would be a "policy" change, not a "technical" one, right?.. Bit confused on that point :) Also, should I make any other considerations? –Sygmoral (talk) 21:59, 22 August 2016 (UTC)

Could a bot be created that would change shortcuts to the longer template name? That way editors who know them can use the shortcuts and the template's purpose would still be clear to future editors? —PermStrump(talk) 22:43, 22 August 2016 (UTC)
WP:COSMETICBOT, but, that's basically what the general fixes in WP:AWB do already. --Izno (talk) 23:17, 22 August 2016 (UTC)
And they're really annoying, when you come across an edit where Yobot (talk · contribs) has made perhaps 30 changes, 29 of which are bypassing template shortcuts, and only one is a valid fix (like moving a period to precede <ref>...</ref>) it's very hard to spot that single beneficial change. See also WP:NOTBROKEN. --Redrose64 (talk) 23:43, 22 August 2016 (UTC)
For example, this edit by I dream of horses (talk · contribs). There are 20+ changes highlighted there, but AFAICT there was only one real change - the very last one, altering a hyphen-minus to an en-dash in a page range. Other than that, I see nothing constructive. --Redrose64 (talk) 08:06, 3 September 2016 (UTC)
We should keep all those template shortcuts. What happens is that editors learn them, and do not know the other longer names, as they are too long and complex, with too many possible alternatives. It is fair enough to rewrite them with AWB (or bot), but don't take away the usefulness of the old name. New editors will need about the same amount of brain power to learn either name, so it is really just a convenience to editors that read the wikitext to know what the template does, to use a longer name. Graeme Bartlett (talk) 23:41, 22 August 2016 (UTC)
+1 @Graeme Bartlett: There is much to be said for shortcuts in entering content; think of them as the equivalent to keyboard shortcuts for office applications -- without those, productivity of experienced users plummets. --User:Ceyockey (talk to me) 01:10, 23 August 2016 (UTC)
As well as the points brought up by Graeme Bartlett, I forsee a lot more typoes in template names if we force everyone to type them long hand. This could even backfire and make it harder for newbies to quickly use the handful of templates they use often. For me, the most confusing bunch of shortcuts was always the policy and process ones (NPOV, V, AIV, COIN etc.) but given that all these shortcuts can be easily searched and there are resources for lost newbies to ask questions, it really isn't a big deal. Happy Squirrel (talk) 00:45, 23 August 2016 (UTC)
+1 @Graeme Bartlett: There is a major accessibility issue here- I meet a lot of older users and it is policy to be inclusive. Think RSI, every extra key stroke is a discouragement. In heavy article which needs expert input we need to keep it as keystroke friendly. I was talking to an 85 year old, yesterday who I want to involve- he showed me how he copes with his Parkinsons on the keyboard- a keyboard style I would describe as 'hope and peck'. To halp I will set up some obscure template shortcuts. We mustn't be discrimnatory or ageist. ClemRutter (talk) 08:52, 23 August 2016 (UTC)

Well then, if there are such strong arguments to keep the shortcuts, should AWB still expand all template shortcuts it comes across? I hear you all say the shortcuts have great benefit and new editors will just learn those as they see and use them - but these benefits are gone if new editors will see (and learn) the full names rather than the shortctus. My point is just that it is confusing that two template names are pointing to the exact same thing, and there is no recommendation on which one to use over the other. There's no consistency, two similar articles could both reach the highest Wikipedia standards but one may be using shortcuts and the other full names? That just doesn't feel right... (perhaps a long term solution lies in changes to the (visual) editor rather than actual code policy) –Sygmoral (talk) 13:17, 23 August 2016 (UTC)

Shortcuts are good for the user adding them, but make things more difficult for users subsequently reading the wikicode. There is certainly something to be said for keeping these shortcut redirects, but replacing them with AWB as a side-effect of other edits. And while perhaps the visual editor can be tweaked to make these shortcuts less needed, please don't make things harder for users who prefer old-style editing. עוד מישהו Od Mishehu 05:29, 24 August 2016 (UTC)
What I meant with the (visual) editor is mostly that people could type the shortcut, and it would be automatically translated into the full form when saved (a bit like a subst, but only from one template name to another). That way, it's more like a real "coding shortcut": writing something shorter that results in the same (longer) code. So then editors can keep using shortcuts in the same way as now, and people reading the saved wikicode see more descriptive template names. The drawback to this is that new editors won't see the shortcuts (which was the whole point) and so won't learn to use them. Which could then be solved with a visual editor that shows available shortcuts (e.g. on mouseover on the template name). So that's also why I said "long term solution" :) –Sygmoral (talk) 03:15, 25 August 2016 (UTC)
@Sygmoral: The role of shortcuts in the visual editor would be in looking up the template to be filled in. Haven't tested this, but best practice would be to have all shortcuts resolve through synonymy to the full template name in the Visual Editor template lookup tool. --User:Ceyockey (talk to me) 14:41, 28 August 2016 (UTC)
Forget Visual Editor very few things work on it. this page shows you extensive usage of templates. Try editing it with visual editor though it is available you can't change a word out there! While VE tends to be good for cleanup writing major pages isn't possible in it. We use {{hat}} for {{Hidden archive top}} are we going to type such a long name. There is 90% chance of errors because either you write the wrong spelling or make a capitalization mistake! — Preceding unsigned comment added by VarunFEB2003 (talk • contribs) 18:32, 3 September 2016 (UTC)
That sounded like a dare, Varun, so I changed a word. Whatamidoing (WMF) (talk) 11:34, 8 September 2016 (UTC)

Sygmoral, it should be possible to do this in the visual editor. I've posted your suggestion at phab:T145067. You can comment there if you have any other details or want to correct something. Every registered Wikipedia editor has an account there: go to the login page, scroll to the end of the page, and click the medium-sized yellow sunflower button for mediawiki (not the big LDAP one). Perhaps they'll agree, and then this will happen eventually. Whatamidoing (WMF) (talk) 12:27, 8 September 2016 (UTC)

Firstly, note I’m also, or maybe even especially, talking about links to official pages of articles’ subject, therefore the scope of this problem I’m writing about is not covered by WP:ELNO.

Warning about one of the sites Wikipedia articles link to being a known attack site. This is a surprise warning: this site belongs to a legitimate entity that can’t be suspected of distributing malware.

This time this problem happens with an article about Collegium Invisibile. Namely, the main site of CI is reported to be an attack site.

6 years ago there were similar issues about the Internet site of Ultra Records. That time, after a short discussion, a warning was temporarily put next to this link.

What should be do now? What should be do on subsequent similar issues? Will we put a warning like that time? Will we remove the link altogether? Or maybe we will just do nothing? (In case of many webpages, if they get compromised, there are hopes these pages will get cleaned up very soon; but in other cases this is not that sure)

If we choose to put warnings or remove such links, maybe it would be worthy to set up a bot that would periodically check if our external links are present on one of the lists of malicious webpages (Google, McAfee Site Advisor, etc?)

Regards, 83.28.154.161 (talk) 17:37, 1 September 2016 (UTC)

Perhaps it can be handled via a javascript call to do something like trap beforeunload events and check the target url? Praemonitus (talk) 19:13, 2 September 2016 (UTC)
Whatever mechanism Wikipedia puts in place to handle this, it should not rely on JavaScript. Some users do not have JavaScript enabled. zazpot (talk) 23:20, 5 September 2016 (UTC)
I haven't checked your links, but if you asked at WP:ELN what should be done with a link to an official website where there is reason to think the website is (or often is) infected with malware, the response would be delete the link. Do not put a warning, and do not show the link as an unclickable URL (with nowiki), just delete it per WP:ELNO#EL3. If the site becomes clean, restore the link. Johnuniq (talk) 08:33, 3 September 2016 (UTC)
Specifically for WP:ELOFFICIAL links, we have occasionally posted the link in plain text ("www.example.com", without any http://), sometimes with a short note (perhaps something like "possibly hosting malware as of September 2016"). This is something to consider when there is disagreement about whether the website is actually malicious (e.g., present on one of the usual lists, but not others; or it's still tagged as dangerous, but the site claims to have repaired it recently).
To give an example that I remember offhand, there was a minor American politician whose site was corrupted during an election, and who publicly discussed the incident (in enough detail that the incident could have been included in the article). We talked about several options, and several editors supported naming the website in plain text, but including a warning. WhatamIdoing (talk) 12:41, 8 September 2016 (UTC)

A way for controversial admins to be "put on trial"

I think that we should take a page from the policy book of the Dutch Wikipedia with how they handle their admins. (see nl:WP:AFM) I think that we should have a process that's available to all users with edits above x amount where they can have an admin be reconsidered to keep their admin rights. This process could only be done every 2 months or so per admin. This process can only be started with a valid reason (perhaps having a criteria page to choose from, like WP:CSD?), other than just the admin being inactive and the such. I know that this Wikipedia has over one thousand admins, but I think it can be done with the right policy and process. Any thoughts to improve this idea? --MorbidEntree - (Talk to me! (っ◕‿◕)っ♥)(please reply using {{ping}}) 12:34, 7 September 2016 (UTC)

Are there any admins that you think need to desysopped? Anyway you can already raise a case at ARBCOM, or have a complaint and a debate at WP:AN/I. If a consensus comes from a discussion there, there could be pressure to make them resign. Also on this board, there can be a community ban discussion. If the community bans an admin from doing certain things it would have to be obeyed and enforced by other admins. I have not heard of this happening, eg a ban aginst blocking people, because if that admin needed to be banned, they should also loose the admin rights. Graeme Bartlett (talk) 12:54, 7 September 2016 (UTC)
I don't have any particular admins in mind, no. I just came across that policy on the Dutch Wikipedia and thought we could use it as a starting point. And I think that having a more concrete way of desysoping admins would be beneficial. --MorbidEntree - (Talk to me! (っ◕‿◕)っ♥)(please reply using {{ping}}) 13:14, 7 September 2016 (UTC)
WP:Perennial_proposals#It_should_be_easier_to_remove_adminship. Two months? Are you crazy? And I think you should stop doing AfD closures (e.g. WP:Articles_for_deletion/List_of_languages_by_number_of_words) until you have more experience participating in AfDs. EEng 12:55, 7 September 2016 (UTC)
The two months (and practically every number I have said) is just a placeholder number. Also, lets leave separate issues to be separate. If you have concerns with my AfD activity, then please direct them to my talk page. --MorbidEntree - (Talk to me! (っ◕‿◕)っ♥)(please reply using {{ping}}) 13:14, 7 September 2016 (UTC)
WP:NOTBURO. Others have also expressed these concerns on your talk page. It's nice that you're enthusiastic, but you're jumping on your horse and riding off in all directions. EEng 13:36, 7 September 2016 (UTC)
EEng, that's completely irrelevant to this discussion. It's incredibly surprising that you, an experienced editor, don't realize that. I'm not sure why you seem to have such a grudge against him, perhaps it's because of this? Whatever the reason, please comment on the content, not the user. This is a proposal to introduce a better way of getting admins desysopped, it's not the place to talk about MorbidEntree's AFD closures. If you want to do that, take it to your talk pages. Omni Flames (talk) 22:00, 7 September 2016 (UTC)
When a new user does something (linked by you above) suggesting poor judgment in discerning what tasks he/she is or is not ready to take on, it's normal to review their contributions to see whether there's a pattern. In this case there is, so I gave a word to the wise in passing. It's not a big deal, except that you both are making it one. EEng 23:46, 7 September 2016 (UTC)
@EEng: "a word to the wise in passing": except that's not what you've done here. You quite literally have only written 3/4 of a line in relation to what's actually being proposed here, and the rest of your participation in this discussion has been criticizing their AFD closures. Omni Flames (talk) 00:05, 8 September 2016 (UTC)
I said one sentence about it. We're alreadt at the :::::::-indent level because you keep yakking about it. Will you now make it ::::::::? EEng 00:22, 8 September 2016 (UTC)
This isn't going to happen for many reasons, most of them outlined in the perennial proposals page. If you have an issue with an admin's action(s) the proper steps are: 1) Talk with the admin on their talk page. They are human you know. Mistakes do happen. 2) Bring the action up for review at AN or ANI depending on the circumstance. 3) Bring to ArbCom as a final step. 99.9% of issues will be solved at step one. We really don't need a trial court (this isn't a place to seek justice anyways) and we really don't need reconfirmations. If there is a problematic admin they are usually taken care of. Please note though, disagreeing with an admin is not the same as a problematic admin. --Majora (talk) 20:59, 7 September 2016 (UTC)
Ideas similar to this have been rejected by the community time and time again. Though consensus can change I find it unlikely that this proposal would pass. The "every two months" requirement isn't going to work, because an admin who's doing exactly the right thing could be brought up by someone just because they don't like one of their actions, every two months. Omni Flames (talk) 00:08, 8 September 2016 (UTC)
Another problem with "two months" is that with the number of active administrators, such a process would immediately be overloaded. Jo-Jo Eumerus (talk, contributions) 15:48, 8 September 2016 (UTC)
There's quite a lot of variation in how the communities handle adminship. The German Wikipedia has a process similar to the Dutch process, although surviving one recall gives you immunity for 6 months. The Swedish Wikipedia requires all admins to stand for re-election every year (or perhaps it's every two years). It would be interesting and probably useful for someone to sort through the policies and procedures at the big wikis and post compare-and-contrast information at meta:. WhatamIdoing (talk) 12:46, 8 September 2016 (UTC)
In a very real sense, with respect to the size of admin corps, there are no other "big" Wikipedias. Compare with the other entries at the list of Wikipedias. English Wikipedia has 1294 admins. The next-largest group of admins is on dewiki (German) with 206—we outnumber them more than six to one. The Dutch and Swedish projects have 49 and 67 admins, respectively, coming in at around 5% of the size of the English project. Processes that work on vastly smaller projects (or at least which don't cause paralyzing chaos) often don't perform nearly as well when faced projects five or ten or twenty times larger. It also doesn't help that for various sociopolitical reasons that enwiki is a disproportionately large target for externally-organized manipulation and grief.
On the flip side of that coin, English Wikipedia has the longest and largest accumulated corpus of institutional experience, memory, policy, and infrastructure related to all aspects of project administration, including adminship. We had the first extant ArbCom, with the largest number of members, with the longest total time in continuous existence (four years longer than the next-oldest active Committee, on dewiki), which actually has (unfortunately) accumulated substantial experience in handling admin misconduct. TenOfAllTrades(talk) 01:50, 11 September 2016 (UTC)

I think Wikipedia's neutralist philosophy is flawed.

Wikipedia has a philosophy of reading like an encyclopedia and in an encyclopedic tone that stems from a neutral point of view. Wikipedia defines NPOV as the POV that almost everyone would have. What almost everyone can agree on; In 1889, the Coca-Cola Company, Nintendo, Adolf Hitler and Thomas Midgley Jr. were born. National Socialism is a form of fascism. Points of view held by a majority or minority would be able to be written about on Wikipedia. But Wikipedia doesn't want to write about points of view held by only a few people. That would mean that Wikipedia is too majority-centric. Biased. Wikipedia wants to be neutral. But apparently some of Wikipedia's rules make it so it isn't neutral neutral. If almost everyone agreed that Hitler was a tyrant or reliable sources say that he is a tyrant, I don't think it shouldn't have to mean that Wikipedia articles should say that Hitler is a tyrant. Wikipedia wouldn't be neutral anymore. The encyclopedia would be biased against Hitler and Nazism, when Wikipedia articles aren't supposed to hold opinions or bias at all.

  • Barack Obama made vast improvements to the United States healthcare system. For example, he signed the Affordable Care act of 2012. This made it easier for everyone to afford healthcare insurance.

This is not neutral. Some people would agree with that, but many others wouldn't. Try again.

  • Barack Obama made terrible reforms to the healthcare system, he signed the Affordable Care act of 2012. Unfortunately, the healthcare system is still expensive despite him forcing us to have insurance.

Oops. That's not neutral either. Try again.

But what if many reliable sources say that?
Wikipedia articles should just use according to lest it take a subjective opinion for a fact.
But it is fact!
Are you sure? See WP:TRUTH.
Well, what if almost everyone has that same opinion? Here.
  • Barack Obama made notable reforms to the healthcare system, he signed the Affordable Care act of 2012. Many citizens agree that the healthcare reforms were terrible.
See WP:WEASEL. You shouldn't use weasel words. Just cite sources as examples.
Aw, come on! The world is non-neutral! We are here to explain the world. Deal with it.
Too bad. I just don't think Wikipedia is neutral enough, okay?
Now here's what I'd put up:
  • Barack Obama signed the Affordable Care act of 2012. (insert names of cited sources here) state that the reforms are 'terrible'.[1][2][3]

My essay contains some examples of my editing philosophy. I'm just thinking that Wikipedia needs to be more neutral and read like an encyclopedia rather than a guide, blog, newspaper, tabloid, magazine, advertisement, editorial or instruction manual. --Turkeybutt (talk) 16:32, 27 August 2016 (UTC)

Please see WP:UNDUE/WP:BALANCE (the section the link points to, not the word "balance") and WP:CHERRYPICK (and cherrypicking) as to why we cannot write an article like that. The only way to write such text would be by selectively omitting sources which praise his reform, which is intellectually dishonest. Also, whether people agree with Wikipedia text is not a concern to us. Jo-Jo Eumerus (talk, contributions) 16:36, 27 August 2016 (UTC)
But I don't want any sources to be omitted. What made you think that my kind of edits would require sources from one side to be omitted? I don't want all the sources from one side omitted. That would make Wikipedia even less reliable. I'm suggesting a way Wikipedia can be more neutral, not less neutral.
Or we can just simply write that fragment like this:
  • In 2012, President Barack Obama signed the Affordable Care Act, nicknamed Obamacare.
— Preceding unsigned comment added by Turkeybutt JC (talk • contribs)
This thread does not seem to be about the example, but about a general trend in Wikipedia to not tske all sides. If we make this idea in extremis we would have to revise or at least discuss claims in e.g. the Pol Pot article that he was a totalitarian dictator, etc. We use mainstream agreement, even if not neutral to avoid exactly such discussions. Arnoutf (talk) 20:19, 27 August 2016 (UTC)
"I don't think it shouldn't have to mean that Wikipedia articles should say that Hitler is a tyrant" - my brain is hurting trying to work out what this sentence means. Are you saying that Wikipedia shouldn't say "Hitler was a tyrant" because it wouldn't be "neutral"? If so, I disagree. Wikipedia favours the consensus among reliable sources, it doesn't need to be even-handed between every possible viewpoint. Sure there were quite a few people who took a positive view of Hitler in the 1930s, and rather fewer who take that same view today, but neither of those facts would prevent Wikipedia from describing him as a tyrant (though, incidentally, it doesn't currently use that word to describe him).
You seem to be suggesting that Wikipedia articles should include all possible points of view. The article on Shape of the Earth should read "Most authorities describe the Earth to be an oblate spheroid, others say it is flat, whilst Sir Bedevere describes it as banana-shaped..." Doing this would apparently make Wikipedia "more neutral and read like an encyclopedia." Can you name an encyclopedia which follows the policy that you advocate? Chuntuk (talk) 12:16, 1 September 2016 (UTC)

The problem is that the world changes, people's understanding of it changes, and 'almost everybody' one day can be whittled away to 'a majority' and then 'many people', 'a few people' and then 'almost nobody'. Scientists tend to cling to their theories if they can have vested interest in them, and eventually, other scientists overthrow them. Wikipedia ought not to cling, or repress the new, because it will slow down the process of theories being overthrown; it will bolster up the old. Unfortunately, it does seem to be doing just that! Nick Barnett (talk) 15:23, 12 September 2016 (UTC)

Restrict uploads to only those that are extended confirmed

So I want to test the waters of this idea before I actually propose it. I know that this was not the original intention of 30/500 but since we have it why not use it.

Anyways, I patrol recent uploads. Every day I tag dozens of images for immediate deletion as F9 or for delayed deletion as F7 (as of this writing 164 just this month). 99% of these images are from people who are not yet extended confirmed. I understand that copyright is a complex thing and that very few people actually understand it well enough to make informed decisions as to the acceptableness of various images for upload here. However, the sheer number of problem images that are being uploaded raises serious concerns. The chance of missing a clear copyvio is high simply because of the number of images being uploaded, and that is a problem. The restriction of uploads is obviously not without precedent. Right now we only allow those that are (auto)confirmed to upload images and other projects restrict that even further to either a patrol an upload user group or to only administrators. We also have WP:Files for Upload where people who have not reached (auto)confirmed can request that uploads be done on their behalf. It is quite backlogged right now but it is being worked on.

So what are people's opinions on this? Pros? Cons? Ideas? --Majora (talk) 01:52, 8 September 2016 (UTC)

  • Yeah, definitely a waste of time, Its like every 2nd image i click on enwiki (which has been added to enwiki) is a copyvio generally added by users with less than 10 edits, we try to be a free website and we are able to get rid of copyrighted articles but images, we somewhat keep, Yes I agree, lets just remove this right for 'Confirmed' users as well, 95% of all uploads are made to commons anyways, lets make it their problem because they can better handle the issue. Not many enwikipedians are well versed in commons copyright policies..There are surely 1000's of images on enwiki that should be deleted but have not been because they are either tagged wrong or are ignored because people assume they may be free..I personally don't think people should upload NFC images if they have no idea what it means. Some other wikis now have a separate right for users that are allowed to 'upload' images to their wikis, enwiki is too big for that so I think this is the next best option--Stemoc 03:36, 8 September 2016 (UTC)
    Whoops changed the name of the usergroup on other wikis. Apparently my brain is still thinking patrol. Thanks Stemoc --Majora (talk) 03:54, 8 September 2016 (UTC)
  • This just pushes the problem off to Commons, who already get all the nonfree and vanity uploads from users who aren't autoconfirmed yet. (And that makes it a hundred times the hassle to remove them when deleting the article here.) —Cryptic 17:43, 8 September 2016 (UTC)
  • I think it's worth backing up a bit when thinking about this genuine problem.
  • First of all we need to ensure that uploads which need to happen can happen. So what are the use cases, and who needs them?
  1. Uploading non-free files like logos or film posters: editors of any experience may wish to do this, and here is the only place that can happen. If more editors were to be prevented from this, FFU and OTRS would need to be strengthened to handle the demand.
  2. Uploading free files: new users should probably be shunted to Commons more forcefully on this. Some experienced editors boycott Commons and this should be respected. Also some files which are free can be WP-specifc.
  3. Editing existing files: uploading new versions should sensibly require equal or higher permissions than new uploads, so this doesn't concern us here.
  4. Reverting file vandalism: we need to make sure that if uploading is not tightly restricted, there are enough users who can quickly undo vandalism.
  5. Spam, copyvios and out-of-scope: principally new users. Obviously this is what we're aiming to stop.
How can we implement tighter restrictions?
  1. Extended confirmed: this will cut out most miscreants, but also stops use case 1 for many. For example, a new user making an article about an album, say, couldn't upload cover art. Also users are not vetted for understanding.
  2. An uploader group: this can have separate, fine-tuned requirements. If automatically granted, a middling level could be set and upload rights could be revoked, or granted early, separately from EC. If requested, users' understanding would be tested but this would be bureaucratic and the need to prove experience at e.g. FFU would deter users who only need a small number of uploads anyway.
Personally I think EC is excessive. Also I don't think it stands a chance of passing: users who don't have experience in file maintenance will naturally lean towards the "anyone can edit" principle, as is happening at the current userspace protection RFC. Initially I am favouring an auto-granted right with middling experience requirements which can be revoked for cause without warning (since if someone demonstrates in their first uploads they don't understand copyright sufficiently, they shouldn't upload until they do, but that shouldn't stop them editing pages in the normal way). BethNaught (talk) 19:12, 8 September 2016 (UTC)
I have to ask, is there documentable evidence (say, an analysis of all uploads by new or non-extended confirmed users) that new user's uploads are a problem? If so, I'd favour an "uploader" user group but it should be clearly indicated on the Special:Upload page where to ask for an upload, not just the default "nopermission" error message (ick, is that really hardcoded?!) Jo-Jo Eumerus (talk, contributions) 19:18, 8 September 2016 (UTC)
Yes, there is. About two-thirds of the files uploaded to Commons by newbies are copyvios or have other serious flaws. ("Newbie" in that sentence means uploads made during your first few edits at Commons, even if you have thousands of edits elsewhere. I have never seen similar studies for files uploaded specifically to the English Wikipedia.)
Many of these images are probably acceptable as fair use in some articles (e.g., corporate logos and album cover art) but not free and therefore not acceptable for Commons. Many others are unlikely to be acceptable anywhere without a formal release from the photographer (e.g., professional portraits or images copied from an org's website by someone claiming to be from the organization). It does not matter what software the newbie is using. The Multimedia team ran a series of tests earlier this year, and couldn't get the numbers to budge more than a couple of percentage points. One perhaps uncharitable interpretation could be that many people are willing to tick boxes until they hit upon the magic combination that makes the upload work, and they don't really care what the boxes say: "Do you want me to say that I personally created this famous old painting? Sure, I'll agree to that, and maybe the upload will work this time."
BTW, I've been making a list of ideas that people have for improving image curation (e.g., to make reviewing someone else's uploads more efficient/easy/reliable/fun/whatever). If anyone has ideas, then please {{ping}} me. Whatamidoing (WMF) (talk) 15:08, 10 September 2016 (UTC)
Whatamidoing (WMF) I am not surprised at all - when people are asked to check off some conditions they frequently will do so irrespective of the merits - the criticism section of End-user license agreement is really telling. I'd also be interested in knowing what the quality of the average uploads of established users is. Jo-Jo Eumerus (talk, contributions) 15:15, 10 September 2016 (UTC)
There's been a little past research and some talk about doing some more. Generally, people screw up their first upload. Part of the problem is: How would you define "established user"? You will get different results for, say, "uploaded 100 images" vs "made 100 non-upload edits", even if the uploads happen on some other wiki and the edits all happen at Commons. Whatamidoing (WMF) (talk) 20:43, 10 September 2016 (UTC)
Marking "established" based on uploads would be a little silly. I consider myself to be pretty well versed enough in copyright to work in the file namespace, and on Commons, but I only have a handful of uploads to my name. The problem is that copyright is so opaque and complex that few users really understand what they are doing. I wouldn't necessarily say that people who have done 500 edits and been here for 30 days know it any better. But they do know our policies a little better and I would hope that most of them would seek assistance if they aren't sure. Brand new accounts just don't do that. They click until their file is uploaded and move on, leaving it for other people to clean up after them. This issue is complicated by fair use which is a completely different set of rules for only certain images. An uploader group is just infeasible on enwiki unless we literally had an army of people who only processed those requests. You just have to look at FFU to see how that isn't going to happen. Commons has the infrastructure to at least deal with copyvios in a much more managed way than we do. Everyone there is working on it. They have a singular goal in mind and for the most part they do alright in patrolling uploads. Here we have a handful of people who look at images. It is just overwhelming and something has to be done. --Majora (talk) 20:50, 10 September 2016 (UTC)
Well, you have to admit that if we made a rule that an editor can't do any uploads unless he's already made at least 100 uploads, that would end the problem of inappropriate uploads and so on quite effectively, wouldn't it? EEng 22:20, 10 September 2016 (UTC)
I was thinking in terms of retrospective research (see whether uploads #1, #10, and #100 have different outcomes), but you're right. Your comment reminded me of the joke that Tech Ops single-handledly stopped all vandalism for half an hour twice last April. It wouldn't do for every day, though. Whatamidoing (WMF) (talk) 08:27, 11 September 2016 (UTC)
@BethNaught: Fair use abuse is also a major problem. As stated in my opening, F9 (copyvio) and F7 (invalid fair use claim) are the top two CSD tags that I use. Very few people understand copyright. Even fewer understand fair use. I'm pretty sure that the number of people that patrol new uploads can be counted on one hand. We are just being overwhelmed with bad uploads and the risk here is actually quite high that something is going to be missed. I wouldn't have started this if I didn't really think something has to be done. I'm just not entirely sure what that "something" is yet. For non-free things perhaps there is a way to program in that if the article the uploader says they plan on using it on is also in Category:Living people to reject the upload unless it is done by someone over a certain threshold. That would stop a lot of the fair use abuse that I see. --Majora (talk) 21:11, 8 September 2016 (UTC)
  • "I know that this was not the original intention of 30/500 but since we have it why not use it." I believe I argued the slippery slope about extended confirmed at one time or another in one of the discussions about it. This is exactly why. This is the encyclopedia anyone can contribute to, hence our system is set up the way it is. A decrease in openness needs good backing. I agree with Jo-Jo Eumerus in a certain respect - that data driven evidence would need to demonstrate that there is a problem before I'd even consider supporting.— Godsy (TALKCONT) 03:03, 11 September 2016 (UTC)
    @Godsy: I believe Whatamidoing started to give that data you seek. About two-thirds of the files uploaded to Commons by newbies are copyvios or have other serious flaws. ("Newbie" in that sentence means uploads made during your first few edits at Commons, even if you have thousands of edits elsewhere). While that is talking about Commons the number can probably be said to be comparable to Enwiki. That number is probably a little lower, admittedly, as the upload wizard fills in a lot of the information for you when it comes to fair use images. I can personally tell you that there are hundreds of bad images uploaded to Enwiki every month. --Majora (talk) 03:22, 11 September 2016 (UTC)

Majora, I think that the overall feeling at Commons is different from your assessment of it. They don't have good infrastructure for what they need to do, and they're not doing well. Regardless of what raw numbers may or may not say, community growth feels like it stalled a long time ago, and may be shrinking. I get the feeling that the general level of community support, especially for patrolling new uploads, is declining, and that the remaining people are trying to hold it together under extraordinarily wearing circumstances. The people who patrol new uploads in particular seem to be burned out, to the point that many of them really would welcome a "no uploads unless you've already uploaded 100 files" rule.

BTW, in doing some of this research, we (everyone, not the WMF) learned a few things about patrolling files on Commons. The Commons' community hasn't really claimed to patrol everything uploaded by new contributors (much less everything by everyone), but one thing we learned was that copyvios were being accepted at a higher rate than Commons' own patrollers believed. A significant fraction of these were because that community had decided (not unreasonably) to ignore thousands of images that had much higher rates of copyvios than they had assumed. Without going into too much detail, if you filled out the info form with a particular (and common) combination of facts, then the patrollers accepted the file with no further questions. I think that they need more support – more technical solutions, more recruiting efforts, more resources, more everything. Whatamidoing (WMF) (talk) 08:47, 11 September 2016 (UTC)

@Whatamidoing (WMF): Well I guess I stepped into a much larger problem than I thought. But that is the point of this board isn't it? To bring ideas to the table. Perhaps a better redesigned wizard for here would help. Perhaps for fair use issues something like I mentioned above would help. Automatically veto any fair use image of a living person as those seem to be the bulk of F7 nominations that I see (that and photos of bands actually). There has to be some way to address the problem we are having here, on enwiki. We just have to find it. --Majora (talk) 18:01, 11 September 2016 (UTC)
Sadly thanks to human nature, I despair of educating uploaders. The cross-wiki upload tool has been causing quite a stink on Commons in the past months. At their demand, WMF did an AB test for the interface to add more verification questions (like did you take this photo yourself? Is it taken from a Google search?) and there was no material change in copyvio rates. People just click the buttons they need in order to upload. This is why I believe all the wizards need more traps, and prominent traps: allow users to upload copyvios and disallowed fair use, but automatically tag them for deletion. That way uploaders are more likely to admit their wrongdoing. The burden of identifying bad uploads is reduced and bad uploaders can have their privileges revoked (possibly by revoking an autogranted user group as described above). BethNaught (talk) 18:38, 11 September 2016 (UTC)
I was actually just thinking about ways to do auto tagging BethNaught. Haven't come up with a way to do copyvios but for the invalid fair use of photos of living people that is definitely doable. An if statement that incorporates the article parameter in the FUR and mw:Extension:PageInCat (which would have to be installed here) could auto tag a lot of the invalid fair use claims without anyone having to review them at all (besides the admin that ends up deleting them). --Majora (talk) 19:15, 11 September 2016 (UTC)
I think that it's probably a good idea to design from BethNaught's POV of despair. Even if you don't want to give up on human nature entirely, the result will still be more efficient. "Upload and queue for deletion" has been considered by the team. It'd be helpful to have some suggested criteria for them (to figure out which things should be queued for probable deletion). Whatamidoing (WMF) (talk) 20:40, 11 September 2016 (UTC)
@Whatamidoing (WMF): Well for fair use violations, images of living people. For copyvios, anything attributed to a social media account. Facebook, Twitter, Instagram, etc. can probably be auto tagged. Other things are a little bit trickier to have an automated process do. --Majora (talk) 20:50, 11 September 2016 (UTC)
I love the Catch-22 situation whereby "an editor can't do any uploads unless he's already made at least 100 uploads" or "no uploads unless you've already uploaded 100 files". Let's do it --Redrose64 (talk) 22:31, 11 September 2016 (UTC)

I note that the Special:Upload form does already have some auto-delete-tagging options (e.g "The copyright holder gave me permission to use this work only in Wikipedia articles"). MediaWiki:Licenses is the page that lists all items - including auto-deletion-tagged ones - on the license dropdown for the normal upload function and MediaWiki:FileUploadWizard.js and Wikipedia:File Upload Wizard contain the same thing for the upload wizard.

As for restricting the upload userright, the main concern will always be that the amount of images on Wikipedia will be reduced and that backlogs in requests will form. So a) any upload request by a non-privileged account should be automatically queued for approval (such as commons:Help:RenameLink does for file renames on Commons), b) one should consider automatically granting the userright to users with over N contributions and Y days since account creation and c) one should make "easy" upload tools for certain common usecases (e.g non-free logos in headers/infoboxes) to facilitate processing. Jo-Jo Eumerus (talk, contributions) 15:22, 12 September 2016 (UTC)

Blank Line Fix Bot

How about a bot that removes blank lines at the top of articles by stripping out extra blank lines between the infobox and the start of the lead? (Per MOS:BODY: "multiple blank lines in the edit window create too much white space in the article.") Praemonitus (talk) 19:49, 12 September 2016 (UTC)

No. --Redrose64 (talk) 22:52, 12 September 2016 (UTC)
And there I was thinking that bots are useful for saving labor. Praemonitus (talk) 21:46, 13 September 2016 (UTC)
What labor woulkd you be saving there? עוד מישהו Od Mishehu 13:50, 15 September 2016 (UTC)
The labor of correcting the layout manually.
Praemonitus, this should be on one of the WP:AWB lists, or in one of the bots that does automatic clean up work while already doing something useful (i.e., not something that only removes those blank lines). It should also remove blank lines between bullet lists. WhatamIdoing (talk) 12:12, 16 September 2016 (UTC)
Yes, I've run into numerous cases like this via the random article link, each time requiring a manual fix. Since I was repeating the same edit over and over, I thought it would be appropriate for a script to perform the task. Praemonitus (talk) 19:33, 16 September 2016 (UTC)

New Idea: Wikipedia needs a FAVORITES list that could be customized just like a Watchlist

hi. i have an idea.

  • I think we need to give users the ability to create a list of "Favorites" here at Wikipedia, i.e. a way for them to save a list of articles, pages, items, etc., which they could then check on a frequent basis. Ideally, this Favorites list would display how many edits, comments, etc have been made since the user's last visit there.
  • the reason for this is simple. currently, there is no way for users to simply keep an eye on their favorite pages other than the Watchlist, which some users may find overly complex and hard to utilize as a simple way to check their favorite pages.
  • the goal here is to encourage the average user or the less-experienced users to be more involved and take a more active voice in our Wikipedia community.

We need to make Wikipedia more user-friendly, and to make it much more easier for ordinary users to come back here, to pick their favorite places to hang out, visit, and discuss, and just for them to pick their favorite ways to become really active and involved members of our Wikipedia community.

what do you think of that? hope that sounds good. please feel free to comment. thanks!! --Sm8900 (talk) 14:03, 14 September 2016 (UTC)

I see no problem with the watchlist. Watch, or unwatch, any page while you're there, and use the "Watchlist" link on the top of the srcreen to see changes madew to pages on your watchlist. עוד מישהו Od Mishehu 13:48, 15 September 2016 (UTC)
IMHO the watchlist is more than sufficient, I honestly cannot understand how anyone could find the watchlist "complex" and "hard to utilize" ... If I can use it no problem then so can everyone else lol, –Davey2010Talk 01:06, 16 September 2016 (UTC)

We old-timers don't see any inadequacy in the watchlist, but we are not the intended target group. They might benefit from something different, and perhaps @Sm8900: can provide a few more details about the proposed improvement. Jim.henderson (talk) 01:24, 16 September 2016 (UTC)

Well, we old-timers do see some inadequacies in the watchlist, e.g., the inability to have more than one watchlist.
Sm8900's idea reminds me of the mw:Gather extension, which we old-timers rejected. It just made a simple list of articles (with a user-created, and therefore potentially inappropriate, title). WhatamIdoing (talk) 12:38, 16 September 2016 (UTC)
Oh yes, I remember that (Wikipedia:Village pump (technical)/Archive 135#Extension:Gather launching on beta); and there is also mw:Extension:Collection. --Redrose64 (talk) 22:00, 16 September 2016 (UTC)
Sounds a lot like a bookmark to me, except for that extra info. I suppose there's a natural bias against stuff like this among experienced folks. We're settled into a familiar and comfortable routine that does the job fairly well for us, and it's hard to see a whole lot of value in something new like this. And then there's the concept of feature creep. Each new feature has costs, both short term and ongoing, and it's easy to forget that. ―Mandruss ☎ 23:23, 16 September 2016 (UTC)
I think the current engineering idea is that it is more likely that we will have multiple watch lists, or buckets on top of one watchlist per user, and then you could use one for your favourites. It's been talked about a lot during hackathoe's and conferences already, but I don't think that major work has been done on it so far. phab:T3492. —TheDJ (talk • contribs) 09:18, 17 September 2016 (UTC)
  • While I don't think another watchlist of sorts is needed (which is basically what this proposal is), I support the idea of being able to further sort or search the current watchlist in some manner.— Godsy (TALKCONT) 09:26, 17 September 2016 (UTC)
guys, thanks for the replies. this would NOT be another watch list. it would be a list of favorite pages, with a single numeral next to each item to show how many changes have occurred since the user's last visit to that item. whereas the Watchlist shows each page multiple times, to reflect each individual change to that page within a certain period of time.
Yes, this would be more similar to a list of bookmarks than to the Watchlist. --Sm8900 (talk) 01:47, 18 September 2016 (UTC)
I consider that a "watchlist of sorts".— Godsy (TALKCONT) 04:08, 18 September 2016 (UTC)
Perhaps I'm too sleepy right now, but it seems much like the watchlist with Help:Watchlist#Options Expand turned off. Which, I don't remember, was that always the default, or did I turn it off ages ago? Anyway, yes, a second or third watchlist would be handy and less confusing, at least to old-timers. Heck, I know a fellow who keeps a separate (and clearly labeled) account for his smartphone with a much shorter watchlist. Jim.henderson (talk) 03:11, 18 September 2016 (UTC)

Closed random RfCs

I would like to discuss an idea for an RfC process that allows only randomly selected editors to comment and vote.

I would like to make this proposal here in the Village Pump after discussing it for a while here.

The problem is that RfCs on contested subjects usually see a pile-on of editors with agendas of an ideological nature. They self-select because they want their "Truth" to be reflected in the content, but this creates a huge sampling bias. Those people who care too much you might say, will participate too much in the RfC and will comment trying to neutralize everyone who votes against their agenda, and they will sometimes overwhelm the votes by sheer numbers. It's sort of a swarming dynamic.

Sort of like jury by peers is a closed semi-random mechanism in the justice system of some countries. In a trial, people don't just come in if they're interested in the topic of the trial. They're selected randomly, a fixed number (often 12 in the U.S.), and they are the only ones who discuss the issue.

If we could have closed RfCs that allow only those randomly selected to discuss and to vote, i think it would go a long way toward shutting down the endless gaming and vote-rigging and endless argumentation that characterizes some RfCs on controversial issues.

There would still be some sampling bias just by the nature of the population who makes up Wikipedia editors (whatever those are) but it at least wouldn't be the self-selecting bias of those who want to push for one version of content piling on endlessly.

What do you think? SageRad (talk) 21:11, 9 September 2016 (UTC)

Bad, bad, bad idea. You are advocating shutting out the editors who understand the details and nuances and history of a conflict, who have some skin in the game and understand the policies and guidelines at play, in favor of jill random editor. I could say more but I'll WP:AGF --NeilN talk to me 21:22, 9 September 2016 (UTC)
Why would assuming good faith even enter into your comment above? Please answer that as i don't understand that part of your comment. I hear you do not like the idea, but you don't really speak to the very problem that i described at some length about the fact that most people who would jump into an RfC in a controversial question often have a prejudiced (pre-decided) point of view and often too much bias, and those who are quite desirous to obtain one outcome over another can dominate the RfC dialog in often pushy ways. I'll love to hear your answer to my question about why you mention AGF here, and then look forward to the comments from other editors as well. SageRad (talk) 21:27, 9 September 2016 (UTC)
"prejudiced (pre-decided) point of view and often too much bias" = yes, they follow WP:RS, WP:FRINGE, WP:NPOV, WP:UNDUE, etc. It's easier for fringe-pushers to post shoddy sources or previously discredited points on the talk page and fool editors not experienced in the area into thinking they were okay. It's too easy for fringe-pushers to say, "hey, let's compromise and meet halfway" and get editors not invested in the topic to agree so they can just be done with something they don't really care about. I think our current RFC process has resulted in articles largely meeting our policies and guidelines so no thanks to spinning the wheel. --NeilN talk to me 21:46, 9 September 2016 (UTC)
Ok, that is your opinion, and i stridently disagree with it from my own experience. And to say that ""prejudiced (pre-decided) point of view and often too much bias" = yes, they follow WP:RS, WP:FRINGE, WP:NPOV, WP:UNDUE" is exactly the opposite of what i am saying. I am saying that the people who run to an RfC to push an agenda are doing the exact opposite of respecting NPOV, RS, and UNDUE policies. So, that may be your estimation, and mine is polarly opposite. So be it. By the way, WP:FRINGE is not policy. It's a content guideline, and i hold that it's too often misused and over-applied in a way that is harmful to the encyclopedia. It's being used too often as a tool of some of the agenda pushing that spurs my proposal here. SageRad (talk) 22:10, 9 September 2016 (UTC)
You did not answer my question about your mention of AGF in a way that seems to be a slight against my motivations here, but i am also attempting to assume good faith and not assume that this is what it was, so please answer my question as to what you meant to help me in assuming good faith and understanding what you mean. Otherwise, you're leaving the dialog incomplete with a genuine and important question hanging here. SageRad (talk) 22:12, 9 September 2016 (UTC)
Then let's not pretend this proposal is not partially or substatially coming out of your unhappiness at being topic banned from GMO articles. What you said about your fellow editors, "They also have a heavy-handed way of bullying and speaking with condescension and dripping with a nasty slimy toxicity that is holographic with the fact that they generally defend the products of the chemical industry, including chemicals which are toxic to living things. They move in groups and support one another, and having the numbers, they can knock others out, one by one, in topic bans and various other mechanisms, as well as just making editing so unpleasant that people who have other points of view simply drop out in frustration and futility. People who really want to improve articles and restore some balance and NPOV." This proposal will do nicely to knock out those still in good standing who opposed your editing, will it not? --NeilN talk to me 22:22, 9 September 2016 (UTC)

As a thought experiment, imagine if we held a trial on a controversial question, perhaps about whether a corporation is liable for harms for pollution of a river, for instance, and instead of a closed jury, the trial used a "whoever shows up can vote" method. What would happen? Wouldn't the corporation probably line up a thousand people to vote in their favor? Wouldn't a citizen's group try to line up people to vote against the corporation? Wouldn't it come down to who has the most people showing up, and not necessarily who is correct in light of the facts and the laws? Wouldn't that also depend on what resources the corporation or the citizen's group had available to hire lawyers and get bodies to show up and vote / argue for the agenda? SageRad (talk) 21:30, 9 September 2016 (UTC)

You've been here for how long and still haven't come across WP:NOTAVOTE? --NeilN talk to me 21:49, 9 September 2016 (UTC)
Exactly. An RfC is to bring in more ideas and points of view, not to substitute new ones for the ones already there. EEng 21:54, 9 September 2016 (UTC)
NeilN, why the snark? I hear snark in your tone there. If it's not then please inform me how it's not. If it is, then be civil or cease commenting to me. SageRad (talk) 22:13, 9 September 2016 (UTC)
I never said that i think an RfC is a "vote" but people to make their votes and comment along with them in RfCs. It's not a "vote" as in you count the responses and that's it. But there is an aspect similar to voting. However, i now inform you that i know that an RfC is not a vote. It is, however, to decide generally among several options in a conflict, as well as to gain new ideas and options many times. I've been around and the tone of condescension is not welcome. SageRad (talk) 22:15, 9 September 2016 (UTC)
It is, however, to decide generally among several options No, it's to find something (possibly a proposal already on the table, possibly something new) that everyone can life with. EEng 01:17, 10 September 2016 (UTC)
Then in that case your thought experiment is irrelevant. --NeilN talk to me 22:24, 9 September 2016 (UTC)

Does anyone else have thoughts on this idea, who is willing to speak respectfully and with good faith? SageRad (talk) 12:13, 10 September 2016 (UTC)

Agree with comments above: it's a very bad idea. Alexbrn (talk) 14:03, 10 September 2016 (UTC)
I think that it could work for some things (e.g., subjects that most editors understand, such as basic questions about BLPs), but that it would be difficult for others (e.g., RFCs in which subject-matter expertise is important). WhatamIdoing (talk) 15:14, 10 September 2016 (UTC)
Editors are explicitly not experts, though, right? I think the policy explicitly states this principle. Editors are not experts and nobody can even claim to be an expert to gain any advantage in any conflict over content. The sources are the experts and editors are like clerks that diligently (hopefully) report what the universe of sources say. So do you either disagree with this assessment of the policy, or can you explain how the critique that says we need experts in the subjects applies? Thanks in advance, WhatamIdoing. I appreciate the discussion. SageRad (talk) 15:43, 10 September 2016 (UTC)
Further to the above is WP:EXPERT which makes the point that Wikipedia grants no privilege or special powers to subject matter experts, nor is there any formal way of identifying who's an expert or not. And sometimes people will claim to be an expert falsely. Anyway, i think an RfC where some of the involved people write 500 word summaries that the random RfC jury could read and process would make it possible to boil down the nuances to be digested by the random jury. SageRad (talk) 16:38, 10 September 2016 (UTC)
You missed the first point of that essay: "Subject-matter experts are well-equipped to help articles achieve a truly neutral point of view by identifying gaps in articles where important ideas are not discussed, or places where ideas are over- or underemphasized, and to identify optimal and recent sources in their fields." --NeilN talk to me 19:33, 10 September 2016 (UTC)
Some RFCs require editors to know something about the subject of the article, and in other cases it's helpful (e.g., editors who have already read enough about a particular border dispute or a particular public scandal that they can easily assess the likelihood that a proposed paragraph is consistent with the overall view of mainstream reliable sources). Other RFCs require editors to know something about the subject of the relevant policies. For example, few of us are experts in Wikipedia's fair-use rules or sourcing requirements for medical claims, but you would want to prefer such experts for RFCs in which that expertise matters. WhatamIdoing (talk) 21:43, 10 September 2016 (UTC)
(edit conflict) I don't think this is a good idea per what others have previously said. Also, there are a lot of problems with the selection of random editors; what happens if you select editors who have no interest in the area, or are inactive? Enterprisey (talk!) 16:38, 10 September 2016 (UTC)
You can easily filter for activity. I suppose you would invite a lot of editors, to account for the fact that most of them won't be interested. WhatamIdoing (talk) 21:43, 10 September 2016 (UTC)
Most won't be interested is quite correct. We have a bot that invites signed up users to comment on random open RFCs. The follow up rate, from what I've seen, is pretty poor. I doubt this process gets even six new editors to participate in most RFCs. --NeilN talk to me 01:56, 11 September 2016 (UTC)
  • Dis-including all but a randomly chosen group of individuals would be against the nature of consensus, which involves "an effort to incorporate all editors' legitimate concerns." This would also encourage the selected editors to vote instead of have a consensus building discussion, as less discussion would be taking place. Major downsides regardless of what kind of discussion it is, but I'm not going to iterate every one, and this idea doesn't specify what type it would handle.— Godsy (TALKCONT) 02:44, 11 September 2016 (UTC)
  • This isn't the first time some kind of randomized jury selection for some WP process has been proposed and this one wouldn't work for the same reason past proposals wouldn't. WP isn't a job. People edit in the areas that interest them and generally won't be forced to take part in areas of no interest to them. A complex RFC requires a significant expenditure of time and effort, particularly if you are completely uninformed about the subject. To even make a worthwhile comment can require a large investment in doing your own research to familiarize yourself with the subject. If it's an active RFC you're talking about following it for up to 30 days as new sources and proposals are provided. Lastly, as Godsy points out above, the point of consensus is to incorporate all editors concerns not a random few. Capeo (talk) 15:35, 11 September 2016 (UTC)
I did search the past archives and didn't see any other proposal of this sort. Anyway, Wikipedia is not a job but that doesn't negate this idea. We have the random calls to RfCs already, and i do answer to them, like a lot of people. But there you see the people who came randomly from the bot, as well as those often very, very, very vested in one outcome who will comment copiously and try to convince everyone of their position even to the point of drenching the RfC in a sea of their own words. So, by limiting discussion and vote of the RfC to the randomly called people only, this pushiness by those with vested interests can be curbed. They can make the initial statements that form the RfC to begin with but then must sit back and let others discuss. SageRad (talk) 12:26, 16 September 2016 (UTC)
And there is a problem with "consensus" in that often there are editors who will simply not listen to evidence or reason even when it's clearly stated, and therefore you do not get "consensus" nor even a good discussion with integrity. And... another problem is when people in groups "pile on" in a gang-like way to try to create the appearance of a near-consensus, and even worse, when they go legal on their "enemies" and get others with whom they disagree topic-banned so they effectively "disappear" their enemies like some governments do. SageRad (talk) 12:28, 16 September 2016 (UTC)
You can fix the bludgeoning aspect simply by making word and dif restrictions per proposal. That would be a good idea actually. Beyond that you want people most familiar with the subject matter involved in the RFC. As to your consensus comment, you obviously think very little of editors around here. I'd venture that if they aren't convinced by the evidence then the evidence wasn't convincing. Lastly nobody gets "disappeared" around here without the consent of uninvolved editors and admins opinions.Capeo (talk) 13:20, 16 September 2016 (UTC)
  • Aside from the problem of excluding the people in a dispute from the consensus building process, I don't see how the proposal here will solve SageRad's concern. The participants in the RfC will still self-select in that the ones who are uninterested aren't likely to take part anyway. The self-selection will be less extreme, certainly, but it will still be there. And if you want any sort of useful level of participation to an RfC on any given topic, huge numbers of editors are going to have to be randomly notified that they are invited, which just seems like it is going to irritate users. Caeciliusinhorto (talk) 12:02, 17 September 2016 (UTC)

Getting to more productive discussions at AN/I using encryption

Newyorkbrad mentioned here that AN/I discussions can unfold in problematic ways due to regulars there dominating discussions who then echo each other. Simply saying that uninvolved people should not comment is not a good idea, because as he explains they can actually be constructive.

As I replied there, I think one can use encryption to deal with that problem. A clerk is then an intermediate who posts comments on AN/I on behalf of other editors. So, if an editor is accused of problematic behavior, then one has to email the AN/I clerk who will open discussion and post the description of the problem. But all subsequent comments and the reply by the accused editor are posted using RSA encryption. After a set period of time all these comments are decrypted and posted below the encrypted text allowing everyone to verify that all he emailed comments were posted and were correctly decrypted (using the public key to check that the decrypted text when encoded yields the corresponding encrypted text, the private key is not disclosed). Then the next round where people can reply will start, this will also involve emailing comments to the clerk who will post the RSA encrypted texts.

Each of the comments on round n+1 are focused on the comments posted in round n. The "me too effect" is then suppressed because you can't see the comments by your fellow editors. Personal attacks will be suppressed as the most important ingredients that lead to it are suppressed. There is no rapid fire exchange where you can become angry and in an angry mood type follow up comments making your opponent angry leading to an escalating cycle. The clerk as an intermediary will also act as a moderator who will get back to you if you want to post inflammatory texts. While the clerk will not act as a very strict moderator, so you can in principle speak your mind freely, the mere fact that comments proceed via the clerk will lead to people thinking more before posting comments. And then because of these effects cause there to be more constructive comments that then means that there is less inflammatory material to get angry about.

Encryption is not strictly necessary, of course, but it will make things a lot easier for the clerk who then doesn't have to deal with large numbers of files containing emailed AN/I texts on his/her computer for many different AN/I threads which each have a different deadline for last posts for the different rounds. The texts can all be posted almost immediately in encrypted form at AN/I. It should also be possible to do this automatically without the need for a clerk using suitable software. An Admin will then use some tool to decrypt round n allowing the discussion to move forward to round n+1. Count Iblis (talk) 18:17, 20 September 2016 (UTC)

Count Iblis (talk) 18:17, 20 September 2016 (UTC)

I love the enthusiasm, but the level of effort and procedure you're expecting the community to A) want to do and B) have the resources to be able to do means this isn't going to fly. The creation of more bureaucracy just gets in the way of what we're here to do. AN/I is called the dramaboard for a reason - and although the harassment and personal attacks which sometimes occur there are not okay, it often gets caught pretty quickly by the admins which watch there (resulting in quicker blocks for those who aren't here for the same reasons as us). I applaud you for thinking outside the box, and perhaps elements could be taken from the proposal. I would be interested in the idea of threads having to pass through an intermediary to be started for example -- samtar talk or stalk 18:25, 20 September 2016 (UTC)

Make hoax templates visible on mobile

I've just flagged an article as a possible hoax and sent it to AfD. Viewing that article in my browser, I see two prominent red boxes at the top of the article warning me about all this, {{hoax}} even having an attention-grabbing red stop sign. If I bring that same page up on a mobile device, though, I just get a small grey "Page issues" note under the heading - the same entirely ignorable note I'd get for an article with any of a hundred minor problems.

Should we make some warning templates visible to mobile users? Perhaps any that display with a red colour bar? "Hoax" and {{db-hoax}} seem like obvious ones where we're doing mobile readers a disservice by presenting a strongly-suspected or obvious hoax as if nothing is wrong with it. "Currently at AfD" might be useful to give the user a heads up that serious concerns may have been raised about whatever they're about to read. --McGeddon (talk) 15:26, 9 September 2016 (UTC)

I'm not sure that "current at AFD" means that there are serious concerns about the article's content. WP:Deletion is not clean up. "This (probably) doesn't meet our criteria for notability" doesn't mean that there's anything wrong in the article itself.
The speedy deletion and hoax templates are a different issue, IMO. There are technical ways to achieve that goal (a change in CSS class), and I'm sure that someone at WP:VPT could do that if there were a consensus in favor of it. WhatamIdoing (talk) 15:12, 10 September 2016 (UTC)
The red colour bar seemed like it might be a good benchmark - if an issue is important enough for an attention-grabbing red banner, that means it's also important enough to mention to mobile readers.
What is Wikipedia intending to communicate when an article has a large red AfD or prod template across the top - are we inviting the typical reader to join the discussion or help improve the article, or are we warning them that the article possibly shouldn't be here and that they should bear that in mind when reading on? I'd assumed it was intended as both, and mostly as the latter. --McGeddon (talk) 14:57, 12 September 2016 (UTC)
A very few tags, such as hoax and attack pages, are partly meant as warnings to readers. None of the others are – not even something like {{POV}}, and certainly not something like {{unref}} (whose message is "Hi, please click that Edit button and add some sources. Thank you!", not "Hi, we thought you might be too stupid to notice that there were no little blue numbers on this page, so we're adding this note that you're probably ignoring"). WP:No disclaimers in articles means that we don't add warn readers about the article content (unless it's incidental to another process, e.g., getting a hoax deleted or getting editors to discuss POV problems in an article). WhatamIdoing (talk) 16:52, 12 September 2016 (UTC)
Yep, I'm only considering red-border tags here - {{unref}} and {{POV}} are orange, {{hoax}} and {{prod}} and {{afd}} are all red. If red turns out to be shorthand for "warning to reader" (I'm not sure what other templates are out there), then I'll consider a pump proposal of "make red-border tags visible on mobile". If it's more nuanced then I'll consider a subset. --McGeddon (talk) 17:40, 12 September 2016 (UTC)
Iridescent did once suggest {{medref}}, {{BLP sources}} and {{hoax}}, if you want a list of "this article has a serious problem and you should be warned"-level problems. Jo-Jo Eumerus (talk, contributions) 05:56, 13 September 2016 (UTC)
And ah, looks like red just means "deletion issue" - {{hoax}} is an arbitrary exception with a recent and somewhat sketchy "ultimately it needs to be deleted" argument. I'll put something forward that suggest a few specific templates. --McGeddon (talk) 09:35, 21 September 2016 (UTC)

Ping thing

You know when you are in edit mode, there is an icon to click for inserting a ref or pic? Could we have one for inserting the ping template? Anna Frodesiak (talk) 04:36, 21 September 2016 (UTC)

@Anna Frodesiak: The thing is, there are several ways to notify a user, many templates that would fit the bill; and you don't even need to use a template, as I have just demonstrated. The essential feature is a link to a user page. --Redrose64 (talk) 08:14, 21 September 2016 (UTC)
Hi Redrose64. That's what I do. I just copy paste the [[User:Redrose64| part and then add ]] and put a "hi" in front of it. A one-click thing would be nicer. Anna Frodesiak (talk) 08:41, 21 September 2016 (UTC)
Anna Frodesiak The shortest template that I know of that will do it is {{u}}, six keystrokes plus the user name. I guess somebody could write a gadget to reduce that. --Redrose64 (talk) 09:45, 21 September 2016 (UTC)
Redrose64 Well, there's lots of space at the top of this edit mode box for a ping icon. Click it and it could give {{u}} and with a double click you could grab any username in the thread and pop it in. Frankly, I think it's about time we had an auto way to present the template, considering we use it so much. Anna Frodesiak (talk) 10:04, 21 September 2016 (UTC)
Hey Anna! This can be easily done by adding a customized button to the wikieditor toolbar (See User:NQ/anna.js) and using User:Theopolisme/Scripts/autocompleter (highly recommended for everyone, makes editing a whole lot easier!). If you replace the contents of your common.js with this (User:NQ/sandbox2.js) and then try to edit this section, you will see a 'bell' icon in the toolbar. Clicking on it will insert the {{u}} template. Start typing the username that's already been referenced on the page and press tab, autocompleter will finish the value for you, inserting it directly at the cursor position. If autocompleter happens to suggest the wrong value, use the up and down arrows to navigate through other possible completions, or hit delete to remove it. Try it and let me know. - NQ (talk) 12:31, 21 September 2016 (UTC)
Hi NQ. Okay, I replaced the content at my commons.js with User:NQ/sandbox2.js. Now how do I get User:NQ/anna.js? Thanks. :) Anna Frodesiak (talk) 22:18, 21 September 2016 (UTC)
@Anna Frodesiak: You don't need it, I already copied that code into your common.js . There should be a 'bell' icon in the toolbar now - https://i.imgur.com/Vw4P0Je.png - NQ (talk) 22:29, 21 September 2016 (UTC)
NQ Yes! It worked! A green bell is there and I did the tab thing and it worked! Thank you so much for taking the time. This will save me hours over the years. I am very grateful! You know, that bell ought to be hardwired into that toolbar. It's very useful. Thank you!! :) :) :) Anna Frodesiak (talk) 23:09, 21 September 2016 (UTC)

Ideas for improving NPP & AfC

There is now a 15,000+ backlog of new pages waiting fro review. Most of them are totally inappropriate but have already been indexed and cached by Google. After 5 years of unstructured discussion since ACTRIAL, a dedicated venue has now been created for combined discussion about NPP & AfC. A work group is being composed to develop recommendations for necessary improvements. It is 'not an RfC, it is a call for genuinely interested users who have significant experience in these areas to join a truly proactive work group. There is some reading to be done before signing up. See: Wikipedia:The future of NPP and AfC. --Kudpung กุดผึ้ง (talk) 04:47, 1 October 2016 (UTC)

Error-reporting button

Maybe we could have a sidebar button (or a more prominent button on the Main Page) directing readers to a Flow discussion page (for ease of use) to report errors? This would make it quite a bit harder for vandalism to go unnoticed for long periods of time. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 14:04, 3 October 2016 (UTC)

We kinda already have a lot of different places to report vandalism. The help desk, the teahouse, even through OTRS. And "errors" are different from "vandalism". Not really sure we need something else and I really don't think we need flow on enwiki. If you want to direct a link to a new section creation that would be much better. --Majora (talk) 23:08, 3 October 2016 (UTC)
@Majora: Yes, but it's not actually obvious that those even exist, from a reader's point of view. (I doubt most people have ever read any of the links in the left sidebar.) I suggested using Flow because it actually works like a normal discussion board and doesn't need people to understand things like signatures, indents and page links, but normal wikitext would probably be fine. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 04:10, 4 October 2016 (UTC)
See WP:Article feedback. The software had a similar purpose but ended up being withdrawn because the signal-to-noise ratio was very low: a great deal of the “feedback” was nonsense or vandalism of some kind (so had to be moderated), and few of the good-faith comments contained concrete, actionable suggestions for improving the articles where it was activated (current-events topics possibly excepted).—Odysseus1479 05:48, 4 October 2016 (UTC)
@Odysseus1479: I forgot that existed… so the WMF ended up making Flow instead. Okay then. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 15:39, 5 October 2016 (UTC)

Semi-automating article assessment

According to stats on WikiProject, ~1.7 million articles have not received a rating on the importance scale, and ~480k articles have not received a quality rating.

It seems like we already have pieces of what is needed to semi-automate this. We have the WikiProject assignment and assessment functions of AfC, and we also have the "browsing a list of articles of a certain type" function of Page Curation. Would it be that difficult to combine the features to make an "assessment curation," which would allow users to browse articles that:

  1. Don't have any WikiProjects assigned
  2. Don't have ratings on the importance scale
  3. Don't have rating on the quality scale

...and then assign them as appropriate? TimothyJosephWood 17:09, 5 October 2016 (UTC)

Perhaps relevant discussion at WT:COUNCIL#Overhaul of article assessments. --Izno (talk) 17:25, 5 October 2016 (UTC)

Bot proposal: CasualtyBot. A bot to replace the euphemisms "lives were lost" "lost X life" and "passed away" with "died"

I'm proposing about a bot to do this on articles;

  • N lives were lost --> N people died
  • no lives were lost --> no one died
  • lost his/her life --> died
  • lost their lives --> died
  • passed away --> died
  • exceptions: quotes and links

Is this a good idea? --Darth Tacker (talk) 21:36, 21 September 2016 (UTC)

Not for a fully automated bot. There are too many cases where "lives were lost" (etc) will be correct (direct quotations, the use of "lost his life" as a reference to amnesia or drug addiction rather than death, "the ball was passed away from the goal", and so on); you'd be looking at way too many false positives for a bot ever to be approved. It could possibly be done as a human WP:AWB search-and-replace run, but it would need very careful checking of every single change. As a concrete example of the scale of false positives you'd be facing, here's the first 20 hits on a search for "passed away", and 17 of those 20 would be false positives. ‑ Iridescent 21:49, 21 September 2016 (UTC)
  • I oppose making those changes systematically; whether that be manually, semi-automated, or by bot. With automation, I certainly don't think it could be easily made fully reliable, as there are many forms of quotation. Regardless of what MOS specifies for quotes, there will be many quotes which are not in line with MOS and would be extremely difficult to detect. E.g. The memorial bore the inscription: In memory of those who lost their lives in the 1897 and 1938 Martian invasions. Similarly, links come in many forms, and would be difficult to reliably detect. I also agree that there will be cases where the meaning would be changed, as above. I also just don't see the need for it. There isn't any strong MOS basis for it (is there?), all of the phrases are extremely common, well understood, free of bias or puffery, and not detrimental to article content. Where is the argument that these changes would improve the quality of the encyclopaedia? Where is the argument for why they are necessary at all? The phrases are in common use by high quality publications and respected journalists, I don't see why they need to be eradicated or even discouraged here. It seems to me that this would just be disruption for no benefit, fixing something which isn't broken. Murph9000 (talk) 22:31, 21 September 2016 (UTC)
    MOS:EUPHEMISM. BethNaught (talk) 22:34, 21 September 2016 (UTC)
    That only covers one case of the five. Murph9000 (talk) 22:42, 21 September 2016 (UTC)
    That is not meant to be an exhaustive list. The examples given there are only meant to be representative of the problem, not a complete list of the only words. It is merely illustrating the problem with euphemism in general, and not meant to be a checklist of specific words to avoid in specific situations. Euphemism is to be avoided period. Not only specific euphemism. That being said, despite your misreading of that guideline, there is no WAY that any bot should do this, nor should any user haphazardly make it their mission to cleanse Wikipedia of these phrases. If one trips over an inappropriate euphemism, fix it. But both bots and people have a bad habit of overapplying the "rules" when they make this a singular mission, and attempt to clear out all examples of this. It's a job requiring a scalpel, not an axe, and it is to be handled with care and caution. --Jayron32 22:57, 21 September 2016 (UTC)
    I do not consider the other 4 to be euphemisms. They are widely used ways of directly referring to death, and I don't consider them to soften or obfuscate the meaning. I have no issues with someone improving wording where they were in there anyway. Murph9000 (talk) 23:09, 21 September 2016 (UTC)
    Well, then, that settles it. It's a good thing that all of Wikipedia is decided by what you consider. Such a policy makes it much easier than having to consider that others may feel differently. We'll just let your consideration set all the rules then, shall we? --Jayron32 23:36, 21 September 2016 (UTC)
    That's quite uncalled for. You made an assertion, I disagreed with it, and did my best to briefly explain my reasoning. Am I compelled to feel the same way that you feel about it? Murph9000 (talk) 23:41, 21 September 2016 (UTC)
  • I think that fixing this is a good idea, but it must be done with extreme human-level judgement for each article. The fact that 18 of the first 20 "passed away" entries are false positives (I just went down the list - the only correct ones are Rabbi Isaac Elchanan Theological Seminary and Lorne Shantz) proves the point that a bot can't do it. And yes, each of these statements, when actually referring to death and not part of a quote or title, should be fixed. עוד מישהו Od Mishehu 05:33, 22 September 2016 (UTC)
    I think we just have to make sure the bot does the right things and not the wrong ones. I stand corrected when it comes to things such as "the ball passed away from the goal". But I think using 'lost his life' to refer to drug addiction would sound like a metaphor. I don't think there should be idioms or euphemisms. --Darth Tacker (talk) 11:50, 22 September 2016 (UTC)
That's correct, but there are two questions which need to be answered:
  1. What should the correct phrasing be?
  2. What should we do about articles that use the wrong phrasing?
An answer to the first question does NOT imply a specific course of action to be mandated for the second. They should all say "died", and avoid idiom, euphemism, and obfuscation as much as possible; that seems to be plain from existing MOS guidance. However, whether any person (via bot or via their own human effort) should endeavor to make a concerted campaign to root out every such instance, is a different story. Such efforts are frequently counter productive because a) they have a high incidence of false positives, even when done manually and b) they generate unneeded backlash which works to steel the resolve of people who may otherwise agree with the result, but come to fight against you because of your methods. Instead, we should merely fix the problem when we come across it during the normal course of reading and editing Wikipedia. That seems like an appropriate recommendation for the second question. --Jayron32 12:01, 22 September 2016 (UTC)
You would also need to consider the way the sentence would sound after fixing it. Consier, for example, "in which many lives were lost and people injured" (from United Nations Security Council Resolution 1611). Were you to replace this with "in which many people died and people injured", this would look very awkwrd. עוד מישהו Od Mishehu 04:17, 23 September 2016 (UTC)

Bot content with updates

User:Lsj has a bot that generates geographical articles (e.g. villages, rivers) in the Swedish and Cebuano wikis using freely available data from NASA and other sources. See the Swedish article on Abuko for an example. More information could be created by other bots on a country-by-country basis such as census information and election results. But the information will become outdated - even climate data. A way to get round the problem would be to

  • Have the bots generate skeleton articles if none exists yet
  • Have the bots generate text files attached to each article in a hidden directory, e.g. Articlename/botgenerated/climate and Articlename/botgenerated/landform
  • Create template {{botdata}} to transclude the text into the article. Thus the code {{botdata|climate}} will dynamically include the text in articlename/botgenerated/climate in the article
  • Quite small text fragments could be supported. Thus {{botdata|latest-population}} might return "27,143 (2006)<ref>....</ref>"
  • Periodically rerun the bots to create text with newer versions of the data, or more complete versions if new sources become available
  • The bots could also generate generate lists of existing articles that should be updated by a human to include the bot-generated data at the appropriate place

User:Lsj has noted concerns that were raised at the Swedish wiki, including:

  • Possible quality issues with the sources used. Source data are not perfect, and the bot may unwittingly include errors.
  • Some people question the relevance of 100,000 stubs about villages in Africa.
  • The articles are too uniform, boring to read. The "random article" function is no fun anymore.
  • The bot does a fair bit of analysis and calculations, and then translates the results into text. So the bot needs to answer the question "how flat is flat", in order to write "The terrain around X is flat." Some people argue that this violates WP:ORIGINAL, or is bad in some other way.

These are surely not show stoppers. All sources may contain errors, but the bot uses high-quality sources. Village stubs do no harm and may be useful. A hidden category "Contains bot-generated text" can be used to control how often the articles show as random articles. Calculations like {{convert}} are not a problem – as long as the raw data is reliable they should be acceptable. This seems a good way to get basic factual information into Wikipedia, updated from time to time, while allowing normal textual information to also be added to the article. It seems sort of obvious. Has this been suggested before? Is there a major problem? Comments on the general concept? Aymatth2 (talk) 15:28, 23 September 2016 (UTC)

Comments on Bot content with updates

I think such bots or mass creations in the past have resulted in problems, e.g due to concerns about the reliability of the sources used. Jo-Jo Eumerus (talk, contributions) 15:38, 23 September 2016 (UTC)
  • Obviously the sources have to be vetted carefully. The main source used by Lsj's bot is NASA, which gives elevation, vegetation type, rainfall, temperature etc. It should be as reliable as any source. For Brazil, the Brazilian Institute of Geography and Statistics publishes quite detailed information from their 10-year census, e.g. Ubatuba. That may not be 100% accurate, but is probably the best we can get. If there is a serious concern about the accuracy of a particular type of data, we can just blank all the bot-generated text files of that type, then regenerate the text when a more accurate source is found. Aymatth2 (talk) 16:14, 23 September 2016 (UTC)
They have at times, yes, but if you look at articles like Wainamah, personally I'd rather a bot created them all with consistent population and coordinate data. Especially as more come online in the next five years, making them consistent and easy to edit would be extremely important I think. Has my full support providing that it uses reliable sources and uses templates like Template:Bignona Department to organize articles.♦ Dr. Blofeld 15:53, 23 September 2016 (UTC)
I would also support an extensive nuking of most of the Brazilian municipality articles and a bot used to recreate them with proper information and sourcing. I'm sure Aymatth would too.♦ Dr. Blofeld 15:55, 23 September 2016 (UTC)

It feels to me that this concept should be done through Wikidata, which is actually designed to be a central data repository accessible to all langauge-version Wikipedias/other projects. Transcluding from template subpages is actually rather fragile, and breaks when the article is moved but not the subpages. Whereas Wikidata is based on a unique identifier (Q-number) that is independent of the page name. Whether done through template subpages or Wikidata, the issue of importing data into prose via wiki-magic would probably need to be revisited – the last discussion (that I'm aware of), Wikidata Phase 2 RFC, was closed as "not appropriate to use Wikidata in article text on English Wikipedia at this time" - Evad37 [talk] 03:04, 25 September 2016 (UTC)

  • @Evad37: The concern with page moves could be addressed by putting bot-generated text into a separate namespace, with files identified by the Q-number. For Abuko the files could be botdata:Q335811/Terrain, botdata:Q335811/Climate etc. My gut tells me that there is value in converting data to text on a periodic update cycle, rather than dynamically each time the article is viewed. Not a strong feeling though, and this is an implementation detail. I am more concerned about the broad concept at this stage. I agree that there are advantages to holding the raw data in Wikidata, and have started a parallel discussion at wikidata:wd:Project chat#Bot generated data to see if there are objections there. Aymatth2 (talk) 16:47, 25 September 2016 (UTC)
Such a proposal is not likely to get consensus here, I believe. There have been a number of issues with the reliability of Wikidata information that will generate a number of complaints. Jo-Jo Eumerus (talk, contributions) 08:40, 25 September 2016 (UTC)
  • The Wikidata Phase 2 RFC discussion was in April / May 2013, when Wikidata was still quite new. The advantage of using Wikidata is that one bot can extract data from a reliable source and store it in Wikidata, then every WP language version can use that data in their local articles. Whether or not Wikidata is used as a repository, the bot and data sources would need careful review before being approved. But see Abuko for what could be achieved. The text on the Abuko United FC and Abuko Nature Reserve is user-generated, and all the rest is bot-generated and could be bot-updated, as could data on census results, etc. We need to find how to make it work, not just say "there could be problems."Aymatth2 (talk) 13:42, 25 September 2016 (UTC)
    Well, the main problem with that is that most Wikidata is not reliably sourced. Unless you can convince them to overwrite/remove all the badly sourced content starting articles with that material is unlikely to gain support here. Jo-Jo Eumerus (talk, contributions) 14:10, 25 September 2016 (UTC)
  • That is reasonable, and I am sure the Wikidata people would not object. A cautious approach would start with existing Wikidata entries:
  1. An approved bot using an approved source like NASA would update the wikidata attributes for a Wikidata entry, recording the source
  2. A second approved bot would then generate Wikipedia text from the sourced Wikidata attributes, e.g.
    ... April is the hottest month, averaging 27 °C (81 °F), and July is the coldest month, averaging 22 °C (72 °F).[7] ...
  3. A tool would let editors review unused text and decide whether and where to embed the text in new or existing articles
  4. Steps 1 and 2 could be repeated as needed to refresh the text
I would be inclined to be bolder, like the Swedes, and let a bot automatically create a new Wikipedia article wherever there is a Wikidata article with the sourced attributes, since that would save a lot of manual effort. Perhaps that is a separate question. Aymatth2 (talk) 14:51, 25 September 2016 (UTC)
About point 1: how will the bot match the wikidata item to the database entry from NASA etc? If that can be done reliably, and without resulting in significant duplication, I'm all for letting a bot create articles as on the Swedish wikipedia. There will still be an enormous amount of work left in the bot's wake (tracking down and merging duplicate articles or wikidata items, fixing non-standard article titles etc.), but overall the labour that editors will be spared (in creating these articles) more than makes up for it. As for incorporating bot-generated data into article prose: that's good for static content but when it comes to stuff that needs to be updated, this should rather go into infoboxes and stay away from article text: the bot will fail in updating it the moment a user edits the relevant bit of the text. Uanfala (talk) 22:44, 25 September 2016 (UTC)
  • @Uanfala: In this proposal a user cannot edit the bot-generated text. Inserting {{botdata|climate}} in the text will result in a display like
Abuko has a savanna climate.[1] The average temperature is 24 °C (75 °F). April is the hottest month, averaging 27 °C (81 °F) and July is the coldest month, averaging 22 °C (72 °F).[1] Average annual rainfall is 1,148 millimetres (45.2 in). The wettest month is August, with 449 millimetres (17.7 in) of rain, and the driest month is February, with 1 millimetre (0.039 in) of rain.[2]
The botdata template displays the bot-generated text. The text cannot be directly edited. It will be updated by the bot as needed. That is the core of the proposal, which addresses the problem of automatically updating variable data like census results. Aymatth2 (talk) 23:59, 25 September 2016 (UTC)
If it can't be directly edited by users, then I don' think it has any place within article text, as that would be squarely against the spirit of wikipedia. But an infobox (or other tabular environment) could be a good place for it. Uanfala (talk) 06:38, 26 September 2016 (UTC)
  • {{botdata|climate}} could return a table, to be placed within the article text. It would still not be editable, because it could be updated by the bot any time better data became available. The data is what the meteorologists report, rightly or wrongly, so there is no reason for editors to change it. Ditto with the latest census data. It may not be accurate, but it is what the census reported, and should not be updated. I can't see any particular difference between text and table format. Abuko uses both in its bot-generated data - whatever is easiest to read. I think the real issue is having Wikipedia mirror data provided by an external source, identifying that source, and not letting editors change what the source says. Aymatth2 (talk) 12:58, 26 September 2016 (UTC)
That would be great! As long as it doesn't become part of the article prose. There is a fundamental difference between text and table format: the table is a receptacle for data (and that's where the bot is at its best), while the text can (and should) contain more varied bits of information. For example, the table can list the latest population figure for a village as well as a the change relative to the previous census, and it leaves it at that. The text, on the other hand, could further contain for example information about the cause of the increase (influx of new workers after the opening of a canning factory), or reports on the attitudes towards the trend (villagers aren't happy about their declining numbers). If we keep the data within the text and make it locked to editors, we'll be placing obstacles to the addition of that kind of further information. That's why I think it should be segregated. Uanfala (talk) 14:43, 26 September 2016 (UTC)
  • The bot would just generate chunks of text. Editors can add text before and after the bot-generated chunks. Example:

Location

Abuko is in the West Coast Division, in the western part of the country, 10 kilometres (6.2 mi) south-west of the capital city Banjul. It had 6,572 inhabitants as of 2012.[1] The area around Abuko is well-populated, with 1,056 people per square kilometer.[2] The nearest larger city is Serekunda, 4.5 kilometres (2.8 mi) north-west of Abuko.[3] The town is home to the Abuko United FC.[4]

The 259 acres (105 ha) Abuko Nature Reserve, created in 1968, lies to the south of the town. It is the most visited tourist attraction in Gambia, with over 30,000 visitors annually. It contains tropical canopy forest near the Lamin Stream, giving way to Guinean savanna further from the water. The reserve is home to many species of bird, four primates and a variety of reptiles.[5]

In this example the first four standardized sentences are generated by {{botdata|location}}. They would not fit easily into tabular format. Text starting with "The town is home to ..." is written by a human editor. The bot, or bots, can generate various chunks of text (and tables) to be inserted at appropriate points in the editor-written text and periodically updated. The trick is to make the bot-generated chunks coherent, not too small and not too large. That may take a bit of experimentation. Aymatth2 (talk) 15:55, 26 September 2016 (UTC)
It strikes me that {{botdata}} could take a parameter |format=text/table. The editor could choose the style they felt was most appropriate. In the example above, {{botdata|location|format=table}} would generate something like:

Location

Division West Coast Division[1]
Part of country Western[1]
Distance from capital (Banjul) 10 kilometres (6.2 mi)[1]
Nearest larger city (Serekunda) 4.5 kilometres (2.8 mi) northwest[3]
Inhabitants (2012) 6,572[1]
Population density 1,056 people per km2 (well-populated).[2]

The town is home to the Abuko United FC.[4]

The 259 acres (105 ha) Abuko Nature Reserve, created in 1968, lies to the south of the town. It is the most visited tourist attraction in Gambia, with over 30,000 visitors annually. It contains tropical canopy forest near the Lamin Stream, giving way to Guinean savanna further from the water. The reserve is home to many species of bird, four primates and a variety of reptiles.[5]

Another parameter could specify that the table should float to the right. From the bot's point of view, it is just putting different wrapping around the same data elements. Aymatth2 (talk) 16:42, 26 September 2016 (UTC)

@Aymatth2 and Lsj: Is the bot code public? Kaldari (talk) 07:16, 30 September 2016 (UTC)

The bot code is available at sv:Wikipedia:Projekt DotNetWikiBot Framework/Lsjbot/Make-Geonames. Not quite the latest version, I don't update it on-wiki every time I modify something. Lsj (talk) 09:09, 30 September 2016 (UTC)
@Lsj: Thanks! That's very helpful for getting a better idea of what the bot actually does. A couple questions I wasn't able to answer from looking at the code: Where does the NASA weather data come from? Is it from the HDF files at http://neo.sci.gsfc.nasa.gov/view.php?datasetId=TRMM_3B43M&year=2014, etc. or does GeoNames provide this data? Is it just using the most recent year's data or averaging over several years? One reason I'm asking is that I noticed there's a big difference between the rainfall data provided by Lsjbot and the data at weatherbase (which is based on local ground monitoring rather than satellite monitoring). For example, for the city of Spanish Lookout, weatherbase gives 1574 mm per year while Lsjbot gives 2581 mm, which is an enormous difference. Kaldari (talk) 23:20, 30 September 2016 (UTC)
The rainfall data are taken from [3], averaged over several years (2012-2015). I downloaded 48 monthly datasets and then calculated the average for each month. Those calculations were done in a separate program, not the one I linked to above. Lsj (talk) 08:21, 2 October 2016 (UTC)

Topics for creation

Draft:Topics for creation (TFC) is a proposed project to fill the gap between Requested articles and Articles for creation.

TFC assists editors in preparing a list of independent, reliable sources on a requested topic. These lists are used to determine if there is a good possibility that the topic is notable according to Wikipedia standards.

Successful TFC topics are graduated into Articles for creation, where editors can then concentrate on writing article prose.

Your ideas and comments? -- 1Wiki8........................... (talk) 12:08, 26 September 2016 (UTC)

I agree in principle, although I would like to see a detailed proposal before commenting further. Best, FoCuS contribs; talk to me! 16:46, 26 September 2016 (UTC)
I have a few opinions on this (not a detailed proposal, sorry!), but since the original thought was so broad, there are many directions we can take this in:
  • At the highest level, TFC should be an intermediate step between a topic and mainspace/AfC. This would imply some elements of RA: anyone can take a TFC list and run with it (i.e. develop an AfC draft or a mainspace article), and anyone can contribute new topics to TFC.
  • A crucial element of TFC would be experienced editors reviewing sources and topics. This makes me think of some AFC elements: any editor can contribute to an existing list, and experienced editors can verify that topics or links comply with sourcing policies.
Of course, there are issues with both RA and AFC that we want to avoid here:
  • One of RA's biggest problems is staleness; even though a tool exists to clean out RA lists, it's not really a well-maintained corner of Wikipedia.
  • Even though AFC doesn't have anywhere near the backlog RA has, there still needs to be a way to involve people in the reviewing and editing process. WikiProject notifications, maybe?
There are also structural decisions we'll have to make: when someone goes to TFC after it's created, are they going to see a large multilevel list with topics and links, or a list of subpages, or something else? How automated will it be? (I was thinking dead-link checking, at least, but maybe also automatic additions based on a topic search?) Most importantly, I think the idea is good, but it's one thing to get sources, and another thing to create an entire article from those sources. It may be scope creep, but we probably should consider to what extent we're going to oversee "finished" lists on their way to becoming articles. Enterprisey (talk!) 20:06, 26 September 2016 (UTC)
Am I misunderstanding this, or is the proposer misunderstanding Articles for creation? AfC is a channel for submitting new articles for review when the creator considers them ready. AfC is used by unregistered editors (IPs) - who can't put a new page into mainspace themselves - or by newly registered and other editors who would like someone else to review their work, or have been advised to use this route. It isn't a list of topics for which good sources exist, as suggestions for articles someone would like to write. The idea of compiling such a list may be a promising one, but the list would need to be located somewhere else: Noyster (talk), 16:56, 26 September 2016 (UTC)
Topics for creation will not replace AFC, rather it is sub-project/taskforce devoted to a specific goal: assisting editors gather reliable sources to show if a topic is notable. One could think of it as a farm system for AFC.
The idea for this project came about because of seeing so many new editors in AFC spending time working on article prose, but ignoring the sourcing requirements. TFC will aim to help editors do the required research and source gathering BEFORE they start writing article prose (and even to help editors see why writing an article on a non-notable topic is not productive) It is also hoped this will cut down on the amount of unsourced/non-notable topics flooding into AFC.
The workflow of TFC is still to be decided: most likely modeled after AFC, with the same requirements to become a TFC reviewer. -- 1Wiki8........................... (talk) 18:08, 26 September 2016 (UTC)
  • A problem with AfC is that the reviewers can be very tough on submissions. An article that could use improvement but would never be a candidate for deletion if it were created directly in mainspace ends up stuck in AfC because it has a few flaws. This is particularly off-putting to new editors, whom we badly need. Perhaps the next step after TfC has confirmed notability with available sources is to skip AfC and go direct to mainspace. Aymatth2 (talk) 20:14, 26 September 2016 (UTC)
Indeed. Going into AFC should probably be optional, for users who want a review of their article prose before moving to mainspace. -- 1Wiki8........................... (talk) 08:03, 27 September 2016 (UTC)

prelim workflow and examples

Draft:Topics for creation is now updated with more info about proposed workflow, and 2 example submissions. Very rough and preliminary, but hopefully may give folks some ideas on how we go forward. -- 1Wiki8........................... (talk) 21:13, 30 September 2016 (UTC)

  • Also see Draft:Redmon Group as an example of using this idea within existing AFC workflow. The draft is almost a year old, and has had continual issues with NPOV and referencing. The company may or may not be notable, but kinda hard to tell currently. So I stubbed the draft, and made 3 new sections to sort the references: References to show notability, References for verification, and a References for review workspace section. -- 1Wiki8........................... (talk) 12:25, 8 October 2016 (UTC)

Topics for creation

Draft:Topics for creation (TFC) is a proposed project to fill the gap between Requested articles and Articles for creation.

TFC assists editors in preparing a list of independent, reliable sources on a requested topic. These lists are used to determine if there is a good possibility that the topic is notable according to Wikipedia standards.

Successful TFC topics are graduated into Articles for creation, where editors can then concentrate on writing article prose.

Your ideas and comments? -- 1Wiki8........................... (talk) 12:08, 26 September 2016 (UTC)

I agree in principle, although I would like to see a detailed proposal before commenting further. Best, FoCuS contribs; talk to me! 16:46, 26 September 2016 (UTC)
I have a few opinions on this (not a detailed proposal, sorry!), but since the original thought was so broad, there are many directions we can take this in:
  • At the highest level, TFC should be an intermediate step between a topic and mainspace/AfC. This would imply some elements of RA: anyone can take a TFC list and run with it (i.e. develop an AfC draft or a mainspace article), and anyone can contribute new topics to TFC.
  • A crucial element of TFC would be experienced editors reviewing sources and topics. This makes me think of some AFC elements: any editor can contribute to an existing list, and experienced editors can verify that topics or links comply with sourcing policies.
Of course, there are issues with both RA and AFC that we want to avoid here:
  • One of RA's biggest problems is staleness; even though a tool exists to clean out RA lists, it's not really a well-maintained corner of Wikipedia.
  • Even though AFC doesn't have anywhere near the backlog RA has, there still needs to be a way to involve people in the reviewing and editing process. WikiProject notifications, maybe?
There are also structural decisions we'll have to make: when someone goes to TFC after it's created, are they going to see a large multilevel list with topics and links, or a list of subpages, or something else? How automated will it be? (I was thinking dead-link checking, at least, but maybe also automatic additions based on a topic search?) Most importantly, I think the idea is good, but it's one thing to get sources, and another thing to create an entire article from those sources. It may be scope creep, but we probably should consider to what extent we're going to oversee "finished" lists on their way to becoming articles. Enterprisey (talk!) 20:06, 26 September 2016 (UTC)
Am I misunderstanding this, or is the proposer misunderstanding Articles for creation? AfC is a channel for submitting new articles for review when the creator considers them ready. AfC is used by unregistered editors (IPs) - who can't put a new page into mainspace themselves - or by newly registered and other editors who would like someone else to review their work, or have been advised to use this route. It isn't a list of topics for which good sources exist, as suggestions for articles someone would like to write. The idea of compiling such a list may be a promising one, but the list would need to be located somewhere else: Noyster (talk), 16:56, 26 September 2016 (UTC)
Topics for creation will not replace AFC, rather it is sub-project/taskforce devoted to a specific goal: assisting editors gather reliable sources to show if a topic is notable. One could think of it as a farm system for AFC.
The idea for this project came about because of seeing so many new editors in AFC spending time working on article prose, but ignoring the sourcing requirements. TFC will aim to help editors do the required research and source gathering BEFORE they start writing article prose (and even to help editors see why writing an article on a non-notable topic is not productive) It is also hoped this will cut down on the amount of unsourced/non-notable topics flooding into AFC.
The workflow of TFC is still to be decided: most likely modeled after AFC, with the same requirements to become a TFC reviewer. -- 1Wiki8........................... (talk) 18:08, 26 September 2016 (UTC)
  • A problem with AfC is that the reviewers can be very tough on submissions. An article that could use improvement but would never be a candidate for deletion if it were created directly in mainspace ends up stuck in AfC because it has a few flaws. This is particularly off-putting to new editors, whom we badly need. Perhaps the next step after TfC has confirmed notability with available sources is to skip AfC and go direct to mainspace. Aymatth2 (talk) 20:14, 26 September 2016 (UTC)
Indeed. Going into AFC should probably be optional, for users who want a review of their article prose before moving to mainspace. -- 1Wiki8........................... (talk) 08:03, 27 September 2016 (UTC)

prelim workflow and examples

Draft:Topics for creation is now updated with more info about proposed workflow, and 2 example submissions. Very rough and preliminary, but hopefully may give folks some ideas on how we go forward. -- 1Wiki8........................... (talk) 21:13, 30 September 2016 (UTC)

  • Also see Draft:Redmon Group as an example of using this idea within existing AFC workflow. The draft is almost a year old, and has had continual issues with NPOV and referencing. The company may or may not be notable, but kinda hard to tell currently. So I stubbed the draft, and made 3 new sections to sort the references: References to show notability, References for verification, and a References for review workspace section. -- 1Wiki8........................... (talk) 12:25, 8 October 2016 (UTC)

Deferred changes

Deferred changes is a way to defer for review edits identified as suspicious by some automated process. I plan on launching an RFC on its implementation. Do you have any suggestions or comments beforehand ? Cenarium (talk) 18:08, 12 October 2016 (UTC)

I've launched the RFC. Cenarium (talk) 09:43, 14 October 2016 (UTC)

Wikipedia should have a small image, icon or symbol to represent every page.

Wikipedia has a symbol directly above its title. Why is the Wikipedia logo (the puzzle planet with the omega sign) above the Wikipedia title? Because it looks good and is easily remembered. Ever been to a site called KnowYourMeme.com? It's a wikipedia but for internet culture and every single one of their roughly 20,000 entries has some kind of image or symbol. Why? Because it looks good and properly represents each page quickly through a single eye-catching easily understood visual.

Simply adding an image to the left of every site header could be quickly done and make the site instantly more enjoyable to look at and make every entry that much more memorable and recognizable. The height and width of the image should both be equal to the height of a page's header font. — Preceding unsigned comment added by Epyc Wyn (talk • contribs) 01:45, 9 October 2016 (UTC)

Do you appreciate how much work you're talking about? (KnowYourMeme has 20,000 pages; Wikipedia has 62,135,645.) I take it you're not volunteering to do this task yourself, which would literally take years to implement and have no obvious benefit. (The first three pages Special:Random brings up are Tumàka't Contemporary Dance, James Burrow and Comparison of MIDI editors and sequencers; what would you suggest would be the appropriate identifying image for any of those?) ‑ Iridescent 13:22, 9 October 2016 (UTC)
@Iridescent: Doesn't the software already select an image from the article to represent each mainspace page (which is displayed at the top of the page in the mobile app)? WMF could potentially decide it's a good idea to take that from the app into the website (it's already in Hovercards). It's not really ideal right now, though, because it tends to select random pictures if the main image is fair use. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:44, 9 October 2016 (UTC)
@Iridescent:5,000,000 pages exist (for the English version) and I suspect some day there will be 5,000,000 more. It'd be good to start now so the work load does not double. Although unlike most edits on Wikipedia, it would not be tedious to quickly go to a page, add a symbolic image/photo, and be on your way. But further let's not overthink things -most pages on Wikipedia are not particularly popular. I would recommend starting with all the portals and most popular pages, and then once those are done gradually working our way down to the less popular pages since those are naturally less viewed. It would not be done in a day but the pages we already have were not made in a day. That being said, it's not difficult on an individual scale of a few people adding one image to say the first 1,000 most-visited pages on Wikipedia and is again far easier and more enjoyable than other edits one has to make on Wikipedia. I believe the extra effort would go a long way looks-wise and encourage more users to go to Wikipedia if such a memorable visually-pleasing simple feature was added.Epyc Wyn (talk) 14:53, 9 October 2016 (UTC)
Many of the most viewed articles already display an infobox in the upper right. WP:Infobox and its talk page archives might be a good start point. — Neonorange (talk) 23:44, 9 October 2016 (UTC)

We already have d:Property:P18. --167.58.75.181 (talk) 18:48, 14 October 2016 (UTC)

Use of colon ":" for indenting comments in discussions should be deprecated and the use of star "*" encouraged

The colon ":" is currently in widespread use to indent comments on Talk pages, and its use is introduced in the Wikipedia Tutorial and is also described in Using Talk Pages, in the Talk Page Guidelines # Layout, and in Indentation. However, this use should be deprecated as it actually introduces the definition half (dd) of an association list item (dl). It is therefore bad HTML practice to use it in this way, because the term half (dt) is left off. In addition, discussions aren’t association lists at all, so their structural meaning is incorrect, which can mislead users of screen readers. This is also noted in the Manual of Style, where it states that “This is not ideal for accessibility nor semantics, but is currently in wide practice.”

All of the above pages also mention the use of bullet points introduced with star "*" as an alternative to colon ":", and a couple mention that star "*" is also in standard use on some pages. Since comments are, in fact, lists of comments, this seems a semantically appropriate structure to use, and the bullets also more clearly mark the beginning of a new comment (a common issue on talk pages, even with indents). It is also somewhat confusing to have two different standards in use.

I therefore propose a policy that the use of colon ":" for indenting comments in discussions be deprecated and the use of star "*" encouraged. This would not forbid the use of colon ":" but would provide a gentle nudge for the use of star "*" to percolate through the community, both with new users but also with experienced users who can be pointed to this best practice. — Andy Anderson 19:12, 11 October 2016 (UTC)

This sounds like an attempt to patch a technical problem using a social fix. The Mediawiki software should be corrected to generate properly formatted HTML, rather than relying on individual editors to learn a particular non-obvious coding convention.
The reason why editors (often) prefer to use colons to indent discussions is because every set of asterisks introduces new bullet point to the left, even where one would be inappropriate or unhelpful. For instance, I've used colons to indent these comments because if I used asterisks then each paragraph of my response (I'm up to two so far) would have a bullet, which would be nonsensical. The appearance would be even more bizarre and less comprehensible if I were to perform another common formatting task, which is to indent a block quote within my post.
It's possible to work around the first problem by using a <br> tag between paragraphs, but only at the cost of making the wikicode less readable to other editors. (Also, I suspect that it reintroduces semantic weirdness that screen readers might have trouble parsing, bringing us back to the same problem.) I'm not aware of any obvious fix that makes indented block quotes work properly—certainly nothing that would be easily comprehensible to subsequent editors of the page. TenOfAllTrades(talk) 20:01, 11 October 2016 (UTC)
You may be right that it’s a technical problem, but if so it is an existing technical problem that is already (in some places) being patched by a social fix, viz. the colon ”:”. In other places it is working properly with the star ”*”, and this proposal is about guiding the first group into the second group. I do know what you mean about bullets showing up in second and subsequent paragraphs, but I’ll note that this paragraph, indented at the same level as yours, does not clearly appear to be from a different writer, so that’s a different problem associated with ”:” that would go away using bullets and line breaks. It would be nice if Mediawiki had an easier way to insert line breaks, e.g. a \ at the end of line. But for now the Mediawiki Formatting page specifically mentions using <br> within bulleted lists which is not a workaround but a standard HTML practice and a lesser semantic issue (this page also notes the accessibility issues associated with indenting with colons ”:”).— Andy Anderson 03:58, 12 October 2016 (UTC)
I don't think this is a good idea; in fact, I remember a few previous proposals to deprecate the star and encourage the colon. While discussion on this topic hasn't yet reached holy-war intensity, I don't think we should make a binding rule one way or the other. Enterprisey (talk!) 22:03, 11 October 2016 (UTC)
  • Remember, in the Village Pump (idea lab) “Rather than merely stating support or opposition to an idea, try to be creative and positive.” Also please look again at what I’m suggesting, it’s not a binding rule but an educational process. — Andy Anderson 04:04, 12 October 2016 (UTC)
Whatever the desired visual appearance (bullets or not), accessibilty is important. Both colons and bullets produce lists; multiple colons or bullets produce nested lists. The same thing happens with a combination of bullets and colons, but in this case, a list of one type is nested inside a list of another type, and the order of the initial characters is important as it affects the nesting order. Let's assume that there are no blank lines (putting blank lines between posts is against WP:INDENTGAP), this will simplify my description.
Consider a discussion like this: 
Initial post
:First reply
::Response to first reply
:Second reply
This is valid nesting, as it's all colons - the semantic effect is of a single two-item list, and inside the first item is a single one-item list. Similarly, 
Initial post
*First reply
**Response to first reply
*Second reply
is also valid nesting (although visually different because of the bullets). What I have seen some people do is 
Initial post
*First reply
:*Response to first reply
*Second reply
but this is not valid nesting as we now have three one-item lists, inside the second of these is a single one-item list. Exchanging the two initial characters of the third line gives 
Initial post
*First reply
*:Response to first reply
*Second reply
and it's now valid nesting because we're back to a single two-item list, and inside the first item is a single one-item list. --Redrose64 (talk) 08:43, 12 October 2016 (UTC)
Bullets are more easily broken:
Initial post

*First reply

**Response to first reply

*Second reply
Results in:

Initial post

  • First reply
    • Response to first reply
  • Second reply
Wheareas colons:
Initial post

:First reply

::Response to first reply

:Second reply
Results in:

Initial post

First reply
Response to first reply
Second reply
Colons are harder to break. Therefore, I'd oppose such a change. I've seen editors become confused over a lot of things in my relatively short tenure here, but I've never seen anyone confuse a discussion for an association list.— Godsy (TALKCONT) 09:02, 12 October 2016 (UTC)
Colons are just as easy to break, if not easier: the breakage is still there, it's just not obvious to a sighted person. This is what WP:INDENTGAP is all about. It's also why I stated "let's assume that there are no blank lines", since I didn't want to complicate my point that :* has a different effect compared to *: --Redrose64 (talk) 09:21, 12 October 2016 (UTC)
Break as in break the visual appearance, which is what my comment concerns.— Godsy (TALKCONT) 09:56, 12 October 2016 (UTC)
  • I’ve seen colon-based discussions broken on numerous occasions, where editors don’t realize that the new paragraphs they’ve started need the same number of colons as their previous paragraph, and it can then become very hard to tell who’s writing what (that’s actually what prompted this suggestion of mine). The visibility of bullets actually help an editor see that what they’ve written doesn’t line up and I think they are more likely to fix it. Also importantly, behind the scenes the extra wiki blank lines are forcing the creation of new groups of list items, rather than simply a new list item, which reduces comprehensibility for accessibility purposes (be aware that screen readers are describing the underlying structure, not simply the visual appearance). Those extra wiki blank lines should therefore be avoided no matter what kind of list you are using, and the documents I reference in the proposal also make this point. — Andy Anderson 12:13, 12 October 2016 (UTC)
Talk page discussions are meant to be readable text for humans, not html or any other computer code. We need to consider how such a change would affect screen reader users per WP:Accessibility. Having "technically correct" html formatting that makes it impossible/difficult for a significant proportion of users to access the content is a nett negative and should not be supported. Roger (Dodger67) (talk) 12:18, 12 October 2016 (UTC)
  • The main thing is that is should be fairly clear when a new person starts adding to the conversation. I tend to use an asterisk to start my comment, but when I have a lot to say, or two different points that other editors may choose to respond to separately, I use colons to start new paragraphs at the same level. I think "to bullet or not to bullet" has been discussed endlessly, and always ended with "no consensus - whatever you like."
Out of curiosity, I checked what the W3C markup validator thought about this page. It threw up a whole lot of errors, almost all "Element dl is missing a required child element." A major site like Wikipedia should presumably have fully-valid HTML. Perhaps the code that converts wiki mark-up into HTML could be adjusted so that if a colon is not preceded by a semi-colon it is considered an indented paragraph rather than list item definition. Aymatth2 (talk) 16:01, 12 October 2016 (UTC)
  • Thanks for checking that, I thought that would probably be the case. Good idea about changing the meaning of a standalone colon, though I would change it to an unordered list item that is missing bullets, e.g. ul li.discuss { list-style-type: none; }, the indenting will follow naturally from that. — Andy Anderson 18:31, 12 October 2016 (UTC)
Replying to all the "fix the wiki software" persons above: There is basically 0 chance that you will get a technical fix for what really is a user problem, not a software problem. Why? Enough WMF engineers don't agree with changing the software (or do agree but have it in mind to make an actual fix, which is to dump wikitext conversation c.f. WP:Flow). So you need to find a poor soul willing to make a change. Then you face the issue of forcing his change into not one but two pieces of software (Parsoid as well as the Mediawiki-standard parser). And then you're back at the first problem: no WMF engineer is going to approve that change. There is presently a Phabricator task for this change lying around, but I have exactly 0 expectation it won't eventually be closed as "Resolved Invalid". --Izno (talk) 16:15, 12 October 2016 (UTC)
  • @Izno: I do not follow that logic. Users mark up discussions like this with colons and asterisks, and it works quite well for them. They have no alternative, but I do not think they have a problem. They get the effect they want. The software generates poor HTML from the mark-up. That seems like a bug to me. User mark-up should never be translated into invalid HTML. It is not a bug that causes any great problem, but it makes the site look a bit amateurish. Aymatth2 (talk) 18:27, 12 October 2016 (UTC)
    Yes, wiki-editors clearly do not have a problem using list markup. However, it is not a bug to say that the system is generating consistent HTML (by design). Whether that HTML is poor is up to where it is being used. The users are clearly the ones using it in such a manner, so then they are using it incorrectly (here is why it is a social problem). As for an amateur site, what makes it look like an amateur site is resorting to list markup to have a discussion, something never intended for that markup. The proper fix for that problem is to use discussion markup instead, not to insert a hack to turn list markup into discussion markup. And that's what WP:Flow does, regardless of any of its other (de)merits. --Izno (talk) 19:02, 12 October 2016 (UTC)
    • I do not buy that. First, software that converts marked-up text into HTML should generate W3C valid HTML from any input text, whatever the mark-up. We cannot say that it is no problem if the developers have deliberately chosen to sometimes generate invalid HTML. That would be called a "known bug". Second, WP:Flow is not available on talk pages like this. The editors are not at fault because they are failing to use a non-existent feature. Aymatth2 (talk) 22:03, 12 October 2016 (UTC)
  • WP:Flow is not going to replace Talk pages; the project page says “As of October 2015, Flow is not in active development, following a decision by the Collaboration team to focus on developing workflow systems.” More importantly, “[A]rticle and project talk pages are used for a number of important and complex processes that those tools aren't able to handle, making Flow unsuitable for deployment on those kinds of pages.” — Andy Anderson 22:44, 12 October 2016 (UTC)
So the argument is basically "change everything you've done for a decade because, even though it's not actually impacting useability, you're doing it wrong"? Yeah, no. Overbearing solution proposed for a non-problem. I agree with others. If your issue is that wikicode is not being properly translated to html, fix the translation. Resolute 02:49, 13 October 2016 (UTC)
  • No, that’s not the argument, because it *is* impacting usability. For the visually impaired, the content described by their screen readers is hard to understand because colons don’t produce the right kind of list and because what they do produce is improper HTML. For the sighted it can be hard to tell when comments switch from one person to the next; see, for example, the first set of five indented comments above, which are from three different people — bullets would make them easily distinguishable. Do you really think that encouraging people to use star and discouraging the use of colon is overbearing? That’s all this proposal is saying. And I do believe people can change, even 10 years of habit. — Andy Anderson 03:34, 13 October 2016 (UTC)
Oppose on many grounds. Look at this from the point of view of the trainer attempting to bring a group of Graduate level newbies up to speed. You are now going to give them extra rule- To indent on an article you use colon *, but on the talk page you use star. If you are cutting a pasting some text from the article onto the talk- remember to change your colons into stars.
Now, at Wikipedia:GLAM/British Library/British wildlife edit-a-thon 2016 our students were editing on 60+ Wikipedias. So it is highly likely, if (en-talk) changes that 59 talkpages will continue to use the old convention. So then we have to have a list of which convention they use on each. Has anyone consulted (de) (fr) who are fairly independent? What happens on (commons) or Template: talk pages?
'*(You can tell me to use -blockquote- but not them: that is not what newbies do when entering their first material) --ClemRutter (talk) 10:15, 13 October 2016 (UTC)
  • The colon shouldn’t be used in articles, either, except to introduce an association list (and the docs I reference above don’t mention its use there, only in Talk pages). That’s even worse for accessibility because it’s not just the initiated who see it, it will make it hard to read Wikipedia in general and for a much larger audience. If you actually want to introduce a quote in the form of a block quote, then you should use <blockquote>; introducing a bit of HTML to your students is probably a good idea in any case, IMHO — it has lots of uses. Is there another reason to be indenting? — Andy Anderson 11:39, 13 October 2016 (UTC)
    You have a totally different approach as witnessed by your idea introducing a bit of HTML to your students is probably a good idea in any case. Why? The priority is to keep it simple and to reduce to the minimum the new concepts we introduce. Yes keep it writer friendly. A gentleman who has just donated a world important collection of bird songs to a national museum with whom we have a partnership, wants to add them to multiple pages: he just wants to copy and paste notes from one of his PhD source texts and get the job done. We can get a bot to do MOS later- as a trainer I need to keep him motivated till the session is over and transclude his knowledge before he gives up. Loss of short term memory is an effect of ageing. In reality you show them how to achieve the indention effect with colons- then two lessons down the line show them copyediting techniques and show them how to (eliminate them) make the articles consistent. Consistency with talk page is important too.ClemRutter (talk) 15:13, 13 October 2016 (UTC)

What I am missing here is that even more so than in article space, talk space should not only be reader friendly it should also be writer friendly. And since Wikipedia claims to be an encyclopedia that everyone can edit, it should be writer friendly for even those who know nothing about html or any other computer coding convention. If there is a major problem (and it seems people manage to work around it rather well - so I doubt it) we should not aim for a project wide social solution, at least not without a technical solution. (btw bulleted lists are relatively well-behaved compared to numbered lists as you can skip a blank line easily as reader, but resetting the numbering is always problematic.) Arnoutf (talk) 14:45, 13 October 2016 (UTC)

you can skip a blank line easily as reader - but not if you're using a screen reader, which is why we have the advice at WP:LISTGAP. It's just as problematical for a blind person hearing multiple levels of lists being reset as it is for a sighted person seeing a number list reset.
As for the original proposal, I oppose it for one simple reason: when commenting I quite often need to use bulleted lists as part of my comment to explain something. It simply causes confusion if the comment itself is part of a bulleted list, so I much prefer to use colons and rely on indentation to distinguish replies from other editors. (It helps if you have .ns-talk .mw-body-content dd {margin-top:0.4em; margin-bottom:0.4em;} in your custom CSS to give each paragraph a little more vertical spacing.) We should encourage use of colon and deprecate the use of star. --RexxS (talk) 15:34, 13 October 2016 (UTC)
There's been a proposal to either make the parsers magically know that only a visual effect is wanted, or to produce a separate bit of wikitext markup that actually means "visually indent for those who are sighted, but don't screw up the page for people who use NVDA and other screen readers" for years. Phab:T6521 is probably the oldest and most central task. Whatamidoing (WMF) (talk) 17:45, 19 October 2016 (UTC)
@WAID: Thing is, it's not rocket science. All it needs is for the parser to detect content on a talk page (which is already marked-up with the class="ns-talk"), then instead of the <dl>...</dl>, emit a <div>...</div> that has margin-left set so that it results in 2em multiplied by the number of colons, relative to the content's left edge. Finally, use <p>...</p> instead of <dd>...</dd> and Bob's your parent's sibling. I'm sure it wouldn't be perfect, but by setting the indent via CSS (and only when the number of colons changes), you get away from using lists to make indents, and that yields valid html and screen-reader transparency. Somehow I doubt that developers will want a cheap solution like that. --RexxS (talk) 19:17, 19 October 2016 (UTC)
See, that's what we're looking for. A screen-reader-compatible solution that doesn't
  • require thousands of editors to change their behavior and learn the subtle and arcane HTML implications of familiar and simple syntax, or
  • break the formatting on millions of extant talk pages.
Definitely won't happen, then. Incidentally, would such a solution tolerate a ":::::*" like I've used to start off the bullets above? Or even a "::::*::", which might show up if there are indented remarks under a bullet point? (Call them "complex" indents.) TenOfAllTrades(talk) 19:44, 19 October 2016 (UTC)
(side note: this very discussion had some use of * followed by :: Pppery 00:01, 22 October 2016 (UTC)
@TenOfAllTrades: A simple implementation, such as I suggested, would tolerate :::::* because that would just be an unordered list inside a <div>...</div> - just as it is presently an unordered list inside nested <dd>...</dd> tags. Sadly, I don't think it's at all easy to try programmatically to make sense of ::::*::, but then again, I'm not sure anybody would need to add indented comments inside a bullet point if they were to stick to colons for comments and bullet points for genuine lists within comments. Which is, of course, the main reason I'm not keen to see bullet points used simply to introduce comments. If anyone has that much difficulty spotting where a new comment starts, then using the French talk page styling, or just setting a faint border-bottom to each <dl>...</dl> using CSS are viable solutions. --RexxS (talk) 00:25, 22 October 2016 (UTC)

Comprehension questions made easy

Maybe it's against the spirit of Wikipedia, but as a regular user I often would like to be able to ask comprehension questions concerning an article. I'd imagine these questions to be treated as hints to the author(s) how to improve the article. Alternatively, there may be given answers to the OP without changing the article.

The asking of such questions should be made very easy, especially should take place in a very simple WYSIWYG environment, not in the rather distracting environment of the talk page with lots of auto-generated content (concerning the status of the article) and where it is necessary to enter the edit mode in a second step where you are forced to use markup language.

There should be a rather strict separation of "talk about article" and "ask a question about the article", specifically: there should be a third tab next to "Article" and "Talk", labelled "Ask".

Answers may be given and discussions may take place on the questions page. But it has be made clear to the user that he/she must not expect an immediate answer. It is probably just his/her voluntary contribution to the improvement of Wikipedia.

The big question is of course: Will the question pages be misused or used too often to be of any help. There will be questions because the reader was too lazy to read carefully or to think by himself/herself, there will be plain spam, and only some of the questions may potentially lead to a real improvement of the article. Is this why the "Ask"-feature has not been considered by now? Marble machine (talk) 07:49, 25 October 2016 (UTC)

You may want to read the history of the Article Feedback Tool fiasco, which sounds fairly similar to what you're proposing—it was shut down after it was calculated that only 12% of the comments made were useful, while moderating it created a huge workload for little benefit. Remember, adding a third tab to every article will instantly create 6,930,027 new pages, all of which will have to be monitored for vandalism and libel, since at least some of the questions will be along "why don't we mention that he strangles kittens?" lines. We already have Wikipedia:Reference desk for people who want to ask questions that don't relate to improving a given article, and if you watchlist the reference desks or look at their histories you'll see that even preventing eight pages of user questions from descending into chaos is a struggle, let alone five million. ‑ Iridescent 08:20, 25 October 2016 (UTC)
This is what I was afraid of. Thanks anyhow, Iridescent, for the link to the Article Feedback Tool, which I was not aware of. I'll read this report carefully. So, finally, you suggest to ask "serious" comprehension questions on the talk page? Marble machine (talk) 08:45, 25 October 2016 (UTC)
If there's some way in which the article lacks clarity, then it seems to me that the talk page is the place to raise that issue. That's what I do anyway. Perhaps you could give some examples of the "comprehension questions" that you have in mind? Chuntuk (talk) 10:10, 25 October 2016 (UTC)
In fairness, some of the high-traffic articles do have a This is the talk page for discussing improvements to the articlename article. This is not a forum for general discussion of the article's subject. template at the top of their talkpage—the intention of this is to prevent Talk:Horse degenerating into hundreds of people chatting about their pet ponies and so on, but I can see how someone with a legitimate question about the topic might find that off-putting. You and I know that "this isn't explained clearly in the article, what's the correct answer" does fall under "improvement to the article" as it's pointing out something which needs rewriting, but that isn't particularly obvious to readers. ‑ Iridescent 15:44, 25 October 2016 (UTC)
We should probably reword that header to "discussing the article, especially improvements to it". This would clearly include "this section isn't clear - can someone please help me understand it", as this section is clearly part of the article. עוד מישהו Od Mishehu 09:58, 26 October 2016 (UTC)

Template vandalism

Template vandalism remains a significant issue, we had one that made news recently, see this for another example. Edit filters have proven to be insufficient on this kind of vandalism: even though we have some specifically tailored to counter these, they can be evaded or the condition limit reached. Semi-protection and template-protection is only applied to the most high risk, but as demonstrated by the recent attacks, substantial damage can be done by targeting templates transcluded in high profile pages. Now all templates transcluded in Hillary Clinton have been template-protected, which represents a significant barrier to editing. Do you have any ideas of how to mitigate this problem, short of mass protection? A proposal for large scale use of pending changes was rejected in 2013. The technical limitations are still there (phab:T61102), but the persistence of the issue despite traditional measures may suggest it's time to revisit this. Cenarium (talk) 23:02, 25 October 2016 (UTC)

Protecting templates isn't a huge barrier to editing, since the users who know enough to edit them are the users who are already familiar with Wikipedia. If you're worried about the work necessary in mass protection of templates, there's always the option of cloning a high-profile page and cascade-protecting the copy. עוד מישהו Od Mishehu 02:57, 26 October 2016 (UTC)
Not even template editors could edit it then. IMO, it's just too restrictive, there are still lots of IPs, and unconfirmed users, editing templates. Those familiar with WP aren't necessarily autoconfirmed. I just think it's sad to lock down so many templates just because of this kind of vandalism, that we could handle with pending changes, if only the bug was fixed. Cenarium (talk) 12:56, 26 October 2016 (UTC)
The solution is surely to educate editors into using the template sandbox in the first instance, even for admins and template editors. There is very little disadvantage in trying out edits to templates in a sandbox before asking for them to be implemented (or implementing them oneself, when possible). And there's the huge advantage of insulating high-profile pages from indirect vandalism – as well as honest mistakes – through template protection. It also often means another pair of experienced eyes will check the request before it gets implemented. --RexxS (talk) 18:51, 26 October 2016 (UTC)
This only applies to complex, very heavily transcluded or "meta" templates. The majority of templates, like Navboxes and such, are relatively easy to edit, they just need a preview before an edit to ensure a proper final result. In practice also, if users are asked to edit a sandbox for every template used in a couple of important article, or to show technical skills upfront, then this will drastically reduce the number of edits, especially by the non-technically minded, to the detriment of overall quality. Cenarium (talk) 21:47, 27 October 2016 (UTC)
If pending changes protection worked for templates, this would be a good idea. Under the current protection system - and even without protection - it is hugely impractical. Jo-Jo Eumerus (talk, contributions) 21:55, 27 October 2016 (UTC)

I've drafted an RFC at User:Cenarium/Template PC RFC to see if there's consensus for extending PC1 there, or for a PC3, that would be restricted to template editors. PC1 would be only for non-complex medium-risk templates, while PC3 for medium-to-high risk, complex templates and modules too, but neither for high risk templates or modules. Cenarium (talk) 00:46, 31 October 2016 (UTC)

What is the relationship between PC3 and template protection? Because having both seems slightly overkill to me. Jo-Jo Eumerus (talk, contributions) 06:51, 31 October 2016 (UTC)
It appears that PC3 is to TPROT as PC1 is to semiprot (autoconfirmed prot). It allows non-TEs to edit, but edits would need review by a TE-reviewer. — Andy W. (talk) 17:33, 31 October 2016 (UTC)
And much like PC1 is not appropriate at times compared to semi-protection, PC3 would sometimes not be appropriate. Template protection would be for truly high risk templates or modules, these with say tens of thousands of transclusions or more. I don't think we should decrease the protection level from template protection to PC3 for those. Most of the edits to those templates/modules should be discussed beforehand, and have first been tested, etc. Template editors would probably be understandably fearful of approving untested or undiscussed edits, resulting in backlogs and unnecessary edit/revert cycles. Cenarium (talk) 22:29, 31 October 2016 (UTC)
@Cenarium: Huh. I was assuming that PC3 means that edits must be approved by a template editor (or admin) at all times. Jo-Jo Eumerus (talk, contributions) 16:19, 1 November 2016 (UTC)
@Jo-Jo Eumerus: They must be, unless done by a template editor or admin. Cenarium (talk) 21:20, 1 November 2016 (UTC)
Then I don't understand why you are drawing a difference between PC3 and template protection. See, the idea I had is to replace template protection with a pending changes setting where nobody has their edits automatically accepted. This way, template editors and administrators could perform bold edits but leave the approval/review to another set of eyes. Or use the template as a sandbox, with revisions being approved once they are ready. And people who don't have the privileges don't have to head to the talk page to ask for an edit. Jo-Jo Eumerus (talk, contributions) 21:25, 1 November 2016 (UTC)
@Jo-Jo Eumerus: Redacted self earlier, sorry, misunderstood To my knowledge, there's no peer edit review system that mandates that every edit must be reviewed by separate distinct editor to go live. I personally can't imagine this "self-templateeditor/admin review" system to be necessary, unless it's deemed that after these episodes of template vandalism by new accounts, edits by TEs/admins need review. If we're discussing opening up templates for sandbox editing, PC3+semi is probably closer to what you're looking for; folks can edit the template, but the change does not appears until reviewed by a TE or admin. — Andy W. (talk) 23:26, 1 November 2016 (UTC)
There's a difference, it would be much easier to submit an edit and get approval on a template under PC3 than under TP. So what you're suggesting is like a PC3 without autoreview? This would need development (and consensus beforehand, to motivate such development). You couldn't really use the template as a sandbox though, since the stable version would be transcluded, not the latest, unless the stable version was only transcluded on some pages but not others, but that would be hacky. I think what you'd like would require a completely new system, it isn't really possible with FlaggedRevs. Cenarium (talk) 23:49, 1 November 2016 (UTC)
I don't think that sandboxes are commonly transcluded by themselves. And Andy, I was listing several different things that can be done with a flagged revision system that can't be done with template protection, not proposing them to become mandatory. Jo-Jo Eumerus (talk, contributions) 06:51, 2 November 2016 (UTC)
Why template editors only? That seems to take it a beyond what is necessary to put a stop to the large-scale template vandalism that has made the news lately. Dustin (talk) 07:06, 31 October 2016 (UTC)
The templates on Hillary Clinton (currently and temporarily) have a hard threshold of template-protection, which allows only template editors to edit, which is stronger than PC3 itself — Andy W. (talk) 17:33, 31 October 2016 (UTC)
Some templates are too complex for the average reviewer to review, and we should also be aware of breaking changes. This was one of the main oppositions in the previous discussion. Template editors have been specifically chosen because of their knowledge of template editing, so this addresses this objection. Also, it isn't uncommon for those vandals to become autoconfirmed in order to bypass semi-protection, the same would eventually happen here if we don't dissuade them. Cenarium (talk) 22:29, 31 October 2016 (UTC)

WikiProject essay guidelines excluding embarrassing facts

I'm looking for guidance and suggestions crafting a proposal to address essay advice or local consensus in three WikiProjects that contradicts policy. At the Firearms, Automobiles, and Aviation (also) projects, there are strict rules against even the merest mention of certain types of facts on articles about project's products or companies (guns, cars, airplanes, airlines, car companies, gun makers). Air crashes, crimes with firearms, and car recalls are all given a high standard for inclusion in associated articles. For any other topic, and any other kind of facts, content policy determines what goes in and what is out.

These special rules raise all sorts of ironies and paradoxes:

  • Should every industry or product have a special rule to exclude certain types of negative information? Should we have a higher-than normal standard for mentioning a security bug in a software article? Or a special rule to exclude even so much as mentioning an incident when a work of art (book, song, movie, video game) is blamed for a suicide or a crime? Why these three industries and no others?
  • What if a firearm maker or car company is accused of insider trading, or job discrimination? Can we mention that based on normal content policy, or do we also need a higher bar for inclusion of those negative facts?
  • Why only negative facts, recalls, shootings, and crashes? Should we also have a special rule prohibiting mention of positive associations with the product or company?
  • Wikipedia:What Wikipedia is not has no comparable strict rule forbidding even the mention of certain types of well-sourced facts. I can't find any policy that works this way. WP:CONPOL and WP:NOT. Prices of products, for example, are discouraged, but may be mentioned provided sourcing and indication of importance exist.
  • The only parallel is Biographies of living persons policy. BLPs may forbid mention of information that can harm a living person, unless a very high standard is met. Should we treat cars or guns or these companies as if the were people? Why only these and not other products?

And so on. The contradictions and absurdities get worse the longer you look at it. There have been several very bitter disputes surrounding these "strict exclusion" rules, and I don't believe it is a problem on other WikiProjects. At Firearms, Autos, and Aviation, debate rages and it gets personal, editors get blocked.

Should get rid of these essay rules, and apply the same content policies evenhandedly, regardless of topic, with no regard to which industry or product it is, or whether it reflects well or poorly on the subject? Part of the problem is that this essay advice, on negative facts, (as well as pop culture and trivia in many WikiProjects), is very poorly crafted. They frequently use the skunked term "notable", triggering unnecessary debates over WP:NNC. Merely saying "significant" or "important" would avoid this. Many of essays incorrectly cite Wikipedia:Manual of Style/Trivia sections, which explicitly is not about excluding content; only article layout and organization. But just better writing is only part of the solution.

The only policy that really gives support to these strict exclusionary rules is Due and undue weight, but this gives no support for the idea of screening out certain types of facts (shootings, crashes) but not others (sporting victories, awards, famous generals carrying a firearm). WP:UNDUE is blind to the subject, as are the content policies. WP:NOT lets "undesirable" facts be mentioned without regard to whether editors think the sources are wrong to cover it. The silliness of the pet rock isn't a reason to exclude it; if our sources cover it, it meets Wikipedia's standard.

Wikipedia:Essays suggests the entire advice page could be userfied, but that's overkill. Most of the guidelines for these projects are fine. Ignoring advice that contradicts policy ought to work, but given all the bitter debates, that seems to be failing. I'd like to propose simply blanking the restrictions, and asking all projects to stick to content policy for these questions, and not craft their own local rules targeting certain kinds of facts. What would such a proposal look like? Would it be better to proposes a policy change that forbids WikiPrjects from creating these kinds of POV funnels? I think this would have little effect; most articles would read the same without these essays. But we could get there without so much debate.

The obvious problem is that any attempt to fix this will only trigger another bitter debate. Is there a more workable approach? A separate discussion at each of the four projects? A single RfC for all four? --Dennis Bratland (talk) 23:19, 24 October 2016 (UTC)

If you are suggesting that articles on gun models should contain indiscriminate lists of criminals who have used that gun,
if you are suggesting that articles on car models should contain indiscriminate lists of not-very-noteworthy recalls,
if you are suggesting that articles on Airports, Airlines, and Aircraft models should contain indiscriminate lists of minor aircraft incidents,
then I oppose the suggestion. This is not about protecting companies from negative information. This is about protecting the encyclopedia (and readers) from vast lists of unencyclopedic indiscriminate information. The reasons such essays or project-guidelines exist if because certain categories of issues come up repeatedly, they are repeatedly reach the same outcome based on on due-weight and other policy grounds, and because it's more efficient to point to how it has been resolved in the past than to have to re-explain it every time the issues comes up again.
I have a suggestion. The next time one of these disputes arises, try looking at the equivalent article in Encyclopedia Britannica[4] or other encyclopedias. If the information is in there, then that would serve as an extremely powerful argument that it should be included here. If other encyclopedia don't include it, then perhaps other editors are reasonable in suggesting that it doesn't belong here either. Alsee (talk) 15:38, 29 October 2016 (UTC)
You don't think maybe that's a straw man? Are you saying you think an article about an airline ought to contain vast lists of unencyclopeic, indiscriminate information, as long as it's about anything except a plane crash? Why are our content policies adequate keep indiscriminate lists out of every other kind of topic but not these?

These project guidelines exist because it is so difficult to justify the systematic suppression of a narrow category of well-sourced facts based on any policy. The double standard is glaringly obvious. These guidelines don't save time because their irrational basis constantly provokes dissent. The only sense in which they save time is the same way that prejudice saves time: it's easier to reject something without bothering to to look at the evidence if you have pre-judged the question.

If it's really necessary to suppress even the barest mention of embarrassing facts for these three industries, then we ought to apply the same standards to all topics. I don't support endless, indiscriminate lists of trivia and irrelevant news bits. But I think our content policies already cover that, and special rules for certain companies are a violation of the neutrality policy.

--Dennis Bratland (talk) 16:01, 29 October 2016 (UTC)
Hard to avoid straw men when you don't offer any concrete examples of content currently excluded that you think should be included. If you're not saying that, for example, "articles on gun models should contain indiscriminate lists of criminals who have used that gun," what policy are you proposing to determine what gets listed at what doesn't? At the moment it's "notability" - which is a necessarily nebulous concept - but what do you propose instead? Chuntuk (talk) 13:51, 31 October 2016 (UTC)
Which policy? The same policy we use for any other topic. The part you quoted is just a paraphrase of existing policy -- that's not the problem. The problem is the additional restrictions added to the basic rules for what is indiscriminate, such as this arbitrary legislation standard, or muddling notability with content policy by saying a crime must increase the notoriety of the gun in order to so much as mention it. Notability policy specifically forbids this kind of thing, because it has been abused so much. The Automobile project's "strictly" forbidding the barest mention of certain facts is similarly outside policy. No other subject area strictly forbids, sight unseen, ever mentioning a well-sourced fact; instead, due weight and other content policy are applied in context. Even WP:NOT doesn't strictly forbid do much as mentioning a thing; it says it depends on the sources. --Dennis Bratland (talk) 16:46, 1 November 2016 (UTC)
  • The policy is that Wikipedia is supposed have well written articles, with a clear, easy to follow narrative flow, which while comprehensive enough to get the full picture of a subject, are also not bogged down in inane and inconsequential trivia. If you're the kind of person who requires a written policy, and for whom merely "doing what is right" is not enough, see Wikipedia:Verifiability#Verifiability does not guarantee inclusion. Being verifiable is a necessary, but not sufficient, condition. Considerations as to the quality of writing and balance and triviality and relevance also come into play, and as stated in the WP:V policy page: " Consensus may determine that certain information does not improve an article, and that it should be omitted or presented instead in a different article. The onus to achieve consensus for inclusion is on those seeking to include disputed content." If consensus exists at a particular Project, or for a particular article, that some pieces of information, while verifiable, do not improve an article by inclusion, they will not be included. If you wish to override this consensus, you'll have to establish a new consensus. --Jayron32 15:58, 29 October 2016 (UTC)
    • That's incorrect. The NPOV policy overrides any local consensus. WikiProject advice essays are supposed to stay within policy, and not contradict it. When a group of editors gets together and works as a group to suppress particular points of view, but not others, in service of the interests of a product or a company, that group is not here to build an encyclopedia. The fact that they act as a group doesn't give them a license to push a POV this way. --Dennis Bratland (talk) 16:05, 29 October 2016 (UTC)
      • I'm afraid you misunderstand NPOV. "Neutral point of view" is not a synonym for "every point of view" and it is especially not a synonym for "my point of view". To quote the WP:NPOV policy page "Giving due weight and avoiding giving undue weight means that articles should not give minority views or aspects as much of or as detailed a description as more widely held views or widely supported aspects...Undue weight can be given in several ways, including but not limited to depth of detail, quantity of text, prominence of placement, and juxtaposition of statements." (bold mine) Indiscriminate lists of accidents or the like is excessive detail. Also, advocating for well-written Wikipedia article is not "acting in the interests of a product or company". WP:AGF is a policy as well. --Jayron32 00:20, 31 October 2016 (UTC)
        • I get the sense you think I'm a child. You are lecturing me as if I'm proposing we eliminate the NPOV and undue weight policies because what I really want is indiscriminate lists of crap. If you're actually here to make a useful contribution, then can you tell me why the policies we have are not good enough for airlines and guns and cars? We have comparable rules for negative information about living people in the BLP policy, because living people have actually been harmed by Wikipedia articles. We carved out an exception to our neutrality policy to give extra protection for living subjects from defamatory information. But airplanes, cars and guns are not people. Do you think these three classes of non-persons deserve the same protection? Why only these three? --Dennis Bratland (talk) 16:46, 1 November 2016 (UTC)
          • Can you please point to the place where I said anything about protecting anyone? You can't because I fucking didn't. If you don't want to be treated like a child, start acting like an adult and don't place words into people's mouths they didn't say. You have now twice disagreed with me over a statement I never actually made. You invented a statement I didn't make, and then disagreed with that. What I said was that when consensus is that a list lowers the quality of an article by throwing off the balance to a well written article, or provides undue weight to a particular part of the narrative, consensus may be to remove that list. Now, do you want to discuss article quality issues like I am, or do you want to pretend like I said something I never did, and disagree with your imagination again? --Jayron32 03:17, 5 November 2016 (UTC)
We have something of a related problem on railway articles. Rail accidents (perhaps because of their rarity compared to road accidents) attract a lot of news coverage - even for near misses, like a driver going through a red signal but stopping before a potential collision could occur. So rail accidents where there is an actual collision usually attract enough press coverage to meet WP:GNG. The problem that we have is that such accidents tend to be described in at least three Wikipedia articles each - one for the company that ran the train, one for the station at (or near) which the accident occurred, and one for the type of train involved. It is unlikely that all three of these - or even two of them - caused the accident. Let's assume that the driver ran the red light because he had not been trained sufficiently: this is probably the fault of the company that he works for, so that article can have the mention. But the type of train may not be a factor, since an improperly-trained driver might still have passed that signal if he had been driving a different type of train; so mentioning the accident on the article about the type of train is somewhat WP:UNDUE and can cast unwarranted aspersions on that type of train. --Redrose64 (talk) 01:49, 1 November 2016 (UTC)
You can't pre-judge questions like the cause of a particular car accident. You have to look at the facts, and apply the policies of due weight, npov, etc. to that case. Lots of things get described on multiple articles. For example, when an Academy Award is given, it gets mentioned on at least three pages: the winner's bio, the article about the movie, and the academy award show article. In what sense is that a "problem"? Our society happens to care a lot about actors, Oscars, and movies, and there's lots of coverage of that.

The underlying issue is that in the opinion of aircraft, gun and car enthusiasts editing Wikipedia, we can't trust our sources. Even our best sources. On the one hand, we claim they meet our standard of reliability, but on the other hand, they give too much coverage of air crashes, crimes and car recalls. It really gets twisted in to knots when these enthusiast editors get especially picky about which sources to use, depending on how they serve the editors' goal of censoring too much mention of these embarrassing facts. Enthusiast publications, or trade journals, will often list every single car recall (routine coverage) or provide comprehensive coverage of every transport mishap, large and small. So that gets tossed out: obviously these specialist media can't be trusted to tell us what may be mentioned. Wikipedia editors know better. But on the other hand, we can't trust major news media, which we would normally use for any other subject. Major media give too much coverage of crashes and crimes. So they don't guide us as to what due weight is for those particular topics. Wikipedia editors know better. There are no external standards, no outside sources who guide us. This ultimately violates the NOR policy: the Wikipedia standard for mention of gun crimes or plane crashes is our own invention, because a few editors didn't like what they found in our sources -- in any kind of sources.

If this paternalistic suppression of well-sourced facts were applied to all articles, or all types of facts, it might at least produce a somewhat balanced result. But it's only being used to set a higher bar for mentioning crashes, gun crimes and recalls, a few things that Wikipedia editors alone decided, readers and all media shouldn't care about so much.

Going back to basics, applying content policy and due weight policy as written, with no special higher standards for particular industries, puts these topics back on the same footing as any other topic. The only area where we need a higher bar is BLPs, and airplanes, trains, cars and guns are not people.

--Dennis Bratland (talk) 16:46, 1 November 2016 (UTC)


I'm going to jump in here because this looks like an interesting application of notability. I looked at the three pages Dennis Bratland cited in his first post in this section (Firearms, Aviation, and Automobiles). They do seem to address the inclusion/exclusion of crashes/accidents/crime based onWP:UNDUE. For example, the following proposal was made and gathered consent on Automobiles:

OK, Proposal:recalls are mentioned in articles when they have received widespread attention in the MSM. This does not include single MSM articles mentioning them as they are announced. For instance http://www.news.com.au/finance/business/holden-issues-a-record-13-recalls-including-barina-trax-and-colorado7/story-fnkgdhrc-1227090048958 would not qualify, whereas the Toyota floor mat/throttle issue or the Ford burning cruise control presumably would.

That seems fairly reasonable to me, because after all the guideline is

If a topic has received significant coverage in reliable sources that are independent of the subject, it is presumed to be suitable for a stand-alone article or list.

So it looks like the proposal by Greglocock meets the significant coverage criterion in reliable sources (plural) that are independent of the subject (so no places where recalls are expected to be, like a car enthusiast magazine). Looking at Firearms,

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."

it looks like that project guideline does stand by the concept of WP:UNDUE, basically saying that events like Columbine and the assassination of JFK which generate a lot of significant coverage by reliable, independent sources are game for inclusion, but the brutal gun murder that happened in my small town of residence isn't, because it received only local coverage that mostly consisted of the police blotter and courtroom testimony. I imagine that statistics describing overall trends, say increasing or decreasing gun violence, would also be notable, seeing as that is often the focus of political campaigns that receive national coverage (for example the 1990s cracking down on crime rhetoric). Considering Aviation, they look like they also address WP:UNDUE adequately. I can't quote the whole essay, but here's the example of exclusion on that page,

Accidents involving light aircraft and military aircraft are mostly non-prominent. They account for many more accidents and incidents than larger civil aircraft. Military aircraft accidents may be suitable for inclusion in the relevant List of accidents and incidents involving military aircraft.

It looks like they have fairly rigorous guidelines that use the significant coverage on an airplane crash from independent sources, so at face value all three categories do seem to meet the same standards as on WP:GNG. That being said, the idea that Wikipedia editors are indeed applying unreasonable inclusion standards should be addressed seriously, and it looks like the existing guidelines on those pages are the tools to use for enforcement when

It really gets twisted in to knots when these enthusiast editors get especially picky about which sources to use, depending on how they serve the editors' goal of censoring too much mention of these embarrassing facts.

Since the proposal Dennis Bratland was originally discussing is reasonably addressed by the guidelines I quoted, I say that we take it upon ourselves to enforce those guidelines upon instances where editors are censoring embarrassing information. I just jumped in, so can @Dennis Bratland: find those instances of guideline violation? I'm willing to help clean up once I know which pages to start on.

Hope we can take some action on this! Icebob99 (talk) 02:07, 5 November 2016 (UTC)

Seperate Disambiguation namespace?

How plausible and useful would it be to have a seperate namespace for Disambig and SIA pages? Iazyges Consermonor Opus meum 23:35, 4 November 2016 (UTC)

Plausible? Sure, AFAIK adding namespaces isn't much of a big deal (not considering the work of moving all extant disambiguation pages to a Disambiguation: title). But why? I don't really see an upside, but at least one significant downside is that it breaks a convention we've established of natural navigation (which includes redirects). For example, a link to a no-primary-topic dab page (like British) would be a redlink if Disambiguation space was separate (because the page lives at Disambiguation:British), whereas now it's a marginally useful bluelink listing possible navigation alternatives. Another problem is if, for example, it's determined some time in the future that British people is the primary topic for the term British, then the page at Disambiguation:British has to be moved and all links corrected, whereas now the page can just be made into a redirect and all the links are fine. I don't think this separate space for dabs is such a good idea. Ivanvector (Talk/Edits) 00:09, 5 November 2016 (UTC)

URL shorteners for archiveurls

Hi all. Before I go further, I would like to point out that I am relatively new to Wikipedia and that this is my first time posting in the Village Pump, let alone the Idea Lab, so if anyone sees something I'm doing that needs correction, don't hesitate to sing out.

Now for the idea: Some of the tasks I have been doing on Wikipedia include adding |archiveurl=, |archivedate=, and |deadurl= to {{cite web}} templates in all references that I create and in other references, regardless of whether the original URLs were dead. This is to preemptively address WP:404.

However, that practice became a point of debate on the Merrick Garland talk page. A user said that the long archiveurls made the wiki markup difficult to read. Frankly, I rather agree, but I think it is more important to include the archiveurls to wipe out linkrot.

I want to discuss a happy medium for both viewing and editing wiki markup while preserving the integrity of references. Consider URL shortening. Here are the pros: quick, easy to read, the only useful info in the archiveurl structure is the date which is already present in the |archivedate= parameter. The cons: extra step between clicking on the reference and arrival at the page, reliant on the URL shortening service continuing to exist, Wikipedia bans most minor URL shorteners from articles (see here). URL shorteners have a history of being used for spam or shock sites, so there is some negative connotation around here. Also, it is possible that vandals could replace shortened URLs leading to archive.org sites with shortened URLs leading to spam or shock sites without anyone noticing.

I want to leave it at that for right now. The archiveurl parameter really is a crucial tool in fighting linkrot, but it makes pages harder to edit, which slows down encyclopedia development. I think the URL shortener has a lot of potential in addressing this problem, but 1. the problem of spam shortened URLs and reliability will have to be addressed, and 2. a bot will have to be built and/or retrofitted to make this implementation feasible.

I have some further ideas addressing the cons of URL shortening, but I want to get a community reaction first. Let me know any feedback you have. Thanks, Icebob99 (talk) 19:28, 4 November 2016 (UTC)

See RfC: Should we use short or long format URLs? — JJMC89 (T·C) 02:32, 5 November 2016 (UTC)
Thanks for the link! Looks like that has been thoroughly discussed, and I can get behind that consensus. Icebob99 (talk) 13:51, 5 November 2016 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(idea_lab)/Archive_21&oldid=1110109238"