Wikidata:Requests for comment/Verifiability and living persons
An editor has requested the community to provide input on "Verifiability and living persons" via the Requests for comment (RFC) process. This is the discussion page regarding the issue.
If you have an opinion regarding this issue, feel free to comment below. Thank you! |
THIS RFC IS CLOSED. Please do NOT vote nor add comments.
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- no changes to current practice --Pasleim (talk) 08:34, 20 August 2016 (UTC)[reply]
Contents
Background
editWe are fundamentally a centralized repository for information for all the different Wikimedia projects that anyone can edit. But as with Wikipedia, this creates problems with the reliability of our information - how do we know that a modification of a piece of data changes it from right to wrong, or vice versa? Much of the information here currently lacks references. For some easily-derived data, this isn't a problem (such as Commons category and other project-internal information). But to ensure the quality of our database as a whole, we need to ensure that consumers of our data can verify the correctness of our information. Help:Sources currently mentions sourcing of information, but does not specify what sources are acceptable, nor any special implications for living people. There currently exists a Wikidata:Verifiability page, but it does not address all the issues here.
This has two important implications.
This is a foundation-level principle.[1] It is of utmost importance that the information we store about living people be verifiable. But we need to define what "verifiable" means in the context of our project. This was a concern brought up in the English Wikipedia RfC on using phase 2 of Wikidata,[2] and almost surely has been such an issue elsewhere as well.
Point 2 has been the subject of dispute because it relies on the currently ill-defined notion of verifiability.
It is impossible to enumerate every type of information we can store. However, a general agreement is needed. Indicate below whether you support or oppose it. These would replace the existing "Verifiability in practice" section at Wikidata:Verifiability.
General guideline
editInformation on Wikidata must be verifiable - reasonable consumers of our data should be convinced that it is correct.
With the following exceptions, all information (particularly claims) must have at least one reliable source. The exceptions are:
- Project-internal information such as template-related data and project pages
- The exceptions at Help:Sources#When to source a statement, except that the first of those does not apply to information regarding living people
- Anything that can be derived from already-referenced information by simple mathematical calculations, such that any reasonable consumer of the data could immediately verify them
The referencing of material should be done as currently described by Wikidata:Verifiability and Help:Sources.
Votes 2.1
edit- Support - though I would suggest the two additional exceptions here (and any further ones, for example specific properties as in the item just below) should just be added to Help:Sources#When_to_source_a_statement. ArthurPSmith (talk) 18:44, 27 June 2016 (UTC)[reply]
- Support This is needed. Jianhui67 talk★contribs 12:08, 28 June 2016 (UTC)[reply]
- Support This is needed, je suis d'accord. --Droit de retrait 03 (talk) 14:39, 2 July 2016 (UTC)[reply]
Supportif and only if the property-specific proposal passes. I suspect it may be difficult to source some things - gender comes to mind. --Rschen7754 04:22, 3 July 2016 (UTC)[reply]- Changing to Neutral due to the concerns raised by Pigsonthewing. I doubt people would remove data en masse, but I suspect that it would lead to wikilawyering. --Rschen7754 00:25, 8 July 2016 (UTC)[reply]
Support--GZWDer (talk) 10:48, 3 July 2016 (UTC)Opposeprefer Pigsonthewing's idea.--GZWDer (talk) 09:49, 7 July 2016 (UTC)[reply]- Support — Revi 13:01, 5 July 2016 (UTC)[reply]
- Support I want contributors to Wikimedia projects, including Wikidata and Wikipedias, to be aware that content should to be verified. "Verifiability" has never been enough for me - I want actual verification and for contributors to feel obligated to try hard to provide references for all content added to all projects. At the same time, I am in the short term (2-5+ years) willing to tolerate unverified claims. Everyone has to tolerate this, because at this point the priority in Wikimedia projects is ease of contribution and not increasing quality. I will not say that preparing for a future without references is a good thing. Claims without references should be solicited with less enthusiasm as compared to claims with references.
- Even though I support having a rule that content must have references, I oppose the enforcement of this rule for the next few years. If casual users add content without verification, then they should be thanked and asked to consider providing references. As users get more engaged, and as the community evaluates larger projects, then the need to demand compliance to verification needs increases. For any new large scale well-funded projects, having references should be required.
- Personally, I am comfortable having rules which say one thing and community practices which permit other things. For now it is enough for me if people come to learn the rule and what is expected, and at some later time, 2-5 years from now, I would support stronger enforcement. As Andy describes, I would not like to see near-future mass removal of data following the passing of this rule. I would like to see contributors increasing encouraged to provide verification. Blue Rasberry (talk) 15:56, 7 July 2016 (UTC)[reply]
- Oppose The condition should be "should" not "must". And if this passes, we would see a mass removal good data, just because a source has not yet been added. We should instead devise an equivalent of Wikipedia's 'Citation needed' tag. We should not be making "Help" pages part of policy. Furthermore, external IDs are generally self-citing. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:21, 7 July 2016 (UTC)[reply]
- Oppose See above .. GerardM (talk) 09:46, 7 July 2016 (UTC)[reply]
- Oppose MisterSynergy (talk) 09:58, 7 July 2016 (UTC)[reply]
- Oppose as per Pigsonthewing. --Magnus Manske (talk) 10:07, 7 July 2016 (UTC)[reply]
- Oppose ChristianKl (talk) 10:25, 7 July 2016 (UTC)[reply]
- Oppose As long as on Wikipedia sourcing information about living people isn't mandatory, why should we be better than Wikipedia? Verifiability is important, but no added source doesn't mean data isn't verifiable. Just that the source of the data isn't clear. Agree with Pigsonthewing that a Wikidata form of Citation Needed should exist and it should be possible to add it to data, but making sourcing mandatory is a step too far. And if we want to make it mandatory then only for data added/edited after a the date the policy becomes active. If we don't do that, we are losing a lot of data because it's possibly incorrect. Mbch331 (talk) 10:31, 7 July 2016 (UTC)[reply]
- Oppose as Pigsonthewing writes. I think Wikidata is doing a great job encouraging sourcing of statements already and has great tools to support this. Egon Willighagen (talk) 10:39, 7 July 2016 (UTC)[reply]
- Oppose as per Pigsonthewing. --Freedatum (talk) 10:52, 7 July 2016 (UTC)[reply]
- Oppose completely agree with Pigsonthewing, GerardM, others... and - a Citation needed equivalent, rather than imposing. - No force removal of info without sourcing should be allowed brutally. --Hsarrazin (talk) 11:57, 7 July 2016 (UTC)[reply]
- Oppose Per Andy's --Discasto (talk) 14:02, 7 July 2016 (UTC)[reply]
- Oppose must language, where is the project team to provide the references that should be there? mass deletion of unreferenced statements is profoundly harmful to the project.Arcituno (talk) 14:13, 7 July 2016 (UTC)[reply]
- Oppose Per Andy's--Kippelboy (talk) 15:40, 7 July 2016 (UTC)[reply]
- Oppose I don't believe we are anywhere near a proper policy on this yet. Perhaps the first step in the right direction has been the "segregation" of identifiers. One doesn't sensibly require verification of an identifier statement, one asks that it (the identification) is carried out properly. For an image statement, one can see a similar issue. Starting at the other end, I would say that unverified dates of birth/death, and unverified statements of family relationships, are two areas that should raise red flags. These are massive things to source; and they are well worth sourcing. But there is a clear need to do such biographical cleanup sensibly. Which is a small corner of the general issue. Charles Matthews (talk) 16:33, 7 July 2016 (UTC)[reply]
- Oppose I totally support the idea in theory, but we just don't have the tools to do this yet. You can't even easily add references by hand, much less update deadlinks and so forth. It would be ridiculous to make this a policy unless you also say there will be no sanctions for ignoring the policy until we have the tools. Intention is one thing, tooling is another. Also, as many others have pointed out, many statements are self-referencing (such as images or authority control properties) which would mean an overkill of references. Jane023 (talk) 18:14, 7 July 2016 (UTC)[reply]
- Oppose Pigsonthewing's approach looks better. Having query engine now, we can design tools to watch unsourced statements and work with them, instead of just deleting good info which isn't yet soruced. --Laboramus (talk) 22:03, 7 July 2016 (UTC)[reply]
- Oppose as per Pigsonthewing. --Geraki (talk) 04:26, 8 July 2016 (UTC)[reply]
- Oppose Agree on the constructive approach using "citation needed" equivalent -- as well as encouraging the implementation of current user scripts that can enable pathways between Wikipedia citations and Wikidata citations. Mission critical that the perspective here is to improve existing data and not delete data. Wikidata as a semantic backbone and/or dataset of Wikipedia can provide citations but the technical side is still being made user-friendly. Destructive / deletionist approach is not helpful or needed for Wikidata -- Erika aka BrillLyle (talk) 05:59, 8 July 2016 (UTC)[reply]
- Oppose Per Andy's Evpok (talk) 09:17, 8 July 2016 (UTC)[reply]
- Oppose per Pigsonthewing and BrillLyle. While the issue is an important one and the proposal well-intentioned, a pre-moderation strategy (prevent/remove edits whose source is missing or hasn't been reviewed) would effectively stop Wikidata's growth. There are several initiatives underway to design strategies (including algorithmic ones) that will help us identify and recommend suitable sources for unreferenced statements after the fact. --DarTar (talk) 15:13, 9 July 2016 (UTC)[reply]
- Oppose Per Andy and BrillLyle. We must make sourcing easier and encourage it, but 'should' not 'must' is consistent with our principles. - PKM (talk) 17:55, 9 July 2016 (UTC)[reply]
- Oppose Verifiability is very important concept, but at the moment Wikidata are still not prepared for strict rule like this. Proper referencing (not only adding P854) is still overcomplicated and user unfriendly. Also we have lot of self-referencing properties. Strict enforcement of proposed rule may lead to massive loss of data. --Jklamo (talk) 12:05, 12 July 2016 (UTC)[reply]
Discussion 2.1
editAndy makes a couple of points I thought would be useful to address. First - on making "Help" pages policy; I'm not sure what the standards ought to be here, but I certainly don't mind having all the exceptions listed on some other page; as I suggested in my vote I think the rules for sourcing should be together in one place wherever that is. Second - I was assuming this would be a policy applied only going forward, so new data added should meet sourcing standards. I do not support removal of unsourced data in wikidata just because it lacks a source, and if that is what is really being proposed here then I am also opposed to this change. I do agree a "citation needed" flag attachable to any unsourced statement would be helpful. Note that the Help page mentioned does exclude external id's from the sourcing requirements. ArthurPSmith (talk) 14:09, 7 July 2016 (UTC)[reply]
- "exceptions listed on some other page" may be the right solution , but the "Help:" namespace is not. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:21, 7 July 2016 (UTC)[reply]
- How will the project will benefit of a citation needed function? My experience is that people will not pay attention to them and the information will be deleted anyways after a amount of time. Sjoerd de Bruin (talk) 15:06, 7 July 2016 (UTC)[reply]
What does this "must" mean? That the claim is deleted if there is no reference? Or that a nice wikidata user makes an automated list of claims missing references? I suppose with living people there are issues with privacy and the like, e.g., linkage to criminal behavior. residence (P551), phone number (P1329), religion or worldview (P140), ethnic group (P172) and convicted of (P1399) would be the problematic properties as I see it. Perhaps there are more: I have seen occupation (P106) used to linked to types of crime. — Finn Årup Nielsen (fnielsen) (talk) 14:47, 7 July 2016 (UTC)[reply]
I don't agree with the phrasing of this: "Information on Wikidata must be verifiable - reasonable consumers of our data should be convinced that it is correct." A statement might have a reference that is a book or newspaper, not online, so perhaps most consumers of that data may not be personally able to verify it. Nevertheless the statement is verifiable and should remain unless the reference is found to be bogus, or better sources indicate the statement is wrong. Jc3s5h (talk) 16:01, 13 August 2016 (UTC)[reply]
Property-specific
editThe general guideline can be overridden for claims using a particular property if after a thorough (i.e. not too short) discussion at Wikidata:Project chat, there is consensus for doing so for that property in a particular fashion.
Votes 2.2
edit- Support - that's effectively what we're doing with external id's. Also I wonder if some properties should be more forcefully required to have sources: eg. family relationship properties, or relations with corporations or government positions etc. In particular to prevent the "it is well known" loophole. ArthurPSmith (talk) 18:48, 27 June 2016 (UTC)[reply]
- Support Jianhui67 talk★contribs 12:08, 28 June 2016 (UTC)[reply]
- Support --Rschen7754 04:22, 3 July 2016 (UTC)[reply]
- Support--GZWDer (talk) 10:50, 3 July 2016 (UTC)[reply]
- Support — Revi 13:01, 5 July 2016 (UTC)[reply]
- Oppose as written - the wording is too vague. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:24, 7 July 2016 (UTC)[reply]
- Oppose Wikidata is not mature enough. Destroying our content as a matter of principle is not a good idea. Thanks, GerardM (talk) 09:47, 7 July 2016 (UTC)[reply]
- Oppose as per Pigsonthewing. --Magnus Manske (talk) 10:07, 7 July 2016 (UTC)[reply]
- Oppose per GerardM/Pigonthewing. Mbch331 (talk) 10:33, 7 July 2016 (UTC)[reply]
- Oppose particulary agreeing with GerardM: Wikidata is doing a great job aggregating data, but to succeed we must have a critical amount of data. A lot of data now comes from the various localized Wikipedia, which is a great source, but the source is not copied along. That is not a bad thing, and this RFC would make that a bad thing. Egon Willighagen (talk) 10:41, 7 July 2016 (UTC)[reply]
- Oppose as per Pigsonthewing. --Freedatum (talk) 10:54, 7 July 2016 (UTC)[reply]
- Oppose as per Pigsonthewing. --Hsarrazin (talk) 11:59, 7 July 2016 (UTC)[reply]
- Oppose as per Pigsonthewing --Kippelboy (talk) 15:41, 7 July 2016 (UTC)[reply]
- Oppose for the same reason as the first one -- we have only just started to classify properties and have a considerable ways to go with that project. Once done we shouldn't need a policy about referencing them because they are self-referencing by definition. Jane023 (talk) 19:05, 7 July 2016 (UTC)[reply]
- Oppose as per Pigsonthewing. --Geraki (talk) 04:27, 8 July 2016 (UTC)[reply]
- Oppose This seems very unclear and seems to have over-arching implications that might be damaging and inhibit communication. Yes, discuss on Discussion tab of particular page -- but to push it to Project chat, that seems extremely unhelpful. -- Erika aka BrillLyle (talk) 06:12, 8 July 2016 (UTC)[reply]
- Oppose Per Andy's Evpok (talk) 09:23, 8 July 2016 (UTC)[reply]
- Oppose as per above. - PKM (talk) 17:57, 9 July 2016 (UTC)[reply]
- Oppose More than proposed "whitelist" concept I will prefer "blacklist" concept for some sensitive properties like P91, P140 or P172. Also Project chat is not a good place for discussion, talkpage of property is better place. --Jklamo (talk) 12:21, 12 July 2016 (UTC)[reply]
Discussion 2.2
editWhy should the discussion not happen on the project page of the property? It's difficult for someone who uses a property to know about every discussion that happens in the project chat. ChristianKl (talk) 10:35, 7 July 2016 (UTC)[reply]
The text as written there becomes our policy.
Votes 3.1
edit- Weak support I think it needs some review, but generally it's good. I have some questions about the meaning of the "database" discussion there for instance - I'll add some comments in discussion below. ArthurPSmith (talk) 18:51, 27 June 2016 (UTC)[reply]
- Support Jianhui67 talk★contribs 12:08, 28 June 2016 (UTC)[reply]
Support--GZWDer (talk) 10:50, 3 July 2016 (UTC)[reply]- Support — Revi 13:01, 5 July 2016 (UTC)[reply]
- Oppose The text referred to is too vague to be a policy. Also, we should not be marking individual sections of larger pages as "policy". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:26, 7 July 2016 (UTC)[reply]
- I believe the idea was to make the entire page Wikidata:Verifiability a policy. Maybe we should focus on improving that page first. ArthurPSmith (talk) 14:49, 8 July 2016 (UTC)[reply]
- The proposal at hand refers explicitly to a single section. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:45, 9 July 2016 (UTC)[reply]
- I believe the idea was to make the entire page Wikidata:Verifiability a policy. Maybe we should focus on improving that page first. ArthurPSmith (talk) 14:49, 8 July 2016 (UTC)[reply]
- Oppose GerardM (talk) 09:48, 7 July 2016 (UTC)[reply]
- Oppose Magnus Manske (talk) 10:09, 7 July 2016 (UTC)[reply]
- Oppose ChristianKl (talk) 10:28, 7 July 2016 (UTC)[reply]
- Oppose per Pigsonthewing above and his statement in the discussion below. Mbch331 (talk) 10:38, 7 July 2016 (UTC)[reply]
- Oppose Wikipedia is not a "reliable source" yet there are excellent curation teams (e.g. the Wikipedia Chemistry Project) and the data is generally of high quality. The current proposal is not suitable for Wikidata. Egon Willighagen (talk) 10:50, 7 July 2016 (UTC)[reply]
- Oppose --Freedatum (talk) 11:00, 7 July 2016 (UTC)[reply]
- Oppose Nothing about primary or secondary sources. No a good policy. Snipre (talk) 11:53, 7 July 2016 (UTC)[reply]
- Oppose too vague --Hsarrazin (talk) 12:02, 7 July 2016 (UTC)[reply]
- Oppose Nope --Kippelboy (talk) 15:41, 7 July 2016 (UTC)[reply]
- Oppose external id's can also be conflicting - the Wikidata policy is to include all known points of view. Jane023 (talk) 19:07, 7 July 2016 (UTC)[reply]
- Oppose as per Pigsonthewing. --Geraki (talk) 04:27, 8 July 2016 (UTC)[reply]
- Oppose Authoritative sources is a misnomer as far as I am concerned. Also, more importantly, Authority Control, which is what underlies the concept here, is a massive, important issue. This statement is too vague and should reflect a more in-depth and coherent explanation and include existing industry standards. This is re-inventing the wheel in terms of Identifiers -- again, mission critical function to Wikidata -- and therefore makes me extremely nervous, so oppose on the basis of that alone. -- Erika aka BrillLyle (talk) 06:20, 8 July 2016 (UTC)[reply]
- Oppose Per Andy's Evpok (talk) 09:23, 8 July 2016 (UTC)[reply]
- Oppose - PKM (talk) 17:58, 9 July 2016 (UTC)[reply]
Discussion 3.1
editOn the statement regarding databases - I thought in general with wikimedia we prefer secondary or even tertiary (newspaper report etc) sources to primary (journal article) sources. Journal articles would usually be where some piece of academic information originated, but they need to be given some time to be reviewed and assessed by the relevant academic community before they could be considered supported in a largely consensus view. So I think reliable government-supported or major-academic-institution-supported public databases should be a preferred source for our use. ArthurPSmith (talk) 18:53, 27 June 2016 (UTC)[reply]
This policy seems to say that Wikipedia itself is no authoritative source. As a lot of the statements on Wikidata have currently one of the Wikipedia's as a source. Is the suggestion that this practice should be stopped and current content that's sourced that way should be deleted? ChristianKl (talk) 12:20, 5 July 2016 (UTC)[reply]
- Wikipedia is not because it's a self-published source; if the information is indeed verifiable, Wikipedia requires a source for it, and the idea is to use those sources directly here.--Jasper Deng (talk) 23:24, 5 July 2016 (UTC)[reply]
- Wikipedia doesn't have a requirement that every fact must have a source, the way it's proposed in this RfC. This would make Wikidata much more strict than Wikipedia. ChristianKl (talk) 10:27, 7 July 2016 (UTC)[reply]
@Pigsonthewing: I see no point to define what are reliable sources strictly. See w:Wikipedia:Perennial_proposals#Define_reliable_sources.--GZWDer (talk) 10:03, 7 July 2016 (UTC)[reply]
- Neither do I; hence it's not what I suggested. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:12, 7 July 2016 (UTC)[reply]
Blocks
editThe repeated addition of unverifiable information (such as "John Doe is the world's lamest man") can result in a block of the offending user.
Votes 4.1
edit- Weak support - this seems a little draconian but maybe needed. I think you ought to give a more thorough set of examples to be clear where problems are. "John Doe owns a house" is pretty neutral in tone, does it need a source? What about "John Doe's telephone # is ...." (which is maybe another reason we shouldn't consider phone #'s to be external identifiers) - or "John Doe's geo location is ..."? ArthurPSmith (talk) 19:00, 27 June 2016 (UTC)[reply]
- Support BLP violation should not be taken lightly I guess. Jianhui67 talk★contribs 12:08, 28 June 2016 (UTC)[reply]
- Note that while the example given (and mine) is BLP the description covers all non-verifiable information, not just on living people. ArthurPSmith (talk) 14:57, 28 June 2016 (UTC)[reply]
- Support --Droit de retrait 03 (talk) 15:02, 2 July 2016 (UTC)[reply]
- The same for users wo use to publish private informations about living people, by extrapolations and personal research. In this field, we have : familial informations (John Doe is the father of - coming from a social network), love life (John Doe haves sex with Suzie - coming from paparazzi), sexual life (John Doe is gay - said by junk website), revelation of adress'home (John Doe lives at this place, coming from annuaire), etc. Wikidata is not a tabloid. No violation of the private life. (sorry for the bad level of EFL) --Droit de retrait 03 (talk) 15:02, 2 July 2016 (UTC)[reply]
- Support--GZWDer (talk) 10:50, 3 July 2016 (UTC)[reply]
- Support — Revi 13:01, 5 July 2016 (UTC)[reply]
- Oppose as written - too vague and too widely applicable. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:28, 7 July 2016 (UTC)[reply]
- Oppose We are not in the business of blocking. We are in the business of aggregating data and find proper procedures to verify not vilify. Thanks, GerardM (talk) 09:50, 7 July 2016 (UTC)[reply]
- Oppose Vague, and probably done already, for obvious vandalism. --Magnus Manske (talk) 10:09, 7 July 2016 (UTC)[reply]
- Oppose as per Pigsonthewing/GerardM/Magnus Manske. Mbch331 (talk) 10:42, 7 July 2016 (UTC)[reply]
- Oppose Too unclear. Bots that source other databases would be OK (actually, this whole RFC is unclear and does not explain if something like "reference URL" is a sufficient sourcing of a statement), but expert editors would not be, correcting false information. The current proposal puts power in the wrong place. Egon Willighagen (talk) 10:52, 7 July 2016 (UTC)[reply]
- Oppose as per Pigsonthewing/GerardM/Magnus Manske. --Freedatum (talk) 10:55, 7 July 2016 (UTC)[reply]
- Oppose, per Magnus Manske/GerardM/Pigsonthewing --Hsarrazin (talk) 12:06, 7 July 2016 (UTC)[reply]
- Oppose --Kippelboy (talk) 15:42, 7 July 2016 (UTC)[reply]
- Oppose this one is really overkill at this point. Blocking policy for this is just silly at this early stage. Jane023 (talk) 19:08, 7 July 2016 (UTC)[reply]
- Oppose I don't think just adding unsourced info should be a reason to block. Adding wrong unsourced info - i.e. vandalism - could be, but there are already policies against that. --Laboramus (talk) 22:06, 7 July 2016 (UTC)[reply]
- Oppose as per Pigsonthewing. --Geraki (talk) 04:27, 8 July 2016 (UTC)[reply]
- Oppose Existing policy on Wikidata:Vandalism is active guideline so this is unnecessary. -- Erika aka BrillLyle (talk) 06:27, 8 July 2016 (UTC)[reply]
- Oppose Per Erika's Evpok (talk) 09:23, 8 July 2016 (UTC)[reply]
- Oppose I don't see why this is not covered already. — Finn Årup Nielsen (fnielsen) (talk) 11:37, 11 July 2016 (UTC)[reply]
Discussion 4.1
editI think it would make sense to have a process whereby a person who adds unverified information get's warned by a message on his talk page that he's engaging in behavior that could lead to a ban before he get's banned. ChristianKl (talk) 12:12, 5 July 2016 (UTC)[reply]
- Issuing warnings when necessary is part of the discretion admins are expected to exercise, based on the principle that we take the least drastic action needed to resolve a given situation.--Jasper Deng (talk) 23:23, 5 July 2016 (UTC)[reply]
- What do you think will be the change to the status quo if this item passes? ChristianKl (talk) 10:29, 7 July 2016 (UTC)[reply]
The example is not good. "John Doe is the world's lamest man" would be regarded as plain vandalism and handled as such. Is there a better example? — Finn Årup Nielsen (fnielsen) (talk) 14:38, 7 July 2016 (UTC)[reply]
- Yes, I don't really have any objections to this, but it seems unnecessary to me because it seems to already be covered by the "hoaxing" section of Wikidata:Vandalism. - Nikki (talk) 19:12, 7 July 2016 (UTC)[reply]
Page protection
editA page subject to the repeated addition of unverifiable information by multiple users may be protected.
Votes 4.2
edit- Support ArthurPSmith (talk) 19:00, 27 June 2016 (UTC)[reply]
- Support Needed obviously. Jianhui67 talk★contribs 12:08, 28 June 2016 (UTC)[reply]
- Support--GZWDer (talk) 10:50, 3 July 2016 (UTC)[reply]
- Support — Revi 13:01, 5 July 2016 (UTC)[reply]
- Oppose Too vague. What level of protection? For how long? under what circumstances can a request for unprotection be made? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:29, 7 July 2016 (UTC)[reply]
- Oppose as per Pigsonthewing. --Magnus Manske (talk) 10:10, 7 July 2016 (UTC)[reply]
- Oppose as per Pigsonthewing. And what if someone wants to add verifiable data? Do they need to post it on the talk page and hope a user that can still edit sees it and adds the information? Or wait till protection ends? And what about indef protections? No more adding information then ever? Mbch331 (talk) 10:44, 7 July 2016 (UTC)[reply]
- Oppose as above, and a proposal that does not scale well. Who will decide to mark a page as protected? Egon Willighagen (talk) 10:54, 7 July 2016 (UTC)[reply]
- Oppose --Freedatum (talk) 11:00, 7 July 2016 (UTC)[reply]
- Oppose as phrased. Too vague ! protection could be applied, but conditions must be more strict, to avoid complete blocking. --Hsarrazin (talk) 12:08, 7 July 2016 (UTC)[reply]
- Oppose --Kippelboy (talk) 15:42, 7 July 2016 (UTC)[reply]
- Oppose opposing for consistency Jane023 (talk) 19:14, 7 July 2016 (UTC)[reply]
- Oppose as per Pigsonthewing. --Geraki (talk) 04:28, 8 July 2016 (UTC)[reply]
- Oppose Existing policy on Wikidata:Page protection policy is active guideline so this is unnecessary. -- Erika aka BrillLyle (talk) 06:27, 8 July 2016 (UTC)[reply]
- Oppose Per Erika's Evpok (talk) 09:23, 8 July 2016 (UTC)[reply]
Discussion 4.2
editDo we have examples where questionable information has been added? I have run into two vandalism: [1] and [2], but apart from that I do not recall questionable edits. Maybe I do not edit "sensible"/"hot" items enough. I just examined the basketball player. I see Special:Contributions/187.147.178.103 doing a some damage. — Finn Årup Nielsen (fnielsen) (talk) 14:59, 7 July 2016 (UTC)[reply]
- Take a look on the history of these items. Sjoerd de Bruin (talk) 15:10, 7 July 2016 (UTC)[reply]
- I find it troubling that several items have been semi-indefinitely protected since 2014. In the case of Liancourt Rocks (Q20317) for example, this seems to have happened after a single problematic pair of edits, which may have been a test as much as anything else, by an IP that made no other edits, ever. The justification was "Excessive vandalism". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:31, 7 July 2016 (UTC)[reply]
- The indefinite protections are indeed a problem. Every thing is based on common sense now, rather than policies. It seems like some sysops protect a item or page based on the experience they have on other projects. I removed the protection on that item, will check others later. Sjoerd de Bruin (talk) 16:44, 7 July 2016 (UTC)[reply]
- yeah, when an english RfC is referenced, that is a tell. some people bring their ethos from other projects here. when you see all the effort in this proposal about blocks, what is this proposal but an excuse to block people. will you then block bot edits on behalf of blocked people? if they cannot adapt to the community here, then why are they admins? Arcituno (talk) 19:16, 7 July 2016 (UTC)[reply]
- The indefinite protections are indeed a problem. Every thing is based on common sense now, rather than policies. It seems like some sysops protect a item or page based on the experience they have on other projects. I removed the protection on that item, will check others later. Sjoerd de Bruin (talk) 16:44, 7 July 2016 (UTC)[reply]
- I find it troubling that several items have been semi-indefinitely protected since 2014. In the case of Liancourt Rocks (Q20317) for example, this seems to have happened after a single problematic pair of edits, which may have been a test as much as anything else, by an IP that made no other edits, ever. The justification was "Excessive vandalism". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:31, 7 July 2016 (UTC)[reply]
Like the section above, I don't have any objections to this but it seems to already be covered by Wikidata:Vandalism. I'm not aware of the current practice for page protection being particularly problematic (out of the approximately 19 million items, we have fewer than 100 protected items... the indefinite ones should be reviewed but overall I don't currently see a reason to be concerned). If we do need clarifications for whatever reason, that would seem more appropriate on Wikidata:Page protection policy rather than here. - Nikki (talk) 19:46, 7 July 2016 (UTC)[reply]
General principle
editAll information about living people must especially be verified well, and any unverifiable information, particularly if contentious or possibly defamatory, must be removed immediately. Editors must be especially careful with the information they add about any living person, on any page on this website (including non-content pages).
Votes 5.1
edit- Support something of this sort is clearly needed to support WMF policy, but to be clear this is subject to the exclusions listed on the Help Sources page, right? For example, ORCID or ISNI id's would be considered verifiable in themselves and don't need a separate source? ArthurPSmith (talk) 19:03, 27 June 2016 (UTC)[reply]
- Support Jianhui67 talk★contribs 12:08, 28 June 2016 (UTC)[reply]
- Support Any unsourced statements must be removed!--Kopiersperre (talk) 16:11, 29 June 2016 (UTC)[reply]
- Support +++ --Droit de retrait 03 (talk) 15:03, 2 July 2016 (UTC)[reply]
- Support--GZWDer (talk) 10:50, 3 July 2016 (UTC)[reply]
- Support — Revi 13:01, 5 July 2016 (UTC)[reply]
- Oppose Too vague. What is meant by "especially" in this context? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:31, 7 July 2016 (UTC)[reply]
- Oppose Much of our data is from other sources. Typically it reflects what is known elsewhere. At this stage we are not able to display our data properly and this is true for sources as well. Thanks, GerardM (talk) 09:45, 7 July 2016 (UTC)[reply]
- Oppose MisterSynergy (talk) 10:00, 7 July 2016 (UTC)[reply]
- Oppose Magnus Manske (talk) 10:11, 7 July 2016 (UTC)[reply]
- Oppose ChristianKl (talk) 10:30, 7 July 2016 (UTC)[reply]
- Oppose The good part is the contentious or possibly defamatory, must be removed immediately part. But that can already be done know as vandalism. So no need to extend the rules for this for BLP. Mbch331 (talk) 10:46, 7 July 2016 (UTC)[reply]
- Oppose The proposal is much too general. Must is too strong and the proposal also does not show notion of authors of reliable sources (like research articles) and, for example, if a research article is sufficient support for a claim about a living person. For example, would the ORCID database be a reliable source in this context? Or the VIAF database? Etc. Egon Willighagen (talk) 10:57, 7 July 2016 (UTC)[reply]
- Oppose --Freedatum (talk) 11:00, 7 July 2016 (UTC)[reply]
- Oppose We need a general policy about verifiability first and after we can specify specific rules for some domains. Snipre (talk) 11:55, 7 July 2016 (UTC)[reply]
- Oppose --Hsarrazin (talk) 12:10, 7 July 2016 (UTC)[reply]
- Oppose As per Magnus--Kippelboy (talk) 15:43, 7 July 2016 (UTC)[reply]
- Oppose opposing for consistancy with my first statement Jane023 (talk) 19:15, 7 July 2016 (UTC)[reply]
- Oppose I think it's going too far. E.g. Barack Obama (Q76) has a bunch of unreferenced statements which are completely true. Defamatory or controversial statements are different thing, so discretion is needed. Banning unreferenced statements won't stop vandals - they'd just add junk as reference, so we'd need to do work anyway. --Laboramus (talk) 22:11, 7 July 2016 (UTC)[reply]
- Oppose --Geraki (talk) 04:28, 8 July 2016 (UTC)[reply]
- Oppose Emphasis on All is too encompassing and too extreme. It is an impossible task to require of metadata. Tools are in infancy to provide this requirement, so patience should be framework. Again: Not a fan of deletionist approach vs. "citation needed" constructive approach. -- Erika aka BrillLyle (talk) 06:39, 8 July 2016 (UTC)[reply]
- Oppose Per Andy's Evpok (talk) 09:23, 8 July 2016 (UTC)[reply]
- Oppose Too extreme. - PKM (talk) 18:03, 9 July 2016 (UTC)[reply]
Discussion 5.1
editI would probably like to see it for convicted of (P1399). — Finn Årup Nielsen (fnielsen) (talk) 15:01, 7 July 2016 (UTC)[reply]
- Having a flag on a property that says "must be referenced" and having report on constraint violation on that may be a good idea for ones like convicted of (P1399). --Laboramus (talk) 22:13, 7 July 2016 (UTC)[reply]
- I think adding statements to properties to say whether references are always required (for properties like the above), expected (for most properties) or not required (e.g. external IDs, internal things like topic's main category (P910)) would be a good idea. That should make it possible for people to create queries listing all statements on a subset of items they're interested in which still need references adding. If anyone wants to make a start on convicted of (P1399), this query should be all statements with no reference at all and this one should be all statements with imported from Wikimedia project (P143) rather than a proper reference. - Nikki (talk) 09:15, 8 July 2016 (UTC)[reply]
- A property on a propery about reference is a good idea. I listed another query here: Property talk:P1399. The problem may be a bit more complex. occupation (P106) and member of (P463) could be required depending on the value. — Finn Årup Nielsen (fnielsen) (talk) 12:28, 8 July 2016 (UTC)[reply]
- I think adding statements to properties to say whether references are always required (for properties like the above), expected (for most properties) or not required (e.g. external IDs, internal things like topic's main category (P910)) would be a good idea. That should make it possible for people to create queries listing all statements on a subset of items they're interested in which still need references adding. If anyone wants to make a start on convicted of (P1399), this query should be all statements with no reference at all and this one should be all statements with imported from Wikimedia project (P143) rather than a proper reference. - Nikki (talk) 09:15, 8 July 2016 (UTC)[reply]
Enforcement by block
editEditors who violate the living persons policy by inserting unverifiable or poorly-verified information about living people may be blocked. In extreme cases (such as blatant libel), this can include first-time offenses.
Votes 5.2
edit- Support sure. ArthurPSmith (talk) 19:04, 27 June 2016 (UTC)[reply]
- Support Jianhui67 talk★contribs 12:08, 28 June 2016 (UTC)[reply]
- Support +++ --Droit de retrait 03 (talk) 14:29, 2 July 2016 (UTC)[reply]
- Support--GZWDer (talk) 10:50, 3 July 2016 (UTC)[reply]
- Support — Revi 13:01, 5 July 2016 (UTC)[reply]
- Oppose Too vague. Nothing about warnings, appeals or expiry. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:32, 7 July 2016 (UTC)[reply]
- Oppose Magnus Manske (talk) 10:12, 7 July 2016 (UTC)[reply]
- Oppose ChristianKl (talk) 10:30, 7 July 2016 (UTC)[reply]
- Oppose per Pigsonthewing. Mbch331 (talk) 10:47, 7 July 2016 (UTC)[reply]
- Oppose as per Pigsonthewing. --Freedatum (talk) 10:57, 7 July 2016 (UTC)[reply]
- Oppose per Pigsonthewing. Also, what if the living person himself add unsourced data, being sort of an expert? What would happen if this person add itself as a source? How will that be dealt with? Egon Willighagen (talk) 10:59, 7 July 2016 (UTC)[reply]
- Oppose We need a general policy for blame and to block contributors having a bad behavior. Snipre (talk) 11:57, 7 July 2016 (UTC)[reply]
- Oppose - specically, I agree with Snipre. --Hsarrazin (talk) 12:11, 7 July 2016 (UTC)[reply]
- Oppose As per what is written --Kippelboy (talk) 15:43, 7 July 2016 (UTC)[reply]
- Oppose opposing for consistancy with my first statement Jane023 (talk) 19:16, 7 July 2016 (UTC)[reply]
- Oppose --Geraki (talk) 04:29, 8 July 2016 (UTC)[reply]
- Oppose First time offense is way too extreme. A more constructive, pedagogic approach would enhance editor engagement and help editors get better. Punishment first is way too drastic. This is sort of the basis of all Wikipedia editing -- we help each other collectively, as no one blossoms instantly into a great editor. -- Erika aka BrillLyle (talk) 06:39, 8 July 2016 (UTC)[reply]
- Oppose Per Erika's Evpok (talk) 09:23, 8 July 2016 (UTC)[reply]
Discussion 5.2
editEnforcement by page protection
editA page repeatedly subject to violations of this policy by multiple editors may be protected as a preventative measure.
Votes 5.3
edit- Support yes. ArthurPSmith (talk) 19:04, 27 June 2016 (UTC)[reply]
- Support Jianhui67 talk★contribs 12:08, 28 June 2016 (UTC)[reply]
- Support--GZWDer (talk) 10:50, 3 July 2016 (UTC)[reply]
- SupportChristianKl (talk) 12:15, 5 July 2016 (UTC)[reply]
- Support — Revi 13:01, 5 July 2016 (UTC)[reply]
- Oppose Too vague. What level of protection? For how long? under what circumstances can a request for unprotection be made? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:34, 7 July 2016 (UTC)[reply]
- Oppose as per Pigsonthewing. --Magnus Manske (talk) 10:12, 7 July 2016 (UTC)[reply]
- Oppose as per Pigsonthewing. Mbch331 (talk) 10:47, 7 July 2016 (UTC)[reply]
- Oppose as per Pigsonthewing. --Freedatum (talk) 10:57, 7 July 2016 (UTC)[reply]
- Oppose as per Pigsonthewing. A general policy explaining the different steps with the conditions in page protection from a general perspective is necessary. Snipre (talk) 12:01, 7 July 2016 (UTC)[reply]
- Oppose per Pigsonthewing and Snipre --Hsarrazin (talk) 12:12, 7 July 2016 (UTC)[reply]
- Oppose As per what is written --Kippelboy (talk) 15:43, 7 July 2016 (UTC)[reply]
- Oppose Opposing for consistancy Jane023 (talk) 19:12, 7 July 2016 (UTC)[reply]
- Oppose --Geraki (talk) 04:29, 8 July 2016 (UTC)[reply]
- Oppose Per Andy's Evpok (talk) 09:23, 8 July 2016 (UTC)[reply]
Discussion 5.3
editEnforcement by revision deletion
editRevisions containing potentially libelous or contentious statements about living people may be revision deleted (hidden) by an administrator.
Votes 5.4
edit- Support ArthurPSmith (talk) 19:04, 27 June 2016 (UTC)[reply]
- Support Jianhui67 talk★contribs 12:08, 28 June 2016 (UTC)[reply]
- Support --Droit de retrait 03 (talk) 14:30, 2 July 2016 (UTC)[reply]
- Support--GZWDer (talk) 10:50, 3 July 2016 (UTC)[reply]
- Support — Revi 13:01, 5 July 2016 (UTC)[reply]
- Oppose As written. OK for libellous statements, but not for those that are merely contentious. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:33, 7 July 2016 (UTC)[reply]
- Oppose as per Pigsonthewing. --Magnus Manske (talk) 10:13, 7 July 2016 (UTC)[reply]
- Oppose as per Pigsonthewing. ChristianKl (talk) 10:31, 7 July 2016 (UTC)[reply]
- Oppose as per Pigsonthewing. --Freedatum (talk) 10:57, 7 July 2016 (UTC)[reply]
- Oppose as per Pigsonthewing. Egon Willighagen (talk) 10:59, 7 July 2016 (UTC)[reply]
- Oppose as per Pigsonthewing. Snipre (talk) 12:01, 7 July 2016 (UTC)[reply]
- Oppose as per Pigsonthewing. --Hsarrazin (talk) 12:13, 7 July 2016 (UTC)[reply]
- Oppose As per what is written --Kippelboy (talk) 15:43, 7 July 2016 (UTC)[reply]
- Oppose As far as I am aware this is currently done. No more policy is needed. Jane023 (talk) 19:11, 7 July 2016 (UTC)[reply]
- Oppose --Geraki (talk) 04:29, 8 July 2016 (UTC)[reply]
- Oppose Per Andy's Evpok (talk) 09:23, 8 July 2016 (UTC)[reply]
Discussion 5.4
edit- "Contentious" statements do not need to be hidden, but it is common on other projects to hide offensive vandalism on BLPs, even if it is not libel. --Rschen7754 00:28, 8 July 2016 (UTC)[reply]
Enforcement by oversight
editIn blatantly libelous or otherwise serious cases, revisions containing offending content may be oversighted. Note that this is already part of the oversight policy.
Votes 5.5
edit- Support ArthurPSmith (talk) 19:05, 27 June 2016 (UTC)[reply]
- Support Jianhui67 talk★contribs 12:08, 28 June 2016 (UTC)[reply]
- Support already part of the oversight policy. --Droit de retrait 03 (talk) 15:06, 2 July 2016 (UTC)[reply]
- Support--GZWDer (talk) 10:50, 3 July 2016 (UTC)[reply]
- Support ChristianKl (talk) 12:15, 5 July 2016 (UTC)[reply]
- Support — Revi 13:01, 5 July 2016 (UTC)[reply]
- Support Magnus Manske (talk) 10:13, 7 July 2016 (UTC)[reply]
- Neutral If it's already in the oversight policy, there is no need to make such a rule again. Mbch331 (talk) 10:48, 7 July 2016 (UTC)[reply]
- Support --Freedatum (talk) 10:57, 7 July 2016 (UTC)[reply]
- Emot tautology (Q841606) -- Innocent bystander (talk) 12:02, 7 July 2016 (UTC)[reply]
- Oppose we don't need more policy if we already have a policy! Jane023 (talk) 19:10, 7 July 2016 (UTC)[reply]
- Neutral I thought it's already the case? --Laboramus (talk) 22:14, 7 July 2016 (UTC)[reply]
- Neutral If it is already the policy, what is the point ? Evpok (talk) 09:23, 8 July 2016 (UTC)[reply]
Discussion 5.5
editSince this is - as noted - already part of policy, the question is moot. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:46, 7 July 2016 (UTC)[reply]
- This RfC is a bad move: "Hard cases make bad law ". Better to draft guidelines, taking advantages of the fact that this is a wiki, then hold an RfC on whether to adopt them as policy. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:45, 7 July 2016 (UTC)[reply]
- There is plenty scope of verifying data using alternate sources. Publishing what is problematic / different will upgrade our quality and use. It is a way that will grow our committed community and not destroy it wit infighting. Thanks, GerardM (talk) 09:52, 7 July 2016 (UTC)[reply]
- I can't figure out the usefulness of any of the proposals above. They don't seem to be well suited for the reality of Wikidata. In some cases the language of a proposal is ok, but I can't imagine any positive action it might be used for. I suggest to redo the discussion from scratch with a clearer "use case" (objectives we want to achieve) and a way to monitor how well we're doing against the goal. Nemo 09:59, 7 July 2016 (UTC)[reply]
- To me, one of the problems with this RFC is that is does not specify in enough detail how sourcing is expected to be implemented, who/what will check things, etc. Detailed information on how the RFC handles the various used of References on statements is required. Keep in mind that Wikidata has a granular system for statements, and various mechanisms of giving a Reference, not all of which seem to be allowed by this RFC, but it is very unclear in what is and is not allowed. Moreover, as others have indicated, no mechanism is in place to challenge decisions based on this RFC, or how to correct situations. I would also welcome to get an idea of how urgent a solution is to the problems that are behind this RFC. Egon Willighagen (talk) 11:04, 7 July 2016 (UTC)[reply]
- To me, this RFC seems oriented to allow enforcement of complete removal of unsourced data, instead of trying and improved insufficient sourcing. A tool allowing to mark, and thus easily find and unsufficiently sourced data, would be much more useful. Specifically, a tool allowing to search for insufficiently sourced specific properties, with wp import, could allow to try and search info inside relevant wp, methodically...
- To me a background colouring system (allowing to choose the colour, for adaptability to various colour-blindness), that would make obvious that a data has "no source", or "wp-only source", could really help, looking for specific data sourcing… --Hsarrazin (talk) 12:19, 7 July 2016 (UTC)[reply]
- I like the fact that this RfC is attempting to address many issues that are important; however, the overarching approaches seem to either re-invent existing policies/functions, take an extreme approach, or focus on deletion and blocking over constructive "citation needed" and teachable engagement to develop editors into better editors. I like many of the comments but the solutions here are not ones I think will help Wikidata grow and get better. -- Erika aka BrillLyle (talk) 06:45, 8 July 2016 (UTC)[reply]
- Using the wikidata twitter to campaign for one position in this RFC (see the Magnus Manske retweet) does not strike me a reasonable use of that account. Is this the way future RFCs in this project are going to go?Geni (talk) 16:32, 10 July 2016 (UTC)[reply]