Jump to content

Wikipedia:Village pump (policy): Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Tags: Mobile edit Mobile web edit
Line 382: Line 382:
:I think it more accurate to say that the coverage all relates to a ''chain of events'' (the campaign) culminating in one event (the election). I'm not sure that BLP1E was intended to apply to this.
:I think it more accurate to say that the coverage all relates to a ''chain of events'' (the campaign) culminating in one event (the election). I'm not sure that BLP1E was intended to apply to this.
:This may be my US outlook on elections... but I doubt anyone from the US would apply 1E to a US election - where we first have primary elections and then the general election ... each of which could be considered separate "events" (even though they are part of the same overarching political process)... as well as numerous campaign rallies, debates, fundraisers, etc. (which could also be considered separate "events"). [[User:Blueboar|Blueboar]] ([[User talk:Blueboar|talk]]) 18:49, 23 September 2017 (UTC)
:This may be my US outlook on elections... but I doubt anyone from the US would apply 1E to a US election - where we first have primary elections and then the general election ... each of which could be considered separate "events" (even though they are part of the same overarching political process)... as well as numerous campaign rallies, debates, fundraisers, etc. (which could also be considered separate "events"). [[User:Blueboar|Blueboar]] ([[User talk:Blueboar|talk]]) 18:49, 23 September 2017 (UTC)

== Straw poll on the current view of WP:NOT#NEWS ==

Recently I proposed a changed at [[WT:NOT]] which related to [[WP:NOT#NEWS]] (Wikipedia is not a newspaper) which was taken through an RFC that closed recently [[WT:NOT#RFC: New subsection under "Not a Newspaper" about commentary here]] ([https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:What_Wikipedia_is_not&oldid=802229589#RFC:_New_subsection_under_.22Not_a_Newspaper.22_about_commentary permalink to that]) It closed as no consensus, but I would recommended reading the !votes and discussion of that, as it highlights a currently growing issue on en.wiki, how are we supposed to handle current events/news.

A key factor is the current fate of [[Wikinews]]. It is, as mentioned several times in the discussion above, effectively a dead project, stuck in a catch-22 problem to get people to use it. There is clearly both editor desire and readership interest to see current news provided in a wiki-style, and en.wiki has generally done well before in covering current events. But events over the last few years (particularly over the last 2 years) have created a lot of editor tension and behavioral problems related to current event coverage (given what passes by AN/ANI/ARBCOM and various policy noticeboards), and highlights the differences between what an encyclopedia is and what a newspaper is. Their goals aren't fully mutually exclusive but there are several conflicting goals. [[WP:RECENTISM]] highlights many of these issues.

So I figure that to try to resolve this is to at least start with a straw poll, not designed to establish any immediate change in policy or guideline, but only to see where the current perception is of how en.wiki should be handling NOT#NEWS. Testing the wind, to speak. To that, there's principle three options to consider to get an idea where an editor/reader's interest in this may be as to determine the preferred method to go forward, if needed.

# The current situation for NOT#NEWS is fine or only needs some small adjustments. This might include defining a guideline to help with writing current events articles (akin to [[WP:Writing about fiction]]), but likely no change to policy.
# NOT#NEWS should be more strongly enforced, and limiting our current event coverage. This ''might'' include stronger enforcement of [[WP:NEVENTS]], additional policies relating to NOT#NEWS, encouraging/putting more current news articles to draft space, pushing more content/editors to Wikinews, and the like.
# NOT#NEWS should be less strong enforced, and expanding our current event coverage. This might include outright removal of NOT#NEWS, adjusting how NOT#NEWS and NEVENTS are written and handled to allow more news, effectively merge Wikinews in en.wiki, and the like.

As this is not an attempt to find a solution right now; I would fully expect that any proposed idea that comes out of that would be under a full Wiki RFC to consider before implementation. So a straw poll is best here. I would request you simply !vote in the appropriate section below, keeping threaded discussion to the provided discussion section. --[[User:Masem|M<font size="-3">ASEM</font>]] ([[User Talk:Masem|t]]) 16:23, 25 September 2017 (UTC)

=== Option 1: [[WP:NOT#NEWS]] is working as is ===
Or: The coverage of current events on en.wiki is about right or only needs fine adjustment
# (vote and sign here)

=== Option 2: [[WP:NOT#NEWS]] should be more strongly enforced ===
Or: En.wiki should have significantly less coverage of current events
# (!vote and sign)

=== Option 3: [[WP:NOT#NEWS]] should be less strongly enforced ===
Or: En.wiki should have more expanded coverage of current events
# (!vote and sign here)

===Threaded discussion on NOT#NEWS===

Revision as of 16:23, 25 September 2017

 Policy Technical Proposals Idea lab WMF Miscellaneous 
The policy section of the village pump is used to discuss proposed policies and guidelines and changes to existing policies and guidelines.
If you want to propose something new that is not a policy or guideline, use Village pump (proposals).
If you have a question about how to apply an existing policy or guideline, try one of the many Wikipedia:Noticeboards.
This is not the place to resolve disputes over how a policy should be implemented. Please see Wikipedia:Dispute resolution for how to proceed in such cases.

Please see this FAQ page for a list of frequently rejected or ignored proposals.


Upgrading WP:INFOCOL

I think time has come to upgrade the status of Wikipedia:Infobox consolidation from a mere essay, so that it standardisation and consolidation process may speed up a little. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 02:23, 23 August 2017 (UTC)[reply]

That's not written in guildeline style, and many points in it are just someone's opinion. A few points in it should probably be integrated into WP:INFOBOX and/or MOS:INFOBOX, as appropriate. What it is, is someone's attempt at an FAQ [or "a FAQ", depending on how you say "FAQ"], which makes it an essay, especially since these mostly do not appear to be questions that are actually frequently asked. Some of the points in it do not really pertain to infoboxes in particular, but are just standard WP:TFD operating procedure for templates in general: we merge redundant ones when possible, to reduce the confusing profusion of low-use templates.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  21:31, 23 August 2017 (UTC)[reply]
Can you please guide on how to improve it to standards? -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 15:34, 24 August 2017 (UTC)[reply]
No, because as I said, "a few points in it should probably be integrated into WP:INFOBOX and/or MOS:INFOBOX, as appropriate", while some of it's subjective, and other parts aren't specific to the issues but are general "what we do with redundant templates" stuff. WP is not in the habit of promoting essays to guidelines, nor creating new guidelines. I can't even remember the last time we did that. We don't need new guideline pages, only refinements to the existing ones, when there's an identifiable problem that can be addressed by doing so. What ongoing, recurrent problem is addressed by anything in that page? In what way(s) is it not already addressed by extant policies, guidelines, and TfD procedures? "I want to promote my essay to guideline status" isn't a valid rationale.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  16:51, 24 August 2017 (UTC)[reply]
In that case, can you please help me in integrating "a few points in it into WP:INFOBOX and/or MOS:INFOBOX, as appropriate"? -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 05:11, 25 August 2017 (UTC)[reply]
In theory, though this is a busy time. The first steps are identifying specific problems to solve, demonstrating they're real problems, and demonstrating that existing guideline/policy language doesn't already cover it (i.e., it could be a behavioral problem on the part of a certain editor or group of editors rather than a guideline wording problem). We don't have guidelines about problems that are only theoretical. When you've identified a clear hole in the guidelines and that it needs to be plugged, I'm pretty good at wordsmithing the plug for the hole. I want to reiterate that much of that page is just describing what WP:TFD already does, so that's all "rehash" material. What is unique to the infobox issue(s)?  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  07:11, 2 September 2017 (UTC)[reply]
Such a policy is needed to reduce comments in discussions like [1]. Also check out {{Infobox fashion designer}} and {{Infobox Hindu leader}}, such Infoboxes should have been merged long before, but more like these still exist. Arguments like these erupt in almost every merge discussion and then the discussion forum gets converted into polling booth based on such arguments. That is why such a policy is needed as there is a good enough policy to describe conditions for deletion of a template but not for merger, specifically for Infoboxes. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 16:08, 6 September 2017 (UTC)[reply]
Another [2] -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 15:42, 9 September 2017 (UTC)[reply]

Now even admins doing the same thing here. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 12:21, 13 September 2017 (UTC)[reply]

Article deletion for TOU violations?

Do we have a definitive policy statement about deleting articles due to TOU violations? Specifically, undisclosed paid editing. I'm looking at Wikipedia:Articles for deletion/Gene Freidman, attempting to close the discussion. One of the assertions there is, The creator violated our TOU so we should delete the article. This is a common claim at AfDs, but I can't find a definitive policy statement one way or another. The TOU certainly gives us the legal right to Refuse, disable, or restrict access to the contribution of any user who violates these Terms of Use, but that's not the same as it being our policy to do so. I'm not looking for advice on how to close the AfD, just a better understanding of our policies. -- RoySmith (talk) 19:24, 2 September 2017 (UTC)[reply]

We don't have such a policy yet. Jo-Jo Eumerus (talk, contributions) 19:52, 2 September 2017 (UTC)[reply]
  • I've taken a look and I've read through that AfD again. Wikipedia's general inclusionist philiosophy is sometimes too wildly applied, especially by participants at AfD who may be less faniliar with our guidelines or who may have an axe to grind with other editors in the discussion or the nominator. IMO, in the absence of a local ruling, we should interpret the WMF ToU as being sufficiently broadly construed to delete such content, particularly in the case of a BLP that might technically pass our notability guidelines. It's loss is no grave concern because if it hadn't been paid for contrary to policy, it would not have existed anyway (at that time). That said, I'm in favour of deleting all works by paid undisclosed paid editors but for a very different reason than most people and one that never gets mentioned - but that would be another debate. Kudpung กุดผึ้ง (talk) 22:14, 2 September 2017 (UTC)[reply]
    • Tend to agree. If the subject is self-evidently notable, a clean article about them can be created. We don't want to be in a WP:BOGOF loop, where Company A hires Paid Editor B to create some shlock, and the Legit Editors C through Z spend a lot of time trying to fix the bogus article. We should only have the article if the legit editors conclude we need one and it's done right the first time.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  00:02, 4 September 2017 (UTC)[reply]
  • TOU is a legal contract between a user and WMF. Its enforcement is responsibility of the parties to this contract - WMF in this case. Other persons have noting to do with it unless they are specifically authorized by WMF. So, in absence of a community policy, TOU is irrelevant to any our internal process. Ruslik_Zero 18:54, 4 September 2017 (UTC)[reply]
    Not really. People get blocked for ToU violations all the time, by WP admins, not by WMF attorneys.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  08:10, 5 September 2017 (UTC)[reply]
    Many of the ToU are included in our policy; violating those policies is blockable by WP admins, violating the ToU is blockable by the Foundation. עוד מישהו Od Mishehu 20:59, 7 September 2017 (UTC)[reply]
    It's this hair-splitting? The short of it appears to be that, yes, people can be blocked for ToU violations. Since Jimbo's backing-away from acting as a "super-admin", all of this seems to be handled by admins anyway, and even in cases where it's not (are there any?), what difference does it make? The end result is the same. If people can be blocked (one way or another) for ToU violations, it would seem to stand to reason that other community actions, like page deletion, can be as well. I do agree that most of the ToU under which that would be common are already also policy-codified, at WP:NOT and elsewhere, but I don't see that any loophole is created, whereby if we've missed a ToU element in the policies, that its somehow fair game to exploit. That's already covered by WP:GAMING and WP:LAWYER.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  04:09, 8 September 2017 (UTC)[reply]
  • Local en.Wiki policy can only supersede the WMF terms of use on this matter with a large sitwide RfC adapting a change. We have not done so, therefore removal of content and/or deletion is justified under the TOU unless there is an explicit en.Wiki policy authorizing otherwise. Since there is no special procedure for it, the correct venue for discussions involving clear TOU violations that are not also G5 or G12 eligible is AfD unless the meet any of the other CSD. Until such a point that the local community here authorizes otherwise, undeclared paid editors have as much right to have their content on en.Wiki as copyright violators: both being explicitly disallowed by the TOU. TonyBallioni (talk) 04:34, 8 September 2017 (UTC)[reply]
Technically, the TOU doesn't state what needs to be done about paid editors - only that they are required to disclose their connection with clients. In particular, it doesn't make any statement about contributions - paid editors who fail to disclose may suffer sanctions, but the content they add is not banned as such. Traditionally, we've retained the content of paid editors unless it met the criteria of CSD or failed at AFD, and keeping the content is not a specific problem under the TOU. - Bilby (talk) 10:56, 8 September 2017 (UTC)[reply]
RoySmoth has pointed out above the passage in question that is applicable. We have the right to remove any content that is in violation of the TOU, and the way we can do that is through the regular deletion process. TonyBallioni (talk) 12:51, 8 September 2017 (UTC)[reply]
If the community wishes to delete paid content, the community is welcome to. I just wished to clarify that your statement was misleading when you wrote "undeclared paid editors have as much right to have their content on en.Wiki as copyright violators: both being explicitly disallowed by the TOU", as the TOU does not explicitly disallow content from paid editors. - Bilby (talk) 13:11, 8 September 2017 (UTC)[reply]
It does, as they have no right to contribute if they are in violation of them. I don't consider that misleading. TonyBallioni (talk) 13:20, 8 September 2017 (UTC)[reply]
Given how the TOU is being stretched recently in regard to paid editing, it is important that we remain accurate in how we describe it. The TOU only mandates that paid editors must disclose - how we manage instances of non disclosure is a choice the community here makes, rather than something directly determined by the TOU. - Bilby (talk) 13:33, 8 September 2017 (UTC)[reply]
  • Object example of the day: [3]. Wow! — fortunavelut luna 09:43, 8 September 2017 (UTC)[reply]
  • The policy we do have is WP:PAID which implies that the community can create a policy that all PAID-violations are auto-delete cases (which it hasn't done yet). I myself closed a similar AFD as "no consensus" (as Sandstein did in this case). Basically, the point is that we don't have a "fruit of the poisonous tree" policy (yet) and creating one is not what AFD is for. Regards SoWhy 10:16, 8 September 2017 (UTC)[reply]
    • The problem is that the policy has no enforcement power. From the points of view of the people making money creating these articles, and their clients, the only effective deterrent is to delete the article. We allow people to make throw-away accounts, so banning is meaningless. If you hire somebody to create a vanity article for yourself, and that person's account d'jour gets banned but the article remains, You're happy. Your paid editor is happy. Everybody is happy but us. So, we need a more effective enforcement tool, and the only one I can see that will work is deleting the article. -- RoySmith (talk) 11:48, 8 September 2017 (UTC)[reply]
      • Feel free to propose an actual change to WP:PAID to that effect. Yours might be a sensible argument to achieve this. However, as noted, current policy does not allow this. Regards SoWhy 12:21, 8 September 2017 (UTC)[reply]
        • No change is needed: the TOU say that material in violation with them can be removed. Absent an explicit local consensus otherwise, that is the policy. You're right that there is no auto-delete. It is a valid argument at AfD, however, which with PROD is currently our only way to deal with this. Your view that it is not a valid deletion rationale would actually be the change in policy without consensus here. Local en.Wiki policy has not chosen to exempt users from the TOU, because it effectively gets rid of WP:PAID by leaving it with no enforcement mechanism. TonyBallioni (talk) 12:51, 8 September 2017 (UTC)[reply]
          • Please quote the section of the ToU that says so. I re-read them and I cannot find any such rule. As far as I can tell, the ToU only contain rules, they lack "punishments". That is for individual projects to decide per ToU #10: "The community has the primary role in creating and enforcing policies applying to the different Project editions." (emphasis added). The ToU explicitly call upon each and every project to create rules how to handle violations of the ToU (which is why Commons or Species for example are allowed to have a policy that does not require paid contributors to identify themselves). Regards SoWhy 14:10, 8 September 2017 (UTC)[reply]
            • Sure, section 5 explicitly prohibits undisclosed paid editing, and also requires a positive consensus to allow for a change to that on a local wiki (as Commons and Species have done). Section 10 allows the Foundation to remove or deny access to any contribution in violation of the TOU. It is the primary role of the communities of the local wikis to enforce, as you have pointed out. Prohibitions must have an effective enforcement procedure, otherwise they are not prohibitions, but merely suggestions. Lacking a clear policy to deal with this specific case, we are empowered to enforce the TOU through our standard local procedures, which are blocks and AfD. To argue that lacking a local policy the TOU cannot be enforced is in effect changing the disclosure requirement to be non-existent, which is explicitly prohibited without consensus. en.Wiki has not created an alternative disclosure policy as of yet, so we therefore have our standard enforcement mechanisms in place to deal with violations. TonyBallioni (talk) 15:36, 8 September 2017 (UTC)[reply]
              • So you admit that #4 of the ToU does not contain any instructions how to handle such content. The rest is one (imho invalid) interpretation of local policies which explicitly do not cover these edits. WP:BLOCK covers those editors as "disruption only" accounts but it does not say "delete stuff created by those editors after blocking" (neither does WP:BAN incidentally). So if the policies do not allow for deletion of edits by blocked/banned users made before the block/ban, why should it be different for PAID violations? After all, vandalism is against the ToU as well and yet no one would argue to delete all good edits a vandal made just because they were later blocked for vandalism. And neither WP:DEL-REASON nor WP:NOT explicitly list violations of WP:PAID as reasons for deletion. Your POV might be ultimately become widespread consensus but the point is this: Don't try to interpret policies to fit the desired outcome, start an RFC to create a policy that explicitly says so. After all,having it clearly written down one was or another will save us from further discussions like this and doesn't force admins at AFD to judge issues that AFD is clearly not meant for. Regards SoWhy 16:43, 8 September 2017 (UTC)[reply]

It is up to local consensus to determine how to deal with it in each specific case. The POV you are arguing for is essentially trying to circumvent the requirement that local communities must positively adopt an alternative to the disclosure requirements by making the requirements non-enforcable. I also have not said here that current policy allows for speedy deletions of all cases, which seems to be your understanding of what I'm arguing. I think it should, but there is not consensus for that yet. My view is quite simple: where local policy does not have any special procedures for dealing with it, we deal with the articles on a case by case basis through the standard local process, which is AfD. We are allowed to argue global policies and TOU in those discussions, since barring an explicit local consensus, they apply to us. Discounting them has no basis in policy, and is in contradiction of the requirement for an alternate disclosure policy to gain acceptance. You are free to argue at AfDs that we should not delete paid discussions per PRESERVE or WP:N or a policy or guideline of your choice, but arguing form the global TOU is equally valid, and as in all cases where there is a tension in the policies and guidelines, it is up to the closing admin to weight them on their relative strength.

I'd give the same advice to you: don't try to do an end-run on an alternate disclosure policy on en.Wiki, which is what refusal to enforce them is. If you think that we should adopt a Commons style policy, please start the RfC. Otherwise, the TOU control, and we have our standard local means of enforcement to apply. TonyBallioni (talk) 17:00, 8 September 2017 (UTC)[reply]

To be honest, deleting content doesn't generally affect the paid editors that we are targeting. By the time we spot and delete the articles, they have generally been paid and have received a positive review. Very occasionally we delete content before the editor is paid, but in most of those cases the editor blames "evil Wikipedians", so the feedback is normally still positive or, at worst, left blank. The problem is that freelance paid editors do not generally have an ongoing relationship with their clients, so problems that emerge after they have been paid don't directly affect them. This is frustrating, as they are generally misleading their clients by not revealing the status on Wikipedia and the additional risks that hiring them entails, making it unethical on multiple levels. - Bilby (talk) 13:20, 8 September 2017 (UTC)[reply]
Since you mention reviews, I assume you are referring to freelancers using sites like Upwork. I think it's safe to say that they are a relatively small fraction of the paid editors. The bulk of the market are paid editing companies and PR firms that create Wikipedia pages as an extra service for their clients. Deleting content they add must surely translate into a significant reduction in leads through referrals, and for those at the higher-end, reputational damage. The second reason I favour deletion of such content is that UPEs tend to use various tricks to maximise the probability that their creations will "stick". These include misrepresented or outright falsified references, sometimes to offline sources, which require a large amount of work to check. Since the subjects are almost exclusively non-notable and borderline-notable living persons and organisations, it's an exceptionally bad use of volunteer time. Rentier (talk) 16:21, 8 September 2017 (UTC)[reply]
I don't know of any figures as to whether PR firms or freelancers are responsible for most of the paid editing - my guess would be that the freelancers edit more articles, but that the PR firms make more edits on individual articles. However, it is largely moot, because most of the paid editing we detect seems to be from freelancers, in which case deleting is rarely an effective preventative tool. Very occasionally it makes a difference, but as someone who has been deleting the work of paid editors for many years, I've almost never seen it make an impact on their future jobs. - Bilby (talk) 17:38, 8 September 2017 (UTC)[reply]
In the absence of reliable figures, all I can offer are a few anecdotes. The Anatha Gulati group doesn't seem to belong to a freelancer -- and its size dwarfs most other UPE sockfarms. I am not aware of any freelancers who handle such volumes. I also don't think the impact on freelancers is negligible. Following the deletion of a number of articles at the end of July, the number of Upwork jobs awarded to BusInCordoba each month dropped from a stable level of 5-8 throughout 2017 to just one in August. I suspect this was caused by their Upwork success rate dropping below the "top rated" threshold of 90%. The success rate can drop without any visible negative feedback as it's based on a private rating given by the clients. It's just one data point (perhaps the person went on vacation), but it suggests that the deletion can have a preventive effect. Admittedly, the impact of similar deletion on Highstakes00 was much smaller, but so was the fraction of identified accounts to the total number inferred from their Upwork history. Still, their success rate dropped by a few points and is no longer perfect. And even for Upwork freelancers, offline referrals by past clients -- which will dry up if the content is deleted -- are an important source of new business. I know because I used to be one. Rentier (talk) 11:14, 9 September 2017 (UTC)[reply]
I have a list of over 100 paid editors from Upwork. The only means I've found of having an impact by deleting articles is to do so after they've created the page but before they've been paid. This is a very small window, and only occasionally is it hit. Some seem to make it extremely small, although I suspect that comes from the arrangement they have with their client. In some cases I've even hit that window, only to see them get positive feedback and a comment that "it was out of their control". In cases where it happens too often, the paid editor normally starts a new account - it is a bit of a loss for them, but a bigger hit for us. That may prove to be the case with BusInCordoba's recent drop in work. So yes, we can have an impact in some cases, but deleting doesn't make much of a dent unless we can get the articles at the right time, and that's mostly to do with when we detect them instead of how quickly they are removed. Just tagging at the right time is effective, but the solution for me is in rapid detection, rather than in what we do to the article next. - Bilby (talk) 03:23, 11 September 2017 (UTC)[reply]
  • We do allow content from banned users (like with COI editing), if other editors in standing accept responsibility to that content. If the article's content does not fail any policy and another editor is willing to vouch for that and take that responsibility from the banned user, there's no point in deleting the content. --MASEM (t) 13:19, 8 September 2017 (UTC)[reply]
  • The Terms of Use state that "If your account or access is blocked or otherwise terminated for any reason, your public contributions will remain publicly available..." So, automatic deletion would itself violate the Terms of Use because the contributions would then no longer remain publically available. You therefore need some other reason to delete besides the ToU violation. Andrew D. (talk) 17:42, 8 September 2017 (UTC)[reply]
  • User:Andrew Davidson That wording should be changed from "will" to "may". Common sense (to me) says we're not legally bound to keep ToU violation content publicly available.
  • It would be good to hear from legal department if content given in violation of the ToU is legal for us to licence (i.e. fruit of the poisonous tree / aiding and abetting a civil offence).
  • For borderline notability (which is common), we should just delete all promo, and speedily per DEL#4, DEL#14.
  • For clearly notable, maybe case by case. I've updated this in WP:BOGOF to reflect this, which basically raises the bar for promo, but doesn't drastically change things. Widefox; talk 15:45, 12 September 2017 (UTC)[reply]
  • The legal status of all material published by Upwork freelancers without going through OTRS is questionable. All rights to such work are owned by the client. I fail to see how asking a freelancer to post text on Wikipedia implies releasing it under a free license. The clients are generally ignorant of our policies (such as WP:PAID) and it's hard to argue that they are familiar with our licensing requirements. It would be good to hear a professional opinion on this. This is a purely legal question, independent on the attitude one may have regarding the undisclosed paid content. Rentier (talk) 16:27, 12 September 2017 (UTC)[reply]
There's the copyright which the contributor always retails anyhow (see WP:C), but the question is... if it's not legal to edit, then (due to legals which I'm guessing at)...can we legally licence it? I would guess from the ToU wording above that the legal line is we can retain and use it. If not, it would have to be deleted anyhow. So (thinking aloud) seems ToU doesn't constrain us, but this should be clarified. Widefox; talk 16:43, 12 September 2017 (UTC)[reply]
I think the question Rentier is raising is who retains the copyright for commissioned works: the client or the freelancer or firm. If the client retains it, there is an argument under our copyright policy that we can't host the text without an explicit license from the copyright holder, which the freelancer would be unable to provide. This is an even bigger question for text that is written by a client and given to a freelancer or firm as something to base an article off of. In those cases, the client all but certainly holds the copyright on the text, and its a valid question as to whether or not giving it to someone to post on Wikipedia is the same as licensing it themselves if they were to do it. TonyBallioni (talk) 17:05, 12 September 2017 (UTC)[reply]
TonyBallioni, Yes, it's not clear that the editor is the copyright owner, so which of these apply (Licensing of Content (1. a. Text to which you hold the copyright, 2. c. Importing text found elsewhere or that you have co-authored with others needing OTRS). My point is different, more general about whether it's possible to have 7. Licensing of Content agreement at all from a prohibited activity. Widefox; talk 01:55, 13 September 2017 (UTC)[reply]
Forgive my naïvety: Is this why we allow paid editors to be OTRS agents? Kudpung กุดผึ้ง (talk) 07:16, 16 September 2017 (UTC)[reply]

A statement from WMF staff about RfC referrer info discussion

It's been one month after the RfC discussion on referrer info was closed. For notification, one of the WMF staff members posted her statement at Wikipedia talk:Village pump (policy)/RfC: Wikimedia referrer policy about the discussion. --George Ho (talk) 12:10, 9 September 2017 (UTC)[reply]

Does/should WP:NOFULLTEXT apply to more than just primary sources?

The wording of Wikipedia:Do not include the full text of lengthy primary sources is rather confusing. It starts "Wikipedia is not a mirror of public domain or other source material", suggesting that the guideline applies to all sorts of sources, but the title of the page refers to primary sources only. I would be interested to hear opinions on whether the guideline applies to articles such as Science and technology in Turkmenistan, which has been copied in its entirety from a UNESCO report, and if it doesn't, then whether the guideline should be changed so that it does. Cordless Larry (talk) 14:09, 10 September 2017 (UTC)[reply]

  • As another data point, we most certainly do have many articles on demography that were copy/pasted from the CIA World Factbook and many articles on American municipalities copied from census databases. There is no problem as such with these and I think the idea that we shouldn't host them is silly. Unless someone has a better alternative, then that is exactly what we should do (consider how difficult it would be to write an article on science and technology in Turkmenistan). Wikipedia is not Wikisource but that shouldn't stop us from using quality public domain sources (e.g. 1911 Encyclopedia Britannica) as the basis of articles. ―Justin (koavf)TCM 17:50, 10 September 2017 (UTC)[reply]
Point taken about demographic statistics, but I think my issue is that whereas those involve copying facts and figures in from external sources, the sort of copying going on at Science and technology in Turkmenistan involves importing opinions (such as "President Berdimuhammadov is far more committed to science than his predecessor"). Copying such large portions of a secondary source such as this presents significant NPOV problems, in my view. Cordless Larry (talk) 18:03, 10 September 2017 (UTC)[reply]
Sure but the solution is to just change the text. It's in the public domain and no one expects integrity of the original source material (like on Wikisource), so I think we are better off having a copy/pasted public domain article by experts on an obscure topic than having nothing. ―Justin (koavf)TCM 18:06, 10 September 2017 (UTC)[reply]
Yep, I agree that the text should be changed, hence my question about whether WP:NOFULLTEXT prescribes this. Cordless Larry (talk) 18:19, 10 September 2017 (UTC)[reply]
@Cordless Larry: The direct answer would be no. Moreover, we also need to be very clear: that there is no minimum requirement for changing the text beyond effectively turning into an article, especially when the content is already encyclopedic in nature with features such as being well written, neutral and well researched. Remember, our goal is to create Encyclopedic content. Sadads (talk) 13:09, 11 September 2017 (UTC)[reply]
Also, this section of the plagiarism guideline, explicitely welcomes these additions. Sadads (talk) 13:12, 11 September 2017 (UTC)[reply]
  • See WP:NOTMIRROR #3, a policy page where the "Wikipedia is not a mirror of public domain or other source material" opening words of the Wikipedia:Do not include the full text of lengthy primary sources guidance seem to have originated from. No, the guideline which, according to its title, only speaks about "primary sources" should not be extended beyond its scope to say also something about non-primary sources: non-primary sources are already covered by policy, and if they need separate treatment in a subsidiary guideline, that would necessarily need to be under a different guideline title. --Francis Schonken (talk) 19:06, 10 September 2017 (UTC)[reply]
  • I really don't understand why we would punish or be unhappy with the kinds of additions: expert written content that is reasonably neutral, from sources with a reputation that are reasonably neutral (i.e. UNESCO), is quite commendable. How else can we expect the coverage? Moreover, the bias introduced by the source, if the language and argumentation is sufficiently removed, shouldn't introduce any more bias than an average contributor -- whether new or experienced. We definitely have tons of materials from US GOV sources (including whole articles about military units, NASA-related writing on swaths of space and climate science, etc). We should be encouraging the practice of using open-access content to fill vital content gaps. This feels like favoring rules, rather than the spirit of Wikipedia. Sadads (talk) 12:35, 11 September 2017 (UTC)[reply]
    • If it was reasonably neutral, I wouldn't have so much of a problem, Sadads, but Science and technology in Turkmenistan is really UNESCO's view of science and technology in Turkmenistan. I've already highlighted "President Berdimuhammadov is far more committed to science than his predecessor" as an example of unattributed POV above, but there are further problems with other articles created from the same UNESCO report. World Science Day for Peace and Development tells us that "The impact of science on people's daily life and its profound societal implications, including those of an ethical nature, make scientific literacy a prerequisite for effective democratic processes". Scientific mobility presents case studies in the manner of an essay. World Conference on Science is worse still. Science and technology in Benin seems to give policy advice: "By diversifying its economy, Benin would reduce its reliance on fluctuating global market prices for commodities and create jobs for its rapidly growing population". These are just a small number of the many issues caused by copy-pasting in article-length portions of text, which could be avoided if contributors used the sources as we would any other source, rather than copying them word-for-word. Cordless Larry (talk) 13:34, 11 September 2017 (UTC)[reply]
      • @Cordless Larry: In general, those articles are reasonably neutral (as opposed to perfectly nuetral) , especially for a relatively new contributor -- its actually of better quality than what we get from most folks with specific background knowledge. I think we need to treat someone doing something like this as if they are learning the practices of our community: we are getting high quality content on topics that would otherwise not be covered. If you notice the less-than-neutral language, you should provide specific feedback, like you would with any other pattern of bias, either by: a) removing the text that is biased or being clearer about the attribution of that opinion (i.e. instead of "By diversifying its economy, Benin would reduce its reliance on fluctuating global market prices for commodities and create jobs for its rapidly growing population" "According to UNESCO, by diversifying its economy, the country of Benin could "reduce its reliance on fluctuating global market prices for commodities and create jobs for its rapidly growing population"); or b) using this as momement where we should be educating the new enthusiastic contributors, with specific and constructive feedback. However, that is no reason to institute additional policy/guidelines by rewriting existing policy/guidelines -- nor to assume that this practice of using open-license text is at the root of the problem -- rather this is a specific directed feedback concern. Sadads (talk) 13:56, 11 September 2017 (UTC)[reply]

Is UNESCO a neutral source? Given its makeup, I'm a bit dubious. Who actually wrote the text that was copied into the article? Doug Weller talk 18:21, 12 September 2017 (UTC)[reply]

I'm not sure that UNESCO is any less neutral than 1911 Britannica or the CIA World Factbook, say. So while I have some concerns about Science and technology in Turkmenistan they are more about the nature of the content, rather than the fact that material from UNESCO is being added. In my view the article as it stands is overly focused on the present government's policies, and doesn't quite have the tone of an encyclopedia article. That said, those are both things that can be addressed by working on the article. The Land (talk) 19:02, 12 September 2017 (UTC)[reply]
They can indeed be addressed, The Land, but Science and technology in Turkmenistan is only one of a number of such articles, and according to this news report, there are plans for more. It would be better to get these articles right from the time of creation, rather than us being left with hundreds of them to clean up. Cordless Larry (talk) 20:28, 12 September 2017 (UTC)[reply]
Well sort of - yes it would be nice for people to create only articles that are perfectly referenced and immaculate - but that has never really been the way Wikipedia has worked. I think in this case we need to consider whether the value being added by this initiative exceeds the hassle of any necessary cleanup. To that, I would definitely say yes... after all, we scarcely have any editors already working on topics like science and technology in developing countries, and as a result very little coverage of it. The Land (talk) 09:08, 13 September 2017 (UTC)[reply]
I'm not insisting that the articles need to be perfectly referenced and immaculate, just that they follow some of the basic rules of WP:NPOV. Cordless Larry (talk) 11:31, 13 September 2017 (UTC)[reply]

Other guidance that may be applicable is WP:COI. John Cummings, in residence at UNESCO, is apparently the main editor importing unedited UNESCO text. We could ask this editor to filter out UNESCO's opinions (such as assessing a president's commitment, speculating about the connection between "scientific literacy" and "democracy" or giving advice to the rulers in Benin), or at least set such opinions in quotation marks with in-text attribution (UNESCO's reports are a *primary source* for UNESCO's opinions, so the primary source-related guidance could come in after all). CIA views imported in Wikipedia by someone in residence at CIA have been rejected by the Wikipedia community before (and drastically removed – if I remember correctly even an IP-rangeblock was applied to prevent further editing from within the CIA's premises). So, I'd suggest to start with such filtering out of UNESCO's opinions ASAP. --Francis Schonken (talk) 12:10, 13 September 2017 (UTC)[reply]

What I meant to say with the previous paragraph is that there is a huge difference between a Wikipedia editor importing data from the CIA World Factbook (which was used as a commendable example above), and someone sitting at a desk within a CIA building and updating Wikipedia articles with opinions about the reliability of politicians and regimes from the CIA's viewpoint (which was cleanly and forcefully rejected by Wikipedia editors, being dragged to COI noticeboard and so forth). I'm not saying which one of the two situations is most comparable here, but was a bit alerted by the "in residence at UNESCO". --Francis Schonken (talk) 12:52, 13 September 2017 (UTC)[reply]

I think that Susan Schneegans is doing most of the importing, Francis Schonken. According to her user page, she is the editor of the source material is being imported from. Cordless Larry (talk) 12:56, 13 September 2017 (UTC)[reply]
Imagine this had been brought up at WP:COIN instead of here where it was connected to the less applicable NOFULLTEXT guidance: by this time John and Susan would probably have been in the phase where they would have been begging to get their user rights back... So I'm happy it was brought up here (COIN can be a bit hit-first-think-later). Nonetheless: John and Susan, please consider the filtering I proposed above (and commit to it explicitly), or this will predictably, almost unavoidably I'd say, be sorted as a COI sooner or later. --Francis Schonken (talk) 13:16, 13 September 2017 (UTC)[reply]
 – Pointer to relevant discussion elsewhere.

Please see "Wikipedia talk:Manual of Style#Merge draft WP:Naming conventions (identity) to MOS:IDENTITY?", a proposal to merge perennial draft material at WP:Naming conventions (identity) to the WP:Manual of Style in one way or another (probably a section at MOS:BIO), since it is a draft style guideline with almost nothing in it that pertains specifically to article titles (i.e., it is not a naming convention).  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  07:47, 11 September 2017 (UTC)[reply]

Wikidata descriptions still used on enwiki

After Wikipedia:Village pump (proposals)/Archive 138#Rfc: Remove description taken from Wikidata from mobile view of en-WP, the Readin Team from the WMF told us that "we have decided to turn the wikidata descriptions feature off for enwiki for the time being."

This turns out to be untrue: online one specific instance of this (standard mobile view) has been turned off, other mobile views (through the Android app c.s.) and other uses of this Wikidata description on enwiki (search, related articles, ...) have not been turned off. Apparently we should have known that the Reading Team is not responsible for what happens for our readers through other channels like the Android App.

The Wikidata descriptions are short, unsourced descriptions of the subject, which are shown in our articles but don't appear in e.g. the history of the article. You can find changes to it by turning on "Wikidata" in your watchlist options, but this also includes tons of unrelated and/or very cryptic changes in your watchlist. The end result is that very little people actually look at these Wikidata changes and patrol them. Vandalism on these descriptions, which is instantly visible to our readers at enwiki, remains unchecked for hours. Only a handful of people patrol this, meaning that such vandalism often remains for hours or days. I don't blame those people who do patrol this, as they are doing a valuable job; however, as a community, Wikidata is not ready or willing to deal with this adequately.

Examples of vandalism or at least poor such edits from today include Margaret Qualley, called a bitch today for more than four hours[4]; Moulden, Northern Territory, an Australian suburb which suddenly had a terrible crime rate for 10 hours[5], and the nasal cavity, which for thirteen hours was described as Jjhghh[6]; Prince, hardly an obscure, unwatched article, was changed from a "singer" to a "pop" in his description 6 hours ago and not corrected at the time of writing[7].

Other BLP violations (like a Mexican actress who suddenly was labeled a swinger for 7 hours([8]) luckily never made it here because we don't have an article on them yet...

Vandalism also happens here, of course, but at least it is usually spotted and reverted faster, and we can deal with the offending editors (e.g. blocking) or protect the page. Page protection does nothing against changed at Wikidata, and people banned at enwiki are happily editing Wikidata.

Do we really need a new RfC to confirm the very poorly implemented consensus of the previous RfC, or can we just state that the WMF should fully respect the previous RfC and the promise they made there in closing, i.e. remove the use of Wikidata descriptions anywhere on enwiki? @OVasileva (WMF): as the WMF editor who made that commitment. Fram (talk) 14:36, 11 September 2017 (UTC)[reply]

Olga has replied to the ping. CKoerner (WMF) (talk) 18:12, 11 September 2017 (UTC)[reply]
  • It actually seems better to have a "short description" editable on Wikidata than to automate things (PageImages used to automatically produce an image for a page, something that should have human oversight). While Wikidata editing should be integrated more closely with the client wikis (for example, Popups could help me to view Wikidata diffs in my watchlist; Wikidata edits shouldn't behave differently from others in an "integrated" watchlist), I am also really tired of this anti-Wikidata crusade. The wiki spirit is fixing things, not turning everything off because it doesn't quite work yet. What I am missing, though, is a concerted effort to gain editors for Wikidata (it is not currently a particularly inviting place). —Kusma (t·c) 14:54, 11 September 2017 (UTC)[reply]
  • Wikipedia itself has plenty of problems, hence the need to fix. Morphing another project that simultaneously relies on WP and also feeds into it is just madness and, well, circular. That's why I am not surprised if there are indeed people on some sort of crusade against it, just like they crusade against Commons.
FWIW, unticking the Wikidata box on my watchlist doesn't alter what is shown. (Firefox 55.02 on Ubuntu 16.04). - Sitush (talk) 15:04, 11 September 2017 (UTC)[reply]
  • (ec)"Fixing things", as suggested at the RfC, would mean creating a cross-wiki template which every language would fill, maintain, ... where needed for their own language, and which would be a part of the actual article, using the actual existing interface (watchlist, undo, block, ...) while producing the same end result in mobile view, searches, ... This (a language-dependent text based on the language-independent Wikidata, combining essentially the worst of both worlds) is not the way forward, and spending time on polishing this turd is not "the wiki spirit" but a desparate attempt to push Wikidata without any concern for what is actually best for our readers and for the editors here. "A concerted effort to gain editors for Wikidata" may be the subject of a different discussion, but doing this by forcing editors to watch and edit two sites instead of one (or three instead of two if you add Commons), where the new one has a different structure, culture, ..., seems not the way to go. Fram (talk) 15:05, 11 September 2017 (UTC)[reply]
The stand-alone App has its own development team that is unrelated to the mobile view as I recall, so its unlikely without WMF-top down management getting involved, that anything could be changed on the App end as a result of an RFC here. RE Kusma, it has come up before that Wikipedia would like short descriptions (which are not in themselves a bad idea) to be editable and controlled by Wikipedia, because our policies on verifiability etc, as well as the base editor numbers, mean that a)its less likely to have unspotted vandalism, b)anything that is will be picked up earlier. There is the related issue that the description on wikidata could be in fact sourced and verifiable (from Wikidata's perspective), but be completely out of line with what our policies require. Do you want to guess what will happen if we start deleting information from Wikidata because its causing a BLP violation on a wikipedia article being displayed on Android/iPhone? I am starting to think that essentially we need to migrate enough editors to Wikidata to *enforce* Wikipedia policies on it given the WMF's push to integrate it into everything.
RE Sitush: The comparison with commons is really a different kettle of fish. A lot of the complaints about commons are about the scope of the material contained there, not the useability of the material. Their policies are actually stricter than we allow for on ENWP. So essentially almost anything on Commons is useable in an ENWP article as long as it is in scope. The same cannot be said of Wikidata, because their basic inclusion policies are non-existant. Only in death does duty end (talk) 15:11, 11 September 2017 (UTC)[reply]
There is no way you can enforce Wikidata to "*enforce* Wikipedia policies". First of all, you probably mean "English Wikipedia policies". The Wikipedia in a default language is indeed the biggest WMF project but by far not the only one, and I am very happy that the vast majority of Wikidata admins and active users are monolingual. There is no way one project can enforce their policies on another project. Concerning deleting clearly wrong data - well, Wikidata has edit summaries, and as soon as these are used to explain that the data are clearly wrong, I do not see much of a problem and would in fact welcome this activity on Wikidata. Specifically for vandalism, it is much more productive to revert it to the last non-vandalized version, which only requires an extra click, but even just removing it would be a progress. The main problem of Wikidata is that it is severely understaffed, and indeed users who patrol changes just do not have the capacity to track all of them in real time (it currently has 39 thousand items).--Ymblanter (talk) 15:25, 11 September 2017 (UTC)[reply]
Yes, Only in death, I am aware that the causes of the pushback are different. But, still, people are pushing back. As it happens, and ignoring the content issues re: "porn" etc, I don't think Commons is particularly good at containing a bad situation - copyright violations are legion. En-WP certainly has problems, and Wikidata has a ton more than both. - Sitush (talk) 23:08, 11 September 2017 (UTC)[reply]
Want to bet? 50 more users could have swung the last RFC on Wikidata into having something *approaching* a reliable source/BLP policy. If the complaint is about 'there are not enough people', well if you want more people I am more than happy to rustle up some, but be warned the first goal will be to put in place policies to make wikidata useable on ENWP. I and other editor's don't want to do this because everybody hates canvassing and laying down ultimatums, but wikidata is swiftly heading towards the point where it, as a project, willingly puts acceptable policies in place, or it will be excluded from any relationship with ENWP. Which obviously will put a cramp in the WMF's and the small number of Wikidata user's plans. Only in death does duty end (talk) 16:08, 11 September 2017 (UTC)[reply]
You may be sure that as a Wikidata crat I will just cross out the votes which were clearly canvassed, this happened in the past though not so often. But if someone wants to work on Wikidata on a somewhat regular basis, even if this work is just removing statements which are obviously wrong, they are clearly welcome, and their opinions on RfC will clearly be taken into account.--Ymblanter (talk) 16:15, 11 September 2017 (UTC)[reply]
(edit conflict) @Only in death, if you rounded up a bunch of en-wiki people who weren't active on Wikidata to try to sway one of their RFCs, it would almost certainly be declared null-and-void and everyone involved blocked. As a thought experiment, what would your reaction be if POTW canvassed a bunch of his friends to set up accounts on en-wiki and vote to abolish WP:BLP or WP:RS? How would the process in the opposite direction be politically or ethically any different? If Wikidata is causing serious problems, the solution is to cut Wikidata loose until they fix the problems of their own volition, not to arrange an invasion by a coalition of en-wiki and commons and try to run it as an occupied territory. ‑ Iridescent 16:15, 11 September 2017 (UTC)[reply]
Well quite, which is why I expect the end result that it will be (attempted) cut off entirely. One of the main complaints from the wikidata crowd is that not enough people want to join the project. People (from ENWP) are not actually interested in joining the project because its base aims are off-set from what wikipedians want to do. The fact that the average wikipedian is accustomed to much more rigorous sourcing requirements doesn't seem to trigger the thought at all that they might want similar standards. In answer to your thought experiment, I have no ethical problems with enforcing standards on a project that is currently (through technical means and the WMF's 'enhancements') enforcing its content onto ENWP's articles without the same level of scrutiny. If we are required to have it encroaching into ENWP content, then it should be required to meet the same standards as anything on ENWP. I have no political or ethical problems with that upsetting people whose walled garden gets a bulldozer from the street to make that happen. I would still vastly PREFER to cut it off entirely, but if we have to go through a fucking humongous bitch-fest with the WMF to do so (as per visual editor, superprotect), it will be extremely contentious discussion. The simplest solution would be for Wikidata to adopt stricter standards than all the projects require (thus satisfying every language's requirements) much like commons, but there is little inclination or indication that will happen. Ever. Only in death does duty end (talk) 16:28, 11 September 2017 (UTC)[reply]
Why do not you fork Wikipedia then? There will be no WMF, no Wikidata, and, actually, no need to have Wikidata.--Ymblanter (talk) 16:40, 11 September 2017 (UTC)[reply]
So your solution to 'ENWP has issues with Wikidata having huge sourcing problems' is not 'fix Wikidata' its 'Fork ENWP so you don't have to deal with Wikidata'. And you wonder why I think the wikidata crowd have no inclination to do anything. Only in death does duty end (talk) 16:44, 11 September 2017 (UTC)[reply]
Not really. You just seem to be unhappy with the existence of WMF and existence of Wikidata. You generally do not care a fuck about other projects, except for may be Commons which provide images - but images could also be uploaded locally. However you have no problems with using servers they provide and using the code they have written (you are not a developer, are you)? I would guess just fork and be done with it.--Ymblanter (talk) 16:51, 11 September 2017 (UTC)[reply]
By the way, it is of course useful for the sake of the argument to label me as a part of the "Wikidata crowd", however just to note that here, on the English Wikipedia, I happen to have made approximately 15 times more edits that you have.--Ymblanter (talk) 16:53, 11 September 2017 (UTC)[reply]
@Only in death: I think you are probably right that the motivation for (some) Wikidata editors is indeed "off-set from what wikipedians want to do". When I am editing on ENWP, my focus tends to be at the individual article level, with the aim to make that article as clear and accurate as I can: my enemies are inaccuracy and unclarity and punctuation-inside-quotes, and I want to root them out. On the other hand, on Wikidata my key motivation is improving the results that I and others can get from queries, at scale (in part to make possible a project to upload with proper categorisation several tens of thousands of map images to Commons). As part of that I can accept a certain degree of unreliability in the data -- to some extent it's inherent in handling any data at scale, to some extent it's part of being a wiki, to some extent it's simply part of how Wikidata has been built up. Of course I'd like the data to be as good as possible, but what I *need* is "good enough to be usable". For the applications I have, better coverage and completeness may be worth some unreliability -- if I know the data may have some unreliabilities, I can treat it as such, and try to filter or cross-check or improve it. But I can't filter hits from my query if I don't get hits at all. So yes, it can be a different mindset, with a different set of balance of advantage compared to WP when it comes to false-negatives (data that's not there) against false positives (data that's not right). To some extent it can be the perspective of search -- we can accept some bad search hits, but the priority can be making sure we get the good search hits. That's probably reflected in Wikidata's attitude to unsourced data: sourcing is valued; but unsourced data is better than no data at all; and then it can be up to users to decide what level of sourcing they need, depending on their application.
I think there seems to be a panic here, that some seem to have about Wikidata, which in my opinion is overblown. Realistically, data from Wikidata is only going to be visible in a limited number of templates, most of which will have no BLP-type risk at all. Yes, Wikidata is a wiki, it's not 100% reliable; it may even as a project not have reliablity focus as Wikipedia. But fundamentally, from the article perspective, it's just a different place to store some of the data. The key thing is for tools and processes to be able to minimise the practical effect of the data happening to be in a different place -- eg so that changes ping watchlists and vandal-screens as one would want, but don't swamp them. It's also possible to write templates so that changes on Wikidata don't automatically change article text, but merely lead to a discrepancy being pinged, triggering a hidden category that can then be investigated.
On the other hand, for some templates it is far easier to manage the data centrally on Wikidata. Consider for example {{Art UK bio}}. The URLs at Art UK are mostly stable. However, they change unpredictably (without any redirects) if Art UK changes either the name or the birth date or the death date of the painter. So they need to be checked regularly. With the data on Wikidata, I can get the full set of the current links with a query in 30 seconds, which I can then feed to a URL-checking script. But if the data is on Wikipedia, I need to run a scraper over all the template instances, just to get where the templates currently point to. Having found out which URLs are broken, and tracked down new values for them, on Wikidata I can update them simply by cutting and pasting from a spreadsheet to a tool called Quick Statements, which will update the statements on Wikidata and the process is all done in a couple of minutes. But if the data is stored on Wikipedia, I would need to write (and get approved) a bot to update each of those template statements. For a job like this -- a large set of (uncontroversial) external links -- having the data held systematically on Wikidata makes it far easier to manage and to check and to keep correct. As well as meaning every other language Wikipedia also gets its links updated as well. For content like this, central management really does make sense. Jheald (talk) 18:40, 11 September 2017 (UTC)[reply]
  • Comment - I have the impression that since descriptions are article as well as language-specific so closely bound to articles, a solution may be to provide an optional template allowing to add those at the top of articles (i.e. {{description|1=...}}). Internally it would not matter how those were processed/cached/displayed/stored (including on wikidata), but the source would remain directly as part of the article and managed/patrolled by the same language-specific project editors... —PaleoNeonate16:21, 11 September 2017 (UTC)[reply]
  • Comment Short descriptions are something we need for mobile. They need to be stored somewhere. A more productive focus (IMO) for this conversation would be: what is the big deal about those descriptions being stored on Wikidata rather than in a field in some non-visible template here -- can we identify what the issues are, and can we fix them, so that it doesn't matter where the descriptions are held ?
- The most important issue (again, IMO) is whether changes to the descriptions get shown in an efficent and useful way in Watchlists and edit-patrolling tools here. (ie: so that the tools pick up all the changes that are relevant, but without getting swamped by all the changes that are not relevant.)
- A second issue is that many of the current short descriptions on Wikidata may not be very good. (But they are usually better than nothing).
- A small third issue is that sometimes the descriptions contain Wikidata "use notes", that really ought to be separated off to a different field.
Wikidata needs short descriptions anyway -- they're generally just what you may want to be able to return in a query to give a brief description of the item retrieved; they're the basis for disambiguation on Wikidata; and they give Wikidata editors useful brief (< 10 word) orientation of what the item is about. So that's why the descriptions are valuable from the Wikidata side. I would suggest that they are also rather more visible (and accessible at scale) on Wikidata than they would be in blind Wikipedia template fields.
To me it would seem to make a lot of sense for the editing efforts of both communities to be combined to refine a single set of descriptions, rather than quality being lost by efforts being diffused. As I said, I don't see why it should matter where the data is stored, so long as the tools are aware of it, and it can be properly policed. Am I seeing this correctly, or is there something I have missed? Jheald (talk) 16:56, 11 September 2017 (UTC)[reply]
FYI, we had invisible templates before Wikidata existed (can't remember their name currently). After giving Wikidata the opportunity to harvest these invisible data, the invisible mainspace content was systematically removed (after a slow and somewhat painful process of finding consensus on how to do that). --Francis Schonken (talk) 17:07, 11 September 2017 (UTC)[reply]
WP:Persondata is the only one I know of which was invisible. --Izno (talk) 17:14, 11 September 2017 (UTC)[reply]
Yeah, that's the one I had in mind. --Francis Schonken (talk) 17:17, 11 September 2017 (UTC)[reply]
Jheald, I think what you're missing is that there appears to be little interest from most enwiki editors in engaging with Wikidata as you describe. It's probably true that if a large number of enwiki editors began editing Wikidata enthusiastically, many problems would go away. The learning curve for Wikidata is slow to climb, however, and I suspect many content editors here don't want to do what feels like gnomery. I'm an IT professional and have no problem with the complexity, but I want to write articles. I don't want to keep an eye on a database to make sure the articles I write don't get messed up -- or if I do have to keep an eye on it, I don't want to go to another website to do so. One watchlist is plenty (and turning on Wikidata in one's watchlist is unfortunately not very helpful). I see little likelihood of the WD editing community growing to a size that would resolve this, nor of the editing environment becoming integrated between the two. Without one or the other of those, I don't see this conflict being resolved. Mike Christie (talk - contribs - library) 17:23, 11 September 2017 (UTC)[reply]
@Mike Christie: Good point, Mike, but then this is what some of what is proposed (that seems to be making people come out with the torches and pitchforks) is actually supposed to make easier -- so, an edit box so that people can edit "short descriptions" without leaving Android; a facility to make editing possible through templates, so that people can fix facts without ever having to go to Wikidata, without leaving Wikipedia.
To me, the key issue that I think most needs to be fixed is getting the Watchlist (and vandal-fighting) integration much much better. What I think would make all the difference is to be able to see any change that alters the output HTML of a page -- and not to see any change that doesn't. And for the page-history by default to show any edits that changed the output HTML -- whether the data was changed through a Wikipedia edit or a Wikidata edit -- without showing changes that eg only affect other languages, or indeed no wikis at all. And for the line in the history to have an "undo" button, that undoes the change, regardless of where it was made. And for anti-vandal tools to be similarly agnostic as to whether the data happens to be stored here or happens to be stored on WD.
I think WD will be more accepted when for practical purposes it no longer matters whether the data happens to be stored here, or happens to be stored on WD. I think it's been clear for at least 18 months that this was a major issue that needed to be a priority area for development. I hope that, going forward, it now will be. Jheald (talk) 18:19, 11 September 2017 (UTC)[reply]
Jheald: I agree that those things are probably prequisties for people to stop caring about this issue; there are probably more, though. I suggested here a list of issues that would have to be resolved, drawn from the discussions on that page. I'm undecided on several of those issues. One I think is very important is having a unified, clear, comprehensible watchlist. Without that it seems to be too hard to keep an eye on what's going on with the articles one watches. Mike Christie (talk - contribs - library) 18:54, 11 September 2017 (UTC)[reply]
It will probably never be resolved. It is unfortunate though that people do not see obvious things. Wikidata was originally created not to provide descriptions for Android. The two immediate goals were (i) to centralize interwiki links (ii) to centralize some sorts of info. For example, we have a lot of information here, on the English Wikipedia, about mayors of obscure Ukrainian towns. This info is typically unsourced and is almost always outdated. Nobody here has issues with it. However, on Ukrainian Wikipedia this info is up-to-date and sources to (unsuprisingly) Ukrainian language sources. There is nobody here who updates the English Wikipedia info on a regular basis, but Wikidata is updated, and often has sourced statements. And this is exactly why it was created. However, an idea that this info can be propagated further to the English Wikipedia meets almost universal opposition, because Wikidata has a different verifiability standard. And, not suprisingly, nobody cares about what data we have here.--Ymblanter (talk) 17:34, 11 September 2017 (UTC)[reply]
Re. "...not suprisingly, nobody cares about what data we have here" – maybe, as a first step, stop insulting the people you'd rather be trying to charm. For the mayor of an obscure Ukrainian town I think readers should rather go to Wikidata (knowing they're not on en.Wikipedia any more), than being presented, in en.Wikipedia, some data of unclear origin with little or no possibility to subject to a normal WP:VERIFIABILITY vetting. --Francis Schonken (talk) 18:14, 11 September 2017 (UTC)[reply]
(By your logic, I am insulting myself). The data on Ukrainian mayors is in the English Wikipedia, and is of very poor quality. Check Kropyvnytskyi as a typical example: the mayor in the infobox is unsourced, it has never been sourced as far as I can see, and I see no mechanism how this one would be replaced with the next one when he retires or does not get reelected. Indeed, this is clearly contrary to our verifiability policy and even WP:BLP (may be the person is offended to be called mayor), but nobody hurries to enforce these policies. Wikidata btw does not have a mayor for this city, and in this sense it is better verifiable than the English Wikipedia.--Ymblanter (talk) 18:22, 11 September 2017 (UTC)[reply]
So your example is just a red herring. You don't seem to care about the mayor of that town, nor here, nor at Wikidata. In sum: charm = zero for trying to illustrate convincingly this would somehow necessitate Wikidata to override the WP:CIRCULAR policy. --Francis Schonken (talk) 19:44, 11 September 2017 (UTC)[reply]
To be honest, I do not see any connection between you write and what I write, and I do not feel like trying to convince people who already have a strong opinion on the subject. I suggest we stop the discussion here. He that hath ears to hear, let him hear.--Ymblanter (talk) 19:52, 11 September 2017 (UTC)[reply]
I would love to see more data stored centrally (say, on Wikidata) so it can be easily updated on all Wikipedias, and everywhere that some data is used. When a city's mayor or population changes, wouldn't it be nice not to have to find all of the lists that mention this and manually edit all of these pages? (The German Wikipedia solves the population problem by an elaborate and somewhat confusing system of templates; instead of duplicating effort/templates, maybe we could do that centrally?) The main problem is I don't know how to use Wikidata for this, and barely understand its function for interwikis (finally found out today that there is an interwiki problem resolving mechanism, which is backlogged for a rather unflattering couple of years). Is there a tutorial somewhere? c:File:An Ambitious Wikidata Tutorial.pdf isn't one that tells me what to do (other than to build Wikidata without immediate benefit to Wikipedia). The explanation on Wikidata, d:Wikidata:Introduction, tells me I can access the data using a "Lua Scribunto interface", which is linked to mw:Extension:Wikibase Client/Lua, a page that mainly tells me I am not part of the intended audience. There seems to be room for improvement. —Kusma (t·c) 20:10, 11 September 2017 (UTC)[reply]
I am also not a tech wizard, but I think it can be done reasonably painlessly, and even with control over the sources which Wikidata uses for such statements. If there is consensus that this information can be used here (either shown directly via templates, or transferred by bots on a regular basis), one can ask on Wikidata how it could be implemented.--Ymblanter (talk) 20:26, 11 September 2017 (UTC)[reply]

One major weakness I find with Wikidata is that there is no clearly marked place for newbies or non-technical folks to ask questions. One issue I've been wanting to bring up there is the fact that the office of Roman consul is almost always occupied by two people, however the data object for it over there does not allow me to intuitively indicate colleagues of consuls. Although there appears to be something similar to the Village Pump over there ("Project chat"), lurking there leaves me the impression it is the domain of techies talking to other techies; much like reading a mailing list on Open Stack for the first time. Also I know from experience techies can be very dismissive about newbies' questions. (And I don't want to explain a thousand years of Roman history in a few paragraphs in order to prove I know what I'm talking about in order to learn how to add a freaking field.)

I'm not bashing Wikidata, mind you. I can see the potential it has for Wikipedia. It's that considering it as a project, it's still very user unfriendly -- unless you are one of the people who are deeply into it, & willing to figure out all of its bits & pieces. (It took me a week to figure out how to add the information that a given fact came from en.wikipedia. And I've spent the last 20 years making a living working with computers -- I can only wonder how daunting it could be for someone not technically inclined?) -- llywrch (talk) 22:16, 11 September 2017 (UTC)[reply]

@Llywrch: On the consul point, it looks like Wikidata could use a new qualifier property, "held office with", that could be attached to the statement "position held:" "consul", "start time:" "date", "end time: date".
Wikidata is still quite a young project, and one of its characteristics is the ability to quite easily extend the data model in this way, to capture relationships which are not yet modelled well. So ultimately what one would do would be propose something like "held office with" as a new property to add, at d:Wikidata:Property proposal/Organization. The proposal would then be open for discussion, as to whether this is indeed the best way to capture the relationship, or whether there's a better way or something else could be re-purposed or whether a slightly different approach might be more general or flexible. But if nobody raises any counter-suggestions, usually a new property like this would be approved in a couple of weeks, and then data could start being loaded.
That's the formal procedure for proposing a new property (like an RfC); but of course it makes perfect sense to see what people think more generally first in a less formal way, by first raising the issue at eg d:Wikidata:Project Chat or d:Wikidata talk:EveryPolitician or d:Wikidata talk:WikiProject Heads of state and government. Yes, much of the discussion on any of those pages can often get quite technical, with people thrashing out the detail of quite fine points of how to model things. It's a fair point that Wikidata needs better support for new editors, and perhaps an equivalent of en-wiki's WP:Teahouse. But there's a lot of good will, with editors committed to helping other editors solve problems and improve the data -- if somebody wants to know how to do something on Wikidata, or how to model some relationship, they will get taken seriously, and people will do their best to help. Jheald (talk) 09:30, 12 September 2017 (UTC)[reply]
@Llywrch: I've opened a discussion on how to best indicate the other(s) of a set of joint office holders at d:Wikidata_talk:EveryPolitician#Joint_office_holders Jheald (talk) 21:48, 12 September 2017 (UTC)[reply]
@Llywrch: So it turns out that there is already a Wikidata property used for this, d:Property:P1706 ("together with"). The data is still rather under-populated, but here's a query to show the consuls for whom there is currently another consul specified: tinyurl.com/ybhqb7ep (hit the big blue button at the mid-left to run). You may want to kill the "query helper" bit of the code display, which isn't very helpful. Apologies for the over-precision in the date shown - this is a known issue with the query service which it's tricky to make combine data held in two different fields (date, date-precision) in its output. Remove the '#' (= comment) signs around the "OPTIONAL" bracket at start of lines 8 and 10 to get the full list of people currently recorded on Wikidata as having been a consul. Or click on any of the Q-numbers in the first results column to see how the data for the person has been entered on Wikidata. Hope this helps! Jheald (talk) 09:27, 13 September 2017 (UTC)[reply]
According to a considerable group of Wikimedians, complex interfaces are a great way to proof a user's 'competence', because it shows that people are really very committed to participating and have moderate intelligence. So it's probably a feature Wikidata considered worth copying from their predecessors. I'll leave it up to you to decide how this reflects on you and/or that line of reasoning... :) —TheDJ (talkcontribs) 22:46, 11 September 2017 (UTC)[reply]
According to my notifications, I've made a shed-load of edits to Wikidata when, to my own knowledge, I've made none at all. That perhaps is something to do with the WMF legals and attribution but it is confusing and not appreciated. - Sitush (talk) 23:11, 11 September 2017 (UTC)[reply]

RfC: exceptions to WP:CIRCULAR allowable for Wikidata?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Should an exception be inscribed in WP:CIRCULAR (and/or other parts of the WP:VERIFIABILITY policy), and/or in the WP:RS guidance, that would allow Wikidata information, which may have originated from en.Wikipedia, from a Wikipedia in another language, or may be user-generated at the Wikidata website itself, to be (re)inserted in en.Wikipedia? And if so, at what level and/or under which conditions?--Francis Schonken (talk) 20:09, 11 September 2017 (UTC)[reply]

Discussion

  • No, not under any guise or format. --Francis Schonken (talk) 20:09, 11 September 2017 (UTC)[reply]
  • I see no reason to treat Wikidata differently from Wikipedia: we copy information all the time (just like when we translate articles from other Wikipedias), but we use external reliable sources for verification. We should encourage sourced content to be copied between wikis, and discourage unsourced content being copied. —Kusma (t·c) 20:16, 11 September 2017 (UTC)[reply]
  • Comment This is a badly formulated RfC by a biased user. Obviously Wikidata should not be treated any differently from other WMF projects. However nobody ever suggested to use it to overcome WP:CIRCULAR. As far as I know nobody reinserts unsourced user-generated content into Wikipedia, and this is not a real issue. The real issue is what Wikidata content can be actually used in Wikipedia and what are the best practices to use it. This RfC does not attempt to answer this issue.--Ymblanter (talk) 20:21, 11 September 2017 (UTC)[reply]
  • Comment. I'd suggest withdrawing this. Wikidata is sufficiently contentious that launching an RfC without prior discussion is likely to be unproductive; and the community only has patience for so many RfCs on the topic -- we should agree what the key issue is before starting an RfC. Mike Christie (talk - contribs - library) 22:35, 11 September 2017 (UTC)[reply]
  • Comment - malformed RfC. You may get comments but you won't get results. - Sitush (talk) 23:13, 11 September 2017 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

RfC: Description field from Wikidata in any view of en-WP

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Re-stating this RfC from March of this year, which asked Do you support the following statement: "The description taken from Wikidata that is currently being loaded in mobile views of en-WP pages, must be immediately removed from mobile views of en-WP pages".

The WMF were at that time including the description field from Wikidata in other views of en-WP content (the Android and iOS apps, at least), and continued to do so after the RfC closed.

Do you support the following statements:

  1. The description taken from Wikidata that is currently being added to any mode of viewing en-WP pages and that is published by WMF, including the Android and iOS apps and the mobile view, must be immediately removed and must not be restored without obtaining prior consent of the en-WP community via an RfC here at VPP.
  2. The staff of WMF who continued publishing the Wikidata description field in the apps after the March RfC had been closed, have ignored the clear sense of the en-WP community that there were governance problems with their deciding to do this, and serious issues with violations of en-WP's BLP and Verify policies being published in a way that made them appear to be en-WP content, produced by the en-WP community.
  3. The staff of the WMF responsible for the continued publishing of the Wikidata description field in views of en-WP content in the android and iOS apps and any other views of en-WP content after the March RfC closed, are hereby banned from en-WP, with a standard six month offer. (we can figure out who that is, exactly, if this is "yes") Jytdog (talk) 00:40, 12 September 2017 (UTC)[reply]

!votes (description field RfC)

Discussion (description field RfC)

  • The principles that we stated in the March RfC obviously generalize to any view of en-WP content. That apparently needs to be made explicit.
I don't know who the individual(s) is/are who made the decision to ignore the March RfC with regard to the views on the apps (and any other views of en-WP content). I imagine others can identify them easily. But in my view, individuals who so blatantly ignore the consensus of this community have no place in this community, as long as they continue to violate WP:CONSENSUS, WP:BLP, and WP:V this way, and as long as they continue to act as though the WMF's role is to make decisions about content. Jytdog (talk) 00:53, 12 September 2017 (UTC)[reply]
It appears that it was a misunderstanding. Ovasileva's explanation seems plausible to me. Since they have already said they are planning to make an additional response, I would suggest waiting for that as point 1 of this RfC may be unnecessary depending on that response. I think your points 2 and 3 should be separated from any RfC on Wikidata in any case, even if you don't believe OVasileva's statement. I'd add that I think banning is a sufficiently major penalty that we should not hold an RfC to ban someone that says we'll figure out later who it is we're going to ban. Mike Christie (talk - contribs - library) 01:30, 12 September 2017 (UTC)[reply]
The reasons en-WP people reacted as they did, were stated very clearly in their responses in the RfC. Please do read it. The BLP and V issues are made clear, as are the governance issues.
I cannot begin to understand how anybody actually reading what the community said in the RfC, and understanding it, could read it so narrowly as to apply only to mobile. The persistence in the apps, is either a blow off, or incompetence, as the issues are exactly the same. We ban people who severely harm content for either reason.
Opening up that incompetence thing a little - people who are given authority are trusted to know what they know and don't know, and to be sensitive to what they don't know that they don't know. If anything was unclear about the fundamental issues identified in the RfC, that should have led them to start a conversation to learn about them.
I don't know everything the WMF is doing with content. I am now aware that there is mobile, android app, and iOS app. I have no idea if there are more. I am uninterested in playing whack-a-mole. That is crazy, really.
They should not have been playing mixmaster with content anyway, and their lack of understanding of the problems it causes just underlines that.
This whole RfC is meant to put a very very bright line around that.
I made the points separate so they would be !voted on separately. Do as you will. Jytdog (talk) 03:57, 12 September 2017 (UTC)[reply]
Jytdog, I am more than happy to help if necessary. However I request you withdraw this RFC for the moment. I would like to see what response we get from the WMF at WT:Wikidata/2017_State_of_affairs#Wikidata_article_descriptions. Parts of the WMF are as bad as ever, but some people there really are trying to do better. I agree their partial removal of descriptions was nonsensical, but it is possible they had tunnel vision. There's at least a chance that they'll be willing to clean it up amicably. We can ramp up the issue if we don't get a reasonable response soon. Alsee (talk) 04:53, 12 September 2017 (UTC)[reply]
OK, willing to pause this for now. Jytdog (talk) 05:48, 12 September 2017 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Further conversation

There's a response and follow up conversation to this topic happening at Wikipedia_talk:Wikidata/2017_State_of_affairs CKoerner (WMF) (talk) 13:08, 14 September 2017 (UTC)[reply]

There is an RFC about the capitalization of formal titles such as "Duke" and "King" (essentially, the question is when to capitalize and when to use lower case) that could use input from the broader community (I have already posted a request at the the peerage and baronage Wikiproject). Please see: WT:MOSCAPS#RfC on capitalization of job titles. Blueboar (talk) 14:41, 12 September 2017 (UTC)[reply]

RFC: "Exemption from WP:V" at Wikiproject Days of the year

There is a discussion underway at Wikiproject:Days of the year regarding whether to require direct sourcing per WP:BURDEN. At least one editor thought that a notice should be posted here to ensure we get broad consensus. Toddst1 (talk) 17:25, 13 September 2017 (UTC)[reply]

ACTRIAL Live

So that everyone here know WP:ACTRIAL just became active a few hours ago. It is scheduled to run for 6 months, followed by a month off, and then a community discussion to decide how to deal with new content created by new users moving forward. TonyBallioni (talk) 23:46, 14 September 2017 (UTC)[reply]

Here's to that. Even in my state of burnout, I enthusiastically applaud this move. The Blade of the Northern Lights (話して下さい) 01:38, 17 September 2017 (UTC)[reply]

Meta RFC on change to paid editing policy

Just a quick note, as this will have implications here. There is currently an RfC on Meta which will require paid editors to provide links from user pages to off-wiki details if they wish to edit. It may be of interest. - Bilby (talk) 04:47, 16 September 2017 (UTC)[reply]

Interesting detail on that page. Most of the oppose !votes have emojis bit none of the support !votes do. I wonder why? --Guy Macon (talk) 14:19, 16 September 2017 (UTC)[reply]
en.Wiki vs. meta practice. Most of the !voters there probably aren't that active on meta so they just followed our practice. TonyBallioni (talk) 14:28, 16 September 2017 (UTC)[reply]
But why would the support !voters be mostly people not active on meta while the oppose !voters are mostly people who are active on meta? Not that it matters, but I am curious.
On a more serious note, would it be worthwhile to see how many !votes are from SPAs? Paid editors might be motivated to stack the votes... --Guy Macon (talk) 14:48, 16 September 2017 (UTC)[reply]

Removal of speedy deletion tags by non-admins

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


TL;DR: only allow administrators to remove CSD tags except for nominator withdrawals or blatant bad-faith nominations.

Hello all,

I've recently had a few speedy deletion tags that I've put on articles removed by non-admins who aren't the page creator. The large majority of these have had to be prodded or taken to AfD with many of the !voters concurring with the deletion per CSD. The most recent case was on Wrong time where a completely invalid rationale for reverting was given by a particular user, who it would do me no good to mention by name, and I re-instated the CSD tag and left a note with an extended rationale on their talk page. An uninvolved administrator has since deleted the page under the speedy deletion criteria which I nominated it on.

The current CSD policy is unclear and only mentions removal by non-admins in passing when referring to the already-banned practice of page creators removing CSD tags.

My proposal is that the CSD policy should be changed to note that only administrators can decline speedy deletions except in cases of self-reverts by the nominator or blatant bad-faith nominations, for example this.

Thanks,

DrStrauss talk 21:30, 16 September 2017 (UTC)[reply]

  • This seems reasonable, since a CSD tag is supposed to bring a page to the attention of an administrator, it seems counterproductive to remove them before this happens. (unless of course it is a bad faith nomination). Either way, this needs to be clarified. Α Guy into Books § (Message) -  21:36, 16 September 2017 (UTC)[reply]
  • Oppose Speedy deletion is for uncontroversial deletions only. The proposal would mean that all non-admins who oppose deletion need to contest the speedy deletion nomination in the same way that the creator of the page needs to contest the speedy deletion. A speedy nomination that is contested is by definition controversial, and will be declined. If you're looking for a better way to detect bad faith removals of speedy deletion nominations, this is not it. Mduvekot (talk) 21:59, 16 September 2017 (UTC)[reply]
  • Oppose there are good reasons that good faith contributors who are not admins can remove a CSD tag from an article. I've saved several articles that others have hastily tagged during NPP from deletion, and the majority of them are from non-Anglophone regions. I fear this exact proposal would increase systemic bias on Wikipedia by making it easier to delete needed articles in non-Anglophone majority regions, and would be a net negative on the content front, which is the most important part of the encyclopedia (its why we are all here).
    That being said, there is at least one user who is on a de facto topic ban from removing CSD tags(this user agreed to stop removing tags because the other option was WP:AN to get a formal topic ban). There is a rough consensus in the community. If a non-admin is disruptively removing tags in a way that is causing more work for other users in a way that is seen by the community as harming Wikipedia, we have a means to stop it: a topic ban discussion at WP:AN (not ANI). To my knowledge this has really only been an issue with one or two specific users, and we've managed to avert formal sanctions. If a user keeps disruptively removing CSD tags, discuss it with them, and if there is a general consensus amongst users who are active at NPP or AfD that their actions are harmful, take it to AN. This allows Wikipedia to grow while having an option to prevent disruption in certain cases. TonyBallioni (talk) 22:04, 16 September 2017 (UTC)[reply]
  • Oppose - at first blush a reasonable suggestion, but actually a solution looking for a problem. Kudpung กุดผึ้ง (talk) 22:24, 16 September 2017 (UTC)[reply]
  • Oppose when someone A7s a book, I expect the first patroller who knows better to revert the CSD tag, even if they are not an administrator. Patrollers make mistakes, administration shouldn't have sole responibility for cleaning those mistakes up. — InsertCleverPhraseHere (or here) 22:37, 16 September 2017 (UTC)[reply]
  • Oppose--Per Tony.Winged Blades Godric 02:59, 17 September 2017 (UTC)[reply]
  • Oppose - per what everyone's already said here. Ivanvector (Talk/Edits) 03:02, 17 September 2017 (UTC)[reply]
  • Oppose It is an absurd idea that "good faith" mistakes made in CSD nominations are always spotted by a deleting admin. List of fictional characters with disabilities was in main space when nominated for WP:G13[9] (only applicable for draft and user space) and was then speedy deleted.[10] Our deletion procedures can be careless and it requires careful editors to prevent bad deletions. Thincat (talk) 14:56, 17 September 2017 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

RfC: Should the WP:TALK guideline discourage interleaving?

Opinions are needed on the following matter: Wikipedia talk:Talk page guidelines#RfC: Should the guideline discourage interleaving?. A permalink for it is here. Flyer22 Reborn (talk) 02:16, 19 September 2017 (UTC)[reply]

Proposal regarding WP:OR and terrorism

Problem:

  • Terrorism-related pages, especially lists of terrorist events, are plagued by original research and synthesis by editors. On list pages, often list entries are made where the source does not support the label of "terrorism" (recent examples: [11], [12], [13], [14], [15]). Other times, the mere mention that ISIL, Al Shabab, or the PKK are suspected appears to prompt editors to add events to the lists, even if terrorism isn't mentioned (e.g., [16], [17]). The issue here is the assumption that all acts by these groups are, by default, terrorism and not some other form of violence such as insurgency, guerrilla tactics, etc. This assumption, while perhaps often correct, still constitutes original research as it is the editor making the connection, not the sources. Currently, the lists of terrorism incidents address this latter issue by including "attacks by violent non-state actors for political, religious, or ideological motive".
  • Related, articles about events often are labeled "terrorism" without proper sourcing or prematurely. This prompted EvergreenFir to make WP:HOLDYOURHORSES because breaking news and first responders too often mislabel events in the initial aftermath. The mere rumor of someone hearing Allahu Akbar sends news reporters and editors into terrorism-labeling mode long before such information is verified by investigators. Examples are the initial reporting on 2011 Norway attacks and 2016 Munich shooting.

Possible solutions:

  • Address this issue by amending WP:OR to require:
  1. Reliable sources explicitly label an event or related individuals as "terrorism" or "terrorist" in their own voice or that Reliable sources report that some official related to the investigation of the event (e.g., mayor, police chief, government spokesperson) has used the label "terrorism" or "terrorist".
  2. Cases where terrorism is "suspected" should be labeled as "suspected" by Wikipedia as well until this suspicion is officially confirmed or denied.
  • A guideline be set regarding the lumping of "attacks by violent non-state actors for political, religious, or ideological motive" into terrorism-related articles and lists

Comments: We understand that carving out a specific topic for special attention in policy pages is undesirable to some editors. However, we believe this deserves special attention because of (1) the seriousness of the label "terrorist", (2) the persistence of the problem across multiple articles, and (3) the contentiousness of the topic vis-a-vis politics and religion. We already have discretionary and general sanctions related to this area (WP:ARB911, WP:ARBAP2, WP:TROUBLES, WP:ARBPIA, WP:GS/ISIL), demonstrating it is a perennial topic for disputes. As such we believe that this broad topic warrants specific attention by Wikipedia policy. The goal of this proposal is to provide clarity to editors and to establish a community norm regarding the application of the label "terrorism".

Signed, EvergreenFir and Doug Weller; Posted by EvergreenFir (talk) 02:01, 20 September 2017 (UTC)[reply]

Discussion - terrorism

Before consideration of any formal proposal occurs, I think this needs input and wordsmithing by folks. I'm open to suggestions as to where any such language should go (perhaps a guideline, add to WP:OR, or some other place I've not thought of). Should some consensus emerge, a formal proposal would be the next step I think.

I'm curious if people share my concerns about the automatic inclusion of any acts by "violent non-state actors". Currently, executions by ISIL are included on these lists. I'm personally on the fence about this, but if folks felt strongly one way or another, I think that's fine as long as we can clarify the position. EvergreenFir (talk) 02:01, 20 September 2017 (UTC)[reply]

I do have concerns that very frequently, right after an event like a bombing, that we do get reports "police are treating this as a terrorist event", which does not necessarily mean that the event will prove out to be terrorism-related (and we need to presume that "terrorism" without context means international terrorism as opposed to domestic terrorism). When law enforcement uses that language in the short-term and hours after the event, that means they gain special powers to quickly deal with the matter (eg [18]) but that should not mean to us that the event is a terrorism-related event. Calling something a terrorist event can only happen after arrests have been made or perps identified and their motives figured out, and far too often the media jump the gun on this. We shouldnt be trying to classify these events as terrorism for at least a day after the event and no earlier than until suspects are determined and preliminary motives worked out. --MASEM (t) 06:11, 20 September 2017 (UTC)[reply]
Hmmm. We call Juggalos terrorists at Juggalo gangs with citations to US government documents. Falun Gong is listed as a terrorist group by the Chinese government, but we don't mention this in their article (but we do quote someone accusing China of being practitioners as state terrorism because of how they have reacted to Falun Gong.) So if a government calls a group a terrorist group, do we include that information? If other governments disagree (as they do in the case of Falun Gong), do we include that? --Guy Macon (talk) 06:13, 20 September 2017 (UTC)[reply]
@Guy Macon and Masem: I agree with both of you. Guy Macon, you make a good point. Who gets to define a group as terrorist? Perhaps we need to leave it to just the sources, independent of the labels used by government officials and law enforcement? But that would mean the sources needs to use it in their own voice, not just quote someone. Or leave it to a third party like an NGO? EvergreenFir (talk) 06:37, 20 September 2017 (UTC)[reply]
Guy Macon We call Juggalos gangs criminal street gangs, not terrorists, and there's a bit there that looks like a BLP violation as it says someone was arrested for allegedly forming a terrorist group, but see this and this. So we have a paragraph in the article that makes it look as though there was a terrorist plot, but there was no such plot. This looks like an example of the problem. As for who, the Myanmar issue is interesting. Are all the people the government is calling terrorist actually terroists?[19] I don't know. Doug Weller talk 18:37, 20 September 2017 (UTC)[reply]
As Doug Weller noted above, he removed one of the places where we call (some) Juggalos terrorists[20] (good call on the removal, BTW) before claiming that "we call Juggalos gangs criminal street gangs, not terrorists". Yet the Juggalo gangs article still says "The other 10–15% make up the Juggalo subculture's criminal element, which has been linked to numerous crimes including extortion, murder, domestic terrorism, drive-by shootings, drug trafficking, arson, burglary, armed robbery, aggravated assault, and weapon offenses, and has been documented collaborating with a wide array of street and prison gangs" (Emphasis added). I just looked at the citations for that claim and could not find anything supporting either the "terrorism" claim or the 10–15% estimate. We need rock solid citations before claiming that 150,000 people are terrorists. --Guy Macon (talk) 21:32, 20 September 2017 (UTC)[reply]
If there is any place for this (or further need for it), it is not WP:OR but rather WP:BLPCRIME. Ultimately, what is said about some act of terrorism needs to pass that bar. If people are engaging in WP:OR, point them to that particular policy, remove or reword the offending material, and move on. --Izno (talk) 11:21, 20 September 2017 (UTC)[reply]
@Izno: BLPCRIME seems like a good place for cases of individual "terrorists". I think Doug Weller and I were suggesting something more broad because this is a perennial and frankly intractable issue. But perhaps specifying for individuals and pointing to OR in that specification would be enough. Doug might be able to explain the admin side more. EvergreenFir (talk) 18:05, 20 September 2017 (UTC)[reply]
I have a problem with relying on law enforcement sources when calling a group terrorists and especially with relying on law enforcement estimates for how many people are in the group. Law enforcement has every reason to exaggerate the problem, plus they pretty much only have information on those who are caught comitting crimes. Far better would be estimates from academics, especially sociologists. --Guy Macon (talk) 21:39, 20 September 2017 (UTC)[reply]
I don't know if sociologists would have better estimates than law enforcement in all cases. Some very reputable ones might, but plenty of sociologists seem to have the opposite bias to law enforcement these days; underplaying the problem in some cases to make minorities or members of certain groups look better. We should use a combination of the most reputable sources available (each case is different), and report on what they say, as usual. — InsertCleverPhraseHere (or here) 21:49, 20 September 2017 (UTC)[reply]
True, but in theory a sociologist will actually do a random survey with a defined methodology and publish it in a peer-reviewed academic journal before making a factual claim. A cop has absolutely no way to know how many law-abiding juggalos there are -- they are invisible to him -- and no way of estimating the total number of lawbreaking juggalos; he only sees the ones in his jurisdiction and he only sees the ones who get caught. --Guy Macon (talk) 22:08, 20 September 2017 (UTC)[reply]

Discussion at NSPORTS

Hello all. In an effort to finally resolve the never-ending and annoying GNG v SSG issue, I've proposed a revision of the NSPORTS introduction. The problem was the subject of a VPP discussion this year. You are all invited to take part in the discussion. Thank you. Jack | talk page 06:20, 20 September 2017 (UTC)[reply]

Two clarification RFCs at the Manual of Style

 – Pointers to relevant discussions elsewhere.

Comments sought at:

Both of these are follow-ups to rather lengthy prior discussions on the same pages.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  19:07, 21 September 2017 (UTC)[reply]

PS: This may also be of interest:

 — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  19:39, 21 September 2017 (UTC)[reply]

And this one (involves both WP:NOR/WP:RS and MOS:TONE/MOS:WAF concerns and how they interrelate). It's a discussion draft, not an RfC yet, but could use more input.

 — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  21:58, 22 September 2017 (UTC)[reply]

Adding a consensus to NPOL

I have recently encountered a draft about a politician for lost an election and which is not notable. However when arguing with the creator, I have realized that our stance on sources related to elections is simply not covered in policy or guidelines. Could this be fixed?

@Primefac: told this person: The "significant independent coverage" that is required for these individuals must be from outside the political sphere to show that they are independently notable from the campaign.

In my opinion this sums up the consensus well, yet I can only find the following to support it, from WP:POLOUTCOMES; "Losing candidates for office below the national level who are otherwise non-notable are generally deleted. They are not moved to user space for fear of establishing a precedent that any premature article about an as-yet-unelected candidate for office can be kept in draftspace pending election returns, effectively making draftspace a repository for campaign brochures (see Wikipedia:Articles for deletion/Siân Gwenllian.)"

WP:NPOL is totally useless for this, as it does not say such politicians are not notable (instead points to the GNG), nor does it deal with the issue of which sources are acceptable. WP:ROUTINE is not detailed enough to be directly usable, as it only mentions events, and WP:BLP1E does not mention elections or politics. I know it is possible to draw a inference of the consensus from these guidelines, but there is nothing that directly covers the issue of the sources.

It could be argued that they are only passing mentions, as they focus on the circumstance of the campaign, and would not otherwise mention the individual, but this is not defined in guidelines either. Sources related to a person, which do discuss the person at length, but which are doing this for the purposes of covering an election campaign, are clearly not usable per WP:ROUTINE. This is not made clear in WP:ROUTINE, in the absence of something being made clear, it is simply my interpretation of the guidelines.

Consider the draft creator has said things like: "Thanks for providing your logic. However your phrase "outside the political sphere" appears to be your personal interpretation of the criteria about "independent, reliable sources", no? There is also guidance about "non-trivial / non-merely-directory-like details" of the news coverage. The Cairns Post (newspaper) & Sydney Morning Herald (newspaper) & 4CA (AM radio) & ABC Far North (FM radio) both offered multiple, independent, reliable, in depth coverage of the campaign..." and "I will now quote the sentence I wish you would acknowledge: Just being an elected local official, or an unelected candidate for political office, does not guarantee notability, although such people can still be notable if they meet the primary notability criterion of "significant coverage in reliable sources that are independent of the subject of the article". Why are Wikipedia editors so intent to judge the content of sources. Just check for the above qualities (only) please!!" (see my talk page).

If I have missed some glaringly obvious guideline that covers this then I apologize in advance. Α Guy into Books § (Message) -  12:18, 23 September 2017 (UTC)[reply]

Please provide a link to the article in question... It is impossible to comment meaningfully without reviewing the specifics of the case. I gather that there was some media coverage... so a lot depends on what the media coverage about him/her says. We would need to review the sources. Certainly a losing politician can be considered notable (example: Jimmy McMillan) ... but that does not mean that all losing politicians are considered notable. We have to judge each case on its merits. Blueboar (talk) 14:26, 23 September 2017 (UTC)[reply]
The article in question is Draft:Kurt_Pudniks Skinduptruk (talk) 14:56, 23 September 2017 (UTC)[reply]
  • I would like to clarify and expand upon my statements (which I still stand by) on the draft and my talk page. WP:POLOUTCOMES is a better essay than WP:NPOL because it better describes the losing candidates. In any election cycle there is bound to be a significant amount of coverage about all parties involved - after all, how else would be public know who to vote for? However, all of this coverage pertains to one "event", meaning it falls under the second point of WP:BLP1E. This is why I requested that there be independent reliable coverage of Pudniks from outside the election cycle - it would show that he's more than just a guy who failed to get elected. Primefac (talk) 16:08, 23 September 2017 (UTC)[reply]
I think it more accurate to say that the coverage all relates to a chain of events (the campaign) culminating in one event (the election). I'm not sure that BLP1E was intended to apply to this.
This may be my US outlook on elections... but I doubt anyone from the US would apply 1E to a US election - where we first have primary elections and then the general election ... each of which could be considered separate "events" (even though they are part of the same overarching political process)... as well as numerous campaign rallies, debates, fundraisers, etc. (which could also be considered separate "events"). Blueboar (talk) 18:49, 23 September 2017 (UTC)[reply]

Straw poll on the current view of WP:NOT#NEWS

Recently I proposed a changed at WT:NOT which related to WP:NOT#NEWS (Wikipedia is not a newspaper) which was taken through an RFC that closed recently WT:NOT#RFC: New subsection under "Not a Newspaper" about commentary here (permalink to that) It closed as no consensus, but I would recommended reading the !votes and discussion of that, as it highlights a currently growing issue on en.wiki, how are we supposed to handle current events/news.

A key factor is the current fate of Wikinews. It is, as mentioned several times in the discussion above, effectively a dead project, stuck in a catch-22 problem to get people to use it. There is clearly both editor desire and readership interest to see current news provided in a wiki-style, and en.wiki has generally done well before in covering current events. But events over the last few years (particularly over the last 2 years) have created a lot of editor tension and behavioral problems related to current event coverage (given what passes by AN/ANI/ARBCOM and various policy noticeboards), and highlights the differences between what an encyclopedia is and what a newspaper is. Their goals aren't fully mutually exclusive but there are several conflicting goals. WP:RECENTISM highlights many of these issues.

So I figure that to try to resolve this is to at least start with a straw poll, not designed to establish any immediate change in policy or guideline, but only to see where the current perception is of how en.wiki should be handling NOT#NEWS. Testing the wind, to speak. To that, there's principle three options to consider to get an idea where an editor/reader's interest in this may be as to determine the preferred method to go forward, if needed.

  1. The current situation for NOT#NEWS is fine or only needs some small adjustments. This might include defining a guideline to help with writing current events articles (akin to WP:Writing about fiction), but likely no change to policy.
  2. NOT#NEWS should be more strongly enforced, and limiting our current event coverage. This might include stronger enforcement of WP:NEVENTS, additional policies relating to NOT#NEWS, encouraging/putting more current news articles to draft space, pushing more content/editors to Wikinews, and the like.
  3. NOT#NEWS should be less strong enforced, and expanding our current event coverage. This might include outright removal of NOT#NEWS, adjusting how NOT#NEWS and NEVENTS are written and handled to allow more news, effectively merge Wikinews in en.wiki, and the like.

As this is not an attempt to find a solution right now; I would fully expect that any proposed idea that comes out of that would be under a full Wiki RFC to consider before implementation. So a straw poll is best here. I would request you simply !vote in the appropriate section below, keeping threaded discussion to the provided discussion section. --MASEM (t) 16:23, 25 September 2017 (UTC)[reply]

Option 1: WP:NOT#NEWS is working as is

Or: The coverage of current events on en.wiki is about right or only needs fine adjustment

  1. (vote and sign here)

Option 2: WP:NOT#NEWS should be more strongly enforced

Or: En.wiki should have significantly less coverage of current events

  1. (!vote and sign)

Option 3: WP:NOT#NEWS should be less strongly enforced

Or: En.wiki should have more expanded coverage of current events

  1. (!vote and sign here)

Threaded discussion on NOT#NEWS