Misplaced Pages

Revision as of 06:12, 30 October 2015

• Table of contents
• First discussion
• End of page
• New post

• WP:VPR
• WP:VP/PR
• WP:VPPRO
• WP:PROPS

New ideas and proposals are discussed here. Before submitting:

• Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
• Consider developing your proposal at the idea lab.
• Proposed software changes should be filed at Phabricator (configuration changes should have gained a consensus).
• Proposed policy changes belong at Misplaced Pages:Village pump (policy).
• Proposed WikiProjects or task forces may be submitted at Misplaced Pages:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.
• Proposed new articles belong at Misplaced Pages:Requested articles.

Centralized discussion Village pumps policy tech proposals idea lab WMF misc Voluntary RfAs after resignation Allowing page movers to enable two-factor authentication Rewriting the guideline Misplaced Pages:Please do not bite the newcomers Should comments made using LLMs or chatbots be discounted or even removed? For a listing of ongoing discussions, see the dashboard. view edit history watch archive talk purge

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

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

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215

Time to shut down WP:NFCR by merging it into WP:FFD?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I propose that Misplaced Pages:Non-free content review be shut down as historical while referring editors to use Misplaced Pages:Files for deletion as an alternative. At the present time, there are 163 open discussions on WP:NFCR with the oldest discussion opened on 10 June 2015 (over three months ago.) The fact of the matter is that WP:FFD can and should be utilized in place of WP:NFCR for multiple reasons:

1. On WP:NFCR, if a file is deemed to be used that is inappropriate, the file should be deleted (an outcome at WP:FFD). Files on WP:NFCR will be kept for the opposite reasons (also an outcome at WP:FFD.)
2. Discussions at WP:FFD can question a file's non-free status, and if it is improperly used, it should be deleted.
3. WP:NFCR does not have daily subpages (and seemingly never has), which causes inability to visualize and work on backlogs. On the other hand, WP:FFD has daily subpages and a backlog notification that accurately appears if there are entries existing more than 7 days old; in addition, the bit management and organization of WP:FFD is a lot more advanced in making it clearer what needs to be closed when.
4. For someone questioning if a non-free file should remain in Misplaced Pages (aka, should it be deleted), it is honestly very unclear whether the discussion should go to WP:FFD or WP:NFCR.
5. The concern regarding if WP:NFCR should still be functional has been discussed previously: see Misplaced Pages:Miscellany for deletion/Wikipedia:Non-free content review. The discussion happened back in 2012, and the discussion was closed with the suggestion to go to other pages to develop a consensus on what to do with WP:NFCR. Since that date, there has seemingly not been very minor, if any, updates to WP:NFCR that better distinguishes it from WP:FFD. (Thus, this is why this discussion is happening here.)

What if the non-free file is used in multiple articles, and the question is if it should be removed from one article and not the other?

NFCR is not to be used for case #1: if the only use of a file is up for discussion, that should be at FFD. All other situations are cases of multiple files and/or multiple uses of a file, which may or may not result in deletion. This means that discussions can be closed without administrator intervention (as is require for FFD and AFD). So no, this is not a good proposal, because NFCR handles far too much more than FFD can accommodate. --MASEM (t) 22:00, 2 October 2015 (UTC)

Or to put it more directly, the distinction between FFD and NFCR is very clear: if you honest believe a specific image should be deleted from WP and just need community consensus for that, FFD is where you go. If you are not sure, or that one is talking about a certain use of an image, then we have the discussion at NFCR. It is the same distinction between AFD (where "D" is specifically for "deletion") and the various "for discussion" boards for other non-deletion options like merges. --MASEM (t) 22:03, 2 October 2015 (UTC)

Or, with my proposal, non-free discussions can happen at WP:FFD. I understand that you are trying to clarify the distinction between the two, but it should not have to be explained in this much detail, nor should an inexperienced editor still be confused after reading the distinction. (Which, I still am, by the way; what is the point of having a possible deletion concern started at one forum, then be forced to move it to another?) Steel1943 (talk) 22:13, 2 October 2015 (UTC)

If someone does open a NFCR case that should really be at FFD, we do close those and point to FFD. There's a certain rigor and process that the FFC/NFCR dicotamy has come out of based on the same AFD/(general article discussion) issues. It's tied to the perennial proposal of why we don't remain AFD as "Articles for Discussion" - deletion of content is meant as an absolute step, and so AFD avoids having cases where the proposal is not to delete content and encourages that to take place elsewhere. Similar case at FFD compared to NFCR. --MASEM (t) 22:22, 2 October 2015 (UTC)

• (edit conflict) I have to disagree with this statement in full. For one, I proposed the exact concern stated here be resolved by amending WP:FFD to allow a "keep, but remove from this article" close. Also, I fail to see how this is any different than a non-admin closing a discussion to "keep" at WP:FFD (or any other WP:XFD forum, for that matter) due to a clear consensus that doesn't require a deletion. If a file needs to be removed from one page but not altogether, a non-admin can do that. Steel1943 (talk) 22:10, 2 October 2015 (UTC)

An admin action is the actual act of deletion. With images, NFCR is not about deleting images, just their uses (with rare cases of immediate CSD-type invalid images). Images may be removed from articles, then, leaving them as orphans which are then tagged with CSD by automated tools and later deleted (if the CSD tag is not removed) by admins later. So a non-admin can safely close a NFCR and take the required action that was developed without having admin tools. There's also much more than just considering keeping an image on a page - a good chunk is evaluating if a non-free could be tagged otherwise, if a non-free needs improved rational, etc. We used to have a noticeboard for the broader issues but that was shut down in favor of NFCR. So it is necessary for the less rigorous discussions that FFD is otherwise not set up for. --MASEM (t) 22:16, 2 October 2015 (UTC)

Let's take the following scenario: User:A finds an image, used in multiple articles, (s)he thinks should be deleted as unfree, and lists it at FFD. A clear (SNOW-level) consensus says that the image belongs in one of the articles. Would that be any different than an NFCR case? עוד מישהו Od Mishehu 16:13, 6 October 2015 (UTC)

If the user nominating honestly believes that the image should be deleted from all uses, the right place is FFD because they are seeking admin action. Just like AFD, an FFD can be closed without necessarily requiring an admin action as the example you give. But it's what the initial intent is - if pulling the trigger for deletion is the desired result, an XFD should be used, otherwise other means that do not demand admin attention should be engaged first. --MASEM (t) 16:48, 6 October 2015 (UTC)

• Fully support this proposal. The distinction between the two fora is an artificial construct of bureaucracy, confuses potential nominators, reduces attention for both forums by dividing admin and voter attentions up between them, and serves no purpose that I can see. While we're at it, merge the utterly obsolete WP:PUF into it too. Fut.Perf. ☼ 18:12, 6 October 2015 (UTC)
  • Do you mean to say PUF is redundant? At first glance I agree with the rest of what you say. BethNaught (talk) 18:18, 6 October 2015 (UTC)
  • By that logic, then we should rename AFD from "deletion" to "discussion" and allow merges and the like to be offered there. The same reason that this idea remains a WP:PEREN applies to FFD/NFCR, as the FFD mechanism is simply not set up to handle the types of discussion NFCR handles. I can agree that PUF might be better at NFCR as NFCR handles the inverse case (possibly free files currently tagged as non-free). And really, the amount of mis-filings at NFCR (eg where the user is seeking deletion outright) is trivial and easily handled. --MASEM (t) 18:42, 6 October 2015 (UTC)
• A question of mine: How does this proposal deal with the occasional topic asking about whether a non-free image really is non-free? There are plenty of queries in NFCR about whether such-and-such logo is original enough to be copyrightable. Lumping these into a deletion discussion is sort of odd.Jo-Jo Eumerus (talk, contributions) 18:48, 6 October 2015 (UTC)
  • Well, that's just the point: the types of questions asked at the three fora overlap to a very large degree. All of NFCR, FFD and PUF can deal with questions of whether something is copyrightable or below the threshold of originality (no matter whether it's originally mis-tagged the one way or the other). Both FFD and PUF frequently deal with questions of whether something is PD-old or not. Both FFD and NFCR routinely deal with whether NFCC#8 claims are plausible, the only difference being that NFCR typically does this across several articles. On PUF you often have the situation that you first have to determine that something was mistagged as free, but then the question arises whether you could alternatively keep it under NFC. Conversely, on FFD you often get things nominated as misapplied NFC but then end up discussing whether you could actually keep it as PD. And so on. It's really the same set of questions everywhere. – As for the cases where things get taken to NFCR for the purely formal question whether a non-free tagging should be replaced by PD-textlogo, the answer is simple: those cases shouldn't be nominated anywhere at all. If somebody thinks such items are mistagged, they should simply change the tags; if they are not sure and need to ask, they shoul damn well leave the file alone. The busibodies who keep nominating these should simply stop doing it. Fut.Perf. ☼ 18:56, 6 October 2015 (UTC)
    • But these are similar issues at AFD too. Dealing with mass noms, dealing with results that are not deletions, etc, and the logic to keep things separate is one of those points in the PEREN "Articles for discussion" ideas. As for those that ask questions if a non-free can be tagged with a PD label, while I do wish some were less wary, there are still a good number of edge cases or logos of unclear origins that should be discussed before retagging, and thus fair questions to ask, just as checking on free images that should be tagged non-free otherwise. I'm totally for cutting 3 boards down to 2 (perhaps even 4 to 2 taking WP:MCQ as well), but I fear trying to group all these to one, particularly in the current FFD approach (where we have by date but not separate nomination subpages) is a recipe for disaster. --MASEM (t) 19:08, 6 October 2015 (UTC)
      • I am not convinced that the "is this image really copyrightable" questions should be thrown to the wayside like this. One consideration for me is whether FFD should stay "Files for Deletion" if folks want to merge PUF or NFCR into it; renaming it to "Files for Discussion" would be a solution to the "odd" issue I have.Jo-Jo Eumerus (talk, contributions) 19:14, 6 October 2015 (UTC)

I would support renaming "Files for Deletion" as "Files for Discussion", as a number of FFD referals I made ended up with new information coming to light which meant files could be moved to Commons. A rename would also allow for PUF and NFCR to be merged into there being a single process for querying image status or information.

Perhaps the existing ffd/puf template code could be factored into feeding a new template which creates a "File for disscussion" entry with a reason code.

Some example reason codes in addition to the fact that the file is merely unfree/unused might be:

• Dead source
• "Practical" Duplicate - ie (not an F1/F8) but is in effect a near identical match to another image even if the hash means they aren't pixel for pixel
• WP:FOP concern
• WP:TOO concern
• Derivative work concern
• Work raises ethics concern ( e.g An image which shows an embarrassing medical condition, and the subject is identified.)
• "Attack" image
• Contested Speedy Deletion.

(Of course obvious cases for some of these would still be under CSD)

In addition to having referral/reason codes, there could be outcome codes along the lines of..

• Deleted - and should not be restored.
• Deleted - but can be restored.
• Deleted - for technical reasons (can be restored)
• Deleted - at Wikimedia Commons. (can be restored)
• Retained - Non-free content
• Retained - With status change/update
• Retained - under new name(s)
• Retained - Commons

Having more discrete referral and outcome codes would also potentially allow users like me that do a lot of file work to find similar previous decisions more easily. I am however wary about fosillising policy decisions "made from the bench" so to speak, given that contributors need some flexibility. Sfan00 IMG (talk) 12:51, 7 October 2015 (UTC)

• Merge to Files for Discussion Articles is the only deletion venue that is explicitly deletion only, and for good reason, that there are a lot and it often takes significant effort to comment intelligently, so we need to keep the load a small as we can. It has nothing to do with whether administrators are required. In this case, like the Redirects, Categories and Miscellany venues, the real purpose is to centralize discussion of pages that may require deletion. Since FFD is not overloaded like AFD, it should be just fine to add non-free content reviews to it. Looking at the page now, there are nominations from four months ago, which is a big problem. (Also, it's difficult to explain the distinction, and I think Twinkle has it wrong) Oiyarbepsy (talk) 03:13, 8 October 2015 (UTC)
• If a file appears on two or more pages and should be removed from some but not all of the pages, then the request should go to NFCR. On the other hand, if it should be removed from all of them, it should go to FFD. This looks like an artificial difference, and users who are unaware of the distinction sometimes send files to the wrong place so that discussions have to be closed as "wrong venue" and forwarded to the other venue. Also, it is not always clear from how many pages the file should be removed at nomination time, so nominations could accidentally go to the wrong place even if the nominator knows about the difference between the venues. I suggest that we merge these two situations by having both at the same discussion board instead of splitting them up. FFD could handle all of these situations.

If an article contains too many non-free files, then some of them need to be deleted from the article per WP:NFCC#3a, but there might not be any preference on which ones we should keep. If the files aren't used in other articles, then I create a section at FFD where I list all of the files, stating that we should keep some and delete some. On the other hand, if the files are used in other articles, then I create the section at NFCR instead. If some of the files appear in other articles whereas other files do not, then the page tends to be listed at NFCR, although the rules maybe technically say that the discussion should be split by listing some files at NFCR and some at FFD. This looks like an artificial difference, and it would be less confusing to list all of these pages at the same place, for example at FFD.

If a file is listed as free but someone suggests that it may be non-free, then the file is listed at PUF. If a file is listed as unfree but someone suggests that it may be free, then the file is listed at NFCR. Both situations (change free → non-free and change non-free → free) require the same knowledge and should attract the same users, so it seems more natural to list all of these at the same place. Adjusting PUF to take all of these files sounds like a good idea.

There was also a proposal to merge FFD with PUF. The difference between FFD and PUF is more well-defined and there is less overlap, so I think that it would be better to keep them separated from each other. --Stefan2 (talk) 16:54, 11 October 2015 (UTC)

• Merge into a single process, unless there is some noticeable difference between the potential outcomes of the 2 processes, or some clearly objective difference between pages you should nominate for each (i.e not just the nominator's opinion about the ideal outcome). Consider calling this process "Files for Discussion" (just like we do for categories). עוד מישהו Od Mishehu 05:42, 12 October 2015 (UTC)

Trans-Pacific Partnership protest

Is Misplaced Pages going to do that semi-blackout thing for the Trans-Pacific Partnership like it did for SOPA?--67.182.233.46 (talk) 08:39, 19 October 2015 (UTC)

Not having been involved in SOPA, I don't know what "that semi-blackout thing" means, but if it means preventing or deterring edits that are contrary to WP:NPOV, or vandalism, then I guess it might be necessary. Ditto for TTIP perhaps. Stanning (talk) 09:51, 19 October 2015 (UTC)

See Misplaced Pages:SOPA initiative. Basically Misplaced Pages was shut down for a day to protest SOPA and 67.182.233.46 is asking if we are going to do the same thing for the TPP. I think there has been some discussion about it at User talk:Jimbo Wales, might be worth checking the recent archives there. Jenks24 (talk) 09:54, 19 October 2015 (UTC)

Aha, thanks. TPP is mentioned in User talk:Jimbo Wales/Archive 196, with pointer to information on Wikisource. I don't see anything about TTIP, which is getting a lot of protest over in Europe, but maybe that doesn't have the same concerns or isn't getting the same attention. Stanning (talk) 13:30, 19 October 2015 (UTC)

Added helpful information from Electronic Frontier Foundation, linked above. — Cirt (talk) 11:53, 21 October 2015 (UTC)

Well, the extension to copyright terms would drastically affect public domain works at Wikimedia Commons and Wikisource. It's a very strong reason to protest. --NaBUru38 (talk) 21:29, 24 October 2015 (UTC)

RfC

A RfC has commenced on whether a limited unbundling of blocking for counter-vandalism should be tried for eight weeks, see Misplaced Pages:Vandalism/RfC for a trial unbundling of blocking. Esquivalience 02:40, 21 October 2015 (UTC)

Indefinite Create Protection

Salted pages should not be case sensitive, as it allows the user to recreate the page by simply turning a letter from small to big or big to small. If an administrator indefinitely create protects Tunga Warrior, then Tunga warrior, Tunga warrioR and TungA warrior should automatically become create protected.--1.39.37.62 (talk) 13:39, 22 October 2015 (UTC)

I'm not sure it's necessary. Where we see odd capitalization, I presume an admin reviewing the CSD nom will also look around to identify that it's a deliberate misspelling trying to do the runaround on the page (if the NPP doesn't get to that review themselves). Recreated page at that point can still go through the salting nomination if it's a repeated action, IMO. --Izno (talk) 13:51, 22 October 2015 (UTC)

Any experienced admin has certainly seen this, we just delete and salt the recreations, and probably block the user responsible. I don't think it's that big of a deal and I'm not at all sure what is proposed here is technically feasible at this time. Beeblebrox (talk) 19:03, 22 October 2015 (UTC)

If it becomes a serious problem with a specific title, we can always use MediaWiki:Titleblacklist - simply add a line to disallow "Tunga Warrior", and it can't be created with any capitalization. עוד מישהו Od Mishehu 20:52, 25 October 2015 (UTC)

TAFI & main page discussion

Please head over to this discussion and place your views. :D--Coin945 (talk) 10:05, 25 October 2015 (UTC)

Internal Hyperlinking of Misplaced Pages article

1. Misplaced Pages can /should interlink all its data so that it will be very much better for user to reach indepth knowledge of any topic/article

their are three ways i think

1. 1. Assign all article titles to an array, replace each array element into hyper link, for example title is Sindh, replace it into hyper link like <a href=www.wikipedia.org?title=sindh>Sindh</a>, now find sindh array element into articles body where it is just word with spaces around both sides. replaec ith with Hyperlink. this will be performed when article is loaded. like we have done at انسائيڪلوپيڊِا سنڌيانا Encyclopedia Sindhiana

1. 2. Apply list of Title to an array and find replace it into store database at once, then on new submission of article the title automatically be hyperlinked into all articles in database.

1. 3. the third way is little easy and bandwidth friendly also time friendly, i think, then above both ways, which is on load of any article assign all words of article to an array, and find each array element/word into list of titles. in find true replace array element/word into hyperlink of finded title. this will loop all words of article with title and hyper link on success find. then echo hyperlinked array element as article body.

(if some data should not be hyperlinked then assign linkable data to a veriable, like find until footnote word or until refrences word, i mean a= a varible of article data from title to footnote or reference. — Preceding unsigned comment added by 182.182.116.243 (talk) 10:50, 26 October 2015 (UTC)

If I can make any sense of this at all, it sounds like you're proposing to do exactly what WP:OVERLINKING says not to do. Or alternatively, to make Misplaced Pages look like the sort of articles you see elsewhere on the Internet where some ad script links random generic words to advertisements. No thanks. Anomie⚔ 12:00, 26 October 2015 (UTC)

Global Encyclopedias Network

i Think there is more then requirement Data available on net, but their is still thirist of even basic knowledge to some humans, the reason is simple we dont let comunicate information with each other, it can be a global network of information, fast, easy to access, and highly as per requirement of user. reach able to depth of requirment.

we can hyperlink all internet encyclopedias artilce's titles, at least we at www.encyclopediasindhiana.org want to let user be in network of encyclopedias.

the formula is simple call and apply any/each encyclopedia's article titles, convert them into hyperlinks in article body. (first stage), second stage is generate auto hyperlink on new submission of any article , auto click it programetically: for example in our case we can send or wikipedia can send us new submission of article, its title, it could be generating auto hyperlink of any new article submition, for example if at wikipedia side a new article is submitted, it can generate link like www.encyclopediasindhiana.org/articles.php?new_wiki_title=Sindh when such link be clicked/checked like google crawler check or broken links detecter check link and it will be ranked one time. so the autometically our page will be opened, on such evend we will add new_wiki_title=Sindh into database table of external links, find sindh word in our data replace it with wikipedia hyper link like www.wikipedia.org/Sindh. i think this would make us very informative and keep in touch with Latest Information. this would be the dream of story writer of time travel movie scene an global encyclopedia. one word can have more then hyper links of diffrent encyclopedias like sindh 1-2-3 (sindh one defind in encyclopediasindhiana.org, sindh two in wikipedia.org, sindh 3 define in encarta.com. — Preceding unsigned comment added by 182.182.116.243 (talk) 11:10, 26 October 2015 (UTC)

No, let's not spam links to every random encyclopedia (by whatever definition separates "encyclopedia" from other things pretending to be encyclopedias) onto all articles, particularly not in some SEO scheme. Anomie⚔ 12:04, 26 October 2015 (UTC)

WikiHistory Project

we at Sindhi Language Authority developed a Project named www.encyclopediasindhiana.org, in it their is a feature of time line (dates entered in encyclopedia's articles and their description) with hyper link to such title of entered date. http://encyclopediasindhiana.org/timeline.php

Misplaced Pages can also build a project name like wikihistory or it can add feature to wikipedia called dates entered in this article, it would be very usefull for historians, students and comman user to search history of for example 2015 year. or history of Internet from 2000 to 2015, The history can be search able date-month wise, date-month-year wise, month-year wise and year wise, subject wise, location/country wise, for example history of Pakistan events or keywords used in description of such history timline.

Misplaced Pages can apply this idea also,,,, create crawler which find date formatted strings inside article data, store it in data base, as description it can crawl and include some sentences of crawled date both sides. for example the Pakistan get independent in 14th august 1947 from Brtain., crawler include words on both sides of date. then user can be asked to proof such entry of date line in such article, proper formate it as standerd date is formated, assign it a Defined description as in article. and update it to database.

or User can insert history from any part of world.

or wikipedia also can add one more feature to existing wikipeida articles, so that when a user enter an article so it can highlight date formated strings which will be shown in side bar of article and whould be added into database of wikihistory, or search able history of wikipedia dates entered in articles.

or this is also an example www.historymole.com — Preceding unsigned comment added by 182.182.116.243 (talk) 11:39, 26 October 2015 (UTC)

Removing Persondata

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

Persondata was been deprecated by an RfC held here, which closed with "Consensus is to deprecate and remove". A bot is needed, to remove it from all articles. However, my request for a bot to do so was closed with the claim "a discussion about a bot operation of this magnitude needs to be held in a broader forum, with more participants and a more focused discussion". I therefore seek agreement here, to have a bot carry out this task. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:12, 8 September 2015 (UTC)

Misplaced Pages:Bot requests/Archive 64#Remove persondata is the request for a bot that Andy mentions. --Izno (talk) 15:59, 9 September 2015 (UTC)

• Conditinal support. As the template has been marked as being deprecated for three months, it makes sense to begin removing it from articles in a methodical fashion. A bot is the most logical means to perform this task. My concern is that some portion of the Misplaced Pages community is unaware that {{Persondata}} has been deprecated and as a result is still adding useful information in calls to the template. To deal with this concern, when a bot is in the process of removing the template from an article it should check Wikidata to see if the data items defined in the template have been migrated to Wikidata. If a data item is missing from Wikidata, then the bot should copy the information there before completing the removal. I am agnostic on how the bot should behave when a conflict between Persondata and Wikidata is detected and will defer to the bot's designer on how to best proceed in such cases. --Allen3  11:10, 8 September 2015 (UTC)
  • @Allen3: Please note the discussion of this point in the RfC. All the data that can be reliably ported to Wikidata automatically has been ported. Wikidata does not want further automated import of Persondata. I share your concerns that some editors are still expending time and energy updating this template - that's why we need to remove it from pages, ASAP. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:33, 8 September 2015 (UTC)
• Question - Has all of the Persondata been migrated to Wikidata? That would seem to be a prerequisite. - MrX 13:33, 8 September 2015 (UTC)
  • Please note the discussion of this point in the RfC. All the data that can be reliably ported to Wikidata automatically has been ported. Anyone wishing to port any remaining data manually may work from articles as they were at the time of Persondata's deprecation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:29, 8 September 2015 (UTC)
• Support. While I respect and endorse the BOTREQ groups desire for caution, that discussion already happened. Resolute 13:38, 8 September 2015 (UTC)
• Support - I and a few other editors have been manually removing them ourselves but it would honestly be a lot easier if a bot could do it for us considering there's over 4 million articles on here, I understand the need for caution but IMHO something needs to be done as it'll take forever to remove them all manually here. –Davey2010 17:00, 8 September 2015 (UTC)
• Oppose using a bot or any automation to remove any persondata until such time that it can be demonstrated that it has been fully migrated to Wikidata, or that it persists in some other machine readable field in each article, for example in infoboxes. Dirtlawyer1 raises some very valid concerns and Andy Mabbett's responses don't exactly fill me with confidence that a bot will handle this properly. Removing persondata is not an emergency, and more harm could come from rushing this through with automation.that has not been migrated to Wikidata. Support removing persondata that has been migrated to Wikidata. - MrX 18:46, 8 September 2015 (UTC), 23:49, 9 September 2015 (UTC)
• Support – it's definitely time to do this now. --IJBall (contribs • talk) 20:28, 8 September 2015 (UTC)
• Support - given that the purpose of Persondata was for automated cataloguing, and an automated tool has already pulled any information useful for that purpose (the rest is unreliable, and Wikidata doesn't want it) then the time is right to programmatically remove all instances of the template. As Andy said, users wishing to port additional information can work from the page history. Ivanvector 🍁 (talk) 21:38, 8 September 2015 (UTC)
• Comment - As a Wikidata editor, on the random of BLPs (and some dead people) on my watchlist that I've edited and noticed the persondata, I've found that not always is the data on Wikidata. This usually pertains to the alternate names, for which Wikidata has not pulled in as either aliases or as statements. A handful of times it has been differing birthdates. To suggest that everything has been moved over when not even aliases have captured the notion of alternative names is odd. --Izno (talk) 21:55, 8 September 2015 (UTC)
  • Once again: Please note the discussion of this point in the RfC. All the data that can be reliably ported to Wikidata automatically has been ported. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:20, 9 September 2015 (UTC)
    • Your snark ("once again") is unnecessary and unappreciated. The point I am making is that there are data which have not been provided to Wikidata; that such data cannot be automatically provided to Wikidata reliably (we agree!); and that mass-removal by bot is thus inappropriate. Except I nowhere opposed or supported. Would you like me to do so now on ad hominem grounds or the actual logical ones of my comment?

      A more sensible approach as provided at WP:Bot requests is to remove the ones by bot which can trivially be shown to have had all their information migrated. In fact, none of the very reasonable suggestions for a bot were presented in this RFC, which I find somewhat specious, since that discussion has gone unlinked in the opening statement of the RFC. Obnoxious. --Izno (talk) 15:49, 9 September 2015 (UTC)

      • There was no snark in my comment; unlike yours. You'll note I referred to "my request for a bot to do so...". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:12, 9 September 2015 (UTC)
    • Misleading statements alert - Andy, that just ain't so, fella. Please see my extended comments below: virtually no alternate form names have been transferred -- birth names, maiden names, married names, etc. -- and that represents a significant loss of USABLE information. Sorry, but you're wrong. Dirtlawyer1 (talk) 17:27, 9 September 2015 (UTC)
      • Anyone is welcome to do as I suggest, and read the discussion of this point in the RfC (and for that matter the discussion on Wikidata to which that links). They'll soon see that the misleading statements are not mine. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:12, 9 September 2015 (UTC)
• Support - having a bot remove deprecated persondata and complete the task. As stated above "Wikidata does not want further automated import of Persondata" so no need to match or compare persondata to wikidata prior to removal. The sooner the removal of persondata, the better - especially since consensus was to remove persondata three months ago. Thank you Andy for following up on this. Gmcbjames (talk) 23:45, 8 September 2015 (UTC)
  • Taking into consideration further discussion, my opinion has not changed. When Persondata is bot removed, information will not be lost - the information is in the article either in the text body or infobox (if used). This information has been visible for anyone to correct misinformation, unlike the invisible and unreliable Persondata. I would suggest editors porting Persondata into Wikidata to carefully double-check the persondata with the article for accuracy. The best solution is to remove Persondata completely at this point of time, as I doubt editors will take the extra time and effort to double-check information prior to porting persondata into Wikidata. As time progresses, the information in Persondata only becomes more stale, so delaying will only compound the problems. Gmcbjames (talk) 05:54, 10 September 2015 (UTC)
• Support Helder 00:23, 9 September 2015 (UTC)
• Support – RGloucester — ☎ 01:24, 9 September 2015 (UTC)
• Support for all the obvious reasons. ~ Rob 01:38, 9 September 2015 (UTC) Oppose. It appears some editors do think valuable information remains and are working to manually transfer it. I would likely support more limited attempts to remove those which are not useful (i.e. blank persondata transclusions or those with only name filled in), but if there is actual data remaining, keeping a comment in the text hurts little to nothing. As we verify that everything has transferred, these templates can be gradually removed. ~ Rob 21:07, 9 September 2015 (UTC)
• Support the bot program, and the sooner implemented the better. Four million articles await, and even with the bot it'll take some time to accomplish. Can we publish this deprecation better so editors don't keep wasting time on updating/maintaining these templates? GenQuest 04:00, 9 September 2015 (UTC)
  • Neutral Changed per the below information. Was the deprecation RfC regarding Persondata and its resultant "Consensus is to deprecate and remove" widely published? If so, the results (if you can call them that), have been poorly implemented. If not, then it seems that someone, somewhere has jumped the gun and the deprecation decision needs to be reversed and a newer discussion held in the broader community. As to @Dirtlawyer1: stating that people wasting time on updating the existing templates is "a red herring", I can assure you that I, who really, really have limited time these days to edit, have indeed been wasting my time on updating/fixing/editing them.
    This is turning into more bureaucratic horse pucky, and there Ain't nobody got time for that... GenQuest 22:05, 9 September 2015 (UTC)
    • @GenQuest: Yes, the decision to deprecate has been widely publicised. removing the template, completely, by bot, ASAP, would prevent other editors from having their time wasted, as yours has unfortunately been, because it was not removed already. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:16, 9 September 2015 (UTC)
• Oppose This discussion is missing an important point. How do you get persondata information into wikidata in the future, if this established workflow of persondata at wikipedia is deleted? The situation is: enwiki persondata was imported in the last months to wikidata, ok. Comparing persondata form enwiki to wikidata has shown very similar quality, no surprise. Now tell me: How many new biographic articles were created at enwiki in the last 2 months? (How do you even find them without persondata?) Does wikidata contain the same data as enwiki-persondata about these new articles? How was this data entered into wikidata, by a wikidata-bot using enwiki-persondata? By a wikidata-bot using dbpedia-data that is harvested from enwiki-persondata? By a wikidata-bot harvesting enwiki-person-infoboxes, if and only if they are available? Or has wikidata no data about those new person-articles, because this dataflow to wikidata is now broken, because enwiki deprecates persondata? Show me the data! How is this going to work in the future? Who is supposed to enter new persondata in wikidata, some magic wikidata-workforce that doesn't exist? Magic bots? Show me the workflow! --Atlasowa (talk) 09:48, 9 September 2015 (UTC)
  • There is no workflow necessary. Once persondata is removed from articles, it will be deleted and the template will no longer exist. From there, if editors care to edit such data, they can put it directly into WikiData. In the meantime, all we're doing by waiting is allowing more editors to waste their time adding information that is no longer being used. ~ Rob 11:29, 9 September 2015 (UTC)
    • @BU Rob13: That's simply not true, Rob. Many editors, myself included, are manually transferring remaining usable persondata -- including multiple name variants -- to Wikidata. I have not seen more than 2 or 3 instances of editors updating Persondata in the last three months, and I have over 6,000 articles on my various watchlists. No one is wasting significant efforts updating Persondata, and we could significantly improve Wikidata if we had widespread notice and explanation of what usable Persondata remains. Instead, we seem to have a "not invented here" mentality driving the desire for the immediate deletion of Persondata. There is ZERO reason to immediately delete all Persondata, and there is no harm in keeping ti for a while longer. Dirtlawyer1 (talk) 17:22, 9 September 2015 (UTC)
      • As noted above "Anyone wishing to port any remaining data manually may work from articles as they were at the time of Persondata's deprecation". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:15, 9 September 2015 (UTC)
  • You appear to be opposing the deprecation of Persondata. That has already been decided and enacted. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:28, 9 September 2015 (UTC)
• Strongly Support Given that wikidata has decided to no longer have data pulled over from persondata and therefore any information entered in it from this point on is about as useful as scribbling it on your wall, it should be removed. Jerod Lycett (talk) 11:24, 9 September 2015 (UTC)
• The Persondata data could be archived on Tools or something. We don't need to keep it lying around in articles; as the bot is removing Persondata, it could be storing it at an off-site location, for interested parties to review at a later time. This would be similar to what's been done with {{Authority control}} (see T.seppelt's Authority control validator). Alakzi (talk) 12:44, 9 September 2015 (UTC)
• Pinging users of the discussion from the bot requests page (whom have not yet commented somewhere above): @Magioladitis, Gerda Arendt, RexxS, Dirtlawyer1, Hawkeye7, SLBedit, Francis Schonken, and Andy Dingley: @Jared Preston, GoingBatty, Jc3s5h, MSGJ, and C678: (Cyberpower as closing bot op). --Izno (talk) 16:06, 9 September 2015 (UTC)
  • I've been closely monitoring this discussion since it made its appearance here. It's good to see that this discussion is more focused. At current it's looking like immediate removal is the preferred outcome at the moment, but this clearly needs to stay open longer.—_Chat:Online 20:10, 9 September 2015 (UTC)
  • And @Periglio:, too. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:09, 9 September 2015 (UTC)
• Support, --Gerda Arendt (talk) 16:36, 9 September 2015 (UTC)
• Support The sooner we get rid of this practically unused misfeature the better. Many of the oppose votes are bringing up the same tired objections that have already been discussed. Jason Quinn (talk) 11:32, 11 September 2015 (UTC)
• Strongly OPPOSE at this time - A lot of misleading comments have been made regarding the status of the migration of Persondata to Wikidata. I know this first hand because I have manually transferred the Persondata from over 1,000 articles to Wikidata in the last 90 days, and I have had ample opportunity to review a sizable sample of Persondata that I entered into the templates myself. In many instances, the following information has not been transferred:

• Alternate names - many, if not most alternate names have not been transferred from Personata to Wikidata by bot action; birth names, maiden names, married names, etc., probably represent the largest potential loss of valid, usable information from Persondata; and
• Brief descriptions - in many instances, the brief descriptions have not been transferred by bot action; and
• Updated information - as best I can tell, no new or updated descriptions -- or new or updated Persondata information generally -- have been transferred since at least November 2014; this includes new or updated names, descriptions, birth dates, birth places, death dates, death places.

The claim that there is no remaining usable Persondata to be transferred vastly understates the usable information remaining to be transferred. Persondata has been deprecated because a better long-term solution for biographical meta data -- i.e., Wikidata -- has been created. That does not excuse throwing away reliable information from Persondata, information that has not been transferred to Wikidata, without making a better effort to transfer what reliable and usable information remains. That's not undermining Wikidata, that's supporting and improving Wikidata. I am pinging "support" voters above (i.e., @Allen3, MrX, Resolute, IJBall, Gmcbjames, He7d3r, and RGloucester:@Davey2010, BU Rob13, GenQuest, Jerodlycett, and Gerda Arendt:) to reconsider their support for the immediate automate removal of remaining Persondata. Few editors have committed more personal editing time to manually transferring remaining usable Persondata to Wikidata than I have (see for my Wikidata contributions), and few editors have better first-hand knowledge of what remains than I do. Simply deleting all remaining Persondata represents an amazingly foolish waste of past efforts, and the loss of an opportunity to improve Wikidata, educate editors about Wikidata, and recruit more editors to improving Wikidata. What is needed is project-wide notice and explanation to all editors and a concerted, a coordinated effort to transfer what remaining Persondata is usable, and a hard deadline for completion. There is nothing to be gained -- nothing at all -- by the immediate automated deletion of remaining Persondata, and much that may be lost. Dirtlawyer1 (talk) 17:16, 9 September 2015 (UTC)

Have you read my comment above? Would you support with the caveat that a copy of all data is made available elsewhere? Alakzi (talk) 17:26, 9 September 2015 (UTC)

@Alakzi: Yes, I did read your suggestion, A. It's a political solution that, as a practical matter, will simply lead to the removal of existing Persondata with virtually no transfer of remaining usable information. Once the Persondata templates are removed from our articles, it's gone. The solution is notify everyone about the status of Persondata, educate our editors about Wikidata and manual transfer of usable Persondata to Wikidata, create a simple set of instructions, and then set a hard deadline. In the mean time, remaining Persondata does ZERO harm, and immediately removing it by bot action represents the loss of usable information -- alternate name forms, in particular -- in many instances. Dirtlawyer1 (talk) 17:34, 9 September 2015 (UTC)

As far as I understand it, the concern is that, so long as {{Persondata}} remains in widespread use, people will blindly copy it over to new articles, or waste their time updating it, etc. The solution is notify everyone ... Instead, we could notify everyone that the data can now be found over yonder at that "toollab", and that they can transfer it to Wikidata at a leisurely pace, without having to mind any deadlines. Alakzi (talk) 18:01, 9 September 2015 (UTC)

Alakzi, I do new page patrol for articles within my subject areas, and I am seeing virtually no new persondata templates being added to new articles. The concern for lost efforts of editors is a huge red herring; where is the concern for the lost efforts of editors who added valid and usable Persondata that has not been transferred to Wikidata? There is no urgent reason to delete all remaining Persondata, and, and based on my first hand review of a relatively large sample, there is much that will be lost. If we simply transfer Persondata to a holding tank, it's as good as deleted, because once it's out of sight, it's out of mind. We both know this. Dirtlawyer1 (talk) 19:14, 9 September 2015 (UTC)

I'm no expert, being an engineer (and previously a software engineer) but is it really beyond the realms of possibility that a bot can sift through article histories and find the last one with the Persondata template and transfer that good stuff to Wikidata? The Rambling Man (talk) 19:49, 9 September 2015 (UTC)

@The Rambling Man: Andy maintains there is no way to engineer the further automated transfers of usable information from Persondata to Wikidata (please see above). If I understand him correctly, in fact, he maintains there is no usable Persondata left to transfer. I can tell you, based on over 1,000 manual transfers that proposition is incorrect. Dirtlawyer1 (talk) 20:31, 9 September 2015 (UTC)

Of course it's possible to do what I suggested. It's trivial. If WMF want me to help out with that, just send me an email. The Rambling Man (talk) 20:34, 9 September 2015 (UTC)

@The Rambling Man: I have little doubt that depends on the skill of the personnel involved. FYI, if WMF has been involved directly in the previous bot transfers of information from Persondata to Wikidata, it's not been mentioned in the previous discussions. This looks like a volunteer effort, not professionally managed. Dirtlawyer1 (talk) 20:57, 9 September 2015 (UTC)

(edit conflict) @Dirtlawyer1: It was my understanding that all automated transfer of persondata is complete. What do you believe needs a manual transfer, and why couldn't that be handled by an automatic transfer? I'm willing to reconsider if given a good reason to do so. ~ Rob 19:52, 9 September 2015 (UTC)

Rob, I see two primary areas of concern: (1) First, most alternate names -- birth names, maiden names, married names, nicknames, etc. -- were never transferred, perhaps because no one wanted to deal with the comma-delimited last-name-first format of the Persondata template. Frankly, from what I've seen, I would not be surprised if no serious automated effort was ever made to transfer alternate names from Persondata to Wikidata. (2) Second, based on my own own observations, I don't think any of the automated bot transfers ever updated any Wikidata fields once they had information present within those fields, and there was no effort made to reconcile conflicting information. Apart from those issues, I have also not observed any attempt to auto-transfer updated Persondata for the past ten months. And then there is the "error factor": dates and places of birth and death which were simply never transferred for some unidentified reason. The automated transfers appear to have been very "down and dirty" -- transfer as much as possible as quickly as possible, and ignore errors, conflicts and omissions. If we care about Wikidata and believe in its importance, we should be systematically reviewing it and comparing to remaining Persondata before it's deleted. In the mean time, it's not harming anything, and we should be encouraging people to review it and start utilizing Wikidata. If we don't, it's a lost opportunity on two levels. Dirtlawyer1 (talk) 20:31, 9 September 2015 (UTC)

You support removing Persondata from any article that has had all appropriate information transferred already, correct? ~ Rob 20:33, 9 September 2015 (UTC)

@BU Rob13: In theory, yes, I do, Rob. The question is how is that determined, and who will make that determination? Andy maintains that "all appropriate information" has already been transferred; frankly, that's simply not accurate. I have three months of first-hand experience in manually transferring usable information from Persondata to Wikidata, and I know that proposition is factually incorrect. Furthermore, I seriously question whether further automated transfers of remaining Persondata -- alternate names, in particular -- are technically infeasible. See The Rambling Man's comments above. Dirtlawyer1 (talk) 21:04, 9 September 2015 (UTC)

You're misquoting me. Please desist. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:19, 9 September 2015 (UTC)

No such claim was made. Please stop tilting at windmills. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:15, 9 September 2015 (UTC)

"All the data that can be reliably ported to Wikidata automatically has been ported." Pigsonthewing @16:33, 8 September 2015. You have now been quoted verbatim. And I hotly dispute the accuracy of your quoted statement: apparently no real attempt has ever been made to "port" alternate names. And your quoted statement raises more questions than it answers; it reads like a lawyer's non-answer. Dirtlawyer1 (talk) 21:52, 9 September 2015 (UTC)

Your claim about alternate names is bogus; they were discussed both on Wikidata and in the RfC which found consensus to deprecate and remove persondata. If you dispute the accuracy of my statement, it is open to you to attempt to disprove it, by showing a method, acceptable to the Wikidata community, by which further data from persondata templates can be transferred, with confidence as to its accuracy, to Wikidata. Please do so, or admit that you cannot. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:04, 9 September 2015 (UTC)

I think that you two are focused on different aspects. Andy is talking about "all the data that can reliably be ported automatically"; Dirtlawyer cares about "all the data", full stop. I tend to agree with Dirtlawyer's suspicion that blanking the remaining data will, for all practical purposes, mean losing the remaining data. However, could we not blank the pieces that we know have been ported reliably, and keep the rest—perhaps with an in-article note that says not to restore what's been ported? Then we could at least clean up some and see the scope of the remaining problem. WhatamIdoing (talk) 00:08, 10 September 2015 (UTC)

@WhatamIdoing: To be clear, WAID, 100% is an unattainable standard, and I understand that perfectly. My primary concern, as I and other have noted above, is that most alternate names have never been transferred, and Andy and others are apparently aware of this fact. I have manually transferred the Persondata from over 1,000 Misplaced Pages articles since June 2015; well over half required the transfer of alternate names -- i.e., birth names, maiden names, married names, nicknames, etc. -- that were not transferred by bot action. As a result, I quite reasonably question the accuracy of the statement "all the data that can reliably be ported automatically" has been; in fact, I would say that it's pretty serious misrepresentation of reality. If that is the best "that can reliably be ported automatically, then we need to find better solutions. Please note I support GoingBatty's modified RFBA proposal to remove Persondata templates that are empty except for the primary name field. No one is questioning that Wikidata is the better long-term solution, or the deprecation of Persondata; I am seriously questioning whether we have made a best-efforts attempt to transfer all elements of usable Persondata, and alternate names in particular. My first-hand review suggests we have not, representations to the contrary notwithstanding. Dirtlawyer1 (talk) 01:51, 10 September 2015 (UTC)

Once again, you "question the accuracy of the statement 'all the data that can reliably be ported automatically' has been", with no evidence to support your claim; one again, I challenge you to show a method, acceptable to the Wikidata community, by which such data can be automatically transferred, with confidence as to its accuracy, to Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:47, 10 September 2015 (UTC)

Two sets of questions:

1. When do those arguing that data should be maintained, pending manual checking, expect to complete that task? On what calculations are those estimates based? Why can such manual checking not be done using old versions of articles?
2. How do those arguing for further automated transfer plan to carry out such transfer? And is this agreeable to the Wikidata community?

If sensible and workable answers are provided, I'll strike my request; if none are, the "oppose" !votes should be struck. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:25, 9 September 2015 (UTC)

If the answer to #1 were 2200, would it matter? Persondata templates do not change the rendering of an article whatsoever. They're not so costly to keep for now as to cause any real issues. A more workable proposal, and one I'm working on fine tuning, is to remove those instances of Persondata where we can reasonably assume everything has transferred to help those doing manual conversion focus on what actually needs doing. For instance, any transclusion of persondata that only has a name can obviously go, and I'm having some discussions on user talk pages about other combinations that could be removed with no data loss. That is a reasonable compromise route that you may wish to consider. ~ Rob 21:32, 9 September 2015 (UTC)

Yes, it would matter (and it would likely be an underestimate of the time required). We already have an RfC which found consensus to remove persondata. This is a discussion about using a bot to do so, not about re-running the original RfC. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:44, 9 September 2015 (UTC)

There was consensus to remove after the useful stuff was moved to WikiData, as far as I can see. A few editors close to the template who have been trying to carry out the consensus to transfer stuff over have stated this isn't complete, and I see no evidence that it is. All persondata should be removed eventually, yes. When depends on how long the transfer takes. ~ Rob 22:44, 9 September 2015 (UTC)

No. The closer stated Consensus is to deprecate and remove. No qualifiers; no waiting period. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:10, 9 September 2015 (UTC)

• BRFA filed based on my prior suggestion, which is intended to be a compromise to respect both sides of this issue. GoingBatty (talk) 23:25, 9 September 2015 (UTC)
• With respect, @Dirtlawyer1:, I will not change my vote. If nobody has found the need to save what data is not already at Wikidata in the last few months, I see no reason to expect it to happen in the next few months. The consensus of the May RFC should not be set aside because doing nothing is more convenient. The community already spoke, and I do not see value into essentially turning this into a rehash of that RFC. Resolute 23:29, 9 September 2015 (UTC)
  • @Resolute: You know me from previous discussions where we have been on the same side of the fence, and occasionally on opposite sides, as reasonable, intelligent people sometimes are. One thing you should know about me by now: I don't bulls@#$. With regard to the original RfC: (1) it did not specify how Persondata was to be removed, and bot deletions require additional approvals; and (2) the original RfC -- how shall I put this delicately? -- misrepresented the status of some usable Persondata, alternate names, in particular: based on my personal review and manual transfer of Persondata from over 1,000 articles to Wikidata, very few birth names, maiden names, married names, etc., were transferred by bot action. You're welcome to review my contributions to Wikidata since May 2015: . I would say that the misrepresentation(s) regarding the "porting" of all usable information should come pretty close to voiding what validity the underlying RfC had/has, but that still does not address the question of bot action required for immediate removal. Mindlessly deleting all Persondata -- including alternate names, most of which have not been transferred -- is just that: mindless. There are multiple solutions here, all of which would be better outcomes for Misplaced Pages and Wikidata, than the immediate deletion of all Persondata. Dirtlawyer1 (talk) 23:54, 9 September 2015 (UTC)
    • Your claim that "the original RfC... misrepresented the status of some usable Persondata" is fatuous, and made, as usual, without evidence. The removal of Persondata templates would not me "mindless"; it has been well-considered. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:44, 10 September 2015 (UTC)
    • Sorry Dirtlawyer. I wasn't intending to target a general response to you personally. Also in general, when push comes to shove, I put very little stock into the needs of machines. So while I respect the work you are doing to aid WikiData, I find it preferable to dump the entire mess entirely since I do not believe it adds much value to the project. Resolute 15:05, 10 September 2015 (UTC)

• Suggestion: Templates with no unique information are deleted. If there is potentially usable info then comment out the template. The comment may include a link for why it is commented out. That link would say the template is deprecated, include instructions for submitting any reliable useful info to wikidata, and say to delete the comment&template when done. Alsee (talk) 02:07, 10 September 2015 (UTC)
  • @Alsee: This comment actually functions as something that's commented out. It doesn't change the rendering of the page whatsoever and exists only to store metadata that is easily readable by machines; something WikiData was designed to take over. That's why we're interested in conversion to there. ~ Rob 21:32, 10 September 2015 (UTC)
    • The factlets in persondata which have not already been transferred are not "easily readable by machines", that's why they were not transferred, and why consensus to deprecate and remove them was reached. Yet again I suggest reading the RfC discussion, and the Wikidata discussion to which it linked. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:10, 11 September 2015 (UTC)
• Oppose As one who has worked with the migration of Persondata to Wikidata, I want to see Persondata disappear, the data within it is just not reliable. For birth/death dates and places, there are more reliable templates to use as a source.

Up until now, I have ignored the alternative name parameter as personally I found it too random to be of any use. However, @Dirtlawyer1: has convinced me that there is data that would be lost. My suggestion of a way forward would be be to remove persondata. If there is an alternative name, create a {{aka}} template. Make this visible at the top of the article and the community would correct the dodgy ones. Periglio (talk) 02:38, 10 September 2015 (UTC)

• Suggestion: I was pinged, and now don't know where to add. I have personally replaced Persondata by infoboxes, much more useful because visible. {{Infobox person}} can hold alternate names easily. I imagine that a bot could check, when removing Persondata, if all information is already in an infobox, if not transfer it there, and if none exists, propose one on the talk page, again to keep the data somewhere visible. (It's not the first time I suggest this. I try to avoid mentioning infoboxes because some don't like them but can't stop thinking that they are useful.) --Gerda Arendt (talk) 08:59, 11 September 2015 (UTC)

• Support: Wikidata covers what is needed, I always wondered why we ever used persondata, it seemed clunky to add invisible content when the same could - and should - be included in visible data in every article. Seems the decision has been made that it's duplicative, so let's get the ball rolling. Montanabw 21:24, 14 September 2015 (UTC)
• Support: The PersonData template was deprecated back in October 2014. After that, no one was supposed to add it to any new articles. Changes were made to prevent its automatic addition. A far better attended RfC in May gave clear support for its methodical removal. I was disappointed that the WikiData people pronounced it of no use whatsoever for their purposes. There was talk of migrating information to the Infoboxes, but no support for this. Which left us with editors being advised not to include them on new articles, to remove them whenever they are editing an article with one, and to get a bot to do the final clean up. Andy is just responding to the recommendation of the RfC and the BRFA. I don't know and don't care what is on Wikidata - it has absolutely nothing to do with us. But I do know that all the information in the PersonData template is already present elsewhere in the article. Hawkeye7 (talk) 05:57, 7 October 2015 (UTC)

Multiphase removal

As I botop, I have a suggestion. It's clear consensus supports removal, at some point, but nobody can seem to agree when that removal should happen. So let's take it at chunks at a time. Here are the phases:

1. Remove all blank templates...
2. Decide on parameters of the persondata template that can be ignored and make another passtrhu with the bot.
3. Repeat 2 until templates with useful information are left.
4. Decide on suitable replacements for the remaining parameters of remaining templates.
5. Implement suggestion with a bot
6. Make a final deletion passthru with the bot
7. Have champagne and beer to celebrate.

How does that sound?—_Chat:Offline 09:21, 11 September 2015 (UTC)

I should point out that number 1 is already being worked on.—_Chat:Offline 09:24, 11 September 2015 (UTC)

I've never seen a blank persondata template in an article; do you have examples? What do you mean by "suitable replacements for the remaining parameters"? And can you relate this proposal to the parallel discussion on Dirtlawyer1's talk page, where a different approach is being proposed? How do you propose to mitigate the apparent "error/conflict rate of 10+%" disclosed there? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:03, 11 September 2015 (UTC)

In which case, Andy, that step should be quick and painless.

Cyberpower, what do you think about changing the "final deletion passthru" to a "copy it to the talk page and remove from the article passthru"? That increases the odds that someone would look into it. WhatamIdoing (talk) 15:04, 11 September 2015 (UTC)

No objections

The BRFA is approved and there are edits that prove the template. Just go there. Each parameter it seems describes an attribute about the person that can be moved to a category, infobox, or whatever. That's what I mean. I'm not proposing anything, I'm suggestion a method of discussion that involves the creation of multiple proposals and them being acted on accordingly, where the final end result is the complete removal of persondata. I'm suggesting a method that might work.—_Chat:Online 21:11, 11 September 2015 (UTC)

You wrote above "I have a suggestion", so you definitely are proposing something. Much of the data is not fit for moving to a category or infobox, as discussed in the aforesaid RfC and on Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:54, 11 September 2015 (UTC)

Which step? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:54, 11 September 2015 (UTC)

The one in which the non-existent (according to you) templates are removed. If none exist, then performing that step should be quick, easy, and painless. WhatamIdoing (talk) 02:47, 12 September 2015 (UTC)

You must be thinking of someone else. I have made no assertion that any templates are "non existent". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:13, 12 September 2015 (UTC)

Right, you only say that you, who have seen thousands and thousands of persondata entries, have never seen such a thing. I admit that is somewhat different from positively asserting that none exist, but still: if you can look at many thousands without ever finding such an example, then removing the few that exist—if they exist—is still likely to be quick, easy and painless. WhatamIdoing (talk) 02:09, 13 September 2015 (UTC)

@C678: My proposal is to delete Persondata only if all of its values are found elsewhere in the article. For example:

• Persondata |ALTERNATIVE NAMES= = Infobox |birth_name=
• Persondata |ALTERNATIVE NAMES= = Infobox |other_names=
• Persondata |NAME= = Persondata |ALTERNATIVE NAMES=
• Persondata |SHORT DESCRIPTION= = Category
• Persondata |DATE OF BIRTH= and/or |DATE OF DEATH= = birth date and/or death date from lead
• Persondata |DATE OF BIRTH= = Infobox |birth_date=
• Persondata |DATE OF BIRTH= = Category:#### births
• Persondata |PLACE OF BIRTH= = Infobox |birth_place=
• Persondata |PLACE OF BIRTH= = Category:People from xxx
• Persondata |DATE OF DEATH= = Infobox |death_date=
• Persondata |DATE OF BIRTH= = Category:#### deaths
• Persondata |PLACE OF DEATH= = Infobox |death_place=

I created a custom module at User:BattyBot/Persondata and submitted a bot request for this, but the bot request was only approved to remove those templates that only have |NAME= populated. Any suggestions for careful removal of Persondata templates that doesn't prohibit the copying of data to Wikidata would be appreciated. Thanks! GoingBatty (talk) 04:28, 12 September 2015 (UTC)

I don't think the presence of any category is a valid substitute for short description. Similarly, we'd have to be somewhat careful with alternative names; the mere presence of an other_names parameter doesn't guarantee every alternative name is listed there. We would need to be careful that we're starting with edits that have zero data loss and going from there. This will help all parties, for the record; we have to start the deletion somewhere, and it might as well be here. It also gives those doing manual transfer an easier time by removing instances where no information is lost and giving them more time to work on the transfer. I'm not suggesting holding up the deletion, just that we might as well start with the deletion that no-one objects to before moving to the deletion that has substantial resistance, even if it's not a consensus not to delete. There's no point in trucking through the editors interested in manual transfer immediately when it will accomplish the overall task no faster. ~ Rob 04:52, 12 September 2015 (UTC)

@BU Rob13: Sorry I wasn't clear. When looking at categories, I meant matches such as Persondata |SHORT DESCRIPTION=American actor = Category:American actors. I also meant exact matches where the entire Persondata |ALTERNATIVE NAMES= value is in the Infobox |birth_name= or |other_names=. Please see User:BattyBot/Persondata for the details of the rules - any suggestions would be appreciated. GoingBatty (talk) 05:16, 12 September 2015 (UTC)

I'm not discussing a proposal to remove something and how to remove it. I'm discussing a proposal on a possible system of discussions so we can systematically remove them where almost everyone can agree with the outcome.—_Chat:Offline 06:11, 12 September 2015 (UTC)

@C678: Sorry for misunderstanding. I appreciate your efforts in proposing this path forward. GoingBatty (talk) 13:16, 12 September 2015 (UTC)

@Pigsonthewing: BattyBot just edited 34 articles that had a blank {{Persondata}} template (e.g. , , , , ). GoingBatty (talk) 05:11, 12 September 2015 (UTC)

@Pigsonthewing: BattyBot also has edited articles that had a full {{Persondata}} template with no values (e.g. , ). GoingBatty (talk) 05:38, 12 September 2015 (UTC)

Thank you for clarifying. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:13, 12 September 2015 (UTC)

@C678: Another proposal would be to remove the entire {{Persondata}} template from pages in the Draft namespace. Since they are not articles, I'm guessing they wouldn't be candidates for copying to Wikidata. Thanks! GoingBatty (talk) 05:59, 12 September 2015 (UTC)

@GoingBatty and C678: What's the policy/process for Wikidata creation for new articles? Presumably, for newly created articles there is standard process -- automated? -- to create new Wikidata profiles. Can someone who is knowledgeable about this process describe it for our benefit? If this process exists, then there is no reason why articles in draftspace should have Persondata templates. That said, I can't imagine that we're talking about more than a few dozen to a couple hundred affected articles. Dirtlawyer1 (talk) 06:22, 12 September 2015 (UTC)

There is no reason for any article, much less one in draft space, to have a Persondata template. The template is been deprecated. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:17, 12 September 2015 (UTC)

@Dirtlawyer1: I'm not aware of automated process for Wikidata creation based on new Misplaced Pages articles. I'm also not aware of any policy that mandates that new article creators on Misplaced Pages also must manually create Wikidata. I would agree that the number of Draft articles with Persondata is a small number. GoingBatty (talk) 13:06, 12 September 2015 (UTC)

@GoingBatty: So, there is no established process for the creation of Wikidata profiles for newly created articles? That's a rather serious omission, don't you think? That said, I also recognize that it's beyond the scope of our present discussion. As for the Persondata templates in draftspace, it would seem that some form of notice should be provided to the draftspace article creators that Personadata has been deprecated, so that no further effort is expended. Dirtlawyer1 (talk) 14:12, 12 September 2015 (UTC)

@Dirtlawyer1: Just stumbled across Category:Wikidata tracking categories, which may interest you. GoingBatty (talk) 18:05, 12 September 2015 (UTC)

See that would be something that could be discussed in phase 2.—_Chat:Offline 06:11, 12 September 2015 (UTC)

@GoingBatty: Okay. What's the official count on Phase I? Has BattyBot run its full cycle? I just checked, and it appears to have removed the Persondata templates from something like 1,700 articles. Dirtlawyer1 (talk) 06:22, 12 September 2015 (UTC)

@Dirtlawyer1: I got all the low hanging fruit first, and now it's going through the first million transclusions of Persondata. However, I'm not anticipating a significant number of additional removals. GoingBatty (talk) 13:06, 12 September 2015 (UTC)

@Dirtlawyer1:  Done - I estimate less than 2,000 944 removals. Only 1.2 million to go. GoingBatty (talk) 02:56, 15 September 2015 (UTC)

@GoingBatty: I understand what you're trying to do with your phase II proposal above. It is predicated on the idea of data preservation, i.e., does the same data exist somewhere in the existing article. My concern is data transfer, i.e. the transfer of Persondata information to Wikidata. So here's my fundamental question for you: why aren't we comparing Persondata to Wikidata? Dirtlawyer1 (talk) 14:21, 12 September 2015 (UTC)

@Dirtlawyer1: Yes - data preservation (by eliminating redundant data first) so that others more technical than I am can continue their efforts of data comparison and data transfer. My proposal also assumes that those who have the technical skills to do data transfer from Persondata to Wikidata could also do data copying from infoboxes and categories to Wikidata. GoingBatty (talk) 14:35, 12 September 2015 (UTC)

"so that others... can continue their efforts of data comparison and data transfer" - I'm not clear what part of this you're having trouble with: but to clarify, again: Those people have already migrated all the data which it is possible and sensible to automatically migrate. They then discussed the results on both Wikidata and Misplaced Pages, including the errors fund and the unreliability of parts of it, and as a result it was agreed at both projects - in the case of this Misplaced Pages, via an RfC - that what could be done had been done, and that no more should be done, and that the Persondata template is deprecated and should be removed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:30, 12 September 2015 (UTC)

Hey, Andy, once again, you've overstated your case, and that's why we're having this discussion now. You have repeatedly cited the May 2015 RfC as the basis for the deprecation and immediate removal of Persondata by the use of bots. In case you have forgotten, when asked for clarification on his user talk page, here's what the May 2015 RfC closing administrator had to say:

Andy, ping me off-wiki. You are in danger of WP:NCR. Seriously, calm down, it can be done slowly and methodically, and let people come to terms with it over a period of time. Seriously, just chill a bit and you'll win the battle for hearts and minds. Nobody doubts your commitment or passion, but you have a positive genius for rubbing people up the wrong way! Guy (Help!) 21:57, 2 June 2015 (UTC) .

That's what the RfC closing administrator had to say, in addition to offering you some excellent personal advice. Do you really want me to post the RfC closing administrator's clarification under every comment where you claim the RfC as authority for the immediate bot removal of all Persondata information? Dirtlawyer1 (talk) 18:29, 12 September 2015 (UTC)

@Pigsonthewing: You're at one extreme, and Dirtlawyer1 is the other extreme - I'm just trying to find the middle ground. Dirtlawyer1 is very interested in data transfer to Wikidata, and is doing so manually. Maybe Dirtlawyer1 will find someone to migrate more data programmatically, and maybe he won't. I've done a little data transfer from Persondata to other areas of the Misplaced Pages article (e.g. infoboxes and categories) - maybe there's opportunity for moving more programmatically and maybe there isn't. Agreeing on any set of Persondata to programmatically remove gets us closer to your goal of removing all of it. GoingBatty (talk) 18:05, 12 September 2015 (UTC)

I don't believe it's "extreme" to remind people of the outcome of a well attended, and convincingly decisive, RfC. And thank you, but we don't need to find the "middle ground" between that consensus and one extreme. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:12, 12 September 2015 (UTC)

Andy, here's what the May 2015 RfC closing administrator had to say:

Andy, ping me off-wiki. You are in danger of WP:NCR. Seriously, calm down, it can be done slowly and methodically, and let people come to terms with it over a period of time. Seriously, just chill a bit and you'll win the battle for hearts and minds. Nobody doubts your commitment or passion, but you have a positive genius for rubbing people up the wrong way! Guy (Help!) 21:57, 2 June 2015 (UTC) .

Do we really need to quote it every time when you cite "the outcome of a well attended, and convincingly decisive, RfC"? Dirtlawyer1 (talk) 18:29, 12 September 2015 (UTC)

You've had a "period of time". May was four months ago. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:58, 13 September 2015 (UTC)

@Pigsonthewing: "Extreme" was a poor word choice - I apologize. Unfortunately, repeating the RfC outcome doesn't seem to be helping. @Dirtlawyer1: No, you don't need to post the wall of bold text again - we got it. I fear that we're not going to make any significant steps forward until the two of you can come to some agreement. GoingBatty (talk) 02:33, 15 September 2015 (UTC)

It looks more like we need to wait until Dirtlawyer1 finds an agreement with the rest of us users who support removal of persondata. If a bot removes persondata, editors watching articles will notice on their watchlists when that happens. If they care they will check what has been removed and - if needed - place it at an appropriate place in the article. I trust us editors and am not afraid of a loss of data. Keep simple. (I also made a suggestion in the section above how keeping data could be done by the bot, which I don't want to repeat again.) --Gerda Arendt (talk) 07:02, 15 September 2015 (UTC)

I've not really been following the details, but this remark does not seem very sensible to me. Much more likely is that most editors will simply trust that the bot, which would have been given approval for this action, would know that every relevant piece of information had already been migrated. It doesn't seem like a good idea to have editors managing the fallout. Granted, those that are "in the know" will probably check up on the bot, but the majority of us will just ignore it. Also, I question the logic of doing this at all by an automated process if a massive decentralized volunteer effort is going to be needed to clean up afterwards. It seems simpler to me to have volunteers migrate the data in the first place. As I understand it, that's how things are currently being handled. Sławomir
Biały 10:31, 2 October 2015 (UTC)

Colsure request

I've de-archived the above; could somebody uinvolved close it, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:03, 1 October 2015 (UTC)

• Oppose immediate closure - I strongly oppose the request for an immediate closure of this RfC: this discussion is NOT RIPE FOR CLOSURE. Previous discussions of Persondata have significantly misrepresented the status of accurate and usable information from Persondata, as well as the extent of previous bot efforts to transfer information from Persondata to Wikidata. I am happy to review my own empirical review and comparison of over 1500 Persondata templates to their corresponding Wikidata profiles. This is one of sloppiest technical processes that I have witnessed in my six and a half years of editing the English language Misplaced Pages. We need an orderly process to continue to discern what remains that is usable, and transfer accurate information from Persondata to Wikidata, not simply delete all of it by mindless bot action without review. Dirtlawyer1 (talk) 22:06, 1 October 2015 (UTC)
  • Of course you do; having this drawn out serves your bizarre objection to enacting the existing RfC conclusion; which RfC was "an orderly process to discern what remains that is usable". Nonetheless this discussion is so over that it was already archived. If there is consensus for your PoV, why would you object to having that noted in a closing statement? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:50, 2 October 2015 (UTC)

Language profile

I don't understand why the feature to select personal spoken languages in my own profile settings is missing! If you read a lot and switch between different languages it is unpleasant to select the desired language from the list, because it is so long. Most people (99%) will only want to read articles in 1-4 languages, i guess. Implementing this feature should be quite simple; it should take a good programmer less then a day. Looking forward on your comments! — Preceding unsigned comment added by Atom Materialist (talk • contribs)

Spark Energy / 2 different companies

The article for Spark Energy needs to be split into 2 articles, for 2 completely different companies. One based in the US and one in the UK. Victor Grigas (talk) 02:07, 29 October 2015 (UTC)

Proposed: Tag / edit filter for talk page abuse

Proposal

Create a special tag / edit filter designed to catch talk page abuse. (Example: )

Envisaged benefits

1. An edit filter could warn users before posting that their comment may need to be refactored to be considered appropriate.
2. Editors could check recent changes for tagged edits, bringing much-needed third eyes to talk pages where an editor may be facing sexual harassment and other types of abuse.
3. Prevention of talk page escalation.
4. Improvement of talk page culture.
5. Enhanced editor retention. Andreas JN466 15:51, 29 October 2015 (UTC)

• Support. Gamaliel (talk) 17:01, 29 October 2015 (UTC)
• Support without reservations.John Carter (talk) 18:39, 29 October 2015 (UTC)
• Support. But I think I'm missing the background/ context to that example. To me it looked like it could easily be interpreted as funny/ ironic. Or is this intended mainly as a sexist abuse filter? Martinevans123 (talk) 18:53, 29 October 2015 (UTC)
• Support. Excellent idea. Sarah 19:04, 29 October 2015 (UTC)
• Nice sentiment. Of course we want to prevent abuse, but the edit filter is a relatively blunt tool, with a high chance of catching false positives on talk pages. What exactly is the test being proposed? -- zzuuzz 19:07, 29 October 2015 (UTC)
• Not possible If regular expressions could identify abuse, what a world that would be. Rhoark (talk) 19:40, 29 October 2015 (UTC)
• Partial support Have to agree on Rhoark's point, particularly in the situation that as a uncensored work that in the course of productive discussion about certain topics, it may be necessary to use language that would easily trigger such a filter. Once also has to consider that what actually might be taken as harassing language by one editor will not be the same that others would consider harassing, and context can be everything. To make everyone happy, we'd have to include a lot of possible hits, and the more we'd have to include the more false positives we'd get. So a full site wide use of a filter would not really work. That said, I would support a filter that could be applied to editors that have been established through AN/AE that they may use language that borders on the uncomfortable that they should be warned if they veer into that again. Or to use on certain talk pages that have already been identified as a hot bed for near-personal attacks to warn users before posting in anger/haste. We'll still get false positives but they will be much more limited and would be much more manageable by admins. --MASEM (t) 20:09, 29 October 2015 (UTC)

This tool is apparently used to deal with cases of long-term abuse, and it might not be a bad idea to expand its use as a targeted discretionary sanction. Rhoark (talk) 20:16, 29 October 2015 (UTC)

I would say there is no shortage of admins and other editors who are willing to pick up on sanction violations without the need for filters or tags. -- zzuuzz 20:26, 29 October 2015 (UTC)

Many cases seem to call for a response stronger than a warning but less extreme than a topic ban. Nuanced sanctions however have proven to be an invitation for baiting the sanctioned editor and playing gotcha. An automatic referee could help in this. Even if not automatically enforced, a code-level specification of the restriction could lower the volume. Rhoark (talk) 20:55, 29 October 2015 (UTC)

Not knowing the technical way this can be done, an ideal use would be where if an editor makes an edit that triggers this filter, that instead of immediately applying the new edit, to provide a warning screen "Hey, this page is prone to issues with such language, please consider rewording your edit, or proceed if you take full responsibility for the language and may be subject to administrative actions if deemed inappropriate." If the editor proceeds, that then would tag the admin flag , if needed. As long as that is used on sets of talk pages aggressively prone to personal attacks and harassing-type language, that should hopefully make editors think twice before posting, cutting down the amount of work admins have to do. But I am not sure if an edit filter can trigger a secondary edit submission check. --MASEM (t) 21:05, 29 October 2015 (UTC)

I'm fairly certain it can. For example, if you put a sanctions notification on someone's talkpage, you'll be prompted to make sure its not a duplicate. I think that's done with this system. Rhoark (talk) 21:52, 29 October 2015 (UTC)

It can indeed; see 2. below (which is copied from Misplaced Pages:Edit_filter). And the first step might well be to pilot such a system on known problem pages. Andreas JN466 05:37, 30 October 2015 (UTC)

• Support, though it should not be preventing any edits, just tagging. The potential for false positives is high. GorillaWarfare (talk) 21:18, 29 October 2015 (UTC)
  • Available edit filter options are:
    • When an edit being saved "triggers" an active filter, the effect depends on a setting associated with that particular filter:
      1. Under the strongest setting, the edit is rejected, and the user sees a message to that effect. (A link is provided for reporting false positives.) It is also possible to have a user's autoconfirmed status revoked if a user trips the filter.
      2. Under a less severe setting, the user is warned via a customisable message that the edit may be problematic. The user then has the option to either proceed with the save or abandon the edit.
      3. Under an even lower setting, the edit is tagged for review by patrollers.
      4. Under the lowest setting the edit is merely added to a log. (This setting is also used in tests of new filters.)
  • I think we would be shooting for 2, i.e. merely a reminder to think about the edit before clicking Save. ClueBot is very smart these days; over time, this filter could become similarly smart, recognise verbal abuse, sexual harassment (there should rarely be a need for someone to say something like "you turn me on", per the example linked above), etc. The tag would simply help getting more eyes on talk page conversations that may have taken a problematic turn. Andreas JN466 22:47, 29 October 2015 (UTC)

After an extensive period of training and refining a filter, it might not be harmful to enable it site-wide at an advisory level only. I'm pretty sure it wouldn't have made a difference to Qworty though. Rhoark (talk) 00:56, 30 October 2015 (UTC)

The difference is that edits like that, happening in some backwater of Misplaced Pages, would have been flagged, and attracted other editors' attention much sooner. Andreas JN466 01:18, 30 October 2015 (UTC)

• Comment What exactly is 'talk page abuse'? The edit filter is very literal and can't be told to just look for 'abuse'; if you can provide some examples of text strings which in the vast majority of cases imply abusive behaviour, which aren't already caught by an existing filter, then that would be more useful. Sam Walton (talk) 22:42, 29 October 2015 (UTC)
  • It would require an effort similar to the one that went into ClueBot and its descendants like ClueBot NG, and a lot of brainstorming. Women editors I am sure could provide examples of sexual harassment, belittlement or other gender-tinged exchanges they found offensive and wouldn't want to encounter again. Off the top of my head, words/strings like "rape you" or "stupid whore" are unlikely to have many bona fide uses. Similarly, "fuckwit", "fuckwad", "you fucking cunt", "you asshole", "fuck you", "you dumbass" etc. are most likely to be used as terms of abuse indicating (or indeed initiating) a breakdown in communication that would benefit from an uninvolved editor having a look at what's going on. Generally speaking, an edit filter warning asking people to think twice about posting these strings would in many cases prevent escalation and reduce admins' and oversighters' workload. At any rate, the strings to be caught should be based on actual user experience of the kinds of exchanges that tend to make talk page discussions go south and contribute to an off-putting atmosphere. I am under no illusion as to the amount of work this would require. But similar work has been done to cut down on article vandalism, with outstanding results, and improving the working climate would to my mind justify another such effort. Andreas JN466 05:24, 30 October 2015 (UTC)
  • Note: The above post of mine was not tagged in Recent changes, despite its abundance of strings that would be clearly problematic if used in an actual talk page discussion. Andreas JN466 05:26, 30 October 2015 (UTC)
• strongly oppose until and unless someone can define "talk page abuse" in a fairly specific way, and can at least outline an algorithm that could identify such abuse with pretty near zero false positives. I don't believe that it can be done at the current state of the art, even by a major AI effort, much less the resources available to a Misplaced Pages edit filter. Remember that it must permit detailed discussion of the content of sexually explicit articles, and so cannot simply block a list of words that are "profane" or "offensive". Any such filter must be able to correctly detect the context that makes a remark "abusive". I don't think this is possible, and anythign less ins IMO unacceptable. DES 01:27, 30 October 2015 (UTC)
  • Exceptions could be defined (talk pages of specific articles, etc.). I suspect ClueBot has similar capabilities today, and similar exceptions have been defined for pictures of gore etc. that have in the past been used for vandalism. Also bear in mind that no posts would be blocked; you'd still be able to post "You're a fucking fuckwit". This would merely remind people to consider potentially abusive posts carefully before clicking Save a second time, and present a tag in Recent changes enabling patrollers to have a look at what is going on. Or you could have the Recent changes tag only. Does this still sound unacceptable to you? Andreas JN466 01:59, 30 October 2015 (UTC)
    • Note quite so much, but I would still want to see a clear and specific definition of what is to be considered "abuse", and a detailed technical plan for the filter before I would support this. DES 03:12, 30 October 2015 (UTC)
• Oppose. In principle, this isn't a bad idea. In practice, I don't trust the subset of the community that will appoint themselves civility-tag first responders and go digging through potentially uncivil edits looking for people to wag their fingers at. I think you're creating a technical mechanism to reward superficially civil goading and baiting and punish the frustrated recipient of it. If you want to design an opt-in tool that will flag potentially problematic edits on your own talk page, great. Opabinia regalis (talk) 06:11, 30 October 2015 (UTC)

Redirect "TEN" (all caps) to "Toxic epidermal necrolysis"

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I would like to suggest that TEN (all caps), which presently redirects to 10 (number), be changed to point to Toxic epidermal necrolysis instead, as this would seem to be much more useful for encyclopedic purposes. If deemed appropriate, the latter article could have a headnote added reading, "TEN redirects here. For the numeral, see 10 (number)." (I considered doing this myself in the spirit of WP:BOLD, but decided it would be better in this case to ask first.)— Jaydiem (talk) 18:56, 29 October 2015 (UTC)

Auto sign on talkpages

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

Now that Flow is deprioritised, I suggest we default all new accounts to autosign on talkpages.

This would require a new preference "autosign on talk" which would default to signing all your posts on talkpages, and a new tick box on the edit screen "sign this edit".

Existing editors could blithely ignore this if they wished, but simply clicking "sign this edit" would be a new way to add a space and four tildas when wanted. New editors and editors who opt in by changing their preferences could still untick "sign this edit" when fixing a typo in their previous talkpage comment.

RFA and certain other pages where you are expected to sign could have a special template to enable autosigning

All welcome templates could have the clunky, offputting and very silly looking bit about please sign your posts on talkpages with ~~~~ removed.

The WMF is asking for community input into things they could do instead of FLOW - this could be one of them. ϢereSpielChequers 13:37, 3 September 2015 (UTC)

• Support - Good idea that's long overdue. The User:Sinebot does this as a cleanup measure anyway, and this would help demystify/declutter talk pages, which by almost every measure are a usability nightmare for newbies. -- Fuzheado | Talk 14:11, 3 September 2015 (UTC)
• Support - frankly this should be in MediaWiki itself. Suggested method: if it doesn't detect a ~~~~ it adds one. You can switch this off in your preferences. Everyone who already has an account starts with it switched off, everyone creating a new account starts with it switched on - David Gerard (talk) 14:15, 3 September 2015 (UTC)
• Support in the model suggested by David Gerard -> I have never understood why we rely on a bot to do this work, when we could just be signing as part of the software, Sadads (talk) 14:16, 3 September 2015 (UTC)

  One limitation should prevent edits to the header section of an article (such as infoboxes) from being signed. Sadads (talk) 14:17, 3 September 2015 (UTC)

• Comment How does Sinebot determine where to put the signature? Presumably this would use a similar algorithm. We would need some sophisticated algorithms or very clear opt-out boxes to avoid messing up e.g. talk page refactoring and archiving. BethNaught (talk) 14:20, 3 September 2015 (UTC)
  • There would be a new tick box on the edit screen "sign this edit". If you don't want to sign you untick it. ϢereSpielChequers 14:43, 3 September 2015 (UTC)
• Support, should indeed be in MediaWiki itself. Fundamentally a talk page should be more like a blog page with threaded comments. As an ordinary non-admin user, I should be able to make posts like this one with the software autosigning, and edit them afterwards without having to specially turn off autosign but with the software either replacing the autosignature (not adding another one) or adding a small text such as "edited ". But as an ordinary non-admin user, I shouldn't be able to edit other people's posts, which AFAIK I can, though I've never tried. Stanning (talk) 14:48, 3 September 2015 (UTC)
• Support This is a great idea. I have proposed an addon on below.—_Chat:Online 15:24, 3 September 2015 (UTC)
• Support, provided there is a clear opt-out so correcting a typo etc. does not result in another signature. If the function could be clever enough to detect when I am just editing my own, already-signed post, all the better. Andreas JN466 16:11, 3 September 2015 (UTC)
• Comment If implemented it in JavaScript it could be running by next week. Doing it JS gives us better interactivity with the user and it would be open source unlike User:SineBot. Why wasn't it suggested before? Oh right: "FLOW is going to fix discussions". — Dispenser 17:39, 3 September 2015 (UTC)
• Support. I didn't even know WP:FLOW had been deemphasized! --IJBall (contribs • talk) 19:46, 3 September 2015 (UTC)
• Support. A sensible improvement to the current talk system. Should really be in core MediaWiki. MER-C 01:11, 4 September 2015 (UTC)
• Support - as long as there is the choice to untick the box, e.g. for minor corrections to talk posts that I've already signed. Smallbones_(smalltalk) 13:41, 4 September 2015 (UTC)
• Support, especially the "special template" to enable autosigning, which is a great idea. APerson (talk!) 18:25, 4 September 2015 (UTC)
• Support a great idea, new users can integrate more easily with one less of Misplaced Pages's many idiosyncracies to master. --Tom (LT) (talk) 00:49, 5 September 2015 (UTC)
• Support - I concur with the above this really should be part of the MediaWiki software, I have a quite few newbies who post on my TP and never sign there posts and seeing as the bot never shows up it means I have to do it myself and quite frankly it's a pain in the arse at times (Admittingly I don't have to do it but I prefer them all signed & dated), Anyway it's a great idea!. –Davey2010 01:08, 5 September 2015 (UTC)
• Oppose as proposed. Many, many users have different signatures from their usernames, or have designed personalized signatures well within our signature guideline that are as much a part of their Misplaced Pages identity as their contributions history. The four tildes is what pretty much every experienced Wikipedian uses, not the "sign this edit" button (which on my screen is in the middle of a long string of small boxes and it doesn't even say "sign", it's just a representation of cursive writing). It also disenfranchises new users from participating in non-talk pages where signatures are expected, which encompasses most pages in Misplaced Pages space, and some in other areas, because they will never figure out how to do it. Risker (talk) 03:05, 5 September 2015 (UTC)
  • @Risker:, We are not proposing to replace tildes with a button, we are proposing to allow users to eliminate both. The intention is that the page is automatically signed with your signature, not a generic one. If you set the auto-sign user preference, you wouldn't need to type tildes or click a button, it would just do it for you like it should. Also, using categories or magic words, the software would also sign pages that are used as discussions even if they don't have talk in the name. Oiyarbepsy (talk) 00:00, 6 September 2015 (UTC)
• Support although it's pointless to do so, since AFAIK this is a WONTFIX issue; would've been done a long time ago if it weren't. Signing is one of our more ridiculous and archaic-looking insider shibboleths. It's also a PITA on mobile, and anything that can make editing on mobile less of a dumpster fire of awfulness is a good idea. Opabinia regalis (talk) 03:59, 5 September 2015 (UTC)
• Support If a bot can figure out how to do this then the interface can just use similar logic. Andrew D. (talk) 09:59, 5 September 2015 (UTC)

  I think Sinebot limits itself to new posts at the end of a section. This is precisely because it couldn't reliably figure out the correct action in other situations. If you add a new unsigned comment in the middle of a thread, the bot won't help you. The bot is also restricted to certain talk spaces. Thus a bot comparison isn't particularly apt. ―Mandruss ☎ 09:20, 6 September 2015 (UTC)

• Conditional support - I think this is a good idea, particularly for mobile devices, as in some mobile keyboards the tilde "key" is hard to find. However, I have one issue regarding how this could work: how would this work if a user adds more than one paragraph or replies to separate paragraphs in the same edit? For example, what if I reply at this section and the section below in the same edit? Would it only sign one of my additions or both? Also, if this proposal is to pass, the coverage could also be expanded to include pages outside of Talk namespaces, such as noticeboards and the Reference desk (i.e. any page in Category:Non-talk pages that are automatically signed. Narutolovehinata5 15:48, 5 September 2015 (UTC)

  Good point, but probably a rare/advanced user one. I suspect if you reply to more than one thread in the same edit it will only sign one of them, however by the time people are doing that they are likely to have learned how to get round that. ϢereSpielChequers 09:52, 7 September 2015 (UTC)

• Support We already have bots that do this, so I see no reason why it can't just be done automatically whenever a talk page edit is made. Spirit of Eagle (talk) 22:41, 5 September 2015 (UTC)
• Oppose People often edit their own comments or make other talk-page edits that don't involve the addition of new comments and shouldn't be signed. Sometimes, people even remove their own comments that they believe to be inappropriate. Even IPs often do this, especially in the case of people who edit frequently without accounts. These edits should never be signed; how would the software detect this kind of thing? However, I would support auto-signing of comments added through the add-a-new-section button, since those always should get signatures. Nyttend (talk) 23:52, 5 September 2015 (UTC)
  • @Nyttend: There would be a checkbox saying sign this post that would be automatically checked. Users who are deleting or editing would simply uncheck the box. Oiyarbepsy (talk) 00:03, 6 September 2015 (UTC)
• Oppose A lot of article talk pages have a large top section that that contains things like ArbCom notices, old AfD notices, GA nom notices, etc. There is also the issue where at times you'll want your signature to be one space behind you post, at other times on a new line below it. It also lets you know about a user's competency as to whether they add a signature or not. Jerod Lycett (talk) 08:59, 6 September 2015 (UTC)
• Support Support as opt-in, Oppose as opt-out Oppose - Which is harder, typing the tildes or clicking the button when you need a sig, or unchecking the box when you don't? Seems like a wash to me, but I'm willing to support giving it a try if WMF is willing to do it. It's completely opt-in, it affects no one who doesn't want it, so the worst case is that we keep a former Flow developer employed for awhile and then have to yank the feature back out in a few years because of lack of use. I could live with that worst case. ―Mandruss ☎ 09:37, 6 September 2015 (UTC)
  • The proposal by DavidGerard is opt-out, not opt-in. The proposal is to give this to everyone by default and then to let people opt-out if they don't like it (and if they can find a prefs switch in the long list of gadgets). I'd be opting out immediately, of course. WhatamIdoing (talk) 16:06, 6 September 2015 (UTC)
    • @WhatamIdoing: That's incorrect. This proposal is as I said at the top for "New editors and editors who opt in" David Gerrard added a suggested methodology, but he stuck with the same "opt in for existing accounts, opt out for new ones" logic. Nobody is suggesting the opt everyone in approach that WhatamIdoing opposes. ϢereSpielChequers 16:08, 8 September 2015 (UTC)
    • I stand corrected, thanks. New optional features should generally be opt-in, and this is especially true when a feature affects everyday work to such a degree. It would be highly disruptive to throw this in and force everyone to adapt immediately or change their prefs immediately. Modified my !vote. ―Mandruss ☎ 00:29, 7 September 2015 (UTC)
    • The ideal would be opt-in for existing users and opt-out for new users, making this even more messy. If this was at VPI first, I'm surprised this didn't come up there, or, if it did, I'm surprised the consensus there was opt-out for everyone. Sorry I missed that. But this Misplaced Pages thing is a messy business all around. ―Mandruss ☎ 01:55, 7 September 2015 (UTC)
      • That might be possible, although it's my impression that it would not be quick and easy. WhatamIdoing (talk) 02:50, 7 September 2015 (UTC)
        • Although I know nothing of the internals, the impression I have from decades in development is that it shouldn't be any harder at all. Seems to me there will be necessarily be two pieces of software involved: (1) a one-time mass update to add the new field to existing prefs, and (2) the code to create a new user. If that's the case, the former could set the fields to "off" and the latter to "on". But who knows. ―Mandruss ☎ 04:59, 8 September 2015 (UTC)
  • Alrighty Then. Per WereSpielChequers's comment above, there's apparently some confusion here as a result of failure to nail down the particulars at VPI first. In any case, if Quiddity (WMF) is to be believed below, and they are in a position to know, opt-in for existing users is not a practical possibility. Since I can't live with opt-out for existing users, I'm left to Oppose. As I said, it's a wash anyway, largely trading one editor effort for another. I'm modifying my !vote, again. ―Mandruss ☎ 09:26, 10 September 2015 (UTC)
• Strongest possible support. The Opt-OUT idea is good as are some of the other technical suggestions for identifying the kind of pages or edits. Kudpung กุดผึ้ง (talk) 05:26, 8 September 2015 (UTC)r.
• Comment There are a couple of key points:

• This proposal is not possible as phrased, because it is asking to turn the gadget off for 25 million existing accounts, but to turn it on for two or three million new accounts each year. This is not possible without some big changes to the performance of the preferences system in MediaWiki, and hacks to implement it would lead to the same performance issues described in the discussion about how to solve exactly this performance problem for VisualEditor (i.e. millions of accounts adding a new preference). Ultimately the developers would come in and switch anything like this off to save the site from falling over.
• If a gadget is used, then to satisfy the requirements of being available for all newcomers (optionally including IP-editors), it would need to be "default on for everyone", with the usual gadget opt-out possibility for experienced users (as we have with Reference Tooltips, for example).

If we do decide to experiment with a gadget, there's an existing userscript at Dewiki (w:de:Benutzer:Perhelion/signing), which appears to generally work as expected. It will have all the limitations that Sinebot does, and possibly more. Creating something more reliable is an extremely difficult goal (because of all the edge-cases), which is why it hasn't been solved in the last 15 years. HTH. Quiddity (WMF) (talk) 18:03, 9 September 2015 (UTC)

• • We now have a range of opinions on the technical side from this needing a week to it not being possible. While I'm not a mediawiki coder, I've been in IT for long enough to know that if the decision is to go ahead the reality will be somewhere in between. We might at worst have an entirely opt in system where we can at least amend all our welcome templates to give people a choice between learning to type tildas or clicking something to set a user preference; That would of course still be a big win. In the meantime can I suggest that we focus this discussion on whether we want to introduce an autosign system with an opt out for existing accounts and an opt in for new ones; And can I point out to those who believe in Flow, that Flow would be resented by fewer if its price didn't include a blanket veto on any attempt to improve the existing software. ϢereSpielChequers 11:00, 10 September 2015 (UTC)

@WereSpielChequers: I now see at least some rationale for opt-in for new users, I guess. I still can't see forcing 120,000 active users to adapt immediately or change prefs immediately; that is, unless we made it extra challenging for the developers and required some kind of pop-up "Do you want this or not?" the first time they edit a talk space after the change. The pop-up would then set the prefs according to the answer given. Without something like that, how are 119,800 of those users going to know about the change and how it affects them? I don't see anything about that in the proposal.
I'd support opt-in for everyone, but this proposal seems pretty much off the rails to me and a new one would be in order (maybe after another round at VPI). I know, it's incredibly messy and frustrating, I've been there. ―Mandruss ☎ 14:28, 12 September 2015 (UTC)

• Oppose per Nyttend. New editors will be annoyed with the fact that their copyedits will be auto-signed, causing a random signature to show up at the end of their copy edits. Also, this proposal assumes that the editor will be knowledgable enough to navigate to the preferences page to disable this feature, which is bad to assume. It would be more efficient for a bot to place an {{Unsigned}} template after the comment, then place some sort of warning message on accounts that fall under the "new" criterion as outlined in this discussion (provided that bot had not already been created.) Steel1943 (talk) 22:28, 11 September 2015 (UTC)
• Support awesome idea Datbubblegumdoe_contribs 01:03, 15 September 2015 (UTC)
• Support This is a good idea for signing talk pages. I recommend thgis be applied across all projects. There could be some editors who forget to sign their comments and other correspondence (I have sometimes as well), but a bot autosigns it. Still, it's an aye from me. Sam.gov (talk) 22:48, 16 September 2015 (UTC)

Set default discussion pages

In conjunction to the proposal above, I believe it is technically possible to implement this. All odd numbered namespaces are talk pages are extremely likely to be talk pages. The system could have magic words such as __NODISCUSSION__ and __ISDISCUSSION__, where the automatically leave the option unticked, or automatically tick it, respectively.

• Support as proposer.—_Chat:Online 15:24, 3 September 2015 (UTC)

• Magic words that could be used for this purpose already exist: NONEWSECTIONLINK and NEWSECTIONLINK. Cenarium (talk) 16:57, 3 September 2015 (UTC)

  Fair enough.—_{Chat:Limited Access} 17:19, 3 September 2015 (UTC)

@Cenarium and Cyberpower678: Wait, unless I've misunderstood something, there are some discussion pages that do not use the "new section" link, AfD discussions being the first that come to mind. Mz7 (talk) 00:43, 6 September 2015 (UTC)

• Comment: any subpages of Misplaced Pages talk:Articles for creation need to be excluded are they are article drafts. BethNaught (talk) 21:11, 5 September 2015 (UTC)

Last year, the AFC project made the change from the Misplaced Pages talk namespace to the Drafts namespace. I do not believe there are still AFC drafts in the Misplaced Pages talk namespace, so I'm not sure if this exclusion would be necessary. Mz7 (talk) 00:46, 6 September 2015 (UTC)

Doesn't look necessary. Eman235/talk 00:59, 6 September 2015 (UTC)

Slipped my mind to do a prefix search. It actually does look like it might be necessary. (The prefix is "Articles for creation" not "WikiProject Articles for creation".) While there aren't any pending drafts currently in the Misplaced Pages namespace, there does appear to be a significant number of declined and old WP:CSD#G13-postponed drafts still there. Mz7 (talk) 02:13, 6 September 2015 (UTC)

A better looking list is at WP:Requested moves/Old AFC submissions. 103.6.159.77 (talk) 13:11, 20 September 2015 (UTC)

• Comment 2 We already have Category:Non-talk pages that are automatically signed Oiyarbepsy (talk) 23:55, 5 September 2015 (UTC)

Move to Misplaced Pages:Village pump (proposals)?

I was going to add my support to the discussion above, but I was hit by the edit notice for the page, which says it's not for consensus polling. Since there has been a rather overwhelming outpouring of support for this idea, and also since it's been listed on WP:CENT, I think this idea should be given the okay to move to the proposals village pump (the entire discussion above should probably be moved there). Mz7 (talk) 02:44, 5 September 2015 (UTC)

Agreed. This is no longer an idea lab.—_{Chat:Limited Access} 15:02, 5 September 2015 (UTC)

 Done Mz7 (talk) 22:34, 5 September 2015 (UTC)

• Misplaced Pages village pump
• Misplaced Pages proposals
• Pages automatically checked for accidental language links