This page contains discussions that have been archived from Village pump (policy). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
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. SportingFlyerT·C14:14, 28 February 2019 (UTC)
Unify alternative names for articles with spelling differences
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):
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)
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)
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💬theythem06:46, 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💬theythem23: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. --Jayron3219: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💬theythem23: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. --Jayron3211: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)
Russian disinformation on Wikipedia
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! -- GreenC20: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)
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)
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. GMGtalk17: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. GMGtalk18:17, 9 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. -- GreenC17:45, 9 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)
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 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ölf22:45, 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)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I note the recently closed "RfC" on organization vs organisation. I dispute this as a settled Wikipedia policy. There has been minimal promotion of this discussion which has a limited number of editors commenting on what can be a huge change. It is being now used as a settled policy, where it suddenly adversely affects a lot of wikipedia, and strikes me as potentially thought of cultural vandalism. It feels like someone has tried to sneak quite a major change through the back door, and that if this needs to be done properly we should just poll every active editor on wikipedia for usage. My personal preference is to have no standardisation, however forcing everyone to use "-ize", is not fair on a lot (and perhaps the majority) of English users where "-ise" is the proper variant. I have cross-posted to the Village pump proposals section. - Master Of Ninja (talk) 15:36, 17 April 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Wikimedia Foundation re-branding discussion/planning
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)
Hastily replying "Not done" to edit requests
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💬theythem13: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💬theythem14: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. --Jayron3214: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💬theythem15: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. --Jayron3216: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. --Jayron3216: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. — xaosfluxTalk14: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💬theythem15:12, 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. — xaosfluxTalk15: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? — xaosfluxTalk15: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)
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|Talk16:48, 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|Talk18:44, 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|Talk18: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)
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)
@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 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)
"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)
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)
RfC: Should the Administrators policy be amended to include a recommendation to use two-factor authentication?
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion.A summary of the conclusions reached follows.
Procedural close as an RfC at a central page like this is overkill considering the (current) Bugger-All discussion on the relevant talk page. Why the urgency to escalate /shrugs/ ——SerialNumber5412922:42, 8 April 2019 (UTC)
I was not aware of a discussion about adding this text recommending 2FA to the policy. Could you please provide a link?- MrX 🖋 22:58, 8 April 2019 (UTC)
I disagree that there was an issue with changing the text, but basically this. If we're going to require it, we can have that talk, but talking about what we "recommend" is bikeshedding. ~ Amory(u • t • c)00:46, 9 April 2019 (UTC)
A strong password and password security are just one part of securing your account. Users with advanced permissions, and indeed all users, should be taking steps above and beyond these requirements to insure the security of their accounts. Two-factor authentication is now available to administrators and will hopefully be rolled out to all users in the near future.
Oppose - I don't really see how this helps. The difference from "available" and "recommended" is very fine. If this was asking for all administrators to be forced to use this, then this would be fine (I'd oppose for the restriction, but at least it would make sense). I'd also mention that having an option just for administrators that is suggested for security, which isn't currently available for all users grinds me up a little. Best Wishes, Lee Vilenski(talk • contribs)09:22, 9 April 2019 (UTC)
No per xaosflux. Policies are for requirements, recommendations should go elsewhere. Otherwise we'll have people arguing that admins violate the policy by not following the recommendation to enable 2FA. Ivanvector (Talk/Edits) 10:45, 9 April 2019 (UTC)
No. The purpose of policy pages is to specify required actions ("standards that all users should normally follow" if you want the official definition), not to act as coatracks for the personal opinions of assorted busybodies as to what they think other people ought to be doing. Regarding consistency with WP:PSR, as far as I can see the "above and beyond" language was unilaterally added by a single editor without discussion (Wikipedia:Security review RfC was the RFC that created WP:PSR, and nowhere either in that or in WT:PSR was there any agreement to recommend 2FA), immediately after that same editor tried and failed to get consensus for it; if anything, we should be removing the showboating from WP:PSR, not allowing this paranoia to spread to further pages. ‑ Iridescent13:54, 9 April 2019 (UTC)
That's a misrepresentation of the linked proposal, when Beeblebrox proposed that the password requirement "be amended to require that these users maintain a password solely for their Wikimedia login". It did not involve 2FA. The edit you link to was concurrent but separate. — Scott•talk13:09, 10 April 2019 (UTC)
Maybe I think we do need to address the problem, but I'm not sure (maybe it is, just not decided) that this language does it best. What I think we really need is "If you want to have advanced permissions, you need to secure your account in these ways. If you don't, AND your hacked account starts being used to damage Wikipedia, you have to go through RFA (or whatever) to get your permissions back. If you ARE following our recommendations, and it gets hacked, we'll let you back in when you get control again" We really need a policy that says "Look, we can't see your password or know your security process, but we DO need people with advanced permissions to take this stuff seriously, and if you aren't maybe you shouldn't have advanced permissions". Yes, everyone can be hacked, but we need to draw a distinction between people who got their back door kicked in vs. those that left the door wide open and left a sign out front saying "take whatever you like". Policy needs to be tightened up on this. --Jayron3214:16, 9 April 2019 (UTC)
Yes - The policy page does more that explain strict rules. It's also a guide for editors who wish to be promoted to admin, and for new admins learning to fulfill their role. It describes expectations, abilities, and best practices. Using 2FA would have prevented several admin accounts from being compromised over the years. The least we can do is raise awareness that using this additional security measure is recommended. Like Scott, I have no idea why this is even controversial. - MrX 🖋 14:25, 9 April 2019 (UTC)
No, because a "recommendation" in a policy page is quite pointless. If we were to require it, it would be a different story. Vanamonde (Talk)18:25, 9 April 2019 (UTC)
No, and no need. Perhaps the OP should actually spend some time looking at the various Mediawikiwiki and Wikitech pages related to 2FA before pushing this any further. The extension is written and maintained by volunteers, there is no committed support of the extension by the WMF, there is no department or unit tasked with assisting users who have problems with 2FA, and it is specifically designed with the assumption that the user has full control (i.e. ownership with full admin permissions - eliminating anyone editing from a work computer, a library, a member of the military, etc.) of their hardware. These are not small issues. Right now the permissions only require interface administrators - users with a high degree of technical knowledge, most of them in regular communication with WMF staff who can leverage those relationships should they encounter a problem. Add in 1600 admins, 3/4 of whom don't use IRC and half of whom have minimal technical expertise and/or have no idea whatsoever who to contact if they have problems. Until the WMF takes proper ownership of the 2FA issue and provides proper support with an extension that doesn't require the user to have admin permissions on the hardware being used, this should be a suggestion only. For that matter, there's a good chance that many users have a 2FA option built into their security software that they can apply without going through the WMF at all, and it will be better tested and better supported than the WMF version. Risker (talk) 01:54, 10 April 2019 (UTC)
an extension that doesn't require the user to have admin permissions on the hardware being used The solution to this is to not use a desktop computer as a 2FA device. Having a smartphone capable of running a code generator app is trivial. You could literally buy a second-hand old phone for very little money just to use for that if you had to. The 2FA documentation shouldn't be suggesting using the same computer for editing and 2FA at all. — Scott•talk12:27, 10 April 2019 (UTC)
You could literally buy a second-hand old phone for very little money Firstly that's not true in all parts of the world, secondly not all admins have the disposable income required to purchase and maintain a smartphone (which is significant in some situations, even for a second hand one), and thirdly we should absolutely not be requiring any editor to spend any money in order to participate in Wikipedia. Thryduulf (talk) 12:35, 10 April 2019 (UTC)
Also some people have disabilities that mean that using a smartphone is very difficult if not impossible for them. Just because something is trivial for a technically-savvy, able-bodied person with disposable income in an affluent Western country does not mean the same is true of everyone. Thryduulf (talk) 12:40, 10 April 2019 (UTC)
Read the proposal again. It isn't requiring (your italics) anyone to do anything. And "affluent Western country" - wow. You need to let those dated and patronizing assumptions go and start paying attention. By next year, estimates Ericsson, 70% of the global population will have smartphones; 90% will have high-speed data access. 80% of those smartphone owners will be in Asia Pacific, the Middle East, and Africa. Regarding disabilities, again: this proposal is to add a recommendation, not a requirement. — Scott•talk12:53, 10 April 2019 (UTC)
No, per Risker and Iridescent. If 2FA is ever fully supported by the WMF and technical barriers to adoption are very significantly lower than they are today then we can reconsider. Thryduulf (talk) 10:52, 10 April 2019 (UTC)
No, partly per Risker. 2FA as currently implemented is a flawed technology based on a lot of assumptions which do not apply in many cases. Admins should make their own evaluation of whether 2FA is suitable for their circumstances, and there should not be a blanket recommendation to adopt a technology which will inappropriate for many admins. --BrownHairedGirl(talk) • (contribs) 11:26, 10 April 2019 (UTC)
No. Risker has come up with a show stopper here. It is bad practice (althought commonplace among Windows users) to use an account on a computer with local admin permissions for anything other than maintenance of that computer. It seems that 2FA requires that, so we shouldn't be recommending it. Phil Bridger (talk) 11:52, 10 April 2019 (UTC)
Phil Bridger - wrong, and that comment is (in my opinion) quite close to sensationalist rhetoric. It's not a show stopper - Risker said nothing about needing administrative permissions day-to-day. To be clear, the technical requirements to use 2FA as currently implemented are: a) a device you can edit from normally, b) a device you can run a code generator app on (which may be, but preferably isn't the same device as (a)), and c) somewhere safe to store the scratch codes. To be fully protected, the device the code generator app is on should be entirely under your control (the second factor is "something you have", versus "something you know" being the password), but even if it isn't entirely under your control (such as a work machine) it's better than just a password as it's still a device the attacker must get access to. The code generating device needs to be something you have access to every time you log in, which is why a smartphone is the ideal device here. The most administrative access to a computer I think you could possibly need would be to install a code-generating app, which falls squarely in the "computer maintenance" zone. stwalkerster (talk) 12:48, 10 April 2019 (UTC)
Please don't accuse me of "sensationalist rhetoric", or anything close to it, when I was simply basing my comment on a reasonable interpretation of what Risker wrote, and which had not been questioned at the time I made my comment. Phil Bridger (talk) 12:54, 10 April 2019 (UTC)
Apologies, I didn't mean to specifically accuse you of it, merely point out that you appeared to have found a minor point and blown it way out of proportion from what actually is the case. While I'm still not sure how you made that leap, I've struck that part of my comment and respect that you did make that leap. I do stand behind the remainder of my comment though. stwalkerster (talk) 21:06, 10 April 2019 (UTC)
No, regrettably. Everyone should be using 2FA as a matter of good practice, but I do recognise that not everyone has a smartphone, or other sensible code generating device options. I also recognise we have a fairly problematic hole in recovery from 2FA which we need to somehow resolve. Technologically, our 2FA implementation isn't really flawed here as far as I can tell - it's entirely the social side of it we seem to have a problem with. For the record, in contradiction to Risker's comment, I occasionally edit from my work computer without admin access just fine (not using my main account because they do HTTPS MITMing, but that's a different problem) - I do have my own smartphone with the code generating app on though, and I believe Risker was referring to "administrative access to the device" to be "the ability to install an app on a device". Also as a matter of good practice, everyone should be using a strong, unique password, and everyone should be wary of malware/keyloggers/etc when logging in on devices they don't have full control of, whether they use 2FA or not. stwalkerster (talk) 12:48, 10 April 2019 (UTC)
So in other words, you have access to *two* devices, which is more than many of our editors have. Please be aware that even having access to two devices doesn't make it less of a challenge, because of the way that data plans work in different countries. A code generated to me from a US server will cost me the "out of country" rate on my data plan, and could easily add up to a supplementary $50 cost per month. (I learned this from experience with 2FA on another US-server website I used to use. Note the past tense.) Other people will have different plans. Risker (talk) 13:33, 10 April 2019 (UTC)
A code generated to me from a US server 2FA codes are generated by the app on your phone. It doesn't require data. — Scott•talk13:49, 10 April 2019 (UTC)
Tell that to my phone plan. Risker (talk) 13:56, 10 April 2019 (UTC) Ahh, I think you've misunderstood my point. I edit solely on computers, never on phones; however the code was generated to my phone to be ported to my desktop. I didn't add software to my phone - and we get back to the issue of security software not being managed or supported by the WMF. Risker (talk) 14:00, 10 April 2019 (UTC)
Two devices are not required, but it's probably better security practice to do so. As I said originally, there are code generator apps available for Windows/macos/Linux/etc. The key thing to multi-factor (read: two-factor) authentication is to make use of different authentication factors in some way - and the three factors are commonly known as "something you know" (eg password, security questions, etc); "something you have" (eg U2F tokens, proof that you have access to a specific device - normally by code generator apps), and "something you are" (biometrics). Biometrics cause a continent's weight of privacy concerns, so the only real option is for you to prove posession of a "thing" somehow. Normally this involves some stored secret combined with the current time to produce a short code only valid for a short time. The secret is generated by the WMF, and transferred to your phone normally by you scanning a QR code, or by manually typing in the secret to the app. As such, the only data transfer to/from your phone from the perspective of your data plan should be the download of the two-factor authentication software. To be clear, this is specifically the TOTP protocol which Wikimedia use - other two-factor implementations do indeed send push notifications or messages to your phone, and of course they do communicate, but the advantage of TOTP is there is no communication in that way. Obviously, with some incomes and budgets in whatever country, this may not be economically feasible for an individual, and I understand not enabling 2FA in those cases, but if you can do it, IMHO you should do it, and you must keep those scratch tokens safe! stwalkerster (talk) 21:06, 10 April 2019 (UTC)
Yes, it is obviously neeeded. And it actually should be made an enumerated requirement, not just a recommendation, since failure to do so that results in account compromise results in turn in a desysop. It's already a requirement, just one we're not listing. — SMcCandlish☏¢ 😼 13:02, 10 April 2019 (UTC)
Support, in fact it should be mandatory. If you're an administrator on a site serving millions of users you have a responsibility to take some security precautions. AdA&D★14:24, 10 April 2019 (UTC)
@Anne drew Andrew and Drew: you have a responsibility to take reasonable security precautions. 2FA is not reasonable for all administrators for various reasons - read this thread for some examples - and even if it was reasonable the WMF do not have the capacity required to support it for all admins. Thryduulf (talk) 16:26, 10 April 2019 (UTC)
No: I object on two grounds. First, a recommendation is not a policy, nor can it be one, by definition. Second (and far more relevant to this discussion), Risker, stwalkerster, and BrownHairedGirl all make good points here, especially amidst calls for 2FA being mandatory. (As an addendum, I would support Jayron32's proposal, to a certain extent.) —Javert2113 (Siarad.|¤)20:05, 10 April 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Meta point: I am just astonished at the numberofeditorswhoclaimed 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". ‑ Iridescent06: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)
Rangeblocks
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. SQLQuery 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. SQLQuery me!22:14, 24 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. -FASTILY02: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. SQLQuery 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. SpinningSpark00: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)
Citing an encyclopedia
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?
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)
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. GMGtalk14:18, 29 April 2019 (UTC)
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?
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.
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@lk22:30, 29 April 2019 (UTC)
Discussion about adding pinging to the WP:Canvassing guideline
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.
@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). ‑ Iridescent22: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
pages created only on Feb 11
16:44, 11 February 2019 diff hist +2,892 N Portal:Politics of South Sudan start portal
16:43, 11 February 2019 diff hist +2,808 N Portal:Politics of Sudan start portal
16:43, 11 February 2019 diff hist +3,055 N Portal:Politics of São Tomé and Príncipe start portal
16:42, 11 February 2019 diff hist +2,853 N Portal:Politics of Tanzania start portal current [rollback] [vandalism]
16:39, 11 February 2019 diff hist +2,857 N Portal:Politics of Togo start portal
16:39, 11 February 2019 diff hist +2,840 N Portal:Politics of Tunisia staart portal current [rollback] [vandalism]
16:39, 11 February 2019 diff hist +2,827 N Portal:Politics of Uganda start portal current [rollback] [vandalism]
16:39, 11 February 2019 diff hist +3,088 N Portal:Politics of the Republic of the Congo start portal
16:31, 11 February 2019 diff hist +2,901 N Portal:Politics of Cameroon start portal
16:20, 11 February 2019 diff hist +43 N Portal:Military of Finland redir current Tag: New redirect [rollback] [vandalism]
16:18, 11 February 2019 diff hist +2,536 N Portal:Western dress codes start portal
16:18, 11 February 2019 diff hist +2,814 N Portal:Wildlife of India start portal current [rollback] [vandalism]
16:17, 11 February 2019 diff hist +2,814 N Portal:Wildlife of Nepal start portal
16:15, 11 February 2019 diff hist +2,723 N Portal:Winter War start portal current [rollback] [vandalism]
16:12, 11 February 2019 diff hist +3,069 N Portal:Finnish Defence Forces start portal
16:08, 11 February 2019 diff hist +40 N Portal:World trade redir current Tag: New redirect [rollback] [vandalism]
16:07, 11 February 2019 diff hist +2,416 N Portal:Yugoslavs start portal
16:07, 11 February 2019 diff hist +2,762 N Portal:Yoruba people start portal current [rollback] [vandalism]
16:00, 11 February 2019 diff hist +2,835 N Portal:International trade start portal
15:57, 11 February 2019 diff hist +2,762 N Portal:World economy start portal current [rollback] [vandalism]
12:44, 11 February 2019 diff hist +2,697 N Portal:Arianism start portal current [rollback] [vandalism]
12:43, 11 February 2019 diff hist +2,717 N Portal:Antimatter start portal
12:43, 11 February 2019 diff hist +2,801 N Portal:Anti-consumerism start portal
12:42, 11 February 2019 diff hist +2,879 N Portal:Ancient Roman religion start portal current [rollback] [vandalism]
12:42, 11 February 2019 diff hist +2,944 N Portal:Ancient Near East mythology start portal current [rollback] [vandalism]
12:42, 11 February 2019 diff hist +2,684 N Portal:Alevism start portal current [rollback] [vandalism]
12:41, 11 February 2019 diff hist +2,827 N Portal:Albanian Civil War start portal current [rollback] [vandalism]
12:31, 11 February 2019 diff hist +2,853 N Portal:Politics of Cambodia start portal current [rollback] [vandalism]
12:30, 11 February 2019 diff hist +2,834 N Portal:Politics of Burundi start portal
12:30, 11 February 2019 diff hist +2,905 N Portal:Politics of Burkina Faso start portal current [rollback] [vandalism]
12:30, 11 February 2019 diff hist +2,853 N Portal:Politics of Bulgaria start portal current [rollback] [vandalism]
12:25, 11 February 2019 diff hist +2,821 N Portal:Politics of Brunei start portal
12:25, 11 February 2019 diff hist +2,827 N Portal:Politics of Brazil start portal current [rollback] [vandalism]
12:25, 11 February 2019 diff hist +2,853 N Portal:Politics of Botswana start portal current [rollback] [vandalism]
12:22, 11 February 2019 diff hist +3,029 N Portal:Politics of Bosnia and Herzegovina start portal
12:19, 11 February 2019 diff hist +2,827 N Portal:Politics of Bhutan start portal current [rollback] [vandalism]
12:19, 11 February 2019 diff hist +2,808 N Portal:Politics of Benin start portal
12:19, 11 February 2019 diff hist +2,821 N Portal:Politics of Belize start portal
12:19, 11 February 2019 diff hist +2,834 N Portal:Politics of Belgium start portal
12:18, 11 February 2019 diff hist +2,840 N Portal:Politics of Belarus start portal current [rollback] [vandalism]
12:13, 11 February 2019 diff hist +2,834 N Portal:Politics of Bavaria start portal
12:11, 11 February 2019 diff hist +2,879 N Portal:Politics of Bangladesh start portal current [rollback] [vandalism]
12:11, 11 February 2019 diff hist +2,834 N Portal:Politics of Bahrain start portal
12:09, 11 February 2019 diff hist +2,536 N Portal:Politics of Artsakh start portal
12:07, 11 February 2019 diff hist +2,866 N Portal:Politics of Argentina start portal current [rollback] [vandalism]
12:06, 11 February 2019 diff hist +2,996 N Portal:Politics of Antigua and Barbuda start portal current [rollback] [vandalism]
12:03, 11 February 2019 diff hist +2,821 N Portal:Politics of Angola start portal
12:03, 11 February 2019 diff hist +2,840 N Portal:Politics of Andorra start portal current [rollback] [vandalism]
12:03, 11 February 2019 diff hist +2,840 N Portal:Politics of Algeria start portal current [rollback] [vandalism]
12:02, 11 February 2019 diff hist +2,840 N Portal:Politics of Albania start portal current [rollback] [vandalism]
12:02, 11 February 2019 diff hist +2,892 N Portal:Politics of Afghanistan start portal current [rollback] [vandalism]
12:00, 11 February 2019 diff hist +2,847 N Portal:Politics of Abkhazia start portal
05:30, 11 February 2019 diff hist +2,905 N Portal:World Rally Championship start portal current [rollback] [vandalism]
05:29, 11 February 2019 diff hist +2,765 N Portal:Worcestershire start portal
05:28, 11 February 2019 diff hist +2,751 N Portal:West Flanders start portal current [rollback] [vandalism]
05:23, 11 February 2019 diff hist +2,681 N Portal:Thrissur start portal current [rollback] [vandalism]
05:22, 11 February 2019 diff hist +2,476 N Portal:The Living End start portal current [rollback] [vandalism]
05:21, 11 February 2019 diff hist +2,765 N Portal:Tamil language start portal current [rollback] [vandalism]
05:18, 11 February 2019 diff hist +2,452 N Portal:Terry Brooks start portal current [rollback] [vandalism]
05:16, 11 February 2019 diff hist +2,710 N Portal:Semiotics start portal
05:13, 11 February 2019 diff hist +2,709 N Portal:Saxophones start portal
05:11, 11 February 2019 diff hist +2,667 N Portal:Rutland start portal
05:09, 11 February 2019 diff hist +2,681 N Portal:Nobility start portal
05:07, 11 February 2019 diff hist +2,905 N Portal:Royal Canadian Air Force start portal current [rollback] [vandalism]
05:03, 11 February 2019 diff hist +2,737 N Portal:Ricky Martin start portal current [rollback] [vandalism]
05:02, 11 February 2019 diff hist +2,765 N Portal:Ras Al Khaimah start portal current [rollback] [vandalism]
04:14, 11 February 2019 diff hist +32 N Portal:World ocean redir current Tag: New redirect [rollback] [vandalism]
04:08, 11 February 2019 diff hist +2,904 N Portal:World Ocean start portal
04:06, 11 February 2019 diff hist +2,793 N Portal:North Queensland start portal current [rollback] [vandalism]
04:05, 11 February 2019 diff hist +2,793 N Portal:Nordic countries start portal current [rollback] [vandalism]
04:04, 11 February 2019 diff hist +2,863 N Portal:National Rugby League start portal
04:01, 11 February 2019 diff hist +2,931 N Portal:Music of the United States start portal
03:57, 11 February 2019 diff hist +2,779 N Portal:Music of Serbia start portal
03:54, 11 February 2019 diff hist +2,737 N Portal:Midnight Oil start portal current [rollback] [vandalism]
03:51, 11 February 2019 diff hist +2,849 N Portal:Maithripala Sirisena start portal current [rollback] [vandalism]
03:49, 11 February 2019 diff hist +2,667 N Portal:Liguria start portal
03:49, 11 February 2019 diff hist +2,653 N Portal:Liège start portal
03:48, 11 February 2019 diff hist +2,765 N Portal:Leicestershire start portal
03:48, 11 February 2019 diff hist +2,751 N Portal:Lehigh Valley start portal current [rollback] [vandalism]
03:43, 11 February 2019 diff hist +2,793 N Portal:Krasnoyarsk Krai start portal
03:42, 11 February 2019 diff hist +2,751 N Portal:Jordin Sparks start portal current [rollback] [vandalism]
03:39, 11 February 2019 diff hist +2,749 N Portal:Islamophobia start portal
03:36, 11 February 2019 diff hist +2,779 N Portal:Insomniac Games start portal
03:33, 11 February 2019 diff hist +2,635 N Portal:World views start portal
03:29, 11 February 2019 diff hist +2,860 N Portal:Communication studies start portal current [rollback] [vandalism]
03:26, 11 February 2019 diff hist +2,905 N Portal:Hunters & Collectors start portal
03:24, 11 February 2019 diff hist +2,653 N Portal:Hotels start portal
03:20, 11 February 2019 diff hist +2,416 N Portal:Grinspoon start portal current [rollback] [vandalism]
03:17, 11 February 2019 diff hist +2,821 N Portal:Germanic languages start portal current [rollback] [vandalism]
03:11, 11 February 2019 diff hist +2,779 N Portal:East Kalimantan start portal current [rollback] [vandalism]
03:11, 11 February 2019 diff hist +2,695 N Portal:East Java start portal
03:10, 11 February 2019 diff hist +2,793 N Portal:Central Sulawesi start portal
03:10, 11 February 2019 diff hist +2,821 N Portal:Central Kalimantan start portal
03:10, 11 February 2019 diff hist +2,737 N Portal:Central Java start portal current [rollback] [vandalism]
03:09, 11 February 2019 diff hist +2,681 N Portal:Bengkulu start portal
03:08, 11 February 2019 diff hist +2,653 N Portal:Banten start portal
03:05, 11 February 2019 diff hist +2,625 N Portal:Bali start portal
02:58, 11 February 2019 diff hist +2,821 N Portal:Football in Jordan start portal current [rollback] [vandalism]
02:56, 11 February 2019 diff hist +2,835 N Portal:Football in Croatia start portal current [rollback] [vandalism]
02:53, 11 February 2019 diff hist +47 N Portal:Field Hockey redir current Tag: New redirect [rollback] [vandalism]
02:52, 11 February 2019 diff hist +47 N Portal:Field hockey redir current Tag: New redirect [rollback] [vandalism]
02:49, 11 February 2019 diff hist +2,933 N Portal:International field hockey start portal
02:46, 11 February 2019 diff hist +2,905 N Portal:Environmental technology start portal current [rollback] [vandalism]
02:46, 11 February 2019 diff hist +2,368 N Portal:Ehime start portal current [rollback] [vandalism]
02:43, 11 February 2019 diff hist +2,681 N Portal:Dyslexia start portal
02:33, 11 February 2019 diff hist +2,756 N Portal:Cryptozoology start portal
02:31, 11 February 2019 diff hist +2,863 N Portal:Cortina d'Ampezzo start portal current [rollback] [vandalism]
02:30, 11 February 2019 diff hist +3,022 N Portal:Conservatism in the United States start portal current [rollback] [vandalism]
02:29, 11 February 2019 diff hist +2,849 N Portal:Cognitive psychology start portal current [rollback] [vandalism]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Support. The existence of an active Wikiproject is a good indicator for the existence of editors who are willing to maintain a portal. Without maintainers, the portal is just a drive by creation of junk. Active Wikiprojects can judge the suitability of a topic for a portal. MFD can not handle the huge number of autogenerated portals, but this proposal should not stop any portal from being proposed for deletion at MfD. Legacypac (talk) 21:45, 30 March 2019 (UTC)
Support this version, as it provides greater impetus for the cleanup of existing portals, although either is better than nothing. -John M Wolfson (talk) 22:09, 30 March 2019 (UTC)
If I'm not mistaken, the global consensus, such that there is one, is shaky as to the very existence of portals. Per ArbCom's statement on the matter local consensus can be taken into account in the absence of global consensus, which is likely to arise in a question of a given portal's existence. Perhaps an appeals process can be in order on MfD, which might be shift preference to Version 2. -John M Wolfson (talk) 22:24, 30 March 2019 (UTC)
My comment has nothing to do with any sort of particular consensus, only a part of the spirit of the policy (specifically called out as such), which is that WikiProjects do not and can not have overriding authority on content matters. I would have little concern with a suggestion that WikiProjects can and should steward portals under their domain, but that's neither the spirit nor verbiage of this proposal, and wouldn't affect anything in the end anyway--WP:MFD would still be the only correct place to delete portals (pending some speedy deletion criterion for TTH's portals being created). --Izno (talk) 18:45, 31 March 2019 (UTC)
Fair enough, I would also support CSD proposal X3 (Regarding TTH's portals not clogging up MfD), and with that I would support something to limit future portal creation (maybe a "Portals for Creation" page similar to WP:AfC, but for every future portal?) I could see how limiting such a process only to WikiProjects might create WP:OWN problems, so perhaps we can leave it to the global community? -John M Wolfson (talk) 19:37, 31 March 2019 (UTC)
Support as proposer. This isn't ideal, but we need some kind of mechanism to gauge which portals are likely to be maintained and considered of potential use, and that mechanism needs to be designed to prevent both the "keep them all" and "delete them all" arguing parties away so they can be discussed by people who will view them in terms of utility rather than in terms of their personal support for or opposition to the concept of portals. I'm not wedded to this proposal, but I've not seen anyone propose anything better. ‑ Iridescent22:49, 30 March 2019 (UTC)
Strong Oppose - See the bullet points below for my various rationales.
Wikiprojects are perenially understaffed and underwatched, with some having no participation for months or even years at a time on their talk pages. Some are marked as semi-active or inactive. Making it a requirement to consult with projects with such problems would amount to muzzling portal creations for many topics, because nobody may actually come along to discuss a portal proposal.
This proposal would further denigrate Wikipedia in the wrong direction, with an increasing nanny state type of governance regarding content, where permissions have to first be made to create pages. This would result in even more chilling effects than already exist in various areas of the encyclopedia at this time.
The proposal goes entirely against the grain of WP:5, point #5, concerning being WP:BOLD. Wikipedia having no firm rules is one of the fundamental principles of the encyclopedia. The proposal also goes against the grain of WP:NOTBUREAUCRACY in several ways.
Regarding the notion that if a topic has no project, the portal would then be procedurally deleted: some topics may not have a direct Wikiproject, but may have a related one. For example, there is no direct project for the topic of air conditioning, but a related project would be WikiProject Engineering.
Furthermore, many of the discussions listed at WikiProject Council/Proposals receive very little input, sitting in limbo. If a Wikiproject cannot be created without first consulting a forum that receives little input, and therefore a portal could not be created without a project backing it, all without a means for a project to get off the ground in the first place, it would amount to a vicious circle of automatically denying portal creation for some topics based upon the already largely broken system at the WP Council.
Would older portals also be automatically, procedurally deleted if no project exists, or would this only apply to the newer ones, with a grandfather clause existent for the older portals? Either way, automatic deletion in this manner goes against several core principles of Wikipedia, and would serve to unnecessarily stifle the creation of functional, useful content.
Regarding having discussions for all existing portals raised on talk pages of relevant Wikiprojects: this is very unlikely to even be viable. Who would ultimately be responsible to perform creating and then watching all of these discussions? Would said posited discussions be a subjective straw poll, or based upon actual objective discussion about a portal's content and how it relates to a topic? Importantly, this would significantly and negatively shift Wikipedia from being a volunteer project to one that requires specific actions, in this case, mandatory discussions for all content in the portal namespace. This would set a very poor precedent for the encyclopedia.
Regarding the notion of procedurally deleting portals if no consensus exists in a talk page discussion: at AfD, MfD, and other areas of deletion on Wikipedia, a no consensus result typically results in retention of a page or pages, rather than deletion.
There's more, but I will leave my post at that for now.
If a topic doesn't have enough notability to sustain a viable WikiProject, it probably doesn't have one to sustain a portal. I know such reasoning is quite sketchy and akin to the "if you've done nothing wrong you've got nothing to hide" reasoning many authoritarians adopt, but it's important to remember that portals are not content, they are a navigational aid, one of hotly debated utility as WP:ENDPORTALS showed. I myself have created articles in the mainspace that have quite niche use, but they are content and limited to one page. Imagine if we allowed such portals as Portal:Harry C. Van Norman or Portal:1929 Chicago aldermanic elections. As such, community consensus can have more power, and any sort of chilling effect it might have doesn't matter as much so long as it doesn't apply to content as such. (Even with content we have such things as WP:NOTABILITY, but I digress.) As a personal side note, I've never really used portals myself, so my Wikipedia experience would not be affected if they were eliminated entirely, BUT I do realize that others' mileages may vary in that regard so I'm not here to denigrate them entirely.
The point about no-consensus usually resulting in keeping for MfD is a valid one, but with this proposal the onus would be for portal retention, NOT deletion. As such, the onus would be on keeping the portal, and a lack of consensus in that regard for retention would probably result in deletion.
I get that your main argument is one about slippery slope, but I don't think that this will apply to the mainspace, and as said before portals are not themselves content.
Oppose, if a portal is well made and well maintained, it should be kept. If a portal is poorly made and there is no sustainable group of editors willing to improve it, it should be deleted. Whether there is a formal WikiProject related to the topic and whether that WikiProject is alive or not can influence whether we believe a portal can be sustainably maintained, and if somebody creates hundreds or thousands of portals that they can't maintain themselves (and we have seen in many recent MfDs that also auto-portals still require maintenance), those should be deleted unless they are adopted by editors who maintain them. But I see no reason to care whether these editors are organised in a WikiProject (and there is no formal way to check anyway). —Kusma (t·c) 09:17, 31 March 2019 (UTC)
Oppose good idea but bad in practice. WikiProjects are largely empty with no active users, so this would be a useless and futile task. I'm almost debating whether this idea is purposefully dooming the creation of portals by trying to require a long-gone group of judges to approve. ɱ(talk)15:21, 31 March 2019 (UTC)
Oppose. Many Wikiprojects have died and some of those that have not have fallen into, shall we say, uncollaborative habits. A rationally argued consensus against the utility of the portal at a functional, relevant Wikiproject should, however, be taken into account at any MfD. Espresso Addict (talk) 08:23, 1 April 2019 (UTC)
Oppose - purely on the idea that wikipedia space/talk space is not the same as portal space. I edit a lot of cue sport articles; and if I was inclined to propose Portal:Cue Sports (If I was inclined), I'd have to ask the WP:CUE wikiproject, which is all but dead. I'd effectly be asking myself for permission to create a portal. However, just because there aren't tonnes of people working on the wikiproject, it doesn't mean that there aren't lots of people updating the articles, or navigating through portals. all the above being said, I wouldn't create a portal; but I wouldn't stop someone else in the same situation. Best Wishes, Lee Vilenski(talk • contribs)08:57, 1 April 2019 (UTC)
Oppose prefer version 2 below. There are times when, outside the scope of a WikiProject, there are going to be well-maintained portals. There will also be defunct projects with dead-end portals. --Jayron3214:11, 1 April 2019 (UTC)
Beyond oppose: This is against multiple policies and multiple ArbCom rulings. Wikiprojects are nothing but pages at which editors with a common topical interest gather to discuss and evaluate articles. They have no authority of any kind over other editors and cannot have any, under WP:CONLEVEL and WP:OWN and WP:EDITING policies. This has been tested at ArbCom repeatedly, and the answer is always the same. WP has no walled gardens, no good ol' boys's clubs, no membership organizations, no topical fiefdoms. The entire notion could never work anyway, since there are virtually no articles that could not be within the scope of multiple wikiprojects, which would just set up a "projectwar". F that noise. — SMcCandlish☏¢ 😼 00:55, 14 April 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
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.
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Support as proponent of this version. This will serve as a check on future reckless creation of portals, provide a place where each future portal can be discussed, and require some degree of involvement. Robert McClenon (talk) 21:19, 30 March 2019 (UTC)
Prefer Version 1 because it helps in the cleanup of the indiscriminately created portals and attracts interested editor attention to the portals that should be considered for keeping. This version has no teeth because it makes WikiProject support optional ie it does not matter, which is how things are now. Legacypac (talk) 21:47, 30 March 2019 (UTC)
Strong Oppose - See the bullet points below for my various rationales.
Muzzling all content creation in a namespace would set a very poor precedent. Wikiprojects are perenially understaffed and underwatched, with some having no participation for months or even years at a time on their talk pages. Some are marked as semi-active or inactive. Making it a requirement to consult with projects with such problems would amount to muzzling portal creations for many topics, because nobody may actually come along to discuss a portal proposal.
This proposal would further denigrate Wikipedia in the wrong direction, with an increasing nanny state type of governance regarding content, where permissions have to first be made to create pages. This would result in even more chilling effects than already exist in various areas of the encyclopedia at this time.
The proposal goes entirely against the grain of WP:5, point #5, concerning being WP:BOLD. Wikipedia having no firm rules is one of the fundamental principles of the encyclopedia. The proposal also goes against the grain of WP:NOTBUREAUCRACY in several ways.
Many of the discussions listed at WikiProject Council/Proposals receive very little input, sitting in limbo. If a Wikiproject cannot be created without first consulting a forum that receives little input, and therefore a portal could not be created without a project backing it, all without a means for a project to get off the ground in the first place, it would amount to a vicious circle of automatically denying portal creation for some topics based upon the already largely broken system at the WP Council.
Oppose, the very idea of asking for permission before editing is a contradiction to the fundamental principle that Wikipedia is a wiki. (But all of the recent mass creations should be deleted). —Kusma (t·c) 09:21, 31 March 2019 (UTC)
Oppose good idea but bad in practice. WikiProjects are largely empty with no active users, so this would be a useless and futile task. I'm almost debating whether this idea is purposefully dooming the creation of portals by trying to require a long-gone group of judges to approve. It also seems like people are searching for yet another MfD argument for deletion... ɱ(talk)15:23, 31 March 2019 (UTC)
Oppose as worded, per my Oppose to the first proposal. However I would not object to advice that portal creators should consult any relevant Wikiproject that is still active, and take into consideration any concerns raised by project members. Espresso Addict (talk) 08:28, 1 April 2019 (UTC)
Beyond oppose: This is against multiple policies and multiple ArbCom rulings. Wikiprojects are nothing but pages at which editors with a common topical interest gather to discuss and evaluate articles. They have no authority of any kind over other editors and cannot have any, under WP:CONLEVEL and WP:OWN and WP:EDITING policies. This has been tested at ArbCom repeatedly, and the answer is always the same. WP has no walled gardens, no good ol' boys's clubs, no membership organizations, no topical fiefdoms. The entire notion could never work anyway, since there are virtually no articles that could not be within the scope of multiple wikiprojects, which would just set up a "projectwar". F that noise. — SMcCandlish☏¢ 😼 00:55, 14 April 2019 (UTC)
Oppose with the same reasoning as many of the above !votes. WikiProjects are interest groups not authorities and I think to the extent that there are problems with portal creation, they should be handled by the same processes that we handle article and template creation. I am mainly commenting because I was brought in by Legobot and had no stake in the original discussions. 0x0077BE(talk · contrib)12:34, 22 April 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
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|Talk21: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)
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)
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)
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)
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 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)
@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 shortcuttables. 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)
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 America100023: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)
About graphic nude photos
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)
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)
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)
"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)
Again thanks for another response!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥♥ Sharif Uddin (talk) 16:40, 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. Levivich17: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)
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." Levivich03:13, 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.
"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)
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". --Jayron3218: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)
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)
NPA potential RFC for gender identification harassment
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 SoWhy09: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)
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)
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 Boriv^_^vBori!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 Mishehu10: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 Mishehu10: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. --Jayron3210: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. JehochmanTalk14: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.) ~ Rob13Talk14: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. JehochmanTalk14: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. –xenotalk14: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)
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)
Alexa rank question
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)
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. -- GreenC13: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. -- GreenC21: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). -- GreenC15: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. — Newslingertalk08: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).
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). — Newslingertalk01: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)
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 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.
@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)
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)
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)
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)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Administrators can bypass deletion discussion and immediately delete Wikipedia pages or media that are within scope of a community general sanction only when the pages or media meet the requirements for speedy deletion.Administrators cannot delete pages or media within the scope of a community general sanction without a deletion discussion unless the pages or media fall under the criteria for speedy deletion. Such deletions are ordinary speedy deletions so have no special restrictions on reversibility and can be appealed at deletion review. Page-level sanctions refer to limitations on the ability to edit pages, or to edit pages in a particular manner, not to deleting pages.
Background: Universa Blockchain Protocol was deleted with the rationale "Covert advertising. Page-level sanction under WP:GS/Crypto". At Wikipedia:Deletion review/Log/2018 July 9#Universa Blockchain Protocol, the community was divided over whether community general sanctions permitted the deletion of pages within the scope of the sanction. The DRV closer wrote, "The community discussion needed to resolve the apparent policy conflict instead needs to happen in a wider venue, such as in a policy RfC, and any who are interested in this issue are invited to initiate such a discussion."
Please also see Abecedare's proposed rewording of the first two sentences below Administrators cannot delete pages or media within the scope of a community general sanction without following the regular deletion process. Such deletions have no special restrictions on reversibility and can be appealed at deletion review. I strongly support this wording over the current wording but have not changed it at this late stage of the RfC, especially since it's already been changed once. Cunard (talk) 06:25, 5 May 2019 (UTC)
Comment--We know that admins can bypass discussion; if it's speedy-able. Meh. This, in effect, prohibits admin from deleting non-speediable pages under the purview of GS but the language is way too backdoor-ish.∯WBGconverse09:28, 28 April 2019 (UTC)
I'd support something along the lines of Pages cannot be deleted by administrators under community general sanctions, deletion of pages must follow the appropriate deletion process.. What's the point of using community general sanctions to delete pages if we're only using them with the current deletion processes? Iffy★Chat -- 09:35, 28 April 2019 (UTC)
Regarding "Pages cannot be deleted by administrators under community general sanctions", I received feedback about an earlier proposal to disallow deletions under community general sanctions here: "There is a longstanding consensus that pages created in violation of topic bans are eligible for speedy deletion under WP:CSD#G5. If the topic ban was imposed under a community sanction then that could be interpreted as the sanction authorising page deletions."
I think your proposed wording is fine as long as it allows those WP:CSD#G5 deletions. Feel free to propose this wording as an alternative proposal in this RfC. I would support the proposal.
Support as appeal should be available via deletion review. Invoking the special clause of "community sanction" should not protect actions from review and possible reversal if the community desires that. G11 and G5 can certainly still be used under the proposed wording. WP:IAR deletes are still possible, but they should be explainable and contestable. Community general sanctions should not in itself be a reason for a IAR delete. The sample delete should just have used the G11 reason to delete and not invoked the sanctions though. Graeme Bartlett (talk) 09:58, 28 April 2019 (UTC)
Support sanctions are supposed to apply to editors, not content. You couldn't use community sanctions to order that a paragraph must be removed from an article, so you can't use community sanctions to order that the article as a whole must be removed. And yes they should not be used as a way to shut down community review either. Hut 8.510:02, 28 April 2019 (UTC)
Support There is no reason to speedy delete a page outside of the provisions of the speedy deletion criteria under any circumstances. Thryduulf (talk) 10:44, 28 April 2019 (UTC)
What Godric and Iffy said, only more so. The intent is good; the wording awful. It bloats into 76 words - and even Iffy's version is 19 - something that should be stated in roughly 1, with "deletion" added to the other exceptions to the ways generic sanctions are identical to discretionary. —Cryptic10:47, 28 April 2019 (UTC)
Oppose. I'm on board with the general sentiment, but this the wording is excessively complicated. Why not just change WP:G5? Replace
This applies to pages created by banned or blocked users in violation of their ban or block
with
This applies to pages created in violation of bans, blocks, or community sanctions
That doesn't make it clear that general sanctions don't authorise admins to delete pages outside the speedy deletion criteria, which is the main point of the proposal. Hut 8.512:28, 28 April 2019 (UTC)
RoySmith, what kind of "Community Sanction" that is not some kind of "ban", do you think should authorize a speedy deletion? I can't see any. I can't imagine any good reason to loosely connect a sanction to CSD and thus enable non-objection speedy deletions by loophole. G5 appears already perfectly well written to enable speedy deletion of pages created by a user who was banned from creating such pages, if anything G5 errs in over-explaining. What is it about G5 that you think is not good enough? Do you want G5 to be retrospective? Do you want G5 to be non-objective? Do you want G5 to be sometimes unreviewable at DRV? --SmokeyJoe (talk) 02:34, 29 April 2019 (UTC)
Oppose - also I am on board with the general sentiment, but the remark .."the community was divided over whether community general sanctions permitted the deletion of pages within the scope of the sanction" reflects my sentiment. I am not sure whether the community at large actually feels that sanctions do not allow deletions. To me '.. or any other reasonable measure that the enforcing administrator believes is necessary and proportionate for the smooth running of the project' can mean that an administrator can believe that a 'reasonable measure' is a deletion of the page in question (as it may be to revert the addition or removal of material - this is the ultimate 'removal of material' which we do allow). Encoding this in this way as described in this RfC would mean that we generate a conflict out of an unclear situation where an administrator cannot apply the measure that they believe proportionate on pages which are (often) created in violation of our m:Terms of use/WP:NOT. I agree that there may be other reasons to delete it (G5/G11), but if an administrator thinks it needs to be deleted with rationale of a sanction, then any possible undelete discussion belongs with the sanction. (and I see no problem with having deletion review possible under the general sanctions). --Dirk BeetstraTC13:52, 28 April 2019 (UTC)
Support – Thryduulf nails it. "Reasonable measures" should not include deleting a page. If it doesn't fall under a CSD, it should go through XfD. All deletions should be reviewable at DRV. (I also agree with Iffy's proposed language above.) Levivich15:11, 28 April 2019 (UTC)
Support mostly by Thryduulf although in the spirit of WP:IAR, I would caution that it's impossible to predict whether there might be future situations where immediate deletion is required without it being codified at WP:CSD. So there might also be cases where GS require immediate removal of a page, ideally followed by discussion. But in almost all other cases, deletion should follow the established policies, so it makes sense, to amend the policy as proposed. Regards SoWhy15:58, 28 April 2019 (UTC)
The question is not whether deletion would never be necessary in an emergency--there are times it will, and they will fall within oversight. The question is whether it will ever be necessary as a enforcement of a community sanction. The purpose of doing something as a sanction is to prevent another admin from restoring it, and any time such prevention is necessary the oversighters will do it under their established procedures. There is no reason for any other admin to. DGG ( talk ) 16:58, 28 April 2019 (UTC)
SupportOppose [tentative] -- I have read the original statement four or five times and I still can'tcould not tell what it means. It appears that the current guidelines are either unclear, ambiguous or contradictory. Rather than add more language that might add even more confusion, I suggest we clarify the existing guidelines, and re-write them in clearer English that does not require years of experience on Wikipedia to comprehend. (See my question below.) --David Tornheim (talk) 19:34, 28 April 2019 (UTC) [revised 13:53, 29 April 2019 (UTC)]
Thanks for the revised statement that is much clearer, and thanks for the extensive explanation added below at my request. The first sentence is clear. I agree with those who support this RfC that we should not allow community sanctions to make it easy to delete articles.
I am still somewhat uncomfortable with adding so much text to the guidelines--the last two sentences may not be necessary (if sufficiently covered by speedy deletion). However, I do understand the purpose of this RfC is to avoid any uncertainty about the more recent issue. Perhaps, rather than add those two sentences into the guideline (making it more difficult for inexperienced editors to read), we simply make it more like a court case judgment of the RfC and refer to this RfC for more information (like providing an Annotation#Law). After this RfC is over--settling the recent issue--I may support some tweaking of the language to make it as simple as possible. Either way, this is a vast improvement. Thanks for all the recent work. Therefore, changing my iVote to support. --David Tornheim (talk) 13:53, 29 April 2019 (UTC)
Support Though like David I was very confused by the current wording. @Cunard: what do you think of rewording the first sentence to:
Administrators may not delete pages or media within the scope of a community general sanction without a deletion discussion unless the page or media falls under the criteria for speedy deletion.
I think what confused me is that I thought I was reading about what Administrators may do under community sanctions when I was instead reading about what they cannot do. I think this wording makes that clear earlier on in the paragraph. Wugapodes[thɑk][ˈkan.ˌʧɹɪbz]23:34, 28 April 2019 (UTC)
Oppose I'm on board with the general sentiment as well, but I don't have any problems with deletions under AE. They should be very rare. I'd personally like to see some sort of policy where in the case of a contentious deletion a reviewing admin can submit the deletion to deletion review. SportingFlyerT·C07:08, 29 April 2019 (UTC)
@Hobit: I don't think that is the point. The cases are probably/likely rare where an editor is in strong conflict with one of these sanctions, and where deletion (in case of the crypto-sanction) cannot be deleted as being in violation of an already placed ban, or that the article is plain advertising (i.e., a regular speedy). We may indeed hardly ever / never use it, but shutting it down may result in material that needs a lengthy process to delete (if the speedy don't apply). We would revert content, and I see here a deletion as a 'revert to nothing'. So it would be appropriate to blank the article under a sanction if an editor created the article? --Dirk BeetstraTC06:27, 30 April 2019 (UTC)
Support, as a participant of the original discussion at Wikipedia:Deletion review/Log/2018 July 9#Universa Blockchain Protocol. To me, the whole wording of WP:GS/Crypto (before the “additionally” item covering the pages explicitly, and as an exception from the other sanctions) is to give the administrators a better tool against *editors* harmful for Wikipedia, not against the *pages*; thus an attempt to expand the “or any other measures” from “virtually everything applied to the harmful editor” to “virtually everything” seems far-fetched. Honeyman (talk) 18:20, 29 April 2019 (UTC)
Support, G5 already authorizes deletion of pages created in violation of specific sanctions, but simply falling under general sanctions isn't a license to delete whatever one may want. SeraphimbladeTalk to me22:41, 29 April 2019 (UTC)
I will note that Abecedare's comment below is important and we still need a bit of tweaking. But the idea is there and clear now. Hobit (talk) 23:02, 29 April 2019 (UTC)
Support (the revised version). Sometimes it takes a new-ish kind of dispute, like abuse of WP by blockchain spammers, for us to notice a hole in our policies. Such holes need to be patched despite not resulting in a problem in 2005 or 2010 or whenever. Now that this one's been identified, publicly, it's just a matter of time before it's exploited (with the best of intentions of course). — SMcCandlish☏¢ 😼 23:24, 29 April 2019 (UTC)
Oppose. Most of the support for this idea seems to be based on the ideas that (1) deletions can be handled at XfD and (2) they can be reviewed at DRV and that there is nothing wrong with these processes. But community sanctions are authorised where community processes for resolving disputes have already broken down and are already ineffective. If noticeboard discussions about editor behaviour cannot be resolved because of deep divisions in the community, why should discussions about article deletion be any different? Even the deletion that kicked this whole thing off demonstrates this; if you filter out the procedural arguments, the remainder boils down to one side in favour of gun control who think the material should remain and another side in favour of the right to bear arms who think it should be deleted (though both sides will, of course, think that only one half of that characterisation is accurate). How will DRV effectively resolve this dispute? GoldenRing (talk) 09:48, 30 April 2019 (UTC)
I think you very much misread the source of the objection. It is that deletion policy is clear cut, as it should be, because it marks the boundary between ordinary editors controlling content and administrators being in control, and your out-of-process deletion was an insult to the respect afforded to deletion policy. Questions of deletion policy and practice have been reviewed and resolved at DRV, with all the community welcome to participate, since the early days of the project. Without claiming DRV is “perfect”, I do declare that it has worked perfectly well for most of the age of Wikipedia. Deletion of an old page directed to improving content pages was most certainly not an action suitable for solving a behavioural issue. How will DRV solve this? Solve what? The scope of DRV is to review deletions and deletion processes. In your case, DRV rapidly found consensus that you misread the the meaning and intent of WP:POLEMIC, on top of the most obvious observation that WP:POLEMIC is not one of the many WP:CSD criteria. The dispute was about your use of the delete button. The dispute about WP:DUE aspects of current coverage of gun control is not a dispute to be solved by a single admin deleting userspace material directed at addressing content. The rest of the objection lies with a rejection of the notion that ArbCom gets to vote in a massive power expansion of ArbCom delegated powers, powers for AE admins to ignore deletion policy, and to be unreviewable except by ArbCom procedures. —SmokeyJoe (talk) 12:21, 30 April 2019 (UTC)
How did the DS deletion of the firearms article resolve any dispute? Also, what harm would have come if it had been taken to MfD? What harm resulted from the DRV of that deletion? The DRV actually resolved faster and with less drama than the AE thread (still open). Which kind of directly disproves the notion that a GS deletion is needed to resolve disputes when community processes break down. AFAIK, there are zero examples of a DS/GS deletion working better than a DELPOL deletion, and at least one good example (the firearms page) of the exact opposite happening. Levivich03:36, 1 May 2019 (UTC)
Oppose This change is a solution to a problem that doesn't exist. Has there been an issue with admins deleting pages under sanctions? Is this being abused in some way? I don't think so. Red Rock Canyon (talk) 10:12, 30 April 2019 (UTC)
This is an actual problem. Admins have deleted pages citing these sanctions as justification, and there have been disputes about the validity of these deletions, in part because consensus on the subject isn't clear. See here for an example. Hut 8.521:06, 30 April 2019 (UTC)
Support the intention. Oppose the currently proposed wording, as being too awkward (even with the mid-RfC revision). Support the better wording provided by Abecedare in the Discussion section below. --Tryptofish (talk) 19:43, 1 May 2019 (UTC)
Oppose Seems like a solution in search of a problem. I have been following these several discussions, and I don't know that anyone has raised the case that there are enough of these that happen to warrant a policy statement on it. Also, the singular case that raised the issue has, not yet, been recreated by anyone, even those untainted by the original case. Surely, if the deletion was made in error, that would mean that someone would be able to create a decent, clean, and well-referenced article. Or at least a draft. we shouldn't create policy to deal with exceedingly rare situations, especially ones where it does not appear that the wrong thing was done. --Jayron3223:03, 1 May 2019 (UTC)
Support with the suggested adjustment below, Administrators cannot delete pages or media within the scope of a community general sanction without following the regular deletion process. Such deletions have no special restrictions on reversibility and can be appealed at deletion review. The original/revised language does not mention PROD, which is part of the deletion policy. --K.e.coffman (talk) 01:58, 2 May 2019 (UTC)
Oppose. I've never used or enforced community sanctions, but this strikes me as WP:CREEP. Changing policy because of one ill-advised AE deletion is excessive. If these things happen regularly, something like this could be considered. Sandstein 17:05, 4 May 2019 (UTC)
This proposed policy change is not because of an "ill-advised AE deletion" but because of a series of community general sanctions here. It is because of your DRV close at Wikipedia:Deletion review/Log/2018 July 9#Universa Blockchain Protocol recommending the creation of an RfC that we are here now. The AE policy change to bar deletions under the Arbitration Committee's discretionary sanctions will be in a separate petition/RfC from this RfC.
Support: Best wording proposed is that from Abecedare, the revised Cunard language is also a significant improvement on the original proposal, though the issue of PROD makes Abecedare's version best. Neither community GS nor AE should be used for deletions except in line with the deletion policy. EdChem (talk) 08:49, 5 May 2019 (UTC)
Oppose as currently proposed. This wording immunizes all articles in the topic area from PROD as well as any future deletion processes the community might see fit to establish. T. Canens (talk) 00:26, 6 May 2019 (UTC)
Oppose in part per T. Canens, and this does seem to be a creeping of policy. The current wording is certainly problematic, but I don't see the widespread problem it would serve even if worded more concisely. Dennis Brown - 2¢01:38, 6 May 2019 (UTC)
Support I generally support this, with two reservations. First, per the discussion below, this shouldn't be interpreted as effecting WP:PROD, and even as worded, I think reasonable editors/admins wouldn't see a problem with an unopposed prod deleting an article subject to community sanctions. Second, the community is of course free to provide deletion as a sanction for a specific case/area following discussion, and this change would only clarify that it is not available by default when the community authorizes general sanctions. Monty84504:18, 6 May 2019 (UTC)
Support per Thryduulf. Our deletion policy is very carefully considered and well developed; there is no reason for any other policy to override it or introduce conflicting provisions. It appears that any of the deletions done under the auspices of general sanctions were likely valid deletions under existing speedy criteria anyway, so there was no reason to cite general sanctions as a rationale and cause confusion about what to do next. Ivanvector (Talk/Edits) 15:07, 7 May 2019 (UTC)
@Cunard: - could I clarify that this is only relevant towards "can it be deleted by admins right here" - it doesn't state anything as to AfD justifications etc. I'm primarily concerned because there's an ongoing discussion about whether a PAIDCOI violation could be an AfD justification to delete - and I wouldn't want this to interfere with that. Nosebagbear (talk) 10:55, 28 April 2019 (UTC)
Correct. This RfC applies to only speedy deletions done under the authority of community general sanctions. It makes no statement about AfD justifications. Cunard (talk) 21:32, 28 April 2019 (UTC)
Question What effect will this have if it is passed other than to add the language proposed above? Will it make it easier or harder to delete pages? What is the existing guideline with regard to deletion that this new language is meant to change, clarify, comment upon, expand upon, etc.? I am not familiar with the dispute that caused this WP:RfC or what it is about the original guidelines are that are allegedly ambiguous and/or contradictory. --David Tornheim (talk) 19:13, 28 April 2019 (UTC)
It's arisen because an admin speedily deleted a page that wasn't within criteria for speedy deletion. He cited arbitration enforcement ("AE") as his grounds. There was an interesting discussion, and that particular deletion was reversed on several grounds. But there was doubt about whether, in other circumstances, it could have been permissible; and if so, where such a deletion could be appealed. Arbcom discussed this at length. On some of the points, Arbcom basically decided not to decide. On others it reached decisions that I would see as subobtimal. My friend Cunard's RFC is intended to clarify.—S MarshallT/C21:03, 28 April 2019 (UTC)
This matters because the speedy deletion criteria specify a narrow set of circumstances under which admins may delete pages without community discussion. On the other hand, deletions under general sanctions are too broad: Admins have the power to delete without discussion any page that falls within the scope of a general sanction like WP:GS/Crypto. A second reason this matters is that as DGG noted, "The purpose of doing something as a sanction is to prevent another admin from restoring it, and any time such prevention is necessary the oversighters will do it under their established procedures. There is no reason for any other admin to."
Normally a no consensus outcome of a speedy deletion's review would indeed have resulted in overturning the deletion. But this procedural direction (strangely, DRV itself doesn't seem to be policy?) assumes that all agree that normal deletion policy applies. Here, however, the very applicability of deletion policy (including DRV) is contested. As a result, I believe that we'd have needed at a minimum positive consensus to overturn an admin action under these circumstances, to take into account the concerns that we might be overturning a specially protected kind of sanction. As it is, I think a broader discussion will be needed to resolve this matter.
This RfC states that normal deletion policy applies to pages within the scope of general sanctions and deletions can be appealed at deletion review.
Additionally, any uninvolved administrator may impose on any page or set of pages relating to the area of conflict page protection, revert restrictions, prohibitions on the addition or removal of certain content (except when consensus for the edit exists), or any other reasonable measure that the enforcing administrator believes is necessary and proportionate for the smooth running of the project.
Does "any other reasonable measure that the enforcing administrator believes is necessary and proportionate for the smooth running of the project" include deletion without discussion of pages that do not meet the criteria for speedy deletion? This RfC says no.
The criteria for speedy deletion (CSD) specify the only cases in which administrators have broad consensus to bypass deletion discussion, at their discretion, and immediately delete Wikipedia pages or media. They cover only the cases specified in the rules here.
The RfC's wording does not say "Community general sanctions do not authorise speedy deletions" because that could be interpreted as barring this G5. Creations by banned or blocked users deletion from happening: (1) An admin under the authority of WP:GS/Crypto issues a topic ban against an editor from creating or editing cryptocurrency pages, (2) An editor creates a cryptocurrency page in violation of the topic ban, and (3) The admin can block the editor violating the topic ban but it is unclear whether the admin can delete the page under G5. The current wording of the RfC clearly allows that G5 deletion to happen.
Thanks to you and the others for the clarification. I don't have time to read it and digest it immediately, but as soon as I am back on Wikipedia, I'll take a thorough look and possibly change my iVote above. I hope these explanations are helpful to other editors as well. Thanks again to all for taking the time to explain. --David Tornheim (talk) 22:01, 28 April 2019 (UTC)
Thank you for asking for clarification to give me the opportunity to provide more context about why I am proposing this change. Cunard (talk) 22:16, 28 April 2019 (UTC)
Comment on draft language: The current language is inadvertently prohibiting Prod-deletion of any article in the community-sanctioned subject area. This can be remedied by, for example, simplifying the first two sentences to Administrators cannot delete pages or media within the scope of a community general sanction without following the regular deletion process. Such deletions have no special restrictions on reversibility and can be appealed at deletion review.Abecedare (talk) 19:05, 29 April 2019 (UTC)
Abecedare (talk·contribs) and Metropolitan90 (talk·contribs), I strongly support Abecedare's proposed language over the current language since I do not intend to bar those articles from being deleted through proposed deletions. I do not think I can change the proposed wording at this late stage of the RfC though, especially since it's already been changed once. Cunard (talk) 05:27, 5 May 2019 (UTC)
I understand the conundrum. I am pretty confident that none of the participants intend the proposal to prohibit PRODing of articles in DS area but, unfortunately, once a statement is added to wikipedia's P&Gs it tends to be interpreted quite literally. So I am not sure whether re-starting the RFC; changing the proposed-language and pinging the editors who have already !voted; or something else would be the best way forward. Perhaps the RFC close can explicitly note the intended interpretation? Am open to suggestions. Abecedare (talk) 05:42, 5 May 2019 (UTC)
If there is a consensus that pages cannot be deleted with a rationale like "Page-level sanction under community general sanctions", I think the RfC close can explicitly note the intention not to bar proposed deletions of articles within community general sanctions. This would allow the wording to be modified to what you have proposed. If necessary, we can run a second RfC to amend Wikipedia:General sanctions#Community sanctions to use the better language that you have proposed.
Agree with Abecedare above. The current language does not correspond with what I expect the proposer intended, and instead protects all articles in the relevant subject areas from proposed deletion. --Metropolitan90(talk)01:19, 3 May 2019 (UTC)
The PROD concern is an irrelevant distraction. The language should be fixed to remove the perceived problem, but no sanction would even require the PROD of an article that I can imagine. PROD is only for mainspace, and the PROD is removable by anyone for any reason. —SmokeyJoe (talk) 07:47, 5 May 2019 (UTC)
I agree that Abecedare's proposed wording is much simpler and much clearer. It can still be substituted, since it's just a clearer way of achieving the same result. DGG ( talk ) 16:59, 5 May 2019 (UTC)
an editor is clearly being informed that certain content is not to be added. They have been reverted on articles where they inserted that information.
as a result of that, the editor is creating an article with said content.
Albeit rare, there may be cases where that material cannot be deleted as promotional material or any other criterion fit for any of our speedy deletion criteria. 'Reverting' this material would basically mean: 'blank the article', as all these constructions that we are here trying to generate are plainly saying: you cannot use deletion as an enforcement tool, only revert their material. Your only option is hence to bring the material to AfD and leave it there for 7 days.
This is a rare scenario, but not completely unthinkable. In any case this is an IAR, whether you codify it down as 'never use deletion under a sanction' or not. Yes, there should be some form of 'deletion review' possible, and I encourage to have such a possibility mentioned (I would suggest a regular deletion review which gets properly advertised at AE and similar. --Dirk BeetstraTC07:01, 8 May 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
RfC about independent sources for academic notability
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.
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.
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)
@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)
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? - PaulT+/C18: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)
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. Rehman04: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. --Begoon04: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. Rehman11:11, 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. Rehman11: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. ‑ Iridescent11: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. Rehman12: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. ‑ Iridescent12: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. Rehman13: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? — xaosfluxTalk14: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.
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. — xaosfluxTalk14: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! Rehman14:52, 30 May 2019 (UTC)
Question on UK terminology
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!--Jayron3214:14, 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)
Woe to them which are but bunches of numbers!
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.
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)
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.)
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)
"Please do not touch" doesn't mean that the unexploded ordinance marked by this sign won't blow up in your face if you decide that "Do not touch" is merely an optional courtesy.
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. SportingFlyerT·C07: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.) SportingFlyerT·C08: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)
Naming convention policy - "U.S." vs. "American" in disambiguators
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)
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)
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". Rockstonetalk to me!21:54, 5 June 2019 (UTC)
Sandboxes, Drafts and Redirects
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. LizRead!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[thɑ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. bd2412T17: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? — xaosfluxTalk20: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. LizRead!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)
Use of "royalty-free" photographs from Shutterstock in Wikipedia articles?
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)
ACC backlogs
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.
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. ~ Rob13Talk03: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)
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)
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. SportingFlyerT·C12: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)
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 Mishehu13: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)
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)
Topicboxes
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)
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)
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)
.jpg)
_-_6.jpg){kind=link}
_Wroclaw_uniwersytet.jpg){kind=link}
