Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Pigsonthewing (talk | contribs) at 16:22, 27 October 2015 (→‎Removing Persondata: typo). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

New ideas and proposals are discussed here. Before submitting:


Village pump (proposals) archive  

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

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

Consensus is to merge NFCR and FFD into one process, called "Files for Discussion". No real discussion into merging WP:PUF into this now, but that can come later. Mdann52 (talk) 08:40, 27 October 2015 (UTC)[reply]

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 Wikipedia:Non-free content review be shut down as historical while referring editors to use Wikipedia: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 Wikipedia (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 Wikipedia: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.)
Very simply put, if a non-free file is not used per WP:NFCC, the file should be deleted immediately. The purpose of WP:FFD is to determine if a file needs to be deleted. However, there is another point from the the MFD discussion above that needs to be considered during this discussion:

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?

For this question, I recommend that WP:FFD be updated to allow an outcome that specifically states that the image "should be kept, but removed from this article". This will benefit closes if these discussions happen on WP:FFD since it could be possible that during the course of the discussion, a non-free file that is on multiple articles but is nominated to be removed from only one article could very well be determined needed to be removed from Wikipedia altogether (which results in the file being deleted.) On a minor distracting note, if this change were to be made to the possible WP:FFD close results, the page may need to be renamed from Wikipedia:Files for deletion to Wikipedia:Files for discussion since the nomination purpose and outcome could then be something other than deletion. (This idea is similar to the fact that WP:RFD is named "Wikipedia:Redirects for discussion" instead of "Wikipedia:Redirects for deletion" since pages are nominated there for reasons other than deletion.) Steel1943 (talk) 21:57, 2 October 2015 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • (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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
    • 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)[reply]
    • 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)[reply]
  • 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)[reply]
    • 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)[reply]
      • 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)[reply]
        • 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)[reply]
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)[reply]

  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Do we have a research template?

Do we have a template like Bulbapedia's MoveResearch? (For articles in general that need research). It would be great if we had one. If we already have something that serves this purpose, tell me here. Hop on Bananas (talk) 15:04, 3 October 2015 (UTC)[reply]

What do you mean by "research"? Original research is not allowed on Wikipedia. For templates that indicate that more or better sources are needed or the article needs to be expanded or improved see: Wikipedia:Template messages/Cleanup. Finnusertop (talk | guestbook | contribs) 19:49, 3 October 2015 (UTC)[reply]

"Original research is not allowed on Wikipedia". Duh, I knew that. I was looking for a template for articles with missing information (which might as well have reliable sources). Hop on Bananas (talk) 17:59, 12 October 2015 (UTC)[reply]

"need research" is very vague. See Wikipedia:Template messages/Cleanup#Expand and add and note Template:Expand. PrimeHunter (talk) 22:58, 12 October 2015 (UTC)[reply]

Okay, that seems close enough. For the record, I was looking for: 

This page is in need of research. Reason: (insert reason here) You can discuss this on the talk page.

I guess {{Missing information}} is good enough.

 – Hop on Bananas (talk) 12:54, 18 October 2015 (UTC)[reply]

Worth looking at the discussion in which the {{Expand}} template was depreciated: Wikipedia:Templates_for_discussion/Log/2010_December_16#Template:Expand. There is an understanding that ALL articles on Wikipedia need improving, and that simply tagging an article as such is not that helpful. And to get a fuller appreciation of why tagging an article as needing general improvement is not helpful, spend some time working through Wikipedia:Backlog. Pick a section, say Category:BLP articles lacking sources from October 2006, and look at the first article in that category: Tracey Cox. What has happened since it was tagged in Oct 2006? It has been tagged twice more, in 2008 and 2010, as needing improvement. There is a school of thought that rather than more tagging, what is needed is more actual work done on articles. Tagging is usually asking someone else to do it. As we see from the backlog, there is no-one else spare to do the work. If you spot that work needs doing, then it would be more beneficial to do the work yourself. SilkTork ✔Tea time 22:42, 20 October 2015 (UTC)[reply]

Trans-Pacific Partnership protest

Wikisource has original text related to this article:

Is Wikipedia 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)[reply]

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)[reply]
See Wikipedia:SOPA initiative. Basically Wikipedia 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)[reply]
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)[reply]
Added helpful information from Electronic Frontier Foundation, linked above. — Cirt (talk) 11:53, 21 October 2015 (UTC)[reply]

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

Deletion to Quality Award

I've created the WP:Deletion to Quality Award.

This recognizes editors who've taken a page previously considered for deletion — to Featured Article or Good Article quality.

The award is inspired by the Wikipedia:Million Award, the Wikipedia:Article Rescue Squadron, and the Wikipedia:WikiProject Quality Article Improvement.

Please see Wikipedia:Deletion to Quality Award.

Thank you,

— Cirt (talk) 00:35, 21 October 2015 (UTC)[reply]

RfC

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

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

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

TAFI & main page discussion

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


Internal Hyperlinking of Wikipedia article

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

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 Wikipedia 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)[reply]

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

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

WikiHisotry 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

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

Wikipedia 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)[reply]


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.
There is consensus to have a bot remove all the persondata from all the articles. The majority argument is that the sooner this is done, it will stop additional wasted effort of those adding persondata. As a side note there is common sense coming from the minority and even some supports. That the removal be done in steps and that moving what has not been moved to wikidata to some other place so that it can be done at a later date is a good plan that may save time of less informed editors. But there can not be said to be consensus for this, though I see no opposes. AlbinoFerret 16:10, 27 October 2015 (UTC)[reply]

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

Wikipedia:Bot requests/Archive 64#Remove persondata is the request for a bot that Andy mentions. --Izno (talk) 15:59, 9 September 2015 (UTC)[reply]
  • 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 Wikipedia 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 talk 11:10, 8 September 2015 (UTC)[reply]
    • @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)[reply]
  • Question - Has all of the Persondata been migrated to Wikidata? That would seem to be a prerequisite. - MrX 13:33, 8 September 2015 (UTC)[reply]
    • 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)[reply]
  • Support. While I respect and endorse the BOTREQ groups desire for caution, that discussion already happened. Resolute 13:38, 8 September 2015 (UTC)[reply]
  • 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. –Davey2010Talk 17:00, 8 September 2015 (UTC)[reply]
  • 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)[reply]
  • Support – it's definitely time to do this now. --IJBall (contribs • talk) 20:28, 8 September 2015 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
    • 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)[reply]
      • 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)[reply]

      • 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)[reply]
  • 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)[reply]
    • 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)[reply]
  • Support Helder 00:23, 9 September 2015 (UTC)[reply]
  • Support – RGloucester — ☎ 01:24, 9 September 2015 (UTC)[reply]
  • Support for all the obvious reasons. ~ RobTalk 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. ~ RobTalk 21:07, 9 September 2015 (UTC)[reply]
  • 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 "Talk to Me" 04:00, 9 September 2015 (UTC)[reply]
    • 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 "Talk to Me" 22:05, 9 September 2015 (UTC)[reply]
  • 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)[reply]
    • 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. ~ RobTalk 11:29, 9 September 2015 (UTC)[reply]
      • @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)[reply]
    • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Support, --Gerda Arendt (talk) 16:36, 9 September 2015 (UTC)[reply]
  • 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)[reply]
  • 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 [1] 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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
@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)[reply]
(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. ~ RobTalk 19:52, 9 September 2015 (UTC)[reply]
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)[reply]
You support removing Persondata from any article that has had all appropriate information transferred already, correct? ~ RobTalk 20:33, 9 September 2015 (UTC)[reply]
@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)[reply]
You're misquoting me. Please desist. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:19, 9 September 2015 (UTC)[reply]
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)[reply]
"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)[reply]
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)[reply]
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)[reply]
@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 Wikipedia 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)[reply]
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)[reply]

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

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. ~ RobTalk 21:32, 9 September 2015 (UTC)[reply]
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)[reply]
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. ~ RobTalk 22:44, 9 September 2015 (UTC)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
    • @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: [2]. 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 Wikipedia and Wikidata, than the immediate deletion of all Persondata. Dirtlawyer1 (talk) 23:54, 9 September 2015 (UTC)[reply]
      • 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)[reply]
      • 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)[reply]
  • 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)[reply]
    • @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. ~ RobTalk 21:32, 10 September 2015 (UTC)[reply]
      • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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(talk) 21:24, 14 September 2015 (UTC)[reply]
  • 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)[reply]

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?—cyberpowerChat:Offline 09:21, 11 September 2015 (UTC)[reply]

I should point out that number 1 is already being worked on.—cyberpowerChat:Offline 09:24, 11 September 2015 (UTC)[reply]
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)[reply]
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)[reply]
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.—cyberpowerChat:Online 21:11, 11 September 2015 (UTC)[reply]
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)[reply]
Which step? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:54, 11 September 2015 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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. ~ RobTalk 04:52, 12 September 2015 (UTC)[reply]
@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)[reply]
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.—cyberpowerChat:Offline 06:11, 12 September 2015 (UTC)[reply]
@C678: Sorry for misunderstanding. I appreciate your efforts in proposing this path forward. GoingBatty (talk) 13:16, 12 September 2015 (UTC)[reply]
@Pigsonthewing: BattyBot just edited 34 articles that had a blank {{Persondata}} template (e.g. [3], [4], [5], [6], [7]). GoingBatty (talk) 05:11, 12 September 2015 (UTC)[reply]
@Pigsonthewing: BattyBot also has edited articles that had a full {{Persondata}} template with no values (e.g. [8], [9]). GoingBatty (talk) 05:38, 12 September 2015 (UTC)[reply]
Thank you for clarifying. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:13, 12 September 2015 (UTC)[reply]
@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)[reply]
@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)[reply]
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)[reply]
@Dirtlawyer1: I'm not aware of automated process for Wikidata creation based on new Wikipedia articles. I'm also not aware of any policy that mandates that new article creators on Wikipedia 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)[reply]
@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)[reply]
@Dirtlawyer1: Just stumbled across Category:Wikidata tracking categories, which may interest you. GoingBatty (talk) 18:05, 12 September 2015 (UTC)[reply]
See that would be something that could be discussed in phase 2.—cyberpowerChat:Offline 06:11, 12 September 2015 (UTC)[reply]
@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)[reply]
@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)[reply]
@Dirtlawyer1:  Done - I estimate less than 2,000 944 removals. Only 1.2 million to go. GoingBatty (talk) 02:56, 15 September 2015 (UTC)[reply]

@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)[reply]

@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)[reply]
"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 Wikipedia, 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 Wikipedia, 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)[reply]
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) [10].[reply]
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)[reply]
@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 Wikipedia 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)[reply]
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)[reply]
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) [11].[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]

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

  • 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 Wikipedia. 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)[reply]
    • 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)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=687765780"