Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Mdann52 (talk | contribs) at 08:17, 1 September 2014 (→‎RfC: Should Persondata template be removed from articles?: Close). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

New ideas and proposals are discussed here. Before submitting:


RfC: Should Persondata template be removed from articles?

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
At this time, there is no consensus to remove persondata, due to the uses of it for various tools. However, there does seem to be a consensus for revisiting this in the future, when most or all of it has been migrated to WikiData. --Mdann52talk to me! 08:17, 1 September 2014 (UTC)[reply]


Background (Persondata)

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.

Positives:

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

Discussion (Persondata)

  • 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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
    @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)[reply]
    @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)[reply]
  • 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)[reply]
  • 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)[reply]
    @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)[reply]
    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)
  •  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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
    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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
  •  Comment: separately maintaining {{Persondata}} is an anachronism with Wikidata existing. *If* the template is to be retained, then it should be auto-filled from WD. That said there is valid comment that there are many statements in existing person data that is not replicated to WD. So until the point that the data is transferred/merged, then we should be retaining the anachronism. Can we look to auto-fill the current template, and then find uses where we have data, but WD is bereft of that and migrate? — billinghurst sDrewth 01:32, 23 August 2014 (UTC)[reply]

Support (Persondata removal)

  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)[reply]
  2. Support as redundant, --Gerda Arendt (talk) 22:07, 20 July 2014 (UTC)[reply]
  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)[reply]
  4. Support per others. --AmaryllisGardener talk 03:27, 21 July 2014 (UTC)[reply]
  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)[reply]
  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)[reply]
    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)[reply]
  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)[reply]
  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)[reply]
  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 (Talk • Contributions • Log) 10:44, 21 July 2014 (UTC)[reply]
  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)[reply]
  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)[reply]
  12. Support, though make sure that the data we are removing already exists in Wikidata first. Cbrown1023 talk 17:45, 21 July 2014 (UTC)[reply]
  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)[reply]
    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)[reply]
  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)[reply]
    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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  20. Support - if data such as this is required, it can be maintained at wikidata. PhilKnight (talk) 13:45, 1 August 2014 (UTC)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  25. Support after cross-check and incorporation into Wikidata. Persondata is now obsolete and redundant. Renata (talk) 00:17, 7 August 2014 (UTC)[reply]
  26. Support this appears to be redundant and therefore unnecessary. Fraulein451 (talk) 16:05, 11 August 2014 (UTC)[reply]
  27. Support. An excellent and laudable project that is now superseded by Wikidata. Ironholds (talk) 10:43, 17 August 2014 (UTC)[reply]
  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)[reply]
  29. Support. It always was just more edit window clutter anyway. SpinningSpark 19:39, 22 August 2014 (UTC)[reply]
  30. Support. Persondata is a very rarely used feature whose purpose is now replaced by Wikidata. The reliability of Wikidata is as good if not better than persondata (as per Periglio's research) so the reason for its existence is now obsolete. Many of the oppose comments have supporting arguments that are perplexing or based on misunderstandings. The non-reader facing aspect of persondata has always made persondata something of an anomaly and I'll be glad to see it go. The tools that use persondata are few and should be easy enough to modify or block. It would be good if somebody were to run a project to import persondata missing from Wikidata and/or to repair inconsistencies between them but even if that's not done during a pre-removal period, I think removing persondata is a positive step forward. Usually change requires more pain that this will entail so this is a rather easy decision. Jason Quinn (talk) 11:51, 23 August 2014 (UTC)[reply]
  31. Support. When I first game here, back in 2009 (2010 was my year when I decided to remove Persondata). When I did it to numerous of articles on the English site, someone told me that it is used to collect dumps from other sites. However, I took a look at other language Wikis such as Russian, Ukrainian, etc, and found out that only {{Defaultsort}} is used! When I first saw Wikidata only couple of moths ago, when it was administered to remove interwikis I was amazed that such a small thing can do something as big as that! My main question however is how and when we will implement it, when we don't even have a template for it, or it will be another invisible tool? Either way, I never liked Persondata because it just adds 240 kb to a server which is already suffering few delays (depending on where you live).--Mishae (talk) 02:47, 1 September 2014 (UTC)[reply]

Oppose (Persondata removal)

  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)[reply]
    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)[reply]
    AFBorchert:
    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)[reply]
    @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)[reply]
    @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)[reply]
    @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)[reply]
    @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)[reply]
    @Superzoulou: Many biographic articles do not have infoboxes but Persondata (example). --AFBorchert (talk) 20:05, 21 July 2014 (UTC)[reply]
    @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)[reply]
    @AFBorchert: Agree with removal persondata from those that have infoboxes.--Mishae (talk) 03:00, 1 September 2014 (UTC)[reply]
  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)[reply]
    @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)[reply]
    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)[reply]
    @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)[reply]
    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)[reply]
    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)[reply]
  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)[reply]
    • How about nuking it as soon as Wikidata has it under control? bd2412 T 19:09, 21 July 2014 (UTC)[reply]
      • 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)[reply]
        • 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)[reply]
  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)[reply]
    • 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)[reply]
      • 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)[reply]
    • @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)[reply]
  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)[reply]
    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)[reply]
      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)[reply]
        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)[reply]
          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)[reply]
  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)[reply]
    @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)[reply]
    @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)[reply]
    @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)[reply]
    @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)[reply]
    @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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  12. Oppose because WikiData is totally unsourced. Most death date has not any references. Christian75 (talk) 18:34, 7 August 2014 (UTC)[reply]
    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)[reply]
  13. Oppose Premature. Alberto Fernández Fernández (talk) 19:01, 7 August 2014 (UTC)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  20. Oppose for the reasons given by AFBorchert, Magnus Manske and SMcCandlish. --Atlasowa (talk) 19:53, 22 August 2014 (UTC)[reply]
  21. Oppose On top of being premature, this seems completely unnecessary. I don't see why we shouldn't wait until WikiData is far more established first. Remove it in a couple of years. We don't need to do this right now. The only thing this will do is stress out the people who actually use it. Feedback ☎ 22:08, 25 August 2014 (UTC)[reply]
  22. Oppose - Not only is this premature and unnecessary, it is original research that reached a false conclusion. To state "It is currently not being used by anybody" is a complete misnomer and the parenthetical does not qualify a thing. I use the information myself. Yes it is hidden but I have found that when it is "out of sync with the article", it is, at times, a vandals handiwork that didn't get reverted. The mechanism to keep it in sync is called collaborative editing, and while it is somewhat redundant when an infobox is present, it is not superfluous because of its usefulness to expose the residue of a vandals hoax. The parameters do have a standard format as can be seen at Template:Persondata/doc#TemplateData, and the documentation can be improved by any editor who sees a deficient instruction.—John Cline (talk) 21:44, 26 August 2014 (UTC)[reply]
  23. Oppose at the present time. • Astynax talk 18:14, 27 August 2014 (UTC)[reply]
  24. Oppose at the present time per Magnus Manske. Apparently, Persondata is currently useful to extract data for Wikidata which isn't present there as yet, so removing Persondata now would seem premature and would mean a loss of useful metadata. Gestumblindi (talk) 23:14, 29 August 2014 (UTC)[reply]

Wikidata person import faulty

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

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)[reply]
Where did you report this issue? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:00, 17 August 2014 (UTC)[reply]
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)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. No further edits should be made to this discussion.


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

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

Survey

  • 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)[reply]
  • 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 (MSGJ—Xeno—Amalthea—TheDJ—Happy-melon—Topbanana—Grutness—WOSlinker) should do it. — {{U|Technical 13}} (e • t • c) 14:36, 1 August 2014 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]

Commons admins with viewdelete

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

  • 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)[reply]
  • 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)[reply]
    • 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)[reply]
  • 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 en.wiki admin to check a file and reply back with the needed info (except for the 6 months when I was an en.wiki 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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
  • Seems reasonable. I am sure they don't let just anyone be a commons admin. Chillum 04:28, 15 August 2014 (UTC)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • As I understand it, in 2008, the idea was as follows. Legoktm is an ordinary Commons user and Wikipedian without admin rights, so he can't see anything that's been deleted on any projects. He passes the Commons equivalent to RFA, and with a single click of the button by a Commons bureaucrat, he's able to view all deleted revisions in the file namespace of all WMF projects; here at en:wp, he can't delete or undelete anything, and he can't view deleted content in mainspace or portalspace, but he can view deleted revisions of files. Such an idea was rejected by WMF, and if I understand rightly, the idea was simply that it couldn't be done — the ru.wikibooks and ang.wikisource servers have no way to understand changes to your userrights on Commons. My proposal is basically a manual workaround, since a human can look at your Commons rights log and make relevant modifications to your rights on other wikis. I know absolutely nothing about global rights, so I can't make any solid comments. Are you basically suggesting that this be a steward-grantable thing, with the provision that when a steward hits a button on Meta, you immediately can view all deleted revisions in the file namespace of all WMF projects? If that's what you mean, I would say that it was even better than my proposal, but again I have no idea whether things work that way. Nyttend (talk) 02:01, 23 August 2014 (UTC)[reply]
  • 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)[reply]
  • Quid pro quo, if we do this, Commons should be willing to grant the same right to en admins at Commons on request. We sometimes need to investigate the disappearance of an image from a Wikipedia article, and that is made ten times more difficult if it was deleted on Commons. SpinningSpark 14:57, 23 August 2014 (UTC)[reply]
  • Granting the ability to view deleted files on a case by case basis to commons admins (or an editor here who just wants to work on file stuff, I guess) is a good idea. I'd prefer if we could set it up such that there's some input for the community, but I don't want to create another mini RfA process. Protonk (talk) 15:20, 27 August 2014 (UTC)[reply]

Break - possible existing solution

Would the reasearcher right already do the job? It allows you to view deleted pages and their histories? Should we just clone this right, and rename it something like "commonadmin"? --Mdann52talk to me! 15:54, 27 August 2014 (UTC)[reply]

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

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

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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
I think the usefulness of such a bot would be reduced if the criteria for marking members as "inactive" were not consistent between projects. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:15, 23 August 2014 (UTC)[reply]
Support I strongly support the creation of such a bot. There are a number of tasks I do which involve going to a Wikiproject I'm not familiar with (example, fielding an OTRS info request) Sometimes I post to the talk page, but I would prefer to make a request to an active member. That is often a tedious task. Restricting myself to a list of active members would be very helpful.
However, I do have a different view regarding the notion that the criteria need to be consistent. I'll illustrate with Wikipedia:WikiProject Basketball/Women's basketball (I do realize, with only 9 members, the bot is a bit of overkill). I would find it useful to know if any of the members become inactive, and I like the second option. I imagine that the list of participants would be changed to active participants, and the bot would move inactive down to a section, which could easily state "Inactive means the editor has not edited a basketball article in six months). If some other Wikiproject prefers a different criteria, they could state it at the top of the list of inactive members.--S Philbrick(Talk) 15:23, 23 August 2014 (UTC)[reply]
  • I could support this idea, but it needs to be done with some sensitivity. Members marked as inactive should not have their membership of the Wikiproject removed, for instance, they should remain in Wikiproject categories (but possibly a sub-category). The bot should automatically put them back in the active member list just as quickly once they start editing again. It should be on an opt-in basis, not foisted on Wikiprojects without discussion. SpinningSpark 14:52, 26 August 2014 (UTC)[reply]
  • The useractivity tool became an information table as it wasn't conveyed well in lists nor should ephemeral info be constantly saved. I spent some time restoring functionlity, it still badly hurt from labs migration (like Bug 68876). Additions I'd like to see in the future is their sub-specialty, best method of communication (e.g. IRC or wiki), and a user invitation system. — Dispenser 14:03, 27 August 2014 (UTC)[reply]

Remove the "Please donate now" banner

The banner is so annoying! I know that logged-in users can disable it using Special:preferences, but what about IP users? It is obvious that most people will just ignore it. If someone wants to donate to Wikipedia, they can still use the "Donate to Wikipedia" which appears at the sidebar.S/s/a/z-1/2 (talk) 03:02, 22 August 2014 (UTC)[reply]

I'm sure if you agreed to personally bankroll the entire necessary endowment to keep Wikipedia running, and were to do so with no strings attached, Wikipedia may not have to run the banner anymore. However, Wikipedia does still have bills to pay, and unless and until you'd like to pay all those bills, it seems unlikely that they are going to stop running the banner asking for people to pitch in and help. --Jayron32 03:45, 22 August 2014 (UTC)[reply]
What do you mean?S/s/a/z-1/2 (talk) 05:06, 22 August 2014 (UTC)[reply]
I mean, it costs money to pay electricity bills, rent, and pay employees to do necessary work for you. I'm unclear on what part of the world you live in where you would be unfamiliar with the concept of needing to spend money on utilities, rent, and equipment. You seem to object to Wikipedia asking for donations to pay those bills. I was suggesting that the fastest way to solve the problem was for you to agree to foot the bill yourself. --Jayron32 03:01, 23 August 2014 (UTC)[reply]
I said "If someone wants to donate to Wikipedia, they can still use the "Donate to Wikipedia" which appears at the sidebar.".S/s/a/z-1/2 (talk) 06:51, 23 August 2014 (UTC)[reply]
Yes, but it's also easy to miss. The banner catches people's attention, which you've proven. The fact that you are annoyed by it only proves that it is doing exactly what it is supposed to be, which is getting noticed. --Jayron32 19:56, 23 August 2014 (UTC)[reply]
I haven't spoken with anyone in fundraising for a while, but the last thing I heard was that IPs can click the button to suppress the banner for (I think) 30 days. It might still be cookie based. It shouldn't be appearing every day on every page, even for IPs (unless they're testing that particular setting at the moment). If you're seeing this all the time, please reply, and I'll go figure out who's handing fundraising tech bugs at the moment. Whatamidoing (WMF) (talk) 21:21, 22 August 2014 (UTC)[reply]
I see it every few days.S/s/a/z-1/2 (talk) 00:42, 23 August 2014 (UTC)[reply]
Do you use the same computer all the time, or are you seeing it on different computers? Whatamidoing (WMF) (talk) 00:55, 24 August 2014 (UTC)[reply]
This is a good question, as we often see people who switch computers or have a dynamic IP may see the banner more frequently than they should. It's also possible you live in one of the countries in which we have recently run a campaign, such as South Africa or Malaysia, during which banners show much more frequently. Regardless of the reason, I'm sorry to hear you have found the banners obtrusive, S/s/a/z-1/2! There are several options available to you to hide the fundraising banners in the future. If you click the X in the top right-hand corner of the banner, it will hide for two weeks. If you return to the 'Thank You' page, it may give the cookie a chance to reinsert: https://wikimediafoundation.org/wiki/Thank_You/en. We never show banners to logged-in users at this point, so logging in is the best and easiest way to avoid them. Thanks for the feedback! --CCogdill (WMF) (talk) 22:17, 26 August 2014 (UTC)[reply]

Bot to enable third-party copyright detection

A bot trial to generate a very limited sample set has begun, please see Wikipedia:Bots/Requests for approval/EranBot. This trial is to determine what the output type of operations will be to create a reference sample. However, additional discussion as to if the task should be performed at all, and if so under what conditions, may need additional discussion. Please see the bot request and feel free to add any questions for the operator, ערן. — xaosflux Talk 15:51, 22 August 2014 (UTC)[reply]

This is one of the initial tests of WP:TURNITIN (proposed), an Internet-based plagiarism-detection service run by iParadigms. The brief overview is that the bot will take edit content, submit it to the third party for scoring, and post a report here. Current examples are here User:EranBot/Copyright. Technically the trials are operating without any issues, however community consensus for this task is unclear, comments at the bot request, or here, are appreciated. — xaosflux Talk 11:00, 26 August 2014 (UTC)[reply]
The bot is only running on medical articles as the community supports it use their. Doc James (talk · contribs · email) (if I write on your page reply on mine) 12:08, 26 August 2014 (UTC)[reply]

Here we have consensus for this bot [2] from WP:MED. Doc James (talk · contribs · email) (if I write on your page reply on mine) 01:59, 27 August 2014 (UTC)[reply]

  • I've always thought Turnitin violates the copyrights of everyone whose work is added to its database. If Turnitin hashes, or whatever the technical method they use to add it to their database, that portion of the database should be made available under a compatible creative commons license. AFAIK, no one has every succeeded against them, but that doesn't change the fact they are taking our work, making profit off it, and not resharing or attributing. Monty845 23:00, 30 August 2014 (UTC)[reply]

WikiProject Rehab

Hey everyone. I'm look for a team of editors to help me get Wikiproject REHAB up and running again. I feel that we should give vandals a chance to turn over a new leaf if they agree to cooperate with the lessons. I need friendly, helpful, yet strict editors. Please help me help others. Thanks, Mirror Freak 17:52, 23 August 2014 (UTC)[reply]

I'm up for it. Feedback ☎ 22:00, 25 August 2014 (UTC)[reply]

Adding a link to "authors" in Wikipedia's by-line

Screenshot with the small proposed change to the page circled in magenta to make it easier to find.

An example of what this could look like is on the article on heart failure. If there is support for this proposal the word "authors" and link to the list of authors would go within the line of code that creates "From Wikipedia, the free encyclopedia".

When a person clicks on the word author it takes you to X! tool here [3]. Preferably the heading "top editors" would be changed to "authors" and that section would be moved up to below "general statistics". I am not sure what punctuation should be used and am open to suggestions / variations.Doc James (talk · contribs · email) (if I write on your page reply on mine) 23:15, 23 August 2014 (UTC)[reply]

Discussion (Adding author link)

There is a common misunderstanding regarding who writes Wikipedia. All we state now in the byline is that the text is "From Wikipedia". Adding the word authors and having this word link to a list of authors would increase transparency to our readership.

Another potential benefit is that making it clear that Wikipedia is written by people, people likely very much like the person reading the article in question. It may thus increase people's willingness to edit and this could be easily studied.

Yes I do realize that one can find this information other ways. One can click on the "history" tab. Than click on "revision history statistics" but that does not clearly lead people to whom the authors of the text are. The word history does not lead me to think of authors or editors. Doc James (talk · contribs · email) (if I write on your page reply on mine) 23:15, 23 August 2014 (UTC)[reply]

In the history page, we can customize everything on the page legend, it is stored in MediaWiki:Histlegend, changing the external link anchors is quickly done if that will help? — xaosflux Talk 23:25, 23 August 2014 (UTC)[reply]
The place one expects to see the authors listed; however, is in the byline. Doc James (talk · contribs · email) (if I write on your page reply on mine) 23:27, 23 August 2014 (UTC)[reply]
I don't really have a strong opinion on if this should be adopted, but if it is I'd suggest it's placement either be a page tab (perhaps incorporating Special:Cite), or else incorporated in to the tag line area From Wikipedia, the free encyclopedia. Having it floating up in the area you have it now seems out of place, especially when used in other display layouts such as mobile view. — xaosflux Talk 23:55, 23 August 2014 (UTC)[reply]

So by "would go within the line of code that creates "From Wikipedia, the free encyclopedia" i mean as you suggest "incorporated in to the tag line area From Wikipedia, the free encyclopedia". The example you see on heart failure is just a mockup of how it could look and only works for desktop and with vector. It was not a suggestion on how it would be programmed. Doc James (talk · contribs · email) (if I write on your page reply on mine) 00:14, 24 August 2014 (UTC)[reply]

I think it would look better there, perhaps along the lines of:
From Wikipedia, the free encylopedia (contributors)
Using PAGENAMEE, and making the external tools more prevalent on the top of the Cite tool? — xaosflux Talk 01:13, 24 August 2014 (UTC)[reply]
N.B. that is the MediaWiki:Tagline page. — xaosflux Talk 01:14, 24 August 2014 (UTC)[reply]
Yes I like the "contributors" in brackets. I still think going to the list of authors is best. We could than add the Special:Cite to that page. Doc James (talk · contribs · email) (if I write on your page reply on mine) 01:25, 24 August 2014 (UTC)[reply]
Changing the tagline is highly visible, to may even need an RFC to run for a bit; if that is where you want this to end up, you should start a section over in MediaWiki_talk:Tagline and link in from locations interested parties will visit (like here). Note, there are translations of that page in to many languages. — xaosflux Talk 01:38, 24 August 2014 (UTC)[reply]
Yes agree a RfC will likely be needed was just going to allow some initial discussion first. Only discussing this for English Wikipedia at this point in time. Have added a link here from meta. I guess we could consider broadening the discussion to all languages of Wikipedia thought. Doc James (talk · contribs · email) (if I write on your page reply on mine) 01:42, 24 August 2014 (UTC)[reply]
Oh no, I mean on enwiki we have additional versions of that page based on user language preferences, no big deal,just will need translators for each. — xaosflux Talk 01:52, 24 August 2014 (UTC)[reply]
Strongly opposed. It's a pathway to egotrippers and gloryhounds, a feature just begging to be gamed to increase their "rankings" on prominent or notorious articles. ("I'm the lead author on penis enlargement!") --Orange Mike | Talk 22:40, 25 August 2014 (UTC)[reply]
People who wish can do this already. Doc James (talk · contribs · email) (if I write on your page reply on mine) 00:17, 26 August 2014 (UTC)[reply]
  • Oppose because the history tab exists. --Jayron32 22:41, 25 August 2014 (UTC)[reply]
  • Strongly support because a) to the casual reader, there is no intuitive way to see who is responsible for the content and b) whether we like it or not, many people, especially those with knowledge of topics sorely lacking in Wikipedia, need to have some kind of credit. This is simply more in line with what is done in many of the publications we rely on.Thelmadatter (talk) 00:38, 26 August 2014 (UTC)[reply]
  • I dropped a few notes at mailarchive:wikimedia-l/2014-August/074133.html. --MZMcBride (talk) 01:54, 26 August 2014 (UTC)[reply]
    • If Willy on Wheels drops by and adds the word "scrotum" to a random article (assume it is not appropriate to the article), does he get counted as an "author" in this scenario? bd2412 T 04:16, 26 August 2014 (UTC)[reply]
      • If Wikipedia were to consistently hide (revdel or whatever the term is) vandalistic edits, would that have the side effect of ensuring the people who made them weren't listed as "authors"? -sche (talk) 04:26, 26 August 2014 (UTC)[reply]
          • For a brief period of time they would have been an author of the article. Doc James (talk · contribs · email) (if I write on your page reply on mine) 08:23, 26 August 2014 (UTC)[reply]
        • Yes that would likely work however it is sometimes useful to be able to see most vandalism. And it is more work to revdel.
        • We could use the term (contributors) instead of authors. Would potentially look like this [4] Doc James (talk · contribs · email) (if I write on your page reply on mine) 04:30, 26 August 2014 (UTC)[reply]
  • Oppose. Not because of the history tab - I'm actually a really big fan of increasing the prominence of the fact that did you know you can edit and this was made by people just like you because however much we assume we're good at that, we actually do a surprisingly poor job. But the current implementation seems likely to interfere with readership - we're directing people to a potentially-unstable labs tool that forces them to navigate away from Wikipedia and all of its links to other knowledge and other content. We are a project dedicated to knowledge and the interconnectedness of all things, and this setup sends users to a dead end. I'd be really supportive of, say, an experiment to gauge the impact of including a link that pointed at...I don't know. A quick summary of how WP is written by random joes and can be edited by you, too. But it would have to be an actual experiment. This looks likely to do unexpected things to readership that we can't currently track, and produce (potential) positive results we have no way of measuring. Generally-speaking I'd like UI changes to be both measurable and measured. Ironholds (talk) 06:41, 26 August 2014 (UTC)[reply]
We could put the list of authors / contributors within a Wikipedia page and thus not send someone to Wikimedia labs.
The whole point is Wikipedia is NOT written by random joes and this is a misconception that is spread not only by the media but many others. Our core community of medical editors is about half health care providers and 85% have at least a Bachelor. Doc James (talk · contribs · email) (if I write on your page reply on mine) 07:15, 26 August 2014 (UTC)[reply]
Okay. What advantage do we get from solving this, then? It seems to actively contradict the potential advantage you raise around editor engagement; I strongly doubt 85% of potential editors have bachelors, or that 50% are nurses or doctors. Ironholds (talk) 14:48, 26 August 2014 (UTC)[reply]
These are not the stats for potential editors. These are the states for the current core editors of Wikipedia's medical content. Do not understand you comment about "contradicting the potential advantage". Doc James (talk · contribs · email) (if I write on your page reply on mine) 22:07, 28 August 2014 (UTC)[reply]
  • Oppose per Orange Mike and the fact that we have a history tab... not to mention that I am not at all sure about where this would really link. Off wiki to some form of statistical data seems out of the ordinary to me.--Mark Miller (talk) 06:57, 26 August 2014 (UTC)[reply]
  • Comment Remember that most "authors" will not be identified by their real names as on a book cover or journal article, but only by usernames that are variously silly, enigmatic or unreadable and mean nothing except to Wikipedia regulars: Noyster (talk), 08:04, 26 August 2014 (UTC)[reply]
A number of the core members of WP:MED use their real names. Doc James (talk · contribs · email) (if I write on your page reply on mine) 08:15, 26 August 2014 (UTC)[reply]
  • -1. Wiki by definition means attributing my text as Wikipedia. Quoting Wiki:
"While a wiki is a type of content management system, it differs from a blog or most other such systems in that the content is created without any defined owner or leader, and wikis have little implicit structure, allowing structure to emerge according to the needs of the users."
WP:REUSE does allow to attribute by linking to the article. --Gryllida (talk) 12:30, 26 August 2014 (UTC)[reply]
  • -1. Oppose listing top editors only; WP:REUSE requires (as an alternative to linking to the article) listing them all with a "Any list of authors may be filtered to exclude very small or irrelevant contributions." comment; this, I understand, implies listing around 99% of the contributors. Every small contribution should count. --Gryllida (talk) 12:30, 26 August 2014 (UTC)[reply]
    • No one is being listed on Wikipedia. The proposal is to a link to another page that lists the authors. Doc James (talk · contribs · email) (if I write on your page reply on mine) 12:52, 26 August 2014 (UTC)[reply]
  • -1. Additionally, people would try to get onto the 'top editors' lists, count the amount of articles they 'co-authored'; this all has negative implications (see Karma). Every small contribution should count. --Gryllida (talk) 12:30, 26 August 2014 (UTC)[reply]
  • On a related note, if you'd like to raise awareness, just make the edit button bigger and put a reasonably well-visible "anyone can edit" line into the interface. Use the space wisely. That'd suffice. --Gryllida (talk) 12:30, 26 August 2014 (UTC)[reply]
  • If you go into it, please allow people to opt out. I'd not like to be, personally, subject to being listed in such author bylines selectively (i.e. only at those where I got into a top editors list). --Gryllida (talk) 12:33, 26 August 2014 (UTC)[reply]
    • We already have ways of determining who has edited an article. Opting out is not currently an option. We are NOT listing any authors by name in the by-line, we are only providing a link called authors or contributors. You can see it on the page heart failure Doc James (talk · contribs · email) (if I write on your page reply on mine) 12:52, 26 August 2014 (UTC)[reply]
  • Support This would be an excellent way of encouraging content contributions. Note that staff such as EpochFail are working on ways of improving attribution for our content and there is external research too; for example, see this paper, which states

    The Wikipedia Reuse Policy requires people reusing Wikipedia material to either provide a link to the original article and revision history, or to cite the most prominent authors of the content. Furthermore, in the Wikipedia community it is felt that proper content attribution is an important way to acknowledge and reward contributors, and to foster participation and contributions from communities where authorship has been traditionally recognized and rewarded, such as the academic community.

If these ideas are brought together then our contributors will get the credit that is their due and that the licencing requires. The history page is currently quite inadequate for this as its purpose is to show the detailed history of changes and so the authorship of our articles is obscured by this mass of fine detail. Andrew (talk) 12:38, 26 August 2014 (UTC)[reply]
Er. Well, people are working on research around editor engagement and attribution, but the paper you've cited doesn't seem to support that at all. Moreover you're not actually citing a part of the paper subject to experimental conditions, you're citing a background section, which is best understood as the author's impression of how Wikipedia works - and surely we're the people who get to decide how much that reflects reality? Paper citations aren't useful for that point. And just to clarify, if the history page didn't do what licensing required we'd have a far bigger problem. Ironholds (talk) 14:50, 26 August 2014 (UTC)[reply]
  • We do have significant attribution problems. For example, I was recently working on yacht delivery. There's a challenge to the copyright status of our text in that article but it's not clear whether the other site got it from us or vice versa. Or there's all those thousands of books produced by VDM Publishing. Ostensibly these were written by the prolific authors Frederic P. Miller, Agnes F. Vandome, &c. but the content is actually taken from Wikipedia and was written by our contributors. Why is "Frederic P. Miller" getting all the credit for our work? When our contributors get little acknowledgement and then see someone else taking the credit for their work, it's not surprising that they decline to do more. Andrew (talk) 15:57, 26 August 2014 (UTC)[reply]
  • Except first, this proposal wouldn't solve for the example you bring up, and second, none of the work on editor or edit decline has suggested a problem around lack of motivation in existing contributors. In fact, our strength is that the survival rate of existing contributors is incredibly high: it's attracting newcomers we fall down on. Ironholds (talk) 16:00, 26 August 2014 (UTC)[reply]
Yup and we plan to look at if this increases the attracting and retainment of newcomers.Doc James (talk · contribs · email) (if I write on your page reply on mine) 22:08, 28 August 2014 (UTC)[reply]
  • I could support something like this. I would call the link "credit" and I would link to just a list of the contributors. Alanscottwalker (talk) 13:31, 26 August 2014 (UTC)[reply]
Would be happy with that too. Doc James (talk · contribs · email) (if I write on your page reply on mine) 13:50, 26 August 2014 (UTC)[reply]
Well, viewing some of the additional comments below, I think I should expand on what I mean by list of contributors. It would include the owners of the image files, as well as the writers. Now, perhaps this does not all need to be done at once but that is what I would like to see. Alanscottwalker (talk) 14:45, 26 August 2014 (UTC)[reply]
Yup if this idea received support should be easy to do. Doc James (talk · contribs · email) (if I write on your page reply on mine) 22:04, 26 August 2014 (UTC)[reply]
  • Support not authors, but contributors for transparency sake (and likely to improve licensing compliant reuse). Identifying the removers of text is fine as they do contribute to the appearance of the article; in another category altogether, identifying vandals is fine, as they should be identified. It should be expanded to image contributors but the perfect should not be the enemy of the good (transparency). Alanscottwalker (talk) 11:18, 31 August 2014 (UTC)[reply]
  • Support – Wikipedia is loosing productive editors at an alarming rate. Anything that can help motivate participation is a good idea and giving credit where credit is due is an effective way of accomplishing this. While there are other ways of determining contribution, this is the most direct way I have seen. Boghog (talk) 14:06, 26 August 2014 (UTC)[reply]
  • Support as "contributors" - Makes what is already available in two clicks (Page information -> Contributors) available in one click instead, and makes that link more visible. As this information is already available and all this proposal is doing is making the access to it easier, I don't understand the arguments that this will somehow be dangerous or encourage glory-hounds, at least not any more than what the normal page presentation already does. Would be very happy to see this deployed in a trial run on selected WP:MED articles, for example, and see what the feedback is, or see whether the contributor profile of those articles changes (RCT anyone)? Zad68 14:33, 26 August 2014 (UTC)[reply]
  • Concerned Wouldn't this give credit not only to contributors of lasting content but also to contributors of large-scale copyright violations, essays, rants and protracted edit-wars? How would, for example, Audit Commission (United Kingdom) appear? X!'s tool shows one editor has made 41% of the edits and 70% of the text additions by bytes, but doesn't show they have all been reverted. NebY (talk) 15:15, 26 August 2014 (UTC)[reply]
  • So should we oppose this proposal until the edit count is not obviously unsatisfactory? NebY (talk) 16:32, 26 August 2014 (UTC)[reply]
  • We could right now without to much difficult remove the two edits involved in a revert from the numbers. Please keep in mind that if everything on Wikipedia had to be perfect before it goes lives we would obviously not have Wikipedia.
  • By the way the tool lists contributors by both number of edits and by bytes contributed. Doc James (talk · contribs · email) (if I write on your page reply on mine) 22:06, 26 August 2014 (UTC)[reply]
  • Would such edits be removed automatically, and would this include cases such as my example above of Audit Commission (United Kingdom)? If so, would this be done using an existing solution or is it something that should be feasible but has not yet been accomplished? We've been shown a research paper from 2013 but no progress report.
  • By the way, as you'll see from the way I presented the example, I do realise the tool lists contributors in two ways. I do also realise that we can't wait for perfect solutions, but I was startled that a supporter of the proposal would still describe the existing count as "obviously unsatisfactory". I hope you don't think it obstructive to consider potential problems and discuss overcoming them. NebY (talk) 14:42, 27 August 2014 (UTC)[reply]
Yes thanks. While it is not perfect this it is simply a single word in the byline. I would imagine it would result in improvements in our analysis of who has edited an article.Doc James (talk · contribs · email) (if I write on your page reply on mine) 05:24, 28 August 2014 (UTC)[reply]
  • Support - clarification on this and a link to the authors would benefit the reader. QuackGuru (talk) 03:16, 27 August 2014 (UTC)[reply]
  • Support Small unobtrusive link that provides "byline" type info. I think this would be useful to those checking to see which editors are most involved in developing an article. Also useful for general attribution. I think this is consistent with what is found in reliable sources. - - MrBill3 (talk) 06:02, 27 August 2014 (UTC)[reply]
  • Support. It adds to transparency. Most casual readers wouldn't know where to find the main authors of an article. --Anthonyhcole (talk · contribs · email) 09:28, 27 August 2014 (UTC)[reply]
  • Support - While far from perfect, I'd actually like to see this added or enacted as an option on the left column, perhaps in the tools section. Gathering details of the page's history from the "view history" section seems a bit silly for attribution and while this tool is not perfect it still represents an improvement. ChrisGualtieri (talk) 12:59, 27 August 2014 (UTC)[reply]
  • Oppose. We have 'history' and other tools for those who need to know this info—the average reader does not. There is no benefit to the average reader knowing who contributed to an article using a pseudonym. And, by-lines are for newspapers. Edit counts are worthless as an edit can introduce incorrect information, be poorly written, vandalism, or just plain bad. The encyclopedia is a community project, not individually driven, and the focus should remain as a collective work, not a personal one. GenQuest "Talk to Me" 13:23, 27 August 2014 (UTC)[reply]
  • Support This might be fun! Also, open source projects often list contributors in a similar manner. It's harder to do when contributions aren't subject to some central authority for acceptance, but it's not without precedent. Protonk (talk) 15:06, 27 August 2014 (UTC)[reply]
  • Oppose per GenQuest. (1) It may be that many contributors to medical articles use their real names as usernames, but the proposal appears to apply to articles on any topic. (2) I can't imagine an automated tool that could reliably make the qualitative judgement on the value of every edit in an article's history: Noyster (talk), 15:48, 27 August 2014 (UTC)[reply]
We could just introduce this on medical articles if this is a concern for the wider community. Our authors are as you mention more transparent and our lack of transparency is criticism I have to deal with when I speak about Wikipedia and medicine. Doc James (talk · contribs · email) (if I write on your page reply on mine) 05:27, 28 August 2014 (UTC)[reply]
Then yes, that sounds like you're trying to generalise specific criticism you have heard voiced (around the primacy of attribution in a medical context, so patients/readers can understand who is providing information) to the project as a whole. How much was this proposal driven by those (very subject-specific) concerns? Ironholds (talk) 07:21, 28 August 2014 (UTC)[reply]
I believe that this is an important move for medical articles. I have no strong feelings regarding the rest of Wikipedia (but lean towards it being a good idea). We could apply it only to medical articles and then present something in 6 or 12 months on the effects it had (we do have fairly good data on editor numbers and could study the effects on a random selection of articles versus a group of controls). Doc James (talk · contribs · email) (if I write on your page reply on mine) 07:47, 28 August 2014 (UTC)[reply]
  • Support per Zad 68's point. Also, a fairly new change to the mobile version is that it now displays the name of the most recent editor. I think that should occur on the desktop site as well. Increasing transparency of Wikipedia's authorship is key to its legitimacy. --Holdek (talk) 17:23, 27 August 2014 (UTC)[reply]
  • Oppose authority from names was tried on Google's Knol and it failed, people who really want to know it will open the edit history anyway for clues or visit the talkpage where the editor names are well visible. Mion (talk) 18:14, 27 August 2014 (UTC)[reply]
This is not about authority from names. This is about transparency to our readership. Doc James (talk · contribs · email) (if I write on your page reply on mine) 05:13, 28 August 2014 (UTC)[reply]
Right, because pseudonymous nicknames and arcane IP addresses are transparent. --Jayron32 13:43, 28 August 2014 (UTC)[reply]
Not all of use use IP addresses and nicknames. Doc James (talk · contribs · email) (if I write on your page reply on mine) 22:04, 28 August 2014 (UTC)[reply]
Mark Twain is a pseudonym.Thelmadatter (talk) 15:29, 29 August 2014 (UTC)[reply]
Excellent point. We are not unique in allowing their use. Doc James (talk · contribs · email) (if I write on your page reply on mine) 19:54, 29 August 2014 (UTC)[reply]
  • Comment - If I were a major contributor to an article that I researched, wrote and continued to refine by hand and then suddenly an editor with automated functions "moves" up to a "by line" level...I would be more than a little concerned and annoyed. That would discourage further input and contributions from editors not using tools to edit.--Mark Miller (talk) 20:55, 27 August 2014 (UTC)[reply]
Please note the suggest is NOT to add anyone user name to the "by line". It never has been. The suggestion is just to add a link to "contributors". See example at the top. The data is given both by bytes contributed and number of edits. Thus if you contributed most of the text you would still be linked higher. There is NO moving up to a byline level. Doc James (talk · contribs · email) (if I write on your page reply on mine) 05:13, 28 August 2014 (UTC)[reply]
I can not support ANYTHING which used number of edits as a measure of excellence, per my comments above. And number of bytes is no better as a measurement, per the same criteria. For instance, some of us actually improve the encyclopedia by removing many, many bytes of badly written prose, comments, narratives, editorializing....etc.; the list is almost endless. Both proposed parameters are pretty much meaningless in the encyclopedia, and wholly not tenable as a measure of article improvement for the reasons I stated. And I have to ask, just what is gained by allowing the average reader, here for information only, to have an instant link to (for example) the list of the last five "contributors" (or prolific serial vandals who have targeted the article)? If Wikipedia were trying to be a primary informational source, I would understand and support this; however, Wikipedia is a tertiary information source—we report what others have written—we just do it in our own words. Authorship is meaningless here (except for those that would revel in their article / edit / byte counts). Given the stated purpose of Wikipedia, this proposal makes no sense. GenQuest "Talk to Me" 14:45, 28 August 2014 (UTC)[reply]
They may not be perfect but they are far from meaningless. These are not measures of excellence but measures of contributions. Many of our articles are far from excellent and still have contributors / authors. It also gives the time line for contributions.
Yes agree that improvement often involves removing large amounts of poorly written text. When article are brought to GA / FA the major contributors are usually listed among the first few editors (at least for all medical articles I have looked at).
Are authors / editors / contributors meaningless? After having dealt with a fair bit of COI I would say that is not the case. The people who write the content are exceedingly important. Doc James (talk · contribs · email) (if I write on your page reply on mine) 22:03, 28 August 2014 (UTC)[reply]
Strong Support (of the "wtf didn't we do this year's ago?" type). It is just so sensible! Over the years I've been involved with WP you wouldn't believe how often readers / press don't understand where the content comes from or what the history tab signifies. There has been a continuous problem with proper attribution of our content for so long and this is a simple and neat way to do something about that. (btw, on my browser, the text on the test page overlaps with other text) --AlisonW (talk) 23:24, 29 August 2014 (UTC)[reply]

Strong support I delete a lot of text, and I am not entitled to copyright for that, so I won't rank highly for number of bytes (nor edit count) Yet I am delighted that those who do contribute prose and images will get clear credit from this. A 'Contributors' link has plenty of meaning and value to anyone who reads the written word (as does the analogous 'credits' when we enjoy TV, movies and podcasts), and even more meaning to those who actually contribute. It will never be perfect. If we copy and paste a sentence from another Wikipedia article, or from another free source with a compatible license, that won't be automatically attributed. Neither will text from the 1911 Encyclopaedia Britannica. (For those reasons, I think the current proposal of 'Contributors' is far better than the original 'Authors'.) Yet despite some small weaknesses, which I are largely fixable later, this is a fantastic idea that is far more digestible than the remote possibility that a reader follows 'More/View history' and realizes that tells them not only what was written, but by whom. Is this really the first time in our history that this has been proposed? By the way, the edit count tools have been around for 6 or 7 years, so I don't consider them to be experimental or unstable. Hroðulf (or Hrothulf) (Talk) 16:20, 30 August 2014 (UTC)[reply]

Watchlists and transclusions

I have a suggestion for a bot. The issue it is meant to address is as follows. I have transcluded the lead of an article B into another article A using Wikipedia:Transclusion#Partial_transclusion. But changes to the lead of B do not show up as changes in the watchlist for article A. There seems to be no way to get around this, to alert people of the changes, short of keeping B in the watchlist as well.

I have an idea for reflecting transclusions. Each time the lead changes on article B, a bot adds a whitespace in the odd iteration, (or removes the whitespace in an even iteration) in article A with the edit summary mentioning the diff. Assuming there are not too many transclusions, and that the transcluded section is not changed too many times, this should not be too much of a problem. Any suggestions on whether this is a good idea? If so, I would be interested in writing such a bot myself, though I don't have any experience in such things. Kingsindian (talk) 07:46, 26 August 2014 (UTC)[reply]

Silent looping autoplay video

Animated GIF really sucks. Everyone knows it. It has limited colour depth and inefficient encoding, meaning large file sizes. Surely it can't be the future of a media-rich internet?

What do you think of the idea of allowing silent autoplay looping WebM/Theora video, as a replacement for animated GIF? An example use case would be File:Lunar libration with phase Oct 2007 450px.gif which is currently on Moon.

Implementation details: some special parameter on the File: link would activate the feature, maybe [[File:Foo.ogv | autoloop]]. If a sound stream is present in the file, it would automatically be stripped in server-side transcoding. -- Tim Starling (talk) 08:33, 26 August 2014 (UTC)[reply]

I like the stripping of the audio channel. I wonder about browser (and mobile device) compatibility, how many people would see "broken plugin" or something like that? Anomie⚔ 10:18, 26 August 2014 (UTC)[reply]
Judging by commons:Commons:Media help, IE and Safari (iOS and OSX) users would be in trouble, but everyone else would be fine. -- Tim Starling (talk) 16:37, 26 August 2014 (UTC)[reply]
people who voluntarily use IE have personal issues beyond the scope of Wikipedia to fix... --Jayron32 19:21, 26 August 2014 (UTC)[reply]
Maybe we could transcode from WebM/Theora to GIF as a fallback for IE, iOS etc. -- Tim Starling (talk) 20:42, 26 August 2014 (UTC)[reply]

If nobody cares (excepting people on my team) then I don't think I will do it or push for it. Plenty of other things to work on. -- Tim Starling (talk) 00:16, 1 September 2014 (UTC)[reply]

I find the looping videos very annoying. We need a way to set the default to "not playing" so that people need to click the image to turn it on. Doc James (talk · contribs · email) (if I write on your page reply on mine) 00:39, 1 September 2014 (UTC)[reply]
You're saying that all animated GIFs should be treated in this way? -- Tim Starling (talk) 01:35, 1 September 2014 (UTC)[reply]
All animated GIFs on a page can be stopped by pressing a key (although Firefox now needs SuperStop for that). After admiring a looping autoplay video, how could it (or all of them) be stopped? Johnuniq (talk) 02:23, 1 September 2014 (UTC)[reply]

Government parameter in Template:Infobox country and Template:Infobox former country

Further information: Template talk:Infobox country § Edit request 27 August 2014

Moved the discussion. — Preceding unsigned comment added by Trust Is All You Need (talk • contribs) 20:04, 27 August 2014 (UTC)[reply]

OTRS members

Following a misunderstanding on my part about an editor modifying an {{OTRS permission}} template on a file page, I propose that a new user group be created for OTRS members similar to the one on Commons so that such editors can be clearly identified. Personally I've grown used to hovering my mouse pointer over an editor's name and seeing a pop-up box that contains basic details including the user groups that editor is a member of. In this instance I saw only the word "rollbacker" and forgetting to check the actual userpage, I asked a question at the OTRS noticeboard about whether the license for a particular file was correct because it had been added by someone I thought wasn't an OTRS member. I'm sure I'm not alone in having this bad habit of using pop-ups rather than clicking on a page and checking it more thoroughly, but it occurs to me that we should have a separate user group for these editors because they are a trusted group and they have access to classified information. If it avoids another embarrassing episode on my part, I think it will be worthwhile to have this group. Green Giant (talk) 14:26, 30 August 2014 (UTC)[reply]

I was actually drafting a proposal at the same time. The full draft is at this page, but a summary is as follows: Create an "otrs-userright" on enwiki as well, that applies "autoreview" (same as what reviewers have to mark edits to pages under PC as reviewed. Then, create an edit summary to pick up any addition of {{permissionOTRS}} or {{ConfirmationOTRS}} by users not in the groups (like this one). This would both help with the issue that Green Giant mentioned, and reduce the number of false taggings that happen. --Mdann52talk to me! 18:15, 30 August 2014 (UTC)[reply]
In that case I defer to Mdann52's superior knowledge and am willing to wait for the RfC to be published. Green Giant (talk) 21:59, 30 August 2014 (UTC)[reply]
I agree that we need to open an RFC for this. Whenever it is read. Cheers, TLSuda (talk) 01:57, 31 August 2014 (UTC)[reply]

New user status level/new protection level

Is there any way that a semblance of common sense could be applied to the current designations of user status, and, relatedly, to how article protection is done?

Currently we have "autoconfirmed users". To be "autoconfirmed" on English Wikipedia you have to have been registered for 4 days and made at least 10 edits [5]. Ten freakin' edits. How long does it take you to make ten edits? I can make ten edits in under five seconds (I am 100% certain that most users can beat that time easily). I really really hope that this is some archaic throwback to the early days of Wikipedia, like 2002, when very few people edited the encyclopedia, and did so rarely, so back then this low threshold made some sense. Otherwise it's just some supreme nonsense. We are not in 2002 anymore and this requirement is completely superfluous.

So here's proposal #1, the Minimal proposal: Drop the "10 edits" requirement from what it takes to be autoconfirmed. This is just common sense which shouldn't even have to be explained and doing so will have no real effect on editors what so ever. It's just recognizing that... it's not 2002 anymore.

But obviously, having an edit requirement is actually a good thing, which is why this now-ridiculous threshold of 10 edits was put in there in the first place. It's just that now, the threshold should be much higher. And in fact, other language Wikipedias do set a much higher level (usually these are the ones with some kind of flagged revisions). So how about getting realistic and setting the auto-confirmed standard at at least 300 hundred edits. Even that is ridiculously low. If it takes me less than 5 seconds to make 10 edits, it will take me less than two minutes to make 300 edits. Any person who wishes to cause trouble around these parts has only to exert minimal effort to meet that (proposed, higher) standard. Really, the threshold should be at 1000 or more edits. But I understand there's institutional inertia here and all that, so... baby steps.

Second, under the generous assumption that it's recognized that the current system of "autoconfirmed users" is just plain idiotic, we need to revisit article protection. Right now we have either semi-protection or full-protection. These are about the two worst options that could be implemented.

Under semi-protection, disruptive users just have to wait four days, go to effort of making ten edits, and then they're free to go. Of course, somewhat smarter disruptive users, will start an account, make ten edits and then just let it sit there for a year or two, then utilize them again when the real edit warring/disruptive activity needs to be done. Anyone who's been involved in content writing or even content supervision knows very well that this is a very common phenomenon (throw away sleeper accounts) across the encyclopedia. Hence, semi-protection doesn't do crap. It's really "nothing".

At the other extreme we have full-protection. Here, only admins are allowed to edit articles, and any proposed changes by non-admins need to be floated on the talk page first. Under ideal circumstances this would work IF: 1) admins who full-protect pages actually bothered to keep track of these pages and, again relateldy, 2) the admin corps was skilled in content-related edits. We can AGF the first part, but it's clear as day that most admins do not become admins because they are familiar with content editing. There's actually nothing wrong with that. Different people have different skills, some people are good at writing content and others are good at administrative work. The problem is that "full protection" forces the people who are mainly good at administrative work to engage in the content work which they are completely not suited for. So mostly... they don't do it.

The end result of this - the combination of the fact that troll-ish new accounts can easily bypass the joke that is "semi-protection" and the frustration with being unable to edit a page which is "fully-protected" by non-admin but established users is that serious editors are leaving Wikipedia. More and more, which is something we're all aware of.

What we need is an intermediate level of protection and a new level of status, which is higher than the presently silly "autoconfirmed" user one, but not "admin".

So here is proposal #2: establish a status which requires 1 year on Wikipedia, 1000 edits and a minimum threshold of these in article space. Establish a protection level which allows these users but not the "I made 10 edits four days ago, now I get to vandalize Wikipedia articles all I want" ones edit.

 Volunteer Marek  00:47, 31 August 2014 (UTC)[reply]

  • I think what you are talking about is fundamentally a "vested contributor" status. While I don't really have a fully fleshed out opinion on this proposal, the one unintended consequence I think this may overlook is that, right now, full protection is actually quite rare an occurrence, and tends to get withdrawn very quickly, largely because it is so onerous for admins to maintain. The low bar to autoconfirmed status means that by default, en.wikipedia is about as strikingly close to the ideal of "the encyclopedia anyone can edit" as can be done feasibly. I think that any conversation about implementing a new "highly protected" status would need to address the possibility of disturbing that equilibrium that so effectively encourages open editing on en.wikipedia in practice as well as in theory. VanIsaacWScont 02:07, 31 August 2014 (UTC)[reply]
Thanks for the input. A couple of points.
First, overall, given that Wikipedia has more than 4.5 million articles I'm sure that full protection is indeed rare. However, if we limit the scope to critical, or highly viewed, or controversial articles - or some combination of these - the situation is different. On these, it's frequent enough to be a hindrance or at least an annoyance.
Second, you're also right in that full protection tends to get withdrawn very quickly. But that's a symptom of its dysfunctionality rather than a perk. Basically what happens is that an important article suffers disruption, it gets fully protected, serious editors then cannot edit the article and get extremely annoyed so then they bug and harangue the admin who fully protected it, so then after some back and forth (and some potential and unnecessary drama, even AN/I discussions) it gets lifted. The fact that full protection is "quickly withdrawn" is evidence of the fact that it sucks and that it doesn't work. Not a testament to its viability.
And you're also right about the third issue - the lowbar to autoconfirmed status does mean that pretty much "anyone can edit". Ok, having admitted that, we can go two ways. One: if it doesn't mean anything why even bother with it? Why even have "autoconfirmed status"? If we really want "everyone to edit" why bother with the hypocrisy of this label and why even semi-protect articles? (A more honest approach would be to simply ban unregistered IPs from editing certain articles). Two: despite the high falutin' rhetoric, we actually DON'T want "anyone" to edit the encyclopedia. We ban people all the time. We waste tremendous amounts of time reverting vandalism. And disruptive edits. And sock puppets of banned users. And sock puppets of vandals. And sock puppets of banned vandals. Etc. We obviously WANT a certain threshold of edit quality to exist and if somebody cannot meet that they're not part of that "anyone" that can edit. That "ideal" that you mention is a "founding myth" which was actually never true in the first place (even back in 2002 they blocked people). It's time we grow up and admit to ourselves that certain standards are necessary (we even have essays, like WP:COMPETENCE or WP:NOTHERE) which pretty much say it).
Finally, and this is in some ways fundamental, the problem is that this is NOT an "equilibrium". An "equilibrium" implies a state of stasis, a constant, a situation which can be expected to persist for the foreseeable future. This isn't it. We're loosing editors, and what's worse, we're loosing *quality* editors. And a lot of that has to do with the issues outlined above. I'd elaborate on this point but we'd be getting off topic. What we have now is an *outcome*, not an *equilibrium*. A bad outcome too, and more importantly an unsustainable one.
 Volunteer Marek  03:42, 31 August 2014 (UTC)[reply]
@Volunteer Marek: would something like pending changes level 2 work, if the bar to the userright was raised to reflect the new level required by such edits? Alternatively, we could create something like TemplateEditor, and use it on protected pages more (like it seems to be on a few pages now). --Mdann52talk to me! 07:04, 31 August 2014 (UTC)[reply]
@Mdann52: That would definitely be a step in the right direction, although if it were up to me I'd move that green box one more square to the right (I'm not clear on why Reviewers wouldn't be allowed to edit - presumably because this Template Editors would be a newly created category?). Those charts actually make my point very nicely - there's semi protection and then there's full protection, and then there is this huuuuggggeee area in the middle. Right now we have a "it really has no effect" policy and we have a "it has a devastating effect policy". Common sense should tell you that we need a bit more... nuance. Very very rough kind of nuance. Volunteer Marek  07:56, 31 August 2014 (UTC)[reply]
template editor is a reletively new right, that was created for this very reason (a lot of non-admins were better at editing templates than admins). If you can get support for introducing, lets say a "protected editor" user right (to allow fulfilling edit requests and making uncontraversial changes on full-protected pages), then it should be fulfulled with little complaint on the dev side of things. --Mdann52talk to me! 08:45, 31 August 2014 (UTC)[reply]
Though I don't feel like supporting the main proposal, I think spinning out the edit full protected right from the admin package is something worth looking into. Obviously such users would have to act as admins in that situation, i.e. not make controversial changes or any significant ones without talk page consensus; also, a policy about granting the right would be needed, say, answering x semi-protected edit requests correctly, demonstrating respect for consensus. Perhaps make this a separate proposal, Mdann52? BethNaught (talk) 10:39, 31 August 2014 (UTC)[reply]
@BethNaught: I'm currently working on another similar proposal (#OTRS members above), but will get round to this once that one is RfC'd and in progress. --Mdann52talk to me! 17:49, 31 August 2014 (UTC)[reply]
  • A valuable proposal. This could lead to a desirable simplification of the user rights system: we could create a general "trusted editor" status, amalgamating:
  • rollbacker
  • reviewer (i.e. can approve or reject pending changes)
  • autoreviewer (i.e. own new pages not patrolled)
  • can edit semi-protected pages
  • more controversially - can delete pages.
The pending-changes system would then be abolished as identical in effect with semi-protection.
Approval for the trusted-editor right would be by (1) a certain number of edits, (2) a certain time since account opened, (3) in-depth examination of editor's record by an admin (two admins?); and the right could be withdrawn by any admin with reasons given to the editor: Noyster (talk), 10:00, 31 August 2014 (UTC)[reply]
@Noyster: are you proposing we get rid of the reviewer/rollback usergroups, or have another one that incorperates the rest of them? FYI, the request to delete pages will not be added to the group by the foundation dev's, because the ability to see deleted content requires a RfA-like process, so I feel that there is little chance of the last point being implimented sucsessfully... --Mdann52talk to me! 17:49, 31 August 2014 (UTC)[reply]
I actually really like this proposal in concert with a "high protection" level; it both simplifies the current cadre of advanced user rights (reviewer? rollbacker? autoreviewed?) and provides a means of relaxing the overkill of many long-term fully protected pages. As to your concern about viewing deleted material, Mdann, I guess the fundamental question here is whether there is a reason why the ability to delete pages needs to be bundled with the ability to view deleted content. If these were, in fact, decoupled from each other, what would be the obstacles, both technical and practical? As far as I can see, the biggest hassle would be the creation of Criteria for Speedy Undeletion to complement the current WP:CSD, perhaps as a subsection of that policy, for cases when material is accidentally deleted by someone who is unable to undelete (undeletion is fundamentally an ability to view deleted content). It would also introduce a small deletionist bias in the system, so it would need a pretty extensive review process. I certainly think it's an idea worth exploring in more depth. VanIsaacWScont 21:28, 31 August 2014 (UTC)[reply]
@Vanisaac: I believe (I may be wrong) that they are bundled together on the MediaWiki side of things. I'll look into it. --Mdann52talk to me! 06:02, 1 September 2014 (UTC)[reply]

Regarding the trusted-editor right, a similar user right was proposed in April 2013 and did not gain consensus. SiBr4 (talk) 20:26, 31 August 2014 (UTC)[reply]

Adding non-economical ranks to the table at the top of country articles

I'm perhaps a bit of idealist, but find it odd that only economical ranks (GDP, Gini) or ranks based mostly on economic performance (HDI) are shown at the {{Infobox country}} table. I suggest adding information about state of democracy, state of freedom of speech and level of corruption the the table, right below the GDP, HDI and Gini ranks. These give a much wider view to the society than just economical.

Especially prosperous East Asian countries seem to be like Western countries based on the table and the introduction part in the article, but they have significantly lower political freedoms than their Western counterparts and are often more corrupt. The table in the article Singapore according to my proposion would look like this: [6] Giving the three ranks of Democracy Index, Press Freedom Index and Corruption Perceptions Index would help understanding the Singaporean exceptionalism, where the 3rd highest GDP and the 5th best rank in the Corruption Index is combined with an authoritarian regime, the Press Freedom being lower than in Russia. /á(!) 00:48, 1 September 2014 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=623681863"