Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia
  (Redirected from Wikipedia:VP/PR)
Jump to: navigation, search
  Policy   Technical   Proposals   Idea lab   Miscellaneous  

New ideas and proposals are discussed here. Before submitting:

« Older discussions, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113
Centralized discussion
Proposals Discussions Recurring proposals

Note: inactive discussions, closed or not, should be archived.

Satpal Maharaj/ Devine Light Mission[edit]

Details mentioned regarding Devine Light Mission should not be the part of Satpal Maharaj.

In any of the record in Govt. of Indian Department , This organization was not headed by Satpal Maharaj.

Satpal Mahraj is founder of Manav Utthan Sewa Samiti - A Non-profitable organization registered as per Society Registration act of India, 1961.

Manav Utthan Sewa Samiti's registration no is S/7341/1974

Devine Light Mission was headed by Prem Rawat.

Mentioning of Devine light Mission under this article is again to vandalize the image of a person.

This should be on the article or project talk page, not here. (Signing so as perhaps this can be archived.) — Arthur Rubin (talk) 01:16, 15 August 2014 (UTC)

RfC: Should Persondata template be removed from articles?[edit]

Background (Persondata)[edit]

The question keeps arising on Wikipedia talk:Persondata and other forums on whether we should drop persondata now that Wikidata provides the same or similar information. I usually state eventually that is the goal, but I haven't heard anything else about it. I decided this time to be more proactive about it.

From Wikipedia:Persondata, "Persondata is a special set of metadata that can and should be added to biographical articles only. It consists of standardized data fields with basic information about the person (name, short description, birth and death days, and places of birth and death) that, unlike conventional Wikipedia content, can be extracted automatically and processed by cataloging tools and then used for a variety of purposes, such as providing advanced search capabilities, statistical analysis, automated categorization, and birthday lists."

At this time, I'm not aware of anyone using the data. DBpedia does gather the information and offers it for download. However, I'm not aware that they use it. Wikidata did have two bots running, which copied |SHORT DESCRIPTION= from persondata and put it into Wikidata. One bot worked only on dewiki. SamoaBot did work on enwiki. SamoaBot's operator stated that he doesn't "...recall having run that task in these months. However, tons of data have already been imported, and now it is up to the English Wikipedia community to decide whether they still want those data within articles." I did ask Wikidata about persondata.

{{Persondata}} does have many drawbacks. Some of which are:

  1. It is hidden, therefore it is often out of sync with the article text or infobox, with no current mechanism to keep it in sync.
  2. If an infobox is present, persondata becomes redundant.
  3. It is currently not being used by anybody (to my knowledge).
  4. |NAME= and |ALTERNATIVE NAME= parameters have no standard format. Format should be surname, firstname, but this isn't always followed. When a person as a stage/pen name, there is not standard on which parameter parameter gets what name.


  1. If the article doesn't have an infobox, persondata can become a source of info.
  2. |SHORT DESCRIPTION= is of use to Wikidata.
  3. From Periglio's talk page, "Wikipedia has an easy accessible database of over 1 million people. It is data available for serious research projects. Why delete it?"

Question: Should the {{persondata}} template be removed from all articles and no longer be used?

Proposed by Bgwhite 21:21, 20 July 2014 (UTC)

Discussion (Persondata)[edit]

  • Have a comment?
  • Before implementing this change all the gadgets and tools that create or use this template must also be changed. Otherwise we will get them being created when others are trying to get rid of them. A comparable situation where the cite gadget creates "deprecated" cite template parameters that bot(s) go around undoing. So this should be done as a proper release, where wikidata, gadgets and tools are all synchronised with the policy implementation to stop wasted effort. Graeme Bartlett (talk) 22:08, 20 July 2014 (UTC)
    Graeme Bartlett, Wikidata is currently not ingesting anything from Persondata. I'm aware of two tools that create Persondata, Persondata-o-matic and AWB. An AWB developer is aware of this proposal. Persondata-o-matic currently doesn't work. There are some scripts/gadgets that do allow for easy viewing persondata. Bgwhite (talk) 22:17, 20 July 2014 (UTC)
    So I think that Wikidata should ingest this. It will be harder to harvest from history as it may not be possible to tell the "correct" version. AFC reviewer tool currently adds persondata. Graeme Bartlett (talk) 06:02, 21 July 2014 (UTC)
  • If this goes ahead, someone (I'm willing to help) will need to close up the Persondata and WikiProject Persondata and related pages. Also maybe notify members of the project (and places like WP:BIOG) that persondata is going to be removed. Is there a way of setting up an ongoing bot to send messages to users who add new persondata?—Msmarmalade (talk) 08:09, 21 July 2014 (UTC)
  • User:Rjwilmsi's bot occasionally adds/updates Persondata using AWB but it should be very easy to diactivate AWB's after we agree to stop adding/remove Persondata. -- Magioladitis (talk) 08:24, 21 July 2014 (UTC)
  • My main concern is Category:Biography articles without infoboxes. This means we have 20,000+ that may have Persondata and not an infobox. -- Magioladitis (talk) 08:40, 21 July 2014 (UTC)
    Maybe it would be a good idea to add infoboxes to most of these pages so that we reserve the information in the article and in a visible place? -- Magioladitis (talk) 16:40, 23 July 2014 (UTC)
    @Magioladitis: do you mean automatically create infoboxes and transfer Persondata to them? One consideration in that case then, is articles where there isn't enough information to justify an infobox (Although I'd like to see almost every page with an infobox anyway, I think the general consensus is that infoboxes without enough info are an eyesore). For example, if only |NAME= is available, the infobox is unnecessary as you can (usually) get that info from the article title. Perhaps these sorts of persondata can be deleted early on.—Msmarmalade (talk) 02:34, 24 July 2014 (UTC)
    @Msmarmalade: we can select some rules (size of page, at least 3 fields are filled, etc.) and create infoboxes using a bot only for these cases. Still much better than now. -- Magioladitis (talk) 05:02, 24 July 2014 (UTC)
  • How reliable is Persondata anyway? in this edit a malformed article title was used to create a malformed NAME, and DATE OF BIRTH was copied from the completely unsourced infobox (it's not present in the body of the article). Where does that leave Persondata - or Wikidata if it scrapes up "information" using the same rules? PamD 10:40, 21 July 2014 (UTC)
  • Questions - Perhaps it's just me, but there seems to be a failure of communications at work here. Even now, many WP editors remain in the dark about what Wikidata is doing, and how it will affect WP articles. In this example, for instance, would the supplantation of persondata by corresponding wikidata yield better WP articles? Will it, for instance, automatically populate WP infoboxes? What would the differences look like? How would they be made compliant with BLP, V, and other WP policies? Would WP editors still be able to correct errors, without having to learn their way around Wikidata? Are there some examples in place to show how these things will operate? LeadSongDog come howl! 20:40, 21 July 2014 (UTC)
    @LeadSongDog:. Some data in the infoboxes could be fetched from Wikidata, but that does not seeem to be the matter at hand here. {{Persondata}} is not meant to be used to populate infoboxes. -Superzoulou
    Thanks, but that really doesn't clear much up. The content of {{Persondata}}, {{Infobox person}}, etc should reasonably be automagically verifiable against the categories the article is put into. References supporting the assertions that cause those categories to be applied must be maintained if we are to avoid finding Koffi Annan in Category:Bollywood stars or something equally absurd. Will/does wikidata support checks to see that the categories are supported in the article, with references? Does it have a mechanism to support variances in sourcing policies between the different WP languages, or at least to attribute the sourcing to the WP language and article where the assertion originates? Vandalism isn't going to be disappearing anytime soon, after all. LeadSongDog come howl! 21:53, 21 July 2014 (UTC)
    I do not really understand what you are talking about. This proposal is not about deleting {{Infobox person}} and afaik, there is no consistency check between persondata and categories. Actually, I do not see how a bot could use Persondata in their current form to know that Koffi Annan should not be categorized as a Bollywood star.
    Many bots have added from which Wikipedia the data originated in the source part of the statement. One has added the actual reference that was used in the article (but this is more difficult so less widely implemented at the moment). --07:16, 22 July 2014 (UTC)
  • Pictogram voting comment.svg Comment There actually appears to be actually two issues:
    1. should we work toward removing Persondata now ?
    2. should we delete data from Persondata wtihout checkign with have their data in Wikidata first ?~
I am certainly in favour of 1), not of 2): if data in persondata match those in Wikidata, they can be deleted. It is a bit pointless that when we want to correct some data, we need to do it in two pages instead of one. But when there are gaps in Wikidata/mismatch with persondata, it should be checked before deleting anything. --Superzoulou (talk) 07:16, 22 July 2014 (UTC)
  • In that case, perhaps we should have a {{persondata moved to Wikdiata}} which can be applied (by humans or bots) once the data is verified as being in Wikidata. It should prevent further addition of Persondata, and enable us to check progress statistics. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:27, 22 July 2014 (UTC)
    Once the data is in Wikidata, I think we can simply delete it, so we would rather need {{Persondata inconsistent with Wikidata}}. At the same time, we should obviously stop creating new persondata here. That means, among other things, updating scripts like User talk:Dr pda/persondata.js by user:Dr pda so that they add the data to Wikidata instead of Wikipedia. -Superzoulou (talk) 13:23, 22 July 2014 (UTC)
    The major source of new Persondata templates, in my experience, is the Articles for Creation process, where reviewers are encouraged by the script to fill out a template. This should be fixed before any attempt at removing Persondata is made. APerson (talk!) 02:34, 2 August 2014 (UTC)
  • The one question that no one is answering is how Wikidata is being maintained? Another example I have just come across is Ed Vokes. Someone updated his birth and death dates on Wikipedia two months ago (16 May 2014). Although the editor updated Persondata but Wikidata still shows the old information. Periglio (talk) 17:21, 26 July 2014 (UTC)
    Have to agree with above comment to which there has been no answer as yet. There are numerous wiki's interfacing into wikidata and there need to be some means of ensuring that they are all kept in step for this to be useful information. Having had experience of the out of date information on wikidata for simple things such as Commons links, there need to be some rigorous system available before we can rely on wikidata information. Keith D (talk) 12:37, 30 July 2014 (UTC)
  • Has this RfC actually achieved anything? The anti-persondata lobby argument argument seems to be based on fact that they don't use it, so lets delete it. As someone who has invested time in playing with the birth and death data, I'm worried that Wikidata will actually be maintained. Although not normally visible, from my experience PersonData normally gets updated when someone changes a date. At the moment, there is nothing in place to update Wikidata.
I would like to use WikiData but I need to convince myself that Wikidata is just as reliable as Persondata. I am working on a Wikidata extract and in the next few days will be generating some meaningful statistics comparing Persondata and Wikidata to see if there is a problem. All I ask is for Persondata to carry on, business as usual, until we have some actual facts in front of us. Periglio (talk) 13:11, 3 August 2014 (UTC)
This RFC hasn't achieved anything because we are going to be removing something beneficial for something that has significantly more problems and the fact that AWB and users are actively updating, maintaining and working on a monumental task while a more "meta" problem is still being worked through. If users don't use or need it, they don't have to, but I see no need to remove it when an equal or better alternative does not exist. ChrisGualtieri (talk) 04:44, 4 August 2014 (UTC)
Update: I have done an analysis (link here) on over 4000 records comparing Persondata and Wikidata. My first conclusion is that both databases have the same level of coverage, which is around 95% of the total population of notable people. My other conclusion is that Wikidata appears to have the edge on accuracy. The bulk of corrections I am making appear to be updating Persondata to match changes in the Wikipedia article. In short, I am switching my personal project to Wikidata and no longer extracting from Persondata. However, I still remain opposed to the removal of Persondata until SHORT DESCRIPTION is moved across to Wikidata. Periglio (talk) 19:40, 4 August 2014 (UTC)

Support (Persondata removal)[edit]

  1. Support, unless anyone shows a temporary need to retain the data while it is copied to Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:55, 20 July 2014 (UTC)
  2. Support as redundant, --Gerda Arendt (talk) 22:07, 20 July 2014 (UTC)
  3. Support as redundant. I've never added it to an article, never understood why. Sometimes have to fix work of others who insert inconsistent data. Montanabw(talk) 02:48, 21 July 2014 (UTC)
  4. Support per others. --AmaryllisGardener talk 03:27, 21 July 2014 (UTC)
  5. Support as long as it is implemented cleanly, (see discussion above) and the information therein is not lost. This sort of data should appear in Wikidata instead, and is not really "encyclopedic" in itself. But it could be a tool to populate indexes, categories, or add to author records - more the thing for Wikidata. Graeme Bartlett (talk) 06:05, 21 July 2014 (UTC)
  6. Support methodical transfer and removal as per others. Perhaps afterwards, focus should move to cleaning up infoboxes, and standardizing the dates, data, etc within them.—Msmarmalade (talk) 07:47, 21 July 2014 (UTC)
    Expanding on that. The examples of people using Persondata that i've read in this ongoing discussion, seem to be personal. It doesn't seem to be used by the main body of Wikipedia users so I think it's not really appropriate to put in the article, albeit hidden. It would be more appropriate to outsource the data, or embed it in the actual article, rather than adding an extra step for editors to complete and maintain, for negligible useage.—Msmarmalade (talk) 07:04, 4 August 2014 (UTC)
  7. Support as redundant. The use to which this data is potentially put is dubious, and the fact that it isn't sync'd seems to make the whole thing pointless. I'd like to see the automated insertion by AWB switched off immediately, and its complete reversal (into 'systematically remove' mode and not just neutral) if the RfC goes through. -- Ohc ¡digame! 09:10, 21 July 2014 (UTC)
  8. Qualified support remove data that are identical on to those on Wikidata so that we do not need to maintain them at two places. Check and then remove the other ones. --Superzoulou (talk) 10:11, 21 July 2014 (UTC) + Superzoulou (talk) 11:01, 22 July 2014 (UTC)
  9. Support Finally the time has come. You always had the highlights and details in infobox, there was no need of persondata like others may have thought as well. OccultZone (TalkContributionsLog) 10:44, 21 July 2014 (UTC)
  10. Support as redundant, and an annoyance to maintain. These can also be a pain to fix when disambiguating links because the link is there, but invisible. bd2412 T 13:33, 21 July 2014 (UTC)
  11. Support I like the idea of using a tool designed to keep track of this sort of data to keep track of this sort of data. Zell Faze (talk) 14:04, 21 July 2014 (UTC)
  12. Support, though make sure that the data we are removing already exists in Wikidata first. Cbrown1023 talk 17:45, 21 July 2014 (UTC)
  13. Support eventual removal - as and when we are confident it's been migrated to Wikidata. Removal on a case-by-case basis when migrated would be reasonable, and then deprecating the system. Andrew Gray (talk) 19:53, 21 July 2014 (UTC)
    Andrew Gray, Wikidata will not import anything but |SHORT DESCRIPTION=. A bot has already imported this data and will run again before Persondata's removal. Bgwhite (talk) 19:59, 21 July 2014 (UTC)
  14. Support The only reason I include persondata in my new stubs is because they otherwise got inserted with incorrect or incomplete data. I have never used the persondata and I believe it is redundant now with Wikidata - maybe someone could run some numbers on the accuracy of persondata vs Wikidata for 100 random biographies? depending on the results we could just rip them all out. Alternatively, we could agree to no longer insert persondata and manually delete whenever we check Wikidata and see the data exists on Wikidata. Jane (talk) 09:10, 22 July 2014 (UTC)
    Comment: I first create a stub on English Wikipedia, then I create the Wikidata item (if it doesn't already exist). When I create a new Wikidata item it imports the persondata so I don't need to type it over. I would not want to see persondata disappear before my workflow changes (i.e. first make improve WD item, then create stub from that). Now WD lets me import the stub, but so far I can't import the WD item to WP. Jane (talk) 13:04, 26 July 2014 (UTC)
  15. Support as redundant, Since I don't use WikiData I find PersonalData to be absolutely useless anyway. –Davey2010(talk) 18:58, 25 July 2014 (UTC)
  16. Support separating plumbing and porcelain. Metadata should be distinct from the text which generates an article as much as possible. It doesn't need to be torn down root and branch but we should not be adding responsibilities to persondata and we should be transitioning to Wikidata over time. Protonk (talk) 18:31, 29 July 2014 (UTC)
  17. Support when all appropriate persondata has been slurped by Wikidata. Until then, we should leave it to carry on its quiet existence at the bottom of our edit screens. — This, that and the other (talk) 10:51, 30 July 2014 (UTC)
  18. Support, after migration is over. The argument about persondata being easier to use is not really convincing, it is rather an argument for simplification of Wikidata APIs, but even now WD looks much better. Max Semenik (talk) 22:33, 30 July 2014 (UTC)
  19. Support per the various arguments already stated with the qualification that a decent amount of time for data migration be granted, again, per the previous comments above. Safiel (talk) 16:17, 31 July 2014 (UTC)
  20. Support - if data such as this is required, it can be maintained at wikidata. PhilKnight (talk) 13:45, 1 August 2014 (UTC)
  21. Support – with the creation of a bot to run through articles, removing Persondata from those where it matches the Infobox and tagging those with diffs for manual processing. Those without Infoboxes should be given one except when only the name is present in the Persondata and it matches the article title. I'm assuming there is nothing inherently harder about scraping from Infobox vs. Persondata for use in Wikidata, etc. Not having to worry about checking the Persondata for agreement with the article all the time will be a nice little improvement to the editing experience. —[AlanM1(talk)]— 21:11, 1 August 2014 (UTC)
  22. Support removal, but not urgently. I've never much liked having "content" that readers of the encyclopedia cannot easily see. --Tryptofish (talk) 20:01, 3 August 2014 (UTC)
  23. Support removal. It does not form part of the encyclopaedia, since it isn't visible to readers. Yes it may help with the Wikidata project further down the line but, frankly, that's that project's problem. Our project is building an encyclopaedia and PersonData does not, and never has, contributed to that. WaggersTALK 13:43, 4 August 2014 (UTC)
  24. Support removal, but delay for a limited time to allow import of short descriptions--if that process isn't complete yet. (A bot doing the removals could also do the imports where necessary, and log conflicts. This shouldn't take a good deal of time, as there has already been a bot pass to record short descriptions. PS: Nice analysis, above, Periglio! --j⚛e deckertalk 01:22, 5 August 2014 (UTC)
  25. Support after cross-check and incorporation into Wikidata. Persondata is now obsolete and redundant. Renata (talk) 00:17, 7 August 2014 (UTC)
  26. Support this appears to be redundant and therefore unnecessary. Fraulein451 (talk) 16:05, 11 August 2014 (UTC)
  27. Support. An excellent and laudable project that is now superseded by Wikidata. Ironholds (talk) 10:43, 17 August 2014 (UTC)
  28. Support I find persondata to be very rarely accurate and have often thought it should be nuked even before we had wikidata. Now that we have wikidata to take care of things and I feel would likely be much more accurate then we should deprecate persondata. -DJSasso (talk) 13:02, 20 August 2014 (UTC)

Oppose (Persondata removal)[edit]

  1. Oppose: First of all, the claim that Persondata are currently not being used by anybody is wrong. Tools that evaluate Persondata exist and are being used. Secondly, Wikidata cannot be taken seriously at this stage as its data (beyond the interwiki links) are simply not reliable. As elaborated in this discussion, Wikidata looks like a Wikipedia from 2003 without any references. A Wikipedia article, however, combines both, literature and references that backup the data given in the Persondata template. At the current state of affairs, the Wikipedia articles and their Persondata records should be considered as a source, not as a target for Wikidata. --AFBorchert (talk) 08:32, 21 July 2014 (UTC)
    And another observation: I just took a first look at one of the dumps of wikidata. They are as ugly as hell as they are embedding JSON within XML. To extract person data from Wikipedia dumps is pretty simple (and frequently done). This fun will be all gone when you have to turn to Wikidata dumps. --AFBorchert (talk) 08:43, 21 July 2014 (UTC)
    Wikidata does not contain enough references, but English Persondata do not contain any, so I do not really understand what your point is. The real question would be which is more reliable between birth/death place/date in Wikidata and in English Persondata. I see no argument one way or the other.
    German Persondata appear to be more used than the English ones, but the discussion for removing them should be done in Wikipedia in German. Does any German tool use English Persondata ? --Superzoulou (talk) 09:56, 21 July 2014 (UTC)
    @Superzoulou: Persondata are embedded in articles that (hopefully) provide references to backup this data. Hence, you have both, data and references in one place very close to each other. If the article is updated in this regard, the persondata can be easily adapted in one edit. At Wikidata we have mostly a heap of data without any references. This does not help us and is surely no replacement for the current Persondata. I refered to the German discussions as de-wp as this was debated there half a year ago. I think it is always worthwile to look into other similar projects and their discussions. And indeed the Persondata were introduced at de-wp and later imported to en-wp. It is surely a predecessor to Wikidata and at some time it may be envisioned to deprecate it but currently I would see it as a great tool that helps in the transition to Wikidata which is not yet sufficiently mature to replace it in my opinion. --AFBorchert (talk) 11:54, 21 July 2014 (UTC)
    @AFBorchert: English Persondata are mostly meant for bots that are not smart enough to read the rest of the article, and for them references elsewhere in the page are not really useful. It is true that people who maintain the template can check the consistency between Persondata and the rest of the article, but I wonder how many people do it by hands. Bots can also check the consistency of the data between Wikidata and Wikipedia. --Superzoulou (talk) 13:17, 21 July 2014 (UTC)
    @Superzoulou: I do it “by hand” at en-wp as well as de-wp. And indeed the consistency check between Wikidata and Wikipedia is an important advantage that would get lost if we would give up Persondata too early. With very few exceptions, I do not edit data records corresponding to Persondata at Wikidata as it is no fun for me to click through all the Javascript-based forms. Wikitext can be edited far more conveniently (and if necessary even by an editor of my choice like Vim), I do not want to waste my time with clicking through a myriad of forms. --AFBorchert (talk) 13:28, 21 July 2014 (UTC)
    @AFBorchert: Consistency of Wikidata can also be checked against infoboxes, and even against the article's lead (Wikidata items about people are marked as such so which avoids the occasional topic mismatch between the infobox and the article proper). --Superzoulou (talk) 14:44, 21 July 2014 (UTC)
    @Superzoulou: Many biographic articles do not have infoboxes but Persondata (example). --AFBorchert (talk) 20:05, 21 July 2014 (UTC)
    @AFBorchert: I know, and I would suggest that we should start the removal with pages with infoboxes. But the data can also be parsed from the article's lead (admittedly, only as an occasional bot task, not like permanent check thourgh templates). Superzoulou
    @AFBorchert: concerning the ugly dumps, the new JSON version will hopefully make things easier [1]. --Superzoulou (talk) 15:28, 23 July 2014 (UTC)
  2. Oppose (from wikiproject templates): until wikidata is brought online, persondata needs to stay in order to populate wikidata with the largest source we have of data on article subjects. I know that AWB automatically copies information from infoboxes to persondata, so there is obviously significant overlap on those two, and I am absolutely convinced that persondata's usefulness will soon expire. But we need to keep this on enwiki, up until a bot goes through and copies the persondata entries to wikidata (just like they did with interwiki links), and no later; nobody else has nearly the comprehensive coverage of biographies that would facilitate that transfer. VanIsaacWScont 09:28, 21 July 2014 (UTC)
    @Vanisaac: In what way is Wikidata not "online"? Are we confident that Persondata is reliable (accurate and up-to-date) enough to be copied to Wikidata? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:58, 22 July 2014 (UTC)
    It's not online in the same way that Obamacare is not online: Yeah, there's a lot of the substantive stuff that's there now, and the different features are getting implemented roughly when they are supposed to, but there's still more to come as time progresses, and it's going to take some effort by people to get to the level of coverage that the system was designed to have. VanIsaacWScont 10:04, 22 July 2014 (UTC)
    @Vanisaac: So you object to deprecating persondata in favour of Wikidata, even though Wikidata does everything that persondata does, and much more besides, because Wikdiata will do even yet more in the future? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:34, 22 July 2014 (UTC)
    Please go back and actually read what I wrote. I object to removing persondata before it's been copied over to wikidata, since enwiki's persondata is likely to be one of the most robust and comprehensive sources for wikidata. That's what "we need to keep this... until a bot goes through and copies the persondata to wikidata" means. Since that has not yet happened, I oppose deprecating persondata at this time. There might also be an argument for keeping it supported after that time, if the transfer bot remains in operation, so that it can be used as a backdoor wikidata upload. But without any details about the wikidata transfer bot, that's merely speculation. VanIsaacWScont 13:03, 22 July 2014 (UTC)
    Yes, I understood that from your original comment, but in the light of it, and of your more recent comments, I cannot make sense of your "until wikidata is brought online" clause. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:23, 22 July 2014 (UTC)
  3. Oppose — this seems slightly premature, and the linked discussion from Wikidata seems to indicate that they would not like to see Persondata nuked just yet. Titoxd(?!? - cool stuff) 18:26, 21 July 2014 (UTC)
    • How about nuking it as soon as Wikidata has it under control? bd2412 T 19:09, 21 July 2014 (UTC)
      • That wouldn't be too problematic, but it's a horse before the cart problem. (Wait a second...) Titoxd(?!? - cool stuff) 20:05, 21 July 2014 (UTC)
        • Titoxd, Wikidata is not importing any data except for |SHORT DESCRIPTION=. This has already been imported via a bot approved in May 2013. In the linked discussion, the Wikidata people were fine or don't care, only two non-wikidata people objected. One of whom uses the data for their personal amusement.
          • Would Wikidata be interested in eventually importing other Persondata fields? Titoxd(?!? - cool stuff) 20:39, 21 July 2014 (UTC)
  4. Oppose. The proposer has not provided any English-language documentation demonstrating that Wikidata is, or soon will be, a fit successor to Persondata. Adding to my opposition, I have become active at wikidata to try to get this matter addressed, and I find a low level of activity and only a few editors over there seem to be interested in improving quality. I believe wikidata lacks a critical mass of editors to create reliable information and should be ignored until they prove their ability to provide reasonably reliable information. The only area they seem to be doing an adequate job in is interlanguage Wikipedia links.Jc3s5h (talk) 19:47, 21 July 2014 (UTC), Remark extended 1709, 11 August 2014 (UT)
    • Jc3s5h, Nobody currently uses the data contained in Persondata. How can there be a successor to something nobody uses? People do use Wikidata and DBpedia. Bgwhite (talk) 20:26, 21 July 2014 (UTC)
      • The proposal uses Wikidata as partial justification for the removal, but there is no link to any documentation about the part of Wikidata that would cover people. As for nobody using Persondata, there seems to be some disagreement about that. Jc3s5h (talk) 20:51, 21 July 2014 (UTC)
    • @Jc3s5h: Wikidata entries for people include a |label= property, which is the equivalent of |SHORTDESCRIPTION=, but also multilingual. They also have |Also known as=, |date of birth=, |date of death=, |place of birth= and |place of death=. Not to mention dozens and dozens of other properties, not available in Persondata, such as |gender= and |VIAF identifier=. See, for example d:Q17279725. Each property can be programatically displayed in Wikipedia templates such as infoboxes, succession boxes, etc. - unlike Persondata. In short, Wikidata does everything that persondata does, and much more besides. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:26, 22 July 2014 (UTC)
  5. Oppose. I am just using Persondata to populate some missing birth/death dates in Wikidata; there are hundreds of thousands of statements that can be used on Wikidata. And if Wikidata were fully "populated", there is no reason to run bots to sync; the template can automatically show Wikidata information if no local data is set, and even add the page to a maintenance category if both is the case, so the information can be merged on Wikidata, and the local data can be removed. Once that is done everywhere, we can think about removing Persondata. Not before. --Magnus Manske (talk) 22:44, 21 July 2014 (UTC)
    1. @Magnus Manske: I fear a misunderstanding; Persondata is not displayed in this wiki. When do you anticipate finishing your bot run? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:42, 22 July 2014 (UTC)
      1. I am aware that it is not displayed here. I have only just started with the bot; there are many cases (e.g. "fuzzy" dates) that I am not sure how to handle yet. IMO it would be beyond strange to destroy data in the Persondata template unless we can be sure it has been properly synchronized with Wikidata. --Magnus Manske (talk) 09:13, 22 July 2014 (UTC)
        1. @Magnus Manske: Thanks for the prompt response; I was referring to your "the template can automatically show Wikidata information" comment. Are you confident that the persondata you are importing is accurate and up-to-date? Do you check it against visible values in the infobox, or lede? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:26, 22 July 2014 (UTC)
          1. @Pigsonthewing: Probably the wrong place to discuss my bot's internals, but I also use the Infobox, and the German Personendaten template; I import the highest precision value into Wikidata, with "source". --Magnus Manske (talk) 12:18, 22 July 2014 (UTC)
  6. Oppose People do use persondata. I am using the data extracted from Persondata on my own website to generate facts eg "Who is 50 years old today". Although my use may be regarded as trivial,it shows that Persondata is available for serious research - births and deaths of over a million notable people. A lot of people are stating that Persondata is not used, but on what evidence? Extraction tools exist, who knows what people do with the article they download?
    My second reason for opposing is that based on my own experience, Wikidata does not provide a reliable alternative for birth and death dates. Admittedly, there appears to be an editor who updates Wikidata death dates as soon as they happen, but new articles and fixes to old articles do not get onto Wikidata. Someone editing an article would not necessarily think that they need to fix Wikidata as well.
    Finally, again from my experience, Persondata is pretty accurate. I expanded my own software to validate the extract, comparing dates against categories for example. There were only two or three thousand entries, from 1.1 million articles, where persondata had vandalised or out of date data and I am currently fixing those! Periglio (talk) 23:38, 21 July 2014 (UTC)
    @Periglio: Why are the results of a "Who is 50 years old today" query on Wikidata not acceptable? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:39, 22 July 2014 (UTC)
    @Pigsonthewing:Because I would miss Joe Gulla who is 50 tomorrow (at time of writing in my time zone). My point is that no one has explained how Wikidata gets updated when an average editor adds a date to an article. I remain opposed until I know Wikidata is not just a snapshot at the time the original bot ran. Periglio (talk) 21:12, 22 July 2014 (UTC)
    @Periglio:. At the moment, I do not think this sort of update is done systematically. But again, is it done for Persondata ? If so, it should be possible to update the system so that it updates Wikidata instead. --Superzoulou (talk) 09:46, 28 July 2014 (UTC)
    @Superzoulou: Persondata is updated manually, but will normally be seen by editors updating the article. The editor is not necessarily aware of Wikidata so I can see a situation where Wikidata will be out of sync with Wikipedia. This is a general problem for Wikidata. There will be more people actively maintaining accuracy on Wikipedia, and there does not appear to be anything in place to keep Wikidata in sync. Periglio (talk) 15:48, 28 July 2014 (UTC)
    @Periglio: Persondata are not very visible either: you need to either edit the very last section, or the whole page and scroll all the way down to the end of the page. I doubt many users do it. With the Visual Editor, it might be even worse. Do we have any data about how many people update Persondata ? Without really looking for it, I just found an article (Otto Zdansky) with Persondata out of synch with the article's body. For the (few ?) experienced contributors, who update Persondata, I think we could advertise more Wikidata instead. --Superzoulou (talk) 20:46, 28 July 2014 (UTC)
  7. Oppose for now - This proposal seems a bit premature. Once Magnus and others are finished utilizing Persondata, then we should remove it, not before. Kaldari (talk) 21:20, 30 July 2014 (UTC)
  8. Oppose - Wikidata is not able to adequately run the data and use it in a meaningful way or respond as flexibly as Enwiki users have made it - Wikidata is not equal or better than our current system and is a very technical part of the projects that seems unable to keep pace or integrate efficiently to make Persondata truly obsolete or needlessly redundant, yet. ChrisGualtieri (talk) 04:46, 4 August 2014 (UTC)
  9. Oppose - I do not see a legitimate reason for the removal of Persondata. It is assuredly helpful for those who are collecting large amounts of data, and allows a way to index the individuals. Currently wikidata is not ready to be the single source of this information and I think we should revisit this at a later time. Jab843 (talk) 02:50, 5 August 2014 (UTC)
  10. Oppose - Persondata is a useful component for editors who wish to add data which would not always be presented in an article (especially if there is no box) including variations in the name (or spelling thereof), additional names (stage names, pen names), exact date of birth and death (rather than just the year), exact geographical locations (including any useful details of village, municipality, region, country) in addition to those specified in the article. I have no idea how I can add such information to Wikidata when writing a new biography -- or indeed how to access and update Wikidata in order to update incorrect data in existing biographies.--Ipigott (talk) 06:12, 5 August 2014 (UTC)
  11. Oppose because of Magnus' project, if nothing else; we mustn't delete persondata as redundant when it still has substantial amounts of unique information. Moreover, Ipigott makes a great point; this is useful for people who are familiar with Wikipedia but not with Wikidata. Perhaps we could deprecate its addition to articles, saying "If you want to add this type of metadata, please create a Wikidata entry", but not remove it from pages that already have it. Nyttend (talk) 18:39, 5 August 2014 (UTC)
  12. Oppose because WikiData is totally unsourced. Most death date has not any references. Christian75 (talk) 18:34, 7 August 2014 (UTC)
    This is true, but part of bigger problem. Although Wikidata largely references Wikipedia for birth and death dates, I am finding that Wikipedia rarely has a date of birth reference. I have raised the issue at the biography project Wikipedia_talk:WikiProject_Biography#Birth_date_citations although not many comments have been made. Periglio (talk) 20:23, 7 August 2014 (UTC)
  13. Oppose Premature. Alberto Fernández Fernández (talk) 19:01, 7 August 2014 (UTC)
  14. Oppose There are a number of en.Wikipedia-only programs which read Persondata fields, but do not read Wikidata. They probably could be rewritten to read Wikidata, but others above say it's not well-formatted. — Arthur Rubin (talk) 01:26, 15 August 2014 (UTC)
  15. Oppose This should not happen unless and until Wikidata is shown, and accepted to be, reliable and maintained with appropriate controls to ensure that it stays accurate. S a g a C i t y (talk) 07:16, 17 August 2014 (UTC)
  16. Oppose, not convinced that there is a problem with keeping it around for a while longer until more people are accustomed to working with Wikidata. —Kusma (t·c) 07:35, 17 August 2014 (UTC)
  17. Oppose: Premature, even WikiData doesn't want this to happen (yet), nominator's claims are false, and most of the "support" !votes either are predicated on such false assumptions or basically amount to WP:IDONTLIKEIT or WP:IDONTKNOWIT, some quite explicitly ("Since I don't use WikiData I find PersonalData to be absolutely useless anyway", which also misconstrues the difference between WikiData and this metadata). Basically a lot of people who don't actually know what's going on are saying "get rid of something I don't understand!" How about, no. At least not yet. When WikiData has sourcing standards (at least for material they get from Wikipedia) that are reliable enough for Wikipedia, then maybe we can move this metadata over there.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  01:57, 19 August 2014 (UTC)
  18. Oppose As premature. Until Wikidata provides a stable, referenced and suitable alternative, persondata should stay where it is.  Philg88 talk 08:18, 20 August 2014 (UTC)
  19. While IU think it can use some more standardization, I think it's useful to have on the page. (And by the way, it is also a good marker for biographical articles - I used it to allow me to exclude all biographical articles in stub searches a few times.) עוד מישהו Od Mishehu 12:51, 20 August 2014 (UTC)

Wikidata person import faulty[edit]

Whatever process for importing personal data into Wikidata from Wikipedia appears to be faulty. For example, Francis Bacon says he was born born January 22, 1561, which obviously must be a Julian calendar date, since the Gregorian calendar wasn't created until 1583. But the Wikidata item (Q37388) says his birth date is January 22, 1561, and claims the date was imported from Wikipedia. So who or what is doing this importing and do they have any clue about how calendars work? Jc3s5h (talk) 20:25, 7 August 2014‎ (UTC)

I will just add that Francis Bacon is not just a one off incident. My analysis has found the same happening with the Russian calendar and a few where the bot picked up a inaccurate date that was not the date being reference. Another example Lekain where Wikidata has two dates, which may be Gregorian related. There is a lot of tidying up that needs to be done. Periglio (talk) 20:14, 7 August 2014 (UTC)
Where did you report this issue? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:00, 17 August 2014 (UTC)
Firstly, I note that our article does not mark the date as Julian. I see that you have already raised the issue at wikidata:Wikidata:Administrators' noticeboard#KLBot2 creating incorrect birth dates, but for the benefit of others, the Wikidata edit in question was made by User:KLBot2 on 14 June 2013. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:00, 17 August 2014 (UTC)

Should the MediaWiki software be modified to include an option for specialized (such as blacklist / whitelist) blocks?[edit]

Would a system of specialized blocks be helpful? Dustin (talk) 02:41, 24 July 2014 (UTC)

Note: This was partly discussed beforehand at Wikipedia:Village pump (idea lab)/Archive 14#Specialized blocks, and I have decided to bring my proposal here. Please read that page first, though. I have started this as an RfC because I consider it to be of significant importance.

(The following has been copied from the idea lab)

The following is a proposed change to the MediaWiki software.

I don't know if something like this has already been proposed, but a brief search on my part didn't turn up something like this, so I will put forth my ideas. Here is my possible proposal, but I am going to give it here first just so we can discuss it and refine the idea beforehand. I would propose that we modify the MediaWiki software as to allow for specialized blocks. Blocks currently only have two options: a block on editing all pages except for a user's own talk page, or a block on all pages, including the user's own talk page. In my new "specialized" block system, there would be many more options.

  1. An administrator could block a user for disruption from editing either a specific, individual page, or the block could apply to a selection of pages. In cases where a user cannot be trusted to follow a topic-ban or does not feel that he/she can follow his/her restrictions, then an administrator could simply block that user from editing a list of manually selected pages which are "at risk".
  2. An administrator could block a user from editing all pages (minus manually chosen exceptions) that have a certain prefix. For example, if one user was being overly disruptive on SPI pages (and I am not talking about vandalism), then an administrator could block that user from editing all pages starting with "Wikipedia:Sockpuppet investigations/".
  3. If there were situations where it was desired that an editor requesting an unblock edit one page apart from his/her talk page similar to this recent instance (but where the user could not be yet trusted to stay on only his/her talk page and the one exception page), then the block could be modified to ignore that one page.

I do not know how we would implement this because it is necessary that someone would develop this feature, but that is something to consider at a later point. I just want to know the opinions and/or ideas of editors. Dustin (talk) 02:42, 24 July 2014 (UTC)

  • I support the general idea, though the specifics of what kind of granularity we want is up for grabs. In particular, one thing I definitely would find useful is the ability to block IP ranges (perhaps as large as /8) from specific pages. Currently the only way to do this is with an edit filter, which impairs performance. -- King of ♠ 02:50, 24 July 2014 (UTC)
    Actually, what Graeme Bartlett said makes a whole lot of sense. And it should be possible to select an IP range as the user to be restricted by the filter. -- King of ♠ 03:43, 26 July 2014 (UTC)
  • Oppose because it would require development support from the WMF. These are essentially topic-bans with supporting block. Robert McClenon (talk) 02:52, 24 July 2014 (UTC)
  • Strong oppose The discussions on blocks have been extensive and the community has been pretty further options are required or needed. No support from me. Sorry.--Mark Miller (talk) 02:59, 24 July 2014 (UTC)
    • You obviously have neither looked at the previous discussion like I suggested, nor at the links at that discussion. Back in 2005, nine years ago, there was another proposal like this one, and it received over 80% approval. I know that was a long time ago, but why should we not reconsider? Dustin (talk) 03:04, 24 July 2014 (UTC)
      • I don't give a crap about that as you don't give a crap about other discussions so just stop complaining and let this go to the community now. You said your piece. If that isn't enough, you failed.--Mark Miller (talk) 03:08, 24 July 2014 (UTC)
  • Having this discussion here somewhat clouds the purpose of the discussion. If the goal is simply to come up with a technical specification of what such a system would look like, would be a better location. A discussion here will inevitably involve local policy implications and we need to have some concrete idea of what the feature's capabilities are before such a discussion could reasonably proceed. Mr.Z-man 04:20, 24 July 2014 (UTC)
I would wonder if this is actually a local issue for Wikipedia as proposed by Dustin. I may think that dragging a discussion from 9 years ago, into this discussion isn't even relevant today but hey....lets let this go its course and see what happens.--Mark Miller (talk) 04:27, 24 July 2014 (UTC)
  • Support As I said on the idea lab this could be an edit filter just applying to one user (or IP). When optimised so that the filter only ran for 1 user there would be no performance impact on the rest. There would be plenty of fine grain here, denying uploads, moves, use of interaction banned users talk pages and so on. Graeme Bartlett (talk) 07:28, 24 July 2014 (UTC)
  • Support However, like Graeme Bartlett I would suggest to go into the direction of edit filters that apply to individual users or IP ranges. --AFBorchert (talk) 08:41, 24 July 2014 (UTC)
  • Not persuaded that usefulness outweighs the effort and complexity. For logged-in editors, this idea is a non-starter for me. If a particular user is subject to a topic or interaction ban, then either they stick to the terms of their editing restrictions, or they get blocked entirely. A user who lacks the maturity or restraint to adhere to an editing restriction (and, for that matter, who edited in a manner sufficiently disruptive to earn such a restriction in the first place) doesn't need additional technical constraints, they need to stop editing until they can control themselves.
    For IP addresses, I can see some argument for this as a way to reduce collateral damage (particularly when placing rangeblocks), but I suspect it will be more complicated than it's worth. Semi-protection already exists as a solution, though it does affect all IP editors of an article. (It's a bit blunt as a tool, but we already tolerate even long-term semi-protection of articles where warranted by circumstances.)
    From an admin standpoint, I can see this becoming rather complicated to manage and track. If I block an IP range from editing a particular article, does it show up in the IP's block log, or in the article's logs, or both, or neither? TenOfAllTrades(talk) 17:52, 25 July 2014 (UTC)
  • Oppose This is a solution looking for a problem. It introduces complexity where none is needed. If a user will not follow restrictions then a conventional block will work. Either a user is willing to follow community expectations or they are not. Specialized blocks would result in gaming of the system. Chillum 18:06, 25 July 2014 (UTC)
  • I wonder: Could selective whitelisting be used to keep someone blocked, but make it possible for them to clean up their own copyvios on specific, identified pages? That might be desirable. WhatamIdoing (talk) 18:49, 25 July 2014 (UTC)
    This goes to the point I made above. If we can't trust someone to follow editing restrictions without building a technical wall around their editing, I can't imagine we would trust them to perform a task requiring careful judgement like cleaning up copyvios—especially where they were the ones who introduced the copyright violations or plagiarism in the first place. TenOfAllTrades(talk) 19:03, 25 July 2014 (UTC)
    It's not unusual to see a request for someone to be fully unblocked so that they can help with copyright cleanup. That requires a lot more babysitting than providing access only to specified pages would. WhatamIdoing (talk) 23:16, 25 July 2014 (UTC)
  • Support the idea, assuming it is technically possible. This would make more sense than existing practice in a number of areas. In the case of 3RR violations, for instance, if an editor is causing problems by edit warring on an article then our only option for stopping them is to prevent them from editing every single page, anywhere, even though they are only causing problems on one page. It would make more sense to prevent them from editing the one page where the edit warring is taking place. Hut 8.5 10:54, 26 July 2014 (UTC)
  • Support - this would allow bans to be more-easily enforced, as well as a list of situations where it would be useful regarding blocked users (e.g {{2nd chance}}, unblock discussions in locations other than the user's own talk page). עוד מישהו Od Mishehu 19:56, 27 July 2014 (UTC)
  • Support Seems like this would be a valuable addition to the admin toolbox. Toohool (talk) 01:18, 31 July 2014 (UTC)
  • Support, ignoring the technical design requirements of which I know very little, but I think any idea worth implementing is worth doing the technical work. I'm a little concerned about difficulty using this for "broadly-construed" topic bans, but maybe we can implement a way to block users from editing pages in a particular category. It's a good idea, anyway. However, I also agree with what another user said above that if an editor can't play by community rules then full blocks and/or community bans are coming anyway. Ivanvector (talk) 15:41, 5 August 2014 (UTC)
  • Support. I like the idea behind this, in principle. Calidum Talk To Me 01:31, 18 August 2014 (UTC)
  • Strong oppose. This is not a good idea at all. Bans exist both to prevent disruptions to the community, and to give infringing editors the opportunity to remain a part of the community. They do this by abiding by the restrictions of their ban. If they are unable to do this, we gave them the WP:ROPE, and they have chosen by their actions to set themselves as being outside the community. Blocks are for those people who chose not to be a part of the community, either by contempt for the bans that the community has imposed on their editing, or by simply breaking obvious rules, eg vandalism. There is no "partial" being a part of this community. You either abide by the rules, or you don't get to participate here. Selective blocks just prevent those people who consider themselves outside of this community to demonstrate to us their decision to stand apart by violating their ban. Selective blocks open up a huge pandora's box of wikilawyering possibilities, and do nothing to promote the community. This is just plain a bad idea. VanIsaacWScont 01:46, 18 August 2014 (UTC)
    • Using the word "strong" doesn't give your !vote any more weight (I don't see why "strong support" and "strong suppose" are ever used), but that being aside from the point, I don't think you considered proposal #3. Dustin (talk) 16:31, 18 August 2014 (UTC)
      • The word "strong" indicates that it is a categorical objection or support of the proposal, rather than, say, a preferential or logistical consideration behind a person's position. And since this is a !vote, of course every !vote is weighted; that's the entire point of it being a !vote. Even though I don't understand how situation #3 can even come about - if we can't trust someone whose contribution history is logged in one place (so it's easy to revert) to have access to more than one page, how could their actions on that one page possibly instill enough trust to allow them access to any more of the project? - #3 can still be accomplished with the current permission scheme by simply copying that article content to their talk page, where they can edit away. VanIsaacWScont 18:59, 18 August 2014 (UTC)

Alternate proposal[edit]

Not sure if this is a proper format for an RfC, but here we go. Admins(explicitly not EFMs) are now permitted to make an edit filter that can block a user from editing certain pages while allowing them to edit others. This is to be treated as seriously as a block(admins are explicitly not to use these for TBANs unless a user made a TBAN infraction normally warranting a block.) For example, if a user requests to have their block discussed at ANI, that user would be unblocked and the filter modified so that the appealing user is blocked from editing any page except ANI. (To avoid confusion that would otherwise arise, admins would create one or two filters that would contain the entire system for blocking edits, something like: ((user_name==appeallingeditor) & (article_prefixedtext !='Wikipedia:Administrator's noticeboard/Incidents')) | ((user_name==TBANnededitor) & (article_prefixedtext =='ContentousArticle' | ...)) then block action, which would prevent appeallingeditor from editing any page but Wikipedia:Administrator's noticeboard/Incidents, and prevent TBANnededitor from editing ContentousArticle. (I'm sure someone can come up with some better code, I was just messing around) Cheers and Thanks, L235-Talk Ping when replying 21:31, 8 August 2014 (UTC)

  • I see that you got more into the code than I ever did... at least from the way it appears, I think I would support this proposal because it would allow for stronger enforcement by administrators, and it would meet some of the goals of my main proposal above. Dustin (talk) 21:44, 8 August 2014 (UTC)
  • Support in theory, but in practice, this may end up causing more trouble than it's worth if the number of edits which hit the EF condition limit is too hig (right now, it's at 0.77%, but it occasionally gets above 5%). עוד מישהו Od Mishehu 08:19, 13 August 2014 (UTC)
  • Well the hitting the EF limits is why I suggested getting special support for edit filter per user or IP in the code. This would make it very efficient, as it would only run for the affected user. Graeme Bartlett (talk)

RfC: Should the hidden navbar be removed from the base Stub and WikiProject banner templates?[edit]

Should the CSS-hidden navbar be removed from the base Stub (1.8 million pages) and WikiProject banner (5.5 million pages) templates? -- Netoholic @ 19:16, 30 July 2014 (UTC) (re-signing to keep from being archived early -- Netoholic @ 01:46, 15 August 2014 (UTC))


  • Remove - This {{navbar}} template call was added to the WikiProject banner back in 2008, but then immediately hidden by CSS (display:none) in {{WPBannerMeta/core}}. The same thing exists in the Stub base template {{Asbox}}. There is a CSS trick which editors can add to their custom CSS files, but this trick hasn't been publicized and is in use by only a handful of already experienced users. Even though it is hidden by CSS, it still adds a few hundred characters to every stubbed or bannered talk page download (and pages with multiple banners add it multiple times). The navbar template transclusion itself is called every time a page is saved (which for talk pages can be alot). Now, normally, we don't worry about performance, but in the template design space we do have to weigh the costs vs benefits, and since these templates are so widely used, I think every small efficiency we can do deserves consideration. The people that know about this hidden trick or would use it, are also experienced enough to get by without it on the rare occasions they need to edit a particular stub or WikiProject template. -- Netoholic @ 19:16, 30 July 2014 (UTC)
  • Keep and add the code to view the links to MediaWiki:Group-templateeditor.css. I'm basing this on the discussions about this I found (Template talk:Asbox/Archive 2#Navbar & Template talk:Asbox/Archive 4#Why the navbar ?) which were sufficient enough to convince me it is a good idea to have the links. I'd be happy to brief over other discussions if you care to link them. Also, I'm not sure if you've notified the people involved in the previous discussions (if you even found all of the discussions, which I'm sure I haven't and don't expect you have), a quick group ping (MSGJXenoAmaltheaTheDJHappy-melonTopbananaGrutnessWOSlinker) should do it. — {{U|Technical 13}} (etc) 14:36, 1 August 2014 (UTC)
  • Neutral. A few facts I can throw at this discussion; firstly the hidden navbar edit links are used by 8 Wikipedians. Per WP:PERF, we should be prioritising pretty much everything over efficiency; there is some discussion here about the impact of this feature - despite the implementation being truly and absolutely awful, it's trivial in the bigger picture of Wikimedia ops. On balance, if there's a better way to do it, we should. If not, we keep it as is. - TB (talk) 09:48, 2 August 2014 (UTC)
  • Remove. It was never really necessary to have this on stub templates in the first place. As Netoholic points out, if you're editing stub templates, chances are you've got enough nous here to know how to do that without having to resort to the embedded links. Similarly, if you're editing a wikiproject's banner, chances are you know what you're doing. I've added the necessary coding in monobook to be able to use them myself, but I can't remember the last time I've actually edited a template this way - it's only the barest fraction quicker than simply editing direct from the template's page. Having the links there, if anything, encourages people to edit the templates - and while editing article pages should be encourages, making changes to heavily-used templates is beyond the scope of "be bold", since it can have far-reaching consequences. So no real benefit, and potential for trouble = ditch it. Grutness...wha? 11:34, 2 August 2014 (UTC)
  • Comment - I don't know enough about this template and its uses to opine about it specifically, but I would like to make a general comment. WP:PERF tells regular editors not to worry about performance because it's beyond their ability to do much about it, since their permissions have been deliberately limited to prevent project-wide impact. While it's true that the "IT professionals" or others with special permissions may be needed to make changes such as the one being discussed, they rely on us to decided which features are important. More and more readers are viewing Wikipedia pages on mobile devices, and I've been reading a lot of comments from editors about page load times on these devices. If a template is being called a gazillion times and is rarely used, I think that efficiency should be considered as well as utility. —Anne Delong (talk) 10:31, 7 August 2014 (UTC)

Patrol edits that remove more than 500 characters[edit]

Proposal: if an editor who's not a reviewer or admin removes more than 500 characters, mark such edits and patrol them. Even patrolling edits by such users if more than 1000 characters were removed would be a most welcome change. Things like this should not go unnoticed for more than three months. The section wasn't blanked there (so it wasn't tagged) and a bot made an edit approx. 2:04 hours later which meant the vandalistic edit was no longer the latest revision. -- (talk) 12:19, 6 August 2014 (UTC)

Large edits are already marked; go to the page history and you'll see that 1,249 is given in big bold text, both when it was removed and when you restored it. Are you thinking of something more extensive? Nyttend (talk) 12:28, 6 August 2014 (UTC)
Yes. Not large edits in general, only large removals. And not with just bold text, but Tag them, and then patrol those edits. Are, for example, edits tagged "section blanking" being patrolled? -- (talk) 12:37, 6 August 2014 (UTC)
I imagine such a patrol would become backlogged almost instantly and never be fully looked through. I don't think we need another such process. Sam Walton (talk) 13:21, 6 August 2014 (UTC)
I think the idea has merit. While I do not have the technical skills to do the check, it shouldn't be hard to figure out how many edits fall into this category. I would even consider making the threshold 1000 characters by anyone who is not yet confirmed or autoconfirmed. If there are thousands in a week and most are false positives, yes it will become useless, but my guess is there won't be that many. My bigger concern is the possible incidence of false positives, where a new user accidentally removes something, then fixes it immediately. If that is common, then false positives may dominate the list.--S Philbrick(Talk) 14:10, 11 August 2014 (UTC)

Really I see no reason to be more vigilant about large removals than large additions. Actually, the latter may need more attention, because someone dumping a large quantity of borderline nonsense into an article is less likely to be summarily reverted by any passerby than a testing-style deletion of a random chunk of text.
This does bring up another point. The problem with the current numbers that show up in the watchlist is that they show you only the net change in the number of bytes. So if someone, say, replaces a good paragraph by a nonsense paragraph of equal length, the change shows up as 0, and people may pass it by assuming that it's a punctuation change or something. What I would like to see is the magnitude of the diffs, both positive and negative. In other words, if the diff adds 123 characters and subtracts 122, then we would see (+123)(-122) in the watchlist line, instead of (+1). --Trovatore (talk) 14:24, 11 August 2014 (UTC)

Yes, the addition of more text is more of a problem than removal. 99% of the "large addition edits" I see on my watchlist from either IP editors or usernames I don't recognise are copyvio issues. Lugnuts Dick Laurent is dead 12:56, 14 August 2014 (UTC)
Especially if the additions are grammatically correct and coherently written. WhatamIdoing (talk) 21:42, 14 August 2014 (UTC)
  Our general usage is so poor that correctness and coherence are a sign of copyvio? That's not good. Reminds me of a line from John Donne's The Perfume about "a good smell".
  I think Trovatore has a good point re net change. ~ J. Johnson (JJ) (talk) 22:43, 14 August 2014 (UTC)
I am sad to say it, but, yes, "correctness + coherence + new user" is a strong (but not absolute, of course) predictor of a copyvio involving an online source. WhatamIdoing (talk) 23:25, 14 August 2014 (UTC)

Show article quality to readers?[edit]

What do people think of showing article quality measurements besides GA and FA to readers on the main article page? It's useful information for readers, as it gives them a rough estimate of how "good" the article actually is. For example, I know I would be more likely to read a B-class article than a start-class article when browsing, or I'd be more likely to trust an A-class article for accuracy than even a GA-class article. StringTheory11 (t • c) 05:41, 9 August 2014 (UTC)

The last discussion on A-class on this board is at WP:Village_pump_(proposals)/Archive_110#Restrict_A_class_usage. That has a variety of viewpoints to get us started. The thing that struck me was: no one talked with the people who work in A-class. We could ask them if you like. - Dank (push to talk) 09:52, 9 August 2014 (UTC)
I never understood why A-class articles don't get a topicon; I suppose a possible reason is that readers can surmise that FA>GA, but not necessarily that A>GA, which seems to me to be a valid but weird system. As for lower ratings, it just creates loads of work updating it, not to mention that often ratings are out of date, or some projects have (for whatever reason, whether specialised criteria or more regular reviews) different ratings.
Another issue is that some articles are A-class quality but will never get a formal review; this puts Hurricane and MILHIST articles at an unfair advantage. I don't support displaying A-class unless these issues can be worked out. BethNaught (talk) 10:21, 9 August 2014 (UTC)
If you are talking about adding the icons of B, C, Start class to the articles just like we have done for GA, FA, then I agree with this proposal. OccultZone (TalkContributionsLog) 12:09, 9 August 2014 (UTC)
In my experience, these quality tags are so randomly and carelessly assigned that they are typically all but useless. I've repeatedly had "start" class tags slammed on articles of my own that were perfectly sourced, perfectly correct and perfectly relevant, albeit relatively short, by drive-by taggers who had evidently hardly even read the article. I'd be strongly opposed to giving these tags higher visibility than they have now, unless we also introduce some measure of accountability for the taggers and an expectation that quality tags should regularly come with an explicit and testable assessment of the relevant criteria somewhere. Fut.Perf. 12:38, 9 August 2014 (UTC)
I have to agree with Future Perfect, most assessments are not worth the electrons they are printed with. In large part this is because the majority of assessments are performed by "reviewers" operating at a rate of 4 to 8 articles/minute in 50 to 200 article bursts. At these rate of speed, it is not reasonable to assume the reviewer has even loaded the article being assessed, let alone that the articles being assessed were read. --Allen3 talk 12:49, 9 August 2014 (UTC)
Also agree - most reviewers seem to judge only on the length of the article and whether it has refs etc. There is rarely any concept that some subjects only need (or, especially in history, can ever have) short articles. Johnbod (talk) 14:16, 13 August 2014 (UTC)
  • Stub-class is noted on the page already. Start-class through B-class are essentially unstandardized and aren't helpful to display. A-class could certainly be displayed, but it's such a niche rating (product of a process used almost exclusively by a set of WikiProjects I could count on one hand) that there has never been sufficient motivation to do so. --erachima talk 12:44, 9 August 2014 (UTC)
I think this is a good idea, but only if the classes are more standardized. Specifically, for each class rating, I'd like to see at least an explanatory edit summary, stating why the article's class was changed. This could take the form of explaining issues the reviewer had with the article, for example. For controversial situations I'd like to see a quality scale assessment on the talk page, going by the criteria for each class. But for that we'd need to set down clear criteria saying what C-class is, what Start-class is, etc. Currently I don't see any list of criteria below B-class.
I also think that A-class is a bit weird honestly. There is this requirement of having a review, but that is only practical for the largest WikiProjects. And even so, you may not get a review, because you don't get the sticker of prestige. And who aims for A-class as a goal in itself, instead of as a stop on the gruelling road to FA?
I am intrigued by the B+-class label. WP Maths, WP Stats, and WP Elements use it (there may be more). But I find the part of it on WP:1.0/A stating "Possible good article nominee" very weird. It defines a class in terms of another class and kind of reduces B+ to just "ready for GA". Does it usually get independent usage?
I kind of see the point of fine distinctions like we have now, but without clear criteria they aren't going to be useful. I submit that there's really only five really important levels at the moment: Stub/Start/B/GA/FA. The first two are a mess or very short. B is the first level where you have a coherent piece that really adequately describes the topic – I don't see the point of C when the point where an article is substantial is very subjective, and the rest is similar to Start.
A has clearly defined criteria, but is rarely used. I get the impression it's not found to be useful, and its position between GA and FA is perhaps counterintuitive. Perhaps A might be useful if you have distinctions between "FA in content level" and "FA in style level" (I used to think those were A and GA), but while doing the latter alone is easy (come on, look at some obscure FAs which didn't get good peer review from TCO's infamous study), doing the former alone kind of does the latter for you because otherwise your content is incomprehensible. (OK, barring citation format, punctuation, etc. which most readers as opposed to researchers do not honestly care about.)
As for B, there is little social reward for this one, even though work to get Stub/Start to B is valuable to our readers. It's not a sticker that people like to post on their userpages, maybe because there isn't a review (although there should be IMHO). WP:Four Award has DYK/GA/FA: I don't get why new article and DYK are counted separately, because they will generally follow together because of the time limit. And's DYK is kind of odd: it's more of an editorial service than a reader's one. The hooks are not always interesting (examples can be provided upon request: thanks to R8R Gtrs by the way for pointing this out!), and it's hard to make it so for some articles: so to make every article have that chance, you sometimes have to sacrifice hook interestingness. But it's on the main page! Surely readers are important too? And it's for this reason that I've tried to make my few hooks interesting, to make readers want to click the link because they are genuinely curious.
But DYK is kind of outside the class scheme. Maybe it would serve very well as a low-class review status, to be the step before B. But I don't see this happening all the time.
This was supposed to be a one-paragraph short post. I don't know what happened: the tale must have grown in the telling. I do hope I tied all the loose ends together, though. Also note that I'm primarily a WP Elements member, which may colour my views because it works on vital articles (level 4) for the most part. Perhaps an interesting case study is WP:Chemicals with a simplified A/B/Start/Stub scheme. It says "Although the Wikiproject does acknowledge the Wikipedia status of Featured Article (FA) and Good Article (GA), these are generic qualifications only, with no specific attention for chemical completeness, and as such are not listed in our Classes." This leads me to wonder if each project should really implement more specific criteria, to supplement or replace the general ones. Double sharp (talk) 21:35, 9 August 2014 (UTC)
I definitely agree with you that C-class is really hard to nail down. In my mind a short blurb is a stub (though the assessment systems says a really bad longer article can be so classified), Start is basically a work in progress (either incomplete or poorly referenced), and then B is a basically complete article that hasn't undergone a peer review process. That leaves C as basically a better start class article. Monty845 22:47, 9 August 2014 (UTC)
The benefit of A-class, for those projects that use it, is that it notes the article is up to the standards of the associated wikiproject. Whether that should actually be how things work or not, I have no idea, but it's the functional meaning. I suspect the idea behind 'B+' is similar: it marks the article as reviewed by editors who are involved in the subject. (Whereas GA-class requires external review.) Thanks to the at times months-long waits articles have on GAN, and then the additional delays once reviews start due to e.g. copyediting stuff, I can see the appeal of a preliminary review and associated grading. --erachima talk 23:14, 9 August 2014 (UTC)
@Erachima: I can definitely see the appeal of that, but it seems as though for all but the largest WikiProjects there is no such review process and grading. WP Elements used to have them for A and B, but after a while they became inactive. That seems to be the problem. For the average WikiProject, I submit that you really only need A/B/Start/Stub, with FA and GA as external general ratings. Maybe even a detailed review isn't necessary for all WikiProjects: just an edit summary explaining the rerating (although the detailed review should definitely be posted if it gets requested). That's what I did when I rerated the WP:ELEM articles a few days ago.
Also, if the ratings differ from project to project, does showing them as topicons really help the reader (as opposed to the editor) gauge its quality? GA and FA are general ratings, so those do help the reader, but I question if showing the rest as topicons would help if they are specific to one WikiProject or another. And what if an article is under multiple WikiProjects and is rated differently by them? (Some time ago chlorine received A, B, and C ratings all at once!) Double sharp (talk) 08:34, 10 August 2014 (UTC)
B-class requires the article to meet six criteria. If an article only meets four or five of those, but is close, it's C-class. For example, if an article is very thorough and informative, but has large unreferenced sections or a confusing layout, it would be C-class. A B-class article could probably get through GAN but may need a peer review first. A C-class article would probably fail GAN right away. A start-class article is nowhere near the B-class criteria. —Designate (talk) 13:15, 10 August 2014 (UTC)
I agree with you here: that's what C and Start generally mean right now. But I submit that defining them only in relation to what B-class criteria they fail isn't a very good a definition. They should have criteria of their own. And from a reader's point of view, C and Start are after all both kind of unsatisfactory (Start is "most readers will need more", C is "Useful to a casual reader" only), especially for more technical topics when C wouldn't be very good at helping people understand the content!
Also, I think that if the layout is confusing, then an average reader wouldn't find it "very thorough and informative", simply because the info is hard to find. Double sharp (talk) 19:50, 10 August 2014 (UTC)
It's possible and acceptable for a WikiProject to write their own standards. Most don't bother. Even when they're supposedly working from the same standard, we find wide variation—and that's before you consider the problem of outdated assessments. User:Nettrom and User:EpochFail just screened WP:MED's stubs for me, and their list suggests that about one in 12 are improperly assessed. Just imagine what the numbers will be for a smaller and less organized project. WhatamIdoing (talk) 23:51, 10 August 2014 (UTC)
Agreed. We can fix that by doing similar screenings for all projects. (Although you are right that it'll be problematic for smaller and less organized projects.) Double sharp (talk) 12:17, 12 August 2014 (UTC)

Also thinking a little about B-class. On the one hand, it has clear criteria and gives the reader good (but not great) content. And getting a lower-class article to B does a great service to the reader, especially since many important articles are not of this quality (e.g. gold is C-class, mostly because it is kind of a mess.) But this is not rewarded. TCO wrote here "Still a little worried at the low social rewards for B and probably the lower stability of B class articles to [degradation]. I would like to see the top 1000 Vital at GA+ and also all the elements because of the benefits of review."

Given this, I think that we should have B-class review available for WikiProjects large enough to cope with it, just like A-class review, and that ideally those classes get topicons as well. B+, I don't know. It is not a standard class, and many large WikiProjects have shown that they don't need it. Nevertheless three WikiProjects (IIRC, Mathematics, Statistics, Elements) have implemented it (Elements as late as 2011). If it gets reviewed as well, I think it could also work.

But there would need to be a caveat for the reader for A, B+, and B stating the existence of different standards among different WikiProjects. Double sharp (talk) 12:33, 12 August 2014 (UTC)

Pretty much the only reason I don't use B+ myself is that it breaks the tables like the one at Wikipedia:WikiProject Astronomy/Article ratings. If support for the class was implemented in these tables, I would probably start using it, since I see it as a class that basically says: "this article is at the point where a GAN alone could address the problems necessary to bring it to GA". StringTheory11 (t • c) 18:44, 12 August 2014 (UTC)

I don't think there is value to our users in hat-noting B-class articles, because the B-class assessment covers so little that is not obvious to the casual reader. Consider the B-class criteria for a moment, which essentially read

  1. Page offers some basic attempt at sourcing.
  2. Page does not have glaring omissions.
  3. Page is not a disorganized infodump.
  4. Page is not grammatically incomprehensible.
  5. Page has appropriate organizational templates.
  6. Page is not a mass of jargon.

Now, of these criteria, how many convey "hidden information" of some sort to our readers? Generally only the first, though in some technical subjects the second may also require a bit of expertise to judge. The remaining criteria are simply a checklist of ways an article may very obviously suck. As a result, telling a reader that they are reading a B-class page communicates almost nothing to them that will not be immediately apparent on reading the article itself.
Where B-class is useful is almost wholly on the metadata side, where it can tell editors interested in a broad subject which articles are and are not at a level of basic presentability.
As to the "social reward" aspect of giving reader-visible announcements, I believe this is a red herring. There are two main routes to B, in my observation. The first is when a page rockets straight from non-existent or stub to B, and most of our writers who can crank out pages like that are perfectly capable of self-assessing when a page is B-grade. Many don't necessarily even bother with having it checked for B before putting it in the GAN queue, and I'm not considering that a flaw. In this context, you'd basically just be giving the writers an extra no-prize for having a draft of the article they're trying to write finished.
The other is when a page has grown organically via the traditional method of everyone who read the page for the last 8 years chipping in a couple sentences, which tends to create pages that have all the necessary factual content for B-grade but are a disorganized mess. In these cases, the reward aspect should already be satisfied: intrinsically speaking, the editor gets to enjoy knowing that it's by their efforts that the page is now essentially readable, and extrinsically, their work was acknowledged by another editor.
In conclusion, publicly visible announcements of article quality are useful to readers only to the extent that they convey hidden information about the page's quality. This is true for the FA process and true for the GA process. It is also in most cases true for A-class, though I suspect that for political and practical reasons a rebranding of A (EA? HA?) with a clearer and more unified associated process may be necessary before it attains community consensus as a recognized category. B/C/Start, however, lack this trait and should therefore be considered purely metadata. --erachima talk 15:08, 13 August 2014 (UTC)

Just a reminder to everyone — while of course this isn't relevant for unloggedin readers, you can get the article quality to appear for you on the top of the article by toggling a gadget. It's the gadget beginning with "Display an assessment"; see User:Pyrospirit/metadata for details. Nyttend (talk) 03:41, 15 August 2014 (UTC)


I was reading this revision of Opinion polling for the Scottish independence referendum, 2014, and I noticed that the ‘School, college and university surveys’ section contained 31 citations for one sentence in a way that was at odds with Wikipedia:Citation overkill. I did not want to spend the time going through the many citations in that section to see which ones were necessary for that particular statement and which ones weren't, so I thought I would flag the section with a template saying that the section contained an excessive number of citations and that disreputable or unnecessary references should be removed. To my surprise, however, there was no such template, so I decided to make one. I did so, added it to the article, and then added it to Wikipedia:Template messages/Cleanup/Verifiability and sources. A user, however, found some aspects of it ‘highly questionable’, and so removed it from the template messages page. He also asked whether there was a consensus behind it, and since there was none, I decided to attempt to establish one. What do you guys think of Template:ExcessiveCitations? We have message templates for virtually every other problem with references or citations (e.g. none, unreliable, more needed, not properly formatted, broken, not used properly), so why not include this one? Esszet (talk) 22:42, 12 August 2014 (UTC)

I dunno. Seems legit to me. I might use it, but I'm more likely to just cull the unnecessary or unreliable citations. In pop culture articles, they're usually very obvious. Discogs, IMDB, Rotten Tomatoes, and AllRovi seem to be the worst offenders. It's a simple matter to move them to the external links, where they belong. For offline sources, this template would be useful. NinjaRobotPirate (talk) 00:46, 14 August 2014 (UTC)
Sounds like a good idea as I suspect many editors have never heard of WP:CITEKILL. That said, I think it should be an inline template only–putting a big box at the top of the page saying "This article may contain an excessive number of citations" is potentially dangerous (e.g. the claim "But it said at the top of the article that I had to remove the citations ...") Instead, we should take a rifle (as opposed to a shotgun) approach with the flag at the end of the "offending" sentence/paragraph. By using a dated category, those so inclined can go through the backlog as and when. I created a similar template, which doesn't get used much(!) but it does the same thing - see {{Chinese script needed-inline}}.  Philg88 talk 16:12, 20 August 2014 (UTC)

Hey, we already have a template for that:

Or maybe you just want moar templates? --Atlasowa (talk) 16:39, 20 August 2014 (UTC)

Granted I may be working in some fairly specialized areas of the project, but I'm hard-pressed to imagine a single instance where I thought citation overkill was even remotely a problem. DonIago (talk) 16:57, 20 August 2014 (UTC)
I've seen instances of this. Usually, though, the problem isn't solely the number of citations. The problem was having a dozen biased primary sources rather than a couple of good sources. WhatamIdoing (talk) 17:05, 20 August 2014 (UTC)
It's definitely a problem. It's bad enough in an academic paper: when you cite more than one thing at once, it's not easy to tell what came from where. However, in such a context, you're typically instructed to be engaging in original research, interpreting what's said. In a context like Wikipedia, where we must say only what's in a source, there's almost never a good reason to cite more than one source for a specific sentence, and the exceptions are situations where we're discussing the sources themselves, e.g. "Alice and Bob say X"<ref>Alice's book</ref><ref>Bob's article</ref>. Whenever we're simply talking about the subject, a single source will pretty much always be sufficient, so in pretty much every situation of this sort, we can simply chop all the other sources, although of course we might have to examine the process of adding the sources in case there really is original research. That's why I'll cut additional sources; if one WP:RS for a statement says everything (especially online, so I can check it), I'll chop everything else, since there's already sufficient sourcing. That being said I don't think another template would help. Just use {{cleanup}} with a parameter saying something like "excessive citations for specific statements". Nyttend (talk) 02:23, 21 August 2014 (UTC)
I've frequently found use for multiple sources on a sentence simply for prosifying reasons. For a simple example, when source A says "X is true of T" and source B says "Y is true of T", so the article says "X and Y are true of T" in one sentence instead of two. Anomie 13:08, 21 August 2014 (UTC)

Wikipedia Adventure[edit]

Not sure where to post this. Could someone think up a way of stopping the invitation bot from inviting users who are indefinitely blocked from taking part in the Adventure? It seems to me a bit pointless, and also a bit of an insult too, as they can't take part. If and when they are unblocked, the bot could then invite them to participate. Peridon (talk) 13:54, 13 August 2014 (UTC)

Any bot that does it. I think it's HostBot. What happens is that a user offends a few times, then gets indeffed, then gets invited to the Adventure. They've usually been welcomed, and warned in varying degrees before the invite lands on the mat. But, without a fairy godmother, they can't go to the ball. Peridon (talk) 14:34, 13 August 2014 (UTC)
  • In the case of HostBot, I know that J-mo is aware of the issue and was working on it at one time. Not sure if that has fallen off his todo list or not, but I've pinged him here a couple times (and you are welcome to leave a TB on his talk page). — {{U|Technical 13}} (etc) 15:00, 13 August 2014 (UTC)
Yo! So, I am aware that this has occurred, and it's generally a case of replication lag with the logging table (which HostBot checks for blocks before inviting). I also parse the page text pre-invite for key words (like "block") before sending invites. But it's an imperfect system and a few will inevitably slip through the cracks. However, I'm not sure that this is a particularly pressing issue, because:
  • A) as far as I know, it's very rare. HostBot has been inviting 100+ editors to the Teahouse every day for over two years now. The process for checking for blocked/banned users before inviting is the same for TH invites as TWA invites. Errors like this are generally pointed out on my talkpage. I don't get them often--maybe once every 4-5 months or so.
  • B) HostBot hasn't sent any TWA invites out for almost three months (for unrelated reasons). The last time TWA invites were sent was May 19th. So, I'm guessing you were looking through stale, blocked userpages for other reasons, and happened upon an instance of this? Or, was it a more recent invite, from a human editor?
That said, I'm always looking to refine the process. Any real life examples you can link me to are appreciated and will help me hunt bugs. Cheers, - J-Mo Talk to Me Email Me 18:31, 14 August 2014 (UTC)

Commons admins with viewdelete[edit]

Some time back, there was a proposal to give Commons admins the right to view deleted content across all WMF wikis; I can't find it, or I'd link it. It gained broad support, but WMF vetoed it on technical grounds, as (if I remember rightly) it wasn't possible to get the software to grant rights to a user on one wiki just because the same user had been granted a different set of rights on another wiki. As far as I remember, WMF wasn't objecting to the idea; I got the impression that it would have been accepted had it been possible to implement.

With this in mind, I wonder what people would think about a request to developers for a new userright that admins here could grant: the right would be called "Commons admin", with just the ability to view deleted revisions of files (both the log entries from the history page, and the actual contents of text revisions and uploads), i.e. vaguely comparable to WP:Researcher in that viewing is the only additional ability, but more viewing ability than Researcher in filespace and no viewing ability in all other namespaces. Upon creation of this userright, we would grant it to any Commons admin who requested it, but under no circumstances would it be granted to anyone else, and (aside from gross abuse) the only reason for removing it would be that the user was no longer a Commons admin. As the biggest WMF project, we're probably the biggest source of images that get transwikied to Commons, so if creating this userright is practical, we'd be able to resolve a big portion of the difficulty that prompted the proposal. I understand that we currently don't have any admin-grantable userrights that involve deletion, basically because admin-type rights are typically granted only after a substantial community discussion, but this is different: we'd simply be allowing our admins to implement what our software would do if it were possible, and anyway people don't become admins at Commons without a substantial community discussion. Nyttend (talk) 14:58, 14 August 2014 (UTC)

  • As long as Foundation Legal is ok with it. (there are legal reasons why view deleted needs to be restricted to a limit number of people, but past discussions haven't given much guidance on how limited, a handful of commons admins who request it should probably be fine) I don't see any reason not to do it. That said, I've very rarely come across requests for that sort of info, do commons admins need it often? Monty845 16:00, 14 August 2014 (UTC)
  • I would personally not have any objections, on the other hand, I am a Commons admin, and I needed this right only a couple of times in my life. Those who transfer a lot of files or those who are superactive on FFD may need the right more often.--Ymblanter (talk) 16:53, 14 August 2014 (UTC)
    • Monty, I suspect that this wouldn't be a Legal concern, since Commons admins already have viewdeleted over there; my proposal, if successful, wouldn't expand the number of trusted users WMF-wide. Both of you address the "how many people" issue, so I've left an announcement at Commons:COM:AN — hopefully we'll hear from more Commons admins. Nyttend (talk) 19:23, 14 August 2014 (UTC)
  • Sounds like a good idea. Having done almost 170000 deletions and 1400 undeletions on Commons, there've been plenty of times when I could have used this to determine whether to restore/delete/DR an image, but instead had to wait for an admin to check a file and reply back with the needed info (except for the 6 months when I was an admin myself of course). There aren't many admins regularly involved in deletions/undeletions/DR/CSD at Commons, so the right would only likely be given to a small number of Commons admins. INeverCry 20:08, 14 August 2014 (UTC)
  • User:Jalexander knows a lot about what's possible with user rights as well as what's likely to wash with the legal team, so let's see if he's got any suggestions. Nyttend, how many years ago was "some time back"? Whatamidoing (WMF) (talk) 22:34, 14 August 2014 (UTC)
  • If I knew, I'd tell you; I'm sorry. I don't think I participated in the discussion; if I did participate, I've thoroughly forgotten. If I remember rightly, I first became aware of it upon reading that the technical staff had declared it impossible. Nyttend (talk) 22:37, 14 August 2014 (UTC)
Just a guess, but I wouldn't be entirely surprised if the technical problems were no longer so difficult. Whatamidoing (WMF) (talk) 02:17, 15 August 2014 (UTC)
Thanks, INeverCry, for finding that! Having seen that date, I was able to find Wikipedia:Wikipedia Signpost/2008-06-26/Global groups. I've checked every Signpost through the end of September without finding further coverage, so I'm guessing that they didn't cover what happened at the end of the poll. Nyttend (talk) 04:00, 15 August 2014 (UTC)
  • Support - English Wikipedia is just one part of the Wikimedia project; to the degree that we can help other parts of the project, we should. This proposal would cause little harm to us (presumably, any user capable of becoming a Commons admin should be trusted to merely view our deleted media and its descriptions), and significant benifit to the Commons, an other part of the project. עוד מישהו Od Mishehu 03:50, 15 August 2014 (UTC)
  • Seems reasonable. I am sure they don't let just anyone be a commons admin. Chillum 04:28, 15 August 2014 (UTC)
Well, they let me be an admin there...but, then again, they let me be an admin here for a while too... INeverCry 07:00, 15 August 2014 (UTC)
  • No opposition from my side, but how is a local group any different from a global group, from a technical point of view? Note that there is also some information at m:Global deleted image review. --Stefan2 (talk) 17:25, 17 August 2014 (UTC)
  • The commonadmin name is too confusing, as they won't be common nor an en-admin; could be fine, under "imagehistory" right, or the like. Those who want it and will use it should apply individually, like "reveiwer" right. Alanscottwalker (talk) 18:03, 17 August 2014 (UTC)
    I said "Commons admin", so your comments aren't quite accurate, although it was a vague suggestion and I expected someone to propose a different name. Perhaps "imagehistory" as you suggest, or perhaps something like "fileviewer"? Nyttend (talk) 13:47, 20 August 2014 (UTC)
  • Comment. This is a redundant proposal. This idea was proposed 6 years ago and was even approved in an RFC. Then a bug report was filed, which unfortunately has not been fixed yet. There are some related bugs that need to fixed before this feature can be implemented. Ruslik_Zero 19:42, 17 August 2014 (UTC)
  • Please re-read the proposal. I'm proposing a technical workaround for manual implementation of the 2008 proposal, since it can't be implemented automatically. I'm suggesting the creation of just a local userrights group, which shouldn't be too hard; during discussions related to Wikipedia:Requests for comment/Template editor user right (I can't find the precise spot), someone observed that creating the TE userright wouldn't be that difficult for the developers. Should all aspects of my proposal be implemented, we admins will be able to grant it just as easily as we grant rollback, although of course relevant policy will place much greater restrictions on who gets it; requests from "hat collectors" will automatically be declined. Nyttend (talk) 13:47, 20 August 2014 (UTC)
  • Umm, how does that work around the technical problems exactly? We'd still need to create a "viewdeletedfile" to add to the enwp group, and at that point we might as well just put it in a global group. Legoktm (talk) 17:37, 21 August 2014 (UTC)
  • Support either a local user right "viewdeletedfile" or similar, to be given to commons admins at their request. Or some other magic that allows them to view deleted files here. —Kusma (t·c) 13:34, 21 August 2014 (UTC)

RFC on SPI Clerk selection[edit]

Could use some opinions here [[2]] Hell in a Bucket (talk) 06:42, 17 August 2014 (UTC)

Bot to keep up to date lists of active and inactive members of WikiProjects[edit]

Members list of WikiProjects tend to grow steadily and are crippled with inactive members. The consequence is that when you add your name in the list, you don't really feel like you are getting involved in anything significant, because it means next to nothing to be in the list.

It is not a very rewarding job to clean these lists by hand but that's how it's done in many WikiProjects. Some tools such as Dispenser's can help but they are not very convenient when it comes to performing the edit itself: lines containing inactive users are simply commented out, which is not suitable if your members list is actually a table, or if you want to store inactive members in another list.

I propose to write a bot to do this task. Actually, most of the code is written. It can update the participants list of your WikiProject (but will not unless you request it for your own WikiProject). The update consists in moving inactive participants listed in the "active list" to the "inactive list" of your WikiProject. You can define what an "inactive participant" is. It supports both lists and tables.

For instance, it can mark participants as inactive when:

  • their last contribution to the English Wikipedia is older than some threshold (typically one year)
  • their last contribution to a page (or its talk page) falling in the scope of your WikiProject is too old
  • their last edit to a page inside the WikiProject itself is too old (discussions about the project itself, the portal, and so on)

You choose what is relevant for your project. It can also sort the two lists of members (active and inactive) by user name if it is told so. And it can move inactive users who are actually active again to the list of active users.

Would you find it useful? I can also propose this code as an external tool, but I think it would be simpler for everyone to run it as a bot. Your feature requests are welcome. If there is a consensus here, I will post a request for bot approval. − Pintoch (talk) 11:57, 17 August 2014 (UTC)

This would be very useful I think. These lists are now mostly cemeteries of former editors (or user names). Johnbod (talk) 12:02, 17 August 2014 (UTC)
  • I think if you supported a config script, like they have for archiving bots, and had the bot limit itself to the section in which the script is found, that would make it a lot more user-friendly. I also think it would be good to check for users that are blocked, in addition to simply inactive. VanIsaacWScont 19:48, 17 August 2014 (UTC)
Checking for blocked users might not be such a good idea as it looked at first. A significant number of blocks are for just hours or days, some of the longer ones are reversed and some are succesfully appealed. We'd have flurries of bot activity changing lists to and fro, and anyone looking to the lists for helpful editors might not realise that an editor listed as blocked could soon be back in action. Short-term blocks might come to be resented more if they were seen as damaging participation in projects. Maybe simply looking for inactivity would be enough. NebY (talk) 20:04, 17 August 2014 (UTC)
It's a good idea to use templates, I will do that. Concerning blocked users, it shouldn't be hard to implement, but I quite agree with NebY. Anyway, I don't think the bot has to do frequent changes to the lists. For most projects it should be fine if their members list is a few weeks old. Pintoch (talk) 20:16, 17 August 2014 (UTC)
I'd be happy to see this done. However, the participant lists involve a wide variety of locations and formats, so it's unlikely that whatever you create will work for all of them.
I'd start with the simplest case: no edits at all for at least one year. WhatamIdoing (talk) 15:16, 18 August 2014 (UTC)
Thanks for your support! The most difficult part is to handle the different formats of lists or tables indeed. Clearly, some formats won't be handled, but I believe for some projects it might be worth changing a bit their habits to get something automated. But I will not force them to do so, of course. Pintoch (talk) 16:00, 18 August 2014 (UTC)

information related to jahanian village in narowal district Pakistan[edit]

Jahanian is a small village located on the Narowal Zafarwal road at 18 kms from narowal and 7kms from zafarwal Near the town of dhamthal just 1 km from dhamthal. The total population is approximately 5000 and majority of the locality is Mayo Rajputs. There are also some other casts like araiyen, mian, maliks,insaris. 98 percent of the population is muslims and 2 percent Christians are there. The major source of income is farming and local government jobs

Additional information will be provided soon


Muhammad Ramzan Jani

Set index articles or disambiguation for placenames[edit]

Two systems are currently used for the disambiguation of placenames. Russian placename disambiguation follows the rules for Set index articles, the rest of the world uses disambuation pages with template:geodis. Since both systems have a history in their respective geographic locations, I suggest to keep the status quo for the time being. A guideline may also be useful. Inwind (talk) 19:37, 21 August 2014 (UTC)

Not sure what it is exactly you are proposing? Any set of entities of the same type by the same name can be compiled as a disambiguation page (unless the WP:DABRL guideline is in the way, but that's a whole other can of worms). A set index approach is only used when inclusion of additional metadata and references (otherwise prohibited by WP:MOSDAB) is deemed to add value and where there is a WikiProject willing to handle set index-specific maintenance. These conditions are met for ships, mountains, anthroponymic lists, chemical elements, and yes, Russian placenames, among other things. Any other WikiProject can come on board or jump overboard at any time; there really isn't anything in the guidelines to either encourage or discourage that, nor should there be, IMO.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); August 21, 2014; 19:57 (UTC)