Content deleted Content added
Lowercase sigmabot III (talk | contribs)
m Archiving 4 discussion(s) to Wikipedia:Village pump (proposals)/Archive 127) (bot
PrimeHunter (talk | contribs)
→‎top: start=110 to include existing archives up to 110+25
Line 1: Line 1:
<noinclude>{{pp-move-indef}}{{Village pump page header|Proposals|alpha=yes|start=100|
<noinclude>{{pp-move-indef}}{{Village pump page header|Proposals|alpha=yes|start=110|
New ideas and proposals are discussed here. ''Before submitting'':
New ideas and proposals are discussed here. ''Before submitting'':
* Check to see whether your proposal is already described at '''[[Wikipedia:Perennial proposals|Perennial proposals]]'''. You may also wish to search the [[Wikipedia:FAQ index|FAQ]].
* Check to see whether your proposal is already described at '''[[Wikipedia:Perennial proposals|Perennial proposals]]'''. You may also wish to search the [[Wikipedia:FAQ index|FAQ]].

Revision as of 02:34, 2 October 2015

 Policy Technical Proposals Idea lab WMF Miscellaneous 

New ideas and proposals are discussed here. Before submitting:



Removing Persondata

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]

        • 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)[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]
        • 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)[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]
  • SupportRGloucester 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]
      • @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)[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]
        • 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)[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]
    • 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.—cyberpowerChat:Online 20:10, 9 September 2015 (UTC)[reply]
    • And @Periglio:, too. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:09, 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]

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]

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]

Motion: AUSC Extension

The Arbitration Committee is currently examining several reforms of the Audit Subcommittee and asks for community input on how they would like to see the Subcommittee function in the future. Because of this, the current Audit Subcommittee (AUSC) members' terms are hereby extended to 23:59, 30 September 2015 (UTC).

Supporting: AGK, Doug Weller, GorillaWarfare, Guerillero, LFaraone, NativeForeigner, Salvio giuliano, Thryduulf, Yunshui
Opposing: Courcelles

For the Arbitration Committee, --Guerillero | Parlez Moi 02:10, 5 September 2015 (UTC)[reply]

Discuss this and the future of the AUSC at: Wikipedia talk:Arbitration Committee/Noticeboard#Motion: AUSC Extension

We Have Created a Timeline for Every English language Wikipedia Article.

To: WhatamIdoing, Mdennis (WMF), Jimbo Wales, iridescent, User:Coren

We have accomplished the task of creating a visual, scrolling timeline of every Wikipedia article. Of course, not every article is historical in nature. Of the 5,000,000 English Wikipedia articles, our estimates are that around 250,000 could use a decent visual, contemporaneous presentation. That is a lot of timelines. We believe it would be one of the most exciting things to happen to history, on the internet, in a long time.

We have put a (mind blowing) demo together at:

http://wikitimelines.net/

In regards to potentially placing timelines on select Wikipedia articles. It would be just 1 small SCRIPT tag and 1 small DIV tag, per Wikipedia article.

It is surprisingly simple to do now.

All I am asking for is a Wikipedia server to install this on. Wikipedia would, of course, have complete authentication authority over this server. This will take less than one day to do.

OR:

I could give Wikipedia.org authentication authority over my "Amazon Web Services" server and Wikipedia would give me permission to use it (I will even pay for it).

Then we can test it on 1 Wikipedia.org article and see what happens.

We cannot believe how well this turned out. We can't stop timelining Wikipedia articles, it is so compelling and fun.

I forgot to mention. This whole thing is NEW. Nobody has ever seen this as of today (making timelines out of Wikipedia articles). We have only shown this technology to like 3 other people.

Thanks Jeff Roehl

Jroehl (talk) 21:54, 13 September 2015 (UTC)[reply]
Have you considered making this tool work using dumps of the Wikipedia database or other "local copy" of Wikipedia? davidwr/(talk)/(contribs) 23:16, 13 September 2015 (UTC)[reply]
To davidwr
I am not sure what you mean by: "dumps of the Wikipedia database"
Can you be more specific?
Thanks
Jeff Roehl
Jroehl (talk) 23:46, 13 September 2015 (UTC)[reply]
See Wikipedia:Database download. davidwr/(talk)/(contribs) 00:30, 14 September 2015 (UTC)[reply]

David = davidwr,

Yes, I would like to get the data from wherever Wikipedia is getting it. If we could get this to run on the same rackspace as the core of Wikipedia. That would be super-fast. And it would be very inexpensive, not taking any TCP/IP resources. Could I get the data in HTML? I am not sure if you guys take your Wiki language and immediately parse out the HTML on an article edit/save. My widget is pretty straight forward. It is aware of what page it is on. So if we placed the widget on:

https://en.wikipedia.org/wiki/Queen_Victoria

And the widget was on a LAN at Wikipedia, this could be translated as:

c:\wikidata\articles\Queen_Victoria\index.htm


Or what ever it is there and serve it out to the user. The key to me is to parse out the current version of the article. So the timeline will exactly match the article every single time. All I need to do is pull the article (locally) and pull the paragraphs out of the article. If I can pull the article in milliseconds, it would be super fast. The slowest part would be serving up the javascript to the widget on the users page. So all I would need is a big outbound pipe.

And I really don't need a lot of diskspace. My biggest worry, in processing millions of timelines a day is deletion of temporary files and releasing that diskspace back to the operating system. Each request for a timeline will produce 5 or so temporary files (SQL output). But those will be deleted within milliseconds after processing. We just have to make sure they are getting deleted. I can set the location of the temporary file location, so we can monitor this.

I may be able to write the system to work with no disk writes (convert all the tables to memory arrays), but that would be a LOT of work. That would be a multi week thing, for sure. So we should leave it the way it is now and see if it ramps up well.

Just my professional assessment, your experience may be different.

Thanks Jeff Roehl Jroehl (talk) 16:01, 14 September 2015 (UTC)[reply]

David = davidwr,

One more thing. Of course we don't want a timeline loading up on a historical Wikipedia article, every time it is accessed. What we really like is the "collapseButton" span tags, usually at the bottom of substantial articles. They are very classy. All we would have to do is add a "collapseButton" to the Queen Victoria page and put my SCRIPT tag and DIV tag in there. So when you opened up the "collapseButton" the widget JavaScript would be fired off and populate this area with the timeline HTML and JavaScript.

And if we could get my brilliant http://184.72.231.130/load1.js to fire at that point it would be all "no worries" after that.

Of course, the problem with this is the "collapseButton" controls are way at the bottom of the Wikipedia pages. I mean WAY down at the bottom. Below the Citations. And that is not good for "our team". Then again, timelines in Wikipedia may be so compelling that everybody might know where they are, by word of mouth, within a short time.

Thanks Jeff Roehl Jroehl (talk) 17:07, 14 September 2015 (UTC)[reply]

I tried it on Timeline of women's basketball for which it would seem to be uniquely well-suited. It was a bust. Did I do something wrong?--S Philbrick(Talk) 19:20, 15 September 2015 (UTC)[reply]
No S Philbrick you did nothing wrong. As of this writing, for the sake of speed and narrative content, we are only placing data on the timeline that is part of a paragraph in any Wikipedia article. That is any content that inside paragraph tags. We will eventually have to write a separate parser for "Wikipedia timelines". One issue is there is no standard format for Wikipedia timeline lists, so it is a trick to parse them. We will be happy to do this, even to the point of writing a program to re-write all Wikipedia timelines into one standard format. Try https://en.wikipedia.org/wiki/Women%27s_basketball which has some paragraph tags with content.
Thanks
Jeff Roehl Jroehl (talk) 18:06, 18 September 2015 (UTC)[reply]
I also recall seeing this a few weeks ago despite the claim that it's new today. I didn't save the link to the discussion and can't seem to find it easily at the moment. Found it Wikipedia:Village_pump_(proposals)/Archive_126#I_would_like_to_put_a_timeline_on_a_wikipedia_page I know there was discussion about getting the Foundation involved so I'd like to hear what is happening on that front.--S Philbrick(Talk) 19:24, 15 September 2015 (UTC)[reply]

Yes S Philbrick not much has happened. Rome wasn't built in a day. All we are requesting is 1 computer to display 1 timeline on 1 Wikipedia article. And then we might see where this goes. We have a 6 month period of time chunked out right now where we can focus on this. From 15 October 2015 to 15 March 2015, possibly 8 hours a day or 1000 hours (if not total hours of work, but our undivided attention and full measure of our devotion). I can't guarantee resources like this will be available after that. I think timelines would be much better understood if we could place a timeline on 10 Wikipedia pages. Then we could debate this content and then possibly take a consensus vote on inclusion. Some articles make better timelines than others and consensus would dictate inclusion in any article.

All we need is 1 server that "The Foundation" has administrative privileges/authentication on, whether that is a server we pay for or not. That is not a very big first step.

We are also going to write a grant application for this and related endeavors (also within the scope of the 1000 hours mentioned above). Any help with this would also be greatly appreciated. So anybody who knows of any organizations issuing grants for "Comparative History" or history in general, give us a heads up on that.

Thanks Jeff Roehl Jroehl (talk) 18:42, 18 September 2015 (UTC)[reply]

Who would make the decision to put 1 timeline on 1 article in Wikipedia?

Thanks Jeff Roehl 64.39.94.189 (talk) 17:11, 23 September 2015 (UTC)[reply]

Ok, lets go back a step.

Who would make a decision to allow me to install and configure a Wikipedia server with my timelining widget software backend?

Jroehl (talk) 15:20, 27 September 2015 (UTC)[reply]

It … doesn't work like that. I'd recommend installing a copy of your software on your own server and using the API to retrieve content on which to render a timeline. If that works well, your next step would presumably be to rewrite your software as a MediaWiki extension (and make it free and open-source if it isn't already), and then campaign for it to be added to Wikipedia proper. {{Nihiltres |talk |edits}} 17:34, 27 September 2015 (UTC)[reply]

Thankyou Nihiltres. I will have my guys look into this. Doing something like this, you never know until somebody tells you how things work. Jroehl (talk) 14:52, 30 September 2015 (UTC)[reply]

And we took the demonstration site down for now. Jroehl (talk) 15:52, 30 September 2015 (UTC)[reply]

Change "px" to "upright="/"size percentage" for all infoboxes?

Now that we have size options, including newest "400px" option, for image display, we should respect people's image preferences per WP:IUP. Somehow, the model of using "px" in infoboxes is detrimental to others wanting to see a big (or small) image initially. Perhaps we should change settings from px to image size percentage/upright. Agree? --George Ho (talk) 06:46, 23 September 2015 (UTC)[reply]

@George Ho: It's been agreed to scrap the "upright" option for images in the next few months/years, so I'd recommend against that. Jdforrester (WMF) (talk) 08:41, 23 September 2015 (UTC)[reply]
If they decided to scrap out "upright" option, how would this affect WP:IUP? Are we gonna use "px" again for all users? --George Ho (talk) 08:45, 23 September 2015 (UTC)[reply]
@George Ho: I believe the aspiration is also to deprecate pixel-specifying too, and instead move to semantic image types, but that's not agreed yet (and I'm not working on it myself, sorry). There are more details at the RfC to which I linked. Jdforrester (WMF) (talk) 08:46, 23 September 2015 (UTC)[reply]
I don't think scrapping out "px" works well. It would affect very tiny icons, like flags and checkmarks. Reading that link, I wonder whether they were discussing frameless images (with or without |frameless|). --George Ho (talk) 08:57, 23 September 2015 (UTC)[reply]
@George Ho: It's quite a wide-ranging proposal to totally change how media transclusions work, yeah. Needs some serious thought, as you say. Jdforrester (WMF) (talk) 17:33, 23 September 2015 (UTC)[reply]

It's already bad that Template:Flag has different flag widths, just because it was preferred to have a standard height (if I'm not mistaken).

If fixed pixel parameters are removed, it would get even worse. --NaBUru38 (talk) 22:59, 24 September 2015 (UTC)[reply]

It's not true that flag icons "have a standard height". Both the width and the height are fixed (the default is 23x15px), so whichever size (23px width or 15px height) causes a smaller icon is used. The same list looks like this with fixed width:
And like this with fixed height:
WT:WPFT or Template talk:Flag would be a better place to discuss the default size of flag templates, though. SiBr4 (talk) 12:06, 25 September 2015 (UTC)[reply]

consistent style usage on referring to the Catholic Church

Please make a global change in how Wikipedia refers to the Catholic Church.

Currently, moderators use the term "Roman Catholic Church", which is NOT how Catholics overwhelmingly refer to themselves.

Since the Catholic Church is comprised of 24 rites, only ONE of which is the Roman Rite, to refer to the whole as the "Roman Catholic Church" is entirely inappropriate and insulting to the other rites. Yes, the Church is 'headquartered' in the Vatican, which in Rome, but that does not justify labeling it as such. No one refers to the LDS church as the "Salt Lake City Church of Latter Day Saints".

"Roman" is at best an out-dated, archaic term. At worst, it is a subtle political label meant to qualify the Church as but one Catholic church among many (e.g. the Anglican Church). The insistence on denominating the Church as "Roman" seems to indicate a deep anti-Catholic, Protestant bias within Wikipedia. Anti-Catholic Protestants for centuries have insisted on denigrating the Catholic Church as merely "Roman". Terms such as "the Roman Church" and "Romanism" were used to smear the Church and cast it as foreign and particular, rather than universal. Since in the Apostles' Creed and Nicene Creed many profess belief in "one, holy, catholic, and apostolic Church" - many Protestants insisted on referring to the Catholic Church as simply the Roman Church. There is also an historical confusion with the Holy Roman Empire, which was a political kingdom unrelated to the Church.

Since there is no "official" name of the Church (it is simply the Church!), we must rely on common usage. Both historically and around the globe, the overwhelming usage of Catholics is to refer to the Church as the Catholic Church. Please update Wikipedia's terminology to reflect both fact and common usage as well as self-identified consensus.

Sincerely,

mnewhous

I always understood the "Roman" to refer to acknowledging the Roman Pontiff", not the Roman rite. There are now and have always been other rites in use. The problem with "Catholic Church" is that many other Christian denominations consider themselves Catholic. DGG ( talk ) 04:20, 24 September 2015 (UTC)[reply]
Mnewhous, Apart from
you'd like us to ditch the pillar of Wikipedia which requires neutrality and fall into line with (what you percieve to be) the RC view and start using a non-specific term? Shall we start referring to Mormons as Saints then, to fall in line with their usage? Or change all references to any faith to "the church"?
Context is everything. You may refer to the RC church as "the church", but would you do so if talking to a protestant and the context could be misconstrued? Would you refer to it as the Catholic church if you were talking to an Old Catholic? Well here, on Wikipedia, you're talking to everybody. Assume nothing, be specific. Regards, Bazj (talk) 14:26, 24 September 2015 (UTC)[reply]
I would generally assume a reference to the 'Roman Catholic Church' to be a reference to the largest Catholic church; whether or not it includes the other particular Catholic churches (such as the Maronites) - which in the narrowest sense it should not - depends on context. Insisting on the church's own usage as the only correct usage would seem to be unduly biased. (But then I'm an Anglo-Catholic, so I'm also biased.) AlexTiefling (talk) 14:31, 24 September 2015 (UTC)[reply]
Dear AlexTiefling, I seriously doubt that the original poster would "like us to ditch the neutrality pillar". If you think that renaming the "Roman Catholic Church" to "Catholic Church" wouldn't be neutral, please explain it politely. -NaBUru38 (talk) 23:06, 24 September 2015 (UTC)[reply]
NaBUru38, The comment you're complaining about is mine, not Alex's. Re-reading it, in its entirety, and in the context of Mnewhous' edit history and the cautions on his/her talk page, I'm quite content with the message. Bazj (talk) 08:38, 25 September 2015 (UTC)[reply]
Article titles can be a really hard thing to do neutrally, because there isn't the possibility of explaining the controversy in the title itself. You'll see that Catholic Church is the main article for the church, as you would desire, and Roman Catholic (term) explains the problems with names. I (not a Catholic-in-communion-with-the-bishop-of-Rome) agree that, in the absence of ambiguity, "Catholic" can be used to refer to the Church-in-communion-with-the-bishop-of-Rome. But there are times when ambiguity is present, and there the word "Roman" is not itself derogatory. (Though "the Roman Church", "the Church of Rome" and "Romanism" all are.) Indeed, the PCPCU use the word "Roman" where not to do so would cause offence/confusion.
Finally, note that "Roman Catholic" and "Latin Rite Catholic" are entirely different terms. There are "Roman Catholics" of other rites, and there are (arguably) Latin Rite Catholics who are not "Roman Catholic".
It's complicated and difficult, but I think Wikipedia's articles on the subject do a reasonably neutral job. Relentlessly (talk) 08:31, 25 September 2015 (UTC)[reply]

Allow the {{db-c1}} template to be removed by the creator

Should {{db-c1}} be able to be removed by the creator? Discuss below. --189.25.240.76 (talk) 16:11, 24 September 2015 (UTC)[reply]

Why? --Jayron32 12:02, 25 September 2015 (UTC)[reply]
I've removed speedy templates from template categories I created several times, where pages had actually been added but were not shown yet; e.g. this one. (When templates are categorized through their documentation subpages, they may not show up in the category until days or even weeks afterwards, because the job queue has to catch up.)
A more frequent scenario may be that a user creates a category, forgets (or doesn't know how) to add pages to it, sees the C1 tag after a few days, and only then adds pages to the category. SiBr4 (talk) 12:51, 25 September 2015 (UTC)[reply]
Then create the category page again. No big whoop. --Jayron32 16:07, 25 September 2015 (UTC)[reply]

OOUI for deletion confirmation

Recently, the move form has been switched to OOUI. The upload wizard will switch to OOUI next week. The deletion confirmation form (for administrators) should also be switched to OOUI. GeoffreyT2000 (talk) 15:58, 25 September 2015 (UTC)[reply]

@GeoffreyT2000: I've created T113758 for this; thanks for the reminder. Jdforrester (WMF) (talk) 16:49, 25 September 2015 (UTC)[reply]
@Jdforrester (WMF): What necessitates OOUI? Any form? Any form with multiple end states? I'm thinking special:log and special:Contributions off the cuff, though special:preferences has a button here or there. Special:MIMESearch too? Maybe someone should scrub the Special:Specialpages. There didn't seem to be a task for all of those. --Izno (talk) 17:24, 25 September 2015 (UTC)[reply]
@Izno: The plan is to eventually replace every UI interface component with OOUI, and delete e.g. jQuery.UI and other deprecated systems. T100161 is the overall ticket for converting all of MediaWiki. T107037 is for all special pages, but there aren't yet sub-tickets for Log, Contributions or indeed most of them. Jdforrester (WMF) (talk) 11:35, 26 September 2015 (UTC)[reply]
Would this discussion be better suited for WP:VPT. Your magical incantations don't really make much sense to us Muggles, and you're likely to get better participation from more knowledgeable people over there. --Jayron32 17:35, 25 September 2015 (UTC)[reply]
@Jayron32: VPT isn't the right venue either for asking for participation for writing code; input is welcome in the form of git patches, which go on gerrit:. :-) Jdforrester (WMF) (talk) 11:35, 26 September 2015 (UTC)[reply]
Ok. I'll bite. What the heck is an OOUI? And that gerritt thing; is that in the same family as a ferret? GenQuest "Talk to Me" 11:48, 26 September 2015 (UTC)[reply]
OOUI. "Gerrit" is the given name of Gerrit Rietveld. --83.255.51.226 (talk) 08:17, 29 September 2015 (UTC)[reply]

Can someone explain to me what the benefit of "OOUI" is? I've read the article linked above, but I fail to see how the new move form is more "object-oriented" than the old one. Jenks24 (talk) 14:23, 29 September 2015 (UTC)[reply]

OOUI when in the context of MediaWiki refers to OOjs UI (demo). This is a modern widget toolkit written with the goals of MediaWiki and Wikipedia in mind. It can be generated in both PHP and Javascript, is accessible, consistent, skinnable, mobile optimized etc. It also allows for easy creation of MediaWiki specific widgets such as an input field for Article titles with autocompletion. It's first user was Visual Editor and the long term plan is that this will be used for all controls at some point. The idea is that not every developer has to reinvent the wheel. You use what is in OOUI already, or you build something new on the foundations that this platform provides you, but you don't start from scratch. —TheDJ (talk • contribs) 15:54, 29 September 2015 (UTC)[reply]
Thanks for the response. So basically it makes things easier for devs? And also it would be nice for things to be consistent? Both of these seem like good things so that's fine. But the change to the move interface has made my work here more difficult. I've now had to file two bugs about it and even once they are both fixed, the old interface will still have been quicker for me (and most others, I assume) to use. Is there any guarantee a change to the deletion interface won't have the same problems? Or am I understating how useful this is on the backend and these minor hassles for editors are worth it? (I realise you, TheDJ, might not necessarily have answers to these questions, they're more general for anyone with knowledge on the subject.) Jenks24 (talk) 16:46, 29 September 2015 (UTC)[reply]
Let's put it like this: I'm sure you love your house full of unique, handcrafted, slightly imperfect yet beautiful, efficient and very expensive furniture, but IKEA has a lot of benefits to it. Currently a lot of community requests are about making things more 'interactive', 'smarter', 'n00b proof' etc. But without changing some fundamentals, many of those requests are actually difficult and expensive to implement consistently in multiple areas of the wiki, for multiple target audiences and multiple target devices (and not breaking on browsers without Javascript). OOjs UI will create new handles for both community and developers to provide some of those changes. —TheDJ (talk • contribs) 17:36, 29 September 2015 (UTC)[reply]

Prefix suggestion: TP: for Template:

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 no consensus for this proposal. The arguments on both sides are good, but the arguments are pretty evenly split. AlbinoFerret 20:39, 29 September 2015 (UTC)[reply]

My idea is so that we could make search "fstr". We already have WP: for Wikipedia:, so let us have that prefix. Gamingforfun365 (talk) 01:26, 30 August 2015 (UTC)[reply]

  • Oppose For the reasons in WP:PEREN#Create shortcut namespace aliases for various namespaces. In particular, the Template namespace is generally not linked often enough that saving the typing of 6 characters is likely to be at all worthwhile and there's nothing available to use for the corresponding talk pages. Anomie 13:27, 30 August 2015 (UTC)[reply]
  • "TL:" would be a much better suggestion for this, as templates can already be linked to with the {{tl}} template. --IJBall (contribs • talk) 15:43, 30 August 2015 (UTC)[reply]
    Won't work, because "tl:" is the interwiki prefix for the Tagalog Wikipedia. "tp:" is currently not an existing interwiki prefix (and an unassigned ISO 639-1 code). SiBr4 (talk) 16:01, 30 August 2015 (UTC)[reply]
  • support Definitely useful, as a guy who pulls up templates more that articles.—cyberpowerChat:Online 20:19, 30 August 2015 (UTC)[reply]
  • Support as TP:. But what about the template talk namespace? TT: is the Tatar language, so TPT? Eman235/talk 22:46, 30 August 2015 (UTC)[reply]
    "tpt" is Tlachichilco Tepehua in ISO 639-3. Anomie 22:11, 31 August 2015 (UTC)[reply]
  • Question: Why not just use {{tl}}? Seems to me a Template talk shortcut would be more useful. —67.14.236.50 (talk) 04:18, 31 August 2015 (UTC)[reply]
    The idea is to be able to write TP: (case insensitive) in the search box to save typing six characters. But if an alias is made then some editors will also write it in saved links. TP sounds like talk page so it may confuse some users. Assuming TP is only defined for the English Wikipedia or Wikimedia wikis in English, it may also confuse people who expect it to work at other wikis. PrimeHunter (talk) 13:26, 31 August 2015 (UTC)[reply]
    That can easily be addressed by creating a T prefix for Talk: TP for Template: and TT: for Template talk:—cyberpowerChat:Online 14:52, 31 August 2015 (UTC)[reply]
    That would require either changing the existing tt: prefix or making all namespace and interwiki prefixes case-sensitive (both of which would break a lot of links globally), as well as deleting/renaming all pages starting with T:, which include some often-used shortcuts to template pages. Hardly easy. SiBr4 (talk) 15:29, 31 August 2015 (UTC)[reply]
  • Support, for ease of finding templates. bd2412 T 13:41, 31 August 2015 (UTC)[reply]
  • Support for search box usability. —67.14.236.50 (talk) 22:24, 1 September 2015 (UTC)[reply]
  • Comment Since {{tl}} and similar templates can be used for linking to templates in discussions, a shortcut like this would only really be useful in the search box (and maybe edit summaries). I just recalled Kipod having written a user script that gives Template: namespace search results in the search dropdown for queries starting with "{{" about a year ago (discussion), and wrote this simple JS script to expand "TP:" as well as "{{" into "Template:" in the search box. That allows the functionality of the proposed namespace alias, without it needing to actually be created (and changed in case of a conflicting future namespace/interwiki prefix). SiBr4 (talk) 14:22, 3 September 2015 (UTC)[reply]
  • Support as a pretty useful suggestion. APerson (talk!) 02:21, 7 September 2015 (UTC)[reply]
  • Oppose People have to refer to Wikipedia a lot, and "WP" is a useful contraction that is widely used and recognizable. The same is not true regarding Template/TP. People fiddling with templates would quickly learn to use TP if they wanted, but TP would be pointless jargon for many people encountering the term. If the only reason for wanting TP is to enter the namespace in search, another method is needed. For example, use the "Remember selection for future searches" after selecting Template in the list of namespaces at the Advanced search. Johnuniq (talk) 21:27, 7 September 2015 (UTC)[reply]
  • Oppose - I honestly don't see much point to this as no one ever uses templates as they do Wikipedia pages, Plus I (and I assume others) are used to searching "Template:" anyway. –Davey2010Talk 01:21, 12 September 2015 (UTC)[reply]
  • Oppose, per Anomie. {{Nihiltres |talk |edits}} 02:42, 12 September 2015 (UTC)[reply]
  • Support A useful, time-saving suggestion. Azealia911 talk 12:35, 13 September 2015 (UTC)[reply]
  • Oppose As many other commenters have said this will be a pain to implement without breaking lots of things if it can be done at all. There is little benefit to the change, when we are discussing templated we use {{tl}} not <nowiki>TEMPLATE:FOO</nowiki> and saving the 1 second it takes to type TEMPLATE rather than TP is just not worth it for the search box. JbhTalk 13:20, 15 September 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.

Delete talk page and/or subpages when moving

When an administrator moves a page, an existing talk page under the new title should be deleted if the "Move associated talk page" box is checked. Also, existing subpages of the new title should be deleted if the "Move subpages" box is checked, and if the "Move associated talk page" box is checked, also subpages of the talk page. GeoffreyT2000 (talk) 14:33, 1 October 2015 (UTC)[reply]

Not quite, but if the "Delete this page" is marked for the article, it should delete the old talk page and move the new one. I'm often opposed to this kind of thing, but here the admin can always just delete the talk page and do the move manually: your proposal wouldn't do much to retard the foolish admin, but it would make it a lot simpler for ordinary moves. I am, however, opposed to deleting subpages: unlike main talk pages, talk page subpages are very easy to overlook, very easy to miss by accident, because if nothing else they don't cause tabs to change from red to blue. I don't want to run the risk of trashing subpages that I never knew about, especially because the pages to be deleted are pages that I might never have seen or edited. Nyttend (talk) 00:39, 2 October 2015 (UTC)[reply]
Completely agreed with Nyttend. A tick box to also 'delete and move' for the talk page would be handy, but having it for subpages is a recipe for disaster, especially in cases where a page and its subpages have been moved back and forth – you'd end up with cases where the actual content is deleted to move a redirect over the top of it. Jenks24 (talk) 01:13, 2 October 2015 (UTC)[reply]

Direct links to Commons edit page

When you attempt to create a description page here for an image that's on Commons, you're presented with the message from MediaWiki:Sharedupload-desc-create, basically a little warning of "This image is on Commons, so please don't create this page", and a link to the Commons URL is provided. See for an example of this message in use. I went to WP:HD asking how to change the URL. Right now, when you go to File:Armed Klansman in southeastern Ohio, 1987.jpg and try to edit its page, the URL in the message is [13], while I was planning to edit the MediaWiki page so that it instead went to , the edit page instead of the description page. PrimeHunter gave me the code, but he also opposed the idea, so I'm not going to make the change without chatting here first.

Proposal Change the URL in the MediaWiki page so that it sends you directly to the screen to edit the Commons description page, rather than sending you to the page itself. My rationale was "it seems reasonable that the typical person editing the page was intending to edit the Commons page, so it will save a step by sending them directly to the edit page instead of making them detour through the description page." PrimeHunter opposed with "[the local file] is missing several features on [the Commons description page] such as Commons categories, section edit links, History tab, and links to the uploader and their contributions...I don't like the idea of cross-wiki edit links. I think users should at least view a wiki before trying to edit it. I wouldn't want Commons or other wikis to have direct edit links to us."

So which is it? Should we change the link as I want it, or keep it unchanged, or modify some other way? Nyttend (talk) 00:33, 2 October 2015 (UTC)[reply]