Wikipedia:Village pump (all)

From Wikipedia, the free encyclopedia

This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.

Click here to purge the server cache of this page (to see recent changes on Village pump subpages)


Village pump sections

Edit-find-replace.svg
Policy
watch
To discuss existing and proposed policies

Preferences-system.svg
Technical
watch
To discuss technical issues. For wiki software bug reports, use Phabricator

Dialog-information on.svg
Proposals
watch
To discuss new proposals that are not policy-related. See also: perennial proposals.

Tools-hammer.svg
Idea lab
watch
To discuss ideas before proposing them to the community and attempt to find solutions to issues

Help-browser.svg
Miscellaneous
watch
To post messages that do not fit into any other category

View all village pump sections at once

Other help and discussion locations
I want... Where to go
...help using Wikipedia Help desk
...to find my way around Wikipedia Department directory
...specific facts (e.g. Who was the first pope?) Reference desk
...constructive criticism from others for a specific article Peer review
...help resolving a specific article edit dispute or making a user conduct dispute complaint  Requests for comment
...to comment on a specific article Article's talk page
...to view other Wikimedia projects Wikimedia Meta-Wiki
...to learn about citing Wikipedia in a bibliography Citing Wikipedia
...to report sites that copy Wikipedia content Mirrors and forks
...to ask questions or make comments Questions


Contents

Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).

Policy

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)

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)
Can you please guide on how to improve it to standards? -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 15:34, 24 August 2017 (UTC)
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)
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)
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)
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)
Another [2] -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 15:42, 9 September 2017 (UTC)

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

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)

We don't have such a policy yet. Jo-Jo Eumerus (talk, contributions) 19:52, 2 September 2017 (UTC)
  • 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)
    • 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)
  • 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)
    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)
    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)
    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)
  • 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)
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)
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)
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)
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)
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)
  • Object example of the day: [3]. Wow! — fortunavelut luna 09:43, 8 September 2017 (UTC)
  • 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)
    • 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)
      • 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)
        • 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)
          • 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)
            • 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)
              • 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)

────────────────────────────────────────────────────────────────────────────────────────────────────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)

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)
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)
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)
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)
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)
  • 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)
  • 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)
  • 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)
  • 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)
  • Rentier, the best place to pose such a question on-wiki would likely be meta:User talk:Slaporte (WMF). TonyBallioni (talk) 16:37, 12 September 2017 (UTC)
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)
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)
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)
Forgive my naïvety: Is this why we allow paid editors to be OTRS agents? Kudpung กุดผึ้ง (talk) 07:16, 16 September 2017 (UTC)

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)

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)

  • 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)
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)
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)
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)
@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)
Also, this section of the plagiarism guideline, explicitely welcomes these additions. Sadads (talk) 13:12, 11 September 2017 (UTC)
  • 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)
  • 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)
    • 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)
      • @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)
        • I have been discussing this with the editor concerned and will continue to do so, Sadads. My comments here weren't so much a request for instituting additional guidelines, but rather to get clarification on what this particular guideline covers, as there is some confusion about this (see Talk:Chinese Academy of Sciences#Restoration of reform section). This confusion stems in part from the title addressing primary sources but the introduction possibly suggesting that it applies more widely (which I see you have tried to address here - thanks for that). Cordless Larry (talk) 14:10, 11 September 2017 (UTC)
          • @Cordless Larry:, one of the issues is there is no to very little guidance about transforming text from an external source into the 'voice' of Wikipedia, I've tried to collate some resources and guidance here, in a length that won't cause people to just TL;DR. Do you have any specific suggestions for that? I think using the word bias isn't overly useful as it has such a broad scope. What I'm hearing from you is something like 'attribute any recommendations or points of view to their sources'. Thanks, --John Cummings (talk) 14:27, 11 September 2017 (UTC)
          • Again, the "primary sources" related guideline only covers "primary sources": making it say something outside that scope would not be appropriate under that guideline title. The related policy (WP:NOTMIRROR #3) is however not limited to primary sources. But I'd stop that route (both the "primary sources"-related guideline as the related WP:NOT paragraph). Seems like what you're looking for is the combination of WP:BALASPS with WP:GNG:
            1. If UNESCO is the only possible source for the "science and technology in <country>" topics, these articles should be deleted or merged while not passing WP:GNG
            2. For each of these articles which have more than one reliable source, WP:BALASPS should be applied: see what other sources say and put it together, summarized, under a WP:NPOV umbrella. --Francis Schonken (talk) 15:37, 11 September 2017 (UTC)
            • That looks helpful, John Cummings. I'd suggest trying to explain that attributing points of view is different from attributing the text (perhaps link to WP:ATTRIBUTEPOV?), as that message doesn't seem to be getting through. I also think we need to emphasise that relying on a single secondary/tertiary sources leaves us vulnerable to the problem that that source might not provide a neutral or complete summary, and that it should be balanced by including material from other sources where possible, to address Francis Schonken's second point above. Cordless Larry (talk) 15:56, 11 September 2017 (UTC)
              • @Cordless Larry and John Cummings: So I think I have enriched the guidance at with a couple easy-to-act-on recommendations at the revision guidelines and the source selection recommendations. Maybe those will help with guidance for the folks that use the guide. Larry: do you think that points towards the main concern you are expressing here? Sadads (talk) 20:30, 11 September 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── 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)

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)
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)
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)
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)

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)

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)

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)
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)

Merge discussion: WP:Naming conventions (identity) to WP:Manual of Style#Identity

FYI: 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)

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)

Olga has replied to the ping. CKoerner (WMF) (talk) 18:12, 11 September 2017 (UTC)
  • 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)
  • 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)
  • (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)
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)
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)
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)
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)
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)
(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)
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)
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)
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)
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)
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)
  • AFAIK Wikidata *is* a fork of Wikipedia (from multiple languages' Wikipedias I suppose). At least at en.wikipedia data from Wikidata should not re-enter the encyclopedia per WP:CIRCULAR, which is a policy here. --Francis Schonken (talk) 17:07, 11 September 2017 (UTC)
@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)
  • 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... —PaleoNeonate – 16:21, 11 September 2017 (UTC)
  • 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)
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)
WP:Persondata is the only one I know of which was invisible. --Izno (talk) 17:14, 11 September 2017 (UTC)
Yeah, that's the one I had in mind. --Francis Schonken (talk) 17:17, 11 September 2017 (UTC)
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)
@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)
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)
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)
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)
(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)
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)
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)
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)
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)

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)

@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)
@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)
@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)
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)
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)

RfC: exceptions to WP:CIRCULAR allowable for Wikidata?

Malformed RfC.There seems to be valid problems with the framing, scope et al.Winged Blades Godric 03:22, 12 September 2017 (UTC)
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)

Discussion

  • No, not under any guise or format. --Francis Schonken (talk) 20:09, 11 September 2017 (UTC)
  • 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)
  • 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)
  • 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)
  • Comment - malformed RfC. You may get comments but you won't get results. - Sitush (talk) 23:13, 11 September 2017 (UTC)
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's talk page or in a deletion review). No further edits should be made to this page.

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

pulled for now. May re-open if the response goes sideways. Jytdog (talk) 05:48, 12 September 2017 (UTC)
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)

!votes (description field RfC)

  • Yes to all three. See below. Jytdog (talk) 00:41, 12 September 2017 (UTC)

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)
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)
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)
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)
OK, willing to pause this for now. Jytdog (talk) 05:48, 12 September 2017 (UTC)

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)

Notice of Discussion at Wikipedia talk:Manual of Style/Capital letters

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)

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)

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)

  • I supported the ACTRIAL years ago, and thereafter read some of the discussion from the developers.  Thank you for the good news.  Unscintillating (talk) 22:14, 16 September 2017 (UTC)
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)

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)

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)
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)
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)

Removal of speedy deletion tags by non-admins

I know it's only been a day but I think we can close this per WP:SNOW. It's clear that this proposal, certainly made in good faith, will not gain consensus because of the reasons mentioned in length by multiple users, especially, but not limited to, the fact that once anyone, admin or not, disagrees with a tagging in good faith, speedy deletion no longer is appropriate. Regards SoWhy 20:09, 17 September 2017 (UTC)
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)

  • 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)
  • 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)
  • 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)
  • Oppose - at first blush a reasonable suggestion, but actually a solution looking for a problem. Kudpung กุดผึ้ง (talk) 22:24, 16 September 2017 (UTC)
  • 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)
  • Oppose--Per Tony.Winged Blades Godric 02:59, 17 September 2017 (UTC)
  • Oppose - per what everyone's already said here. Ivanvector (Talk/Edits) 03:02, 17 September 2017 (UTC)
  • 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)

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)

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)

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)

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)
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)
@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)
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)
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)
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)
@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)
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)
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)
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)

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)

Two clarification RFCs at the Manual of Style

FYI: 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)

PS: This may also be of interest:

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

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)

Technical

Wikipedia:Graphics Lab/Photography workshop

Resolved sections on this page are not being archived anymore. Could someone please attempt to fix that issue? Thanks. --Leyo 08:25, 30 August 2017 (UTC)

@Leyo: it's because ClueBot III (talk · contribs) is down (again). So it's a problem for the botops, nothing we can do here at VPT. --Redrose64 🌹 (talk) 09:54, 30 August 2017 (UTC)
The last archiving was 15 July [21]. ClueBot III has only been down since 25 August. PrimeHunter (talk) 10:16, 30 August 2017 (UTC)
Indeed, but this disabling of the archiving was not re-enabled until 22:33, 28 August 2017 - after the bot went down. That "temporarily disable autoarchive" on the part of AntiCompositeNumber (talk · contribs) explains the lack of archiving between 15 July and 28 August. --Redrose64 🌹 (talk) 12:20, 30 August 2017 (UTC)
Oh right. So I wasted a lot of time investigating the situation because Leyo failed to say that archiving had been disabled until two days ago. Sigh. I did look for recent edit summaries mentioning archiving but Leyo didn't say it when enabling it. PrimeHunter (talk) 15:39, 30 August 2017 (UTC)
I didn't expect that digging into the history was needed to answer the question. Sorry about that. Let's hope that the issue ClueBot III will get resolved soon. --Leyo 22:13, 30 August 2017 (UTC)
@Leyo: and everyone else, I disabled the archiving because the current configuration will archive every section, as the appears the same as {{resolved}} to ClueBot. The proper way to fix that would be to change the instructions to an edit notice. I started working on one at Template:Graphics Lab/editnotice. Now that I'm back from wikibreak, I'll also be manually archiving the page regularly again, at least until we can get the bot working as intended. --AntiCompositeNumber (Ring me) 01:00, 3 September 2017 (UTC)
@AntiCompositeNumber: I'm having difficulty understanding your phrase "as the appears the same as {{resolved}} to ClueBot". Have you missed something out here? --Redrose64 🌹 (talk) 08:23, 3 September 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Based on the source, AntiCompositeNumber may have tried to display "as the <nowiki/> appears the same as <nowiki>{{resolved}}</nowiki> to ClueBot". I'm not sure what it means but I think I know the archiving problem. The new request link at Wikipedia:Graphics Lab/Photography workshop preloads Template:Graphics Lab/new request/preload which includes: <!-- mark request as {{resolved|1=~~~~}} when finished or {{stale|1=~~~~}} when inactive for at least one month -->. The removed archive instructions [22] said: |archivenow=<nowiki>{{resolved|</nowiki>. See User:ClueBot III/ArchiveThis#Optional parameters for archivenow. It causes the bot to archive all sections with the preloaded text because the comment contains the archivenow string.[23]. It was only intended to archive sections where an editor has added {{resolved}}. A possible but inelegant solution would be to complicate the preloaded instructions like: <!-- mark request as {{RESOLVED|1=~~~~}} but with lowercase "resolved" when finished, or {{stale|1=~~~~}} when inactive for at least one month -->. If a user keeps uppercase {{RESOLVED}} then the template works via a redirect but the bot doesn't archive until an editor changes it to lowercase. PrimeHunter (talk) 10:43, 3 September 2017 (UTC)

Exactly. I should really stop using {{subst:CoNo}} and ignoring it in the preview, it seems to cause more trouble than it's worth. --AntiCompositeNumber (Ring me) 12:12, 3 September 2017 (UTC)
@AntiCompositeNumber: Are you aware of the various template-linking templates? The basic one is {{tl}}, but I find {{tlx}} to be more useful, also {{tlxs}}. So in your last comment you could have written {{tlxs|CoNo}} which displays as {{subst:CoNo}}; and earlier on you could have used {{tlx|resolved}} which displays as {{resolved}}. --Redrose64 🌹 (talk) 13:10, 3 September 2017 (UTC)
@Leyo: ClueBot III was restarted at 01:23, 6 September 2017 and archiving of Wikipedia:Graphics Lab/Photography workshop occurred at 22:40 the same day. --Redrose64 🌹 (talk) 10:33, 7 September 2017 (UTC)
Well, but it's done incorrectly as you can see in the diff you provided. --Leyo 18:53, 9 September 2017 (UTC)
You wanted to know why it wasn't being archived. We explained it. Archiving started again. Why is it now a problem? --Redrose64 🌹 (talk) 22:57, 9 September 2017 (UTC)
I explained why it archives too much above and gave a possible but inelegant solution. You have to do something or the same will repeat every day. PrimeHunter (talk) 23:11, 9 September 2017 (UTC)
@PrimeHunter: I am not sure if I got your solution right. Could you implement it so that we may see, if it really works? --Leyo 07:41, 13 September 2017 (UTC)
Done.[24][25] PrimeHunter (talk) 10:33, 13 September 2017 (UTC)
It worked.[26] Only sections with lowercase {{resolved| were archived. PrimeHunter (talk) 00:55, 14 September 2017 (UTC)

Should we ask for mapframe to be turned on?

Mapframe is an extension that is being developed by the WMF to show small OpenStreetMap maps in articles. Background information is at mw:Help:Extension:Kartographer. It is currently enabled on some Wikipedias that have opted in, and I think it would be useful here as well. Personally, I'm interested in using this in Wikidata-driven infoboxes such as the one at Lovell Telescope to replace {{Location map}} with OSM data, but it also has wider applications. I don't think that it interferes with existing coding here, so it just adds functionality that we can use. I can't spot any previous discussions about this, so I'm starting this discussion here to try to determine consensus. Also see phab:T138057 and phab:T175102 Thanks. Mike Peel (talk) 00:29, 6 September 2017 (UTC)

Agree I think it would be a major benefit to have proper interactive maps in all Wikipedias, not just the ones that opted in. <mapframe> functionality has not caused any technical issues on any other wikis. Map code is already deployed to all Wikipedias as <maplink>, so enabling it would be as simple as flipping a switch. --Yurik (talk) 00:41, 6 September 2017 (UTC)
Support This should've been done waaay sooner. Ladsgroupoverleg 10:58, 6 September 2017 (UTC)
Support. Also support T137253 converting Earth coordinates in {{Coord}} to use <maplink> as well. Jc86035 (talk) 11:27, 6 September 2017 (UTC)
Support, would be especially useful to have mapframe maps in the infoboxes of road articles. See commons:User:Evad37/sandbox/maps for some examples - Evad37 [talk] 23:48, 6 September 2017 (UTC)
Note from the Wikimedia Foundation product team: This is a totally reasonable thing to request as better maps on Wikipedia could improve the user experience and would make a lot of people happy. Previously, we had internally decided on a process to enable mapframe for new Wikipedia projects by request on a batch basis every 6 months. However, the future of maps support from the Wikimedia Foundation is uncertain and at this point I think all new communities considering adding maps should be made aware of it.
The Reading product team has been working to try to figure out how to support the existing maps implementation, and our initial analysis is that maps requires significantly more resources than were assigned to the project at inception. We are currently working on establishing if we can prioritize resources to get maps into a stable, healthy state and will update folks on a plan as soon as we have a draft for comment. It has taken longer than we would have liked to get more clarity, due to organizational changes, but I think we are making progress and should have a clearer answer by the end of September, 2017.
The current situation is that over the last several months the maps project has relied on the goodwill of individual engineers at the Wikimedia Foundation to keep it up and running in addition to individual volunteers contributing support. We also have a contractor, working on a cartographic re-skin as well as dealing with some other maps issues like disputed borders.
I am personally very nervous about having maps on English Wikipedia because we don’t know what kind of support we will be able to offer in the future and I want to minimize the amount of editor effort going into a feature that is at risk. We are frankly concerned that the resources required to maintain and make necessary upgrades to the map service are more than we can commit to.
We’d like to propose that we revisit this question in October when we have more clarity over the path forward for maps. Thoughts? Jkatz (WMF) (talk) 00:23, 7 September 2017 (UTC)
@Jkatz (WMF): Thank you for the background information on the development work. I think that there are two different issues here that can be handled in two separate stages. First, do we want to have this functionality available on enwp? That is what this discussion will hopefully decide. Second, is WMF ready to support the deployment? That is something that the WMF has to decide, and if the answer to the first question is 'yes' then the timing of the deployment is up to the WMF; if it is 'no' then the WMF is off the hook. ;-) I think that delaying this until next month doesn't help with either question, so it's still worth asking & answering the first question now. Thanks. Mike Peel (talk) 01:06, 7 September 2017 (UTC)
@Mike Peel: I think that is a totally reasonable approach. Am I correctly interpreting your intent when you say "if it is 'no' then the WMF is off the hook." to mean that if the Wikimedia Foundation is not ready to support the deployment, we will have a discussion and that you wouldn't deploy until we were? This interpretation seems like a great way to break down and approach this problem (thank you!). If, instead you mean you would deploy without our support, it makes me very uncomfortable, as it would mean deploying map infrastructure we are responsible for supporting and maintaining at a time when we are suggesting we might not be able to support and maintain it. Can you confirm that I am reading your intent correctly? Thanks. Jkatz (WMF) (talk) 03:18, 7 September 2017 (UTC)
@Jkatz (WMF): My understanding was that someone at the WMF would have to flip the switch to deploy this. Even if that's not the case, I don't think it makes sense to deploy it until the WMF is ready to support and maintain it. So let's answer the first question here (do we want it here), and then we can move over to phabricator and the WMF/devs can determine when to deploy it. Thanks. Mike Peel (talk) 12:15, 7 September 2017 (UTC)
@Mike Peel: Makes perfect sense. Thanks for clarifying! I'll probably add my note with our concerns to the phab ticket too, just so it's in the relevant places. Jkatz (WMF) (talk) 18:12, 7 September 2017 (UTC)
I'll support.. I've been playing a bit with maps, and it could really use and benefit from some more exposure and feedback by a bigger audience. —TheDJ (talkcontribs) 20:00, 13 September 2017 (UTC)
  • Thanks! Is anyone else interested in commenting on this? 6 supports (including mine) and no opposers gives an answer, but a weak consensus, so more opinions would be good. Thanks. Mike Peel (talk) 23:38, 20 September 2017 (UTC)
  • Support. Interactive maps are such an ubiquitous feature all over the web that it's surprising that we still don't have it, especially given that a really large number of articles are about places. I imagine that such maps can be turned on across the board (without the need for editor input in individual articles) for all articles that have explicitly set coordinates. – Uanfala 11:48, 21 September 2017 (UTC)
  • Support. Maps are a traditional feature of encyclopedias, and these days, we should provide the best maps we can within our articles. Better interactivity / better integration with what the editing community needs (e.g. for data display) sounds like a useful feature to put WMF developer time into. —Kusma (t·c) 13:48, 22 September 2017 (UTC)
  • Support per the above. See also WP:VPTECH#Article with 201 unverifiable references due to exceeding the 2 MB template include size – hard-coded interactive maps can cause serious problems.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  16:54, 22 September 2017 (UTC)
  • I'm amazed by growing number of "support" votes here. Right now, the feature is used by less than 200 users (but slowly growing). --George Ho (talk) 00:44, 23 September 2017 (UTC)

Mysterious random popup

I was at MOS:NBSP and switched to another tab, then switched back; and this popup appeared. I know what a half adder is (have done for 40 years) - my question is, how is it relevant, and where has this come from? --Redrose64 🌹 (talk) 20:24, 7 September 2017 (UTC)

Oho, it's Thursday! Wacky new features time! --Redrose64 🌹 (talk) 20:29, 7 September 2017 (UTC)
I just opened Copenhagen and got 'Would this be useful to someone searching for "List of hospitals in Andorra"'. I'd love to know just who sold the WMF whatever algorithm they're using. ‑ Iridescent 20:33, 7 September 2017 (UTC)
Interestingly, we don't even have a list of hospitals in Andorra :-) Nyttend (talk) 22:29, 7 September 2017 (UTC)
But we do have a red link to it in {{List of hospitals in Europe}}. Clicking the link gives an option to search for it. I guess that's how a search got registered and placed in the test, but I have no idea why Copenhagen is suggested. PrimeHunter (talk) 23:42, 7 September 2017 (UTC)

You know what they say about incorrect proclamations. This has nothing to do with Thursday. This wiki is currently still running the prior version of mediawiki. This is likely an A/b test / survey probably to help improve the cirruSearch search engine. 20:38, 7 September 2017 (UTC) — Preceding unsigned comment added by 197.218.89.254 (talk)

You say "A/b test / survey probably to help improve the cirruSearch search engine", I say "yet more fucking about with the interface without consultation or notification". It's probably one of those tricky irregular verbs. ‑ Iridescent 20:45, 7 September 2017 (UTC)
The screenshot includes the string "would they want to read this article". I searched it at Phabricator and got three results: phab:T171740, phab:T171741, phab:T174106. It's an A/B test for Search Relevance. PrimeHunter (talk) 21:15, 7 September 2017 (UTC)
Yes, we're currently running a test for Search Relevance (graded by humans); more information can be found in this ticket: phab:T171740 and the most recent test is detailed here: phab:T174106. DTankersley (WMF) (talk) 22:48, 7 September 2017 (UTC)
I was reading the Adder (electronics) page when one of these appeared. My thoughts were " — there's a pop-up — how did that get here — it seems to be from Wikiepdia itself — it's asking me a question, I'll try to be helpful — it says 'Would you click on this page ...' — would I ever click on a page? — why might I click on a page? —" and before I could come up with a sensible answer, it vanished again. If this is intended as a way of getting useful feedback from users, it's doomed to failure. Maproom (talk) 17:35, 8 September 2017 (UTC)
This reminds me of the Article Feedback Tool. Yuck. (((The Quixotic Potato))) (talk) 19:49, 8 September 2017 (UTC)

The pop-up box is missing an important element - the checkbox or button that says "do not show me this again (ever, on any article)". Mitch Ames (talk) 00:21, 10 September 2017 (UTC)

Personally I don't mind cooperating with it. But if it's going to ask tricky qurestions like "Would you click on this page", it ought to be polite enough to hang around until I've figured out what they mean. Maproom (talk) 19:16, 10 September 2017 (UTC)

Unexpected popup

A strange undocumented popup 2017-09-10 at 2.37.39 PM

While viewing Agarose, a box suddenly appeared in the article, asking "if someone searched for 'red seaweed' would they want to read this article?" I have been unable to find any documentation for this "feature" in Wikipedia, Wikimedia, or Google. The closest I came was an entry in phabricator. Where is the rest of the documentation? What is the extent of this project, in terms of timespan or articles. Comfr (talk) 05:25, 11 September 2017 (UTC)

There is some information at #Mysterious random popup and phab:T174106. PrimeHunter (talk) 10:33, 11 September 2017 (UTC)
I was just scrolling down the page of History of Chinese Americans#Arrival_in_the_United_States, and a pop up appeared in the upper right hand side, looking exactly like the screen shot above, except it asked a different question. Obliterated my view of the image of the man with the queue. My first thought was "malware", and then I remembered this thread. Computer users pay for security software that blocks pop ups, and Wikipedia overrides it and makes us look at popups anyway. — Maile (talk) 13:30, 17 September 2017 (UTC)
The wording can vary. I got this on Film producer: "If you searched for 'focal reducer', would this article be relevant?" PrimeHunter (talk) 13:47, 17 September 2017 (UTC)
I got one of these popups, I don't recall where, but as I recall the search term it asked about was exactly the title of the article. I also don't recall what I clicked, there was no button for "whuh?" Ivanvector (Talk/Edits) 14:40, 17 September 2017 (UTC)

Keep getting asked about search results

Every time I visit the H2S radar page, a pop-up repeatedly appears in the upper right corner of the browser window asking me if this is a suitable article if one is searching for "Lancaster operators". I answer No, trying to be helpful. Then it asks me again. And again. And again. Is this something en.wiki is doing, or is this perhaps a 3rd party plugin? Anyone know what this is? Maury Markowitz (talk) 13:22, 19 September 2017 (UTC)

It's the enwiki test at #Mysterious random popup. Does it repeat if you reload the page? PrimeHunter (talk) 13:29, 19 September 2017 (UTC)
I'll check. Maury Markowitz (talk) 14:01, 19 September 2017 (UTC)
It does come back after a refresh. Maury Markowitz (talk) 14:11, 19 September 2017 (UTC)
@Maury Markowitz: there was a bug, where there was a unit conversion problem, causing the popup to think it had been 2 days since the last time it asked you, while actually it had been no more than 172 seconds.. A fix will follow. —TheDJ (talkcontribs) 16:28, 19 September 2017 (UTC)
Ok, but why does it ask more than once after I answered? And why only in that article and no others? Maury Markowitz (talk) 17:07, 19 September 2017 (UTC)
I've written a post for the Wikimedia Blog that expands a bit on the reasoning behind the test. As TheDJ pointed out, a bug means you got asked every three minutes instead of every two days. However, I don't think we have anything in place to keep it from asking you on the same article. This is an initial test of the process, so I'll add that to the possible feature list for future versions. Though you are less likely to be on the same article two days later (as opposed to 172 seconds later). As for why that article and no others, the surveys are only on a handful of articles right now, but won't ever be on every article. TJones (WMF) (talk) 18:27, 19 September 2017 (UTC)

Page with wrong latest revision

The revision as of 00:34, 24 July 2010 appears to be the latest revision in the history of User talk:Brendanmccabe/You Lucky Dog (2010 Television Film). However, if you look into the bot's 50 oldest contributions, the revision does not have "(current)" next to it. Also, if you view the 3 user talk pages created by Brendanmccabe, the creation at 18:28, 23 July 2010 has "(current)" next to it. The page's page_latest field in the database was not updated when a new revision was inserted. Finally, the edit summary says "moved", but in fact the page was not actually moved at all. Are there any other pages where the latest revision is wrong? GeoffreyT2000 (talk, contribs) 01:37, 10 September 2017 (UTC)

The bot tried to move the talk page [27] and associated non-talk page [28] to the same Wikipedia talk page. Only the non-talk page was actually moved. Articles for creation was placed in the Wikipedia talk namespace at the time because IP's could create talk pages but not other pages (the draft namespace is newer). I guess the bot was trying to move the talk page along with the draft in the non-talk page. I don't know what happens today if you select "Move associated talk page" while moving a non-talk page to a talk page. In July 2010 it apparently caused a misleading page history entry in the talk page, at last when a bot did it via the API. I don't know whether there are other cases. PrimeHunter (talk) 02:40, 10 September 2017 (UTC)
Can an administrator please fix the problem causing "page_latest" for the above user talk page to be wrong? Try running attachLatest.php on this wiki with "--regenerate-all" set to true, if possible. Otherwise, try deleting and then undeleting the page. GeoffreyT2000 (talk, contribs) 22:32, 12 September 2017 (UTC)
Is there a problem which couldn't be fixed by just making a dummy edit to the page? PrimeHunter (talk) 00:17, 14 September 2017 (UTC)

X-Tools not working?

Is X-Tools not working for anyone else? It's not for me, and it wasn't working for me at the beginning of August, either, when I was going to update my edit stats with July on my user page. It's sitting there loading forever this time—the loading circle in the tab isn't even turning blue to indicate the page is about to display, it's just sitting in the state before that forever—but last time I think it threw an error: [29]. Amaury (talk | contribs) 17:32, 11 September 2017 (UTC)

@Amaury: I suggest using the new version (in beta). — JJMC89(T·C) 17:38, 11 September 2017 (UTC)
@Amaury: We've restarted the xtools web server process. It should be working now.
However, JJMC89 is correct in that we will be using the new version. The new version is significantly more stable. ~ Matthewrbowker Say something · What I've done 22:16, 11 September 2017 (UTC)
@Matthewrbowker: I already added it as a bookmark and removed the other one after JJMC89's reply. Face-smile.svg Thank you both! Amaury (talk | contribs) 22:24, 11 September 2017 (UTC)
Face-smile.svg Good to hear. ~ Matthewrbowker Say something · What I've done 00:16, 12 September 2017 (UTC)
I hope that the new one will still be improved before replacing the old one officially, as it only shows me the edit summaries at top (all other details currently require scripts and dynamic loading)... —PaleoNeonate – 22:50, 11 September 2017 (UTC)
"Scripts and dynamic loading" are our solution to handling very heavy database queries (it's a large part of what brought the old one down so often). Work is ongoing, see our workboard on Phabricator ~ Matthewrbowker Say something · What I've done 00:16, 12 September 2017 (UTC)
I can understand if someone doesn't trust JavaScript on the web in general, but I can assure you that XTools is safe :) Please consider whitelisting if you are having trouble. You should be seeing more than just edit summaries, though? All the data except the year/month counts, timecard and global edits are served as raw HTML. While I can't promise we can show you charts, we can make some improvements to show the underlying data to users without JavaScript support. For this I've created T175661. Best MusikAnimal talk 00:33, 12 September 2017 (UTC)
For more information on why scripts are currently completely disabled in the browser instance used with Wikipedia: User:PaleoNeonate#Wikipedia_and_Javascript. —PaleoNeonate – 10:49, 20 September 2017 (UTC)

Lysteria bot and shadowing

There have been previous discussions about Lysteria bot and non-free images (the most recent one was Wikipedia:Village pump (technical)/Archive 158#Listeria bot and non-free images) and an attempt to get input from the bot's operator Magnus Manske was made User talk:Magnus Manske#Non-free images being added by Lysteria bot, but the bot still continues to inappropriately add non-free images to pages such as User:Stinglehammer/Gothic writers 3 and User:Jane023/Female novelists in violation of WP:NFCC#9.

The two files it keeps adding this time are File:Stevie Smith.jpg and File:Sylvia Townsend Warner.jpg. Both of these files are/were shadowing Commons files (c:File:Stevie Smith.jpg and c:File:Sylvia Townsend Warner.jpg), but one of the Commons files has already been deleted as a copyvio and the other is nominated for deletion for the same reason. It seems that there should be some way for the bot to distinguish between a freely licensed file or a non-free file; otherwise, any time someone (perhaps in good faith) uploads a copyvio to Commons which has the same name as a local English Wikipedia file, the bot is going to add the local file by mistake.

Files shadowing other files is a problem for sure, and if simply moving the local file is the best solution, then fine; however, moving is kind of pointless when the Commons file is almost surely going to be deleted. In this case, the bot still seems to "think" that the Commons file for Sylvia Townsend still exists, and therefore keeps re-adding what it believe to be a Commons file to the two aforementioned pages. If it simply takes a few days for the bot to get this out of its system, then OK if, however, the bot is going to continue to make the same mistake in perpetuity, then something needs to be tweaked to stop this. I'm sure the bot does lots of good work, but there needs to be some way for it to "realize" to not keep re-adding files which have been removed for WP:NFCCP reasons. Perhaps there's some way to tweak the local file's page (WP:HIDDENCAT or WP:MAGIC) to let the bot know not to re-add the file? -- Marchjuly (talk) 02:08, 12 September 2017 (UTC)

It's because the link to that file wasn't removed from Wikidata yet, see this edit. —TheDJ (talkcontribs) 06:00, 12 September 2017 (UTC)
That's fine and thank you for doing that. The question is then whether the bot can subsequently remove any non-free files it mistakenly adds to pages if the file Commons file being shadowed is deleted and the Wikidata has been edited accordingly or the shadowing local file is subsequently renamed. If it can, then it can self-correct any NFCC#9 problems; if not, then maybe it should be set (if possible) to distingusih between non-free and free to avoid such problems. -- Marchjuly (talk) 07:29, 12 September 2017 (UTC)
@Marchjuly: technology can do many things, it just depends how much time you pour into it. If you are asking if it is likely that someone is going to change that specific bot to look for deletions that have been made, then I'd say no. Rather, I think this more points towards the problem that CommonsDelinker currently doesn't remove deleted files from WikiData. This so far has been a minor issue, but i've seen multiple complaints recently, that basically would have been avoided if it did have this capability. I think it is more likely that that bot is adapted and I have left some feedback in the bug system of that project. —TheDJ (talkcontribs) 08:51, 13 September 2017 (UTC)
I wasn't aware that tweaking another bot might be a way to resolve this, so thank for trying to help sort this out. -- Marchjuly (talk) 04:27, 14 September 2017 (UTC)

Repeating table header

What is the Wikipedia way of repeating the header of a long complicated table such as ro:Păsările_Republicii_Moldova? so that the reader always knows what is the meaning of the column she/he is reading. Gikü (talk) 07:39, 13 September 2017 (UTC)

There isn't really a methodology for that. You can either repeat the header cells, or create multiple tables. —TheDJ (talkcontribs) 08:40, 13 September 2017 (UTC)
@Gikü and TheDJ: How about putting the header code into a subpage and transcluding it wherever you want it? Wouldn't that work? Please {{Ping}} me to discuss. --Thnidu (talk) 23:08, 13 September 2017 (UTC)
@Thnidu: Mainspace doesn't have subpages so it should be a template. It would work. I don't know whether it limits the ability to edit the table with VisualEditor but there should be no problems in the source editor. PrimeHunter (talk) 23:56, 13 September 2017 (UTC)
──────────────────────────────────────────────────────────────────────────────────────────────────── Templates are intended for multiple-page use, so a template for a single table's column-headers is likely to be deleted, although extremely useful templates for thousands of pages tend to get deleted more than hundreds of peculiar one-off templates. Also perhaps use bold-row token "!" on all header rows, to help other editors notice the column-headers are being repeated. Beware repeat headers in sort-able tables, where the extra headers are likely to sort in strange places. You really want a vertical-scroll table region with fixed stationary headers. -Wikid77 (talk) 00:14, 14 September 2017 (UTC)
  • Scroll wide tables for mobile-phone viewing: If the table might get over-wide, then also consider wrapping entire table inside an extra div-section, as an auto-scrolled table to fit smaller handheld devices, by:
  <div style="width:auto; overflow:scroll">
  {|...
  |}</div>

That div section places the entire table in a scrollable region (on narrow screens) and prevents the tabular format from squeezing the page text as tiny-font, half-screen width on some mobile phones. -Wikid77 (talk) 00:14, 14 September 2017 (UTC)

The mobile version of the websites already does this. You shouldn't do it manually. —TheDJ (talkcontribs) 10:51, 15 September 2017 (UTC)
The original post was about the Romanian Wikipedia ro:. They may have other policies or no relevant policies. Here we dislike single-use templates but I'm not sure we are against single-page templates with multiple uses on that page. PrimeHunter (talk) 00:26, 14 September 2017 (UTC)

Any problems with nested articles

I have created a nested article, "Reverse surge" which trancludes page "{{:Voltage spike}}" while adding a special top hatnote about others as "...see: Surge". However, I wonder are there problems with bottom categories, or other technical issues to beware with nested articles? -Wikid77 (talk) 22:11, 13 September 2017 (UTC)

It would create almost identical articles and we don't do this [30] at the English Wikipedia. We redirect the page per WP:PRIMARYREDIRECT, and consider placing {{Redirect}} at top of the target if the redirected term is ambiguous. {{Redirect|Reverse surge||Surge}} would produce:
Reverse surge has been redirected to Voltage spike without using {{Redirect}}. PrimeHunter (talk) 00:11, 14 September 2017 (UTC)
Whoops. Done it. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 14:39, 14 September 2017 (UTC)

Fixing abuse of list markup (talk page accessibility, etc.)

Our use of wikimarkup : "indentation" for the purposes of threaded discussions is a gross misuse of the underlying <dd>...</dd> HTML markup, which is for (and only for) the definition or explanation of a term or other entry previously given with <dt>...</dt> (; in wikimarkup). Worse yet, any time there's a blank line inserted, it breaks the surrounding <dl>...</dl> list into a separate list after the line break.

The solution to this is technical and should have been proposed and implemented years ago: convert any : indent into a CSS-indented <div>...</div> when it is not immediately preceded by a ; (or explicit <dt>...</dt>). Our talk pages should not be using <dl>...</dl> structures at all, other than for creation of actual description lists we intentionally want to be formatted as such.

While we're at it, we should also do a similar conversion on any line starting with ; (a <dt> entry), and turn it into a boldfaced div, if it is not immediately followed by : producing a <dd> entry.

Both of these should also suppress the parser's creation of surrounding <dl>...</dl> markup, without any actual <dt> or <dd> items to wrap.

These fixes would also clean up a lot of misused of description list (a.k.a. definition list, association list) markup in articles, where it's being abused for boldface and indentation of non-list material.

Similarly, a line starting with * in absence of any other contiguous line of the same sort should be converted on the fly into an indented line with a bullet, not a "list" with one item. In cases where it's actually desired to use a one-item real list (e.g. to match the formatting of longer lists in the same material), explicit <ul>...</ul> and <li>...</li> markup can be used.

I'm not sure I care whether it's fixed by the devs in the MediaWiki parser, or fixed on-site by JavaScript. The former would be better in the long run, since it would apply the fix to all installations, but the approaches aren't mutually exclusive; the latter could be used in the interim.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  02:13, 14 September 2017 (UTC)

Javascript would not be a good solution for this for many reasons; it sounds indeed that you want to have the mediawiki parser changed, so should bring this up at www.mediawiki.org or on phab, since it would not be only for the English Wikipedia. — xaosflux Talk 02:20, 14 September 2017 (UTC)
@SMcCandlish: see requests such as phab:T6521 that appear similar. — xaosflux Talk 02:22, 14 September 2017 (UTC)
Thanks. Will look into that, and see if that's the right pressure point.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  06:02, 14 September 2017 (UTC)
Is this not on WP:PEREN? It should be.... FACE WITH TEARS OF JOY [u+1F602] 03:26, 14 September 2017 (UTC)
No, it shouldn't be, because it's not a subjective idea the community keeps rejecting, it's a technical glitch that needs to be fixed because it's causing problems.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  06:02, 14 September 2017 (UTC)
"The community/communities is/are right because they misuse wikitext"? I see. That's definitely a technical glitch. (<- yes, sarcasm). This comes up every once in a while. As I've argued before, the WMF has a replacement for the predominant use case where these elements are misused that the community has rejected. The community should lie in their mess that doesn't so-affect accessibility that Graham pitches a fit (and you know we all rely on Graham--he has previously said that he gets the gist of talk pages from context). For other uses, the correct solution, as with many other things, is to fix the wikitext. (We might reasonably create a lint error when e.g. ; is not followed by a : or another ; in a content space; I would certainly support such a solution.) -Izno (talk) 11:57, 14 September 2017 (UTC)
I note that HTML5 defines the contents of <dl> as "Zero or more groups each consisting of one or more dt elements followed by one or more dd elements, optionally intermixed with script-supporting elements." So the suggestion here that every ';' must be immediately followed by a ':' and every ':' must be immediately preceded by a ';' is overly restrictive. Anomie 14:19, 14 September 2017 (UTC)
Yeah, technically you can have two or more DTs followed by two or more DDs (e.g. British and American spellings of a term, with multiple definitions from different fields). What's required is that each group have both a DT and a DD. So, what I've suggested works if you extrapolate a little: the parser shouldn't treat a ;-starting line as a DT unless followed by a DD or another DT, nor treat a :-line as a DD unless preceded by a DT or another DD. We don't appear to have any use case for "optionally intermixed with script-supporting elements", and even if we did, there's no reason for markup so advanced it strains the limits of what MW can handle to be something that has to be supported in ;-and-: basic markup mode, rather that requiring dropping into full-on HTML mode with actual <dl><dt><dd></dd></dt></dl> markup.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  00:21, 19 September 2017 (UTC)

Merging infobox

I was trying to merge {{Infobox Tibetan Buddhist monastery}} with {{Infobox religious building}} but there are too many different parameters. Some of those I am stuck with include |order=, |no._of_monks=, etc. Would anyone like to help? -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 03:01, 14 September 2017 (UTC)

So maybe you shouldn't try to merge them. The same probably is true of {{ infobox XXX church }} and {{ infobox XXX monastery}} (or whatever). What you're trying to do seems to me better done by categorization of the articles involved, and has probably already been done. --Thnidu (talk) 06:00, 14 September 2017 (UTC)
Please see the template, then you would know the result of merge discussion. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 12:27, 14 September 2017 (UTC)

Bot request

Is it possible to add such cleanup tasks to one f the existing bots or create a bot for such cleanups? These fill up the maintenance cat of unknown parameters unnecessarily. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 12:27, 14 September 2017 (UTC)

Even GA level articles has such issues. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 12:54, 14 September 2017 (UTC)
Try Wikipedia:Bot requests. -- GreenC 13:04, 14 September 2017 (UTC)

Improvements coming soon to Recent Changes

Hello

In short: starting on 26 September, New Filters for Edit Review (now in Beta) will become standard on Recent Changes. They provide an array of new tools and an improved interface. If you prefer the current page you will be able to opt out. Learn more about the New Filters.

What is this feature again?

This feature improves Special:RecentChanges and Special:RecentChangesLinked (and soon, Special:Watchlist – see below).

Based on a new design, it adds new features that ease vandalism tracking and support of newcomers:

  • Filtering - filter recent changes with easy-to-use and powerful filters combinations, including filtering by namespace or tagged edits.
  • Highlighting - add a colored background to the different changes you are monitoring. It helps quick identification of changes that matter to you.
  • Bookmarking to keep your favorite configurations of filters ready to be used.
  • Quality and Intent Filters - those filters use ORES predictions. They identify real vandalism or good faith intent contributions that need help. They are not available on all wikis.

You can know more about this project by visiting the quick tour help page.

Concerning RecentChanges

Starting on 26 September, New Filters for Edit Review will become standard on Recent Changes. We have decided to do this release because of a long and successful Beta test phase, positive feedback from various users and positive user testing.

Some features will remain as Beta features and will be added later. Learn more about those different features.

If your community has specific concerns about this deployment or internal discussion, it can request to have the deployment to their wikis delayed to October 1, if they have sensible, consistent with the project, actionable, realistic feedback to oppose (at the development team's appreciation).

You will also be able to opt-out this change in your preferences.

Concerning Watchlists

Starting on September 19, the Beta feature will have a new option. Watchlists will have all filters available now on the Beta Recent Changes improvements.

If you have already activated the Beta feature "New filters for edit review", you have no action to take. If you haven't activated the Beta feature "New filters for edit review" and you want to try the filters on Watchlists, please go to your Beta preferences on September 19.

How to be ready

Please share this announcement!

Do you use Gadgets that change things on your RecentChanges or Watchlist pages, or have you customized them with scripts or CSS? You may have to make some changes to your configuration. Despite the fact that we have tried to take most cases into consideration, some configurations may break. The Beta phase is a great opportunity to have a look at local scripts and gadgets: some of them may be replaced by native features from the Beta feature.

Please ping me if you have questions.

On behalf of the Global Collaboration team, Trizek (WMF) 15:26, 14 September 2017 (UTC)

I suggest we launch the RC change as opt-in for existing users and as opt-out for new users... Otherwise I don't see this ending well. —TheDJ (talkcontribs) 15:41, 14 September 2017 (UTC)
Yep, I'm sure there will be some drama if this is opt-out for existing users. Stryn (talk) 17:02, 14 September 2017 (UTC)
Thank you for your suggestion. I'll report it to the team and we will take a decision. Trizek (WMF) (talk) 18:50, 14 September 2017 (UTC)
Trizek, I have at the moment no opposition to this release, I just have serious misgivings about your statement "If your community has specific concerns about this deployment or internal discussion, it can request to have the deployment to their wikis delayed to October 1, if they have sensible, consistent with the project, actionable, realistic feedback to oppose (at the development team's appreciation)." Why?
  • Why only a delay until 1 October?
  • Why does it matter if the opposition is sensible, consistent with the project, actionable, realistic feedback to oppose?
If a community (not some individuals, but e.g. a speedy RfC) decides that they don't want to have this enabled, for whatever reason, why can't you just say "fine, we'll leave it as it is for your wiki"? Considering that everyone will be able to opt-out anyway (meaning that there isn't a technical reason that after 1 October, the current system can't remain in place), it shouldn't be too hard to set this to "automatic fixed opt-out for everyone" on that wiki. I totally understand that you do not have to cater to every wish or whim of the communities, and that your team has its say in what comments, wishes, blockers are actionable and realistic and which aren't. I have in principle no problem if you would check the comments and come back with a "no can do, take it or leave it". What I don't get is why you instead say "no can do, you have to take it". This really doesn't send a "we are here for you, we want to work together" message but again the typical "we know better so leave us alone" some of us have come to expect. Fram (talk) 08:35, 15 September 2017 (UTC)
@Trizek (WMF): Fram (talk) 07:59, 19 September 2017 (UTC)
Sorry for the delay Fram, I was sick these days.
The work on those filters has been done based on user research and user testing, and we have actively took care of all feedback received (which has been overall very positive so far). For us, this justifies a release by default for all users on all wikis, to help people taking care of Recent Changes.
We have set a deadline to move on new improvements (like filter by user or by category) and new projects. Set a different configuration for several wikis is not comfortable for future maintenance work, improvements and operations and requires time to take care of those communities.
Concerning the delay itself, some communities may have issues using the Beta feature we are not aware of (the filters are breaking something completely for instance). That's why we ask those communities to tell us if they need a delay, if necessary and realistic. If the bug is our responsibility, we have until October 1st to fix it, if it matches the project goals. If the bug is the community responsibility (because of a compatibility issue with a local script/gadget for instance), they can ask for a delay to fix it (and we provide assistance if possible) until October 1st. We will of course be working together on those requests. But blockers like "We don't think this tool is useful" or "We don't like the colors" are not eligible for the delay.
We are not forcing everyone with no exception to use the filters. We are providing a way to opt-out for all users who don't want to have them and we think it is a reasonable way to satisfy everyone. We don't say "you have to take it" but "your wiki will have it but you can choose if you want it on your personal interface or not". Maybe the wording for my message was not optimal?
Best, Trizek (WMF) (talk) 15:33, 20 September 2017 (UTC)

Why searching for # takes me to the main page?

Hello. I noticed that putting just the # -symbol to the search box takes me to the main page. Adding text after the # -symbol takes me to that section of the main page, say searching for <#Today's featured picture> takes me to Today's featured picture section of the main page. Adding nonsense after the # simply returns the main page. Just wondered why this happens. Voltteri (talk) 19:17, 14 September 2017 (UTC)

This is phab:T28766. See Talk:Main Page/Archive 139#Should we add "For technical reasons, .23 redirects here .5B....5D see number sign" for an old discussion about putting a hatnote on the main page. PrimeHunter (talk) 19:31, 14 September 2017 (UTC)
Interesting. Thank you for quick response. Voltteri (talk) 19:41, 14 September 2017 (UTC)

ACTRIAL beginning today

Just dropping a note to let folks know that WP:ACTRIAL is beginning today around 23:00–24:00 hours. During this experiement, non-autoconfirmed users will be redirected to Wikipedia:New user landing page whenever they follow a red link or otherwise try to create a new article. They will still be able to create new pages in all namespaces except the main article namespace. We expect this will lead to an increase in submissions to Wikipedia:Articles for creation, so any help with reviewing submissions there would be appreciated during the trial (See Wikipedia:WikiProject_Articles_for_creation/Participants). If you're interested in the research aspect of this experiement, please see meta:Research:ACTRIAL. Kaldari (talk) 19:34, 14 September 2017 (UTC)

This experiment has so many nuisances that it will probably be very hard to quantify. Due to the open nature of wikis, a conspiracy theorist could simply claim that those who want this to succeed (or fail) and know how to game the system will be able to do so.
Also, it might be prudent to avoid the same pitfall as mw:PageTriage, a one trick pony that was only deployed here for apparently the same reasons. All improvements to that extension are certainly very hard to justify because they only help this wiki (or other non-wikimedia wikis that managed to get it working). It might be prudent to deploy this tool at least to mediawiki.org, or possibly ask one non-latin based wiki to opt-in. It could even be deployed with a less strict setting that allows users to create articles as normal, but requires them to go through the landing page first. Such a article creation tool should be a basic tool in any wiki, and may even be welcome by many wikis. Although a disclaimer that this may be removed, or that it might not get any new features or bug fixes might be reasonable before allowing any further deployments.
Deploying the tool in at least one extra wiki will provide an extra data source that would somewhat reduce the researcher bias. 21:21, 14 September 2017 (UTC) — Preceding unsigned comment added by 197.218.82.173 (talk)
That precisely makes nil sense.By the way, whose logged-out version are you?Winged Blades of GodricOn leave 10:10, 15 September 2017 (UTC)
I'm very much looking forward to the results of the research. I'm sure it will be open to many interpretations, but at least we will have data. —TheDJ (talkcontribs) 10:46, 15 September 2017 (UTC)

Range contributions coming soon

I'm excited to announce that today phab:T163562 was deployed to English Wikipedia, allowing you to query for IPv4 or IPv6 ranges at Special:Contributions. It does not support wildcards, but the gadget many of you use will continue to work. The native contributions list will simply be shown below the gadget's results.

However historical data is not yet available, making this feature not-so-useful. Backfilling this data is proving to be a big challenge for a large wiki like English Wikipedia. In the meantime, new edits from IPs (since deploy time) are being stored, so if you see edits when querying for a range such as Special:Contributions/2601:401:503:62b0::/64, this is why :)

There is also a new interface message shown when you are viewing an IP range: MediaWiki:Sp-contributions-footer-anon-range (which is empty at the time of writing), as opposed to the normal MediaWiki:Sp-contributions-footer-anon message you see when viewing a single IP. One more important note is that Special:DeletedContributions does not support IP ranges -- yet!

Just wanted to give you a heads up. You can follow phab:T175105 for progress on backfilling the data. I will write back here once it is resolved. Best MusikAnimal talk 03:52, 15 September 2017 (UTC)

Excellent, thanks! Johnuniq (talk) 06:16, 15 September 2017 (UTC)

Indigenous territories of Costa Rica

Could you fix image and its description?--Kaiyr (talk) 09:02, 16 September 2017 (UTC)

@Kaiyr: Each Wikipedia language has its own templates like {{legend}}, and parameters are often different. You can usually not copy template calls directly from other languages. I have fixed it.[31] PrimeHunter (talk) 10:53, 16 September 2017 (UTC)

Wikimedia error

Just for documentation, I've gotten this several times today. However, it may not be Wikimedia. my computer is really slow and making a lot of noise. Usually after a few minutes have gone by after I turn it on all of this starting up activity ends. Something else is going on.— Vchimpanzee • talk • contributions • 16:24, 16 September 2017 (UTC)

Are you sure its a Wikimedia error? My Computer is running alright without making a lot of noise its virtually quiet. What system are you using? Have you checked for any viruses if using MS Windows? S. Little talk 16:58, 16 September 2017 (UTC)
I've had a few messages as well. Aiken D 17:08, 16 September 2017 (UTC)
I absolutely saw the words "Wikimedia error".— Vchimpanzee • talk • contributions • 17:09, 16 September 2017 (UTC)
It could be a glitch on Wikimedia's-side, though since I haven't experienced this problem have you filed a bug report with a detailed report about this? It could be related to them using a newer version of MediaWiki though I'm not sure. S. Little talk 17:51, 16 September 2017 (UTC)
It's just a "high server load" message. They'll know about it, no need for bug report. When you get this message, just use your browser's refresh feature (F5 in Firefox and Opera). You might need to do it two or three times, but don't do it too quickly. --Redrose64 🌹 (talk) 20:32, 16 September 2017 (UTC)
And in fact it doesn't necessarily mean the edit failed -- I had this happen earlier today and tried the edit a couple more times, getting the same error each time; I later found out I'd posted three copies of the same new talk page section. Mike Christie (talk - contribs - library) 22:15, 16 September 2017 (UTC)
Might be phab:T175803 but hard to say without a full error message. --AKlapper (WMF) (talk) 10:01, 18 September 2017 (UTC)
I sometimes get random errors but these are different than in this ticket. Something like the servers are too busy, please refresh. When it occurs it doesn't last long. An unrelated but more serious problem I lately get is when attempting to fix someone's broken signature, where the server worker thread appears to hang until the browser eventually reponds with a broken https connection (I get no error message from the server then, only from the browser). There might be some buggy edit filter involved... In this latter case, retrying the edit consistently reproduced the bug. —PaleoNeonate – 14:38, 18 September 2017 (UTC)
I have gotten the error message starting "Our servers are currently under maintenance or experiencing a technical problem" many times in the last days. The message is shown at Wikipedia:Wikimedia Foundation error but I also get it in other circumstances. Reloading usually works. PrimeHunter (talk) 13:49, 19 September 2017 (UTC)
Full text is:
Wikimedia
Error
Our servers are currently under maintenance or experiencing a technical problem. Please try again in a few minutes.

See the error message at the bottom of this page for more information.

If you report this error to the Wikimedia System Administrators, please include the details below.

Request from 87.115.199.145 via cp3040 cp3040, Varnish XID 1030324244
Error: 503, Backend fetch failed at Wed, 20 Sep 2017 09:08:56 GMT
plus one image. As I noted above, the browser's refresh feature (F5 in Firefox and Opera) clears this and shows the desired page. --Redrose64 🌹 (talk) 09:12, 20 September 2017 (UTC)

Email notifications linking pages with parenthetical disambiguators broken?

I'm not sure if it's just my email provider (yahoo.co.jp), but I noticed some time ago (and have largely been ignoring it) that the diffs of "this change" when someone edits a page on my watchlist that happens to include parentheses in the title are always broken, as the link cuts off mid-title; I have been getting emails saying that

  • To view this change, see

https://en.wikipedia.org/w/index.php?title=Wikipedia:Articles_for_deletion/Cultural_health_(2nd_nomination)&diff=next&oldid=800898836
which I imagine would be really annoying if the discussion at Wikipedia:Articles for deletion/Cultural health (2nd nomination) were more active and I was receiving piles of useless emails with links to the wrong page.

Any idea why this is? Is it a project-wide problem or is it because of the specific email address at which I am receiving the notifications? Sorry if this has come up before, but I couldn't find it on a brief scan of the archives...

Hijiri 88 (やや) 22:13, 16 September 2017 (UTC)

The mail is sent as plain text saying https://en.wikipedia.org/w/index.php?title=Wikipedia:Articles_for_deletion/Cultural_health_(2nd_nomination)&diff=next&oldid=800898836. Mail software (and other software like MediaWiki itself) will often try to convert some text strings to links, e.g. if they start with https://. It's common that they guess a link stops before certain characters like "(" and ".". MediaWiki gets this one right: https://en.wikipedia.org/w/index.php?title=Wikipedia:Articles_for_deletion/Cultural_health_(2nd_nomination)&diff=next&oldid=800898836. Help:URL shows percent encoding which could help such software but the link becomes less human readable with encoded characters like %282nd_nomination%29 instead of (2nd_nomination). PrimeHunter (talk) 23:24, 16 September 2017 (UTC)
You can test your mail software by sending this to yourself via Special:EmailUser:
Unencoded plain text:
https://en.wikipedia.org/w/index.php?title=Wikipedia:Articles_for_deletion/Cultural_health_(2nd_nomination)&diff=next&oldid=800898836

Encoded plain text:
https://en.wikipedia.org/w/index.php?title=Wikipedia:Articles_for_deletion/Cultural_health_%282nd_nomination%29&diff=next&oldid=800898836
Both strings are converted to correct links by my mail service. Sending it with your own mail software may invalidate the test by converting plain text to links before the mail is sent. PrimeHunter (talk) 23:41, 16 September 2017 (UTC)

Template help

Seventy-first session of the United Nations General Assembly
← 70th 13 September 2016 – September 2017 72nd →
Host country  United Nations
Venue(s) United Nations Headquarters
Cities New York City
Seventy-first session of the United Nations General Assembly
Host country  United Nations
Dates 13 September 2016 – September 2017
Venue(s) United Nations Headquarters
Cities New York City
Follows Seventieth session of the United Nations General Assembly
Precedes Seventy-second session of the United Nations General Assembly

Can someone add a "next" and "previous" tag (as in elections and sports templates) to the templates at General Debate of the seventy-second session of the United Nations General Assembly and Seventy-first session of the United Nations General Assembly.Lihaas (talk) 19:48, 17 September 2017 (UTC)

If you mean in the infoboxes then they currently (via redirects) use {{Infobox organization}} and {{Infobox summit meeting}}. The latter has the documented parameters follows and precedes. See 30th G8 summit for an example use. Do you mean you want an option to display it more like "← 2008" and "2016 →" at United States presidential election, 2012? {{Infobox organization}} has no next/previous parameters and they would rarely make sense so I don't think the infobox should be complicated with them. It does have predecessor/successor which make more sense for organizations but would sound wrong for General Debate of the seventy-second session of the United Nations General Assembly. PrimeHunter (talk) 22:43, 17 September 2017 (UTC)
@PrimeHunter: Yep I meant like the election article.Lihaas (talk) 00:30, 21 September 2017 (UTC)
I have added (not yet documented) a compactnav option to make compact navigation in {{Infobox summit meeting}}. The examples here show how Seventy-first session of the United Nations General Assembly could look with and without compactnav if the existing parameters follows and precedes are used. With compactnav I placed the date of the current event between the links like in elections. The image is commented out in the examples. PrimeHunter (talk) 01:20, 21 September 2017 (UTC)
Cool stuff; I can think of another use or two for that sort thing.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  01:47, 22 September 2017 (UTC)

HELP: Needs Userbox code?

HELP: Needs Userbox code?

IF Possible - At present, {{User UBX/WikiGlobalEdits}} (or "User:UBX/WikiGlobalEdits" ) on a user page (for example, see userbox below - or - in the middle right column of the "User:Drbogdan" profile) - requires that a specific UserName be manually added to the "Global Edit Counter" ( at https://tools.wmflabs.org/guc/ ) - and then - the resulting edit counts needs to be manually added to the template ( for example, {{User:UBX/WikiGlobalEdits|[https://tools.wmflabs.org/guc/ 55,002]}} )

Wikipedia-logo.png This user has made over
55,002 edits on All Wikis.

QUESTION: Is there a way of performing this procedure more automatically - by adding relevant coding?

Thanking you in advance for any help with this - Enjoy! :) Drbogdan (talk) 21:00, 17 September 2017 (UTC)

You can ask for template help at Wikipedia:Requested templates. I have coded it to automatically make the link based on the page name.[32] Wikitext doesn't have access to edit counts or query results so that part can only be automated if a bot or other tool periodically stores the counts for users of the userbox. They could be stored in a central page like User:UBX/WikiGlobalEdits/counts and automatically be read from there but somebody (not me) would have to code and run the bot. It could be requested at Wikipedia:Bot requests. PrimeHunter (talk) 22:21, 17 September 2017 (UTC)
By the way, the userbox currently says "on Wikipedia" but https://tools.wmflabs.org/guc/ includes all Wikimedia wikis, e.g. Commons, Wikidata and so on. PrimeHunter (talk) 22:25, 17 September 2017 (UTC)
There also exists a MediaWiki module to allow a special variable to expand to an edit count but it is not enabled and may never be (it was proposed and challenged, if I remember). There's an optional JS gadget for users to see their count (but that obviously doesn't update it for other editors). —PaleoNeonate – 22:37, 17 September 2017 (UTC)
@PrimeHunter and PaleoNeonate: Thank you *very much* for the *Excellent* comments - and suggestions - they're all *greatly* appreciated - may have to do a bit more homework with this to sort things out - in any case - Thanks again for the help - and - Enjoy! :) Drbogdan (talk) 00:19, 18 September 2017 (UTC)

Infobox font size

As a percentage of the page default, what is the font size for the body of an infobox? For verifiability, where in the code can this be seen? ―Mandruss  00:17, 18 September 2017 (UTC)

It may depend on the infobox, but the {{Infobox}} template invokes Module:Infobox which source shows a 125% default which also corresponds to the Infobox template documentation (which also shows abovestyle under its CSS section). I hope this helps, —PaleoNeonate – 00:26, 18 September 2017 (UTC)
I suspect the question was not about the heading but the fields inside the box. Infoboxes have class="infobox" which sets the size in MediaWiki:Common.css:
.infobox {
...
    font-size: 88%;
PrimeHunter (talk) 00:38, 18 September 2017 (UTC)
"for the body of an infobox" err, yes.Face-smile.svg Thanks, —PaleoNeonate – 00:45, 18 September 2017 (UTC)
Thanks. So, per Template:Small, which says 85%, use of {{small}} within an infobox field produces 74.8% of the page default (0.88 * 0.85), which is below the 85% minimum size specified in the last paragraph at MOS:FONTSIZE. Just wanted to be sure my head is screwed on right about that, and wanted to get the exact numbers. ―Mandruss  01:00, 18 September 2017 (UTC)
Please don't use {{small}} in an infobox; more on a recent similar case at User talk:RexxS#Small caption in infobox. --Redrose64 🌹 (talk) 07:49, 18 September 2017 (UTC)
User talk:RexxS#Small caption in infobox says 90% because it is about {{Infobox solar eclipse}} which uses Module:Solar eclipse where the default 88% is overridden with this: ["bodystyle"] = "width:25em; text-align:left; font-size:90%;",. PrimeHunter (talk) 09:12, 18 September 2017 (UTC)
Rose, I don't use {{small}} in infoboxes. I wanted to get the exact numbers to support my occasional removals of that. ―Mandruss  09:32, 18 September 2017 (UTC)

Edit view slow to load

Can anything be done about how slowly the edit view loads and, worst of all, the accompanying jumps as various elements load in succession? It happens too frequently that when I go to click something as edit view is coming up, the page shifts down slightly and I end up clicking on something else. The worst culprits seem to be the bar directly above and below the edit window: "B I ..." and "Insert – — ° ′ ″ ≈ ≠ ≤ ≥ ± − × ÷ ← → · § ...". Thank you, -- Black Falcon (talk) 01:21, 18 September 2017 (UTC)

@Black Falcon: I don't think they can do much about the speed of how it loads, since it's dependent on how fast your computer and network connection are, but you can turn them off in the Gadgets section of preferences. Jc86035 (talk) 03:26, 18 September 2017 (UTC)
@Jc86035: I don't think it's my network connection as I can load what should be more resource-intensive pages more quickly. It started, I think, after the edit window acquired its more "modern" look—e.g. the blue "Save changes" button instead of the previous grey version. I'll tinker with my preferences to see if I can improve it. Thanks! -- Black Falcon (talk) 04:34, 18 September 2017 (UTC)
Some time ago, I made my edit page loads significantly faster by going to Preferences → Editing and turning off both "Show edit toolbar (requires JavaScript)" and "Enable enhanced editing toolbar". I also turned on "Temporarily disable the visual editor while it is in beta" (I never use VE apart from trying it in the very early days), just in case the VE javascript is still being sent through when you click "Edit source" - it certainly was at one time. --Redrose64 🌹 (talk) 08:06, 18 September 2017 (UTC)
@Black Falcon: Which of the many toolbars ? there is a long list. —TheDJ (talkcontribs) 09:18, 18 September 2017 (UTC)
I didn't realize there were so many... WikiEditor is the one. It and CharInsert are always the last elements to load. -- Black Falcon (talk) 14:29, 18 September 2017 (UTC)
@Black Falcon: Can you check your preferences for me ? I suspect you have "Show edit toolbar (requires JavaScript)" disabled... It sounds weird (and it's a bug), but if you enable that, the reflow of at least the toolbar will be less. —TheDJ (talkcontribs) 05:22, 19 September 2017 (UTC)
@TheDJ: It's enabled; and as far as I recall, it has been. Incidentally, the lag is about 4–5 seconds from when the edit window appears (and I can start typing) to when the WikiEditor toolbar and CharInsert finish loading. Thanks, -- Black Falcon (talk) 04:39, 20 September 2017 (UTC)
Thanks, Redrose64, I'll try those tips. -- Black Falcon (talk) 14:29, 18 September 2017 (UTC)

Page moves logged twice

If I move a page from name X to page Y, it is logged in the page logs of both pages. OK so far. But as a result, it is also logged twice in my personal contributions list :: is this duplication needed? Anthony Appleyard (talk) 05:54, 18 September 2017 (UTC)

Yes. You can't have an action in a page history without it also being an action performed by an individual, and vice versa. Two on one means two on the other; it's like double entry bookkeeping - "for every credit there must be a debit". --Redrose64 🌹 (talk) 07:51, 18 September 2017 (UTC)
It may often look redundant in the main user contributions page but it can be filtered by namespace, one of the pages might be deleted so contributions are removed, and so on. PrimeHunter (talk) 09:26, 18 September 2017 (UTC)

Tech News: 2017-38

15:31, 18 September 2017 (UTC)

Commons category not working - links to main page

I have added a commons category template in Sveti Đurađ monastery. Hovering over the created link with my mouse pointer, it links to [36] which seems OK and works fine, when i copypaste the link and use it directly in my browser (in the URL edit field in Firefox). However, when I click the link in the article itself, it leads to [37]. Maybe some kind of conversion problem with the special character in the name or a problem within the template? GermanJoe (talk) 12:47, 19 September 2017 (UTC)

It works for me. The Firefox addon NoScript has done things like this as part of a defense against cross-site scripting in url's.[38] I haven't seen reports for a long time but see Wikipedia:Village pump (technical)/Archive 140#Redirect to Commons on one issue if you have NoScript. PrimeHunter (talk) 13:18, 19 September 2017 (UTC)
Thanks for the tip. Yes, it seems to be the same NoScript problem with parentheses and/or coded characters - disabling NoScript (for a second only) "fixed" the issue (for a second). Oh well, just have to remember it the next time not to bug you again :). GermanJoe (talk) 15:00, 19 September 2017 (UTC)

My Sandbox changed by other editors

Are other editors normally permitted to make changes and deletions in my Sandbox? (cf: User:Dthomsen8/sandbox/Streets/Cherry: Revision history)--Dthomsen8 (talk) 12:49, 19 September 2017 (UTC)

Depends on what the changes are really. Sandbox pages shouldn't appear in categories (unless for short term testing purposes), or contain BLP violations or personal attacks. If the sandbox is intended as a draft/collaborative space, they could also do some copy-editing. I don't consider the redirect as something productive. If the sandbox was derelict (or forbidden per WP:WEBHOST or something), blanking would be more appropriate. Headbomb {t · c · p · b} 13:09, 19 September 2017 (UTC)
Or copyright violations, these aren't allowed anywhere. Doug Weller talk 13:16, 19 September 2017 (UTC)
It looks like you copied from the sandbox to the article and not the opposite way but see Wikipedia:User pages#Content copied from mainspace. PrimeHunter (talk) 13:26, 19 September 2017 (UTC)
True, I did, but my concern was that I created the Cherry Street (Philadelphia) article in April, 2015, and liked to have that availabe. In that case, I see that there is a complete history, unlike some other Philadelphhia streets, which were deleted, and returned to me by an Administrator in my Sandbox.--Dthomsen8 (talk) 23:11, 19 September 2017 (UTC)
As you can see, my first edit to that sandbox was to update a category link, before I deleted the old category page. In other cases I have blanked stale user versions of live articles during such cleanup exercises. In this case I could see that the draft had been made live, so I thought a redirect would be marginally more useful, being the same result as if the draft had been moved to article space. WP:STALEDRAFT says Redirects from userspace subpages to mainspace are common and acceptable. However, I apologise if this came across as impolite. I'll change my practice and blank such pages rather than redirecting if people find that preferable. – Fayenatic London 07:33, 20 September 2017 (UTC)

Email confirmation never arrives "Hotmail"

I asked on the admin boards, they mentioned someone here might help as this has happened in the past with certain email providers. Yes I've checked my spam folder, and requested it be sent several times from here. No luck. Double checked there is no misspelling of the email address and revisited my email preferences. Anything else I should be doing to verify my email address? TIA Peniole (talk) 13:50, 19 September 2017 (UTC)

Is it related to Outlook's other current problems? BBC News - Microsoft confirms Outlook issues ? Cabayi (talk) 13:55, 19 September 2017 (UTC)
See Help:Email confirmation for general help. You can try another mail provider or just live without Wikipedia mail. It isn't required and most users rarely or never use it (but be sure not to forget your password). PrimeHunter (talk) 14:13, 19 September 2017 (UTC)

Actually signed up last year, no email confirmation then. Tried again this year, same problem. So unrelated to their recent outage. Thanks for the tip. Will see if I can get it sent to a secondary email address since Hotmail servers seem to block incoming from wiki.Peniole (talk) 08:10, 21 September 2017 (UTC)

My watchlist changed: Can't tell which pages are unread

So none of my pages that have changed since I last visited it are being bolded anymore. I highly rely on that. What happened to it?—CYBERPOWER (Chat) 17:11, 19 September 2017 (UTC)

  • +1 - As stated at Help Talk:Watchlist the new watchlist takes a good 10 seconds to load after every refresh (The previous took a second if that),
The other issue I have is that if I go to refresh the watchlist and then go on another tab - the watchlist won't load in the background - I have to physically be on the page for it to load,
IMHO this should be reverted back until the issues can be fixed, Thanks, –Davey2010Talk 18:07, 19 September 2017 (UTC)
@Cyberpower678: @Davey2010: Do you have the "New Filters for Edit Review" beta feature enabled? We changed that beta feature today so that it now puts the new filters on the watchlist as well. If you have the beta feature enabled, please try if disabling it fixes your issues. The styling of unread pages on the watchlist has a number of gadgets and other user/community-maintained things interfering with it. I updated the ones that we know about (e.g.), but maybe you're using something that we didn't know about and didn't update. --Roan Kattouw (WMF) (talk) 19:05, 19 September 2017 (UTC)
Roan Kattouw (WMF) you're a life saver! - I disabled that and it's gone back to the old watchlist, I had no idea New Filters was even enabled but yeah that seems to have been the cause for me, Thanks, –Davey2010Talk 19:11, 19 September 2017 (UTC)
@Davey2010: Well, we should still fix it :) . I think I found the culprit: your user CSS has a line (the last one, with line-watched) that unbolds changed lines. With the new Watchlist UI disabled, the gadget to bold such lines (which you've probably also enabled) wins out over that, but with the new UI enabled it doesn't. Since you seem to want to have bolding, you may want to remove the line in your user CSS that disables bolding. Cyberpower678 has something similar in their global CSS on meta (.mw-special-Watchlist .mw-changeslist-line-watched .mw-title { font-weight: normal; [...] }). --Roan Kattouw (WMF) (talk) 19:19, 19 September 2017 (UTC)
Roan Kattouw (WMF) - I've blanked the CSS and re-enabled New Filters - It took 8 seconds to load so still not overly quick, Also it's now bolded my watchlist which I disliked - Doesn't ever bother me at Commons or at Simple but does here, Anyway the loading time for me is 2 seconds quicker so not really a great improvement, Thanks — Preceding unsigned comment added by Davey2010 (talkcontribs) 19:33, 19 September 2017 (UTC)
  • @Roan Kattouw (WMF): Sorry, but I have all beta features disabled. Something else must have changed. I'd really like to get this function back.—CYBERPOWER (Around) 22:43, 19 September 2017 (UTC)
    The performance on this feature is intolerable. I, too, lost my bolding (which was added in my vector.css file). I just want the bolding back. I don't want the giant widgets, nor do I want the insane load time.Jorm (talk) 00:14, 20 September 2017 (UTC)
    Fixed it: .mw-changeslist-line-watched .mw-changeslist-line-inner span.mw-title { font-weight:bold !important; }
    You have to put "!important" on it now, I guess. Ugh.--Jorm (talk) 00:22, 20 September 2017 (UTC)
    @Jorm: Bolding should work in the beta feature without doing anything special; if it doesn't, that's a bug, or you have user CSS somewhere that overrides it. If you do not have the beta feature, English Wikipedia's confusing stack of gadgets means you have to explicitly enable a gadget to get the bolding, but it was like that before the release too.
    The load time issue is known and tracked at phab:T176250, we've got some patches in review for it already. --Roan Kattouw (WMF) (talk) 02:06, 20 September 2017 (UTC)
    @Cyberpower678: I was confused about what was going on in your case, but my teammate MFlaschen (WMF) figured it out. You have CSS in your global CSS on meta that puts the bold in (I was confused because it looks like it removes it, which it does, but then it puts it back a few lines later). That CSS doesn't work any more because of a change in enwiki's WatchlistBase gadget (the gadget that removes the bolding for everyone except people who choose to have it). There are two ways to fix this:
    1. Enable the WatchlistChangesBold gadget (Preferences -> Gadgets -> "Display pages on your watchlist that have changed since your last visit in bold"); or
    2. Change your global CSS from .mw-special-Watchlist .mw-changeslist-line-watched .mw-title { to .mw-rcfilters-disabled.mw-special-Watchlist .mw-changeslist-line-watched .mw-title {
    Jorm, you may have the same problem (and the same solutions) if you were using user CSS to put the bold in, rather than the gadget that English Wikipedia provides for that purpose. --Roan Kattouw (WMF) (talk) 02:19, 20 September 2017 (UTC)
    Thanks for that. But it does concern me that someone just unilaterally decided to have a gadget override my global CSS.—CYBERPOWER (Chat) 13:26, 20 September 2017 (UTC)
    @Cyberpower678: The goal was not to override user CSS like yours. That was an unintended side effect due to increased CSS specificity. Mattflaschen-WMF (talk) 01:12, 21 September 2017 (UTC)
+1 on the loading. It's more like five or six seconds for me—not 10—but if that can be fixed to load like the old design, I'd be just fine with that. I have no other issues with this change. Amaury (talk | contribs) 04:53, 20 September 2017 (UTC)

I can confirm the bolding of unread results is working fine for me without me having to change anything. I tested the performance a little bit, I found that for me the old version loads in around 2.7 seconds whereas the new version loads in around 4.2 seconds. That's not too bad for a beta version of this feature, especially since there's more performance improvements planned. I find the shifting of the watchlist items after the page is fully quite annoying, but to be fair this already happened to a lesser degree with the old watchlist due to watchlist notices. --Deskana (talk) 09:04, 20 September 2017 (UTC)

I created a ticket for that shifting phab:T176300. Note that watchlist notices only do this, if you don't dismiss them. They are hidden by default and then revealed when not yet dismissed. —TheDJ (talkcontribs) 09:32, 20 September 2017 (UTC)

Wikimedia Errors

Is anyone else getting a lot of these? Seems every page I click/edit on gives this at the moment. Text states:

Error

Our servers are currently under maintenance or experiencing a technical problem. Please try again in a few minutes.

See the error message at the bottom of this page for more information.

Also, I'm unable to compare diffs in the edit history - the pages don't load. I've tried this in several browsers this morning. Thanks. Lugnuts Fire Walk with Me 07:56, 20 September 2017 (UTC)

Please paste the "error message at the bottom of this page". I think that message includes your IP address (not sure). If it does, change it to x.x.x.x before pasting. Do you mean every page? Apparently WP:VPT worked, how about some short articles? Any particular page giving trouble? Johnuniq (talk) 08:03, 20 September 2017 (UTC)
I am getting errors too: "Request from xx.xx.xx.xx via cp3043 cp3043, Varnish XID 782598746 Error: 503, Backend fetch failed at Wed, 20 Sep 2017 08:06:28 GM" William Avery (talk) 08:07, 20 September 2017 (UTC)
@Johnuniq: - About 30 minutes ago it was every page, although it's calmed down a bit now. I did have the extra text at the bottom of the error, but it had my IP address, so I didn't post it. It's the same format as William's, above (thanks William). It took about five attempts to post this initial thread too. Lugnuts Fire Walk with Me 08:26, 20 September 2017 (UTC)
Known issue at T175803, which will be intermittent. You should soon be routed to a different datacenter -- There'sNoTime (to explain) 08:08, 20 September 2017 (UTC)
I've been seeing the "Our servers are currently under maintenance" error message more than usual as well. I assumed it was a rate-limit issue. power~enwiki (π, ν) 08:09, 20 September 2017 (UTC)
I too am finding that approximately every third page I access returns a 503. Looking at the Phabricator ticket it seems this has been going on for a week now. Is there any sign of progress towards a permanent fix? Yunshui  08:14, 20 September 2017 (UTC)
Fixes have been attempted, and some have definitely improved the situation - today has been especially bad, so the operations team have depooled the misbehaving server, and we hopefully won't see any more errors. This is only temporary, but a resolution is in the works Face-smile.svg -- There'sNoTime (to explain) 08:19, 20 September 2017 (UTC)
Anyone interested should definitely have a look at the linked task (its the most recent related task), and keep an eye on this dashboard - the spikes which cause these errors are "HTTP 500/503 Responses". On a brighter note, a moment of appreciation for the guys and gals in the operations team, who keep Wikipedia ticking along with over 7 million requests per minute - impressive! -- There'sNoTime (to explain) 08:37, 20 September 2017 (UTC)
Without tempting fate, it's been back to normal for the last 10 minutes. Thanks to everyone who looked into it. Lugnuts Fire Walk with Me 08:32, 20 September 2017 (UTC)
It's happening less often - but I'm still getting those same 503 errors fairly regularly. Yunshui  10:22, 20 September 2017 (UTC)
@Yunshui: Still getting these fairly regularly at the moment? -- There'sNoTime (to explain) 10:53, 20 September 2017 (UTC)
Haven't had one since I posted the above message, actually. Boy, is my face red... Yunshui  10:57, 20 September 2017 (UTC)
No drama, we should be 503-free for at least a little while Face-smile.svg -- There'sNoTime (to explain) 11:00, 20 September 2017 (UTC)

Watchlist: slow load times

Is there a temporary fix for this? Can I somehow disable Javascript only for the watchlist page rather than the entire domain? Thanks.—Cpt.a.haddock (talk) (please ping when replying) 10:19, 20 September 2017 (UTC)

Just disable the Beta feature. —TheDJ (talkcontribs) 11:21, 20 September 2017 (UTC)
Also see #My watchlist changed: Can't tell which pages are unread above. ​—DoRD (talk)​ 11:39, 20 September 2017 (UTC)
Thank you both. For anyone else wondering, this can be done within the Beta features tab in Preferences. You'll first want to uncheck Automatically enable all new beta features and then uncheck New filters for edit review.—Cpt.a.haddock (talk) (please ping when replying) 13:10, 20 September 2017 (UTC)

Mapping Hiragana and Katakana?

We recently got a suggestion via Phabricator to automatically map between hiragana and katakana when searching on English Wikipedia and other wiki projects. As an always-on feature, this isn't difficult to implement, but major commercial search engines (Google.jp, Bing, Yahoo Japan, DuckDuckGo, Goo) don't do that. They give different results when searching for hiragana/katakana forms (for example, オオカミ / おおかみ "wolf"). They also give different *numbers* of results, seeming to indicate that it's not just re-ordering the same results (say, so that results in the same script are ranked higher). (You can see more details of my tests on Phabricator.)

I want to know what they know that I don't! Does anyone have any thoughts on whether this would be useful (seems that it would) and whether it would cause any problems (it must, or otherwise all the other search engines would do it, right?).

Any idea why it might be different between a Japanese-language wiki and a non-Japanese-language wiki? We often are more aggressive in matching between characters that are not native to a given language--for example, accents on Latin characters are generally ignored on English-language wikis. So it might make sense to merge hiragana and katakana on English-language wikis but not Japanese-language wikis.

Thanks very much for any suggestions or information! TJones (WMF) (talk) 14:04, 20 September 2017 (UTC)

I have summoned WT:JP and WT:LANG here in case they may have feedback. --Izno (talk) 14:37, 20 September 2017 (UTC)

Deletions not showing in watchlist

And I have logged actions selected as a feature. I'm just trying to see if there is anything I'm missing or if there is already a phabricator task open on this before I create a new one. This is a major issue for me since I'm pretty active in NPP and seeing the status of articles in my watchlist helps me when I go back through to see if speedy templates/PRODs have been removed, etc. TonyBallioni (talk) 14:41, 20 September 2017 (UTC)

The "latest revision" filter seems to remove log entries. I hope that is a bug. —Kusma (t·c) 15:13, 20 September 2017 (UTC)
I'm pinging @Dchen (WMF): on this because I believe she worked on this project and might be able to answer the questions as to whether this is intentional or just a bug. TonyBallioni (talk) 15:41, 20 September 2017 (UTC)
@TonyBallioni: do you have the 'New filters for edit review' beta feature enabled? If so you can you verify the watchlist is working properly if you turn this off? — xaosflux Talk 15:52, 20 September 2017 (UTC)
@TonyBallioni: (ping fix) — xaosflux Talk 15:52, 20 September 2017 (UTC)
Hi TonyBallioni
Daisy has worked on design research but I'm the point of contact for the new filters system.
Can you share the filter combination you use with me? I'll investigate on this bug.
Thanks, Trizek (WMF) (talk) 15:54, 20 September 2017 (UTC)
@Xaosflux and Trizek (WMF): Yes, turning the beta off fixes the problem. I'd had it enabled a while ago and like the changes other than this small issue. The filters I currently have on are: changes by others, latest revision, page edits, page creations, logged actions. Unfortunately I'll be turning the beta off until there's an easy way for it to only show the latest revision but also show logged actions. TonyBallioni (talk) 15:59, 20 September 2017 (UTC)
TonyBallioni, can you add a recently deleted page to your watchlist and check if it is on your watchlist using the filters? It works for me if I only display logged entries, or when I remove "lastest revisions" filter. Trizek (WMF) (talk) 16:16, 20 September 2017 (UTC)
Trizek (WMF), yes, using only that one filter it shows up or removing "latest revisions". The problem is that the current non-beta version of the watchlist allows you to see the logged actions combined with only the latest revisions. If I want to see deletions combined with edits like I'm currently able to do in my watchlist, I should be able to have that as a setting without having to change the filters every time. This is a major step backwards for the watchlist. TonyBallioni (talk) 16:24, 20 September 2017 (UTC)
Thanks TonyBallioni. I've reported it and I'll keep you posted. Trizek (WMF) (talk) 16:39, 20 September 2017 (UTC)

Feature request: filter history by blocked accounts

I would find it useful if someone were to develop a gadget so that a page history could be filtered to show only edits by users who are currently blocked (mostly useful at SPI). There is already User:Ale_jrb/Scripts User History to filter history by one user's contribs, and MediaWiki:Gadget-markblocked.js for highlighting blocked users. Would someone more proficient than me be able to put those two together? Ivanvector (Talk/Edits) 18:30, 20 September 2017 (UTC)

I just created User:The Voidwalker/histFilter.js. It still needs some work (for example, it only checks the most recent 500 revisions and does things a bit sloppy), but it should work. (only tested in vector) -- The Voidwalker Whispers 22:44, 20 September 2017 (UTC)
Thanks, I'll try it out! (I'm using vector anyway) Ivanvector (Talk/Edits) 20:01, 21 September 2017 (UTC)
Okay so it works great, the only thing is it adds the "show blocked users only" button three times, and only one of them does anything; may have something to do with admin buttons. Can't post a screenshot at the moment, but I'm getting a working button beside "compare selected revisions" on the left, then two that don't work beside "change visibility of selected revisions" and "edit tags of selected revisions" on the right (these are both admin-only buttons AFAIK). But it's not really interfering with anything. Ivanvector (Talk/Edits) 20:09, 21 September 2017 (UTC)
I should have realized that was a possibility. I'll play with the selection statement for adding the button on a testwiki where I have those admin buttons. -- The Voidwalker Whispers 20:14, 21 September 2017 (UTC)

Pages jumping around while loading

I know that this has been discussed before, but it seems to be getting worse, leading to lots of misclicks. I inadvertently hit rollback twice recently, at least one of which was a page I hadn't even looked at, and today I hit the block button for Purplebackpack89 when I had intended to click on the diff above Purple's post on my watchlist. What needs to happen to get this fixed? SarahSV (talk) 15:23, 21 September 2017 (UTC)

The watchlist at Commons is bad for that: there's a box at the top which starts off zero height, then the JavaScript expands it to about two lines high; then it collapses to zero again, all in the space of a second or two. Whilst this box is visible, most of it is blank except for a link "Provide a translation or suggest a new notice" at upper right. But I have made lots of misclicks as a result. This is with Opera 36 in MonoBook skin. --Redrose64 🌹 (talk) 15:27, 21 September 2017 (UTC)
Pages jumping, happens when we add or hide content. The higher up the page, the more annoying it i. So sitenotices, watchlist notices, geonotices, etc etc. are super high impact for that. To counter it, we either need to start floating them OVER the page (historically disliked by people), or find a completely different spot for them all together. Or we can 10 fold or more our investment in technology, so that we can just serve every single person a page tailored just for them. Specifically for the watchlist however, it is currently rather bad if you are enrolled in the the beta for filters. This is being worked at, but in the mean time, you can disable the beta of course. If you have more specific idea of what content is being hidden, that is causing you grievance, then maybe it can be looked at, sometimes it can be made less terrible, though often not. —TheDJ (talkcontribs) 15:49, 21 September 2017 (UTC)
Thanks for the information. I've now disabled the beta for everything except preview, which is very helpful. I'll see whether that makes a difference. SarahSV (talk) 16:09, 21 September 2017 (UTC)
Another workround, thoough I expect you've thought of this, would be to use an alternate account without admin or rollback, etc, status. I disabled WikEd, which was such a pest, mainly because of a single icon it slid in and so shifted everything else. Thincat (talk) 18:32, 21 September 2017 (UTC)
That's a good idea, Thincat. I've never been clear about what causes it. So the admin tools do, WikiEd, I've already disabled Twinkle. Is there anything else obvious? Alternatively, if the ultimate cause is the addition or hiding of sitenotices, etc, would it not make sense to deal with those instead? SarahSV (talk) 21:37, 21 September 2017 (UTC)
Twinkle was fixed two weeks ago btw. Or well.. the dropdown TW menu i should say. Not where it adds all kinds of links to the diff or history page views. —TheDJ (talkcontribs) 22:16, 21 September 2017 (UTC)
I started a brief thread about this on wikimedia-l earlier this month, see [39] - there were some useful replies, particularly from @Krinkle: [40] and @Quiddity: [41]. I couldn't think of a useful way to follow up on them, though. Thanks. Mike Peel (talk) 21:52, 21 September 2017 (UTC)
Thanks, Mike. Quiddity, can the WMF do anything about this? When checking my watchlist recently, I twice misclicked rollback on pages I hadn't even looked at, [42][43] and didn't realize I had done it. See the bewildered response from one editor. I also misclicked the block button. It didn't lead to a block because that needed another step, but even so it's annoying, SarahSV (talk) 00:00, 23 September 2017 (UTC)
I surrendered the rollback right for that reason. Net negative. Of course that particular situation could be fixed by requiring a confirmation click per common software design principles, but that hasn't happened to my knowledge. ―Mandruss  04:19, 23 September 2017 (UTC)

A bot able to alert many WikiProjects to an RfC about a policy or guideline matter?

I wasn't sure if I should post this here or at WP:Village pump (idea lab), but it's a query about what Wikipedia might already be able to do. Recently, Newyorkbrad expressed a concern on my talk page about me notifying a number of guideline, policy and WikiProject talk page to an RfC that affects the Wikipedia community as a whole. I'd rather continue that discussion here or at Wikipedia talk:Requests for comment than on my talk page. He wondered if some of the notifications were relevant or appropriate. I noted that, in the case of RfCs that affect the community as a whole, I have been notifying a lot of pages (mainly WikiProjects) for years without incident and that it has helped pull in a lot more participants. I've done this ever since this RfC in 2014, where I contacted WikiProjects based on WP:RfC's "Issues by topic area" categorization format. Wikipedia:Requests for comment#Publicizing an RfC mentions that it is okay to alert the talk pages of policies and guidelines that are closely related, and WikiProjects that are relevant, but I asked Newyorkbrad: "How can we define 'closely related' in this case when the discussion at hand affects all of Wikipedia?" I told Tryptofish the following, "How can we judge which WikiProjects are more relevant to the discussion at hand? We cannot. And the same goes for our policies and guidelines, with the exception of WP:Manual of Style, which I also alerted. None of the WikiProjects are any more deserving of receiving a notification [...] that affects all Wikipedia editors, and I don't see the 'WikiProjects that are involved in setting policies or guidelines [...]. I am aware of WP:CENT. [...] I left a notification at WP:Village pump (policy), but I have found that this is not enough for cases such as these. Such limited notification usually only ends up notifying those who watch that page or are heavily involved in our policy and guideline issues. It leaves out the general Wikipedians. I've seen this complaint -- that there are a limited number of editors shaping our policy and guidelines and not enough general Wikipedians being alerted to the issues -- many times."

So other than WP:CENT, is there a way to alert editors to an RfC that affects the whole community, similar to the MediaWiki message delivery bot? If not, is such an implement worth it? Pinging WhatamIdoing since she commonly has insights into Wikipedia's technical endeavors. Also pinging editors from the latest RfC I advertised in case any of them came to that RfC via one of my alerts: Fyddlestix, Mandruss, Stickee, Johnuniq, Guy Macon, Andrewa, Redrose64, Diego Moya, Bkonrad (older ≠ wiser), NewsAndEventsGuy, North8000, PBS, Masem, Alanscottwalker, RexxS, Kudpung (Kudpung กุดผึ้ง), Moxy, Jytdog, JRSpriggs, Lawrencekhoo (LK), DIYeditor, BrightR (Bright☀), SlimVirgin (SarahSV), Piotrus, Ivanvector, Sizeofint, and Bondegezou. I already know that Doc James and a few others did. And, for the record, if there consensus that I shouldn't be alerting this way, I will abide by it. With the exception of WP:Manual of Style, SMcCandlish (who also took part in the RfC) reverted my notifications to the policy or guideline pages; so I know that he objects, at least on that front. And I know that I went a bit overboard on alerting the policy pages. Flyer22 Reborn (talk) 00:23, 22 September 2017 (UTC)

I have used massmessenger on meta. Centralized discussion does a fairly good job. Doc James (talk · contribs · email) 00:27, 22 September 2017 (UTC)
In the RfC that produced this issue, you correctly listed the RfC at Wikipedia:Requests for comment/Wikipedia policies and guidelines. You also advertised at WP:VPP. Between the two, you would've reached most editors who care much about changes to the p&g area, certainly enough people to reach a healthy level of participation and the point of diminishing returns (i.e. 150 editors are likely to produce the same conclusion as 50). Me, I don't watch VPP much these days, and I never watch the RfC listing pages. I trust that the editors who do will do things that I can live with. If not, that's on me. ―Mandruss  00:45, 22 September 2017 (UTC)
What about editors who are not heavily involved in building and/or editing our policies and guidelines, or the ones not involved at all? They care about some of these issues too. Over the years, I've gotten appreciative comments or thank yous via WP:Echo from such editors for my notifications because they would not have known about the issue(s) otherwise. Above, Doc James is one such editor. Flyer22 Reborn (talk) 01:02, 22 September 2017 (UTC)
(edit conflict) I think there's an uncorroborated assumption there. Is it true that 50 random editors are likely to produce the same result as 150 random editors? Sure - the Central Limit Theorem helps smooth it out. But is it true that 50 editors "who care much about changes to the p&g area" will produce the same result as 150 random Wikipedians? I suspect not. I applaud efforts to involve as many editors as possible as that tends to produce a more unbiased cross-section of opinion. Of course, there's no way of guaranteeing that, but the solution to anyone feeling that some notifications are biased is generally to notify more editors, not try to notify fewer by reversion. --RexxS (talk) 01:05, 22 September 2017 (UTC)
Flyer22: Well I think I addressed that in my previous comment. If one doesn't watch the two main pages having to do with p&g changes, they can't reasonably complain about the resulting p&g changes. I don't, and I don't. You might as well propose that we advertise all p&g RfCs to all these different pages. ―Mandruss  01:11, 22 September 2017 (UTC)
But, Mandruss, not all RfCs will affect the whole community. I'm talking about the big ones, like the aforementioned WP:TALK one. As for your point that editors should watch the two big pages, it's a sound point; I just don't think that many do. It seems that only a limited number do -- the ones heavily involved in policy and guideline matters. Flyer22 Reborn (talk) 01:20, 22 September 2017 (UTC)
WP:RFC lists four other topic areas under "Project-wide" topics: Wikipedia style and naming (style), WikiProjects and collaborations (proj), Wikipedia technical issues and templates (tech), and Wikipedia proposals (prop). All of these areas affect the whole community, per "project-wide". So we need to indiscriminately scatter-broadcast those, too, with the same rationale, correct? ―Mandruss  01:24, 22 September 2017 (UTC)
Not sure I get your latest argument. Flyer22 Reborn (talk) 01:44, 22 September 2017 (UTC)
You said, quite correctly, not all RfCs will affect the whole community. But certainly the topic areas listed under "project-wide" do, by definition? As SMcC's comments have implied below, it would be unwise to let the RfC's opener decide how much of the community is affected by it, since that will often be a matter of opinion and perspective. Scatter-broadcasting has to be all or none, and I submit that none is far better than all. ―Mandruss  01:53, 22 September 2017 (UTC)
"All or none" is obviously not my motto. I subscribe to RexxS's viewpoint above. I would state "many or none." The goal is not to manually alert every WikiProject there is; not only is that a huge task without a bot and some WikiProjects are likely to be overlooked, not every WikiProject needs to be notified. Like I told Newyorkbrad, what is important when alerting a number of WikiProjects to an RfC that affects the whole community is trying to get a wide range of views, the WikiProjects that cover topic areas such as science, medicine, math, culture, sports, women's issues and so on. Aiming for the big WikiProjects is key. The current way things are set up already decides how much of the community is affected by whatever RfC (and by "affected by" in this instance, I mean "alerted to"). If this were not the case, the many people who thank me for being alerted to the RfCs would already know about them without my involvement. All I am doing is pulling in more people. As far as the WikiProjects portion of Wikipedia:Requests for comment#Publicizing an RfC goes, it's useless for policy and guideline issues such as this since there is no way to state "this and this WikiProject is relevant, but not these." Flyer22 Reborn (talk) 02:09, 22 September 2017 (UTC)
If WikiProject Neuroscience needed to be notified about an RfC about a relatively minor aspect of talk page behavior in all talk spaces, and other projects did not, I'm interested to know how you arrived at that decision. Are there projects that don't involve discussion in a talk space? Anyway, a major and controversial change like you are suggesting will not be made without an RfC consensus, so I'll try to watch for that RfC, which should be placed at WP:VPR. ―Mandruss  02:24, 22 September 2017 (UTC)
I stated above that ever since this RfC in 2014, where I compiled a list of WikiProjects based on WP:RfC's "Issues by topic area" categorization format, I've been following that list. A few of those WikiProjects are semi-active, but I contacted them anyway. One is inactive, and I did't contact that one this time. Over the years, I've been contacting other WikiProjects in addition to that list. I should have left WP:Neuroscience off the list since WP:Med covers it well enough (editors watching that WikiProject are usually WP:Med editors). As for a bot, you're right, but I do think further discussion about the Wikipedia:Requests for comment#Publicizing an RfC wording should perhaps take place at Wikipedia talk:Requests for comment. I mean, in cases like these, does one alert any WikiProjects or not? Flyer22 Reborn (talk) 02:35, 22 September 2017 (UTC)
Agreed with Mandruss. I actually reverted many of those notices myself (after the outcome was already WP:SNOW) to discourage anyone else from thinking that hitting every highly watchlisted Wikipedia-namespace talk page was an RfC notification norm. Our P&G talk pages would become unusable if people started doing this, even in small numbers. And that RfC didn't and won't "affect the whole community"; it was noise about a rare, almost imaginary minor problem; I think I saw a total of 4 cases anyone could point to, all them either noobs who hadn't learned our talk page etiquette yet, or generally disruptive parties headed for long-term blocks for multiple reasons. The comments are an interesting read, a thick pile-on of "don't you dare touch my posts!" WP:OWN chest-beating. That kind of RfC doesn't attract commentary from anyone but people with a weird bone to pick.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  01:29, 22 September 2017 (UTC)
We disagree on the RfC; I think the comments from others there have shown a convincing concern about the issue its tackling. I've had non-newbie editors break up my comments, and my objections were never a WP:OWN violation. I always made it clear that the "breaking up" had confused things or was likely to confuse things. And, for the most part, we do own our comments, which is why others are generally not allowed to touch them. The exceptions are clear at WP:TALK. Flyer22 Reborn (talk) 01:44, 22 September 2017 (UTC)
I'm reiterating some of the above, but this is what I do rather methodically:
  • Make important policy discussions be WP:RFCs with |policy; this will ensure that WP:FRS subscribers who subscribe to the policy RfC feed will get drawn in. (This does not happen instantly; I'm not sure what the algorithm is, but there's some kind of randomization, and not everyone immediately gets a note about every RfC in the categories they're watching, even if they're set to get all of them. They get doled out over time.)
  • Post a pointer at WP:VPPOL (or even host the RfC there). The whole point of VP is that it's where the community members who don't just WP:DGAF come and look for site-wide issues to resolve. If it's of the nature of a proposal for some major change, not just a tweak, it can also be cross-listed on WP:VPPRO.
  • If I'm sure it's going to be of wide-spread interest, list it on WP:CENT. Once in a while someone may revert a listing if they think the entry is trivial or of too micro-topical interest; most sensible entries seem to stick.
I wouldn't mind a notification system more quick and sure than FRS, or just a change to FRS so that I can tell it "notify me of every policy-categorized RfC, immediately". A lot of editors would rather eat their own feet than subscribe to that, but some of us are keenly interested in long-term policy stability and continuity, yet also flexibility, as WP grudgingly matures into another stage of the organizational life-cycle.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  01:29, 22 September 2017 (UTC)
PS: "there are a limited number of editors shaping our policy and guidelines" – Yes, of course. This is true – and necessarily true – of all human endeavors. WP:Writing policy is hard, and policy analysis is a professional-level skill that is difficult to learn much less excel at. When people who suck at it and/or don't care end up getting affected by policy in ways they don't like they make a lot of noise, and the people who are competent and interested enough to re-balance the policy make some adjustments. This is how our species operates.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  01:33, 22 September 2017 (UTC)

For what is worth, I concluded in a peer review paper that Wikipedia's anti-canvassing / don't spam people POV means that 99% of the community is kept in the dark about important issues, while crucial decisions are being shaped by a small number of people - not intentionally, but just the lucky ones who saw the right notice or were more active in a specific time period. We need a better way to inform people about important stuff everywhere. This is doable, we just need to want to do it. You may find the article interesting ([44], OA mirror). --Piotr Konieczny aka Prokonsul Piotrus| reply here 03:29, 22 September 2017 (UTC)

Piotrus, thanks for weighing in. WP:Canvassing is a different issue than notifying a number of WikiProjects to a policy or guideline issue. We see that it lists the following as an appropriate form of notification: "The talk page or noticeboard of one or more WikiProjects or other Wikipedia collaborations which may have interest in the topic under discussion." It doesn't give an exact number. And like I noted above, I feel that the issue at hand is not of interest to any one WikiProject, but to all of them. As for contacting all of them, see what I stated above. Flyer22 Reborn (talk) 03:41, 22 September 2017 (UTC)

I can see why Flyer22 wanted to notify many projects about the interleaving RfC. Most editors would correctly think they should work on articles rather than pay attention to esoteric guidelines. Yet those editors may want to know about an RfC that could affect behavior on the talk pages they use. I can also see why some others do not want widespread notifications—if that became the norm, projects would be overrun with spam. I would not want to see an automated system to spread notifications because that would be overused and would lead to wholesale reverts and/or banner blindness. If considered appropriate, WP:centralized discussion or even WP:watchlist notices could be used—if others felt the issue warranted wide dissemination. Johnuniq (talk) 03:53, 22 September 2017 (UTC)

Good point about the overrunning. If we did have a bot for this, I guess we wouldn't always be able to decide which cases it should be used for. Flyer22 Reborn (talk) 04:01, 22 September 2017 (UTC)
But then again, Johnuniq, we don't have a lot of policy and guideline RfCs. It's more so occasional. Flyer22 Reborn (talk) 05:06, 22 September 2017 (UTC)
Agreed, but as you know, there are many people with unusual views at Wikipedia and they would be sure to want to maximize publicity for whatever they thought was important. Re policy/guideline RfCs being rare, that might be a good reason to list the RfC at the central or watchlist links I mentioned. Johnuniq (talk) 05:18, 22 September 2017 (UTC)
I'll bring WP:AALERTS as a possibility for smaller RFC topical to a small number of projects, or for project to be notified or certain discussions happening on specific venues. Headbomb {t · c · p · b} 06:13, 22 September 2017 (UTC)
In this recent case, I found {{u|Flyer22 Reborn]]'s approach helpful and only came to the RfC because of the note on WikiProject Medicine. Bondegezou (talk) 09:47, 22 September 2017 (UTC)
I was pinged above. Flyer, for discussions about policies or guidelines, you could reasonably ping WP:WPMOS and WP:WPPG. You could also list them at related policies and guidelines. For example, some editors watch WP:V and some watch WP:RS and others watch WP:NOR, and if there's an RFC at one, it's reasonable to post links at the other two.
We don't have a way to notify a representative set of active editors. I doubt that the core community truly wants such a thing, since it would mean a greater voice for people with less experience, and therefore mathematically less voice for people like us.
As for the instant case, an interesting thing to do would be to find several recent examples of interleaved comments that did not involve you personally, and ask those editors (the person who wrote the original comment and the person who inserted something) to comment. They are far more likely to have a useful, practical view of the question than editors who've never seen it, and they're the ones whose comments you're proposing to protect (for the original editor) or ban (for the interjecting editor). I recommend posting those examples in the discussion at the RFC (or a note saying that you couldn't find any, because that would also be relevant information in a WP:CREEP-prevention kind of way). WhatamIdoing (talk) 17:35, 22 September 2017 (UTC)
  • Thank you for the ping, and thank you for seeking community views about the issue. I agree with Mandruss and SMcCandlish, as well as with what Newyorkbrad originally said at Flyer22's talk page. What drew my attention to the matter was seeing a note at WT:WikiProject Neuroscience – why is talk page interleaving of any special interest to editors who work on neuroscience content, aside from the subjective opinion that the issue is supposedly an important one to everyone at Wikipedia? – after having seen the same note at WT:Conflict of interest – I doubt that editors with COIs interleave their comments more or less than other editors do. Now, that said, I don't see what Flyer22 did as being anything really awful (had it been, it would have been a matter for WP:ANI, and it clearly was not that), but rather, as a matter of subjective judgment. Myself, I would have considered listing at RfC and CENT, along with a VPP note, as being entirely sufficient and appropriate. I do not see any reason to believe that any user felt badly disrupted by the notices, but I think some editors found them a waste of time while others found them helpful. So I think that it comes down to a subjective judgment about the degree to which the benefit of more editors finding out about the RfC balances out the feeling of wasted time experienced by editors who felt that there were too many notices. Don't overestimate the benefit of such wide publication in this case. There is nothing that stops editors from watchlisting RfC notices and checking CENT and VPP from time to time if they want to. And frankly, although the RfC was about talk page guidelines, it really wasn't something that rose to the level of something that required community-wide alerts. It pretty much became a consensus of "yeah, please avoid interleaving, but if you do interleave, it's not the end of the world". Hardly groundshaking, hardly controversial. There's a more subtle issue here as well: should every RfC where the posting editor wants wide participation be so widely announced? If not, is there a problem with some discussions being more widely evaluated than others, whereas if so, how much potential spam will this lead to if everyone does it? Do we really want to make this standard practice? And please don't underestimate the inconvenience of editors who didn't need to see the notices in so many places. Editor time is a valuable commodity. Of course, editors who are not interested can just ignore the notices, but nonetheless that happens after having spent a few moments reading the notice and then deciding not to respond. And the community has something of a consensus against spam – just see what WP:Canvassing#Inappropriate notification says about it. Most interested editors would have found the RfC without so many notices, and even though some editors responded after seeing the WikiProject notices, most editors who watch WikiProjects did not. So, bottom line, it was marginally a net negative. It was bad judgment and probably not a good precedent, but not a high crime or misdemeanor. --Tryptofish (talk) 18:13, 22 September 2017 (UTC)
  • Flyer, thanks for the ping and the only thing that matters to me when there are pings is whether I was pinged as part of a POV based canvassing campaign, which this isn't. Go for it. I have no opinion on the existing or proposed tools other to say thanks to those eds interested in the subject. NewsAndEventsGuy (talk) 22:05, 22 September 2017 (UTC)

New account creates a new account while logged in

Please see these log entries in UTC time:

  • (User creation log); 03:02 . . User account Yutaui123 (talk | contribs) was created by Yutaui (talk | contribs) ‎(it won't let me)
  • (User creation log); 03:00 . . User account Yutaui (talk | contribs) was created ‎

How can that happen? Dr. K. 03:36, 22 September 2017 (UTC)

This is normal. Special:CreateAccount can be used by already logged in users to create another account. I deliberate did it myself when creating alternative accounts.[45] PrimeHunter (talk) 09:33, 22 September 2017 (UTC)
Thank you PrimeHunter. I didn't know about that. The thing is, how can a brand-new account know the existence of that link. Dr. K. 11:13, 22 September 2017 (UTC)
Maybe they didn't realize that they were logged in already and tried to register again, were told that it is already registered and then registered an alternative name? Just guessing of course. Have you asked them before labeling them a sockmaster? Regards SoWhy 11:57, 22 September 2017 (UTC)
Yes, after creating the first account and being logged in they may just have used the browser back button to get back to Special:CreateAccount. That is the page logged out users get on "Create account" at the top of any page. Both the accounts edited the same article against Wikipedia:Sock puppetry#Inappropriate uses of alternative accounts but attempted deception is unlikely when the usernames are so similar. It looks like a good faith mistake. PrimeHunter (talk) 12:54, 22 September 2017 (UTC)
They could also be familiar with MediaWiki generally, even if new to enwiki :) FACE WITH TEARS OF JOY [u+1F602] 17:49, 22 September 2017 (UTC)
Thank you both. I had not considered these possibilities. :) Dr. K. 18:25, 22 September 2017 (UTC)

Is content font size too small?

For years I have felt that content size is too small. The font size is set at the Vector skin repo. It cannot be changed without a community consensus, so I started this poll:

https://docs.google.com/forms/d/e/1FAIpQLSe7ZzgS46IrkeVEuwsQQeElPH-PddONfE2e4_9pKhApr-fQgQ/viewform (google form).

Golopotw (talk)

I think that an on-Wikipedia RFC may be better. Also, browser features (i.e. ctrl++ on most), browser preferences, or custom CSS (User:Golopotw/common.css) could be used to have text as large as you would like. —PaleoNeonate – 07:28, 22 September 2017 (UTC)
@Golopotw: Please don't make us go outside the Wikimedia Foundation to discuss Wikipedia matters. --Redrose64 🌹 (talk) 10:43, 22 September 2017 (UTC)
@Redrose64: It is a polling tool unavailable in WMF softwares. It does not take away discussions from this thread because it does not have a discussing feature.Golopotw (talk) 11:07, 22 September 2017 (UTC)
Golopotw, are we not discussing something here? Do you really think that nothing has been discussed or decided on Wikipedia in all the years its been running? How will you verify whether contributors to the google doc are wikipedians? not blocked? not sockpuppets? Wikipedia guarantees the anonymity of wiki-users - how will you preserve that anonymity on google docs? Frankly, I don't see any way that the results of an off-site discussion would be acceptable on Wikipedia. Cabayi (talk) 11:20, 22 September 2017 (UTC)
@Cabayi:It is not google doc, it is a polling app and what is did is complementary to what happens here. You click Yes or No and submit, and get the count, that all it does, no discussion happens there. The people who participate are all Wikipedians seeing this thread. It is possible someone do corrupt things to bend the data, though. Seeing so much discussion diverting from the original question makes me want to remove it now.Golopotw (talk) 11:44, 22 September 2017 (UTC)
Any result from an off-wiki poll outside Wikimedia control will almost certainly be ignored when a decision is made so I don't see much reason to keep it open. Users who do participate will just be wasting their time. PrimeHunter (talk) 12:23, 22 September 2017 (UTC)
Golopotw, If you're concerned about vote counting you ought to (re-)read Wikipedia:Consensus. Cabayi (talk) 17:33, 22 September 2017 (UTC)
Without wanting to be rude, if you are finding that the font size on Wikipedia is too small for you to read comfortably, then you need to either use a physically larger monitor, use reading glasses, or increase the zoom of your browser until the size is comfortable. Wikipedia is by no means the only popular website to use fonts at around 14px size (12.7px for Monobook), so there must be lot of readers for whom the current size is an acceptable compromise between legibility and the amount of text that is in view without scrolling. I doubt you'll be able to disturb the current (silent) consensus just to please folks like me who need glasses to read Wikipedia. --RexxS (talk) 17:07, 22 September 2017 (UTC)

Article with 201 unverifiable references due to exceeding the 2 MB template include size

If you load Cities and towns during the Syrian Civil War (which is under community sanctions) you are immediately confronted huge and extremely detailed map, a Lua module found at Module:Syrian Civil War detailed map. Unless your experience is very different from mine, you will only see part of it. It's a thing of beauty which can be expanded to show extraordinary detail. Hold the mouse over a place to see its name pop up, and click a link for details. It is a magnificent achievement and is a great resource for those who want that detail. Warning though, it doesn't exactly load quickly.

Once you get the article fully loaded, if you look at the references section you find that there are 348 references, but Chrome's find function shows that 201 of them show no sources but only " Template:Cite web", " Template:Cite news" etc. The technical problem which causes the broken templates is that the 2 MB template include size is exceeded.

I've got several issues with this. The first of course is that all sources must be verifiable, and we have over 200 that can't even be identified in an article under sanctions.

I don't think that the map itself is appropriate for an encyclopedia and in practice can be almost unusable depending on your browser, number of tabs open, bandwidth, etc.

This makes the article almost not fit for purpose if anyone who has ordinary or low bandwidth, which probably includes most of the people who actually are physically in the area of the map.

Any suggestions as to how this can be fixed? Thanks. Doug Weller talk 07:51, 22 September 2017 (UTC)

I've made a BOLD suggestion. power~enwiki (π, ν) 08:06, 22 September 2017 (UTC)
I remember that article and previously commented about it on its talk page. There are so many templates that the expansion exceed the allowed server-side processing time limit... The reflist would not show too, until replaced by a tag instead of the template. —PaleoNeonate – 09:22, 22 September 2017 (UTC)
Thanks. We'll see if having a link to the map template sticks. That's really the only choice I think given that the map gives an include size of 1900092/2097152 bytes leaving no room for most of the other templates. Now that's done, you can see the citations. Doug Weller talk 09:28, 22 September 2017 (UTC)
Other choices are harder to implement. The used module produces a huge number of consecutive entries similar to this:
<div style="position:absolute;top:17.143%;left:70.09%"><div style="position:absolute;left:-3px;top:-3px;line-height:0">[[File:Dot yellow ff4.svg|5x5px|[[Tell Nasri]]|link=]]</div><div style="font-size:0%;position:absolute">[[Tell Nasri]]</div></div>
The code could be shortened (I don't want to work on it). PrimeHunter (talk) 09:43, 22 September 2017 (UTC)
@Power~enwiki: thanks for the current solution, —PaleoNeonate – 09:50, 22 September 2017 (UTC)
For people or configurations that prefer/need a less detailed map (smaller size) there is the overview map. You find it on https://en.wikipedia.org/wiki/Template:Syrian_Civil_War_overview_map.
For all the people for wich the high detailed level is a necessity, there is the https://en.wikipedia.org/wiki/Template:Syrian_Civil_War_detailed_map
So just use the overview map instead if the detailed is to extended for you're preference or for this specific wikipage/articla.
The article is about cities and towns, so including the overview-map with only towns, cities and strategic places is more fit than including the detailed map in to this article.--Niele~enwiki (talk) 11:48, 22 September 2017 (UTC)
Does this solve the loading problem? I've got very fast internet so I can't tell. Doug Weller talk 12:42, 22 September 2017 (UTC)
Hmm, it seems some people are confusing Wikipedia with an OpenStreetMap layer... Our technology is not optimized to scale for usecases like these. I suggest choosing a different approach. —TheDJ (talkcontribs) 12:46, 22 September 2017 (UTC)
It is, however, a pretty awesome map, and as maps are commonly found in encyclopedias, it is strange that we have so few customised clickable maps in Wikipedia. Can we improve our technology for cases like this? —Kusma (t·c) 12:54, 22 September 2017 (UTC)
Possibly that a lazy ad-hoc effort would be a bot regularly updating/generating a screenshot of maps designed for it (or placed in a category for it), so the article could use the generated svg or png image instead... I'm not sure if a MediaWiki module doing the equivalent more transparently already exists (if so, enabling it on en-Wikipedia might be another challenge)... —PaleoNeonate – 13:05, 22 September 2017 (UTC)
ON THAT NOTE, let's advertise the better alternative. --Izno (talk) 13:19, 22 September 2017 (UTC)

Rogue Bot

The Internet Archive Bot has been tagging HathiTrust links as dead links. See Equipollence (geometry) for example. The Talk of the Bot does not recognize a logged in editor, so the "tool" offered is in fact not available. Comments on the Talk are discouraged. — Rgdboer (talk) 20:51, 22 September 2017 (UTC)

I reported the false positives using the interface. — JJMC89(T·C) 21:30, 22 September 2017 (UTC)

Proposals

Upgrade WP:DRAFTIFY to policy or guideline and disallow moves to Draft- or userspace without discussion or consent

Since it's been pointed out to me that currently a number of editors believe in draftifying articles without prior discussion or request/consent (see previous discussions here and here for example), I hereby suggest that the WP:DRAFTIFY portion of WP:Drafts is given the status of policy (or at least guideline) and that it's clarified that moves that are not the result of i) a deletion discussion, ii) an undeletion request, or iii) userfication [upon request] are not allowed, except by an admin as an alternative to speedy deletion (provided the article could have been deleted otherwise).

The reasoning is this: Such moves circumvent the deletion policy by removing articles from mainspace without either discussion at WP:AFD or applicability of WP:CSD. Just as admins are not allowed to outright delete such articles if they don't fall under WP:CSD, so other users shouldn't be allowed to "pseudo"-delete them by removing them from mainspace without prior discussion. While such drafts might still be available (until deleted under a new G13 as proposed after six months), they are removed from the public eye, the result is thus the same as with outright deletion. Also, such moves usually violate WP:IMPERFECT and WP:PRESERVE, since either the topic is notable enough for inclusion - then it should stay in mainspace - or it is not - then it should be deleted.

While I understand that some editors feel that they are actually helping the project by draftifying content that would otherwise be deleted, allowing such moves without prior discussion is too risky, especially if G13 is expanded to allow deletion of all pages in Draft: space just based on age. Regards SoWhy 13:02, 8 August 2017 (UTC)

IMO, any speedy deletable content may be draftified; if it's subsequently deleted under G13, it can be REFUNDed by request of a user who intends to work on it. עוד מישהו Od Mishehu 13:09, 8 August 2017 (UTC)
This proposal is about content that is not speedy deletable. I won't argue that we shouldn't draftify instead of deletion. I've clarified it above. Regards SoWhy 13:13, 8 August 2017 (UTC)
Actually, it isn't. This proposal specifically disallows draftification as an option to non-admins even when speedy deletion criteria apply. — InsertCleverPhraseHere 14:57, 8 August 2017 (UTC)
If an article is about a clearly notable topic, but is so appallingly written that it shouldn't be visible to readers of the encyclopedia in its current form, then moving to draft space is a sensible move until it can be fixed. Peter coxhead (talk) 13:17, 8 August 2017 (UTC)
@SoWhy: I'd recommend waiting on the close for the current discussion to expand G13 before we discuss this. My opinion would change based on whether we'd be retaining these drafts indefinitely or not. ~ Rob13Talk 13:17, 8 August 2017 (UTC)
Unfortunately, the current proposal does not make an exception for such drafts, which is the reason I brought this here in the first place. Regards SoWhy 13:38, 8 August 2017 (UTC)
@SoWhy: I'm not sure exactly what you mean. My point is that if G13 is not expanded and draftifying stuff means indefinitely retaining something unsuited for mainspace, I'd oppose this. If it is expanded, I would need to think on it more, but I'm leaning support. ~ Rob13Talk 15:51, 8 August 2017 (UTC)
  • Oppose PRESERVE says nothing about this (or deletion, by the way), and anyway we have WP:DON'T PRESERVE right below it that points out when removal may be appropriate. While I appreciate SoWhy's concerns, I think they are very far removed from the practical use of this tool and also would serve to create a distinction between admins and non-admins on the use of the move tool. The content that I move to draft is either 100% in violation of WP:V, is speedy deletable, or is an abandoned article that is so poorly formatted with few sources to the point where it would be likely PRODed or CSD tagged and deleted regardless of the actual content in it. Moving content like this to draft to give the user time to improve it rather than taking to to AfD, or PRODing It, or CSD tagging it is the definition of not biting newcomers and BOLDly improving the encyclopedia rather than letting it sit and rot in main space or be deleted. TonyBallioni (talk) 13:21, 8 August 2017 (UTC)
Both WP:DEL and WP:DPR are quite clear on how articles can be deleted: CSD, PROD or AFD. Moving to draft-space? Not on that list. In fact, WP:DPR explicitly mentions it as a potential outcome of a deletion discussion. Saying you move content that is a violation of WP:V or because it's poorly formatted is basically my point: Both are either fixable - then per WP:IMPERFECT they should stay - or they are not - then what's the point of moving it to Draft-space? After all, doesn't policy say Even poor articles, if they can be improved, are welcome.? Regards SoWhy 13:38, 8 August 2017 (UTC)
SoWhy, except draftification is the exact opposite of deletion, which is why it has no business being in the deletion policy. As for WP:V: if there is a two sentence stub about a village with nice palm trees in Foo that searching provides no sourcing and is completely inappropriate for mainspace there are three options: blank and redirect, PROD, or send to draft. Draft:Cantabaco is an example of the type of article that would easily be deleted via PROD for failure of WP:V, but is notable as a named placed and the author should be given more time to update it. Sending it to draft is much better than either redirecting or PRODing.
We also get articles such as Draft:Nerds On Ice that would be G2 eligible. Also ones like Draft:Loctote that were apparently AfC submissions that were accidentally created in mainspace. I can go through countless other examples, but draftification is actually a major tool in upholding WP:PRESERVE, a policy I know you care deeply about. TonyBallioni (talk) 14:00, 8 August 2017 (UTC)
It removes articles from sight, so how is it different from the reader's point of view? As for your examples: If it's a village, WP:GEOLAND says it's notable, so remove the incoherent stuff and leave it in mainspace. The second is an AFD submission in mainspace, not an example of draftifying. The third example is not really something to be proud of. Draftifying within seconds of creation? Most likely the user was working on it but when they were done, the page was gone and they left the project for good. Regards SoWhy 14:21, 8 August 2017 (UTC)
Except that notability isn't the issue. Of course it was notable, the question is whether or not we should delete a notable article that fails our most central content policy (per WP:DEL7) or whether we should give the author time to develop it. I vote for giving the author more time to develop it. Re: Draft:Nerds On Ice, the creator was clearly trying to create a draft article and moving it to the right namespace for them to have that opportunity is already anticipated by WP:PM/C#3. Its the exact same as the AfC submission above, and if it weren't draftified it would have been deleted within minutes via G2 by someone who is much less conservative than I am on G2. I was acting quickly to prevent deletion because the front of the feed is where overtagging for CSD is most common. I'm also pinging Boleyn, who is one of our best and most dedicated reviewers, as a courtesy since you used an article she touched as an example below. TonyBallioni (talk) 14:29, 8 August 2017 (UTC)
But that's the point, isn't it? If the subject is a geographic location, source will exist. So why move to Draft when you could easily spend five seconds on GBooks and add a source? Doesn't that violate WP:FIXTHEPROBLEM? After all, this is a project that strives on collaboration, so why should any one editor be responsible to "develop it"? ICPH bemoans below that "tag bombing" is not the correct solution but how is moving stuff out of sight any different? Both imply that it's somebody else's problem when in fact it's ours. And leaving it in mainspace at least allows others to fix it. Regards SoWhy 15:52, 8 August 2017 (UTC)
SoWhy, the issue is as ICPH points out below that no one fixes it, and per WP:CANTFIX when this is the case it might justify removal from article space. Most of these types of articles require knowledge beyond a simple Google Book search to fix the problem: I know absolutely nothing about the Philippines, and that Google Book search told me nothing that was of use in verifying the content in the article or in creating what you would expect for a geographic article. I assume the article creator will know enough about the article to find sources and improve it and then move it to mainspace. Draft space is a much better place to do this. This is similar to when I remove CSD tags I leave a note for the nominator rather than sending it to AfD myself if I think it should be deleted: I assume the first person who spots the issue is going to be better at explaining their reasoning than I am, and giving them the space to do it is important. I think this principle applies even more for content that someone who isn't a generalist wouldn't be able to verify. TonyBallioni (talk) 16:13, 8 August 2017 (UTC)
(edit conflict) SoWhy. Editor discretion is what is needed to decide the appropriate action in each specific case, not a top-down ban of draftification. If it looks like the editor might keep working on it, I'd draftify an article rather than leave it to get PRODed or worse by another less-kind patroller. A big deletion notice tends to discourage editing... why bother if it is going to be deleted anyway? but draftification with a message indicating how the problems can be solved can encourage further editing. Generally the only editors that see stuff in the New pages feed are patrollers anyway, as these articles are not indexed, so either you are suggesting A) we should tag bomb articles and then mark them as reviewed and hope for the best in 'the wild', or B) that NPP has an obligation to improve every half-baked article with a potentially notable subject that comes into the feed to an acceptable standard, regardless of how bad it is.
All of this supposes whether we are sure that the subject even is or is not notable. In many cases the subject is a two line article with a couple crappy blog sources about some Pakistani actress that may or may not be notable, and all the potential sources are not in english. Or else it is a single sentence article on a long dead scottish playright with one dubious cite to an offline source that may or may not be reliable, or can't be confirmed to exist, and where most other likely sources are offline as well. These sorts of grey area examples are where draftification is often a very good fit, and NPP often is not black and white the way you want it to be. — InsertCleverPhraseHere 16:22, 8 August 2017 (UTC)
──────────────────────────────────────────────────────────────────────────────────────────────────── I think there is some misunderstanding here. I don't oppose draftifying per se, in fact, I believe it to be a good alternative to deletion where possible. What I do object to is unilateral draftifying, one editor deciding an article is not worthy of inclusion or not fit for inclusion even when it would not be deleted at AFD and speedy deletion is not applicable. The current practice relies on a single editor (sometimes with an user right he got from a single admin (w/o discussion usually)) making the "right" call, often the same people who are unable to apply speedy deletion tags correctly. I know NPP is not black and white, I was a NPPer once as well (nine years ago...damn, now I feel old). But I also know that clear rules are extremely important in this area because these are the editors most newbies encounter first and thus whose actions will have a lasting impact. That's why CSD is so strict and that's why draftifying needs to have strict rules too. And just like CSD it's dangerous if there is not a second pair of eyes forced to check each action. I can think of a lot of alternatives, from allowing AFD nominations with the intent to draftify to a PROD-like system (draftify after seven days if no one objects) but in all cases it needs to be clear that draftifying is only an option if the article were otherwise deleted without a doubt. It can't be (as it has become for some) a way to push sub-standard articles out of mainspace. I welcome any wording suggestions. Regards SoWhy 17:37, 8 August 2017 (UTC)
  • Oppose Draftification is useful. It is often more appropriate, and less BITEy to retain a badly written article for further work as a draft than any other option available to NPP (tag bombing or various deletion options). This proposal seems to specifically only allow admins to draftify articles (even when speedy deletion criteria apply). This would mean that non-admin NPPatrollers would need a whole new system in place to tag articles for draftification instead of CSD if this was their preferred choice. Without some other whole level of tagging that would need to be implemented with the Page Curation tool (good luck getting the WMF to work on this in a timely manner) this proposal would essentially hogtie non-admin NPP into proposing deletion or tag bombing and would remove the option for Draftification from non-admin NPP altogether. — InsertCleverPhraseHere 13:35, 8 August 2017 (UTC)
Speedy deletion uses a four-eyes-principle for a reason: One user tags, an admin (usually) reviews and decides. Unilateral draftification is like speedy deletion without the second pair of eyes. Considering how many things are tagged for speedy deletion incorrectly, one can easily guess how many articles are moved to draft-space that shouldn't be without anyone ever noticing. Why should NPPers who are not allowed to delete pages, be allowed to "pseudo"-delete them in such a manner? Why bother about WP:CSD at all if you can just move everything out of sight? Regards SoWhy 13:43, 8 August 2017 (UTC)
No one is suggesting 'moving everything out of sight', most problem articles are still clearly best served by other options, but it is the best option for some new articles. The only users that can move articles without a CSD on the redirect (i.e. without oversight) are admins and page movers. Policy reflects current practice, not the other way around. What I see is this: Wikipedia:New_pages_patrol#Drafts, as the current accepted practice of draftification as it relates to NPP. If you want to see a change to the current implimentation, I would suggest starting over at NPP rather than trying to pull the rug out from underneath patrollers that are simply trying to find the best solution for each individual problem (and draftification often is the best solution). I don't object to a proposed draftification tag, or something similar being added to the Page Curation Tool, but I wouldn't hold my breath: a proposal to add draftification to the PC tool has been on the list for over 10 months already. — InsertCleverPhraseHere 14:05, 8 August 2017 (UTC)
The problem is not what someone is suggesting or not, it's what is possible at the moment. What policy is stopping someone with "an agenda" from moving thousands of articles to draft? Articles such as Siamese buffalo don't belong in Draft: space, yet there they were. Saying something is current practice does not make it right. In fact, that it is current practice is the reason I proposed this change in the first place. Regards SoWhy 14:14, 8 August 2017 (UTC)
No doubt people make mistakes (though I'd point out that the article you linked above was named Krabue buffalo at the time, so this particular mistake was understandable given there was also no refs for verification at the time). Admins also make mistakes and delete articles that clearly shouldn't be deleted as well (i.e. Speed Langworthy as a recent example that I dealt with the aftermath of), but you don't see me advocating completely taking away admins' power to delete articles do you? I don't object to a clarification as to when draftification is appropriate and when it is not; this would be useful to NPP. I object to your proposal for several reasons that I have stated above. It is unnecessarily restrictive to non-admins and destroys the usefulness of draftification entirely by essentially making it not allowed except as admin discretion during CSD, and removes a useful tool from NPP when we need all the help we can get at the moment. — InsertCleverPhraseHere 14:34, 8 August 2017 (UTC)
Lets also not forget that we have WP:ACTRIAL coming up soon as well, which will essentially mean that all new articles not from autoconfirmed editiors will be essentially forced to use the draft space anyway. It seems to me that you are trying to force the rigid rules of deletion policy on a system that needs flexibility now more than ever. — InsertCleverPhraseHere 14:38, 8 August 2017 (UTC)
@Insertcleverphrasehere: To my knowledge there has never been a consensus amongst NPPers about draftification. Wikipedia:New_pages_patrol#Drafts was inserted recently and isn't the result of any prior discussion as far as I'm aware. Draftifying has crept in because individual users have decided it's a good idea (which is fine), but when it has actually come up in a discussion there have been objections to it. In my opinion SoWhy is absolutely right to seek a wider consensus on this issue. Even if there were a prior consensus amongst NPPers (and again, I don't see one), WP:LOCALCONSENSUS applies. – Joe (talk) 15:05, 8 August 2017 (UTC)
I never claimed any consensus. However, this is how draftifaction is currently implemented by patrollers, both in the tutorial for NPP (for the last 10 months) and in practice as I experience it 'at the coal face' so-to-speak. No offence meant here, but if you had actually done a bit more coal digging yourself you might understand the usefulness of draftification. I respect SoWhy, and I don't dissagree with his seeking wider consensus about the future of draftification (I agree that we need clarification on the dos and don'ts). However, I think that the current proposal is misguided and both of you seem to not quite get why so many experienced patrollers find draftification to be a useful tool in many cases. — InsertCleverPhraseHere 15:29, 8 August 2017 (UTC)
I've never claimed to be a very active patroller, but I wasn't aware that was a requirement for having an opinion on policy. I have been doing AfC reviewing and WikiProject new article monitoring for over five years, if that counts. Not all patrollers agree with draftifying, as you well know, which is why it's disingenuous to declare it the status quo and argue that "policy reflects current practice". That we don't get why draftification is useful is exactly the point: none of the oppose !voters have been able to explain why it's useful beyond that fact that they WP:DONTLIKE the established processes for deletion and cleanup (i.e. "tag bombing"). – Joe (talk) 18:25, 8 August 2017 (UTC)
I presented an argument below. RileyBugz会話投稿記録 18:56, 8 August 2017 (UTC)
I moved Siamese buffalo to draft for very good reason. My edit summary was 'unref sub-stub with no clear indication of notability. Please move back to mainspace when it's ready.' However, that was only part of it, I had spent several hours over weeks on that editor's unreferenced and unclear articles, and was finding no evidence that some were subspecies at all, rather than just, for instance, buffalo in Thailand. The editor had repeatedly refused to communicate and been warned about his behaviour by more than one editor on several occasions. I was hoping that moving to draft would stop us propagating something unverified, as well as encouraging the editor to stop the constant stream of unclear, unreferenced one-line articles. Boleyn (talk) 06:29, 9 August 2017 (UTC)
  • Strong support. I've noticed the draftification trend creeping in for some time now (e.g. perennial requests to make it a built-in feature of the Page Curation tool), so thank you for finally opening it up to a wider community discussion. I understand why superficially draftifying seems an attractive option when faced with tough calls at WP:NPP, but for me it is a very bad solution for two reasons. The first is that it is a form of "soft" deletion. Brand new editors are not going to understand that they have the right to move it back to mainspace if they disagree, and if they aren't autoconfirmed they won't have the technical ability to. In all likelihood most draftified articles are going to hang around in draftspace for six months (possibly bouncing back and forth to AfC a few times first) until they're G13'd six months later. The end result is that an article is deleted based on a single editor's opinion. This flies in the face of Wikipedia:Deletion policy, which requires a broad consensus at AfD, or at least, in in a small number of well-defined circumstances previously established by broad consensus (i.e. CSD and PROD), the agreement of the nominator and an administrator. Proponents contend that the deletion processes are more bitey than draftifying, but what would you prefer: a prompt and clear message that unfortunately your contribution is not suitable for Wikipedia; or being kept in limbo for six months whilst you struggle to jump through the hoops given to you in vaguely worded templated messages, until you give up and it's summarily deleted anyway?
My second objection is that any purpose draftifying might serve is pre-empted by WP:IMPERFECT. Although many NPPers and AfC reviewers seem to think otherwise, there is no minimum quality standard required for articles to exist. If the subject is not suitable for inclusion, you should nominate it for deletion via AfD, PROD, or CSD. If the subject is suitable for inclusion, you should do as much cleanup as you fancy, and tag the rest for someone else to do at a later date. Poor articles on suitable subjects are much more likely to be improved in mainspace than hidden away as drafts. – Joe (talk) 14:46, 8 August 2017 (UTC)
  • Oppose - This makes it so that users don't have to go through a stressful deletion process. It makes it so that, if I find an unsourced science article with lots of jargon while looking at new pages, I can give the creator the opportunity to improve it. More accurately, I can make it more likely that the creator will improve it so that when they move it to the mainspace, they don't have to worry about it being moved back to draftspace. This does violate WP:PRESERVE, but, as stated in the banner at the top of the page, "It describes a widely accepted standard that all editors should normally follow. Changes made to it should reflect consensus." (emphasis mine) This shows that the nature of policy is to describe standard, accepted practice. Thus, we should follow standard practice when we know it, and policy when we don't. This, of course, is overruled by ignore all rules. Anyways, standard practice is to draftify these things instead of having a tag sitting on top of an article forever, with the problem never being fixed. RileyBugz会話投稿記録 14:52, 8 August 2017 (UTC)
Also, we don't need more bureaucracy to slow us down. RileyBugz会話投稿記録 14:53, 8 August 2017 (UTC)
@RileyBugz: Your examples, like so many of the explanations I've seen people give for draftifying, don't appear to me to match policy at all. Why would deleting an "unsourced science article with lots of jargon" even be on the table? As long as it's viable subject, you can tag it with {{unreferenced}} and {{jargon}} at all. Why do you think it has to be in draftspace to be improved? Can't it be improved in mainspace? What if the creator can't or doesn't know how to move it to draftspace, and just gives up instead? – Joe (talk) 14:57, 8 August 2017 (UTC)
I do it because nobody would fix it otherwise. And besides, I move it to draftspace, and then leave a note describing to the creator 1. that I did it 2. where they can find it 3. how they can move it out when they are done. To answer not matching policy, isn't this for discussing policy? RileyBugz会話投稿記録 14:59, 8 August 2017 (UTC)
How is you moving it to draftspace "fixing it"? How is it different from "tag bombing"? In both cases the problem persists, however, in case of draftifying it's now out of sight of "common" editors who might stumble upon it otherwise and fix it. Regards SoWhy 15:57, 8 August 2017 (UTC)
First off, I never said that it was fixing it. What moving the page to draft does is keep a potentially bad page off the mainspace while allowing the creator to easily improve it. Overall, it is a win-win, even if the page wouldn't be deleted by an AfD. Also, I want to present another argument. This rests on the fact that 1. tag bombing is bad, as it is BITE-y and doesn't fix much 2. Not doing anything to an article is slightly bad, as it significantly decreases the chance that somebody will fix the problem, although it does not help BITE the creators or anything. 3. Draftifying is slightly positive in terms of the fact that it helps encourage creators to actually fix their page but slightly negative in that it is a bit BITE-y. This makes Draftifying a neutral process. 4. AfDing an article is the best, as it encourages people to fix it, although in some cases (such as for an unreferenced article with lots of scientific jargon), the fact that people would not have an incentive to clean it up (as they would vote keep no matter what, as you don't have to save it from deletion) makes the BITE factor of AfD outweigh the cleanup part. If we follow this model, we can see that, in some cases, Draftifying is the best idea. RileyBugz会話投稿記録 16:50, 8 August 2017 (UTC)
Tag bombing is NOT the universal solution that you seem to think it is Joe. We currently have 206,011 articles tagged with 'unreferenced' and 320,706 articles tagged with 'needs additional references' on EN wiki. — InsertCleverPhraseHere 15:10, 8 August 2017 (UTC)
@Insertcleverphrasehere: And? – Joe (talk) 18:25, 8 August 2017 (UTC)
I thought my point was clear, but here you go: my point is that tags do next to nothing in many cases. A quick look at Category:Articles_lacking_sources will reveal that there are many articles without sources there that have remained unsourced since 2006. — InsertCleverPhraseHere 20:43, 8 August 2017 (UTC)
"I do it because nobody would fix it otherwise." RileyBugz, I heard recently (but don't have a link) that there's been the effect of putting a page in draftspace. One conclusion: articles in the mainspace are far more likely to be improved than articles in draftspace or userspace. If your main goal is more like "hide imperfect articles from readers", then moving them to draftspace is fairly effective. If your main goal is to get articles improved, then moving them to draftspace is counter-productive. They will get fewer edits and less improvement. Moving the articles to draftspace with a message seems plausible (you're basically trying to bribe the initial editor to make extra efforts, in return for a promised 'reward' of some AFC regular eventually moving the article back in the mainspace), but it doesn't actually work. WhatamIdoing (talk) 02:33, 9 August 2017 (UTC)
  • Oppose: draftifying a new user's article is sometimes better than a long deletion discussion because it is less bite-y and less bureaucratic. For the most part, I trust the discretion of new page reviewers and draftifying is a legitimate alternative to tagging which requires no discussion. I've not witnessed any draftification wars so I think this solution is probably unnecessary. DrStrauss talk 15:04, 8 August 2017 (UTC)
  • Suggest drafting a guideline. I'm seeing good arguments from both sides. At the moment the discussion seems to be leaning "opposed" to flat prohibition on draftification. However I think there is implicit support for a guideline to clarify what is or isn't appropriate. I'm personally leaning to the position that draftification could be a good option, at least in some circumstances. Given the uncertainty here, it would probably be best to draft different levels of allowance/prohibition. Then an RFC can more clearly sort out what we want. Alsee (talk) 15:39, 8 August 2017 (UTC)
Alsee, agreed. I think this is a good solution, and long overdue. One suggestion that I have is that we should have a specific CSD template made up that is to be used on the redirect by patrollers who have draftified articles without admin or pagemover rights. This will tip off admins to review the decision to draftify and check whether the choice was correct when compared to whatever we decide are the acceptable limits of draftification. I think that page movers can be trusted to generally work without a second set of eyes and follow whatever guidelines we decide upon, given the requirements of that user-right, though I suppose this point is debatable. — InsertCleverPhraseHere 15:53, 8 August 2017 (UTC)
  • Oppose. If speedily deletion remains possible, then the lesser recourse of speedy draftification must remain possible. bd2412 T 19:04, 8 August 2017 (UTC)
  • Support It is our policy that "Even poor articles, if they can be improved, are welcome." Pushing an article into draft space is not welcoming. If it is done without leaving a redirect, as I've seen happening then it is effectively deletion by stealth – exploiting a loophole to subvert all our deletion policies. This loophole should be closed. If it isn't then you're going to see move warring and article recreations causing chaos and confusion. Andrew D. (talk) 19:14, 8 August 2017 (UTC)
I'm not sure how others do it, but if a user decides to simply move the article back to mainspace, or to recreate it, I simply give up on draftification and persue other means of patrolling the new page via CSD/PROD/AfD/tagging/etc in order to avoid any kind of move warring. I agree that clarification for patrollers is needed here and I'd like to see some version of this (don't force draft if new users don't want to work in draft) recommended as part of the proposed guidelines in a future RfC per Alsee. — InsertCleverPhraseHere 20:37, 8 August 2017 (UTC)
  • Strong Oppose setting up yet another restriction applicable only to non-Admins that Admins like SoWhy can sanction lowly regular users on is not welcome. There are already so many conflicting rules it is hard to keep track. This restriction will just remove another tool from the toolbox of NPPers that are struggling to keep up with the firehose of garbage pages being created. Many new mainspace pages should have been started in Draft and putting them where they belong is a kind and appropriate gesture. Legacypac (talk) 21:32, 8 August 2017 (UTC)
  • Oppose moving something to draft space counts as a WP:BOLD step that can be reversed. Limiting it to admins will have an artificial divide between activities admins and non-admins can do. Sure, moving to draft space has its disadvantages, but leaving a piece of junk in article space does too. Instead of blocking out this option, explain what patrollers should do, ie notify the writer(s) about the move and how to fix the page up so that it can be returned. Those that think this is a problem can look at the move log to see when draftification happens. Graeme Bartlett (talk) 22:13, 8 August 2017 (UTC)
  • Support I can see no reasons for draftifying. If an article falls under CSD then it should be deleted. If there is a dispute about that, it should be sent to discussion (AfD). If the article is a crappy stub, well, that makes it par for the course. Hawkeye7 (talk) 22:18, 8 August 2017 (UTC)
  • Very strong Oppose - this is a classic example of a solution looking for a problem. There would need to be proof and evidence of misuse of the 'Draftify' solution. Precisely the reason the Draft mainspace was created was for good faith creations that are however absolutely not ready for publication in mainspace. and to undo now would be a significant step backwards. The 'move to draft' is actually used much less frequently than the non NPP voters would claim, and AFAIK, no creators have complained. Of those new articles that I have moved to Draft, the creators have actually thanked me for it. To be absolutely honest, I see this RfC, while in good faith, not only as totally superfluous, but a drain on our time having to respond to it. Kudpung กุดผึ้ง (talk) 02:48, 9 August 2017 (UTC)
    • Well, "less frequently" is a loose term. I don't think 200 such moves in a week alone (cf. https://quarry.wmflabs.org/query/20795) can be considered infrequent. I don't have time now to check all those moves but I am fairly certain not all of them were correct (and those are just moves without a redirect, i.e. those not leaving a trace for a second pair of eyes to check). Regards SoWhy 07:23, 9 August 2017 (UTC)
      • I have made a somewhat easier to read list of the moves mentioned above here.Mduvekot (talk) 14:10, 11 August 2017 (UTC)
    • That's a common misconception. In the run-up to the Olympics/Paralympics, the Olympic Project creates many articles on Olympians. In some cases, they are not presumed notable, because they are not considered Olympians until the games begin. But we want to have the articles on them on day one, when the readers will start looking for information on them, so they are kept in the User space until either the articles reach the point where WP:GNG is demonstrated, or the games begin. The Draft space cannot be used for this purpose. The Draft space is reserved for the use of AFC Project. Hawkeye7 (talk) 22:10, 9 August 2017 (UTC)
That's not been my experience, and I think the discussion about G13 at WT:CSD makes it clear this is far from universal. @Legacypac and Premeditated Chaos: both of you have much more experience than I do in this area. Is what Hawkeye saying the current standard practice? TonyBallioni (talk) 00:36, 10 August 2017 (UTC)
──────────────────────────────────────────────────────────────────────────────────────────────────── Not remotely, which is the entire reason we've been having the discussion at WT:CSD about expanding G13 to cover all drafts in draftspace. Drafts don't get tagged for AfC until someone (usually their creator) submits them to AfC for review. Anything submitted to AfC and subsequently abandoned is eligible for G13. At present, anything not submitted to AfC will not have an AfC tag and will therefore never be eligible for G13. There's no mandate that items in draftspace must have an AfC tag and I honestly have no idea where Hawkeye7 got that impression. (Check out the stale drafts report for confirmation that there is plenty in draftspace without an AfC tag) ♠PMC(talk) 00:55, 10 August 2017 (UTC)
As noted in the links, that is exactly what happened. Articles in the draftspace were tagged for AFC without my submitting them. That then made them G13-eligible. You cannot honestly assert that you have no idea where I got that impression when I have presented the evidence. Furthermore, I note the discussion at WT:CSD#Expand G13 to cover ALL old drafts under which AFC asserts the right to delete articles under G13 regardless of whether they are AFC tagged. The reading of Editors may also optionally submit drafts for review via the articles for creation process by AFC is that any editor may submit any article in the draftspace to AFC, not just the article creators. Hawkeye7 (talk) 21:23, 10 August 2017 (UTC)
You are correct in saying that any article in draftspace may be tagged by anyone for submission. I clearly acknowledged that in my original comment (until someone (usually their creator) submits them to AfC). However, it is not the case that, as you said, anything placed in the Draft space will be tagged with a AFC submission template. Just because it can happen does not mean that it will happen to all drafts. Your experience is far from the norm; if you look at the stale drafts report you will see that the vast majority of those do not have AfC tags and never will. ♠PMC(talk) 05:33, 11 August 2017 (UTC)
How about a way of preventing it from ever happening? Hawkeye7 (talk) 03:37, 12 August 2017 (UTC)
Not the scope of this RfC, so not worth arguing about further here. If you'd like to change the way Draftpace/AfC works, you should make your own RfC asking to prohibit other editors from putting AfC tags on other peoples' drafts. You will almost certainly encounter strong resistance; the possibility of editors finding and improving other peoples' drafts is supposedly one of the main benefits of draftspace so I doubt the community would agree to a measure that would prevent that. ♠PMC(talk) 07:27, 12 August 2017 (UTC)
Which brings us back to the draftspace being AFC's playground, and unusable for any other purpose. Hawkeye7 (talk) 13:00, 14 August 2017 (UTC)
  • strong support - draftifying should be viewed as a type of deletion, ands only be used when outright deletion would be appropriate. עוד מישהו Od Mishehu 03:08, 9 August 2017 (UTC)
  • Oppose Draft-space is a useful 'stick' to motivate contributors, especially UPEs and those with COIs who only care about getting an article into the encyclopedia to improve their articles and avoid perpetual tags. It is also useful as an alternative to deletion, where an otherwise useful new contributor might find that their article is at AfD or speedy deletion because they don't know about the various hurdles and notability criteria that they have to demonstrate. In draftspace, especially if they submit to AfC, they can get feedback regarding this. I agree that this RfC is not in bad faith, and I do think there should be more monitoring to make sure it isn't being used as a 'quick deletion' option, but that fundamentally the option to draftify should remain. jcc (tea and biscuits) 09:10, 9 August 2017 (UTC)
  • Oppose - draftification should be kept as a viable interim step to other deletions. I would support a pohibition on subsequent attempts to draftify if the measure was contested, similar to PRODs, but nothing more stringent.--John Cline (talk) 10:07, 9 August 2017 (UTC)
  • Guideline Per Alsee. A soft delete without due process invalidates Prod, xfD etc. Yet I do see Kudpung's point. In case this is a solution looking for a problem, writing up a guideline will prevent loss of time in the future. Started it, might as well finish it right now...ronazTalk! 11:06, 9 August 2017 (UTC)
  • Oppose you show a picture of a cute buffalo, but what I think about is this. I have nothing against buffalos. So far, I have draftified exactly one article - a rejected AfC draft moved to main by one of nearly 100 blocked socks of a paid editor. It had 68 references, and had been rejected as "improperly sourced". I moved it back to draft space where it belongs. See also Jasmine Directory for a nice example how draftifying a promotional article prompted an editor to come forward, fix it and resubmit through the proper channels. Please consider these anecdotes when writing a guideline regarding draftification. Rentier (talk) 15:34, 9 August 2017 (UTC)
  • Oppose. Moving an article to draft is a substantially "softer" way of doing things than tagging for various forms of deletion on a new editor. It keeps stuff that isn't ready for mainspace out of it, but still keeps what they've done intact to get fixed. There still might be clearly unsalvageable stuff that needs deletion outright, but other stuff can go to draftspace and either become a viable article there or eventually fall into G13. Seraphimblade Talk to me 17:06, 9 August 2017 (UTC)
    • Seraphimblade, who gets to decide what's truly "ready for mainspace"? Should every autoconfirmed editor be allowed to boldly move pages to draftspace, without any kind of notification, discussion, or determination of consensus? What if other people disagree? Should they just boldly move the same article back to the mainspace? And what's the standard for "not ready for mainspace"? Anything that's WP:IMPERFECT? WhatamIdoing (talk) 22:18, 11 August 2017 (UTC)
  • Oppose. Draftifying allows new article creators to learn through feedback and communication, instead of feeling unwelcome – never to return or try again. GenQuest "Talk to Me" 17:16, 9 August 2017 (UTC)
  • Strong support. "since either the topic is notable enough for inclusion - then it should stay in mainspace - or it is not - then it should be deleted." is the key here, really. WP:FIXTHEPROBLEM - shoving a poor article behind a curtain means less chance of editors actually seeing and correcting the article. If a topic is notable enough for inclusion, then it can stay and be fixed, if not deleted. The only argument for draftifying is that an editor (usually they who created the article) is going to expand it - but surely then it can stay in mainspace? I see no real place for draftifying articles on Wikipedia - after all, we are the encyclopaedia that anyone can edit, not the encyclopaedia that require some arbitrary standard of quality otherwise your edits will be hidden from view and forgotten about. There is no difference between draftification and deletion, except that the content is still accessible - if you know where to look. Keira1996 00:09, 10 August 2017 (UTC)
  • Oppose a blanket ban, support the creation of some kind of guideline. ♠PMC(talk) 01:02, 10 August 2017 (UTC)
  • Oppose. If a new editor believes that they can WP:BOLDly move a draft into the article namespace, I do not see why experienced editors cannot, in return, WP:BOLDly disagree with that move, return the page to the "Draft:" namespace, and get the indexed redirect in the article namespace removed via WP:R2. Also, I agree with GenQuest's approach about how to communicate with the draft creator and/or publisher after moving the article back into the "Draft:" namespace; we are not in the business of chasing new editors away, but we have to ensure that the content being published is either up to our standards (usually eligible for WP:CSD) or on the way to becoming an article worthy of being in the article namespace (and thus moved back in the "Draft:" namespace pending further improvements). Steel1943 (talk) 06:22, 10 August 2017 (UTC)
  • Qualified Oppose Move to draft should be retained as an option when the creator has been told what improvements are necessary and there is reason to think they will make these improvements. However, we are no longer in the days when most creators could be assumed to be both competent and willing to follow guidance, engage in discussion and bring their articles up to scratch; it should be discouraged to fill draftspace with pages that have no hope of improvement. Such pages need to be improved by others, tagged, or deleted: Noyster (talk), 07:46, 10 August 2017 (UTC)
  • Strong oppose: Draftifying articles that is still under development or other issues is useful for newbies rather than being bitten by editors. KGirl (Wanna chat?) 20:13, 10 August 2017 (UTC)
  • Strong oppose per Seraphimblade. (((The Quixotic Potato))) (talk) 23:19, 10 August 2017 (UTC)
  • Oppose unless there is data showing that limiting draft moves is beneficial. Esquivalience (talk) 00:49, 11 August 2017 (UTC)
  • Strong oppose per TonyBallioni and Kudpung. Draftifying or userfying is in no way a form of deletion, since the article still exists, and can be restored to articlespace whenever it is appropriate. Inappropriate draftifications or userfications can be dealt with the old-fashioned way, through consensus discussion between editohrs. Beyond My Ken (talk) 13:34, 12 August 2017 (UTC)
  • Oppose  A bold move to draftspace or a "Speedy incubate" is fine, and strongly supported by our fundamental principles.  The remedy to a bold move is a revert.  Imposing a new bureaucracy violates policy. 

    I've written before about this, and Andrew D. points to a key flaw in the current design, which is the semi-auto deletion of the remaining redirect, which causes a loss of information.  Editors can't revert the bold move if they don't know that it is there. 

    If an article is present in drafspace, we need technical support to lockout the creation of an article in mainspace.  This lockout mechanism must not prevent a mainspace redirect.  We also need the ability to edit articles (i.e., add to the edit history) under a redirect.  This is not a proposal here, just elements of what have been many proposals over the years.  Unscintillating (talk) 14:13, 12 August 2017 (UTC)

    • What purpose does a redirect serve that {{There is a draft for this article}} does not? Does it just need to be displayed more prominently, or maybe for Draft: to be searchable by default along with mainspace? —Cryptic 17:33, 12 August 2017 (UTC)
      • Well, my experience has been that editors object to having a working redirect going from mainspace to draftspace.  Nor do I think that draftspace should be searchable from Google. 

        Here is a new proposal: Adding Category:Wikipedia draftspace to a redirect, soft or hard, in mainspace moves the edit history to draftspace, and no further edits are allowed until the draft article is moved back to mainspace.  A common redirect is {{soft redirect|Wikipedia draftspace}}.  Then we'd need to write the article at Wikipedia draftspace to attract new editors and explain how to locate articles in draftspace.  Unscintillating (talk) 19:43, 12 August 2017 (UTC)

        • Cross-domain links will be speedily deleted. (WP:R2) Hawkeye7 (talk) 14:36, 23 August 2017 (UTC)
  • Strong support. We are supposed to be the encyclopedia that anyone can edit. Articles in draftspace are effectively invisible to most editors (=readers), because you will only find them if you know exactly what you are looking for. It becomes a form of deletion by the back door and (with the exception of the cases covered by speedy deletion) deletion should require discussion. I also see draftification being used contrary to WP:BITE. Matt's talk 22:56, 13 August 2017 (UTC)
  • Strongest possible oppose – articles that do not meet notability guidelines such as WP:NFF or WP:TVSHOW, etc., but which are likely to once the guidelines are met to, should be moved to Draft space in the meantime, post haste. It doesn't take an Admin to figure this out – any NPP'er or experienced editor, can figure it out on their own. Making it an "Admin only" thing is another attempt to give Admins "super powers" over other editors. Now, if someone wants to come up with a better policy for when clarifying exactly when this can/should be done, then fine. But banning the practice outright is beyond harmful, and is likely to be roundly ignored even it's formalized. --IJBall (contribstalk) 03:49, 14 August 2017 (UTC)
  • Oppose - I had never even heard of "draftification" before but I find the oppose arguments above, particularly that of Kudpung and InsertClever...., to be compelling. Carrite (talk) 11:34, 14 August 2017 (UTC)
  • Strong oppose per Kudpung, Seraphimblade, TonyBallioni etc – in many cases, this is the least bitey method of dealing with new articles that have, in their current state, little or no chance of survival in mainspace. It gives inexperienced new editors breathing-space in which to learn what is expected of an article and how to fulfil those expectations, and is – I believe – far more likely to contribute to editor retention than is summary speedy deletion. Our guidelines should be rewritten to clarify that this an acceptable option and an integral part of what the draft space was created for. Disclosure: my name is among the most frequent on the list of such moves provided by Mduvekot above. Justlettersandnumbers (talk) 14:23, 14 August 2017 (UTC)
  • Strong oppose - No, moving articles to draft is not deletion. There is very little upside to this proposal, and significant downside as it would tend to make maintenance much more onerous while bringing down the average article quality in main space. Articles are moved to draft space because they are poorly written, poorly sourced, poorly translated, lack sufficient context, written like essays, or are of unknown notability. It's a simple matter for the creators of any such articles to improve them so that they approximate the quality of other articles, before they are republished in main space.- MrX 15:08, 17 August 2017 (UTC)
  • Strong oppose - qualified reviewers granted such rights, especially for use in NPP and/or AfC are, well...qualified to do so and for good reason. If they abuse the right, there are remedies. I see no reason to keep articles in main space that simply are not ready for main space or that fail one way or another. The quality of our articles is essential to the integrity of the project which is why we have the process in the first place. Atsme📞📧 12:10, 20 August 2017 (UTC)
  • Suppress draft space. This just goes to show how overly complicated our editing process is if things get just bolted on in a Byzantine manner until even veterans don't understand how we are supposed to work. Any article content should be either presentable (in mainspace, even if stubbed), improvable (in the userspace of somebody who intends to improve it), or deleted. Quartium non datur.  Sandstein  07:35, 23 August 2017 (UTC)
    I already provided a counter-example above, where this is not the case. In the run-up to the Olympics/Paralympics, the Olympic Project creates many articles on Olympians. In some cases, they are not presumed notable, because they are not considered Olympians until the games begin. But we want to have the articles on them on day one, when the readers will start looking for information on them, so they are kept in the User space until either the articles reach the point where WP:GNG is demonstrated. The draft space would be better suited to this purpose, if we could use it, rather than having the articles scattered across the User space. Hawkeye7 (talk) 14:31, 23 August 2017 (UTC)
    And I've given two more examples above – films and TV shows that are in the planning phase but which do not yet meet WP:NFF or WP:TVSHOW (e.g. because they haven't yet gone into principal filming/production). All of these are clear examples of articles that would do well cooling their heels for weeks or months in Draftspace until they meet the relevant WikiProject notability guidelines. And it boggles my mind that people think Userspace is better for this than Draftspace... --IJBall (contribstalk) 03:57, 24 August 2017 (UTC)
  • Oppose, and suggest drafting a guideline instead, per Alsee, et al. We do not promote essay material to guideline status (maybe in Ye Olde Tymes, but not any more), much less tiny bits of them. Doing it with one fragment would encourage a thousand WP:OWNish camps to try to elevate their own WP:PROJPAGE and other essay nit-picks into policies. Guideline wording should be drafted and discussed, for inclusion in a pre-existing guideline page (or policy page, if people think it rises to that level). The "blanket" approach being taken (both most people on both sides) is unhelpful. I agree that guidance on when draftification may or may not be appropriate is needed.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  23:25, 23 August 2017 (UTC)
  • Oppose. This is NOT a good idea. This just adds more unneeded bureaucracy to the unneeded bureaucracy that is AFC. KMF (talk) 18:20, 27 August 2017 (UTC)
  • Comment Something that might be of interest to those following this discussion. I have had a chat with Evad37, and at my request he modified the User:Evad37/MoveToDraft tool to add a 'Draftify log' functionality similar to the CSD log functionality of Twinkle. I thought it would be useful to have a way to keep track of draftifications afterward. All you need to do to activate logging for the tool is to create a page at User:Username/Draftify log (with your own username in place of 'Username'). — InsertCleverPhraseHere (or here) 06:29, 28 August 2017 (UTC)
  • Oppose. In my experience there is far more of a problem with articles being CSD'd or AfD'd too soon and while the shiny new editor who created it is still working on it, than there is with such articles (which should have been created in draftspace or userspace in the first place) being unilaterally draftified by a more experienced editor. Leaving such articles in mainspace where they will be vulnerable to the many overzealous deletionists runs a significant risk of the first interaction a new editor has with a more experienced editor being the flagging of their article for deletion, which many new editors find so off-putting that they leave Wikipedia forever. Sure, some of them are people we don't really want editing here anyway, but that's not always obvious from a look at the earliest version of an article. WP:BITE, WP:BITE, WP:BITE. —GrammarFascist contribstalk 17:48, 30 August 2017 (UTC)
  • Oppose. I've come across a lot of new articles during the new page review process and I always check for myself if the topic has any chance to pass the notability guidelines. And, surprisingly, about 40-50% of them does, and the articles are well written. The problem is with the new, inexperienced editors who don't (always) know all the policies or where to search for independent reliable sources. Because of this issue, most often noteworthy articles end up being prod-ed. Instead, moving such an article in the user's draftspace (on topics that I'm familiar with I reference the article and review it) gives the opportunity to the editor who created it to learn Wikipedia policies, encourages him (psychologically) to continue and improve his work, get help, and, the most important aspect, the article is not lost. Robert G. (talk) 07:11, 2 September 2017 (UTC)
  • Oppose Per the many opposes above and the farcical convoluted reasonings supporting this proposition. I know from my personal review very few of those supporting actually have walked a mile in NPP or AFCs shoes (and surprisingly show up frequently to argue tortured inclusionist positions). Unless SoWhy is volunteering to be on call 24/7/365 to support these draftifications, the position is untainable. If there is a rogue user incrrectly moving things to draft space we deal with that user via topic Ban (and other forms of ban/block), when we have ~5 users all doing it, then we could consider if this really needs to happen. Until then this is just a policy land grab that takes a useful tool out of the toolbox of all non-admins to preserve content that would be headed to the Shred bin when there could be improvement. Hasteur (talk) 01:56, 11 September 2017 (UTC)
  • Comment A 'new article review flowchart' is being developed by myself and with the input of others over at the NPP discussion board that hopes to clarify and codify the step by step process of reviewing a new page. Development of that flowchart/reviewing instructional tool is ongoing, so any input by others is appreciated. While clarification of a guideline about when draftification should/shouldn't be used is still a priority, this flowchart does identify at least one potential outcome of the review process where draftification is the most desirable action and could be used as a starting point for a new guideline on when draftification is/isn't appropriate. — InsertCleverPhraseHere (or here) 04:11, 11 September 2017 (UTC)
  • Oppose -- appears to be a solution in search of a problem. K.e.coffman (talk) 04:43, 11 September 2017 (UTC)

Create a new Event Coordinators user group

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There is consensus to oppose this proposal. Many participants have come to a common conclusion that editors in editathons ≠ high quality contributors ≠ article creations that don't need a review.Counter-arguments related to CAPTCHA et al don't seem satisfactory.Winged Blades of GodricOn leave 14:15, 18 September 2017 (UTC)

This is a follow-up to the previous RfC about extending the Account Creator user group. Per the comments in that RfC, there seems to be general agreement that there should be some technical means for people who have experience running edit-a-thons and similar events (and have a proven track record of successfully onboarding new editors) to be able to work around the limitations of WP:ACTRIAL during its duration—specifically, the limitation that non-autoconfirmed users can't create new articles. The main objection raised in the previous RfC was that the Account Creator user group wasn't a good user group to use for this purpose since it is given out freely to editors who haven't been adequately vetted for the ability to onboard new editors and thus shouldn't be trusted to grant autoconfirmed status to other users. For this RfC I am proposing the following:

  • A new user group is created called Event coordinators with the following rights: noratelimit (can create more than six accounts in a 24-hour period with Special:CreateAccount), ability to add group Confirmed users (See WP:CONFIRM).
  • This new user group will have the following requirements to be granted:
    • User must be auto-confirmed themselves
    • User must have a proven record of running successful Wikipedia editing events
    • User must have good understanding of key Wikipedia policies and guidelines related to article creation

Kaldari (talk) 21:56, 18 August 2017 (UTC)

  • Support at Wikipedia:Account creator there is text about giving account creation rights to people coordinating events. Account creator userights include the right to make more than 6 accounts from one IP and also some odd rights related to account creation which can cause extra damage. For the sake of event coordinators organizing Wikipedia editing events, we need a userright to bypass the 6-account limit and which admins can grant freely to users who cannot be fully trusted with the extra privileges which come with account creator. This issue has been discussed for several years on the talk page of the account creator rights. In 2018 probably 100 accounts would need this event coordinator right and the use is likely to increase over time. Many people are uncomfortable with the account creator right being granted so freely to so many new users. Blue Rasberry (talk) 22:07, 18 August 2017 (UTC)
    Not seeing how this is much differnt - yes this one doesn't have list override, but it still has wide open throttle override. — xaosflux Talk 22:10, 18 August 2017 (UTC)
Striken then - I am expecting a solution which addresses the technical issue raised years ago, and which has been the focus of discussion since then. I just want new users to be able to create accounts to contribute someplace, and I would prefer to maintain status quo in other regards. Blue Rasberry (talk) 22:52, 18 August 2017 (UTC)
  • Comment @Kaldari: have you seen the discussions at Wikipedia talk:Account creator - talking about event needs? — xaosflux Talk 22:08, 18 August 2017 (UTC)
    • @Xaosflux: I agree we need better tools for events, especially around account registration issues (and related security concerns). Although this proposal won't solve that, I think it might be a useful stopgap during WP:ACTRIAL. Kaldari (talk) 22:30, 18 August 2017 (UTC)
  • Oppose - Per SilkTork's oppose at the previous RfC, The most appropriate, manageable, and helpful route to creating new articles during an edit-a-thon is via the draft process. - FlightTime (open channel) 22:18, 18 August 2017 (UTC
    • The feedback that I've seen from actual event coordinators doesn't seem to support that conclusion. For example: "I don't know any edit-a-thon organizers using AW+Draft space at events, and personally I've never found AW to be super useful."[46] Kaldari (talk) 22:26, 18 August 2017 (UTC)
  • Oppose I oppose granting account creators or event organizers the ability to make new users autoconfirmed. I've seen no evidence that these new users are better than other new users at creating new pages. New users should work in Draft. The event organizers can use their own accounts and judgement to move anything new into mainspace. That way if there are inappropraite moves we can discuss it with an established user. Or let AfC do it's job. New users should not be starting by creating new pages anyway - they shoudl learn on improving and expanding established articles. Legacypac (talk) 22:23, 18 August 2017 (UTC)
  • Oppose This is an even worse idea. Even an experienced event-coordinator can't oversee all the new editors that show up, not that they would even want to. If anything, admins should be more careful who they give account creator to; we need not create a new user group to fix past errors in judgement. There's no reason to ameliorate the effects of ACTRIAL. All new editors should be going through AfC, no exceptions. Chris Troutman (talk) 22:30, 18 August 2017 (UTC)
  • Support for a different reason Per Gnangarra's comments in the last RfC, The ability of an event coordinator to confirm other users would remove the very annoying and disruptive CAPTCHAs that come up constantly for non-autoconfirmed users. This by itself would immeasurably improve the experience for new editors at editing events. — InsertCleverPhraseHere (or here) 23:00, 18 August 2017 (UTC)
  • Comment @Kaldari: Respectfully, I'm not sure I agree with your reading of consensus on the previous RfC, which you withdrew without an uninvolved closure, as is permitted. I see two main objections to the prior proposal, with the second one being that all new users should go through the draft / AfC process, as argued by SilkTork, Ivanvector, Kudpung, et al. What I do not see is a general agreement that there exists a need to "work around the limitations of WP:ACTRIAL". I wonder if the Foundation seriously considered Cabayi's proposal centred on "event" templates, or Jytdog's idea to recruit reviewers for real-time feedback through the AfC process. I have no strong opinion on the present RfC, but don't read it as significantly different to the prior one. Snuge purveyor (talk) 23:25, 18 August 2017 (UTC)
  • Support as per my comments in the previous RfC, somewhere along the way we forget where we started and the mistakes we made. AfC is the problem, being bitten by that process is the biggest issue in editor retention and positive experiences by new users from workshops. Putting a time limit on being able to create accounts for event organisors would remove the issue of the tool being given to readily and not monitored. As we grow we have a habit of developing fiefdoms and power structures when maybe we should be reminding ourselves "Anyone can edit" and "Assume good faith" before a new process is created and ask are we hindering that. @Kaldari: is trying to address that and refine the previous rfc based on comments there, the opposes so far have raised nothing new they continue to be new user shouldnt be able to create articles not much AGF there. Projects like WikiWomen, Women in Science, Education and many other Wikibombs are specifically aimed at the creation of new content in areas where we lack coverage while at the same bringing in new editors. Either we start to address the concept that we truly want to share the sum of all knowledge and we want to address systemic bias and the cultural bias of editors or we choose to say stuff it this is a male dominated community and only the knowledge of interest to males matters. Gnangarra 23:45, 18 August 2017 (UTC)
  • There is nothing in the present system that hinders addressing any perceived systemic bias. Unless you have evidence that AfC enforces such bias? Allowing a bunch of avowedly single-purpose accounts to by-pass standard procedure on any grounds is surely not A Good Thing. - Sitush (talk) 20:43, 19 August 2017 (UTC)
the current system does hinder many people contributing, not every one learns the same way at the moment we have developed a processes that attracts only one style of learning, the workshops help to attract the majority of learning patterns dont fit into the jump in feet first basket. If we want to diversify the contributor base we need to ensure that there are are differing paths to come into the community and contribute productively. I heard all kinds of arguments put forward, but AFC has back logs and takes weeks to get past, we have backlogs of poor articles but the bar is set so high its actually contributing to those back logs, this proposal isnt about allowing anyone to bypass standard procedures.... Remember those standard procedures didnt exist when were at our peak in growth both in content and contributors the came in to address one issue and created others the end result was a drop in contributors, a drop in content expansion unlike sourcing/citation drive there hasnt been the impact we still get the problems. We keep standard procedures because we enjoy the power it gives us, but we lament the falling growth, and lack of diversity those standard procedures prevent while rejecting the idea that maybe we can do things differently or enable others to do things differently. Gnangarra 02:44, 21 August 2017 (UTC)
None of that addresses your claim re: systemic bias. And, FWIW, we introduced a tremendous amount of crap in the early growth years, eg: the copy/pastes from EB1911 and ODNB, from British Raj sources etc. We're still trying to clean that up. - Sitush (talk) 09:46, 21 August 2017 (UTC)
Systemic bias is definitely a problem around both NPP and AFC. Here's why, as the subject has been researched. New pages and draft require reviewers to evaluate their suitability for Wikipedia guidelines, and many truly good and truly bad articles are easily processed. But the ones that get looked at but not reviewed, or not approved or rejected are typically (and here's the research on it) "time consuming judgment calls". And a key type of TCJC is articles that are "well-written but have questionable notability" (scroll up in the link to see that last term).
Well, that's exactly the kind of articles that edit-a-thons tend to produce. The explicit goal of many Edit-a-thons is to create Wikipedia pages on topics that are insufficiently covered on Wikipedia. Edit-a-thons are, by design, Countering Systemic Bias. These Edit-a-thons teach principles of notability to editors so that they don't created deletable pages, but they don't teach AfC and NPP reviewers how to effectively evaluate that notability for a subject that is chosen precisely because it's underrepresented in the popular imagination. Result: these articles are consigned to purgatory and edit-a-thon attendees learn that Wikipedia is a place where their hard work goes to die.
And we also have research showing us [the net effect of shunting users through AfC]: fewer lasting articles created by new users.--Carwil (talk) 18:14, 8 September 2017 (UTC)
I'm sorry but I have little faith in anything said by people who are closely connected to the WMF. I've previously provided examples showing just how screwed up and incompetent such people can be when it comes to edit-a-thons etc; some are also arguably conflicted from a financial point of view. With a very few exceptions, people who are or have been involved with the WMF should be asked to stay well away from the editing side of this project. - Sitush (talk) 20:29, 9 September 2017 (UTC)
  • Neutral I supported the previous RfC as a measure of goodwill towards event coordinators who said they wanted this during conversations around ACTRIAL. I still don't see it as that big of a deal, but I also think the last RFC revealed that the community didn't want event participants to actually be exempted, and some appeared to be under the false impression that ACTRIAL was a permenant thing that had already been implemented, and were opposed to any exemption from it. Given both set of concerns raised by editathon coordinators and those who opposed the ability to confirm in general last time, I am neutral on this request, but thougut it appropriate to make it clear here since I have been heavily involved with the ACTRIAL conversation. TonyBallioni (talk) 23:56, 18 August 2017 (UTC)
  • Comment: While this is slightly different, I'm not changing my stance from the previous RfC: One of the major objectives of ACTRIAL is to reduce the workload for reviewers and other maintenance workers. Last week an editathon in South Africa organised by the SA chapter and the Swedish embassy was publicised during a TV interview and received a high participation. Unfortunately, the facilitator was ill prepared for the unexpected high participation and a number of articles were produced in good faith but were totally unsuitable for an encyclopedia. It's a shame to have to delete these otherwise good faith efforts. Rather than making any changes to the User Group permissions, perhaps it would be more appropriate for editathon facilitators to teach their students how to edit by getting them to create their articles in their sandbox or or in the Draft namespace instead. Facilitators could them move suitable articles to mainspace for them.
I think that good preparation for an editathon should enlist an admin who will be present or online during the event. The recent editathon in South Africa went wrong. This does not instill confidence that event organisers are automatically any more qualified than anyone else. That said, I would like to invite the comments of RexxS, a highly experience editathon facilitator and qualified teacher and instructor who generally ensures that his editathon students make their creations in their sandboxes. Kudpung กุดผึ้ง (talk) 01:30, 19 August 2017 (UTC)
Perhaps there is a broader question of how much help we give to event organisers in general. I've faced a lot of unexpected problems at events over the years, and eventually you learn how to anticipate the commoner ones (e.g. have a spare laptop and AV cables available), but getting examples of good practice beforehand can help. To be honest, I dislike losing time in creating accounts on the day, so I strongly encourage participants to register an account at least four days before the event. That's the single easiest means of completely avoiding the non-confirmed problems. Sometimes you can't, so I try to catch participants before the event starts (maybe over coffee) and get them registered then without using up scheduled time and keeping a group waiting. Otherwise you need an assistant who knows how to use Special:CreateAccount, who can make accounts while you get the rest of the group started. As for AfC - I simply prefer not to use Draft space, sorry. Despite all your good efforts, the quality of reviewing remains variable, and I much prefer working entirely in user sandboxes, at least until the participants can comfortably add referenced content. Even then, many will not be capable of getting to grips with WP:N, so ought not to be creating new articles until they are somewhat more experienced. In the rare cases where a new editor does have a notable subject with good sources, then I have no problem with doing any moves for them, if needed. I should say that the participant:instructor ratio really ought not to exceed around 12:1 (and half of that is better). It's always a good idea to have a capable assistant who is learning how to be an instructor anyway, as you can never be sure when you're going to be needed to solve an urgent problem, so the assistant can step-in to avoid "downtime". Anyway, my point is that I don't particularly need the ability to confirm new editors. It will be perfectly possible to run an event without it, even when ACTRIAL is running. It just means that some organisers may find that modifying how they work will yield better results. I'm always happy to talk through organising with folks who are uncertain. Please feel free to contact me on my talk page or by wiki-mail, if I can help. --RexxS (talk) 13:32, 19 August 2017 (UTC)
Though I don't do it exactly like RexxS does, my experience with running editathons as the Wikipedian in Residence of a museum is the same as his and, I too avoid the draftspace and encourage people to work in their sandboxes. While I'm not opposed, per se, to this proposal, neither do I have a need for it. Regards, TransporterMan (TALK) 20:24, 19 August 2017 (UTC)
  • Kaladri, one specific point: just dealing with ratelimit does not solve the problem. Many school and some library and university websites have their ip blocked because of persistent abuse--the even coordinator also needs ip block exempt. This would be necessary also. More generally, we also need to provide for unofficial editathons. Anyone can run an editathon, and some satisfactory ones have been done without contacting us at all. (A good number of unsatisfactory ones have been done that way also). Obviously we cannot extend special privileges to those who don't know enough to ask for them, but we shouldn't pose too great difficulties either. Incidentally, I think must people who use the internet are accustomed to CPATCHAs in all sorts of situations--that doesn't bother me.
My experience in NYC is a special situation, unlike many places, we have sufficient experienced event leaders and administrators to deal with this problem for all events that ask us for assistance--even when there are multiple events on the same day. We need to keep the others in mind also. DGG ( talk ) 04:22, 19 August 2017 (UTC)
CAPTCHAs for every single edit are not disruptive? — InsertCleverPhraseHere (or here) 05:33, 19 August 2017 (UTC)
@Insertcleverphrasehere: see Special:Captcha. CAPTCHA's are not required for every single edit at all. Even non-logged in users can make most edits without captchas. — xaosflux Talk 12:44, 19 August 2017 (UTC)
On the contrary, Special:Captcha is clear that "Unfortunately, this may inconvenience users with limited vision or using text-based or speech-based browsers. At the moment we do not have an audio alternative available." This is an accessibility barrier and needs to be resolved. In addition, making edits that add content require sources, most of which will be web-based and hence contain an external link that requires a CAPTCHA. I've had editathons where some well-prepared new editors actually were getting a CAPTCHA on every edit. --RexxS (talk) 13:32, 19 August 2017 (UTC)
I had the same issue at a recent editathon, editors adding external links getting CAPTCHAs on nearly every edit. It actually ends up discouraging new users from adding sources, which is pretty much the last thing we want to do to new editors at an editathon. — InsertCleverPhraseHere (or here) 14:48, 19 August 2017 (UTC)
It is significantly better if the CAPTCHA problem happens at an editathon (where a human can apologise) versus when a newbie is editing at home alone. We certainly should not discourage anyone from adding sources (but apparently we do). —Kusma (t·c) 12:23, 24 August 2017 (UTC)
@Xxanthippe: There are lots of good reasons to oppose but the userright should reduce special interest problems, not increase them. The WMF and other wiki sponsors already funds and encourages hundreds of annual editing events by special interest groups. Right now there is no system for tracking the connection between the sponsor and the wiki editing group, no way of tracking members of a collective editing team, and no way for the wiki community to capture the attention of every individual in a group to direct them to training or alert them to a group problem.
If you wish to counter wiki capture by groups, the place to address this is probably at the level of WMF policy, because so long as they are encouraging and funding this behavior, the problem cannot be addressed by avoiding action at the community level. Blue Rasberry (talk) 13:25, 25 August 2017 (UTC)
  • Support the technical details can be discussed later, but I think this right will help clarify and centralise the discussion and management of event coordinators, by viewing them as a separate group. Overall in the right direction. --Tom (LT) (talk) 08:26, 19 August 2017 (UTC)
  • Oppose I still don't see the need for editathons to bypass ACTRIAL... just going to an editathon doesn't mean you're going to write quality articles that don't need review.. -- There'sNoTime (to explain) 13:39, 19 August 2017 (UTC)
    • There's a misunderstanding here. Anyone can write an article in their userspace and then move it into mainspace without review. During ACTRIAL, it will simply mean that they have to wait four days before they can do that. It should be the case that the delay won't matter to an enthusiastic new editor who may work on an article for longer than that anyway; whereas the typical spammer will find it a barrier. The whole point is to decrease the number of unsuitable articles dropped directly into mainspace, not simply divert them into an ever-increasing queue at AfC. Being at an editathon certainly ought to mean that your work is reviewed there and then, by an experienced editor in person, before being moved into mainspace. --RexxS (talk) 14:33, 19 August 2017 (UTC)
  • Commentary There is still a need for people to "make accounts" at editathons - and auto confirmation is primarily intended to stop vandals; ACTTRIAL actually raises the overall bar for "what autoconfirmed means" here - to me it means "brand new editors" should use drafts - not skip it because they are at a specific location. I don't think having inexperienced edits (such as the ones getting account creator access today) is the way to manage an event at all though. — xaosflux Talk 14:31, 19 August 2017 (UTC)
  • Oppose This is little more than an attempt at an end-run round the previous withdrawn proposal. It has similar problems, as I and others have documented elsewhere. In particular, I documented some specific instances of long-standing event co-ordinators and past/present WMF staff who made the most ridiculous errors. While errors can slip through anyway, I don't trust any carte blanche being given that might imply some sort of "supervote" regarding the quality of submissions etc. - Sitush (talk) 20:31, 19 August 2017 (UTC)
some AGF its not an end run around the previous withdrawn proposal, its the person taking on board the concerns and rethinking the proposal which is what we expect to happen as issues are identified, then addressed by to proponents until we find a solution to an obvious problem. Gnangarra 02:54, 21 August 2017 (UTC)
It is not an "obvious problem" and, as someone else said above and I said on Kaldari's talk page prior to them mooting this proposal, Kaldari seems to have misread the consensus of the first proposal anyway. - Sitush (talk) 09:43, 21 August 2017 (UTC)
  • oppose i oppose this for the same reason i opposed the preceeding one. There is a misconception that new editors putting articles through AfC is any kind of bad thing. It isn't a bad thing. It should be the normal thing and i believe that one day it will the normal thing. Companies have orientation for new people; nobody starts driving without taking drivers ed first. It is not even a little kooky that brand new editors don't create new articles right away. This is just more backwards-thinking workarounds. If there is a desire to get immediate gratification for new editors, the coordinator can recruit an AfC reviewer to review on the fly. Jytdog (talk) 02:02, 21 August 2017 (UTC)
and we are suppose to be a community that anyone can edit and one that has no editorial oversight, yet AfC is both a preventing anyone from contributing new content and imposing editorial oversight on the contributions of others. Now telling event organisors that they need to seek out an approved AfC reviewer we might as well also change the name back to Nupedia or what was that other mob Citizendium or some such nonsense. Gnangarra 02:59, 21 August 2017 (UTC)
Wikipedia is a community that is dedicated to building an encyclopedia for the benefit humankind, and has made much progress in that aspiration. All other considerations are subordinate to that. WP:Wikipedia is not therapy. Xxanthippe (talk) 03:12, 21 August 2017 (UTC).
  • Oppose, the Wikipedia experience for newbies at edit-a-thons should not be substantially different from that of other newbies. If ACTRIAL ends up breaking edit-a-thons, so be it (maybe we'll find out that ACTRIAL is a bad idea). —Kusma (t·c) 12:20, 24 August 2017 (UTC)
  • Support in part: I think the user group/right should exist, but cannot agree with the "proven record of running successful Wikipedia editing events" criterion, since that's elitist and a barrier to getting things done. It verges on self-defeating, since it's people trying to organize such events who need the ability to do this. The cart is before the horse. You don't offer a useful tool only to those who've already proven they don't really need it to get the job done. There are other ways to weed out suspicious noobs from gaining potentially mischief-enabling power they shouldn't have.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  05:40, 25 August 2017 (UTC)
  • Oppose, sounds like a terrible idea. There's no reason to imagine that just because a user shows up at an event their contributions are automatically better than any other user, and a policy to help them avoid scrutiny is wrong for so many reasons. Andrew Lenahan - Starblind 16:50, 1 September 2017 (UTC)
    Actually after several years of editathons we can now say that editathon attendees are different from other newbies. A significant minority of newbies are vandals. I'm not aware of any editathon attendees who have had to be blocked as vandals - experience means we have good reason to believe that editathon attendees are much less likely to be vandals than other new editors. ϢereSpielChequers 20:56, 9 September 2017 (UTC)
  • Oppose per Starblind. – Train2104 (t • c) 18:28, 6 September 2017 (UTC)
  • Support this is good for productivity of new users who receive training at edit-a-thons. (See my comments above.) See if it works on its own. If it doesn't, make the right revokable when a given distributor of user rights creates a cadre of problematic users.--Carwil (talk) 18:14, 8 September 2017 (UTC)
  • Oppose - This proposed user right is unnecessary. Per above votes, we already have "Draft" namespace if newly registered editors want to create new articles. Also, if they want to become Confirmed users, they should go to WP:Requests for permissions/Confirmed, wait for four days, and/or make ten edits to become autoconfirmed users.

    As for edit-a-thons, which are for usually creating new articles (but also improving existing articles if new editors are willing to do so), rather than rely too much on tools, event coordinators/organizers should communicate with ACTRIAL coordinators or WMF if they are concerned about ACTRIAL. Also, they can go to the Wikipedia talk:Articles for creation if they find the AfC process problematic.

    I was going to raise the COI issue regarding this proposed user group, but then I saw one proposed rule saying that applicants should understand existing enWP rules, including the COI guideline, especially if they run edit-a-thons. Still, I don't think another user group is needed unless the community finds the rules to become Autoconfirmed too rigid. --George Ho (talk) 19:50, 9 September 2017 (UTC)

  • Comment — We need new AfC reviewers to deal with the influx of drafts that will come with ACTRIAL. the current situation (without the influx) is already a minor crisis: 1703 backlogged articles as of today.--Carwil (talk) 14:55, 13 September 2017 (UTC)

The above discussion is preserved as an archive of the debate. Please do not modify it. No further edits should be made to this discussion.

Modification of WP:PROF

An editor has started a discussion on the notability guideline for academics. Interested editors may wish to participate in the discussion. Thanks. Ivanvector (Talk/Edits) 14:31, 30 August 2017 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
The proposal is to change the guideline to say that Wikipedia should not necessarily have articles about BLPs that meet the NPROF criteria (e.g., "Made a significant impact on higher education"), but about whom editors have been unable to find any WP:Independent sources (e.g., sources that are not affiliated with that BLP and that support the claim about the BLP's research having any effect on higher education).
NPROF is one of the few (perhaps the only) WP:SNGs that does not make the existence of independent sources a universal requirement. WhatamIdoing (talk) 22:34, 30 August 2017 (UTC)
The claim is false. WP:Prof requires many (often 1000) citations to the work of the subject to pass WP:Prof#C1. Debate is at [47]. Xxanthippe (talk) 00:02, 31 August 2017 (UTC).
Yup. Exactly one (1) of the nine (9) criteria requires WP:Independent sources (NB that happening to cite your paper might not technically count as an independent reliable source about you).
That means that eight (8) of the nine (9) criteria – a smidge under 89% of the criteria – do not require independent sources. When 89% of the criteria do not require independent sources, I believe that it is entirely fair to say that the existence of independent sources is not "a universal requirement" under this guideline. I have not yet encountered any definition of universal that amounts to "in just one (1) of the nine (9) options", and until I do, I stand by my statement that NPROF "does not make the existence of independent sources a universal requirement".
I also note, for those less familiar with this guideline, that several of them are entirely subjective. NPROF permits BLPs on anyone who has made "a significant impact in the area of higher education", and it does not require even a single independent reliable source to attest to this claim. According to NPROF, an editor's personal opinion or the prof's university bio is sufficient to establish that the BLP had a "significant impact". WhatamIdoing (talk) 15:23, 12 September 2017 (UTC)
Why are you putting these comments here? The discussion is at the link I placed above. Most of the editors there are not aware of this thread, it's just a notification. Ivanvector (Talk/Edits) 18:02, 18 September 2017 (UTC)
  1. Because a little extra information about the subject of the discussion is more likely to attract interested editors than "Please see Mystery Meat on this other page".
  2. Because an editor replied here, to say that s/he thought I was wrong, and I cannot agree with him/her that "one criterion" is the same as "all nine criteria".
Also, please don't WP:COLLAPSE comments in an effort to stop discussions; it interferes with reading and searching (⌘F) for content on the page. WhatamIdoing (talk) 17:42, 22 September 2017 (UTC)

The above discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Changing the color of DELETION TEMPLATES from from red to light green/light blue

@Ritchie333: has a page User:Ritchie333/How newbies see templates.

It would reduce WP:BITE, if Prod, csd templates and "notifying page creator templates" don't have red color. Red is warning/danger sign. If these Twinkle "article deletion" messages are light green, it won't scare new editors. --Marvellous Spider-Man 05:34, 2 September 2017 (UTC)

Humm well it might scare them a little less. I'm ok with a change. Legacypac (talk) 05:53, 2 September 2017 (UTC)

I admit, green and blue seem a little incongruous on a "ATTENTION THIS PAGE MAY BE DELETED" template. Deletion is deletion, irregardless of whether the template is red, blue or green. Jo-Jo Eumerus (talk, contributions) 08:46, 2 September 2017 (UTC)
They will know that their article might be deleted. Red is a color of warning, which should be used only to warn vandals, or block templates. Creating article about non-notable actors, musicians, bands, politicians is not vandalism. They should not see red colored template on their article page and talk page. Marvellous Spider-Man 09:10, 2 September 2017 (UTC)
While I appreciate the intent here, red is the appropriate color for "THIS NEEDS URGENT ATTENTION". Alsee (talk) 17:52, 2 September 2017 (UTC)
Split the difference and use yellow or orange.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  09:01, 5 September 2017 (UTC)
Yellow seems right--or orange -- red is overused on WP. Are there any problems about accessibility? DGG ( talk ) 20:27, 6 September 2017 (UTC)
No more so than Red.
People with deuteranomaly and protanomaly are collectively known as red-green colour blind and they generally have difficulty distinguishing between reds, greens, browns and oranges. They also commonly confuse different types of blue and purple hues. People with reduced blue sensitivity have difficulty identifying differences between blue and yellow, violet and red and blue and green. To these people the world appears as generally red, pink, black, white, grey and turquoise.
So to color blind people it will look the same. (probably) Α Guy into Bοοks § (Message) -  09:15, 10 September 2017 (UTC)
Have a look at it yourself with Coblis if you want to check. — InsertCleverPhraseHere (or here) 04:52, 11 September 2017 (UTC)
  • Oppose. The Ambox color scheme was decided 10 years ago, and most changes since then have been minor. This is not minor at all. KMF (talk) 16:39, 16 September 2017 (UTC)

RfC: Amending WP:NMEDIA and related guidelines to accord with WP:PSCI/WP:NFRINGE

specific proposal withdrawn; keeping discussion open to see if something that can be worked out that might gain consensus Jytdog (talk) 21:01, 19 September 2017 (UTC)
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.

This applies to WP:NMEDIA and related guidelines WP:NFILM, WP:NBOOK, WP:PERIODICAL, WP:NJOURNALS, WP:BCAST, and WP:RPRGM.

Propose to add the following to each of the above, in order to accord with the pseudoscience policy WP:PSCI and the according guideline for notability, WP:NFRINGE, by adding the following:

A media property (a periodical, a book, a film, etc) that advocates a pseudoscience or other fringe perspective is not notable if there are not independent reliable sources with significant discussion of the pseudoscience or fringe nature of the content from a mainstream perspective, as described as WP:NFRINGE. Wikipedia articles cannot become coatracks for pseudoscience and fringe notions, under the argument that an article is about a book, movie, etc, and not also about the pseudoscience or fringe ideas that the media property propagates.

-- Jytdog (talk) 21:21, 18 September 2017 (UTC)

!Votes

  • Oppose – the proposal mixes two things: notability can be about more than the (pseudo)scientific content of a media franchise; that such articles don't become a coatrack for various side-topics is about the content of the article, not about its notability. With the above guidance many of Arthur Conan Doyle's writings are in danger of being deleted: they may contain fringey (pseudo)science (while, yeah, fiction, or something Conan Doyle believed in but which was disproved by later science) which may possibly not be discussed separately in literary analyses of these works; another example: "The Unparalleled Adventure of One Hans Pfaall" could no longer have a separate article, while built on pseudoscientific insights (e.g. that there's enough oxygen outside the atmosphere to be pumped in a vessel of waxed cloth for human survival), etc, etc. --Francis Schonken (talk) 21:40, 18 September 2017 (UTC)
We hate coatracks but the above proposal reads too much like burn every house that may likely ever contain a coatrack. --Francis Schonken (talk) 21:44, 18 September 2017 (UTC)
  • Oppose -- I don't care for the phrase significant discussion of the pseudoscience or fringe nature of the content from a mainstream perspective. This language seems to imply that if the mainstream analysis doesn't identify and criticize each and every detail for its inadequacies, then that aspect is off limits for Wikipedia. JerryRussell (talk) 23:41, 18 September 2017 (UTC)
  • Oppose I can see this being gamed already, as while things with pseudosciences can be generally objective, other fringe ideas - or at least what constitutes fringes ideas - can be highly subjective and could be used to shut down topics in political or ideological areas. Fortunately, we do have the requirement at WP:N that works need to be independent of the topic they cover, so a book published by a known proponent of a fringe concept covering that fringe concept is definitely not "independent" for notability determination. It can still be used if the topic is otherwise notable to document what those proponents state about the fringe idea (and we would be remiss in not including that if the fringe idea is notable otherwise per NPOV). --MASEM (t) 23:49, 18 September 2017 (UTC)
  • Oppose If this requires a formal !vote, here's mine. Mostly per myself (below) and Francis Schonken. Headbomb {t · c · p · b} 00:33, 19 September 2017 (UTC)
  • support As proposer. We are currently defenseless against pure COATRACK articles, where "reception" is entirely driven by low-quality but still impossible-to-exclude advocacy websites. Not a single opposer has addressed this. It is not game-able, as every article about a work advocating a controversial subject should have discussion in the Reception section representing the mainstream - or at least multiple - views on the subject matter. If there are none and all the refs are from one perspective, the work is not really notable. We should not have articles that are purely in any bubble. Jytdog (talk) 00:41, 19 September 2017 (UTC)
  • Oppose as written. Uses the difficult to define term "mainstream" as a basis for the entire policy change, which seems like a recipe for ambiguity and constant arguments. Pure fringe sources don't classify as reliable sources anyway, and hence do not contribute to notability. While notability for some articles might be based on sources that are not wholly 'mainstream', WP:NPOV pretty much prevents those articles from becoming advocacy themselves. I don't see how this would improve the encyclopedia, and can see some ways that it could be used to do a lot of damage instead. Plenty of things are notable but only of interest to certain fringe groups, but as long as our coverage is kept neutral, this is not a problem. The examples submitted below by the proposer are not convincing as problems in need of deletion, but rather seem clearly notable and present fairly neutral points of view on the subjects. — InsertCleverPhraseHere (or here) 01:25, 19 September 2017 (UTC)
  • Support in spirit. This is the right general idea, though I can't argue much with the wording concerns raised above. I would treat this RfC has a drafting process not a "do we ever want anything like this?" vote. The central premise of the proposal is already inherent in our policies. It's simply a matter of spelling it out in a way that people don't quibble with it.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  11:21, 19 September 2017 (UTC)
  • Oppose I'm not seeing a COATRACK problem. This proposal would require Orwellian denouncements of content in our articles based upon certain Wikipedians' orthodoxies. While critical commentary is needed in articles like Is Genesis History?, we cannot simply delete a well-written neutral article lest the reader come to believe a POV about which some disagree. This proposal evinces an effort to control the narrative which is out of step with our nonpartisan efforts to write an encyclopedia. Chris Troutman (talk) 15:20, 19 September 2017 (UTC)

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.

Discussion

For examples of where this was an issue, see:

I don't see any need for a specific quack-related guideline/amendment anywhere. In the first case, it both clearly passes WP:GNG and WP:NJOURNALS#C1. In the second case, it's a clear pass of WP:GNG as well (and closed as keep, not keep/no consensus). There's no need to have specific criterion for determining the notability of quack topics, whether the topic concerns quacks themselves, the specific quack theories, quack publications, etc. Journals/Movies aren't considered notable if they lack "independent reliable sources". That covers both quack and non-quack journals/movies. Headbomb {t · c · p · b} 21:29, 18 September 2017 (UTC)

The second is a clear pass only in violation of PSCI. The purpose of this RfC is to change the guideline so that it is clear that WP articles cannot be COATRACKS.
The general N guideline addresses articles about pseudoscience directly at Wikipedia:Notability#Fringe_topics but nothing addresses media that is propaganda for FRINGE/PSCI, and that is a big hole. And if you read the whole close of the creationist fakeumentary, it ends with This leaves us, given the headcount, with a rough consensus for keeping the article (or at the worst, with no consensus for deleting.). Jytdog (talk) 21:36, 18 September 2017 (UTC)
I don't see the coatrack. Reading Is Genesis History?, I find it a dispassionate treatment of the movie as a subject, and stays completely neutral on the subject of the movie. I'm surprised very little non-Christian sources analyze the movie, much in the same way you can find in Expelled: No Intelligence Allowed, but it could simply be no one bothered to look. Or maybe they don't exist because no one outside the Christian world cared. I don't see what either of these articles warrant additions to our notability policies. These articles are notable, both are clear passes of WP:GNG, and no amount of "but it's quackery" will make them non-notable.
As for "but nothing addresses media that is propaganda for FRINGE/PSCI, and that is a big hole" we have something that does cover that: WP:IS/WP:RS. Headbomb {t · c · p · b} 21:43, 18 September 2017 (UTC)Italic text
I will not be replying to you further. Jytdog (talk) 21:48, 18 September 2017 (UTC)
Typical Jytdog reply. Can't land arguments, ignore the person calling you on it. Headbomb {t · c · p · b} 22:23, 18 September 2017 (UTC)
Nope; you don't listen and misrepresent other people and I am not going to derail this dealing with malarky. You will surely write something snarkish in reply, and I will not reply to that. Sorry if you are all sweaty and Ready to Fight but I am not interested. Jytdog (talk) 22:26, 18 September 2017 (UTC)
The second has been stated as a clear pass of GNG, but I would challenge you to actually look for sources. Included in the list of sources keep !voters repeated are WorldNetDaily, Biologos Founadtion, Box Office Mojo, and other advocacy sites (which, regardless of their bias, do not contribute much to notability when posting about their focus subjects on their own websites). In fact, there was an extended discussion defending WorldNetDaily in that AfD. There are a couple other decent names mixed in, but upon further inspection they're simply press releases, screening announcements, brief mentions, and offer no in-depth coverage of the film (let alone sufficient coverage of PSCI/FRINGE, which were relevant issues, but the debate wound up resting on the question of whether PSCI was relevant, with most people uncritical of the claim that it passes NFILM/GNG. — Rhododendrites talk \\ 00:00, 19 September 2017 (UTC)
  • User:Francis Schonken no, it does not mix two things. N is the guideline that implements the WP:NOT policy - it answers the question: Does this topic belong in Wikipedia or not? The basic answer if GNG, as we all know. The idea is that if there are insufficient sources with which we can create an article that is WP:NPOV, the topic is not suitable for Wikipedia. WP:PSCI is part of NPOV. All this does is apply WP:NFRINGE to media properties that are propaganda for pseudoscience or FRINGE topics. The hole that was exploited to create the creationist COATRACK article is clear as day and easy to close. If you really do oppose this, how do you propose we prevent COATRACK articles from existing? (real question) Jytdog (talk) 21:48, 18 September 2017 (UTC)
    • Nah, the proposal is badly written. There can be a significant amount of independent reliable sources that don't delve into the is-it-true-or-not aspects of a literary work (or film, or whatever) that advocates a pseudoscience. On the merits of these reliable sources which discuss the work (without much discussing its pseudoscientific content) it can pass GNG without passing this proposed guidance. So no, wouldn't work. Tries to solve an issue of keeping out coatrack content by forbidding the article.
    Re. "how do you propose we prevent COATRACK articles from existing?" – by keeping out the coatrack elements. Suppose a gifted author writes a beautiful love story, but interwoven with pseudoscience advocacy. Press praises the book for its literary qualities, but largely ignores the pseudoscientific content. If then, the Wikipedians who write the article on that book keep to what reliable secondary sources have written about the book, they avoid the coatrack and keep the article. --Francis Schonken (talk) 22:33, 18 September 2017 (UTC)
User:Francis Schonken Thanks for replying but I don't see how it is possible to keep out RS that promote the pseudoscience. have a look at Is_Genesis_History?#Release_and_reception. What do we do about that? (and really I looked and looked and there is only one source (which is sub-WP:PARITY) that addresses the pseudoscience of this propaganda piece.) I feel you are being too ... glib here. (if you are watching and I shouldn't ping you pls let me know)
If you have ideas about how to improve the proposal, very open to that. Jytdog (talk) 22:38, 18 September 2017 (UTC)
Re. "RS that promote the pseudoscience" – maybe listen to yourself: "RS that promote the pseudoscience" are either not truly RS (then take to WP:RSN to check) or not truly promoting pseudoscience (take to WP:FTN to check). If neither of that helps, take to WP:NPOVN to determine how to incorporate content, in a balanced manner, from a RS that leaves a door open to something that would generally be considered pseudoscience.
Re my ideas "about how to improve the proposal": WP:SNOW (in fact: WP:TNT), this is not going anywhere while it mixes two things: notability (about the existence of articles) and COATRACK (about the content of an article, once its topic is deemed notable enough for existence). --Francis Schonken (talk) 22:56, 18 September 2017 (UTC)
I appreciate your time but we are far from SNOW, and you are not dealing with the difficulties of an article like the Genesis one or similar PSCI advocacy media. We will see what others say. Thanks again for your time. Jytdog (talk) 23:16, 18 September 2017 (UTC)
I think Is_Genesis_History is a perfectly fine Wikipedia article about a notable film. It can't be construed as promotion of pseudoscience as long as there's a link right at the top to the article about Young Earth Creationism. The more unfriendly this place is to diverse content, the more editors will get fed up and leave. Then there will be nothing left but MainstreamPropagandaPedia. JerryRussell (talk) 23:55, 18 September 2017 (UTC)

A more promising try (in the sense of likely to draw support) may be to add a qualifier rather than change the meaning of notability in this sense. By qualifier I mean something like an addendum to the notability criteria e.g. "Note that it is possible for a film to be notable, but to fall short of compliance with other content policies like WP:NOT, WP:FRINGE, or WP:NPOV. In such cases, it is usually preferable to redirect or delete the article rather than retain an article that cannot be developed beyond a stub." — Rhododendrites talk \\ 00:11, 19 September 2017 (UTC)

Stubs are better than redlinks. Headbomb {t · c · p · b} 00:36, 19 September 2017 (UTC)
It is not game-able, as every article about a work advocating a controversial subject should have discussion in the Reception section representing the mainstream - or at least multiple - views on the subject matter. this is problematic statement. Because we are such a wide variety of topics, this idea - while well-intended to prevent promotional regurgitation of fringe theories - would also potentially be applied to topics that do not regularly receive "mainstream" coverage but still are considered appropriate topics for WP here. I agree we have to be aware if all the sources for a topic in a fringe area are strictly all fringe-y, and they are all overly promotional (rather than being a more critical review), that's definitely a good sign that the item is not notable. But even within these fringe fields, there are "reliable sources" that are editorially control, and are reviewing these works from a critical eye rather than a proselytizing view, then that makes the works notable by our metrics. It doesn't matter it is fringe theory, as long as we write in a neutral tone and assign fringe claims to the appropriate attribution. --MASEM (t) 02:33, 19 September 2017 (UTC)
I wonder whether films such as Reefer Madness would be classified as something that "advocates a pseudoscience or other fringe perspective". Presumably Dressed to Kill (book) would be in that category, too. WhatamIdoing (talk) 17:55, 20 September 2017 (UTC)
  • I've withdrawn the RfC but am keeping discussion open to see if agreement on some refinement can be reached. Nobody has put out specific language and I look forward to seeing something like that. Jytdog (talk) 21:04, 19 September 2017 (UTC)
    The movie-article[48] you cited appears to have turned out acceptably. However I have an idea. I haven't thought it through deeply yet. If an article on a topic such as a movie significantly discusses a subtopic such as creationism, and our article on that subtopic explicitly identifies it as fringe/pseudoscience, maybe we should explicitly endorse adding NPOV context for that subtopic. That would apply even if we have no sources about the movie addressing the fringe nature of the subtopic. We would basically just insert text briefly explaining subtopic is pseudoscience and wikilink to good articles addressing the issue. Alsee (talk) 23:24, 22 September 2017 (UTC)
User:Alsee thanks for that thoughts. There is a very fine line between complying with PSCI by doing what you say, and editors committing WP:SYN by doing the debunking themselves instead of citing sources that do the debunking. The WP:FRINGE guideline talks about this some. I try like crazy to avoid the SYN thing. Jytdog (talk) 00:01, 23 September 2017 (UTC)

Define "COATRACK article"?

Taking a step back from the original discussion, maybe the issue should be analysed a bit more thoroughly before solutions are proposed (to avoid "solution in search of a problem" issues).

Maybe a good vantage point would be to give a good definition of "COATRACK article". The obvious meaning would appear to be "an article that is entirely (from start to finish) a WP:COATRACK". Well, if that is the case I suppose the problem could (and should) be addressed by a WP:RM – reasoning: if the entire content of the article doesn't fit under its stated article title, then move to an article title that does cover the content of the article.

But that does not seem to be (not by far) the issue which the proposal above aims to address. So, would it be possible to give a workable definition of "COATRACK article", or, at least, what it stands for in the discussion here? --Francis Schonken (talk) 07:28, 20 September 2017 (UTC)

I just looked at the WP:COATRACK essay again. Its actual title is Wikipedia:Coatrack articles, and sort of defines the "coatrack article" concept in terms of article content, with a variety of advice on how to handle coatrack issues (move the coatracked content elsewhere, remove bias, etc., see Wikipedia:Coatrack articles#What to do about coatracks). Multiple ideas afaics on how to "prevent COATRACK articles from existing", i.e., by transforming them into non-coatrack articles. Again, probably not what we're looking for here (unless, for instance, upgrading the essay to guideline status is what is being sought here – is it?). Maybe the "What to do about coatracks" section can be finetuned, with specific advice on how the type of coatracks that are experienced problematic in the current discussion should be handled. Still, an accurate definition of the kind of coatrack articles we're trying to prevent now (as opposed to the types of coatrack articles already covered by the guidance in the essay) would seem a first step. --Francis Schonken (talk) 08:53, 20 September 2017 (UTC)

User:Francis Schonken thanks for giving some thought to this. In the Is Genesis History article, the "hook" was the movieness (made by X, cast of Y, premiere on Z, box office of A) but the "coat" was the POV celebration of the creationist pseudoscience. I had to reach deep down in the gutter of blogginess to make the reception remotely compliant with PSCI - there are actually no mainstream sources that discuss this movie for what it is - pure pseudoscience. And if I hadn't been able to find that shitty blog that described the movie for what it is, it would still be a celebration of pseudoscience, right here in WP because of a lack of mainstream sources. We delete articles generally where there are insufficient sources to create an NPOV article. The AfD should have been a resounding "delete", but people concentrated on the hook (it's a movie) and ignored the coat. What can happen with this piece of progaganda can happen with any kind of propaganda - Nazi shit, racist shit, MRA shit, whatever shit. Hence the suggested change to the guidelines. There really is a problem with N guidelines that people can cite to allow POV Jytdog (talk) 23:58, 22 September 2017 (UTC)

RfC about refactoring

FYI: Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:Talk page guidelines#RfC: Should the guideline discourage interleaving? #2. The proposal could have significant impact on what is permissible under WP:TPO and WP:REFACTOR.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  10:14, 19 September 2017 (UTC)

Deprecate old parameters

per WP:IMGSIZE, the |image_size= should be deprecated fully from all infoboxes and replaced with |image_upright=. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 02:55, 20 September 2017 (UTC)

  • Oppose - IMGSIZE does not prohibit the use of pixel specification, it discourages it "except with very good reason". Unless someone can show that there is never a very good reason to use pixel specification in an infobox, we will continue to need support for the |image_size= parameter. ―Mandruss  09:05, 20 September 2017 (UTC)
  • Support in the absence of any evidence that this is neccessary or desirable. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:47, 21 September 2017 (UTC)

Tool to PROD, AfD, or Speedy Delete a class of articles

I came across a large (not sure how large) group of articles with the following characteristics:

  • Biographies of persons who died more than 200 years ago
  • Persons whose biographical references are likely not in English (the ones I found were Japanese)
  • Articles with no references for eight or ten years or more
  • Many were based on Japanese Wikipedia
  • These articles had propagated through the WP mirrors, making searches for original references a real slog

My belief is that a fan of samurai history figured out a way to quickly generate these articles into the English WP without any references. Because the references are likely to be in Japanese, an English language editor is unlikely to ever discover them. Having these article on the backlog will only slow down the task of cleaning it up.

As a general matter, articles for which the best references are not in English, and for which there are not English references and have not been for years, should be left to the editors of the natural language of the article. We should simply delete our musty articles. If they are later offered to English with references, we can take them. In the mean time, the current batch should go.

Technically, writing such a script should not be so difficult. Look for articles including {{unreferenced and {{Japanese name and whatever date parameter you want and you've got your selection tool. The tool can be generalized with the language of the name to help clear the backlog. Waddaya think? Rhadow (talk) 11:14, 20 September 2017 (UTC)

Have you tried searching the contribution history of the creator, including the page creations? Legacypac (talk) 11:23, 20 September 2017 (UTC)
On quick inspection, all the ones Rhadow presently has PROD-tagged are different creators. However, the edit history of Akechi Mitsutada shows an edit summary of "rm reference to Samurai Wiki" - possibly some or many of these were originally referenced from Samurai Wiki, which is less than optimal. ♠PMC(talk) 12:37, 20 September 2017 (UTC)
Ohh hell on closer inspection these are super hinky. Lots were created by Darin Fidika operating under a number of socks, including Cosmos Raver and Exiled Ambition, and others listed at his sock category. The master, Darin, was blocked in 2008 for serious issues including copy-pasting straight from Samurai Wiki. This ANI refers. There is also the page history at User:Nihonjoe/Samurai which describes the effort to clean all this trash up. Even if they're not copyvios now they're not great :| ♠PMC(talk) 12:54, 20 September 2017 (UTC)
Courtesy ping to Nihonjoe since a page in his userspace has been brought up. TonyBallioni (talk) 14:37, 20 September 2017 (UTC)
Anything created by this editor (under any username) is suspect. Feel free to browse through all the contributions by any of them and nominate anything that appears dubious. Given his history, it's entirely likely he's still operating under some undiscovered username, too. He seemed very miffed at being blocked over and over. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 15:40, 20 September 2017 (UTC)
I don't think such a script should be created since it will most likely lead to mass-nominations with serious WP:BEFORE violations. If there really is a group of such articles that need equal handling, such exceptional cases can be discussed at a noticeboard and if consensus is to delete them all, an admin can do so. Or you can create a multi-AFD for a set of them (say 20), tag them with AWB or similar and see if there is actual consensus to handle them all at once; somehow, I doubt it.
But the core assumption that we should delete articles because sources in English do not exist is contrary to WP:NOTENG and WP:NEXIST. If sources exist in any language, then the article should be kept, because readers should not be deprived of information just because some people here cannot read Japanese. Regards SoWhy 15:10, 20 September 2017 (UTC)
Hello SoWhy -- I understand your line of argument. The result of it, though, is a free pass for any article about Flat earth or Pink elephants written prior to 2007, because someone believes there are existing references in Old church slavonic. Pink elephant articles will stay in the list of 280,000 unreferenced articles. It shifts the burden of proof from the reckless copy-n-paster to the hapless volunteer. As long as we celebrate the number of articles created by an editor, rather than the quality, the backlog of unreferenced articles and pointless lists will continue to grow. Rhadow (talk) 16:05, 20 September 2017 (UTC)
I think you misunderstood. Deletion of articles because they are completely unverifiable is perfectly acceptable, see WP:DEL7. What you were proposing though is deletion of articles that are verifiable but just are not yet referenced. That is what I object to, because there is no deadline. Regards SoWhy 16:17, 20 September 2017 (UTC)
  • Oppose Such a script would be contrary to policy. Andrew D. (talk) 21:09, 21 September 2017 (UTC)
  • Comment a maintenance category could probably be used instead? —PaleoNeonate – 21:30, 21 September 2017 (UTC)
  • Apart from opposing much of the rest of what is proposed here, I would point out that the existence of Wikipedia mirrors doesn't in any way get in the way of finding sources. It is silly to expect sources for people who died over 200 years ago to be available on web sites anyway, so the fact that Wikipedia articles are mirrored there doesn't get in the way of sensible searches for books and academic papers. 86.17.222.157 (talk) 21:42, 21 September 2017 (UTC)

Re-hiding the siteSub "from Wikipedia blah blah"

In the same fashion as when suffixes of browser titles were shortened from "- Wikipedia, the free encyclopedia" to "- Wikipedia",

I suggest removing the text "From Wikipedia, the free encyclopedia" that is displayed below the <h1> page titles. It's pretty obvious we are on Wikipedia, it just adds clutter. Note it is hidden by default in MediaWiki.

Refs:

  • https://en.wikipedia.org/w/index.php?title=MediaWiki:Monobook.css&diff=prev&oldid=4764942
  • https://en.wikipedia.org/w/index.php?title=MediaWiki:Vector.css&diff=prev&oldid=300913899
  • https://en.wikipedia.org/w/index.php?title=MediaWiki:Modern.css&diff=prev&oldid=187577589
  • Cologneblue skin shows it by default.

Od1n (talk) 22:04, 22 September 2017 (UTC)

Od1n, if Monobook, Vector, and Modern all hide it, it sounds obvious to remove it and reduce page size. However since it's hidden, could you post a screenshot of Cologneblue displaying it? I'd like to know what we're considering removing, before supporting removal. :D Alsee (talk) 22:38, 22 September 2017 (UTC)
Just use query string useskin=cologneblue. Also I just noticed cologneblue doesn't remove it from the homepage, contrarily to the other skins. This reveals that skin isn't much supported by en.wikipedia in practice. Od1n (talk) 04:29, 23 September 2017 (UTC)

Idea lab

# as used for numbered lists

# at the starts of lines makes a numbered list, as is well known. But how can I make the sequence of numbers start with 0 rather than 1? Anthony Appleyard (talk) 16:14, 10 September 2017 (UTC)

Draft of proposal regarding WP:OR and terrorism

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.

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" (e.g., [49], [50], [51], [52], [53]). 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., [54], [55]). 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.

Proposed solution: Address this issue by amending WP:OR (or similar policy?) 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". I am hoping that VPIL can help determine exact wording.
  2. Cases where terrorism is "suspected" should be labeled as "suspected" by Wikipedia as well until this suspicion is officially confirmed or denied.

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) 18:40, 12 September 2017 (UTC)

Anyone have any suggestions? EvergreenFir (talk) 20:10, 15 September 2017 (UTC)


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.

Let editors ask for review?

I recently noticed on another editable website site that when you try to save your edit there is a prompt like "Ask another editor to review this edit?". I thought this was a marvelous idea. I was a new editor there and the editing was quite complex so I could really relate to the feeling of uncertainty that a new editor feels. When the site asked me to ask another user to review my edit, it felt nice and it was a great way for me to signal that I was uncertain if I'd done something right and I needed help until I get more familiar with the editing on the site. It also tells other users that even if I screwed up an edit that I was participating in good faith. I think such an idea might really work well at Wikipedia too. Perhaps a proposal might be to have by default all edits by IPs and new accounts asking if the editor would like such a review. We'd also have to think about how we'll handle these requests; so ultimately we'd have to upstream a proposal to Mediawiki as a feature request, but what are your general thoughts on the impact on users? Would it help them? Help reader retention? New editor uptake? Etc. Jason Quinn (talk) 15:15, 14 September 2017 (UTC)

The idea sounds good on paper but who will actually review those edits? We already have a review system at WP:AFC which is extremely backlogged, not to mention all other reviews that need to be done. I'd love to see this idea in action but unless the Foundation starts employing reviewers, there will likely not be enough people to handle such requests in a timely fashion Face-confused.svg Regards SoWhy 16:02, 14 September 2017 (UTC)
This idea is really, really good. I can see no drawbacks at all of this idea, and I completely agree with all of the upsides you mentioned. If someone can work on this, that would be awesome. Maybe we could start with a default-on gadget that sends an API call off to a toollabs tool, which logs the edit in a database and makes it visible to a dashboard that volunteers would look at? (I also disagree with what SoWhy said - AfC and all of the other "review" systems that he brings up are for the page creation process, which is necessarily heavyweight. But looking at individual edits would be lightweight, so the backend systems should be correspondingly simple and not complicated.) Enterprisey (talk!) 00:08, 15 September 2017 (UTC)
Not a technical editor but it seems like implementation might be similar to the (likely abandoned) WP:Deferred changes project, where tagged edits will appear at Special:PendingChanges. Rolling out this feature should be done cautiously to prevent pending changes from being severely backlogged, though. Perhaps someone could even finish the deferred changes project while working on this, though that seems unlikely. Darylgolden(talk) Ping when replying 05:29, 16 September 2017 (UTC)

An anti-WP:SOAPBOX task force/notice board?

The below is transposed from Wikipedia talk:What Wikipedia is not: it got a fair amount of support there (and do please read that conversation), but I'd like to take it a 'level up' and transform it into a concrete proposition, so any input and help would be appreciated.

Since Wikipedia is (one of) the world's most consulted website-references that 'anyone can edit', that makes it a prime target for anyone seeking to WP:SOAPBOX-'broadcast' it. I've seen this a lot in my ~13 years here, but have seen little done to counter it.

It takes a contributor/admin with a lot of patience and experience to see a widespread, organised 'slow attack' pattern any given conflict (because where there's soapboxing, there's most always conflict), but most are too busy/'here and now'-focused to see any larger pattern, and any admin intervening towards the end of such a conflict will find an unreadable talk-page mess almost impossible to unravel, which makes one tend to take claims at face value and only deal with the behavioural aspects of the situation, and this too works to the soapboxers' advantage.

Most of the tactics used to impose and 'enforce' non-WP:V is a 'slow attack' that often passes under the radar (and over the head) of beleaguered admins and Wiki in general. Namely:

  1. Refusal to engage in discussions over challenged content *
  2. Off-wiki networking *
  3. 'Us' and 'them' behaviour *
  4. Poisoning and 'drowning' debate *
  5. Targeting the opposition *
  6. Multiple accounts and frequent name-changing *

While soapboxers learn from their successes and failures, Wikipedia does, too, but soapboxing seems to be still both above and below Wikipedia's mostly 'here and now' radar. But if some patience-laden people conscious of this trend were to populate a task force or notice board dedicated to countering it, it might focus and streamline efforts in that direction, as well as raising vigilance against future occurrences. TP   20:10, 17 September 2017 (UTC)

  • Comment - While I don't object, we also already have WP:NPOVN for point of view issues (including soapboxing) and WP:COIN which can also be used in cases of self-advertizing. We also have WT:WPSPAM where people experienced with link spam can add links on a list to be automatically reverted, or add a pattern to a blacklist. —PaleoNeonate – 21:21, 17 September 2017 (UTC)
Thanks, I've seen these, but they seem to be efforts to treat 'here and now' dilemmas; soapboxing campaigns are often both discreet and long-term (one instance I was involved in (countering) lasted a decade). TP   21:28, 17 September 2017 (UTC)

Second chance for requested articles

Wikipedia has Wikipedia: Articles for deletion, and it is not all uncommon for an article to go through a second nomination for deletion there. Wikipedia also has Wikipedia: Requested articles, and some requests - such as the request I made some time ago for an article called "Parametric data" - have been there a long time. Would it be possible to have a box in the requested articles box called "Second requests?" I do not know how long articles can remain at Wikipedia: Requested articles without been removed, but if articles cannot remain there indefinitely, this idea might help Wikipedia. Vorbee (talk) 15:47, 19 September 2017 (UTC)

There was an old project called Wikipedia:Articles requested for more than a year that has apparently become defunct. That's unfortunate. Personally I think the whole "requested article" process could be greatly improved. For example, it should track the original poster, the date posted, allow for a longer description, have a way to add suggested sources and/or signed comments, flag when a request is older than some interval, and have a process to remove completed or non-notable requests. Right now it's too informal and subject to vandalism.
As for parametric data, isn't that covered by parametric statistics? Or do you have something else in mind? Praemonitus (talk) 22:13, 20 September 2017 (UTC)
Does the requested article process actually work at all? Does a significant number of articles get created after being listed there? These are not rhetorical questions, because I don't know the answer, but it would be useful to know whether there is actually any point to this process. 86.17.222.157 (talk) 17:52, 22 September 2017 (UTC)

Miscellaneous

Links to Wiktionary

I recently (11 September) made two internal Wiktionary links, thinking this was correct. The reverting editor (13 September) failed to give reasons/guidance at the edit summary, and has failed to respond to a polite request for reasons at their talk page, but has logged-in since and I want to get on top of it without waiting further.

Apologies if approaching the Pump seems a cop-out instead of doing lengthy research on a minor point, but if someone could confirm what the issue is here - for example - are Wiktionary links becoming deprecated - then I would be obliged. I admit the links look clumsy, but I didn't write the template, and I was thinking of the readers, including non-English first speakers when writing the original prose with Wiktionary links. Many thanks! Semperito (talk) 09:25, 14 September 2017 (UTC)

No problems, false alarm I hope - I've learned it's easy to pipe-link to Wiktionary, avoiding the clumsy appearance, that I assumed would not be possible. I have re-established the links and invited the reverting editor to comment at the article Talk page, if necessary. Semperito (talk) 13:31, 15 September 2017 (UTC)
In my personal opinion, it would be better not to link to Wiktionary inline. In the examples you provided, if you feel that a word in your prose needs to be linked to a definition for an English audience, you should probably rewrite in more accessible language (WP:TECHNICAL covers this, albeit for a different case). For example, you could wikilink to remonstrance, and you could use "affluent" or even simply "wealthy" or "rich" rather than well-heeled, and could link that to affluence or wealth if those meanings are close enough to what you intended. Although you also don't have to link everything. If you feel you absolutely must use these words which require definition, it would be better to insert a redlink anyway, and then create a soft redirect to Wiktionary with the {{Wiktionary redirect}} template - this way we have the ability to link to that redirect from other articles, and track if readers are really clicking through for additional information. See instructions at the template for how to use it, and when you should and should not create a redirect - you definitely shouldn't create them for every dictionary word. Ivanvector (Talk/Edits) 13:59, 15 September 2017 (UTC)
Thank you - I will research this further, as you suggest. Wikipedia gets - IMO - too-disparate and too-technical with the available options that need expertise in understanding, and is not time-effective for something I don't recall using previously, and may not use again.

In the case of well-heeled, the film character is a well-established scrap-metal dealer, historically notorious in UK society for business practices using cash and having large disposable incomes; the character has a good, well-groomed appearance, an expensively accessorised motor scooter and fine clothing including a long, tailored leather overcoat, whereas the lead film character is young, with a base-level office job and pays weekly in advance towards a new, tailored cloth suit, covered with an ex-army Parka, as was the vogue at the time; well-heeled covered all aspects of what I needed, as did remonstrated.

I couldn't think of anything better at the time of writing, and I would've preferred to know the deleting editor's motivations, who chose not to replace the words. I am always conscious of the needs of, for example, people in, or originating from, near-Europe who may have a good grasp of English language but may need assistance that a wiktionary link could provide. I'll try to find synonyms to 'dumb it down'. Semperito (talk) 14:48, 15 September 2017 (UTC)

Inline links to Wiktionary are permitted (see Wikipedia:External_links#cite_note-body-2 for the official guideline). I don't usually see it used for "technical" things; it's usually more common for what you might call "fancy vocabulary words". Since one of our goals is Wikipedia:Brilliant prose, then "dumbing it down" is not usually the right choice. WhatamIdoing (talk) 17:32, 19 September 2017 (UTC)

Search Relevance Survey on diff page of MoS

Not quite sure where to put this, so I figure here is better than nowhere. I was viewing a Difference between revisions on the MoS when a bubble appeared in the top right with the question "Would you click on this page when searching for 'half adder truth table'?" and the options "Yes", "No", and "I don't know", as well as a link to wmf:Search Relevance Survey Privacy Statement. This was the first time I'd ever seen something like this, and I was confused by the wording. While copying the text, I accidentally clicked inside the bubble but outside the options, dismissing it, but now that I understand what it was asking, I want to say for the record that I highly doubt I would click on a diff page of the MoS when searching for 'half adder truth table'. ReGuess (talk) 16:11, 14 September 2017 (UTC)

@ReGuess: Sorry no one responded sooner. This seems like a weird glitch. There shouldn't be surveys on diff pages. I don't think there should be a survey on the MoS page, either. I know it's been almost a week, but do you have any recollection of what you were doing right before that? The survey should have popped up 30 to 60 seconds after you started reading a targeted page. Any chance you were reading a page, jumped to the MoS page, and then jumped to a diff, all within 30 seconds (or maybe a few seconds)? Even then it sounds like a strange browser glitch, which are the hardest to reproduce. If you have any info, though, it might help. This was a small scale test, and we want to make it better if we proceed with a larger implementation. Reply here, or on Phabricator if you like. Thanks. TJones (WMF) (talk) 14:30, 20 September 2017 (UTC)
@TJones (WMF): Power users use search outside of content space, so I would appreciate machine learning to help me find not-the-endless-pages-of-articles-for-deletion. You might reasonably have different tuning there, I guess... :) --Izno (talk) 14:40, 20 September 2017 (UTC)
@Izno: Can you message me or comment on this Phabricator ticket with more details and examples for what you are looking for as a power user? Not sure what to make of "not-the-endless-pages-of-articles-for-deletion". Thanks! TJones (WMF) (talk) 14:50, 20 September 2017 (UTC)
@TJones (WMF): I can't recall exactly what I was doing, or how quickly I was switching between tabs, but I don't think it was anything special, and it didn't have anything to do with logic gates (a subject that, while I do have great interest, if you dig deep through my contribs, you'll probably see I might have a contributed a copyedit here or there). I happened to have kept the browser tab open, so here it is in case it's of any interest: [56] ReGuess (talk) 19:23, 20 September 2017 (UTC)
@ReGuess: Thanks for the link. It may help track down what happened—but this one is pretty weird. For better or worse, a lot of the survey questions end up not being terribly relevant to the page they are on. See this blog post for more info on what we're trying to do and why, if you are curious. TJones (WMF) (talk) 20:07, 20 September 2017 (UTC)

Zimbabwe_African_National_Liberation_Army

This is probably the wrong place but I've had enough find Permit A 38 for today.

Anyway, someone knowledgable with a neutral POV should probably have a look at https://en.wikipedia.org/wiki/Zimbabwe_African_National_Liberation_Army and its sources and at least delete the unsourced parts. --2A02:8071:B693:BE00:D814:5296:7CAE:AD4F (talk) 17:43, 17 September 2017 (UTC)

The text looks like it was copied from somewhere. Ruslik_Zero 19:06, 17 September 2017 (UTC)
Possibly from the "dominant" source: Ndlovu-Gatsheni, Sabelo J. (18 October 2013). "Rethinking Chimurenga and Gukurahundi in Zimbabwe: A Critique of Partisan National History". African Studies Review. 55 (03): 1–26. doi:10.1017/S0002020600007186.  Why do editors cite sources that are available online as if they are not? Roger (Dodger67) (talk) 13:54, 22 September 2017 (UTC)

RfC regarding "Interlinking of accounts involved with paid editing to decrease impersonation"

There is currently a RfC open on Meta regarding "requiring those involved with paid editing on Wikipedia to link on their user page to all other active accounts through which they advertise paid Wikipedia editing business."

Note this is to apply to Wikipedia and not necessarily other sister projects, this is only to apply to websites where people are specifically advertising that they will edit Wikipedia for pay and not any other personal, professional, or social media accounts a person may have.

Please comment on meta. Thanks. Send on behalf of User:Doc James.

MediaWiki message delivery (talk) 21:06, 17 September 2017 (UTC)

christopher gikas

sadly, Wiwaxia passed away on February 25, 2017. http://www.legacy.com/obituaries/name/christopher-gikas-obituary?pid=1000000184323976&view=guestbook. he will be missed
— Preceding unsigned comment added by 2601:644:101:2c0e:20c2:48e1:7c38:d9d3 (talk) 23:29, 18 September 2017 (UTC)

men's assistant coach or assistant men's coach?

Hello, I'm not sure it's the right place to ask, but here it is anyway. English is not my mother tongue and I didn't find by myself. I have a seen 2605:E000:9161:A500:34F4:4D6D:1063:30AF (talk · contribs) is repeatedly making the same change (see title), and out of curiosity I would like to know fore sure which one is correct. Google has hits for both ([57], [58]). Maybe an american/british english difference? Does anybody have a definitive explanation about this?

Kiwipidae (talk) 05:57, 20 September 2017 (UTC)

Discussion on synced reading lists

CKoerner (WMF) (talk) 20:35, 20 September 2017 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(all)&oldid=638744879"
This content was retrieved from Wikipedia : http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(all)
This page is based on the copyrighted Wikipedia article "Wikipedia:Village pump (all)"; it is used under the Creative Commons Attribution-ShareAlike 3.0 Unported License (CC-BY-SA). You may redistribute it, verbatim or modified, providing that you comply with the terms of the CC-BY-SA