Please see Wikipedia talk:Templates for discussion#RfC: Proposal to make TfD more RM-like, as a clearinghouse of template discussions.  —  SMcCandlish ☏ ¢ 😼  05:17, 27 February 2019 (UTC)

There's a long and continuing edit war going on at Sofia Airport (and several other airport pages, but curiously only a select few) regarding removal of future routes from airline destination tables. Typically, as evidenced at airports worldwide such as Dubai International Airport#Airlines and destinations, Phoenix Sky Harbor International Airport#Airlines and destinations, Melbourne Airport#Airlines and destinations, and Jomo Kenyatta International Airport#Airlines and destinations, describing our current general policy shows future routes can be listed in destination tables if properly sourced. The edit war goes in circles, though, since the reverting editors continually cite WP:PROMO, WP:CRYSTAL and WP:NOTTRAVEL. I don't think any of those actually apply - we note all future routes objectively, so we're not advertising them, we require sources for routes per WP:CRYSTAL (and never have any problems finding sources). Finally, WP:NOTTRAVEL has had a sticky past with transportation articles since anything transportation related is necessarily travel related, and it seems that either the entire airlines and destinations table fails WP:NOTTRAVEL or none of it does. (I strongly believe it does not – I use the information encyclopedically to do basic research on transport routes/city and airport connectivity.) But I wanted to pose the question at a place where non-airport editing users might see it: Is the rule "Future routes may be included in an airport's airlines and destinations table if properly sourced" an accurate reading of our current policy? Thanks in advance. SportingFlyer T· C 14:14, 28 February 2019 (UTC)

The article American and British English spelling differences includes a lot of words that are Wikipedia articles themselves. Reading through them I noticed that there is no uniform way in which the alternative names are presented. See below a small sample of the first sentence of some articles (references also copied from the articles):

• rumor ( American English) or rumour ( British English; see spelling differences)
• Color ( American English), or colour ( Commonwealth English)
• caliber or calibre
• fetus or foetus
• license (American English) or licence (British English) ^[1]
• Hemoglobin (American) or haemoglobin (British)

As you can see, there are too many different ways in which the spelling differences are presented.

The proposal is to update the first sentence so that it is uniform and just contains the alternative names in bold, with no link or reference since the main topic has nothing to do with American or British pronunciation in most cases. Vpab15 ( talk) 23:33, 26 February 2019 (UTC)

• Support as proposer Vpab15 ( talk) 23:34, 26 February 2019 (UTC)
• This is about the content of the article. You should raise the issue at Talk: American and British English spelling differences, not here. – Ammarpad ( talk) 04:44, 27 February 2019 (UTC)

  Vpab15 is actually talking about the leads of the various talk pages, so can't raise it there; probably MOS:LEAD or some MOS page's talk page would be the best place to raise this. Galobtter ( pingó mió) 05:21, 27 February 2019 (UTC)

  Thanks, moved discussion to Wikipedia_talk:Manual_of_Style/Lead_section#Unify_alternative_names_for_articles_with_spelling_differences. Vpab15 ( talk) 14:16, 1 March 2019 (UTC)

I have two ArbCom-related questions.

What comes next?

What is the best venue for the current dispute at Wikipedia:Arbitration/Requests/Case to continue at if it is not heard by ArbCom? Qzekrom 💬 ^they_them 18:50, 6 March 2019 (UTC)

Participating in ArbCom

(Moved from Wikipedia:Village pump (miscellaneous))

I believe that the current dispute at Wikipedia:Arbitration/Requests/Case should be heard by ArbCom, but I don't know what I could say that hasn't already been said by the other users that posted statements. Basically, I agree that some aspects of this dispute have already been resolved or can't be resolved through arbitration, but I think other parts of it (the conduct stuff) can't be resolved effectively except through arbitration. What should I say? Is what I have written here enough? Qzekrom 💬 ^they_them 06:46, 6 March 2019 (UTC)

This is already being discussed in multiple places. Do not try to spread it elsewhere as well. Natureium ( talk) 19:03, 6 March 2019 (UTC)

Natureium, I don't want to discuss the issue itself here. I came to VPP because I wanted advice on how (and whether) to get involved in the discussion in the proper venues. Qzekrom 💬 ^they_them 23:09, 6 March 2019 (UTC)

• I would say to just let the matter go. If it is the consensus of the community, and if ARBCOM also concurs, that there is nothing more to do, then there is nothing more to do. If the matter persists into the future, that is if the kinds of behavior that led to the ARBCOM filing, continue repeatedly, we can revisit the matter, but if nothing else bad happens going forward, there's no need to continue pursuing anything. -- Jayron 32 19:05, 6 March 2019 (UTC)

  @ Jayron32: It looks like ArbCom is settling on deciding that the case would best be handled in another venue. There is one aspect that I predict will come up again in the near future, and that leaves me concerned. So far I'm not really doing anything, but I want to see which way it goes. Should I push to get it addressed now or wait for it to come up again? Qzekrom 💬 ^they_them 23:20, 6 March 2019 (UTC)

  I would say it would better sum up the results of the ARBCOM discussion that the committee roughly believes that the community has handled the issue in other venues. The two most recent decline votes basically say as much, and one of the few accept votes, that of SilkTork, basically declines all aspects of the case as "the community already dealt with this" except for one small issue, and there is not much consensus, among either the community at large, or other ARBCOM members, that the particular issue he thinks needs dealing with is an issue at all. (particularly relevant is Ivanvector's comments regarding the appropriateness of prosecuting whistleblowers...) In all, I would say that ARBCOM isn't saying the community needs to do more to deal with the issue, they're largely saying that it has been dealt with, and that there isn't any good reason to keep this fire burning any longer. -- Jayron 32 11:24, 7 March 2019 (UTC)

Depends on what exactly you want to achieve, but usually an WP:RFC, at either WP:VP or WT:SIGNPOST would be the way to go. I'd wait until the Signpost makes a statement before doing so, personally, but Bri has yet to come back from his Wikibreak due to the situation. Headbomb { t · c · p · b} 23:31, 6 March 2019 (UTC)

RFC probably, depending on what you're trying to achieve. But if you want remedies and AC doesn't take up the case, there's no other choice but a request for comment, that is the only binding method possible, and one that ArbCom doesn't have a choice to reject or not take up. -- QEDK ( 後 ☕ 桜) 19:00, 7 April 2019 (UTC)

Is anyone aware of any past or current discussions about Russians potentially engaging in government-sponsored disinformation on Wikipedia? To be clear, I don't mean accusations pointed at specific editors. I'm thinking more of VPP discussions about the problem more broadly, detecting if it exists and how it might be addressed. After all, we know Russian disinformation is on all major social media platforms, so why wouldn't it be on Wikipedia? I know I'm not the only one thinking about this. And Russia was caught doing this at least once, though in a ham-handed way in 2014. Please ping me, as I won't be watching this page. R2 ( bleep) 17:30, 8 March 2019 (UTC)

I don't think I've seen any particular "Russian" effort, but that's probably because there are always POV pushers all over Wikipedia so that one more campaign does not necessarily stick out. Jo-Jo Eumerus ( talk, contributions) 19:28, 8 March 2019 (UTC)

I agree. There are all sorts of people, including those organised by or editing in support of states, who behave in this way. There are some who make themselves obvious and get blocked or banned quickly, and there are some others who make lots of good edits but show their true intentions in a particular area. All we can do is to be vigilant. And, by the way, if you want to see the responses to your edit then do put the page on your watchlist. It's not up to other people to obey your commands about pinging. Phil Bridger ( talk) 19:41, 8 March 2019 (UTC)

Geesh, I was just asking for a courtesy, you were under no obligation to comply. Anyway, the thing that makes Russia different from other POV pushers is that the Russian online international disinformation effort is by far the biggest in the world and is well-documented in the reliable media. I've been wondering for some time whether the armies of editors who push for certain POVs on certain pages are in fact paid by the Internet Research Agency or related entities, in violation of our TOS. Whether that is something that can or should be investigated or addressed would be an open question. I'm merely trying to educate myself on whether this has been discussed in the past. R2 ( bleep) 20:07, 8 March 2019 (UTC)

Personally, I don't think that the pro-Russian POV-pushers are worse than any other POV-pusher, and we have a wide variety of them from antivaxxers to ufologists. Which might say that this IRA isn't active on Wikipedia. Or it might say that IRA-sponsored POV-pushing is no worse than the other kinds of POV-pushing. Jo-Jo Eumerus ( talk, contributions) 19:47, 9 March 2019 (UTC)

Speaking of anti-vaxxers, a recent study found a Russian involvement: [1]. This is how they work, they get involved in controversial topics and blow it up and amplify it for the purpose of sowing FUD. The Russians were famously behind the myth that AIDS was a US government conspiracy. The Russians "promote discord" and it works! -- Green C 20:16, 9 March 2019 (UTC)

I don't doubt at all that Russians are involved in spreading misinformation - you will see that I have in the past had run-ins with conspiracy theorists, who may or may not have been sponsored by the Russian government, on the article that you linked and others where people tried to spread nonsense about HIV and AIDS, but there are plenty of others apart from Russians who engage in such activity. We should be careful about all POV-pushers, not just Russians. Phil Bridger ( talk) 20:31, 9 March 2019 (UTC)

We also shouldn't minimize or discount it, either. -- Green C 04:05, 10 March 2019 (UTC)

I'll be so happy, if & when the new McCarthy era comes to an end. GoodDay ( talk) 20:10, 8 March 2019 (UTC)

• I'd be surprised if we didn't have some Russian state editors on the site (between here and their own Wiki, I'd imagine). However, nothing particularly has jumped out - there's lots of ranting on the Crimea page and I suppose either side could be them, but nothing that indicates evidence on the issue. — Preceding unsigned comment added by Nosebagbear ( talk • contribs)
• Probably not, it's best not to worry about stuff till we have evidence we need to worry about it. And considering America's legislature isn't averse to editing Wikipedia, there's not much wiggle room when it comes to finger-pointing. SITH (talk) 16:43, 9 March 2019 (UTC)
• You might find some stuff in the archives of User talk:Jimbo Wales, which is the natural home for this sort of discussion. I'd agree with others that few campaigns are going to make a successful difference on this wiki. However, I wouldn't be surprised if Russia's English Wikipedia efforts concentrated on influencing secondary sources. For example we have over 1,000 links to Sputnik, which is something I wouldn't normally recommend. -- zzuuzz ^(talk) 16:52, 9 March 2019 (UTC)
  • Basically this. Every time you see a link to Russia Today or Sputnik, you are seeing the effects of Russian propaganda and social engineering efforts. These sources exist for no other reason other than to populate the public discourse with the official government position. Some of these people may be active agents of the movement, proactively trying to add these to push a POV. Others may have just found a "source" that they intuitively agree with or that fits their preconceptions, and so they use it more as a dupe than as a co-conspirator. There is no real difference for our purposes. GMG ^talk 17:08, 9 March 2019 (UTC)
    • I agree that that is the case when such sources are used for anything that is controversial, and that also goes for many of the non-Russian sources that are accepted uncritically as reliable, but they are reliable for such things as who has been appointed to which official position or for the football results. Sources are only reliable or unreliable according to the context. Phil Bridger ( talk) 18:06, 9 March 2019 (UTC)
      • No. These sources only exist for the purpose of operating a propaganda arm of the Russian government. If you really need a source for the mundane details of the latest football match, then there are surely plenty to choose from, and no reason to use these in particular. The only reason the US Department of State doesn't give you the stats on the latest game is because the US DoS isn't trying to masquerade as a news agency. GMG ^talk 18:17, 9 March 2019 (UTC)

(cough, cough) Radio Free Europe/Radio Liberty..... Carrite ( talk) 11:54, 29 March 2019 (UTC)

• Significant programs of interference in social media exist in Russia, China, Iran, North Korea and a few others - and Wikipedia's open culture is dangerous and antithetical to those regimes. There is no question Wikipedia is on the list of sites to influence, we are the top 5 site in the world, get the top google hits and "anyone can edit" - of course they are. I read an article about this concerning Wikipedia (forget where) describing how IPs and socks don't work well, so the trick is to use long-term reputation accounts ("unblockables") and even admin moles. Personally I think that method is too expensive and low impact. A cheaper method would be to undermine and confuse reality (and Wikipedia's reputation) by quietly injecting wrong and distorted information that has no apparent bias looks like incompetence. This is essentially how they undermine the free press, by creating confusion and a mix of false and true, it is misdirection trick you don't know who to blame or trust, it keeps authoritarians from being ousted. -- Green C 17:45, 9 March 2019 (UTC)

You're thinking of the New Statesman article I linked to in my original post. Ha. R2 ( bleep) 06:03, 10 March 2019 (UTC)

Hah! Yes that is a very good article. -- Green C 16:02, 10 March 2019 (UTC)

• My personal concern is not so much about POV warriors--in general we know how to deal with those--and more from editors who might be strategically disrupting specific articles or discussions in order to inhibit article development in certain undesired ways. The "strategic disruptor" wouldn't need to show a pro-Russian bias, or any bias at all. Their agenda would be hard to detect, and if they were careful, they could evade admin attention long enough to cause long-term damage. And by damage I don't necessarily mean POV content, I mean non-POV editors being pissed off or distracted and, for example, not developing an article on some topic Russia would like to suppress. R2 ( bleep) 06:18, 10 March 2019 (UTC)

And I will add, building on GreenMeansGo's comment, when I see disruptive editors seeking to add post-1932 U.S. politics sourced to Russia Today or Sputnik, I do begin to wonder. And when those editors make awkward, unsolicited references to being American when no one ever asked them about their nationality, that makes me wonder even more. R2 ( bleep) 06:24, 10 March 2019 (UTC)

• Response. R2, to answer your original question: Wikipedia:Administrators' noticeboard/IncidentArchive1002#Editor with ties to Russian government. Yes, that was one specific editor, but it contains some more information about the problem. This link contains some really good reading for any interested. The problem is not isolated to Russian state contractors. – MJL  ‐Talk‐ ^☖ 20:58, 10 March 2019 (UTC)
• This is a relevant Wall Street Journal story from last month about how Russian disinformation trolls used Wikipedia in conjunction with Twitter and Tumblr to promote fake news in 2015. They created a hoax story about a food poisoning attack in New York, then created a Wikipedia page about it ( 2015 New York poisoned turkey incident), then tweeted about it thousands of times. Fortunately the WP hoax page was spotted by WilliamJE and speedy deleted. I don't know how he spotted it. 4 sockpuppets were detected and blocked. Interestingly, the 4 socks were created during the same 2-day span (May 20-21, 2015) but had very different editing patterns before being caught. None did any POV pushing that I could find. One of them, Jenniohra ( talk · contribs · deleted contribs · logs · filter log · block user · block log), did a fair amount of editing relating to American white supremacists. R2 ( bleep) 18:49, 11 March 2019 (UTC)
  • I don't recall at all why I smelled a hoax. It could have been the article's poor sourcing and the fact no Mainstream media (MSM) was picking it up. I worked for a MSM outlet for a while. Maybe it has given me a stronger bullshit detector. Here [2]and here [3] I found WP articles, including a GA, with serious misinformation/errors in them. I call it 'bullshit with a reference' pardon my French.

Anyway, if any administrator sees this I wouldn't mind getting a copy of that deleted article in order to further jog my memory. Thanks in advance. ...William, is the complaint department really on the roof? 21:13, 11 March 2019 (UTC)

I'd like to see its edit history as well. R2 ( bleep) 17:00, 13 March 2019 (UTC)

Ahrtoodeetoo, CambridgeBayWeather restored it at User:WilliamJE/Hoax. Galobtter ( pingó mió) 05:37, 14 March 2019 (UTC)

• Wikipedia:Disinformation -- Green C 20:16, 11 March 2019 (UTC)
• I think the case with Russia is probably similar to usual practice in POV pushing: hired meatpuppets exist, but their efforts probably pale in comparison to those of bona fide believers relying on dubious sources, or just going with whatever suits their third-party POV agenda. Daß  Wölf 22:45, 13 March 2019 (UTC)

Disinformation is distinct from POV editing, vandalism and COI. -- Green C 23:51, 13 March 2019 (UTC)

• Comment on OP. I am sure it goes on all the time, as do both state-sponsored and personal ideological peddlers of bias from around the world. If you were to ask me, which country has the biggest community of nationally-biased editors I would be hard put to identify one from say the East-West, India-Pakistan, Arab-Israeli or any other major global tension. Then of course there are the endless religious, pseudo-scientific and other contentious issues. Making a special fuss at high level about any one of them might encourage them to think that they were someone special. They are not. We should deal with Russian state abuse the same way we deal with all of it - stolid and persistent detection, identification, protection, and move on to the next incident in the queue. In other words, business as usual. — Cheers, Steelpillow ( Talk) 12:59, 8 April 2019 (UTC)

See the recent Foundation blog post at Leading with Wikipedia: A brand proposal for 2030 and the ongoing discussion on Meta at m:Communications/Wikimedia brands/2030 research and planning/community review. Just dropping a few public notifications since I'm not sure this project has been otherwise notified. GMG ^talk 15:03, 27 February 2019 (UTC)

• Indifferent towards branding, but I think we need to increase the distance between us and other Wiki stuff like WikiLeaks and Wikia. I didn't know WikiLeaks wasn't a WMF project until Assange's arrest myself. John M Wolfson ( talk) 18:37, 19 April 2019 (UTC)

Looking through edit requests on pages like Talk:Logic (musician), I've noticed that several editors respond with "Not done" even when they would be able to fulfill the edit request given a little extra information. Sometimes, when a user gives a fairly precise description of what changes they want made, their edit request is rejected for want of reliable sources. The respondent doesn't try to help them find those sources. UI-wise, the red "not done" icons are intimidating as they resemble warning signs. I think this practice is BITEy and would have discouraged me from making further edit requests long ago.

I understand that the Done/Not done templates are part of canned responses provided by e.g. {{ ESp}}. (I have never used this template when responding to edit requests myself.) Can we change some of the canned responses to something like "More information needed" with a blue icon, as appropriate? Qzekrom 💬 ^they_them 13:08, 5 April 2019 (UTC)

@ Qzekrom: I think this is a good idea, even if almost none of those users will come back (most of them are there because they clicked on the button).

You could test this in the template sandbox, although I'm not totally sure if just making an edit request to implement changes would be appropriate in this case. Jc86035 ( talk) 14:08, 5 April 2019 (UTC)

@ Jc86035: I like that idea. I can edit the template itself as I am autoconfirmed, but I want to gain consensus here first. Qzekrom 💬 ^they_them 14:43, 5 April 2019 (UTC)

This is a good idea with little to no drawbacks. If anything, an edit request with "more information needed" could be left "open" for a week, and closed after that. Tools should ping users to let them know they are being asked to provide more information too. Headbomb { t · c · p · b} 14:48, 5 April 2019 (UTC)

I would actually prefer if there was a standard number of days an unfulfilled request was left open. If someone responding can't do what the requester desires, there's no harm in leaving it for someone else. 1 week does not seem unreasonable. Even if the OP has left some work for the responder to do (like dig up sources, etc.) I see no reason to close the request so early. If the responder doesn't feel they are up to the task, then let someone else try. -- Jayron 32 14:52, 5 April 2019 (UTC)

@ Headbomb: Yes! Edit requests shouldn't be limited to the binary states "answered"/"unanswered", since characterizing an edit request that has a response but is incomplete as "answered" is misleading. How about three states—open, in progress, closed (cf. GitHub issues)? Qzekrom 💬 ^they_them 15:18, 5 April 2019 (UTC)

( edit conflict) @ Jayron32 and Headbomb: I think the problem partially stems from most IPs ignoring the big box that says to ask for something specific. Under the current convention (for lack of a better word, since Wikipedia:Edit requests is not a guideline), all requests which would require any significant effort on the part of the respondent are supposed to be declined. (That IPs can't receive notifications doesn't help.) Perhaps broadening the process – e.g. so that |answered= has a third option for asking someone else to do the work – would be appropriate. Jc86035 ( talk) 15:26, 5 April 2019 (UTC)

Well, the thing is, there are two issues. First, of course, is where the requester leaves the template blank, so they don't ask for anything, or alternately where what they ask for is plainly goofing off, or not serious, or gibberish. That should be closed without a response. However, when the person making the request makes a good faith request for a change to an article, the first person to show up and see the request shouldn't instantly close it if they find fulfilling the request too onerous or not worth their time, or too hard to do, or requiring too much work. Good faith requests for an edit should be either left alone or completed, at least for a reasonable amount of time (like 1 week). Any request still open after a week can be closed with a pro forma "Sorry, there was nothing wrong with your request, it's just that no one felt like dealing with it" sort of response. It's the edit requests that get closed with some form of "Sorry, can't be bothered" within minutes. I get that some requests require some work to do; but some people like doing that work, and when people close good faith requests because they are something more complex than a spelling mistake, that presumes that the next guy to come along wouldn't want to or be able to respond to this. Too many edit requests are closed too fast. That's the issue. -- Jayron 32 16:02, 5 April 2019 (UTC)

@ Jayron32: I always understood that the process was strictly only for specific requests like "change X to Y" or "add this exact text to the article". "I can't be bothered" is currently the correct response, because the person requesting that the change be made is supposed to put in that effort (you might want to read Wikipedia:Edit requests if you haven't already). Even if some editors do put in the work to complete those requests, they aren't expected to under the actual conventions of the process.

I think this is probably at least in part because of the "anyone can edit" philosophy, which doesn't necessarily work that well in practice. Jc86035 ( talk) 16:34, 5 April 2019 (UTC)

"Is" is not a synonym for "should be". Whatever is being done, for whatever reason, has nothing to do with what should be done. -- Jayron 32 16:41, 5 April 2019 (UTC)

I mostly process 'technical' edit requests - if the edit isn't clear, I usually deactivate it and leave a note for the requester to work up the change in a sandbox first. As far as this being a "policy" discussion though, are you trying to create or alter a specific policy here @ Qzekrom:? Wikipedia:Edit requests is specifically marked as "not" a policy or guideline. — xaosflux ^Talk 14:56, 5 April 2019 (UTC)

@ Xaosflux: I think there should be a guideline for responding to edit requests stating that responses should be friendly and non-BITEy. Changing the response template would help to implement that. Qzekrom 💬 ^they_them 15:12, 5 April 2019 (UTC)

@ Qzekrom: I don't think any policy or guideline change would be necessary for modifying the template, since a change to the template to make it friendlier would be in line with Wikipedia:Please do not bite the newcomers, which is already a guideline. Jc86035 ( talk) 15:26, 5 April 2019 (UTC)

@ Xaosflux: Fair enough. Qzekrom 💬 ^they_them 15:28, 5 April 2019 (UTC)

Being friendly is a good idea, and at the least if we "deactivate" an ER without completing it, adding specific information to the requester is useful (obv not needed for when there are non-er er's like empty ones) - but for most of these it should be clear that ER's are not meant to be a "suggestion box" - they are meant to be a check against the protection policy. Ideally no articles would be protected, and noone would make bad edits - but obviously that is a pipe dream; so ER's serve as a way to allow for improvements when pages are protected. If we really want a "suggestion box" function, it should be tracked in another manner. — xaosflux ^Talk 15:30, 5 April 2019 (UTC)

If so, the 'closed' status could still be |answered=?, with a twinkle/script/whatever message be ' Additional information needed', rather than ' Not done'. Some of the required changes would need to be done at Module:Protected edit request. I don't know about the scripts involved though. Headbomb { t · c · p · b} 15:36, 5 April 2019 (UTC)

( edit conflict) @ Xaosflux: I don't think a different process altogether would be as helpful. The interface for unregistered users would be made more confusing if there were both "edit request" and "suggest an improvement" buttons on protected pages. Having a time-limited (e.g. extra parameter with value being the timestamp, template turns from big notice to smaller notice and is recategorized after seven days) and centrally tracked system for this would seem useful, although maybe this would just end up being the same as (or possibly a mildly improved version of) the article feedback tool. Jc86035 ( talk) 15:42, 5 April 2019 (UTC)

{ec}} @ Jc86035: We could perhaps modify the template {{ edit semi-protected}} to have an additional status for answered= - this would mean it stays the same for the requester, but instead of just on/off for the responders it could be on/off/(something else). The (something else) could be for more general discussions and not pollute Category:Wikipedia semi-protected edit requests with edits that are not ready-to-go? — xaosflux ^Talk 15:59, 5 April 2019 (UTC)

​@ Xaosflux: Perhaps "Wikipedia semi-protected edit requests in progress"? I think this would require some other things:

• An RFC, if the issue is potentially contentious
• Changes to AnomieBOT (since it generates lists of edit requests)
• Changes to the relevant templates, edit notices and information pages (I don't think Twinkle has any related functions, but maybe other scripts might)
• MassMessage to users who have recently marked edit requests as not done, informing them of changes to the template
• Creation of a category for older "in-progress" edit requests, if the existing categories become too large
• Creation of a parallel "process" (i.e. categories, template code and edit notices) for edit requests to unprotected pages?

At that point it might also be useful to test whether making a "suggest improvement" button more visible (i.e. before the user goes to an article's edit window) results in any useful feedback, perhaps in conjunction with WMF staff. Jc86035 ( talk) 16:23, 5 April 2019 (UTC)

Keep in mind, this isn't just done for articles. Plenty of edit requests are made at templates and modules with a "please implement this feature" by editors don't know how to code things themselves. You might argue this is a misuse of the template, but a "more information needed" closure would be much better than "No, code it for us first, you lamer!" closure Headbomb { t · c · p · b} 16:40, 5 April 2019 (UTC)

I have been thinking about this issue some also. What I would like to see actually is a more rich |answered= set of parameters (not just ? but more like "needs consensus"/"no details", which would categorize accordingly and deactivate the request) and softer language/iconography in the responses. I distinctly do not want an "in progress" indicator. That has low utility. As for technical edit requests, see also WT:TFD##RfC: Proposal to make TfD more RM-like, as a clearinghouse of template discussions. -- Izno ( talk) 16:48, 5 April 2019 (UTC)

Don't forget to update WP:EPH. That's what most user's use to answer edit requests and place Done/Not done templates. 125.63.105.110 ( talk) 15:24, 9 April 2019 (UTC)

My understanding of the purpose of edit requests is as follows. They allow knowledgeable unregistered editors to edit protected articles, doing all the work except the actual edit. I'm opposed to changing that, at least without wide community participation and consensus. i.e. a max-exposure RfC. We have other avenues for mentoring and newbie assistance. The reason there are so many "not dones" is because so many users follow our easy navigation to the edit request facility without reading even the information put in front of them during that process, let alone WP:Edit requests, and are therefore misusing the process because we make it so easy for them to do so. ― Mandruss  ☎ 16:43, 9 April 2019 (UTC)

This does this need a RFC. Any time restriction should not apply to requests that don't actually make a request and to those where the IP simply copies the entire article to the talk page. Both of these happen more often than you would think. MarnetteD| Talk 16:48, 9 April 2019 (UTC)

Then maybe we need to make it just as easy to ask for help in the "correct" way as it is to make an edit request. Phil Bridger ( talk) 17:05, 9 April 2019 (UTC)

WP:AGF is not a suicide pact. Both of my examples are all too often simply trolling. What easy or correct way to ask are you talking about. MarnetteD| Talk 18:44, 9 April 2019 (UTC)

I assumed that was a reply to my comment made by an editor who understands and follows WP:THREAD. ― Mandruss  ☎ 18:49, 9 April 2019 (UTC)

Yes, it was. Phil Bridger ( talk) 19:12, 9 April 2019 (UTC)

Yes, I agree that the edit request system is not meant for such things. All I was saying in my reply to Mandruss was that editors who need help should be able to get it easily by other means. Phil Bridger ( talk) 19:12, 9 April 2019 (UTC)

( edit conflict) To put it another way no matter how you change the edit request system you are still going to get requests with no actual request or those where all the IP does is copy the entire article to the talk page. There is no earthly reason to wait seven days to respond to - or remove - those from the talk page. MarnetteD| Talk 18:51, 9 April 2019 (UTC)

As a WP:Template editor who fairly regularly responds to editprotected requests, I support this idea, in some form or another. I detest flippant, robotic "not done" responses so much I never use them with others unless the request is toward the WP:BOLLOCKS side. I just manually explain why something has not been done yet, or should not be done unless there's a strong show of consensus for the change, or is a request that can't really be parsed and needs to be rewritten, or seems like a reasonable idea but has not been sandboxed, or .... Using a "Not done" implies some kind of "ruling" that the request cannot proceed, when it's more often "I don't understand", "I don't care", "I don't see a discussion about this", etc., and should have simply either been left open for someone else to deal with, or responded to with something more useful, like a request for more information. I've even taken some other TEs to task on their user talk page for responding with "Not done" to requests that should have been done, in cases where it was clear that that request was rejected out of lack of interest or time or understanding, not lack of the request having sufficient merits.  —  SMcCandlish ☏ ¢ 😼  01:53, 14 April 2019 (UTC)

I have no objection to any editor using a kinder, gentler template instead of {{ not done}}. Perhaps it will catch on, perhaps not, but we can't mandate it. While any editor is free to assist and pamper clueless readers to whatever degree they desire, it must remain completely optional. In my experience most of these bad edit requests don't come from people who would invest the time to become competent editors if only we were less bitey, but rather from readers who want knowledgeable editors to work for them on an ad hoc basis. That's not what edit requests are for, and it's not what I signed up for. If anyone wants to propose a WP:Editing services function with voluntary participation, I suggest doing that at WP:VPR after testing the water at WP:VPI. ― Mandruss  ☎ 12:39, 14 April 2019 (UTC)

I think we mostly just need a (template/interface) editor to make the changes to enable this from a responder point of view. Once editors have access to the other options, I doubt many will default to the harsher "not done". -- Izno ( talk) 23:03, 14 April 2019 (UTC)

I agree. This doesn't seem to be controversial in any way. Deb ( talk) 15:25, 19 April 2019 (UTC)

Course of action

@ Qzekrom, Headbomb, Jayron32, Xaosflux, Izno, Mandruss, MarnetteD, Phil Bridger, SMcCandlish, and Deb: If the template messages are actually to be changed, it should be fairly trivial since the entire family of templates (except {{ not done}} and similar) is based on {{ EP}}, which is only semi-protected. The main change in the template sandbox so far is that the blue "i" is now used for two of the options.

For proposing changes to the edit request process itself, should an RfC be drafted somewhere (perhaps Wikipedia talk:Edit requests)? I think using a two-round structure could be beneficial if there's a lot of things to propose changes to (edit notices, the actual process, related templates, categories, bots, etc.). Jc86035 ( talk) 09:55, 20 April 2019 (UTC)

@ Jc86035: will any of this get pages out of the main Category:Wikipedia edit requests queue - but possibly place them in a different queue to be followed up on - or will this still just deactivate? — xaosflux ^Talk 14:10, 20 April 2019 (UTC)

@ Xaosflux: I don't know, since nothing has happened yet. It's possible that if an RfC succeeds that that would happen (e.g. if requests responded to with "please demonstrate consensus" are to be left open for a week). Jc86035 ( talk) 14:12, 20 April 2019 (UTC)

I'm hella busy with stuff from school right now, so I'll return to this in about a week. Qzekrom 💬 ^they_them 05:06, 21 April 2019 (UTC)

I'm in no hurry, for my part, nor do I have concerns either way about category handling. I support the idea of adding options to the template to make it less bitey and "final ruling"-sounding, hopefully not coming across that way by default. I'm not sure I have really specific ideas for it yet. If people what to change what this does and how, sufficiently that we need an RfC, then let's do that. I'm not sure there's much point in trying to wordsmith some parameters now if a larger discussion is needed for bigger changes.  —  SMcCandlish ☏ ¢ 😼  00:01, 22 April 2019 (UTC)

Not strictly a policy matter, but something raised here from time to time. This proposal to lift a subset of indefinite IP blocks might be of interest to regulars of this page: Wikipedia:Village_pump_(proposals)#Proposal_about_some_indefinite_IP_blocks. Your input is welcome. -- zzuuzz ^(talk) 10:21, 23 April 2019 (UTC)

I have noticed some photos recently with only a GFDL license in the form of "GFDL-user|migration=not-eligible". I'm tagging the ones I find with a {{ Do not move to commons}} template, as commons has ceased accepting GFDL only licenses for photos since 15 October 2018 - see c:Commons:Licensing#GNU_Free_Documentation_License. Would it not make more sense for Wikipedia to follow the same policy? Ronhjones   ^(Talk) 17:06, 26 February 2019 (UTC)

Question: Per [ https://www.gnu.org/licenses/fdl-1.3-faq.html],

"Section 11 has been added to allow wikis like Wikipedia to use FDL-covered works under the terms of CC-BY-SA 3.0 if they choose to do so. They have told us that they would like to explore this option, and adding this provision gives them a clear path to do so."

"Normally, these sorts of licensing decisions can and should be handled by the copyright holder(s) of a particular work. However, because Wikipedia has many copyright holders, the project needed some alternative way to accomplish this, and we've worked with them to provide that."

The above was added in 2014, yet to my untrained eye the actual text of section 11 at [ https://www.gnu.org/copyleft/fdl.html ] doesn't appear top do what the above says it does, and instead has some November 1, 2008 and August 1, 2009 deadlines. Or maybe the legal language is confusing me. -- Guy Macon ( talk) 17:23, 9 March 2019 (UTC)

I agree but am not a lawyer either. It is a time-restricted one time opportunity that if unused is lost. ~ ToBeFree ( talk) 12:58, 12 March 2019 (UTC)

If a GFDLd file is useful on Wikipedia, then I think it is acceptable to host it here, even if commons does not accept it. So we should not change the rules to exclude them. We should discourage or deprecate new uses of the license here though. How big is the problem? Graeme Bartlett ( talk) 12:57, 5 April 2019 (UTC)

I think Graeme Bartlett's question could be an important one. Do you know how big the problem is? WhatamIdoing ( talk) 21:51, 23 April 2019 (UTC)

Meta point: I am just astonished at the number of editors who claimed in this discussion that policies are for "requirements", and that mere recommendations belong in some other page. I invite all of them to read and reflect on Wikipedia:The difference between policies, guidelines and essays, which was written out of multiple long discussions at WT:POLICY about this question. The fact is that it can be, and is, our policy to make certain recommendations, which editors should (there's that word again!) normally follow, even when it is not our policy to require that recommended thing. If the PGE page isn't clear enough, then I invite them to count the number of times that the word should (i.e., a recommendation that is not actually a requirement) appears in core policies such as WP:NOT and WP:NPOV, or even legal policies, such as WP:COPYVIO. Some of our policies also use wording such as "Editors are encouraged to..." Obviously, our policies can and do recommend certain things without requiring them, and there is no reason why this one couldn't do the same. WhatamIdoing ( talk) 03:52, 26 April 2019 (UTC)

In my experience, if we end up adding a "recommendation" to *anything* you will see people who treat it as a policy. And that is often a source of problems, such as in RfA processes. This kind of nuance doesn't work often enough. Jo-Jo Eumerus ( talk, contributions) 05:35, 26 April 2019 (UTC)

What JJE said; you may well have written Wikipedia:The difference between policies, guidelines and essays based on "multiple long discussions at WT:POLICY about this question", but you (a) wrote it eight years ago, and (b) wrote it based on the experience of the kind of person who would be commenting at WT:POLICY, not the people at the coalface, who are aware that your page doesn't actually reflect how Wikipedia's editors actually operate. The five people you're calling out by name above for having the temerity to disagree with your particular interpretation comprise four admins and a fifth longstanding editor and include a current checkuser, a current oversighter and a former arbitrator; we haven't just got off the boat and don't yet understand how Wikipedia works. As JJE (almost) says, WP:PGE can say whatever it likes, but what actually happens is that editors—and more importantly, those bodies like the admin boards, RFX voters and Arbcom who have to decide whether a given editor is acting abusively—interpret policy as "things you must do", guidelines as "things it's strongly recommended you do" and essays as "things you should consider". ‑  Iridescent 06:58, 26 April 2019 (UTC)

Oh, sure, the problem of people interpreting a recommendation as an absolute requirement has been going on for at least a decade. They don't even always stop to check whether the page they're holding forth as a requirement is actually a policy, or even a guideline. (BRD, which was reclassified as a "supplement" a little while ago, is a particular problem for that error, and is usually held forth as an always-mandatory policy by editors who think that they're entitled to revert anything, for any or no reason, and that their reversion creates a duty for someone else to start a discussion, even though BRD says that's not true.)

But I still see that NOT uses should/should not language four times for every time that must/must not is used, and I still see that it says that "editors are encouraged to" rather than "editors are required to" ...and if we want to other editors to know that policies aren't always mandatory, and that they can include information that isn't entirely mandatory, then we all have to point out when public overstatements like these have been made. WP:Nobody reads the directions, and because of that, this sort of word-of-mouth comment is what trusting editors will believe is an accurate description of "the policy". WhatamIdoing ( talk) 18:21, 26 April 2019 (UTC)

I've written User:Bri/Misapplication of blocking and would like to start discussion around excessive rangeblocks especially of educational networks and other resources available to a wide swath of users. Bottom line up front: Is there a policy or even guidance on how admins are to weigh the impact on the project of blocks affecting large numbers of contributors? Under the current system blocks appear to be ad-hoc, sometimes punitive, applied for arbitrary time periods, and under the radar unless one is skilled in sussing out edit summaries and technical logs. In addition long-lived hard blocks make it impossible for well-intentioned users to even request an account. This is contrary to policy. ☆ Bri ( talk) 18:21, 24 February 2019 (UTC)

Bri, I'm not certain "no apparent reason" is accurate when looking at that database report. For an example, in the report, 159.65.0.0/16 shows no reason given, but there is clearly a reason - "{{colocationwebhost}}: <!-- DigitalOcean -->". There are many other instances of this - it looks like there may be an issue with that database report. This quarry should have the missing data filled in. SQL ^{Query me!} 21:57, 24 February 2019 (UTC)

I have raised the issue (and provided a fix) regarding the errors in the database report at Wikipedia_talk:Database_reports/Range_blocks/Configuration. As to some very specific examples you've listed - we should probably notify those editors: Materialscientist (regarding [4]), and Gilliam (regarding [5]). As far as indef'ed ranges - specifically those set by Ryulong, those are webhosts. They shouldn't be editing - but I am of the opinion that they probably shouldn't be blocked indef. IPs change hands - we should be re-checking those periodically. SQL ^{Query me!} 22:14, 24 February 2019 (UTC)

FYI, SQL, last I heard, Materialscientist has notifications disabled. — DoRD ( talk)​ 11:16, 26 February 2019 (UTC)

DoRD, Thanks, left a TP message. SQL ^{Query me!} 04:35, 27 February 2019 (UTC)

• Is there any evidence of a problem? Is there an example of an IP block that was removed and where some of the IPs went on to do good work? That is, work that outweighed any vandalism from the range? Total freedom would be wonderful but in reality it is not satisfactory to rely on someone else to do the cleanup from open proxies and vandalism-only IPs. Such cleanup is soul destroying and burns out the few good editors who do it. They need support from the community, not hurdles. Johnuniq ( talk) 22:33, 24 February 2019 (UTC)

I prepared a long answer to this that I think I'll save for later if someone else wants to talk about what excessive means. WP:IPBLENGTH already answers this is a plain-English way. Instead here's a response to your question about vandalism-only IPs. Basically I challenge that there is such a thing as a vandalism-only educational range at all. I don't buy the argument that all these libraries and school districts on the blocklist are full of nothing but vandals. What is the human capital we're turning away from the project by blocking them? SQL linked above to two three year blocks of two states' education networks, account creation blocked! There most definitely is a cost imposed on us by blocks. The reckoning of the cost should be public and demonstrable, not just some hand-wavey clairvoyance about negativity of future contributions from a range. It seems to come close to an elitist and hostile attitude to a whole population of people among whom are some bad actors. ☆ Bri ( talk) 04:03, 25 February 2019 (UTC)

There is no proof that keeping a long block of an IP range is necessary, but you have just demonstrated that there is no evidence that unblocking is ever helpful. Johnuniq ( talk) 22:53, 25 February 2019 (UTC)

I have several times asked about this while I was on arb com. The general line of response from arbs and other functionaries was the the need to block vandals was so important that the minor difficulty of asking people to make accounts outside the institution was trivial. I disagreed rather completely, but the reception to my questions was so negative, that I did not pursue it further. It was my impression that most of my colleagues on the committee had no conception and nor realization at all that the survival of wikipedia requires the continual recruitment of new editors, and anything that has the effect of discouraging this harms the encyclopedia. They did not realize the difficulty for many people in the world of editing from anywhere except their schools and libraries. They did not realize that we need to take advantage of every opportunity someone has to contribute, because if they run into difficulties initially, very few will keep trying. I attribute this total misunderstanding of priorities to be the result of the focus of almost everybody who would want to be a functionary on dealing with disruption, more than on editing. They see the problems from the small part of the encyclopedia where they work, but not those from the main function, content building.

I make the following proposal as first step, what I consider a very modest proposal: a range block for more than 4 months, that involves a school or library requires clear consensus . I consider this minimal, but it would at least require periodic discussion. Those who would be involved in such discussions are mainly involved with vandalism fighting, not editing, and 4 months (the length of a school term) is a very long time--but I can see a one person persisting that longer, but think it would be very rare for it to be longer. We have edit filters to deal with such problems. Assuming that the WP does not bring itself into total disrepute after a year of a policy like this, I'll suggest changing it to 1 month. DGG ( talk ) 19:53, 25 February 2019 (UTC)

Those are good points but keeping editors is also necessary! A new user can be enthusiastic for a month then run into persistent silliness from a range of IPs. It does not help to tell a new user that there is no problem, all they have to do is AGF and take an hour to explain procedures to each new IP and be sure they don't edit war. Anyone, new or experienced, can be burnt out by unrelenting silliness. Johnuniq ( talk) 22:53, 25 February 2019 (UTC)

Those aren't mutually exclusive goals. From a purely technical perspective, there is no good reason to indef IPs, because these may be re-assigned by ISPs without warning and without notice. Blocks/Unblocks can and should be carried out by adminbot; for example, ProcseeBot tirelessly identifies and blocks open proxies. - FASTILY 02:48, 27 February 2019 (UTC)

Fastily, I've been considering doing this for a while - an adminbot that double-checks aws/azure/google compute/other ranges and auto-blocks / unblocks them. SQL ^{Query me!} 04:32, 27 February 2019 (UTC)

User:Johnuniq, have you heard about any of the research into The Great Editor Decline™? Visible vandalism seems to attract and retain editors. As we created vandal-fighting bots, the perceived need for editors declined, and so did the number of active editors. There's a pretty significant generational divide between editors like us (≥10 years) and newer editors (≤5 years), especially in terms of how we got started. One story (i.e., it's probably true but it's not the sole Truth™) is that reverting obvious vandalism is a fun and easy entry point for new editors, and we have taken that gentle onboarding ramp away from them, and handed it over to the bots. This (and all the other actions like it) shrinks our pipeline.

I'd like to echo User:DGG's concern about our future, but I'm going to be a bit blunter about it. In the last couple of years, I've written two WP:OBITs for editors whose work I loved and respected. I expect my name to be there someday – and yours, too. It's easy to say "I'm just upholding quality and removing annoyances by not letting any of those kids in here", but the English Wikipedia has a deep, existential need to bring in younger editors. Our core community is aging at something uncomfortably close to the rate of one year per year. We are not going to live forever. We are going to die. If having ClueBot revert a couple of extra rounds of poop vandalism is what it takes to teach the people who will still be alive what that Edit button is there for, and maybe even let them know that when they're not trying to show off in front of their friends, they could contribute the name of their favorite singer's latest album or something (or that, several years later, when they're trying to find out why the baby seems sick, that they don't put too much trust in an article that anyone can edit), then it really might be worth the cost. WhatamIdoing ( talk) 21:48, 23 April 2019 (UTC)

What if we block school IPs, but allow account creation from school emails only and blacklist blocked emails. Advantages:

• Limited ban evasion—once someone's created an account with their email address, if they get blocked they're stuck.
• Deterrence: if we (threaten to) send emails of vandals to school administration, that's likely to deter vandals.

Main disadvantage I see is the complexity implementing the feature, as well as maintaining the whitelisted email domains. Also, doesn't help with libraries. Gaelan 💬 ✏️ 05:25, 26 February 2019 (UTC)

• I used to be meh about this, but schoolteacher friends and acquaintances have told me in no uncertain terms that vandalism originating from school accounts is completely unacceptable and they should be blocked. Hawkeye7 (discuss) 10:12, 26 February 2019 (UTC)

• I work in education, and many schools are quite happy that their students can't edit - as long as they can read articles - as they don't like an IP page with their school name emblazoned on it followed by a whole list of vandalism warnings, and I can quite understand why. Black Kite (talk) 10:20, 26 February 2019 (UTC)

• Schools and libraries only get blocked for time periods of months if they have persistently been outputting nothing but vandalism for a considerable time. There will have been multiple blocks for a much shorter time before that happens. There are many schools out there where the internet access is not supervised or controlled who have had long blocks for years. It is almost guaranteed that soon after the block expires vandalism will start again, but we always give them a chance and refrain from blocking until that actually happens. There's no other site out there that would put up with that. Anywhere else, once you're blocked, you stay blocked. Spinning Spark 00:44, 5 March 2019 (UTC)
  • Anywhere else, it's usually still "you" that's blocked and unable to even create an account, and not thousands of kids and sometimes teachers who are blocked because a former student vandalized pages several years ago. (I'm also doubtful about this whole idea that unsupervised teenagers naturally vandalize articles unless the school or library is watching them all the time. When you were a teenager, would you have vandalized articles just because nobody was looking over your shoulder? I wouldn't have, and I think that's true for most of people.) WhatamIdoing ( talk) 21:23, 23 April 2019 (UTC)
• I've worked all my life with school teachers and administrators and information technology people. The best of them are eager to find way to experiment to provide better results, but others are more concerned with avoiding anything unpleasant, and are especially fearful of unregulated projects. To them, WP is just the sort of unregulated project whose consequences they cannot control, and where they are much more likely to see the possibilities for harm than the potential benefits. We should not let the fearful over-influence us. Here at WP we accept the possibilities of vandalism in order to provide anonymity. Young people in schools and libraries are no different than they are elsewhere. They do vandalize sometimes out. of play, or to see what they can manage to get away with, or to display their skills, or to show their independence of authorities. I doubt there is anyone here, young or old, who has not themselves at least once in a while participated in some of this. The only way to prevent computer systems (or any other medium of expression) from being abused, is to regulate them strictly and keep detailed surveillance over all the activity. This sort of petty tyranny inhibits learning and creativity and free expression--we all know this, or we wouldn't be here ourselves.

We have to protect the encyclopedia, and we have ways of doing this. They've developed greatly over the last 15 years, and we are normally one of the fastest reacting systems in the world--not because of our technical sophistication, but our reliance on large numbers of volunteers who care and watch, and a sufficient number of volunteers administrators, who care and watch and take rapid action. The only way of reducing this to zero, is to filter everything through multiple layers of approval and bureaucracy, producing the media systems of past generations that set immense barriers to active participation, screening out all but the exceptionally persistent. WP was founded and designed not to do this--to accept the harm from uncontrolled editing in order to get the benefits of uncontrolled editing. Our entire basic principle is that anyone can edit, which recognizes as inevitable that some will do so uncooperatively and even destructively. We knew from the start this would take work to discourage and remove the harmful material--though we may not have fully realized how much work it would prove to be. Look around right here at those who are commenting--and recognize the work in various aspects of this that we all are doing.

One of the key aspects of media freedom is the opportunity it gives the individuals. One of the great things about our project is the potential it provides for individual growth. We need to protect and encourage every individual person who wants to join us. We need to both forgive their errors, which is why we try to avoid indefinite blocks except for the incorrigible, and we need to prevent individual fro being harmed by the bad deed of others, which is why we should avoid range blocks as far as we possibly can, and certainly never use them for long periods. This is already policy. But we administrators who have the necessary power to prevent harm, have the same tendency of people enforcing regulations generally--to gradually let the boundaries of their power expand. I make no claim to be free from it myself, and in the field I work, I need to watch that I am not so eager to remove advertisements that I remove well-intentioned but clumsy articles. It would be just the same if I were primarily blocking vandalism. We need to watch ourselves, and it helps to have rules that encourage us to stay within our propeer limits. DGG ( talk ) 00:42, 24 April 2019 (UTC)

I am an advocate for registering. It does not mean that I think it should be an only option but simply there are advantages to registering. In the scheme of life requiring registration would make things simpler, and likely put a lot of editors doing more constructive things, but that is not "the way of Wikipedia". Since that is a fact then anything that potentially hampers this encyclopedia should be closely examined. We cannot be an encyclopedia "that anyone can edit" when there are things working against that. I am not going to go into any long-winded semantics on this but there is an issue that needs resolving. "If" an admin gives a broad range block it should be for a valid reason, never without an explanation, only short-term, and subject to revisit and re-examination. If an admin does not want, or can't, take the time to have further involvement then maybe someone else should handle it. If there is not an "agreement" in place between admins then it should be understood that lifting a block should be a proactive move to protect the "rights" of unregistered editors after a certain time.

I have not gotten into IP range blocks but I can see that an attempt to stop clear disruptions from a certain area would be important. We CANNOT arbitrarily give out corporal punishment in the guise of seeking to "do good". The fact is that a long-term IP range block creates a stumbling block. Ultimately the potential loss of one good editor would be counter-intuitive.

I like the reasoning of User:DGG and User:WhatamIdoing. We want "freedom" so advocate "ignoring the rules" when it improves Wikipedia. Even this "rule" is hamstrung with exceptions (subjectivity and consensus) but they are necessary. Without some "rules there will be chaos and most know this. An admin is an editor the community has entrusted to handle certain things. I have seen some that I consider not so objective, and that clearly has made questionable calls, but if this is more than just a mistake, more ongoing, we can recall or just "make a change" the next time. Making mistakes is a fact of life and not abuse. That is the politics of Wikipedia. I am not above or afraid to take issue if I see what I think is an abusive admin. I also think most admins (that I have seen) generally do a good job but the position does give "power" and this can be abused. The fact is a block with good intentions becomes a liability if left active for no clear reason.

Wikipedia can generally be "fast-acting" but things can fly under the radar. I don't know about the "block school IPs" as that is a different discussion than broad-range IP blocks to prevent vandalism. We have programs to encourage school activity so I would think this a negative move. I have not looked to see if there is a monitored list but if not there should be. Any range blocks (short or long) should not given out without some follow-up. The battle to prevent vandalism should never be used to even possibly hamper new editor involvement if we are going to claim to be a "free encyclopedia that anyone can edit". Let's do every thing in our power to encourage new editors so we don't become stagnate. Otr500 ( talk) 13:21, 28 April 2019 (UTC)

Hello - I'd like to hear some thoughts on an issue I've noticed with the references at Septuagint - an article rated vital level 4 in Arts, and top or high importance for 5 different Wikiprojects. The issue is that a large part of the article relies on citations from a single source, and (poorly formatted in that article) this source appears to be an article that appeared in an encyclopedia in 1906.

It concerns me because I have seen other articles using these statements - apparently cross-referencing from the WP article, and yet I can't really see the justification of such heavy reliance on a single source, in particular one from so long ago in another encyclopedia. I know we value secondary sources, but this is a bit ridiculous isn't it?

Any thoughts? JMWt ( talk) 15:15, 24 February 2019 (UTC)

Avoiding any specifics about this article, which belong in the discussion that you started on the talk page, I would think that there must be better sources than one published in 1906 in any field, including bible studies, that has moved on significantly since that time. We should reflect more recent scholarship about such subjects. Phil Bridger ( talk) 15:53, 24 February 2019 (UTC)

I've always been opposed to citing from general encyclopedias, as opposed to a specialist encyclopedia written & edited by experts. Such general encyclopedias -- such as Encyclopaedia Britannica -- are often written not by experts, but anonymous freelance writers, are reviewed only once for errors, & more often with an eye to reduce their length, & far too often contain errors due either to sloppiness, or because it repeats "stuff everyone knows is true". (Sometimes these articles are reprinted with no changes from editions written as long as a century before.) The exception in these cases are signed articles, which are written by recognized experts in the field, yet even these may not be examples of that expert's best work. -- llywrch ( talk) 20:13, 24 April 2019 (UTC)

• the 19th and 120th century encyclopedias are of value only in showing the staate of knowledge and the manner of thought at th time. They are not reliable sources for anything now. There has been much work on the topic mentioned above since then, many books and scholarly articles, and possibly even a journal devoted to it. These are the appropriate secondary sources, and the current religious specialized treatises and encyclopedias are usable tertiary sources. The difficulty is that the proper sources are not free online, but only the obsolete ones. That does not mean our articles are to be based on the obsolete information that is easy to get for free; it rather means that only the people who can find the appropriate information can work properly on the articles. The way to deal with this is to obtain more sources for those working here, and encouraging more people who can use the current sources to work here. The old Jewish Encyclopedia and the Catholic Encyclopedia were not written by anonymous hacks, and neither was the 11th ed of the Brittanica, so they are RS for what was the general anglo-american jewish , catholic, and English establishment views at that time, as are the similar encyclopedias of other languages. ( I even own personally a printed set of the 11th Brittanica and the Catholic E. and read them for my own knowledge & interests, but I would not use them as sources for a WP article except in special cases, to show the earlier development of a subject, or a fact of 1907 (etc.) geography. For example, EB is a RS for the state of UK railroads at the time, but not for the current understanding of the historical development of UK railroads or their actual role in the world even then--we may now know more of their economic and social effects of he period than people did at the time/ ).

It's time we systematically replaced the information based or quoted from these sources. Using them was a naïve short-cut even at the beginnings of WP. DGG ( talk ) 23:12, 28 April 2019 (UTC)

Editors willing to participate should go to the RfC page. With thanks. -- qedk ( t 桜 c) 13:57, 29 April 2019 (UTC)

Eww. Four RfCs on one page? I want to leave a snarky comment, and it's not that I don't have one, but I just have too many to choose from and I'm so dreadfully indecisive. GMG ^talk 14:18, 29 April 2019 (UTC)

I'm considering translating /info/en/?search=Bradycardia into Dutch. There is already a page there, https://nl.wikipedia.org/wiki/Bradycardie but not only is it very brief and lacking references, it also has contradicting information.

Is it appropriate for someone like me that doesn't have primary knowledge on the subject to translate the English page into Dutch, overriding the content on the Dutch page and reusing the English language references?

Aethalides ( talk) —Preceding undated comment added 12:06, 27 February 2019 (UTC)

I think it would be better to ask that question on the Dutch Wikipedia, because it is their article that you would be changing, and they may have different policies and guidelines from ours. Phil Bridger ( talk) 12:11, 27 February 2019 (UTC)

I believe that a couple of Dutch Wikipedians were irritated a few years ago when their (brief and under-cited) article was overwritten completely, but that might not have been representative.

User:Jfdwolff, what do you think? WhatamIdoing ( talk) 21:57, 23 April 2019 (UTC)

In this particular instance I think the overwrite is entirely justified. The Dutch article is an unreferenced stub. As for the general principle, I think anything other than a stub should not be replaced unless some form of discussion has been had on the talk page. JFW |  T@lk 22:30, 29 April 2019 (UTC)

Everybody, opinions are needed at Wikipedia talk:Canvassing#A rule clarification that is (apparently) needed. There is also a poll subsection as part of the discussion. The discussion concerns whether or not pinging should be added to the guideline and how it should be added to the guideline if it's to be added. Flyer22 Reborn ( talk) 06:07, 3 May 2019 (UTC)

Since User:Iridescent has proposed, in response to my ArbCom case request, that ArbCom adopt language requiring WikiProject sponsorship for portals, I am submitting their draft language to the community for consideration. I am including the version submitted by Iridescent as Version 1, and am requesting that the community consider it, and any alternate versions. On each version, please provide your opinions and brief comments on the Survey, and extended discussion is permitted in the Threaded Discussion.

If two or more versions are approved, the closers may determine that one of the versions is encompassed in another as a subset, or may relist this RFC to require a choice between versions. Robert McClenon ( talk) 21:19, 30 March 2019 (UTC)

Version 1 (WikiProjects and portals)

Draft Language (WikiProjects and portals version 1)

All editors intending to create a portal must consult with the relevant WikiProject for that topic as to whether they feel a portal would be useful. All existing portals should be raised at the talk page of the relevant WikiProject and deleted if there is a consensus at that project that the portal is not useful. If the topic has no relevant WikiProject, it should be deleted.

Survey (WikiProjects and portals version 1)

• Neutral as scribe for this version, because I would prefer to let existing portals be discussed on their merits at MFD. Robert McClenon ( talk) 21:19, 30 March 2019 (UTC)
• Support this version, now that X3 has been sent off by a supervote. Robert McClenon ( talk) 16:42, 7 April 2019 (UTC)

• @ Robert McClenon: There are ≈4000 existing portals, and that's before we get on to the equal if not greater number of "outline of…" pseudo-portals, most of which were created by the same editor who bulk-created the portals. Even if one were to assume that 50% of the portals and all of the outlines are self-evidently non-problematic—a huge assumption—then assuming we restricted MFD nominations to 50 nominations per week to avoid flooding the process completely it would take two years just to get through 2000 portals. Per my comments at the AN thread, this is certainly not an ideal solution and nobody on either side of the debate will like it very much, but Wikipedia's usual processes aren't really capable of handling this kind of scale without breaking (MFD typically only handles a total of 100-ish nominations per month, and most of those are usually uncontroversial deletions of drafts). ‑  Iridescent 22:49, 30 March 2019 (UTC)

Indeed when one person created 109 portals in a single day how can we review them all at MfD? This puts the onus on the person who created all this crap to find support after they ignored WP:MEATBOT and WP:POG

Discussion (WikiProjects and portals version 1)

Threaded Discussion (WikiProjects and portals version 1)

Version 2 (WikiProjects and portals)

Draft Language ((WikiProjects and portals version 2)

All editors intending to create a portal must consult with a WikiProject for that topic as to whether they feel a portal would be useful. No new portal may be created without the sponsorship of a WikiProject.

Sponsorship of existing portals is desirable but not required, and the lack of a sponsoring project will be considered as a factor in a deletion discussion at MFD.

Survey ((WikiProjects and portals version 2)

Threaded Discussion (WikiProjects and portals version 2)

I see one problem with either of these. In there heyday Wikiprojects were numerous and well stocked with participants. Now there are numerous ones that have no active editors. What happens when when a project is asked and no response is forthcoming? MarnetteD| Talk 21:29, 30 March 2019 (UTC)

That's not a bug. That's a feature. If a WikiProject is asked to support a new portal and no one answers, it has no support. If a WikiProject is asked to support an existing portal and no one answers, it is an orphaned portal, and there can be a deletion discussion. Robert McClenon ( talk) 21:50, 30 March 2019 (UTC)

I had not seen the AN thread RM We can move this post there if that would be better. MarnetteD| Talk 21:32, 30 March 2019 (UTC)

My preference is to leave it here. Robert McClenon ( talk) 21:50, 30 March 2019 (UTC)

Sounds good. Thanks. MarnetteD| Talk 22:03, 30 March 2019 (UTC)

What about a situation in which no one previously affiliated with the relevant wiki project supports the portal, or the wikiproject is moribund so there’s really no one there to ask, but then a newcomer to the wikiproject says “I’m signing up for the wikiproject to support the portal”? Newyorkbrad ( talk) 23:14, 30 March 2019 (UTC)

I guess if they follow up with it it'd be a feature and not a bug per User:Robert McClenon's response. - John M Wolfson ( talk) 23:23, 30 March 2019 (UTC)

• Comment – There is an essentially duplicate discussion about this topic presently occurring concurrently at Wikipedia:Administrators' noticeboard § Proposal 7: Toss it to the WikiProjects. North America ¹⁰⁰⁰ 00:34, 31 March 2019 (UTC)

General discussion (RFC: Portals and Project Sponsorship)

The idea of having portals sponsored by WikiProjects was proposed in February by UnitedStatesian at the portal guidelines talk page. The issue is not one of ownership; it's integrating support for portals with the same interested editors who maintain the navigation boxes and articles for the topic area. Particularly if the helper templates are used, editors need to take portals into account when modifying any associated navigation boxes and articles. But in general, portals can only be successful in the long term if they are supported in the same way as the rest of the related content. Accordingly, decisions on their creation and maintenance should be made by those editors, either under the aegis of associated WikiProjects, or through other methods of identifying editors active in the area. isaacl ( talk) 16:14, 31 March 2019 (UTC)

Also, it looks the ArbCom case might not go anywhere. Even without such case I still think this, or a variation of this, is a good idea. - John M Wolfson ( talk) 17:04, 31 March 2019 (UTC)

The issue is not one of ownership The effect is the same: WikiProjects would WP:OWN their portals the way these proposals are crafted, rather than stewarding them. (See also WP:CONLEVEL.) -- Izno ( talk) 18:50, 31 March 2019 (UTC)

Personally, I am happy with other means of identifying interested editors, and since there is no criteria to be part of a WikiProject, any interested editor can be automatically deemed a part of the associated WikiProjects. The point is that just as it makes sense for a navigation box to be maintained by someone interested in a topic area, and for discussion about whether or not a navigation box should exist to take place amongst interested editors, creating, updating, and maintaining portals should be integrated in the same way with the mass of tasks done by those working on related content. Yes, in theory, the larger community could decide that a given navigation box should exist, but that doesn't really work if no one wants to create and maintain it. isaacl ( talk) 19:37, 31 March 2019 (UTC)

Right, I don't think I would object to "you should request feedback from editors of interest, which may include leaving a note at a WikiProject talk page", but the musts in the above clearly don't have that in mind. :) -- Izno ( talk) 16:09, 1 April 2019 (UTC)

Version 3(?): Portals for creation and (maybe, though irrelevant here) X3

Perhaps something of the following could be in order:

• X3 is adopted, so MfD would not have such a high workload (See separate discussion at WP:X3)
• For future portals, a process analogous to WP:AfC, Portals for creation, is adopted as a requisite (not merely a recommendation, unlike AfC IIRC) for all future portals (not just the first portals of a given user, unlike AfC) Given that portals are not content but navigational tools and are non-mainspace, concerns about stiflement and chilling do not apply here IMO. To address concerns about stewardship PfC would be open to the global community.

The main concern I have with this is that opening it to the global community might lead to each PfC to become simply a fight between anti-portalers and pro-portalers between the merits of portals as a whole (i.e., it might devolve into simply WP:ENDPORTALS2) and not of the merits of the specific portal at hand. This doesn't address pre-TTH portals, but I believe those are of such a number to be addressable individually. Hopes this works as a compromise between the parties involved. - John M Wolfson ( talk) 19:54, 31 March 2019 (UTC)

• Oppose X3 for all the reasons explained repeatedly and in detail in the proposal at WP:AN (which should have been at WT:CSD). I strongly recommend you remove it from this proposal to keep all discussion in one place. Thryduulf ( talk) 08:50, 1 April 2019 (UTC)
  • Fair enough, I have removed X3 from the discussion here. - John M Wolfson ( talk) 13:25, 1 April 2019 (UTC)
• Cautiously support portals for creation. It would need enforceable guidelines to ensure that all comments addressed the individual portal being proposed with (parts of) comments that address only portals in general (positive or negative) being struck or removed. Portals created outside of PfC should not be automatically deleted, but it would be a factor that can be considered in any deletion discussion. Thryduulf ( talk) 08:50, 1 April 2019 (UTC)
  • Portals created outside of PfC should not be automatically deleted, but it would be a factor that can be considered in any deletion discussion. The problem with that is that it doesn't give PfC enough teeth, IMO, and makes it yet another layer of bureaucracy that doesn't fully prevent a TTH repeat. Maybe we can make any extra-PfC portal automatically PROD'd, but then the creator of the portal can just remove such tag with impunity. - John M Wolfson ( talk) 13:25, 1 April 2019 (UTC)
    • The issue I see is with someone creating a new portal in good faith without realising that they should have gone through PfC, deleting that would not benefit the encyclopaedia. Automatically prodding them is a possibility, but that would require a consensus in favour of prod for portals (currently proposed somewhere, I think at WP:AN, with no clear consensus either way last I remember the proposal for this at Wikipedia:Administrators' noticeboard#Proposal 6: Proposed Deletion for portals was withdrawn by user:Pythoncoder after it received a generally unfavourable response). Thryduulf ( talk) 15:59, 1 April 2019 (UTC)
      • That's fair enough, perhaps a message on that user's talk page directing them to PfC. Although we're all rather shaken by the recent shenanigans with Portals I think WP:AGF still applies and I'm not sure our consensus reached by WP:ENDPORTALS has changed in light of the recent events. - John M Wolfson ( talk) 18:43, 1 April 2019 (UTC)
• Comment. Portals for Creation is something I have thought about proposing myself -- as long (as the nominator mentions) as it did not become yet another battleground between those vehemently opposed to the concept of a portal & their opposite numbers. It would need guidelines and probably a moderation team, to make sure the guidelines were followed. (Agree with Thryduulf that this discussion should not bundle in 'X3', which is an entirely different topic.) Espresso Addict ( talk) 09:16, 1 April 2019 (UTC)
• Comment If this proposal is approved, PfC is the obvious acronym but WP:PFC already exists as a redirect to the essay Wikipedia:Procedurally flawed consensus. Retargetting that would need to be discussed at RFD, but unless and until Portals for Creation actually becomes a thing it will never get consensus. Thryduulf ( talk) 15:59, 1 April 2019 (UTC)

  That's a bureaucracy thing. -- Izno ( talk) 16:09, 1 April 2019 (UTC)

  That's a rather short essay that doesn't appear to be anything close to policy, so we could just redirect it to Portals for Creation and put a hatnote on the Portals for Creation page directing the reader to Procedurally-flawed consensus. - John M Wolfson ( talk) 18:43, 1 April 2019 (UTC)

  Retargetting established shortcut redirects should only ever be done with extreme caution (i.e. after fully examining the history, links, views, etc.) In this case it's probably ok to retarget as the redirect doesn't seem to have garnered much use, but it's always best to make sure. Thryduulf ( talk) 20:33, 1 April 2019 (UTC)

  Perhaps. I can look through the What links here for that redirect if this gains traction. - John M Wolfson ( talk) 21:34, 1 April 2019 (UTC)

  @ Thryduulf: It turns out only five (!) pages link to the WP:PFC redirect, two of which are this discussion (for both the policy Village Pump and the full Village Pump), another is the full WP:Procedurally-flawed consensus page, and the other two are shortcut tables. As such, I think it's hardly an established redirect, and per WP:SNOW I doubt we need to waste everyone's time with a full RfC if Portals for Creation gets off the ground. - John M Wolfson ( talk) 16:02, 2 April 2019 (UTC)

  It would (I hope!) be an RfD rather than an RfC, but yeah it does seem that retargetting this redirect won't cause issues. Thryduulf ( talk) 17:00, 2 April 2019 (UTC)

• Hesitant support from me here. This would function similarly to WP:WikiProject Council/Proposals I guess? This process should not be mandatory. -- Izno ( talk) 16:09, 1 April 2019 (UTC)
• Strong Support - Discussion and consensus both going in and going out is what we need. The current mess with thousands of portals would never have happened if there had to be discussion before creating portals. Robert McClenon ( talk) 05:31, 2 April 2019 (UTC)
• Support - This is the best option in terms of how it would work out if it went well, and I think we are capable of putting together policies that should filter out nonconstructive participation in PfCs. — Charles Stewart (talk) 14:05, 2 April 2019 (UTC)
• Comment - I created a somewhat more detailed mock-up of what PfCs would be here. If you think it'd be better at a different location feel free to move it. - John M Wolfson ( talk) 17:19, 2 April 2019 (UTC)
• Oppose yet another dramaboard which would likely be populated by extremists on both sides slinging mud at each other indefinitely, with any ordinary editor interested in creating a portal getting caught in the crossfire. What we need is objective notability criteria and minimum content criteria, so there can be a reasonably objective way to determine whether a portal is justified. A set of criteria for staying in date would also help with apparently abandoned portals. Easy to use tools will help as long as they are reasonably bug-free. All the proposals here are just passing the buck and do not address the actual problem, which is insufficiently clear criteria to create or delete. · · · Peter Southwood ^(talk): 08:52, 3 April 2019 (UTC)
• Oppose – Ultimately just more red tape, unnecessary bureaucracy and layers. I agree with the notions set forth by Peter Southwood above. The best way to move forward is to focus portal matters upon the actual portal criteria at Wikipedia:Portal/Guidelines, which would be best discussed in one area, at Wikipedia talk:Portal/Guidelines, rather than having multiple discussions in multiple venues constantly occurring simultaneously. North America ¹⁰⁰⁰ 23:49, 5 April 2019 (UTC)
• Oppose Editors of good reputation have made comments that have convinced me that this is not an effective solution. As an editor who is not particularly active and part time I have found wiki become more bureaucratic. We need more editors to produce content. There are many people I know who have valuable content that they and their students could produce. We need to make that task both easier and attractive. Reason for opposing - not workable. Suggest that portals started that are dormant without action for a set time be cued for auto - deletion if the portal is not completed with its content page. Isthisuseful ( talk) 05:39, 7 April 2019 (UTC)
• Cautious support PfC. This will provide a check on the appropriateness of new portals, without resorting to drastic solutions. This proposal leaves unresolved portal creation criteria, and the question of what to do with the mess of existing portals, but it stops the problem from getting worse effectively. Tazerdadog ( talk) 17:56, 9 April 2019 (UTC)
• Theoretical support: It would have to be non-binding, non-mandatory, just like Wikipedia:WikiProject Stub sorting/Proposals and Wikipedia:WikiProject_Council/Proposals. "Failing" to use either of those processes is not a deletion rationale. Any undiscussed new stub type or wikiproject that someone wants to delete is considered on its own merits (at WP:CfD or at WP:MFD, respectively). However, both processes weed out good-faith but poorly thought-out stub and project ideas (and shunt them into something more productive, like a stub type/cat. that already exists and can encompass the topic, or a how to start a taskforce/workgroup of an extant project). A process for portals could do similar. However, we sure as hell do not need another bureaucracy, another layer of rule-thumping and "I'd rather play police than work on the encyclopedia" crap. WP is overrun with too many control freaks already.  —  SMcCandlish ☏ ¢ 😼  01:04, 14 April 2019 (UTC)
• Theoretical support similar to SMcCandlish above. The stub sorting proposal process works well, and a similar system for portals would significantly improve their overall quality.  —  Mr. Guye ( talk) ( contribs)  13:56, 1 May 2019 (UTC)

I am not talking about censoring that, but can we make a system that we will make the image folded (i forgot the accurate word) and if anyone put the cursor on the image, it will show a message, that the image has graphic nudity, and also a show option will be given with the message. If any user want to see the picture, he or she will click the show option. If he or she doesn't, he or she will not click the show option. I think the idea is more democratic than the present policy. Waiting for all other's responses. Love for Wikipedia. Sharif Uddin ( talk) 02:58, 10 March 2019 (UTC)

Nope. For many, many reasons. First, WP:NOTCENSORED. Second, people would now need to flag 'nudity' in images. Second, this is an extremely slippery slope. First it's nudity. Next it's bad words. Then it's ideas. Headbomb { t · c · p · b} 03:08, 10 March 2019 (UTC)

@ Sharif Uddin: maybe try User:Anomie/hide-images -- DannyS712 ( talk) 03:10, 10 March 2019 (UTC)

Historical reference - something similar to this was proposed some time ago. I was on the "managing the vote" side of things so wasn't paying too much attention to what happened with the results, but it's pretty clear that the broad global community was pretty evenly split on the "worth investing in" vs. "not worth a nickel" spectrum. That was pretty much the last we ever heard of the idea. The biggest challenge is not so much the intentionally placed graphic images (whether of nudity or other potentially "shocking" material); if one opens an article about human reproduction or war atrocities or certain medical conditions or artists whose work includes nudes, it's likely that at least one graphic or NSFW image will be present. No, the bigger issue is when these kinds of images turn up unexpectedly on pages or articles where they don't really seem to fit. There's no really effective way at this time to immediately identify and 'tag' an image with graphic content at the time it's uploaded. Risker ( talk) 03:20, 10 March 2019 (UTC)

It is very embarrassing for me to edit on wikipidea in front of everyone of the office in a desktop computer. Yesterday, in front of one of my coligue I openes an article, and I didn,t khnow that the photo contain nudity, when I opened the article it came out with a photo recently taken by camera including a complete uncovered people on the top of the article, and from then a negetive idea about me has been silently born on his mind. My family already started thinking me negatively because they I edit in wikipedia, and it is full of open graphic nudity. I think it is similar to a torture on the editors to make them seeing this photos who do not want to see this, and making them deprived of sharing the experience of wikipedia with othrs. I will not try to attack your ethics, you should not attack mine, but we all have the equal rights to get a neutral preview of wikipedia to enjoy the informations, becaousse wikipedia is of all. Sharif Uddin ( talk) 12:07, 10 March 2019 (UTC)

I think a vote such like this should be again started meta:Image filter referendum/en. Sharif Uddin ( talk) 12:58, 10 March 2019 (UTC)

Sharif Uddin, if the article included a nude photo that was a surprise, it's possible that article shouldn't include a nude photo. If you let us know which article it was, maybe we can offer other opinions. valereee ( talk) valereee ( talk) 13:07, 10 March 2019 (UTC)

It was exhibitionism, and as a muslim, it is also my duty to maintain my haya and refrain myself from Fahisha.I will not or never tell you to censor them, but I think as a human being, I also have the right to enjoy my religious or personal ideology in wikipedia's policy equally as other user's enjoy and make impact on them, so I think wikipedia should keep an opportunity to hide these pictures for a user. I don't know wheather all other muslim users will agry with me or not but most probably bost of them will agree with me including some or many other users. Sharif Uddin ( talk) 15:00, 10 March 2019 (UTC)

As an encyclopedia, articles on subjects related to nudity will have nude images. The best solution here is for you to not visit pages on topics related to sex or nudity. A second solution would be for you to use work computers for working rather than editing wikipedia. Natureium ( talk) 15:09, 10 March 2019 (UTC)

I thought, i would have a better response than that, but no problem. Still now I will remain in my request to all of you to make a better solution for it. Sharif Uddin ( talk) 15:18, 10 March 2019 (UTC)

i was editing the article tazkiah in bengali wikipedia, there was a term Riya which is similar to "the tendency of showing of something", in english wikipedia there is a link added ostentation. so I started sarching the word exibition (in bengali "prodorshon") to link with it, the translated article came out in the search result as the name "Prodorshon Batik" (Show off disease or disorder), I clicked on hte link and then it happened. Same kind of occurance happened many time in English wikipedia, and it is undeniable that all other language based wiki community just follow the english wiki policy and most often translate the english wikipedia rather than hardly or poorly transforming it according to their own culture. In bengali wikipedia, there is all agreed community policy that real photography of graphic nudity is not allowed but artwork is allowed, so in bengali wikipedia, I removed the image, but the same problem I face on enlish wiki, I think a don't have the right to tell it to make it censored, but as a wikipedian like other wikipedians, I must have the right to ask wikipedia to make an opportunity option for the users to hide it, javascript is ess havenot worked today as I tried, so I think making a better option will work and make the rights equal. Sharif Uddin ( talk) 15:26, 10 March 2019 (UTC)

@ Sharif Uddin: Did you have a look at User:Anomie/hide-images as suggested above? -- bonadea contributions talk 15:30, 10 March 2019 (UTC)

I just checked now, it doesn't work. Sharif Uddin ( talk) 15:44, 10 March 2019 (UTC)

Sharif Uddin, it doesn't work for you because you didn't follow the installation instructions. User:Sharif Uddin/common.css needs to be exactly what it says in User:Anomie/hide-images. The script does work for me on Exhibitionism for example. Not that I would ever use it, other than for testing. I find all forms of censorship, including self-censorship, abhorrent. Vexations ( talk) 23:51, 10 March 2019 (UTC)

"as a muslim, it is also my duty to maintain my haya and refrain myself from Fahisha" You do realize that it is not incumbent on us (either as individuals or as the collective Wikipedia) to help you maintain your personal principles or help you refrain from doing or seeing things that upset you? We do not need to "make a better solution" as there is no problem on our end. The problem is entirely your own. If you do not wish to see these things, then don't look at them. -- Khajidha ( talk) 19:24, 2 April 2019 (UTC)

If I intentionally viewed an article titled exhibitionism, I would expect it would include images of exhibitionist behavior, i.e. nudity. There are many types of content on the internet (and in the world in general) which I do not wish to see. For the most part, I self-select what I'm going to look at. I only get upset when I'm tricked into looking at something I didn't want to by a misleading title, unexpected pop-up, etc. As long as it's appropriately labeled, I can make my own informed decisions about what to access.

That being said, one of the nice things about wikipedia is that all of the content is freely available for anybody to do whatever they want with. Artificial intelligence has advanced to the point where it's quite feasible to have a computer detect nudity in images. It seems like it would be a useful project, for an interested person or group, to systematically examine all of the images contained in wikipedia and assign them tags describing aspects of the image which might be offensive to various groups. This collection of tags could then also be made publicly available, and people could build software that takes advantage of them. I could envision a browser plugin which, before it displays each image, would do a lookup in this database and decide to show or hide each image according to whatever set of rules the user has configured. I suspect many people would find such a system useful, and building it would be entirely within the spirit of wikipedia. -- RoySmith (talk) 15:47, 10 March 2019 (UTC)

Many many many many many many many many many support as a proposer. ♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥ I am tooooooooooooo much happy that I have got apositive response, Again LOOOOOOOOOOOOOOOve ♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥ to Wikipidiaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.............!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Sharif Uddin ( talk) 15:54, 10 March 2019 (UTC)

This is more or less what commons:Commons:SDC will do/enable directly. -- Izno ( talk) 16:25, 10 March 2019 (UTC)

Again thanks for another response!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥ Sharif Uddin ( talk) 16:40, 10 March 2019 (UTC)

We do not need the hyperbole. Please be more gentle with your keyboard. -- Izno ( talk) 16:48, 10 March 2019 (UTC)

RoySmith, I had the same thought initially–well, if you want to avoid nudity, don't click on exhibitionism–but then it occurred to me that you and I know what that word refers to, but others–particularly non-native English speakers–may not understand that "exhibitionism" isn't just a synonym for "show off". Perhaps easier than an AI to filter the images would be a little [[[NSFW]]] tag that appears after wikilinks to NSFW articles. It could be a script/gadget so editors could turn the NSFW tags on or off depending on if they wanted them. The hard part would be compiling a list of all the "NSFW" articles, but that could actually probably be done semi-automagically using categories and keywords (and also by looking at the categories that images in the article are tagged with). So if an article is in an NSFW category, has NSFW keywords, or has an image that is in an NSFW category (like "nude"), then it would get the NSFW tag after the link (if the user had that feature enabled), so users would be warned not to click on NSFW links. Leviv  ich 17:02, 10 March 2019 (UTC)

Anything addressing this needs to take account of the fact that different readers find different things offensive, especially in a world-wide encyclopedia such as this, so any global "NSFW" tag will not work. For example, on an individual level, I don't have any problem with nudity but am very squeamish when it comes to pictures of medical operations, particularly if internal organs are visible. And there are also cultural differences. In general (although there are, of course, many individual exceptions) Europeans are more accepting of casual, non-sexual, nudity than Americans but less accepting of violent images, and there are other differences in all cultures. And, of course, such issues exist all over the Internet, not just on Wikipedia. I think it would be best, if people are offended by a particular type of image, to use some sort of global solution that applies to all web sites (surely there are browser add-ons on the lines of AdBlock that can be configured to the user's requirements?) rather than develop something that only works with Wikipedia. Phil Bridger ( talk) 17:30, 10 March 2019 (UTC)

@ Levivich: See Wikipedia:Templates for discussion/Log/2019 February 14#Template:NSFW and Wikipedia:Templates for discussion/Log/2019 March 4#Template:NSFW -- DannyS712 ( talk) 00:00, 11 March 2019 (UTC)

DannyS712, wow thanks for that, I didn't realize this was a current topic of discussion. But anyway I wasn't suggesting a template, I was suggesting more like a script, that would essentially be like a link highlighter, highlighting any link that pointed to a page in a certain category (e.g., pornography). Then people would know not to click on the link. Only those who wanted the highlighter would install/enable it. No one would have to go around tagging stuff "NSFW." Leviv  ich 03:13, 11 March 2019 (UTC)

I am so much happy that I have got a lot of positive response. Thank you all. Sharif Uddin ( talk) 09:11, 11 March 2019 (UTC)

I just followed Vexations and the anomie js worked but I also differently followed the Z-man's bad image js but it didn't work. And initially I dont want to hide all image except the graphic nude images (It would be better for me including semi-nude pictures, but now only graphic nude will at least work.), It will be very irritating for me to do it manually again and again. And also it completely spoils the attention of the work then i intend. Sharif Uddin ( talk) 09:54, 11 March 2019 (UTC)

To comment further on "the bigger issue is when these kinds of images turn up unexpectedly on pages or articles where they don't really seem to fit. There's no really effective way at this time to immediately identify and 'tag' an image with graphic content at the time it's uploaded." – More to the point, we have a large editorial pool, including a lot of people devoted to anti-vandalism and anti-trolling. If you stick a cock picture in Star Wars: Episode I it won't be there long. This is basically a "solution" in search of a problem.  —  SMcCandlish ☏ ¢ 😼  14:32, 12 March 2019 (UTC)

I think probably most editors would agree that the fact that users of the encyclopedia are unexpectedly confronted with material that is shocking or traumatic to them is at least an issue; maybe it is time to revisit the matter of content/trigger warnings. They could be the most principled way to deal with Sharif's issue. But not such an easy task: see Wikipedia:Perennial proposals#Content_warnings and Wikipedia:No disclaimers in articles.

The counterarguments there seem possible to tackle: I'm reminded of Scott Alexander's "I still really want an Official List of Trigger Warnings, looked at and endorsed (if grudgingly) by An Assembly Of Reasonable People"; ^[1] if any assembly can do that, Wikipedia can. The use of content/trigger warnings is that they can appear in popups, be a basis for article exclusion by user preference according to whatever technical choice is favoured, and perhaps eventually influence search results. It makes most sense to say that the topic concerns, say, human sexuality or suicide, rather than the actual contents of articles, since the latter are relatively transient and judgements about them perhaps more likely to be subjective.

Does anyone else think this topic is worth raising? — Charles Stewart (talk) 13:22, 16 March 2019 (UTC)

I think there are valid points that deserve more examination. Otr500 ( talk) 12:24, 29 March 2019 (UTC)

"I think probably most editors would agree that the fact that users of the encyclopedia are unexpectedly confronted with material that is shocking or traumatic to them is at least an issue" Nope. Readers of an encyclopedia should EXPECT to come across things that will upset them. Encyclopedias deal with the real world. And the real world doesn't give a pile of fetid dingo's kidneys about your feelings. The only "warning" you need is the fact that this IS an encyclopedia. If you can't deal with that, log off. -- Khajidha ( talk) 17:25, 2 April 2019 (UTC)

Strong oppose per User:Headbomb. John M Wolfson ( talk) 01:56, 2 April 2019 (UTC)

Continuing oppose to image hiding or other censorship. At the ideological level, Wikipedia's sole loyalty should be to the truth -- not to imposing certain cultures' unspoken rules of what is suitable for "a workplace" (whose workplace? They vary!). At the tactical level, it is better to stake out a position for Wikipedia as an uncensored textbook for an adult audience than to risk being pushed toward a role viewed as presenting to (censored) children, which would only create many more demands. And at the practical level, this is a crowdsourced, unpaid environment. Maybe Facebook has a huge team of 15,000 miserable low-paid censors working for a subcontractor [6] who can delete 1.5 million copies of the New Zealand shooting video, [7] but we don't. So there is no way you can avoid being confronted with an occasional nude on Wikipedia. The rarer you make it the more 'embarrassing' it will be when it happens, so what is there for you to gain? Wnt ( talk) 14:10, 2 April 2019 (UTC)

• Oppose In the OP's personal, local community, images of nudity may be locally held to be offensive, but that doesn't mean that they are everywhere. Going to the "exhibitionism" example, such images are not universally offensive. We don't, for example, alter, remove, partially hide, or obscure with a warning, images of the prophet Muhammad, even though several hundred million people find those images offensive. If images of Muhammad are appropriate in the article titled "Muhammad", images of exhibitionism are appropriate in the article titled "exhibitionism". -- Jayron 32 18:15, 2 April 2019 (UTC)

•  Comment: Pretty soon (first steps this Tuesday), Commons is going to get a detailed tagging system, allowing the contents of photos to be specified in terms of Wikidata items. It's going to take a while, but once this data is well populated it should make it easier to create a voluntary add-on that would 'modesty curtain' images showing particular things. Jheald ( talk) 09:57, 19 April 2019 (UTC)

It won't stay voluntary. It will turn into those "please log in to register that you have a dissident interest in material that ought to be retroactively illegal tomorrow and will be banned anyway once we know what it is" like on the other Silicon Valley outfits. I have spoken against this idea many times on the projects I know, because tagging is an exercise in arbitrary decision making that cannot be reconciled with equality among editors, but Wikidata is an abyss of "computer development" where authority seems to come from the top down. We should think about going over there to edit war over some of these decisions, just in order to determine what is in control of it. He who owns the computer controls the computer -- that's why Wikipedia is impossible. On the other hand, I should note that AFAICT " Commons:Commons:Depicts" as software does not in and of itself mandate that specific categories of unmentionables universally be defined and agreed on, so if a central authority should fail for whatever reason to assert itself over the editors, the scheme should fragment to the point where no 'useful' (i.e. harmful) content stigmatization can be done with it. Note: by "edit war" I mean "contribute enthusiastically within the formal limits of relevant policy". Also, this appears more difficult than I thought since even the Pictures of the Day still have no basic description let alone "depicts" terms. Wnt ( talk) 15:41, 5 May 2019 (UTC)

• Oppose. Unless and until there is a culturally universal, objective definition of what is or is not "suitable for work" (or any other such term you wish to use) then the only filtering system that can work is one that is extremely fine-grained and tailored to individual preferences. Even something that would seem innocuous to filter at first glance, e.g. naked children, would prevent people seeing the images at Phan Thi Kim Phuc. As a fair use image that wouldn't receive any tags at Commons anyway, and so would not be caught by a filter. You also need to consider that an image might be desirable to see in one context but inapropriate in another (which is impossble to know without the context).
  Another consideration is that to be useful at all a filter must work very nearly 100% of the time, this means that you need to tag pretty every image that could appear in an article - otherwise a blacklist filter will show inappropriate images and a whitelist filter will hide millions (literally) of unproblematic images. Tagging will need to be applied to new uploads, at the time of upload, to be effective, which means that you are requiring every uploader to know and correctly apply tags to every image they upload, which is not always going to be obvious - should File:Merchant Seamen's Memorial - reliefs in the sunken garden 03.jpg be tagged as containing nudity? The people in the image are all clothed but at least two of the statues in the background depict nude figures (I'm not sure whether they are real people or mythical figures - does that matter?). According to its description, File:The Four Horsemen of the Apocalypse (1921) - 6.jpg contains implied partial nudity, but I wouldn't know that without having read the caption - how should that be tagged? What about File:Jessica Szohr LF.JPG where the subject is wearing partially transparent clothing? Assuming you tag that with "transparent clothing" and blacklist that, you are also hiding File:Chemical agent protection.jpg. You could rectify that with a tag such as "transparent clothing revealing or partially revealing female breasts" (and should that also be set if it only applies to a person half-visible in the background?) but when you get to that level of detail you are requiring taggers to know about all these tags and people who wish to hide such images from chosing to pick literally thousands of different categories - and before you say to group them into broad categories, who decides whether "shirtless men" (itself likely to have subcategories) is a depiction of nudity or not (it likely would not be regarded as such in French culture but more possibly would be in say Arabic culture). tldr tags that are practical cannot work, and tags that can work cannot be practical. Thryduulf ( talk) 16:42, 5 May 2019 (UTC)

  Damn, I'm not used to hearing people be about 50 times as persuasive as I am on this issue. Keep it up! Wnt ( talk) 18:49, 5 May 2019 (UTC)

  @ Wnt: I've been making arguments about tagging and similar for years and don't intend to stop until the proposals for it do! Thryduulf ( talk) 12:34, 6 May 2019 (UTC)

I've noticed that certain user categories are frequently kept at CfD despite failing WP:USERCATYES and meeting WP:USERCATNO (the purpose of user categories is to categorise Wikipedian editors by participation in the project, no?). Category:LGBT+ Wikipedians (and its subcategories) is one; simply being LGBT says nothing about what one likes to do on Wikipedia; it doesn't mean one also likes to edit LGBT articles. It's merely a statement about the person that describes real-life aspect of him/her, not a Wikipedia-related one. This was given as a reason why Category:Heterosexual_Wikipedians should not exist, and the same logic applies to the other sexual orientations. Similarly, Category:Wikipedians by ethnicity and nationality and its subcategories also seem to have nothing to do with Wikipedia editing (for example, just because I'm English doesn't mean I like to edit England-related articles, and it's not about one's ability to improve the encyclopaedia, or about knowledge of the country), yet I highly doubt that any proposal to delete them would be seriously entertained. In fact, many subcategories of Category:Wikipedians have little if anything to do with Wikipedia editing, and seem to me to be more characteristic of social networking than Wikipedia editing. It seems to me that there are many exceptions to WP:OC/U, but that guideline page doesn't go into them. I think some clarification is needed here and put into the guideline page. Thoughts? Adam9007 ( talk) 20:08, 28 April 2019 (UTC)

If CfD results consistently go against guidelines then either the guidelines need to change or the wider community needs to tell CfD regulars to do things differently via an RFC. I prefer not to have a user page describing myself, and just redirect it to my talk page, because I treat this as an encyclopaedia rather than a social networking site, but I can see the slight possible benefit to Wikipedia in telling people that I have a degree in mathematics, read English and Polish fluently and several other European languages reasonably well, and take an interest in inclusivity, including of LGBT+ people, but I can't see any conceivable benefit in telling people what my sexuality or nationality (a clue to that is that I wish I qualified for an EU passport after Brexit like most of my close family members), or whatever else goes in these user categories, is. Judging by the number of people, including you, who do tell everyone such information on their user pages I think I am probably in a minority here. Phil Bridger ( talk) 16:24, 29 April 2019 (UTC) P.S. I just love good cheese.

Phil Bridger, The issue here is the categorisation, not the user page content. The guideline says that the categories (that is, the categories at the bottom that the page is put into) shouldn't just be statements that the user wants to advertise; they must have some relevance to the project's maintenance and/or improvement. Consensus is against having a straight Wikipedians category for that very reason (Yet somehow, being gay or bi inherently says more about one's WIkipedia editing habits than being straight. I don't get it?), and also because they're evidently in the overwhelming majority. On that basis, perhaps we shouldn't have an American Wikipedians category, because there are far too many here from the USA that having a category for them wouldn't aid navigation. In fact, I daresay that people from the USA, Canada, UK, Ireland, Australia, and New Zealand together make up the vast majority of editors here, so we should only have categories for editors who are not from these countries. Or have I got the wrong end of the stick? There are also many categories, such as Category:Wikipedians by text editor, whose relevance to Wikipedia editing I am at a loss to fathom. That doesn't mean editors should advertise these statements on their user pages, but according to the user categories guideline, they're inappropriate because they don't seem to facilitate navigation based on Wikipedia editing. Adam9007 ( talk) 21:32, 29 April 2019 (UTC)

Yes, I know the issue is categorisation, and that was the specific issue that I thought I was addressing. Many editors, including you, have these categories listed at the bottom of user pages. Phil Bridger ( talk) 21:51, 29 April 2019 (UTC)

@ Phil Bridger: Many editors, including you, have these categories listed at the bottom of user pages And that is what makes me believe that consensus is that they're okay, yet I see nothing in our guideline for user page categorisation that corroborates that belief. Do you think I should CfD them? Adam9007 ( talk) 22:12, 29 April 2019 (UTC)

CfD has already looked at most of them and is producing contradictory results, so a VPPOL RfC is probably in order to get a consistent answer.  —  SMcCandlish ☏ ¢ 😼  02:26, 6 May 2019 (UTC)

I think you may find that, despite WP:USERBOXCAT, many of these categories are populated by people putting userboxes on their user pages. Perhaps the categories would drop out if the userboxes were seen to. Thincat ( talk) 20:44, 29 April 2019 (UTC)

Thincat, Well, I recently created Category:Asexual Wikipedians, and edited some Asexual userboxes to auto-categorise into it, thinking that if we're going to categorise user pages by sexual orientation, we need categories for every orientation, not just some of them. But then I saw the CfD for Category:Heterosexual Wikipedians, and it made me question how on Earth any of them comply with our guideline for user page categorisation. If being straight is just a statement about the person him/herself, so is being any other orientation. This also applies to categories for ethnicity and nationality; they're just statements, and say nothing about one's Wikipedia editing. I simply do not see how they comply with our guideline for user page categorisation (they're not relevant to Wikipedia editing). Yet, both the LGBT+ and gay Wikipedians categories survived their most recent CfD, and I think they'll do so again if they were to go through CfD now. It therefore seems to me that the guideline needs clarification. Adam9007 ( talk) 21:46, 29 April 2019 (UTC)

I hadn't seen that background. I'm not too keen on userboxes or user categories but I wouldn't want to interfere with how other people present themselves. I think for me being English does affect the way I edit WP and it may help for that to be evident to anyone interested. So I suppose I could put myself in Category:English Wikipedians but I haven't bothered. But I'd never, ever put an English flag on my userpage. And I suppose my userpage gives a broad hint I'm heterosexual (bearing in mind my other hint about my age). You might be interested in a CFD discussion I was unfortunate to get tangled up in recently: WP:Categories for discussion/Log/2018 December 15#Wikipedians by philosophy. Thincat ( talk) 22:12, 29 April 2019 (UTC)

@ Thincat: Well, CfDs like that certainly corroborate my belief that the guideline needs clarification! :). By the way, I fail to see how your userpage implies you're heterosexual? (I think this is relevant because I've been told that certain statements on my userpage can be misconstrued (that's already happened once, and the consequences were not pleasant!), and of course I'd rather not be auto-categorised into any "statement" categories that I don't fit...) Adam9007 ( talk) 22:51, 29 April 2019 (UTC)

Thincat's comment is interesting, because userboxes are much less regulated (by community consensus); there are plenty of userboxes for British people and gay people and probably gay British people, and if you want ones without flags, you have that option, and if you'd rather have one with a kitten, you can do that too (in your own userspace, or the special User:UBX "holding tank" for them. But you can't go around creating random user categories; there are actual criteria. The problem is that in some cases we've not been enforcing them, only because doing so tends to get one reflexively attacked as [something]phobic. It's a subjective wikipolitical thing, not a policy-based series of decisions (made by a too-small cluster of editors).  —  SMcCandlish ☏ ¢ 😼  11:33, 5 May 2019 (UTC)

SMcCandlish, Exactly. If a Straight Wikipedians category fails the criteria (if the most recent CfD is to be believed), I am at a loss to understand how a Gay Wikipedians category meets the criteria simply because there are likely to be fewer of them. The fact that we categorise editors by sexual orientation at all suggests to me that the community has decided that there is a purpose to it, but excluding certain orientations kind of defeats that purpose doesn't it? In this case, it seems like there's one rule for certain orientations, and another for others. Yet it doesn't seem like the same can be said of things like race and nationality; they're all okay, even though one's race says nothing more about their Wikipedia editing habits than their sexual orientation does. I don't think we're going to have common practice changed to fit the rules, so I think we need to change the rules to reflect common practice (like you said, I think any proposal to delete the Gay Wikipedians category will likely be deemed homophobic, and I'd rather avoid any (further) insinuation of homophobia). Adam9007 ( talk) 21:21, 5 May 2019 (UTC)

That's just giving in to the factional/special-interest PoV-pushing and name-calling ("you get your way because you'll call me names" = "you get your way because you already did call me names", other than the latter might be grounds for CIVIL/NPA noticeboarding). Either a) such user categories serve an encyclopedia-building purpose, or b) they're just social-networking noise we should delete; the answer to the question will have nothing to do with which persuasion or ancestry it happens to be in a given case. Part of what's happened here is that various gendered, LGBT-related, ethnic, and other categories for mainspace have been kept (only when the label applies to a minority within the larger category and/or could have some bearing on the reason for notability, like LGBT politicians, male nurses, LGBT writers, women writers – but not male doctors, or LGBT doctors; and some have been perpetually controversial, such as Category:Actresses). This article-categorization rationale has no relationship of any kind to rationales for categories for editors. The case for keeping these "heart-on-sleeve" categories is unusually weak, because userboxes serve the same purpose with more flexibility and without polluting categoryspace with Facebook-style "identity posing" that doesn't facilitate collaboration, the sole purpose of editor categories.  —  SMcCandlish ☏ ¢ 😼  02:21, 6 May 2019 (UTC)

This is definitely worth RfCing (all that "the wider community [maybe] needs to tell CfD regulars to do things differently via an RFC" part). What's been going on at CfD (where I'm a regular participant – don't mistake this for some kind of WP:GANG or WP:OWN finger-pointing – it's just a matter of human nature and affinity-group clustering) with categories like this obviously fails WP:NOT#SOCIAL and WP:NOT#WEBHOST principles, and has been failing them due to WP:NOT#ADVOCACY problems; when one policy is ignored, it tends to lead to more policies being ignored to excuse the first violation, in a cascade. It's thus a WP:CONLEVEL failure, in turn: the minute fraction of editors who participate at CfD cannot override central, site-wide policies (cf. WP:FALSECONSENSUS).  —  SMcCandlish ☏ ¢ 😼  11:17, 5 May 2019 (UTC); tweaked 04:03, 8 May 2019 (UTC)

@ SMcCandlish: the minute fraction of editors who participate at CfD cannot override central, site-wide policies But it's what's said at CfD that determines whether or not a category is kept, not what the policies and guidelines say... Adam9007 ( talk) 21:53, 5 May 2019 (UTC)

CfD making up stuff on the fly between a handful of like-minded editors certainly does not set the NOT and CONLEVEL and other policies. Your argument inverts the relationship between the policies and the cluster of editors; it isn't responsive to what I said. "[W]hat's said at CfD that determines whether or not a category is kept" still has to produce results that comply with site-wide policy or the "consensus" is false. An RfC will sort this out.  —  SMcCandlish ☏ ¢ 😼  02:21, 6 May 2019 (UTC)

@ SMcCandlish: Shall I turn this into a RfC, or start a new discussion once this one ends? Adam9007 ( talk) 23:59, 7 May 2019 (UTC)

I wouldn't turn this} into an RfC. Better to clean-slate the matter with a concise and neutral RfC question, and maybe a list of links to previous discussions, relevant P&G pages, etc. as a backgrounder; and pre-loaded with a "Comments" section for short !votes and an "Extended discussion" section for arguing. :-)  —  SMcCandlish ☏ ¢ 😼  04:03, 8 May 2019 (UTC)

FYI Wikipedia_talk:No_personal_attacks#Harassment,_mocking_or_otherwise_disrepecting_someone_on_the_basis_of_gender_identification_and_pronoun_preference -- Fæ ( talk) 09:21, 8 May 2019 (UTC)

The Arbcom has, in a recent post to all admins, made it clear that they may permanently desysop administrators after their account has been compromised. "The Arbitration Committee may require a new RfA if your account is compromised." [8]

In discussions afterwards, there were multiple comments in the line of "we shouldn't permanently desysop people for good-faith compromises" ("good faith" to exclude e.g. admins simply giving away their password to others or posting it publicly). Even a temporary desysop is usually not necessary for compromised accounts, these get locked instead, but that's a different discussion. Permanent desysops (requiring a new RfA) are normally only done for admins who have either repeatedly or egregiously violated policies (certainly when done using admin-only tools) and where previous attempts at dispute resolution didn't work (in some extreme cases, no such prior dispute resolution is needed).

Does having your account compromised by carelessness, bad luck, or some other involuntary security breach constitute a sufficient reason to warrant a permanent desysop even after you have regained access to your account and have been confirmed to be the rightful owner? Or should this be the kind of thing were a warning is sufficient? This thing has been discussed for more than a decade [9], but probably needs some formalization or reaffirmation. (This is not a formal RfC, let's first discuss this to get some general idea of what people think is best before trying to shoehorn it into a policy text) Fram ( talk) 08:31, 7 May 2019 (UTC)

The wording above "The Arbitration Committee may require a new RfA if your account is compromised." suggest this isn't even particularly for admins being careless. This would also include any admin that had been maliciously compromised. Why we would ever consider a user to need a new RfA, would only be on behaviour in my eyes. Having your account tapped into might be a sign that it isn't secure enough, but we can't say that wholesale. Best Wishes, Lee Vilenski ^{( talk • contribs)} 08:36, 7 May 2019 (UTC)

Permanent desysop should imho be the last recourse for behavioral problems. Such problems can include carelessness though. If an admin uses "password" as their password on Wikipedia or their associated email account, I would certainly assume that this person is not someone who can be trusted to have access to the admin toolkit and that if they want the tools back, the community should explicitly decide to regrant these tools. Regards So Why 09:14, 7 May 2019 (UTC)

I agree that removal of adminship should never be permanent for any reason outside of behavior. —⁠ 烏⁠Γ ^{( kaw)} │ 09:20, 07 May 2019 (UTC)

Speaking as someone who has been permanently deopped ( and who will remain so as long as CRASH exists) a permanent deop for account compromise is not justifiable unless there's evidence the admin doesn't take action to ensure that it isn't compromised again (at which point there's no justifiable reason to let them keep the mop). — A little blue Bori v^_^v ^Bori! 10:14, 7 May 2019 (UTC)

• When it comes to permanent de-sysopping, we should compare this suggestion to other acts (presumably behavioural) that do and critically don't result in de-sysopping. These have included some pretty serious acts, and thus I feel this would be an egregiously OTT reaction. The interpretations given about are reasonable - either repeated incidents due to inaction (3+ incidents even with action would probably demonstrate something direly wrong, however) or egregious carelessness (ala "Password" as password) Nosebagbear ( talk) 10:19, 7 May 2019 (UTC)

  3+ times would tell me either their computer is bugged, they're reusing passwords that were used on sites that had been compromised, or they're gullible enough to get phished. — A little blue Bori v^_^v ^Bori! 10:38, 7 May 2019 (UTC)

  Has any admin account ever been compromised more than once? * Pppery * _survives 22:23, 7 May 2019 (UTC)

  Not thus far, though this is because the admins involved took steps to avoid getting compromised again (mainly password changes, since they were primarily compromised due to password reuse). — A little blue Bori v^_^v ^Bori! 20:15, 8 May 2019 (UTC)

• I believe the key word is "may". They are saying that they will look into each case, reserving themselves the right to require the user to go through a new RFA depending on the circumstances. The better steps you take to prevent the account from being compromised, the less likely they are to require this. עוד מישהו Od Mishehu 10:28, 7 May 2019 (UTC)
  • To quote the admin newsletter: In response to the continuing compromise of administrator accounts, the Arbitration Committee passed a motion amending the procedures for return of permissions ( diff). In such cases, the committee will review all available information to determine whether the administrator followed "appropriate personal security practices" before restoring permissions; administrators found failing to have adequately done so will not be resysopped automatically (emphasis in the original, marked differently). In other words, if the admin followed what ArbCom believe to be appropriate personal security practices, then (s)he will be resysoped without any need for a new RFA; if not, (s)he won't. עוד מישהו Od Mishehu 10:48, 7 May 2019 (UTC)
    • I'm quite fine with that. Advanced permissions require advanced security, and if an admin cannot be responsible for basic password security, then I have no problem with them re-applying for RFA. -- Jayron 32 10:51, 7 May 2019 (UTC)
      • I'm basically okay with that too, although I've suggested a change in process somewhere else (here? there are a lot of side discussions scattered about). What I'm not okay with is that Arbcom seems to be making up definitions of "appropriate personal security practices" on a case-by-case basis, so I have no real idea if my "personal security practices" are up to the standard where I would not have to go through RFA if my account were hacked. I have an 80+ character unique randomized password, 2FA on my recovery email which has a similarly strong password, login notifications turned on, I rotate my passwords periodically, I use an alternate account when I'm not sure of my network's security, and I periodically log out to clear open sessions. Is that good enough? No idea. Ivanvector ( ^Talk/ _Edits) 14:08, 7 May 2019 (UTC)
• "the revocation of privileges may be permanent." Comes from WP:SECUREADMIN policy, which policy contrasts "permanent" with "temporary", Arbcom as an investigating body has always decided on when permission is removed in context at least until a new RfA, when the Community decides. Moreover, in matters of such security, it seems inevitable that evidence should often be taken privately. Alanscottwalker ( talk) 10:58, 7 May 2019 (UTC)
• Just thoughts here. I think it would be a good idea to de-pair "compromised account" from "admin violating policy" to inform what to do here, and get out of this loop of "who has the rights to do what". A compromised account, admin or functionary or otherwise, is a global issue - the account is compromised on every wiki and other website which shares our unified login. Compromise should not be an arbcom issue in the first place - it should be a contact the stewards, lock the account, contact WMF Trust & Safety issue. Forget about contacting some number of arbitrators, convening a panel via email, finding a bureaucrat who's awake, ... just lock the account. Find a steward on IRC or email WP:EMERGENCY or whatever. Account locked. Compromise stopped. Done.

Once Trust & Safety confirms the account is secured, then we have a discussion here about how the admin whose account was hacked secured their account, if they're obeying WP:SECUREADMIN (which is a community-endorsed requirement of all administrators, regardless of how long they've had the bit), and if it's found that they breached the policy then they may face desysopping for cause. Much of that will be private, obviously, so that's where Arbcom gets involved, and it's Arbcom that gives orders about desysopping for cause anyway.

Changing our processes this way has the added benefit locally of not caring about rights removal and restoration (a locked admin can't do anything anyway), and of passing the buck back to the WMF, who have promised to improve the ongoing account security issues for at least four years. Ivanvector ( ^Talk/ _Edits) 12:20, 7 May 2019 (UTC)

• I may be chiming in on this with a lack of perspective, but if an admin that is permanently de-sysopped from a compromised account is required to undergo another RFA, and that admin has been in good standing at the time of their account being compromised, what is the issue with requiring another RFA? The main difference that comes to mind is that the standards for being an administrator may have changed significantly since they were last given the bit, but I don't see that as being a situation where requiring an RFA would be an overall burden on the community.-- WaltCip ( talk) 12:25, 7 May 2019 (UTC)

  I don't think anyone wants to deal with 27 questions and 5-10 serial opposers finding a silly reason to oppose (which will happen because the account was compromised, no matter what the reason was) spread out over one week. Even the recent new admins with near-perfect RFAs were still answering pointlessly-complex questions long after it was clear they would be promoted. ZettaComposer ( talk) 12:44, 7 May 2019 (UTC)

  @ WaltCip: - 2 main problems: depending on your admin field, a person may have created significant opposition in the acceptable course of their duties. Second, ARBCOM has demonstrated multiple members do not have a great idea about security aspects, despite being an intelligent group of people. I imagine the general knowledge about security is significantly lower in an RfA. Nosebagbear ( talk)

  All fair points, though I think that speaks more to the RfA process being flawed as a whole rather than the proposed process by ARBCOM which is to require a re-confirmation RfA for compromised accounts, because anyone who edits in a controversial field of Wikipedia (like American politics or any of the WP:DSTOPICS) would be subject to the first point you made, regardless of their status. I don't think it's too much of an ask to have some sort of re-confirmation step (like a CratChat, as proposed below), even if it's not an RfA.-- WaltCip ( talk) 13:22, 7 May 2019 (UTC)

  I would note that that suggestion would not (from my POV) be a "all compromised admin accounts go through it", it'd be a "if ARBCOM thinks a competence/conduct failure was sufficiently bad that a de-sysopping would be reasonable, then the 'Crats would have at it". Nosebagbear ( talk) 14:00, 7 May 2019 (UTC)

• If you must have an idea like this, then why not require a ' CratChat - much higher % who are technically adept, a much higher community trust level - seems a good compromise. Nosebagbear ( talk) 13:12, 7 May 2019 (UTC)
• If an account is compromised it should be locked until the owner can secure it. If those who manage the lock and unlock (stewards? bureaucrats?) get a feeling that the user was negligent and that user has advanced ops, then they could report it to ArbCom and if necessary a case could be started to determine if the user has violated policy to the extent that they should have their ops removed. That's how the process should work in fairness to all. ArbCom should not take it on themselves to start cases when nobody in the community has complained. Jehochman ^Talk 14:08, 7 May 2019 (UTC)
  • @ Jehochman: Theoretically, I'd support this, but in practice, there are grave difficulties. Discussing account security with a compromised admin should happen off-wiki for BEANS reasons, but the bureaucrats no longer have a mailing list. It was shut down by the community, so they have no way to perform this role. It's worth noting that mailing list existed when the existing policy was written. Further, only ArbCom has the information relevant to determine if a user was negligent in many cases. We seek information directly from the WMF, and they are generally very forthcoming to us about details of an attack on the understanding that we will keep that information private due to our confidentiality agreements. At the very least, they will privately tell us the suspected vector of attack if requested by us, which is not always the case when asked publicly. It's unclear how the bureaucrats could ever make a determination on whether the admin left their account vulnerable without being able to discuss or speak with the WMF off-wiki. (Also, please do keep in mind that arbitrators are community members, too. I think that basic concept is lost a bit in your last statement. If no arbitrator - who is a community member - expressed concern based on the private information we received, no case would be started, presumably. We're just community members that may be in a better position to have information relevant to whether or not we should be concerned in this case.) ~ Rob₁₃ ^Talk 14:18, 7 May 2019 (UTC)
    • Maybe the flow of information needs to be changed. We should probably think about the best way to address community issues rising from account security, rather than trying to fit square pegs in round holes. Maybe the mailing list needs to be reinstated, with secure archiving and proper oversight. Jehochman ^Talk 14:30, 7 May 2019 (UTC)
    • I don't think bureaucrats have an appetite to get involved in the investigative process. The committee's advisement as to whether a previously compromised user is now fulfilling their security requirements and accordingly the committee endorses a resysop is still desired. I think this is all just a matter of some unfortunate wording in the recent communique and perhaps previous motions which implied the committee had the authority to actually sysop users. – xeno ^talk 14:47, 7 May 2019 (UTC)
• RFA is something of a trial by fire, where a user's whole conduct and merits are measured by the hoi polloi—it is an arduous process, and though I think most admins would pass RFA again if tested, is it really appropriate to require this of them when they would have been desysopped on purely technical grounds? (And would most of them pass? It's quite easy to make enemies) If they are desysopped on technical grounds, they should be judged on technical grounds by some sort of crat chat as Nosebagbear mentioned above. Also, any sort of delay or chance they might not be resysopped after being compromised makes compromising an even more effective tool for abuse, and could make such abuse targeted. Pinguinn  🐧 14:54, 7 May 2019 (UTC)

  We deal with "technical" breaches of policy all the time, indeed all breaches of policy are technically breaches, but in each case the issue sometimes becomes what more does it mean, matter, or portend, and in each case we then investigate it somewhere, whether at AN/I or at Arbcom. And it seems Arbcom is what makes sense here, unless you want a bunch of ADMINACT questions at AN/I. Alanscottwalker ( talk) 15:05, 7 May 2019 (UTC)

  I mean "technical" in the computing sense, in that compromises of accounts (unless the password was given away intentionally) are in some manner or another a security breach, not a policy breach. I certainly do not profess advanced knowledge of how such accounts are compromised or if, in any certain scenario where an admin has been compromised, that admin had been negligent in securing their account. I doubt many people do. Yet I and people like me would be voting at an RfA or commenting at ANI. So I agree with you that Arbcom or crats should be the ones to handle this as sufficiently experienced users who deal with nonpublic information all the time. But they shouldn't be throwing such judgements back to the community in the form of reconfirmation RfAs. If Arbcom believes a user has been so negligent in securing their account to not resysop them immediately after they have been compromised, what can the community add to that judgement? It certainly doesn't seem like best practice to potentially let them overturn it. Pinguinn  🐧 08:05, 8 May 2019 (UTC)

• I honestly believe that every computer is compromised at this point. It is only a question of by whom and what they plan to do with the data. Maybe you have a virus, maybe you have a virus checker that is busy uploading 'samples' of your 'suspicious data' (especially key logs of your password entries). Maybe you have a compromised browser (which one isn't -- Tor was screwing around without a rubber thanks to a Firefox de-certification of all plug-ins including NoScript the day that Wall Street Market was taken down last week). Maybe you have a compromised operating system (Microsoft has all the same shit in its terms and conditions as any free or pay virus checker). I truly believe that there is not one admin here that the NSA couldn't have their account posting dick pics in half an hour. The only thing up to you is how much you want to reward the spies for using their god-like power should they choose to. Wnt ( talk) 15:37, 7 May 2019 (UTC)
• If your password was "123456", you need a new RfA. Otherwise, ArbCom should not be creating new policy out of thin air by requiring RfAs for hacked accounts. — pythoncoder ( talk |  contribs) 21:42, 7 May 2019 (UTC)

  Amazing! That's the same password I have on my luggage! ~ ONUnicorn^{( Talk| Contribs)} problem solving 13:14, 8 May 2019 (UTC)

  Admins' passwords are required by the software to be at least 10 characters long. * Pppery * _survives 22:23, 7 May 2019 (UTC)

  1234567890, then?-- WaltCip ( talk) 11:59, 8 May 2019 (UTC)

Does that apply to admins that haven't changed their password since 2006? Ivanvector ( ^Talk/ _Edits) 12:10, 8 May 2019 (UTC)

Yeah. If their password is something like 'Password' or 1234 they'll be asked to change it, probably everytime they log in using Special:Userlogin. But a "skip" button also exists, so it's not being forced, at least for now. – Ammarpad ( talk) 13:04, 11 May 2019 (UTC)

Wikipedia has very widespread use of Alexa ranks in website results, but there seem to be some issues with the idea:

• As described here, there are also Nielsen NetRatings and perhaps other ratings groups. Why do we always seem to just have Alexa?
• The arrow for "decreasing" or "increasing" seems recentist to my eyes - it doesn't provide an encyclopedic sense of the site's overall course beyond whatever month an editor sampled, plus it doesn't say how much it is increasing or decreasing (there's no neutral that I know of).
• I just saw a deletion at Wikipedia:Articles for deletion/List of countries by future population (United Nations, medium fertility variant) based on the idea that a UN table of projected populations could be copyrighted information. I wasn't convinced that is true, but I should check: how many Alexa ranks can Wikipedia reproduce in various articles in a standardized format before we run into trouble? Note that an Alexa rank is not even as factual or objective as an estimated future population, since the rank explicitly is taken only from among whatever websites they survey by some means.
• Why does the infobox generally give one or more numerical ranks that mean little to us, rather than some kind of number of visitors information?
• On the other hand, if the information is not copyrighted, then could we have a tiny little inline graph, like one of those trendlines out of the new Microsoft Office products, that gets automatically made up for the site from the reported data so that we can read back at least a few years to see the total trend?

Maybe this should be at the template talk page, but I feel like only technical editors would read it there and this seems like a broad policy question affecting a vast number of pages. Really, it's a question inherent to each of the articles that use the statistics. Wnt ( talk) 14:33, 2 April 2019 (UTC)

• @ Wnt: please also see Template_talk:Infobox_website#Bot_Job_and_arrows - we have a BRFA on hold ( Wikipedia:Bots/Requests for approval/LkolblyBot) that will update these ranking, pending on what to do about the arrows. — xaosflux ^Talk 14:56, 2 April 2019 (UTC)

  Which could also be canceled if someone decides we shouldn't maintain this information at all of course! — xaosflux ^Talk 14:58, 2 April 2019 (UTC)

  Which is the comment I made at {{ infobox website}} of course. See talk page. :^) -- Izno ( talk) 16:51, 2 April 2019 (UTC)

• Thank you, Wnt, for bringing this up here. I don't know what the situation is like now, but I remember that some years ago bots used to get approved on the basis of their technical correctness, with little regard to whether the edits that they make are a good idea. I don't see why we should aim to reproduce one ratings company's results, and especially not the "up" and "down" arrows that are a blatant example of recentism. This is an encyclopedia, not a running commentary on one organisation's measure of a web site's popularity. Phil Bridger ( talk) 17:09, 2 April 2019 (UTC)
• I agree that those up and down arrows and whatever information they convey have no encyclopedic value and ditching them is actually a good idea. – Ammarpad ( talk) 07:47, 3 April 2019 (UTC)
• Oppose Alexa The amount of resources required to keep this data updated is fairly intense, a ton load of web scraping of the Alexa site is going on. This is not good. I don't see why we can't just link to the Alexa page and be done. Users can click through and discover information from Alexa like they would any other external link. -- Green C 13:38, 3 April 2019 (UTC)

  From a technology POV, if we were to do this, would suggest the following: Rename the infobox field from |alexa= to |web_rank= (something generic). Populate that infobox field in every article with a new Lua template called {{web rank}} (or whatever). Create Module:Web rank/database which is the top 1,000 websites ranked. This file is updated once every 6 or 12 months by a bot. The template will display ranking data if the website exists in that file, otherwise it will display a generic link to Alex and/or other ranking services, but otherwise no actual ranking information. -- Green C 21:17, 3 April 2019 (UTC)

• I also Oppose Alexa and think it should be deprecated. It seems to me to be the definition of non-encyclopedic content, the non-reliable/subjective equivalent to updating the infobox of each public company's article with its daily closing stock price, which a bot could certainly scrape from a finance website. UnitedStatesian ( talk) 13:44, 3 April 2019 (UTC)

  I think of it as being closer to a company's number of employees than its stock price. A stock price is of little importance to understanding a company, unless you're an active investor. However, the number of employees gives you a rough size of the company (100,000 employees? 100 employees? You imagine very different companies for these two values, whereas a $20 stock price vs. $1000 stock price tells you absolutely nothing beyond the market cap/number of shares ratio). We maintain the number of employees at a given company, even though that value is subject to recentism. e.g. Myspace, which at its heyday had 1,600 employees but now has 150. We report the 150, and we don't just provide a link to the citation so the user can click through find out on their own. (however, I agree that the up/down arrow is of little value, especially given the short time over which it cares) Lkolbly ( talk) 13:42, 4 April 2019 (UTC)

  I would think that a measure of the number of visitors would be much more important than the rank, by this analogy. I mean, if you read a company was the 4000th largest employer in the U.S. and the 15000th largest employer worldwide... Wnt ( talk) 13:52, 4 April 2019 (UTC)

  For sure I could agree with that. I would absolutely support replacing Alexa with some other datasource that gave absolute number, I'm not presently aware of a reasonable alternative datasource (SimilarWeb appears to have similar data, after a quick Google search. But licensing may be an issue, I dunno). Lkolbly ( talk) 14:22, 4 April 2019 (UTC)

  IMO absolute page view counts are arbitrary data, it lacks context unless you can intuit what the numbers signify. It would be like maintaining a database which isn't what Infoxbox's should be for. We can provide external links to third party sites that do web rankings and view counts as their core mission, and not get into the business of maintaining that data internally, except for the top 1000 or so (much more and it puts a load on resources). -- Green C 15:56, 4 April 2019 (UTC)

  I dunno. Page view counts specifically maybe aren't too great, in my mind I think unique visitors would be the ideal metric. That's something you can intuit pretty reasonably, just as well as you can intuit number of employees or revenue (both of which are database-like items we maintain internally. Can you intuit what it means that Baidu has CNY 175.036 billion worth of equity in 2018?). If I see a website has a billion unique visitors, I'll think it's 1000x more popular than some other website with only a million unique visitors. But page view counts gives a roughshod approximation of that. Lkolbly ( talk) 16:24, 4 April 2019 (UTC)

• ​ ​ ​ ​I agree with GreenC that the best approach would be to have a Lua module for website statistics. The data is meaningful in that it provides an indication of how popular a website is, so I think removing all of the data summarily would not be helpful. As noted above, there may be other metrics, but they may not be as consistently useful or readily available (most websites don't publish unique visitor statistics, whereas just about every marginally important website in the 21st century has or had an Alexa rank). Furthermore, the stock price comparison isn't necessarily accurate, since Alexa ranks represent a rolling average.

  The up and down arrows presumably match the ones shown on the website, which indicate change after 3 months (based on subtracting 3 from the month number and comparing data from that date). If the convention is consistently followed, then I think that data could be useful as well. (Tangentially, many of the arrows are reversed to indicate that lower is better; this could be a point of contention.) Jc86035 ( talk) 07:37, 5 April 2019 (UTC)

• Support Alexa. As Lkolbly mentioned earlier, Alexa ranks give readers a measurement of how significant a website is. In my opinion, the best comparison from {{ Infobox company}} is the company's revenue, which is a metric that provides an instant impression of the subject's scale. Both revenue numbers and Alexa ranks can be accompanied with up/down arrows and also need to need to be updated on an ongoing basis. I personally find Alexa ranks (and the arrows) to be useful information.

  Based on how the proposed LkolblyBot would operate, I think the amount of server resources consumed would be negligible. According to alexa.py, the bot would query Alexa's API and parse XML responses like this one for wikipedia.org, which is only 1.1 kB in size. Multiply that by the 4,560 domains in the candidate list, and the total amount of bandwidth required to download the data for all of the domains in the list is just 5.0 MB. "A subset of these pages will be updated each month." This script would barely consume any resources on a low-end personal computer.

  Responding to Wnt's suggestions, I would prefer to see both the unique visitor and Alexa rank metrics for each website. To be vendor-neutral, it would also be appropriate to use similar statistics from Nielsen, SimilarWeb, and other data providers when available (although I have not looked into whether this data is actually publicly available from these other providers). With multiple providers, I'm not sure how much of this information would belong in the infobox, but the metrics would be worth displaying in a table in the article body.

  GreenC's suggestion to use a module appears to be the best and most versatile method for data storage, although I would prefer to see the metrics updated monthly instead of (bi)annually. —  Newslinger  talk 08:44, 5 April 2019 (UTC)

  @ Newslinger: One of the issues I had with archiving data was that it was impossible to save the API pages in the Wayback Machine, even though it would have been much better to use the API than to save the HTML pages. This now seems to work (even without logging in and using the beta version of Save Page Now). There was a very large amount of overhead associated with archiving the full HTML, although the graph images are useful due to containing data for the past year.

  @ Lkolbly: Are the API keys necessary? In my experience, while collecting data from the API (without archiving it), I was able to download data for more than a million websites by making hundreds of concurrent connections and resetting my network's IP address every few minutes. I'm not saying that this would be a good way to do it, but it's certainly... possible. Jc86035 ( talk) 09:26, 5 April 2019 (UTC)

  I don't think they're strictly necessary. You don't get as much data (basically just rank and delta, but that's all we show anyway), being who I am I love collecting as much data as I can from everywhere and storing it in text files until I run out of disk space. Resetting my network IP every few minutes would be... inconvenient, for sure. As far as server load goes, Wikipedia currently receives 1.8 edits per second, this would be increasing that by 1.7 milliedits per second (0.1%). Linking to the API page from the citation would be not user friendly for people who did want to click through to the Alexa page, though. Lkolbly ( talk) 12:54, 5 April 2019 (UTC)

  @ Lkolbly: Perhaps a custom citation could be used to link to both the current HTML and XML pages, as well as the archived XML page?

  With the Lua module approach this could be accomplished with very few edits, as few as one per month (i.e. by updating all of the data at once).

  Incidentally, you might be interested in looking at Module:Alexa, Wikipedia talk:Lua/Archive 6#Alexa template and User talk:Jc86035#Alexa ranks. Jc86035 ( talk) 15:53, 5 April 2019 (UTC)

  Since this discussion is in the policy section of the village pump, it might be better to focus on whether Alexa ranks should be included at all, rather than the technical implementation (which would be moot if there is consensus against including Alexa ranks). —  Newslinger  talk 01:30, 6 April 2019 (UTC)

• Kill Alexa ranks. Wikipedia is an encyclopedia. In case you've never seen an encyclopedia besides Wikipedia, I assure you that they don't have things like current stock value, Alexa ranks, or other information that is constantly in flux. They give you the big picture and point you to other resources for more detailed information. Kaldari ( talk) 22:35, 5 April 2019 (UTC)

  @ Kaldari: We have plenty of other time-dependent statistics (population, for instance). Alexa ranks aren't inherently unsuitable just because they're updated every day and aren't publicly archived by the company. As noted above, some sort of statistic to indicate the popularity of a website can be of value (though not necessarily just the Alexa rank). Jc86035 ( talk) 08:12, 6 April 2019 (UTC)

  Also probably worth noting is that Wikipedia isn't really that similar to a traditional encyclopedia, because it tends to have much more depth and breadth (and, of course, can be updated more easily). Outside of articles about people and buildings, there are definitely a lot of regularly-updated statistics (music charts, passenger numbers, political polls...). Jc86035 ( talk) 08:51, 6 April 2019 (UTC)

  I think one question to ask is whether Alexa is a primary or a secondary source. I mean, I know that the ratings come from a Computer, which sits between the seraphim to judge the deeds of men, but it does after all post on little pages that few people read that aren't even archived. If some blasphemer were to come along and say, "the Computer is wrong!", the answer would surely be that Alexa faithfully publishes the result of its Algorithm and therefore cannot be held to blame for following its outcome wherever it leads without question, even if it is "a complicated calculation that involves correcting for biases as well as identifying and discarding fake or spam traffic", as the official guide below puts it. But Wikipedians are a crusty group with a formidable dogma of their own, and I think any delivery of magical stone tablets from a burning table at Wikimania would be attended by protests concerning use of a self-published source. And some of us might read the heresies of those excessive in the faith, noting that there is guide after guide after official guide online about how to improve a site's web rankings by means such as the company installing the Alexa Toolbar on all their browsers in all their computers to start, registering/verifying the site with Alexa, using the Alexa Rank Widget on company pages because "every click will be counted", and all the usual SEO techniques to improve Alexa ratings by subscribing to Alexa's Marketing Stack and Advanced Plan. I should note the importance of search-directed traffic in that, so it is worth noting that readership of the Alexa article increased long term after Template:Alexa was introduced in November 2016. If I were the Computer I would send that Wikipedian a Christmas present, but that's just me. Anyway, I think it is instructive to consider the difference in reaction Wikipedians would have if someone gave each company site a rank based on some human reviewer they found on the internet, even if he wasn't biased and didn't sell services on the side. That's how much more important and dignified by nature the Computer is than any of us... remember it. Wnt ( talk) 10:33, 6 April 2019 (UTC)

  @ Wnt: Assuming good faith on Alexa's part, presumably those methods would allow them to get more accurate data (although obviously they wouldn't mention that a website's ranking might actually go down if they got more accurate data from that website, since they're trying to sell something). Obviously it's impossible for anyone outside the company to genuinely verify whether their statistics are made-up, but the ranks themselves are usually close to or in agreement with those calculated by other companies.

  On whether Alexa is a primary or secondary source, I would say that Alexa is mostly a primary source since they collected and analyzed their own data in order to publish the ranks (rather than, say, analyzing a public dataset). However, the data has been used in various reliable secondary sources, including the New York Times (2014) and the Guardian (2006). Jc86035 ( talk) 18:41, 6 April 2019 (UTC)

  @ Wnt: On the page views issue, the increase could also be partly attributed to another bit of Amazon with a similar name becoming increasingly popular around that time. In any case, {{ Infobox website}} has had |alexa= for an uninterrupted period beginning on 15 March 2008, and the parameter previously existed as early as 18 September 2006. Furthermore, the creation of the template doesn't mean much on its own; editors would still need to manually add that data ( OKBot used to update some of this data from 2011 to 2014). Jc86035 ( talk) 19:05, 6 April 2019 (UTC)

• Why You Shouldn’t Use Alexa Traffic Statistics
• Alexa is Bullshit – Please Stop Using it as a Traffic Comparison Tool
• The Real Problem With Alexa
• How Accurate Are Website Traffic Estimators?
• The Curious Case Of MomDot.com’s Traffic Stats
• Why can’t marketers see that digital metrics are bullshit?
• Web Stats for musicians: Lies, Damned Lies and Google Analytics.
• Buywebsitetrafficreviews: We know where to buy web traffic

If anyone with a credit card can inflate a statistic, the statistic is useless as a Wikipedia source. I'm just saying. -- Guy Macon ( talk) 12:11, 6 April 2019 (UTC)

@ Guy Macon: All sorts of other minor statistics could be faked and we wouldn't be able to tell; for example, music sales have been faked in the past, but Wikipedia doesn't just write off all of the music charts from the decades where this was an issue.

I think this Guardian article might be somewhat helpful, although it's almost nine years old.

On the pages you've linked: I note that almost all of them are anecdotes and most of the analyses don't seem to be conducted by professionals in the field. While the anecdotes may be somewhat useful, most of them are just from people who run websites, and I don't think any of them mention any filtering of bot/crawler traffic.

• The first is someone's blog, so we can't really use it. The points are, I think, valid; but given the difficulty in collecting the data in the first place, discrepancies are completely expected. The data collection issue is somewhat concerning, although it's worth noting that because none of these companies publish a complete methodology (e.g. how is the data from the Alexa add-ons normalized relative to the data collected directly from the websites?) it's more difficult to tell if Alexa's doing it right. They do, at least, have multiple data sources. Presumably, since their data is (hopefully...) their main product, they do have an interest in keeping the numbers somewhat accurate.
• The second is also someone's blog. I think it's possible that the author is... counting the wrong things (raw traffic instead of unique visitors), but I do think that their perspective is useful here. If anything, this indicates that multiple data sources should be used, sort of like {{ Infobox US university ranking}}.
• The third, a forum post from a website owner, is more than ten years old, which is from before some (to my knowledge) significant changes in Alexa's data collection. Some of the points that the author makes are somewhat flawed (e.g. should Alexa actually have excluded iframes if the embedded content was transferred normally as if it were loaded in a separate window? if they were directly measuring the use of the embedded content they might not have been able to tell).
• The fourth is another blog post, from a staffer at an SEO company. They don't mention Alexa at all, but discuss other companies' traffic statistics and compare them to private Google Analytics numbers. I'm somewhat irritated that they measured "most accurate" by calculating the average error without adjusting for the traffic volume for each website and without using the absolute value value of each error (i.e. instead of letting numerically negative errors cancel out positive errors), since it's not like SimilarWeb's estimates were anywhere close to perfect.
• The fifth, another blog post, has a semi-retraction at the end.
• The sixth is a Marketing Week article (or opinion piece?) which doesn't mention Alexa. I agree with the author's points on why these statistics are unreliable. However, the author notes that he and his co-debater actually lost (and "lost badly") the debate which is the subject of the article; and the inability to measure exact data does not necessarily mean that all of the data has to be written off. Wikipedia has hundreds of pages dedicated solely to cataloguing opinion polls for elections, although arguably those are on slightly firmer ground because polling firms usually release detailed methodology and their reports can be more easily re-evaluated by third parties.
• The seventh, another blog post, doesn't mention Alexa, or any other company that publishes traffic estimates. The author's main point is that interaction matters more than page views. I'd say the page is somewhat irrelevant to this particular discussion because the only way Wikipedia would be able to catalogue interaction in a meaningful and scaleable way is by keeping a database of Facebook likes and such, which is another can of worms and would also be flawed in different ways (e.g. because of those Wi-Fi networks that require users to like the venue's Facebook page before proceeding).
• The eighth and last is a review site for websites which sell traffic. Those services' existence doesn't necessarily indicate that we should summarily ignore all web traffic data. The article The New York Times Best Seller list mentions similar issues. If even "the preeminent list of best-selling books in the United States" has these issues, perhaps it's just something that has to be taken into account if anything useful is to be gleaned from this sort of data.

The problem with writing off this sort of data entirely is that it isn't really definitively more or less reliable than other pre-internet datasets that have been published outside scientific journals (e.g. how the Times compiles the [Best Seller] list is a trade secret), and it doesn't make sense to ignore this data when the pre-internet data has been used anyway just because there's nothing better. Jc86035 ( talk) 18:41, 6 April 2019 (UTC)

Music sales cannot be easily faked by anyone with a credit card. There is a huge difference between "we try to provide reliable statistics but some people figure out how to cheat" and "there are multiple web pages that will reliably and undetectable make the numbers as big as you want, with prices starting at less than a hundred dollars". -- Guy Macon ( talk) 19:03, 6 April 2019 (UTC)

@ Guy Macon: I agree that the stakes and costs are obviously a little higher in those cases, but it's not necessarily "as big as you want". A rank in the top 10,000, for example, would be much more difficult to fake than a rank in the top 1,000,000. We also don't really know how good those services are. (And it's plausible that several hundred US dollars would be enough to make a difference near the bottom of some music charts, given a cooperative record store manager...)

When I was trying to archive [way too much] Alexa data, I used lists of URLs from a competing service which publishes a list of 1 million domains in order to be able to archive Alexa data. Many of the sites on the other list had almost identical ranks on the Alexa chart, whereas some of the others had Alexa ranks far below 1 million, which indicates that Alexa might have been more capable of filtering out spammy websites. Nevertheless, a rank above 10,000, or even above 50,000, is presumably something to write home about ( sorry, Wikinews). Jc86035 ( talk) 19:19, 6 April 2019 (UTC)

If the Alexa rank is notable, put it in the article body. We don't need them in every website infobox, IMO. Kaldari ( talk) 19:40, 6 April 2019 (UTC)

In the comments above, Jc86035 confuses the criteria for using a source in an article with the criteria for using a source in a talk page discussion. Yes, a blog is not a reliable source for use in an article. But then again, the comments Jc86035 makes and the comments I make on article talk pages are not a reliable source for use in an article. Whether considering a link to a blog someone posts or the words we write on this page, the reader is expected to evaluate the opinion and decide whether it is a compelling argument.

Jc86035 goes on to question my assertion that anyone make the numbers as big as they want, limited only by their budget. I believe that I am correct. I could, for the princely sum of $25, buy compete control of 1,000 computers with 1,000 IP addresses on a botnet, and use them to inflate the Alexa ranking of a website. If Alexa figured out that the 1,000 computers were inflating the ranking (more likely if I used one computer a lot, far less likely if I only used each computer a handful of times) another $25 would by me a fresh set of a thousand computers. $110 would get me 5,000 computers/IPs and $200 would get me 10,000 computers/IPs. It really is that easy, which is why so many people sell pageviews and visitors.

DO NOT VISIT THE FOLLOWING LINKS!! ONE LINK IS CLICKBAIT AND THE OTHER MAKES FUN OF CLICKBAIT!! Don't Click Me #1 Don't Click Me #2 Don't say that I didn't warn you. -- Guy Macon ( talk) 21:11, 6 April 2019 (UTC)

@ Guy Macon: Thanks for your response. I don't think I was confusing the criteria – to my knowledge, there are no established criteria for collecting anecdotal evidence on talk pages(...?), so I wouldn't have been able to confuse them – though I thought it was worth noting whether they would pass as reliable sources.

Returning to the actual purpose of the discussion, I agree that the statistics are far from perfect due to being proprietary and being apparently easy to manipulate. However, I think this would be grounds for establishing minimum criteria for those statistics' use in articles (e.g. something like "at least two data sources ranked the website at 175,000 or above in the past year, or at the website's peak if the website is currently defunct"), rather than disallowing those statistics altogether. We can presume that it's harder to fake higher ranks, and I think it's somewhat more unlikely that already-notable entities would be deliberately inflating their own website usage in this way. Jc86035 ( talk) 15:53, 7 April 2019 (UTC)

• I would oppose all use of Alexa ranks -- but, it would be pointless. O3000 ( talk) 21:19, 6 April 2019 (UTC)
• Kill Alexa ranks in infoboxes. It may be useful in very very specific cases, but in general this is pretty much a factoid. That a site is ranked 3543rd or 2561st or 8234th on a given day is useless, as it its increase/decreased from some some point in the past. I've been debating to make this proposal myself for a while, but I'm glad someone took the initiative to remove this unencyclopedic stuff on a larger scale. Headbomb { t · c · p · b} 14:44, 17 April 2019 (UTC)
• Can someone who cares about this issue turn this into an actual WP:RfC so proper notice is given, with an actionable outcome? (Also, list at CENT) Alanscottwalker ( talk) 14:53, 17 April 2019 (UTC)
• While that is pending, this is as relevant as votes in an election, or runs made in baseball games, or rankings of teams in a league, or revenue of films, or NYT bestseller rank of books, or any other figure in the world that is determined in a particular way according to particular conventions, and considered important by those in the field. For many of these, it may be too complicated to give in an infobox, especially if we have data over a periods of time. But i still should be given, and I'd suggest much less of this go in infoboxes and more in tables in the articles. But it belongs in he WP, because we report the real world.

There are objections that some of this data may be inflated, or otherwise inaccurate--and this is true for all statistical data whatsoever. That doesn't mean we do no give it. (If the next US census ends up undercounting because of a political decision about what questions to ask, we still give the values. So people can interpret them we discuss them in our atricles on the data sources in question--the rules of baseball, the article on the nyt bestseller list, or on the census, -- or on alexa. We do not decide what ought to be important in the world, and write our aricles as if that were the case. DGG ( talk ) 00:41, 29 April 2019 (UTC)

Re: "There are objections that some of this data may be inflated, or otherwise inaccurate--and this is true for all statistical data whatsoever" there is a basic difference in play here. Anyone with a credit card can get their Alexa rank as high as they want, limited only by how much they are willing to spend. The same is not true of votes in an election, runs made in baseball games, rankings of teams in a league, or revenue of films. I could, for the princely sum of $25, buy complete control of 1,000 computers with 1,000 different IP addresses on a botnet, and use them to inflate the Alexa ranking of a website. If Alexa figured out that the 1,000 computers were inflating the ranking (more likely if I use one computer a lot, far less likely if I only use each computer a handful of times) another $25 would by me a fresh set of a thousand computers/IPs. $110 would get me 5,000 computers/IPs and $200 would get me 10,000 computers/IPs. It really is that easy, which is why so many people sell pageviews, visitors, likes, upvotes, etc. online. And the more popular services actually do deliver the Alexa ranks they promise. -- Guy Macon ( talk) 07:28, 6 May 2019 (UTC)

@ Guy Macon: We do still include the results of rigged elections, and we do catalogue the subscriber numbers of several hundred YouTubers, as well as several lists of Internet statistics.

We don't know how effective the ranking manipulation services are, whether any Wikipedia-notable websites would even use them, or whether Alexa and other companies do anything about this manipulation. On the other hand, if a website manages to get a really high ranking because of a botnet, researchers might find out about that because of the botnet itself, and the manipulation still doesn't result in the ranks for other websites being substantially more inaccurate (a website that would otherwise be ranked e.g. 1,268 would just be at 1,269 or 1,270). It's telling that it takes hundreds of millions of hijacked systems (i.e. an entire botnet) to get a rank that high.

We do anecdotally know that the ranks are only estimates and are only a little more accurate than the order of magnitude, but maybe that's enough (especially if there isn't any similar data that's much better). Given that what we include in articles is dependent on reliable sources, and multiple reliable sources have used this sort of data, maybe we shouldn't be putting too much emphasis on the anecdotes. Jc86035 ( talk) 16:30, 12 May 2019 (UTC)

• Kill Alexa ranking is a constantly-in-flux value with no quantifiable meaning, and can easily be influenced with a bit of money or a sockpuppet farm. MoonyTheDwarf (Braden N.) ( talk) 16:54, 13 May 2019 (UTC)

An RfC has been opened at Wikipedia talk:Notability (academics)#RfC about independent sources for academic notability to decide the following question:

Current wording: Academics/professors meeting any one of the following conditions, as substantiated through reliable sources, are notable.
Proposed wording: Academics/professors meeting one or more of the following conditions, as substantiated using multiple published, reliable, secondary sources which are independent of the subject and each other, are notable.

Shall the wording in the section Wikipedia:Notability (academics)#Criteria be changed to the proposed wording above?

Editors are welcome to join the discussion. -- Netoholic @ 20:14, 7 May 2019 (UTC)

The RfC has been closed with clear consensus against it. Xxanthippe ( talk) 23:11, 16 May 2019 (UTC).

There is a request for comment about the italicization of the names of websites in citations and references at Help talk:Citation Style 1/Archive 72#Italics of websites in citations and references – request for comment. Please contribute.  SchreiberBike |  ⌨  04:57, 18 May 2019 (UTC)

The Wikimedia Foundation has invited the various Wikimedia communities, including the English Wikipedia, to participate in a consultation on improving communication methods within the Wikimedia projects.

Phase 2 of the consultation has now begun; as such, a request for comment has been created at Wikipedia:Talk pages consultation 2019/Phase 2. All users are invited to express their views. Individual WikiProjects, user groups and other communities may also consider creating their own requests for comment; instructions are at mw:Talk pages consultation 2019/Participant group sign-up. (To keep discussion in one place, please don't reply to this comment.) Jc86035 ( talk) 14:48, 18 May 2019 (UTC)

Currently, the rule for COI is as follows:

Editors with a COI, including paid editors, are expected to disclose it whenever they seek to change an affected article's content. Anyone editing for pay must disclose who is paying them, who the client is, and any other relevant affiliation; this is a requirement of the Wikimedia Foundation. Also, COI editors should not edit affected articles directly, but propose changes on article talk pages instead.

I was looking recently at requested edits, and found on Axios (website) a requested edit by a COI editor that had resulted in a sprawling discussion on rules lawyering, whitewashing, and whether or not a specific website should be cited. Looking further into the issue, the user at question has a history of being a WP:LAWYER to get changes made for their clients. The Huffington Post article being debated on the talk page discussed the user's misuse of petitioning users on their talk pages to chime in in that editor's favor. Looking personally into that user's history (leaving the debatable Huffington Post article aside), I found that the user's talk page history is full of deletions, and the user's contributions is full of messages added to other user's talk pages to obtain support for their rules mongering.

This is not to point fingers at one specific user, though I believe that user is a problem, but rather to point at the general hole in WP policy that allows this to occur. COI is bad, but lawyering 'in the rules' COI is insidious. The success of this one particular user at doing what they do indicates to me a system that needs repairing.

I propose that there needs to be editing to the COI policy to prevent this kind of rules lawyering. Thoughts?

(This is my first time posting here, so I apologize if I did anything wrong. Advice and feedback is of course welcome.) -- Nerd1a4i ( talk) 20:08, 19 May 2019 (UTC)

Well, if memory serves this incident was discussed at WP:AN a while ago and it was conclusively found to not be an instance of rules lawyering. Jo-Jo Eumerus ( talk, contributions) 20:47, 19 May 2019 (UTC)

@ Jo-Jo Eumerus I'd be interested to see a link to that, but regardless, that proves my point precisely: what this person is doing is within the rules, but I'd argue it's detrimental, and that the rules need to be changed to prevent it. -- Nerd1a4i ( talk) 21:15, 19 May 2019 (UTC)

Link to summary "closure", but the full discussion is at the parent section. -  Paul ^{T +}/ _C 22:50, 19 May 2019 (UTC)

Psantora Thank you for linking that. Reading through that discussion only further indicated to me how the rules here need to be rejiggered...the talk page for Axios (website) includes the user claiming that the 'close' there supports him, while really it's just saying that that space is not the right one for discussing banning paid editing. There need to be at minimum further limitations upon paid editors, if they are not banned outright. -- Nerd1a4i ( talk) 01:47, 20 May 2019 (UTC)

If that is what you think, then follow the summary's directions: the suggestion that those who wish to see a change in policy initiate a RFC as described on WP:PAID and not have such conversations at AN where many editors will not see it. I don't think it needs to be brought up again here. As an aside, can you please point to what you mean by the talk page for Axios (website) includes the user claiming that the 'close' there supports him, while really it's just saying that that space is not the right one for discussing banning paid editing? -  Paul ^{T +}/ _C 18:36, 20 May 2019 (UTC)

Psantora The direct quote is "Namely, an independent admin, User:SoWhy, summed up the consensus of the Admin Noticeboard as 'a) the article was written by someone who has no idea how Wikipedia works and b) the editor mentioned in said article has not violated any policies or ToU.'" Just doing ctrl-F for "SoWhy" finds the comment. And also, sure, I'll start the discussion at the right spot. Apologies. -- Nerd1a4i ( talk) 22:54, 20 May 2019 (UTC)

That is (accurately) directly quoted from Wikipedia:Administrators' noticeboard/Requests for closure/Archive 28#Wikipedia:Administrators' noticeboard#HuffPost article on WP COI editing. Also, it looks like there already is an RFC at Talk:Axios (website)#RfC: Paid Wikipedia editing, though I don't think it follows the instructions at WP:PAID for changing that particular policy "with legal considerations" and looks to only apply to the article in question. Anyway, just something to think about. Thanks for the quote. -  Paul ^{T +}/ _C 01:25, 21 May 2019 (UTC) Actually, now that I just checked, the quote is also directly from the summary "closure". Not sure how I missed that. -  Paul ^{T +}/ _C 01:28, 21 May 2019 (UTC)

Hello. With FileImporter now live for some time, are there any plans to discontinue the use of all older manual file transfer methods (i.e. download from Enwiki and reupload to Commons)? I couldn't find any related discussions, and was surprised the switch hasn't been made yet. It seems the old download-and-reupload methods are still very much used, and we're loosing a great deal of valuable file history in the process. Reh man 04:07, 29 May 2019 (UTC)

I understand your point, but how would you "discontinue" manual uploads since it's a thing people do rather than a button you can "take away"? You can update instructions and help pages and/or make a "transfer with FileImporter" option more obvious/available at file description pages when it's appropriate (by this I mean that having such an option on non-free files etc. could potentially encourage chaos) but I don't really see how you can prevent it. You can make attempts to educate people who have made poor transfers - some people do an awful job of preserving information, but not all, and if someone is doing the job manually (or semi-automatically) and well then that seems ok. I've always personally used c:COM:FtCG, which seems to do a pretty good job, although I'm not a big "transferrer", I tend to upload new files or work on existing ones/derivatives. -- Begoon 04:22, 29 May 2019 (UTC)

Thanks for the feedback, Begoon. I will be bold and add the extension as the preferred and recommended method of transfer. The gadget is available to every user in preferences, and is far more efficient in transferring and preserving history. It also allows to make changes prior to saving on Commons. If there are any concerns, I'm sure someone would reach back. Reh man 11:11, 29 May 2019 (UTC)

The extension which you are speaking of is still in beta testing. Killiondude ( talk) 04:25, 29 May 2019 (UTC)

Thanks for the feedback, Killiondude. I didn't notice the small text mentioning release status. It is probably the reason no serious effort is put into discouraging other transfer methods. Reh man 11:11, 29 May 2019 (UTC)

It's worth re-emphasising that we probably don't want to be encouraging the use of this tool without making the pitfalls very clear. While many files on en-wiki were genuinely uploaded here in error when they should have been uploaded to Commons, many more were uploaded locally for good reason (generally a clash between US and county-of-origin copyright law); what we definitely don't want is to create a situation where a good faith newcomer thinks they're being helpful by moving files across, and ends up banned both from Commons for uploading copyright violations, and from en-wiki for disruption. ‑  Iridescent 11:19, 29 May 2019 (UTC)

Hello Iridescent. Just to be clear, this post is not about what file should or shouldn't be transferred, but instead about the preferred tool to use for those that should be transferred. Reh man 12:13, 29 May 2019 (UTC)

I get that, but if we put a big red "TRANSFER THIS FILE TO COMMONS" button on locally-hosted files, there's a risk people will be tempted to use it in a good faith attempt to be helpful. It's exactly the same reason Commons intentionally make it difficult to find the basic upload form if you're not experienced enough to understand what you're doing, and instead have the "Upload file" button default automatically to Special:UploadWizard which forcibly walks you through all the non-free-content pitfalls and gives multiple opportunities to change your mind. ‑  Iridescent 12:38, 29 May 2019 (UTC)

Iridescent, sorry, but your response is still entirely unrelated. The post has never been about advertising to transfer files to Commons. But simply, to restrict the tools available to a user who already chose to transfer a file. It is more of a back-end thing, if you want to put it that way. Majority of the transfers that are being done currently are loosing a lot of valuable history, that is what I am trying to resolve. Reh man 13:52, 29 May 2019 (UTC)

@ Rehman: I'm a bit lost here? Which policy or guideline are you proposing we change? Nothing we do will prevent anyone from downloading files, and nothing we do has any impact on what is going on over at commons. As far as the "FileExporter" beta feature - well it's beta, once it gets promoted out of beta there may be consideration if it is 'opt in' or 'opt out'. Is there a different gadget you want to have changed as well? — xaosflux ^Talk 14:15, 29 May 2019 (UTC)

Hello. Xaosflux, I am looking forward to thoughts about removing links to older transfer methods, and encouraging the use of FileExporter (even though it is currently in beta). This is not really a formal proposal as such, but a discussion to see the pros and cons of it. FileExporter not only correctly preserves the file history through contributors' global accounts (other tools does not), it also has inbuilt features to prevent fair use/posters and other incompatible content being transferred, including blocking transfers based on the use of certain templates. Even though it is in beta, there are very few known issues, and the tool is far superior to the ones mentioned/promoted in most places. FileExporter also logs actions.

• An example result of current transfer methods (note the file history - including deleted): en:File:Wroclaw uniwersytet.jpg vs Commons:File:(7) Wroclaw uniwersytet.jpg.
• An example result of FileExporter (note the file history - including deleted): en:File:Tidalenergyturbine.jpg vs Commons:File:Tidalenergyturbine.jpg.

-- Reh man 03:29, 30 May 2019 (UTC)

@ Rehman: thanks for the note, regarding "removing links to older transfer methods" can you be very specific? (e.g. Change MediaWiki:SomeMessagePage to remove "this text") ? — xaosflux ^Talk 03:35, 30 May 2019 (UTC)

Xaosflux, to remove non-FileExporter entries and manual instructions at Wikipedia:Moving files to Commons#Tools (and any other places, if they exist). I initially also wanted to remove the direct CommonsHelper manual transfer links in {{ Copy to Wikimedia Commons}}, but it seems like those have already been rightfully removed in 2017 by Fastily. Reh man 03:52, 30 May 2019 (UTC)

I wouldn't think removing working options from Wikipedia:Moving_files_to_Commons#Tools is a good idea, but feel free to add more columns, and even add some prose to that section on the benefits of FileExporter. From a commons' perspective (where I assume you are wanting to fix a "problem", because this isn't an enwiki problem) I'm not thinking that a lot of commons uploaders are causing this problem because we have a list of tools. — xaosflux ^Talk 14:38, 30 May 2019 (UTC)

It's not a "problem" as such, but more of a serious quality issue. As you probably saw in the examples, old forms of transfers looses a lot of valuable/historic data, that could have otherwise been preserved by FileExplorer. IMO, it is more related to enwiki as we are loosing the data in the process. I will leave this thread open for more thoughts, and will eventually update the page in a couple of days, in the way you suggested. Thank you! Reh man 14:52, 30 May 2019 (UTC)

Is there any established convention on when to use terms like "British" versus terms like "Welsh", "English", or "Scottish" when describing various entities related to the UK, like people, organizations, etc? Thanks!-- Jayron 32 14:14, 30 May 2019 (UTC)

There's a sort-of essay which is a sort-of convention: WP:UKNATIONALS. I'll just say it can be tricky sometimes. -- zzuuzz ^(talk) 14:25, 30 May 2019 (UTC)

As per zzuuzz above. The image on the right image probably best explains it. And the nationalists (all five entities) don't help.

- X201 ( talk) 14:36, 30 May 2019 (UTC)

Do you realise what a can of worms you are opening up there? For a start many people in Northern Ireland define themselves as British and many as Irish and many as Northern Irish. For organizations/organisations it's sometimes fairly simple to make the distinction on the basis of whether they operate in the whole of the UK or in part(s) of it, but for people it's a very difficult distinction to make. If I'm taking to an Argentinian I will probably say that I am British, but if I'm talking to someone from Wales I will probably say that I am English. In everyday life most people rely on muddling through in this way rather than think too much about how much they identify with a particular entity. A good example of this is that when Andy Murray is winning English people tend to say that he is British, but if he is losing we say he is Scottish. I doubt if you will get a much straighter answer here than "it depends". Phil Bridger ( talk) 17:49, 30 May 2019 (UTC)

Businesses aren't straightforward. They can be registered in England or Scotland and operate in either or both. And after that they may choose to be referred to as Engl/Scot/Brit - ish. - X201 ( talk) 08:37, 31 May 2019 (UTC)

I said that it's sometimes a simple matter, which is far from always. I wasn't thinking about businesses, but more about organi[s/z]ations in fields such as sport and politics, where the UK and Ireland are divided up in different ways. In football there are five separate national teams for England, Scotland, Wales and the two parts of Ireland, in rugby union England, Scotland and Wales have their separate teams but Ireland has a unified team, in cricket England and Wales have a unified team, Scotland has its own team and Ireland has a unified team, in the Olympics there is a unified team for the United Kingdom of Great Britain and Northern Ireland and one for the Republic of Ireland, and I could go on. In politics the Republic of Ireland obviously has its own parliament, there is a United Kingdom parliament, a Scottish parliament and assemblies for Wales and Northern Ireland, but no body specifically for England. All of these can be described as they are, but in general for businesses, people etc., the whole matter is, as I said, a can of worms that is best not opened. Phil Bridger ( talk) 17:32, 31 May 2019 (UTC)

How authoritative is WP:Basic copyediting when it states: "The month, day, year style of writing dates requires a comma after the year, e.g. On September 15, 1947, she began her first year at Harvard"? I ask because recently I discovered an IP ( Special:Contributions/137.187.235.102) that was doing just the opposite in dozens of articles. Their arguably good faith contributions look to have been confused as vandalism and rolled back.

[10] [11] [12] [13] [14] [15]

Regards, Guywan ( talk) 11:50, 17 May 2019 (UTC)

I think it's very authoritative, especially since the final comma would be there to mark the end of an introductory phrase, even if the year weren't somewhat oddly treated similarly to how an unrestrictive appositive would be (compare how "On 15 September 1947" would be treated). Dhtwiki ( talk) 20:49, 17 May 2019 (UTC)

@ Guywan: The more "authoritative" source would be MOS:DATEFORMAT. 142.160.89.97 ( talk) 07:44, 1 June 2019 (UTC)

Thanks, BoN. I overlooked that. (^_^.) Guywan ( talk) 11:00, 1 June 2019 (UTC)

WP:CCI currently includes the text After submitting a case, please notify the contributor by adding {{subst:CCI-notice}} ~~~~ to the bottom of their talk page. It is not necessary to notify individuals who are currently blocked for copyright infringement, even if temporarily.

Saying "Please do X" doesn't necessarily imply a policy requirement so much as an option courtesy, in my reading, but saying that it is "not necessary to notify individuals who are currently blocked" would seem to imply that it is necessary to notify those who are not. However, if it were like AN/ANI/ANEW I get the impression that it would be a lot clearer than that and explicitly say you must notify the reported user; my understanding is that the difference is that those fora are for requesting sanctions, while CCI is just about cleaning up copyright problems. If my interpretation is correct, then there is no requirement to notify CCI reportees, but rather it is an optional courtesy. Given how apparently obscure CCI is (the backlog is massive, and not receiving much attention) I get the impression that no broader community discussion has been held over whether there is a requirement to notify the reported user(s) or not, so I brought it here.

(This is not related to either of the currently open reports there that were filed by me over the last several months.)

Hijiri 88 ( 聖 やや) 09:02, 29 May 2019 (UTC)

• It seems reasonable, but the "no need to" section should probably be expanded, if not to all blocks (could cause issues with a short 3RR) then at least indefs Nosebagbear ( talk) 09:23, 29 May 2019 (UTC)

Hijiri 88, you are incorrect in thinking that "please" means that a behavior is optional. "Please" means that we're polite and relatively formal. Imagine a police officer saying to you, "Sir, please get out of your vehicle". Do you really think that's an optional instruction? WhatamIdoing ( talk) 05:00, 3 June 2019 (UTC)

Umm... no... I took it as meaning exactly what you say it does (as indicated by my own action taken at around the same time as posting the above -- I took a whole lot of shit for doing so, but that's beside the point); what I mean is that it should be an optional courtesy, and if it is in fact something "you must" do (to quote the edit notice on ANI) it should probably say as much. Your explanation doesn't explain why ANI is not "polite and relatively formal". Hijiri 88 ( 聖 やや) 05:25, 3 June 2019 (UTC)

• It should not be an optional courtesy, and I recommend changing the word "please" to "you must." "Please" is more collegial but will be read as "you don't have to do it" by users who don't want to do it. SportingFlyer T· C 07:00, 3 June 2019 (UTC)

Yeah, but what about those who forget? I first heard of CCI because I posted about an issue on ANI, an admin told me to file a CCI, and I went ahead and did on the fly (I was in a rush) exactly as I had been told to rather than how the relatively-difficult-to-read prose instructions half-way down the page said to (and I had already notified the subject of the ANI thread anyway, and given plenty of advance warning before that). The reason we require notifications for AN, ANI, etc. is to allow editors to defend themselves from block/ban requests, but CCI is just meant to establish whether content needs to be cleaned up, and if so to facilitate such. I'm generally opposed to blanket-requiring notifications for cases like this (@ SportingFlyer: How do you feel about WP:SPI, which actually discourages notifications unless specifically deemed necessary?), but if we are going to do so then an edit notice should be added similar to AN, ANI, etc. Hijiri 88 ( 聖 やや) 07:31, 3 June 2019 (UTC)

It needs to be fixed so it is clear, or, more specifically, there needs to be an RfC to gain consensus to fix it. The "no other requirements" along with the word "please" on the notification don't make it clear the user should be notified. CCI is meant to address copyright problems with specific users - there are other forums for other copyright issues, and the goal of CCI is to clean up the content and inform the user they may be committing "large-scale, systemic" violations. If a user is already blocked for copyright infringement, they should already aware of this. But CCI, while rarely used, is also very serious. "I forgot because I was in a hurry" isn't a great look. (Also, the SPI's a red herring. Not every user needs to be notified every time they're under some sort of investigation.) SportingFlyer T· C 08:26, 3 June 2019 (UTC)

and inform the user they may be committing "large-scale, systemic" violations Well, if that's what you meant, then I think it would need to be dealt with on a case-by-case basis anyway. I've filed three CCIs, and in all three cases the subject had already been made well aware of the problem on their talk page, so a notification with that specific purpose would be just as redundant as a notification to an already-blocked user. I would not be opposed to a requirement to notify editors who may not already be aware that they are violating copyright, but if I had to put a number on it I'd say any more than two messages specifically addressing the copyright concerns in question should be enough to say "already aware". Hijiri 88 ( 聖 やや) 09:41, 3 June 2019 (UTC)

As a result of the recent North Face COI editing controversy, a lot of attention is being paid to how to describe the incident on The North Face's page. Any views specifically on that situation should be directed there, so as to keep the discussion in one place, but I want to bring one question raised by that discussion here to see about establishing a broader consensus. The North Face is a start class article, and many sections are pretty bare-bones, so as a result, any mention of the controversy in any amount of detail will take up a significant portion of the article. This has led some editors to argue that it would be WP:UNDUE. Others, however, contend that, were the article fully developed, spending a paragraph on the controversy would not take up a huge amount of space proportionally and would probably be fine, and that the article won't become more fully developed unless we allow additions, even if it temporarily leads to some unbalance. So: To violate WP:UNDUE, does content need to be undue with regard to the current state of an article, or does it need to be undue with regard to what the article is expected to become once it is fully developed? Any thoughts on this would be appreciated! (I do realize it's in some ways a proxy for the whole WP:Immediatism/ WP:Eventualism debate.) Thanks, Sdkb ( talk) 21:10, 3 June 2019 (UTC)

While I cited UNDUE in that discussion the issue at play there is really WP:PROPORTION (aka the first subsection of Due weight). That argues for particular caution for events in the news as in that article. The more eyeballs that are on an article the more important it is, in my opinion, that we get it right in the moment. I am on the "current state of an article" side of things but also think that in most situations it's not a big deal and we should defer to the enventualism side of things. In most cases it's only when it's absurdly long (e.g. overly long plot summaries), is getting regular attention, or is up for some sort of article status (e.g GA, A class, FA) that we need to be at our best about UNDUE coverage.. Best, Barkeep49 ( talk) 00:41, 4 June 2019 (UTC)

I've raised this before...twice, but the first time was 7 years ago in reference to my first ever attempted article. I imagine it failed for several (numerous?) reasons, but on being told to instead merge it into a pre-existing article, its watchlisted editors raised concerns about UNDUE - and I raised them at the Help Desk, to which I got a "meh, we don't know a clear answer"-esk response. Moving on, it's a worthwhile issue to discuss. I find it unfair that (if UNDUE is in effect) an editor is stuck with a choice: Increase the rest of the article to avoid UNDUE, potentially requiring a 4x increase, or truncate large amounts of relevant detail. That then leads to a second question - do we prefer to avoid unfairness to our editors or a misbalance of article content? Nosebagbear ( talk) 09:36, 4 June 2019 (UTC)

• To avoid UNDUE, I would lean towards more Summary and less Detail when it comes to adding material on recent events. Blueboar ( talk) 12:18, 4 June 2019 (UTC)

Is there a blanket policy that states whether to use "U.S." or "American" in disambiguators when referring to a subject that has an affinity to the United States? Asking since I'm beginning to run across some issues pertaining to disambiguating article titles about people (Example: "U.S. politician" vs. "American politician"). If I recall, for a while, the titles of television series articles ( WP:NCTV) were instructed to use "U.S. TV series" as opposed to "American TV series", but it seems that recently changed ... even though the talk page of WP:NCTV shows that there was not consensus to move some titles away from their "U.S. TV series" disambiguator titles. So, back to my initial question now that I've gotten that preamble out of the way ... Does a policy exist that specifically states to use either "U.S. (subject)" or "American (subject)" in disambiguators? Steel1943 ( talk) 05:26, 30 May 2019 (UTC)

• Not sure where you see that there was no consensus at WP:NCTV as this RfC closed with one. -- Gonnym ( talk) 06:07, 30 May 2019 (UTC)
  • @ Gonnym: I think I may have mistaken seeing "U.S." vs. "animated" as disambiguators. But either way, the articles mentioned in Wikipedia talk:Naming conventions (television)#On "by country" being the "preferred" disambiguation under NCTV are currently at "U.S. TV series" disambiguators, rather than the "American TV series" disambiguator recommended at WP:NCTVUS ...which itself adds a bit of confusion. Steel1943 ( talk) 07:07, 30 May 2019 (UTC)
    • None of the pages have yet to be moved, but a bot operation has been approved to move them and hopefully will be running soon. -- Gonnym ( talk) 07:10, 30 May 2019 (UTC)
• We don't have a blanket policy, but if one is to be made it should reflect that (American ---) be used for people as a demonym, but (U.S. ---) be used for non-persons (newspapers, films, TV series, organizations, etc.) to reflect the actual name of the country of location or origin. -- Netoholic @ 06:53, 30 May 2019 (UTC)
• Although not related to disambiguators some category trees mix French, German, Dutch etc and then use United States rather than American so a wider issue as to how United States/American is used. MilborneOne ( talk) 07:22, 30 May 2019 (UTC)
• No, we don’t have a policy on this... nor do we need one. The goal of disambiguation is to separate subjects with the same name, not to group subjects together ... so there is no need for the terms used as disambiguators to be consistent between subjects. Blueboar ( talk) 14:05, 30 May 2019 (UTC)
  • I disagree that we don't need some sort of streamlined process, but comments like this give me an idea how I would need to formulate an RfC if I ever create one for this issue. Steel1943 ( talk) 20:14, 30 May 2019 (UTC)
• Unless there's some context that makes the other option better, I would prefer "American" as it avoids the U.S. vs US debate. — pythoncoder ( talk |  contribs) 21:15, 2 June 2019 (UTC)
  • Part of the issue is that "American", while usually referring to the United States, can also just refer to the Americas as a whole. Referring to something as "US" avoids that issue, while adding the issue that it can be "U.S." or "US". Rockstone talk to me! 21:54, 5 June 2019 (UTC)

Hey, all,

I'm posting this query on the policy page because I have a general question. I am currently deleting hundreds of redirects to deleted pages. Almost all of them are redirects from editors' sandboxes to deleted draft pages. In doing this, I have noticed that there are some editors who task themselves with moving drafts out of editors' sandbox and into Draftspace. I understand that this is the area where people now generally work on draft articles but, as far as I know, we are still telling new editors to start work on articles in their own sandboxes. This seems silly if, as soon as the editor goes inactive, we move their works into Draft space.

If this is the new policy (or has just become the new custom), I think we should state this in new editor information and get the word out because many editors are still telling newbies to create articles in their sandboxes. I guess we should skip this step and tell them to put their new work in Draft space instead. I imagine this would involve changing the welcome templates we post and also getting the Help desk and Teahouse on board.

What do you think? I can't imagine the hours of time some folks have spent moving all of these pages over when the new editors could just have been started in the Draft space instead. Just a colossal amount of unnecessary extra time and work to move pages when they could have been in the space to begin with. Liz ^{Read! Talk!} 22:57, 1 June 2019 (UTC)

I vaguely remember there being some discussion about moving user drafts into the draft namespace not too long ago but can't for the life of me remember where. If I remember this correctly though it was somewhat contentious. Some saw moving userspace drafts into draft space as a way of gaming WP:G13. I'd hesitate to say there's a firm consensus on it, but if someone knows the discussion I'm thinking of it might help you some. Wugapodes [t^hɑk] [ˈkan.ˌʧɹɪbz] 21:37, 2 June 2019 (UTC)

Liz, I think that some of this happens when people submit their userspace pages to AFC. If so, then that ought to be visible (to admins) in the history of the since-deleted page. If there are systematic efforts to do this outside of the AFC process, then perhaps the individuals in question should be encouraged to stop it. WhatamIdoing ( talk) 05:11, 3 June 2019 (UTC)

This is generally an AfC process - the sandbox is the first thing new editors who immediately want to create an article come across. Hunting down how to make a draft is quite tricky until you gain a little information (whether by welcome or being otherwise pointed). The article wizard converts them to drafts in the process of submitting to AfC. Can you imagine the effort (and intensive pointlessness) of doing so, just to employ G13? I don't know if accepting an AfC draft terminates the original redirect, but in any case the number will be spiking up because of the AfC backlog. Nosebagbear ( talk) 12:20, 3 June 2019 (UTC)

Some editors will, on WEBHOST grounds, move stuff out of userspace and into draftspace so it can be G13 regardless of whether the article was submitted or not (and sometimes regardless of whether it had the AfC tag or not). I know one editor who is not currently active who regularly did this. This bothers me and here is a practical piece that such editors should hopefully consider when doing such moves (if any are still currently doing them). Best, Barkeep49 ( talk) 00:45, 4 June 2019 (UTC)

My recollection of the discussion Wugapodes refers to is that one of the reasons given for creating new articles in the userspace rather than the draftspace or mainspace is to keep them out of the hands of AfC. Hawkeye7 (discuss) 02:27, 4 June 2019 (UTC)

@ Hawkeye: - What do you mean "out of the hands of AfC" - we neither chase down non-submitted drafts for G13s or look for non-submitted drafts to be added. I've only heard of 1 or 2 cases of anyone (who hadn't created it or been drawn to it) finding a draft and deciding to submit it. Nosebagbear ( talk) 12:00, 4 June 2019 (UTC)

Nosebagbear, Who is the "we" in that statement? There was definitely at least one editor who had been doing exactly that. In looking over the last 1500 moves it doesn't appear to still be happening currently which is good. Longstory short I don't think we, collectively as Wikipedians, should that. I think there's nothing wrong with new or experienced editors creating drafts in their sandboxes. Best, Barkeep49 ( talk) 16:23, 4 June 2019 (UTC)

Barkeep49 - it was we in the sense of reviewers, or at least in the general sense of reviewers - bizarre behaviour and incompetence are hardly unheard of (not to mention several recently being disbarred for being paid editor lying scum). I've absolutely nothing against where editors make their proto-work - it would be the height of hypocrisy if nothing else. My point purely related to the redirect aspect of the discussion. Nosebagbear ( talk) 17:32, 4 June 2019 (UTC)

I see nothing wrong with starting articles in a user subpage, as long as it doesn't get ridiculous and the editor remains reasonably active. I do it all the time. When the page is in good enough shape to be called a draft, I move it to draftspace. Sometimes I just build it up to sufficient quality to move to article space, and move it to article space. bd2412 T 17:44, 4 June 2019 (UTC)

I'm not seeing any policy issues here. The way I like it is: if you want to draft a new article "by yourself" you should use a user sandbox - if you want your draft to be open to collaboration, use draft space. I don't see a lot of utility in bothering to delete usersandboxes that are redirects to deleted pages. In fact if it someones primary usersandbox (e.g. User:Foo/sandbox as opposed to User:Foo/SomeArticleTitle) the deletion may not be needed at all, just blank it - or just leave it alone, its not hurting anything right? — xaosflux ^Talk 20:16, 4 June 2019 (UTC)

Well, I think Barkeep49 is getting at my concern. There are a few editors who spend a lot of time moving old drafts from sandboxes to Draft space where, because most of the editors are not currently active, the drafts get deleted after 6 months. Since I'm in the position of deleting the red link redirects from user sandboxes to the deleted Draft pages, my concern (although admittedly a remote possibility) is that an editor returns to work on a draft in their sandbox and--poof!--it is gone and they don't know what happened to it. They can look at the page log and see that the page was moved but I think most new editors might not even know that a draft restoration was possible. Not every admin who deletes drafts sends a G13 message to the content creator. I think we overestimate the facility of new editors with the maze of policies and procedures that are involved with editing on Wikipedia.

First, we are talking about thousands of sandbox drafts that are being moved. And even if only a few dozen would result in viable articles, it's still a loss. I think regular editors can be blase about the frustrations of new editors but, as I see it, because of retirements, deaths and unfortunate blocks, Wikipedia must rely on a regular influx of new editors if this project is going to be around in another 18 years. That's my concern. Anything that squashes the work of new or infrequent editors is a minus (given the exceptions of spam, copyright violations and other unacceptable content). </soapbox> Any way, I've stated my concern, if there isn't an impetus to do something about it (and I'm not sure what that would be), then I have said my peace and go back to my regular work. Liz ^{Read! Talk!} 01:21, 6 June 2019 (UTC)

I did have an article I was working on suddenly moved to the draftspace. Our specific problem at Wikipedia:WikiProject Olympics was that large numbers of articles on athletes are created in advance of the games. Many are already notable, but some will only become so when they actually become Olympians. Waiting until then to write the articles means that they will not be available when they are wanted most. The articles are therefore held in user space until the games begin. Hawkeye7 (discuss) 02:25, 6 June 2019 (UTC)

This page published by Shutterstock, Inc. says:

216 centaurus constellation stock photos, vectors, and illustrations are available royalty-free.

And below that, many images are seen. Can these be used in Wikipedia articles? "Royalty free" is not the same as "public domain", nor need an image be in the public domain to comply with Wikipedia's policies. Michael Hardy ( talk) 21:24, 6 June 2019 (UTC)

"Royalty free" only means you don't have to pay ongoing royalties to use them once you've bought them or paid the subscription fee or whatever; it has nothing to do with copyright. Shutterstock's terms of use specify pretty clearly that they reserve copyright over work hosted on their site and that it is not free to use. I would say you cannot use them on Wikipedia; anything you might use would very likely fail WP:NFCC#2. Ivanvector ( ^Talk/ _Edits) 21:37, 6 June 2019 (UTC)

Agreeed. See PART I – VISUAL CONTENT LICENSES, 2. RESTRICTIONS ON USE OF VISUAL CONTENT, item f:

YOU MAY NOT: Resell, redistribute, provide access to, share or transfer any Visual Content except as specifically provided herein. For example and not by way of limitation, the foregoing prohibits displaying Content as, or as part of, a "gallery" of content through which third parties may search and select from such content. Meters ( talk) 21:44, 6 June 2019 (UTC)

Definitely unusable. Same issue with the "free" allowance that Gettys uses, it fails the definition of a free license set forth by the WMF (free to redistribute and modify for any purpose including commercial). -- Masem ( t) 21:53, 6 June 2019 (UTC)

TL;DR: "rights-managed" = a restaurant where you pay for each dish, "royalty-free" = an all-you-can-eat buffet, "free content" = a collective farm. -- King of ♥ ♦ ♣ ♠ 00:14, 7 June 2019 (UTC)

There's been a lot of discussion recently about the backlogs at WP:ACC, for example here and here (where I was advised to post to VPP). At this time there are 5,417 open ACC requests going back 5 months. There are 60 registered operators of the ACC interface, and only a minority are active. Apparently, ACC currently receives about 80 account requests per day. This is not a good situation. If anyone wants to join up and help out, please do so. However I'm here to discuss a change to the wording of the advice we give to users.

Since ACC was introduced many blocks templates have been changed to advise users that if they can't edit they, "request an account be created for you". This strikes me as really bad advice for a first step solution. Their first step should not be to pile onto the volunteer backlogs, but to try and create an account using any method available to them. Although not universally true, I'll bet almost everyone has access to another IP address - some immediately, and some at a later time, but all within 5 months. I've listed a bunch of the most relevant templates at WT:ACC. I don't have the precise wording we should be using, but I'm going to suggest they get changed to 'demote' ACC to a last resort as soon as possible. Some pings: @ 1997kB, Bluerasberry, BU Rob13, Callanecc, Cymru.lass, Dane, DeltaQuad, JJMC89, Nosebagbear, Oshwah, QEDK, Stwalkerster, Swarm, and UninvitedCompany: (and apologies to anyone I've left out) -- zzuuzz ^(talk) 22:28, 25 May 2019 (UTC)

• Not that I'm particularly active at ACC, but if admins who are not CUs are making blocks of wide ranges, it may be useful to mark them as ACC ignore or simply disable the account creation block feature (or consult a CU). It depends on the case, obviously but if you're blocking a really wide mobile range or something of the sort, it's likely there is a fair amount of collateral. TonyBallioni ( talk) 22:32, 25 May 2019 (UTC)
  • What Tony mentions is one of the biggest issues I see, and have to make blocks ACC ignore so they aren't queued for that reason. I cleared out 50 requests from two ranges in the CU queue because of these types of blocks. On the other side, ACC is moving further towards automation and getting these people through a lot faster, maybe without human intervention. But this coding will still take some time to move forward. -- Amanda (aka DQ) 23:21, 25 May 2019 (UTC)
    • Indeed ACC ignore should be used far more often. However marking ACC ignore only reduces the burden on checkusers, and not the general 5-month backlog. I see reducing unnecessary input to the entire process a key step forward. Although most people probably arrive through block messages, I also get the impression that both OTRS and UTRS direct users to ACC. -- zzuuzz ^(talk) 23:34, 25 May 2019 (UTC)
      • UTRS has a wonderful template that tells school children to create accounts at home and then to use ACC if that doesn't work. Might be worth copying some language there. TonyBallioni ( talk) 23:39, 25 May 2019 (UTC)

(Sorry if I'm repeating anything already covered by others.)

• Using <!--ACC ignore--> in the block rationale will only help the ACC CU backlog but not the overall ACC backlog, but yes it should be used more. Wide range blocks or blocks where the target never uses an account should have it, especially for {{ rangeblock}}.
• In addition to not disabling account creation when blocking, block templates should direct the user to create their own account when this is the case, e.g. {{ rangeblock}}'s |create=yes. (The option needs to be used in the block rationale, not just on a talk page.)
• I'm thinking that we should create a help page to link from block templates when account creation is disabled. This page can detail using another connection and/or location to create an account with ACC as a last resort. We'd then have two options in the templates: 1) If you do not have an account: link to help page 2) If you have an account: log in.
• Referrals from OTRS and UTRS can be necessary since those tools don't show IP and UA (CU only) data like ACC does.

—  JJMC89 ( T· C) 00:20, 26 May 2019 (UTC)

UTRS does have CU data, but only provides it to CUs. -- Amanda (aka DQ) 01:58, 26 May 2019 (UTC)

• I'd love to get more people helping out with ACC (hint hint!), but it's probably also a good shout to reduce the incoming traffic until we've at least got the backlog a bit more under control. I've just been through and mostly cleared out the ACC CU queue (there's 13 requests left in it at the time of writing). I'd like to point out that the automation we're trying to bring in is for accepts only. I'm very strongly opposed to automating declines for the simple reason ACC is the backstop for when automation preventing account creations elsewhere (looking at CAPTCHAs, AntiSpoof, AbuseFilter, TitleBlacklist, etc) has failed. Most of the checks that are performed we have some form of automation in the works for checking, but everything is on a hair-trigger so if the slightest thing is found it'll still be up to a human to review. None of this is integrated into the tool yet, that's still a work in progress. stwalkerster ( talk) 00:35, 26 May 2019 (UTC)
• The problem with changing our wording on block templates is that, if we direct editors to just try another IP address, we're going to be telling some block targets how to evade their block. That's not ideal. ~ Rob₁₃ ^Talk 03:05, 26 May 2019 (UTC)

  This is indeed a valid point, and probably one of the main reasons I haven't changed the templates so far. It's probably a risk worth taking though, if the wording can be got about right. Any vandals taking this route will just get blocked again on their other network, which probably won't be a hassle. -- zzuuzz ^(talk) 14:11, 30 May 2019 (UTC)

• I've been a short-term ACC tool member (>24 hours) and long-term OTRS member and I quite agree, I think a few months ago, PrimeHunter and a few editors went out and tried to remove info-en-at-wikimedia-dot-org from seemingly unnecessary places. The general view was that it helped reduce numbers somewhat, but it wasn't enough a dent we wanted to put in the backlog. I'm not sure if all the "ACC as a last resort"s can be removed, but certainly a lot can be. We don't reference ACC much in OTRS but the one template that does refers to it as an alternative in case normal account creation is not possible. -- qedk ( t 桜 c) 04:59, 26 May 2019 (UTC)

However I believe that template could be re-written to suggest using an additional IP first. I'm not sure how much block evasion this would encourage. It might get a few more seriously basic evaders through, but anyone competent enough they'd actually cause a big enough nuisance would a) already know to use another IP first b) not use ACC and summon any additional attention. Thus minimal negatives for a slight rewrite I'd say. Nosebagbear ( talk) 10:13, 26 May 2019 (UTC)

I think wording it like "try resetting your network connection" is better, although that is some sort of poor security through obscurity tactic. More importantly, my point is how often will it actually resolve the matter and not have them send us some other ticket. -- qedk ( t 桜 c) 03:18, 27 May 2019 (UTC)

• I've been planning to help reword WP:ACC to help encourage users to create their own account if possible and then continue with a request if they're still unable to do so. With the number of requests that we receive a day, as well as the number of users that I end up noticing that eventually just create their own account after the request is made - I'm quite certain that many of these users visit the ACC page as a first resort. Just providing a short paragraph and a way to help users troubleshoot the main reasons (such as CAPTCHA not loading and emails not coming through - just make sure to turn off adblockers and check your spam folder) that they may be having trouble creating an account will (hopefully) reduce the amount of new requests. Doing this would be a win/win for us... even if it reduces the number of new requests by a small amount. ~Oshwah~ ^{(talk) (contribs)} 00:59, 27 May 2019 (UTC)
• direct users to automated options I am in favor of revising our documentation to advise users to try automated options before requesting manual review and account creation. I expect that will lessen the number of incoming requests. I continue to recognize the problem. I cannot commit to leadership in reform but I am ready to back someone else's proposals or ideas. Blue Rasberry (talk) 14:24, 28 May 2019 (UTC)
• "Direct users to try a different IP address" pretty badly fails to recognize that likely the vast majority of users would not know how or may not be able to for various reasons. We're supposed to make things easy for users who want to contribute, not make them jump through endless hoops in hopes of maybe being gifted with an account some time in the next half a year. Plus what BU Rob13 said about evasion. If we need more hands then we need more hands. I was somewhat active on the CU queue before some unpleasantness last month but never really on actually creating accounts or processing the main queue. I'll look into that when I have more time. Anyone know of a good guide? Ivanvector ( ^Talk/ _Edits) 14:22, 6 June 2019 (UTC)

  The guide is at Wikipedia:Request an account/Guide. —  JJMC89 ( T· C) 03:38, 7 June 2019 (UTC)

I have started an RFC at Wikipedia talk:Notability#Request for comment on train station notability to formally establish whether or not the often repeated claim at AFD that there is consensus that all train stations are notable actually has support. Spinning Spark 18:54, 8 June 2019 (UTC)

I know this is a borderline perennial proposal, but why is it that this doesn't exist? Stuff like Draft:Fisayor Montana are perfect candidates for non-speedy but non-discussion based deletion: apparent self-promotion based draft created by a user that goes on to sock to promote himself, would be A7 eligible in mainspace, but doesn't fit any of the G-criteria, MfD seems like a waste of effort, and keeping it around doesn't really do anyone any good.

I hate to say this, but it isn't exactly like draft space is filled with hidden gems. Most of it is crap that will never be mainspace eligible but gets a pass at CSD because we don't apply it that strictly to drafts, and no one wants to bother going through MfD for it. PROD makes sense here. I'm not proposing a formal RfC (yet), but getting views on PRODs for drafts outside the normal circles who discuss draft deletion would be useful to forming a potential proposal in my view. TonyBallioni ( talk) 05:08, 15 May 2019 (UTC)

• Support. It would be helpful to extirpate the dross at source. Xxanthippe ( talk) 05:54, 15 May 2019 (UTC).
• Support expanding the scope of PROD to cover drafts is a good idea. Reyk _YO! 06:02, 15 May 2019 (UTC)
• Oppose. Virtually all draftspace pages are virtually unwatched, and so this is a backdoor WP:NEWCSD. WP:PROD only works acceptably in mainsapce because it is assumed that all worthy pages are watched, and for the few exceptions, there are Category:Proposed deletion patrollers. The requested new CSD doesn't exist because for every draftpage that is not CSD eligible, CSG#G13 suffices. Draft:Fisayor Montana looks pretty WP:CSD#G11-eligible, so what is the point of that example? I do support WP:CSD#A11 being broadened to draftspace, with caveats, such as the author being advised of a WP:REFUND route.

It is true that most of it is crap. This is mostly because mostly only newcomers with no Wikipedia skills try to write new pages there. For all others, they learn about WP:DUD. Everyone is welcome to edit Wikipedia articles, but this should be be taken to the extension that everyone is welcome to start new topics before even becoming autoconfirmed. The probability of a newcomer arriving with a new topic that is so far un-covered anywhere in mainspace, and needs a new page *now*, and some Wikipedian is not already writing, is vanishingly small. To the extent that it is true that all draftspace pages may as well be deleted without care, it is true that all of draftspace should be shut down. The costs of running draftspace for AfC for newcomers who can't be bothered to spend four days and ten edits improving existing content far exceeds the value of the pages that come out of AfC and couldn't have been started in mainspace or userspace. -- SmokeyJoe ( talk) 06:50, 15 May 2019 (UTC)

• • Well, I disagree that the page in question met G11 which is about tone, not intent, but someone else disagreed and went ahead and deleted it. That’s unfortunate in my view because stretching G11 for cases like this just renforces the idea that it is the main/only way to deal with promo crap, which isn’t true. I also disagree with what you say about it being a new CSD; it takes 7 days and allows removal by the author. If I’m reading the rest of your comment correctly you’re arguing draft space is a failure, which I agree with, but I’m also not sure why that’s a reason to oppose this. TonyBallioni ( talk) 11:28, 15 May 2019 (UTC)
    • I didn’t see the deleted page, only the deletion log. I have supported a number of CSD expansions, but the usual opposition defeating them is that G11 serves. Can we temp-undelete the delete page? If it needs deletion, and G11 doesn’t apply, then there’s a problem needing a solution. I think a draftprod allowing the author, and effectively only the author as no one else is watching, to remove it, is not a useful way to go, because either the author will simply remove it, or the author has left to not return and there is no harm in letting it sit the six months. I also don’t like it because it is a perversion of the PROD system, which was predicated on it being used on pages that editors are watching.
      On the whole of draftspace being a failure, my problem is that this is a part solution that is far short of a solution. This is really just a comment, not the reason to oppose. I think we might be agreeing that there is a problem needing some solution.
      I think there is widespread variation in understanding of the scope of G11. I don’t agree that it is limited to tone. I think G11 is well applied to anything remotely interpreted as promotion if it is unsourced, or sourced or linking only to unsuitable sources, most typically YouTube, Facebook, LinkedIn, and the subject’s personal website. A recent discussion on differences of interpretated scope of G11 is at User talk:SmokeyJoe#Re: Wikipedia:Miscellany for deletion/Draft:Laura with me. — SmokeyJoe ( talk) 12:26, 15 May 2019 (UTC)

The worst thing about AfC and draftspace is that invites wide-eyed newcomers to start a new page, in isolation from the real community, isolated from mainspace editors with similar topic interests, and leaves them to wallow. Draftspace PROD would only make this worse. Better to not invite them to start new pages in the first place, better to tell them to improve existing content. No new worthy topic is an orphan topic. — SmokeyJoe ( talk) 22:24, 15 May 2019 (UTC)

• Neutral I support in principle, but most of the crap gets cleaned up automatically. I'm worried that becoming too deletionist in draft space could be on the WP:BITEy side. There's plenty of stuff in draft space which is fine, or which helps the writer become acquainted with our processes. I also agree there probably needs to be some way to more easily clean up pages like the one TonyBallioni identified. I don't know where I'd vote on an RfC, I'd want it to be narrowly tailored, hence my neutral stance. SportingFlyer T· C 12:42, 15 May 2019 (UTC)
• Oppose until there is evidence that there is a need to delete drafts that are not speedy deletion candidates sooner than G13 allows and that there are so many of these that MfD would be overwhelmed. Despite multiple draft prod suggestions over several years, nobody has been able to demonstrate there is a problem that draft prod would be capable of solving. Thryduulf ( talk) 16:10, 15 May 2019 (UTC)
• Oppose per WP:CREEP, CSD G13 is completely adequate to its task. I don't think we are running out of space in the Draft: namespace. UnitedStatesian ( talk) 16:14, 15 May 2019 (UTC)
• Oppose as WP:CREEP. The existing tools work well enough. -- RoySmith (talk) 16:39, 15 May 2019 (UTC)
• Comment first this is not a proposal it was trying to open a discussion about what would be an acceptable form of proposed deletion for drafts. There is literally nothing to support or propose. Second, to the CREEP point, this is the exact opposite of CREEP. It’s removing the completely unnecessary step of MfD for deleting hopeless drafts.
  Finally, RoySmith, to your point: the current CSD criteria do not work. We have a massive AFC backlog, well over 80% of which will never be mainspace ready and probably 50%+ would be A7 eligible if in mainspace. Draft space is broken and is nothing more than a dumping ground for stuff that’s going to be deleted 6 months after the author gives up on trying to write their autobiography in most cases. Having an actual discussion about making processing of drafts work in 2019 rather than in the 2005 era mindset of every byte of text being sacred is needed. Not because keeping them around is that harmful, but because it isn’t beneficial, and it takes time away from reviewers focusing on the minority of drafts that will actually become articles. TonyBallioni ( talk) 16:55, 15 May 2019 (UTC)
  • What is the benefit in deleting "hopeless" ^{[citation needed]} drafts sooner than 6 months? Specifically, how will this improve the encyclopaedia and increase editor retention? If it doesn't do both of those things then I don't really see it as something worthwhile spending any time or effort on. Thryduulf ( talk) 17:44, 15 May 2019 (UTC)
    • Thryduulf, the benefit is that it would create a painless deletion process for drafts that no one would oppose at MfD. Would provide those who work in draft space with more options, while also providing new users with more flexibility to contest deletions than creating a draft specific CSD criteria. There is zero benefit to the encyclopedia in keeping the mass of A7-quality drafts around until G13 comes along. I'd also support getting rid of draft space all together and just have people wait 4 days to create a new page as has been suggested a few times here, but I doubt that would gain consensus (and I think the PROD method would be better for saving new content, fwiw.) TonyBallioni ( talk) 19:20, 15 May 2019 (UTC)
  • I think there's a great difference between drafts that were created in draft space and then neglected, and articles that editors have chosen to move to draft space with little quality control over whether they should have been moved there in the first place, but in neither case do we need any new procedure and neither contributes to the AfC backlog unless they are submitted to AfC. My preferred solution would be to do away with draft space altogether and get back to the normal wiki process by which articles on notable subjects are developed in main space, and ones on non-notable subjects are deleted. The whole process of moving articles to draft and then speedy deleting on sight after six months is simply disruptive. I don't normally look out for such articles but I noticed Franz von Gernerth yesterday, and have seen other articles on clearly notable topics before that should never have been draftified. If the same standards are to be applied to articles in draft space as to those in main space then what is the point of draft space? Phil Bridger ( talk) 18:34, 15 May 2019 (UTC)
• Oppose - I see no evidence of any problem which must be dealt with more urgently than G13 allows and isn't covered by G10, G11 or G12. עוד מישהו Od Mishehu 13:31, 16 May 2019 (UTC)
• Oppose As there are so few watchers that a prod would go unnoticed. There is no hurry to delete the harmless material, and te harmful content gets deleted via other speedy deletion criteria anyway. Graeme Bartlett ( talk) 08:46, 18 May 2019 (UTC)
• Comment: I agree with this PROD in principle because it's always been something I thought we should probably have; while G13 is generally reserved for drafts that might have some promise but neither the creator or other editors are interested in improving. However, I'm not aware of how many drafts arrive through the Article Wizard (it would be interesting to know) and hence how many of the drafters blatantly disregard the instructions at the Article Wizard. One possible solution would be to increase ACPERM to 90/500 and deprecate AfC entirely. Kudpung กุดผึ้ง ( talk) 04:50, 19 May 2019 (UTC)
• I generally see the Draft namespace as not fit for purpose, and a draft PROD as an improvement. The main problem is that the existence of G13 virtually guarantees the deletion of a draft after six months regardless of any other considerations, it discourages evaluation of a draft before deletion. We need the deletion process to be more discerning overall: and it's a step in this direction if editors can prod the bad drafts leaving a smaller pile of stuff with higher potential for others to sort through before everything gets bulldozed after the set period of inactivity. – Uanfala (talk) 11:33, 20 May 2019 (UTC)
• Oppose as unnecessary and overly aggressive to newbies, hundreds of drafts are deleted every day through csd G13, 11 and 12 and G6 can be used for BLP violations such as bios about private people, while deletion for test edits can be used for single sentence efforts. There are many good articles in draft space that would be vulnerable to prod and give more workload to prod patrollers, thanks Atlantic306 ( talk) 19:37, 22 May 2019 (UTC)
• Comments: I am not opposed to attempts at finding easier ways for reviewers, therefore also agree with "this PROD in principle" so thanks to User:TonyBallioni but per User:SmokeyJoe there can't be "a part solution that is far short of a solution". There needs to be some agreed upon solution that many won't consider WP:CREEP. I have become disheartened at times after randomly clicking on many multiple drafts (and quickly going to the next so sort of wading through the crap), in search of one that would make a passable article or one that might possibly have substance enough that would survive an AFD, in a sometimes attempt to not be "too deletionist" (per User:SportingFlyer). I attempt to use the stop choice only when I see several rejections and reviewers suggestions being continually ignored on re-submissions or just patent advertisement or serious violations. I would never want to hinder a new editor or possibly good new article creations and sometimes just leave comments. Considering these things it would be cool if there could be more categories other than Category:Declined AfC submissions that could separate drafts that have been reviewed and those that haven't as opposed to just those that are declined. Category:Pending AfC submissions states, "This category lists the submissions that are waiting to be reviewed through the AfC process." that if commented on seems not accurate. It also seems it would give benefits that some progress could be visible. I suppose comments from "prod patrollers" would be important on this and I don't know enough yet about the actual "workings" so just offering comments. Otr500 ( talk) 13:28, 26 May 2019 (UTC)
• Support - project-minded editors keep trying to push G13 in this direction, by adding caveats and deletion waiting periods and exemptions and what-not. Let's just do this instead. If someone PRODs a draft and nobody objects within 7 days, it's harmless to delete it. If the creator returns, PRODs are automatic REFUNDs. Ivanvector ( ^Talk/ _Edits) 13:51, 6 June 2019 (UTC)
• Suppor: At this time per User:Ivanvector as it make sense. It seems this may need relisting for more input. Otr500 ( talk) 01:23, 10 June 2019 (UTC)

There are only 2 weeks remaining on the consultation period of a user reporting system on abuse.

Given the current discussions that are limited to their respective pages ( WP:FRAM and WP:AC/N) a pointer to the meta/WMF discussion seemed critical.

Unlike the Talk Page consultation, this seems to have not been added to the banners.

With the shortness left, please participate and spread knowledge of the discussion - it's had very little involvement given the potential impact. Nosebagbear ( talk) 16:26, 15 June 2019 (UTC)

Since there are absolutely no details about what is intended, it is very difficult to give meaningful comments. Nigel Ish ( talk) 16:45, 15 June 2019 (UTC)

The topic box at Syrian Civil War is not wide enough; it's only four columns, there should be at least one more column. Can someone technical stretch this topic box and add another one or two or three more columns? - ApexUnderground ( talk) 06:12, 16 June 2019 (UTC)

@ ApexUnderground: What kind of information are you wanting to add to the infobox? You should probably take this request to the talk page, and when there is some concensus about what more information needs adding, a user with 'technical' expertise may make the necessary changes. Regards, GUYWAN ( t · c ) 15:31, 18 June 2019 (UTC)