Wikipedia:Village pump (idea lab)/Archive 21

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

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: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)

I think that we should take a page from the policy book of the Dutch Wikipedia with how they handle their admins. (see

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

{{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

{{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)

Wikipedia has a philosophy of reading like an encyclopedia and in an encyclopedic tone that stems from a

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

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:

— 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)

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

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

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)

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

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.

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)

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)

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

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
  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)

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

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)

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 {{

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 {{

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 - {{

McGeddon (talk

) 17:40, 12 September 2016 (UTC)

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

McGeddon (talk

) 09:35, 21 September 2016 (UTC)

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)

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)

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

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)

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)

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

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)

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?

Perhaps relevant discussion at

WT:COUNCIL#Overhaul of article assessments. --Izno (talk

) 17:25, 5 October 2016 (UTC)

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

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

  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)
  • I didn't say this article shouldn't be fixed; only that a bot wouldn't be able to handle it. There are too many varioations on wording, which a human editor can pick up on and a bot can't. עוד מישהו Od Mishehu 04:47, 7 October 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:PEACOCK.--♦IanMacM♦ ^{(talk to me)}
  05:35, 23 September 2016 (UTC)

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:

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)

@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)

• I forgot to note that a related discussion has been running at Wikidata:Wikidata:Project chat#Bot generated data. Aymatth2 (talk) 11:29, 10 October 2016 (UTC)

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

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)

• To riff a bit on automation possibilities: It would be amazingly great to automatically identify links from press release agencies (PR Newswire, GlobeNewswire, etc) They can never be used to show notability. -- 1Wiki8........................... (talk) 08:16, 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)

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

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)

• To riff a bit on automation possibilities: It would be amazingly great to automatically identify links from press release agencies (PR Newswire, GlobeNewswire, etc) They can never be used to show notability. -- 1Wiki8........................... (talk) 08:16, 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)

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

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 60,547,155.) 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

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)

The colon ":" is currently in widespread use to indent comments on Talk pages, and its use is introduced in the

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

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)

• I've informed
  WT:WCAG. --Redrose64 (talk
  ) 22:52, 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

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)

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

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

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

(talk)

07:06, 31 October 2016 (UTC)

The templates on

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)

I'm looking for guidance and suggestions crafting a proposal to address

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?
• 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

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

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
  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: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: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

BLPs, and airplanes, trains, cars and guns are not people.

--Dennis Bratland (talk

) 16:46, 1 November 2016 (UTC)

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)

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)

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 {{

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)