Wikipedia:Village pump (idea lab)

Centralized discussion
Proposals: policy	other	Discussions	Ideas
Proposal to keep two-item disambiguation pages Preventative/punitive blocks and outing Should articles "1" – "100" be about years or numbers? Does this source violate WP:BLPSPS? 2016 Arbcom Election RFC Protecting user pages by default New user right for New Page Patrolling Route diagram templates and Template:Routemap Rewriting PORNBIO For a listing of ongoing discussions, see the dashboard. Note: entries for inactive discussions, closed or not, should be moved to the archive.
archive talk edit history watch purge

I think Wikipedia's neutralist philosophy is flawed.[edit]

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[edit]

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 ^(TALK_CONT) 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)

Make hoax templates visible on mobile[edit]

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)

Closed random RfCs[edit]

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 ^(TALK_CONT) 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)
  • This kind of discussion always makes me think of the only real solution, which is dedicating some time to joining RFC discussions. Anyone who cares about this problem should drop by Wikipedia:Requests for comment/All. Even occasional contributions make a difference overall. WhatamIdoing (talk) 14:58, 19 September 2016 (UTC)

Blank Line Fix Bot[edit]

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[edit]

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, –Davey2010^Talk 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 ^(TALK_CONT) 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 ^(TALK_CONT) 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)

Getting to more productive discussions at AN/I using encryption[edit]

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)

Ping thing[edit]

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)

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

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)

• "In which there were many injuries and deaths" solves the problem, and avoids idiom. --Jayron32 17:30, 26 September 2016 (UTC)

• Oppose: Bots aren't perfect and this is a content related issue which should be left to the discretion of human editors. It is also making an exception for WP:EUPHEMISM when there are similar policies involving words and phrases to avoid such as WP:PEACOCK.--♦IanMacM♦ ^{(talk to me)} 05:35, 23 September 2016 (UTC)

Bot content with updates[edit]

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[edit]

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:

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:

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)

Topics for creation[edit]

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)