Wikipedia:Village pump (policy)

"WP:VPP" redirects here. For proposals, see Wikipedia:Village pump (proposals).

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

The policy section of the village pump is used to discuss proposed policies and guidelines and changes to existing policies and guidelines.
If you want to propose something new that is not a policy or guideline, use the proposals section.
If you have a question about how to apply an existing policy or guideline, try the one of the many Wikipedia:Noticeboards.

Please see this FAQ page for a list of frequent proposals and the responses to them.

« Archives, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197

New privacy policy, which does not mention browser sniffing

I'm troubled by the deceptive language in the Privacy Policy that was approved at the board meeting last week. I had pushed for and gained consensus for language in the new policy that made it clear that the privacy policy would not allow [clarifying edit: browser sniffing what I mean is browser fingerprinting, which enables persistent user tracking even when users try to stay pseudonymous, as described, e.g. here; it's a sort of extensive browser sniffing on steroids.] The language was added back in December when this was discussed AT LENGTH, HERE and stayed in the draft for weeks. Success! Then on the last day of the discussion period, it was removed by a staffer. Now we have a draft privacy policy that does NOT bar browser sniffing, does not indicate that browser sniffing may take place and yet claims to be maximally informative. That's an untenable situation. That's the bottom line. I've complained about this as Talk:Privacy_policy#Legally binding? when I noticed it, and was ignored. I have raised it with the board too. I hope the board adopts a new policy that is not misleadingly incomplete. I call on the community to pressure the board and WMF to approve a policy that is as honest as it claims to be. How invasive is browser sniffing/fingerprinting? Click here to see how trackable your browser becomes with browser sniffing techniques the privacy policy allows. --{{U|Elvey}} ^{(t • e • c)} 21:21, 10 May 2014 (UTC)

Agreed. Browser sniffing is a big issue as it can lead to uniquely identifiable information. Regards, Sun Creator^(talk) 22:55, 13 May 2014 (UTC)

@Elvey: Please clarify the first link. The linked page has no mention of the word "sniffing". --Redrose64 (talk) 09:17, 14 May 2014 (UTC)

Isn't browser sniffing currently necessary on Wikipedia, to determine whether the software serves up the Visual Editor to individual users, and to let the devs know how many users are using VE-compatible systems so they know where to direct their efforts? Banning the WMF from keeping track of how many users are using which browser, or which fonts are in common use among readers of Wikipedia, would hobble development. 188.29.164.13 (talk) 10:01, 14 May 2014 (UTC)

There is a difference between using statistical information, from data mechanically collected, aggregated and then the individual details discarded, and keeping the same data in such a way that it can be used for identification purposes.—Anne Delong (talk) 14:22, 14 May 2014 (UTC)

See clarifying edit, above. Sorry for the slow responses.--{{U|Elvey}} ^(t•c) 02:48, 22 May 2014 (UTC)

Well, I think if we want to be a little more accurate, the complaint here is that the privacy policy does not directly and explicitly mention browser sniffing one way or the other. It does not say that it is permitted. WhatamIdoing (talk) 18:17, 14 May 2014 (UTC)

What I wrote is: Now we have a draft privacy policy that does NOT bar browser sniffing, does not indicate that browser sniffing may take place and yet claims to be maximally informative. I did NOT claim that it says 'that it is permitted'. That's your straw man. --{{U|Elvey}} ^(t•c) 02:48, 22 May 2014 (UTC)

What you wrote was "New privacy policy, which allows browser sniffing", in the section heading. WhatamIdoing (talk) 17:16, 22 May 2014 (UTC)

For both technical usability reasons, and CU, I think it is exceptionally unlikely that browser sniffing would be disallowed, but we should be saying what we collect and why. Due to CU, we are almost certainly storing the information at an individual level for some period of time. Gaijin42 (talk) 18:39, 14 May 2014 (UTC)

There is a lot of difference between what CU stores and what EFF's fingerprint demonstration extracts. All the best: Rich Farmbrough, 15:29, 19 May 2014 (UTC).

Gaijin42:And yet it is something We will never use, according to the quote (normally displayed in blue) below. --{{U|Elvey}} ^(t•c) 02:48, 22 May 2014 (UTC)

Rich Farmbrough:Where is that difference documented?--{{U|Elvey}} ^(t•c) 02:48, 22 May 2014 (UTC)

For background on why we changed what we changed it may be helpful to read my original post discussing the situation. It is a bit long, but hopefully it will provide useful background. In a nutshell, when Verdy p asked "what about header X", we realized that the way we'd defined the problem was wrong: it was focused too much on one specific way of thinking about the problem, and didn't address the much broader set of information that could become problematic in the future. As a result, we broadened the definition of PII, so that it can include not just the four headers that we removed but other headers that might become problematic in the future. In other words, the complete set of changes made the document more protective of user privacy, not less.

More generally, we're well aware of the difficulties around sniffing, and have been working extensively with analytics and engineering to become much more aggressive in how we filter out some of the sort of information that makes EFF's demonstrations so effective. (For example, eventlogging and labs now automatically filter some of the most problematic fields from the user-agent string.) But because the term is ill-defined, and because it may change over time, the best way to address the problem is through training and an expansive definition of PII which can be made stronger in the future. Locking four fields into the definition, which may become obsolete, was not the right approach. Hope that helps clarify.

On a more personal note, Elvey, I just want to add that it isn't very helpful or motivating to call me "deceitful" (earlier discussion) or state that I and the WMF have not been "honest". I've given my entire professional career - basically my entire adult life - to free software and free culture; Michelle similarly. This does not mean our work shouldn't be questioned - we make mistakes like anyone else. (It was a question from a user that made us realize this mistake!) But evidence-free attacks on our motives and our integrity, or those of our coworkers, does not help you, us, or the movement. —Luis V. (WMF) (talk) 23:53, 20 May 2014 (UTC)

I've just added a inch of interleaved comments to reply to various discussion points above. In addition:

Luis Villa: I'm sorry. It was a shock to see the change I'd made reverted at the last minute. You are taking comments that were not meant to be personal or directed at you personally, because, well I was in shock and though I tried, I see that I failed to simply present the evidence and so was blown off. Again, I'm sorry. I can see how "With the changes LVilla has made, Wikimedia IS setTING a bad example and beING deceitful about what IT collectS" can most easily be seen as directed at people and not content, though I would hope you can see that it can be interpreted as about content, not people, too. Perhaps if I hadn't been blown off, and not given you the opportunity to take my use of the term "deceitful" to have been directed at you or the WMF, we'd be in a better place now. I should have spoken only of the text and the timing of the reverts, and, for example, left characterization of what that timing meant to the reader. That was my intention and was my recollection, though I have gone back and it looks like I did otherwise; I'm sorry. The resultant text does still seem deceitful to me. My claim that the text is deceitful was not presented evidence-free; I believe I've presented chains of evidence; I guess you think its chains all break down somewhere, but it's not fair to label it evidence-free. And it's not fair to accuse me of calling you or the WMF dishonest because I write, above, "I call on the community to pressure the board and WMF to be honest," because there's no accusation of dishonesty. There's no discussion of past behavior or actions of any kind. It's a plea to be careful regarding future action. If a policy that is deceitful goes into effect, then in a way I am being deceitful, because I'm a member of the community, and the policy is a statement by the community; that's true for all of us. Nonetheless, I've edited my language, above.

My first edit was a change that I made to the policy that was accepted and survives (diff). There are others. Please keep that in mind.

As I've said in other words before, if there's a case for this sort of browser-fingerprint-enabled invasive profiling, make it. If it's felt that the the views of the community on invasive profiling are less important than, and need for some reason to be weighed against the needs of the community to, for example, enforce consequences on policy violators, then the policy should say so. The policy shouldn't deceive users into thinking we don't and won't use this sort of invasive profiling. If it's only going to be for CU use, I would bet the community would be all for it. AFAICT, the Privacy Policy offers no such disclosure, no such case, and no such restriction.

Here's the CRUX of the matter: I was told by a WMF representative:

The EFF has a website called panopticlick that shows you how unique your browser is based on this technique.
This technique can be used to keep tracking people even when they clear their cookies after each session.
uffice to say, we will never employ this technique because it would violate our principle of collecting as little data as possible.
(source)

I edited the policy to reflect that statement: diff. That edit was reviewed by the staff, and remained 95% in place, through dozens of edits by WMF LCA staff, until the day before the comment period closed, when you removed it, without so much as aElvey to let me know!

If you've explained how the new policy reflects the statement quoted above, that We "will never employ this technique", I missed it or didn't comprehend it. Please try (again). If Drdee misspoke, say so. (Or speak up, Drdee.) Yes, I've read your "original post discussing the situation", Luis. You say that "the complete set of changes made the document more protective of user privacy, not less". I've taken another look to see if I can see what you mean this time. I see that you now use the term "user-agent information" and that you DO NOT DEFINE IT. It could be interpreted to include or exclude what panopticlick detects. I think a normal user would interpret it to refer to the user-agent string, but that's ONE of EIGHT browser characteristics that go into a panopticlick browser fingerprint. You say, "event logging and labs now automatically filter some of the most problematic fields from the user-agent string," (my emphasis) however https://bugzilla.wikimedia.org/show_bug.cgi?id=52295 is still open. AND again, we're talking about far more than just the user-agent string. You said that some of it is currently collected, but apparently avoided stating what it's collected for. You said what it could be collected for. Yet the policy says "We are committed to: Describing how your information may be used".

Well, let me ask you, point blank, on behalf of all users, since the policy doesn't tell us. What are our plugin versions, fonts available, HTTP_ACCEPT headers, and color depth information collected for? LuisV (WMF)You say they are collected (Well, you say that my sentence which said they are not collected is inaccurate, which amounts to the same thing.) On behalf of all users: What are our plugin versions, fonts available, HTTP_ACCEPT headers, and color depth information collected for (I also wonder how long are they kept, and who has access to them.)

The draft policy states, twice!: "we believe that you shouldn’t have to provide personal information to participate..." Let me ask you point blank: Does that mean you don't collect this information from non-logged in users? That's how I read it, but if the info is purely for CU purposes, that seems nonsensical. You redefined personal information but did you look over the policy to see what the implications of that redefinition might be? For example:

The draft policy states: We collect very little personal information about you. How does collecting our plugin versions, fonts available, HTTP_ACCEPT headers, and color depth information square with that claim?

How does it square with the statement, also in the policy, that "Unless this Policy says otherwise, you should assume that information that you actively contribute to the Wikimedia Sites, including personal information, is publicly visible and can be found by search engines"? Can you define actively contribute so that it's clear whether it includes browser fingerprint data or not?

There's the statement, also in the policy, that We may "disclose your personal information if we reasonably believe it necessary to detect, prevent, or otherwise assess and address potential ... technical concerns" That's loophole big enough to make most potential uses of personal information permissible.

I see it as a conflicting definition of personal information when you say (in the policy): "No other personal information is required: no name, no email address, no date of birth, no credit card information." That's a profoundly different definition.

I see it as a conflicting definition of personal information when you say (in the policy): "personal information (like your IP address)" too. That's a drastically, profoundly different definition. Is using all these different definitions of "personal information" consistent with the statement in the policy that "we want to be as clear as we can"?

A good norm I see in legal documents is that once you define a term, you print it in bold type whenever you use it. Please consider adopting that norm, or better yet, link to the definition.

Speaking of terms, I see you are still editing the policy. Please define in the policy what you mean in the policy when you say "aggregated". E.g. is a list of all the IPs I've ever logged in from "aggregated'? Arguably it is. Hopefully you have a narrower, specific definition in mind. Maybe one of you doesn't. Please define nonpublic information too. include these definitions, as well as the definition of nonpublic information found here, which ought to be linked to from the Privacy Policy, Access to nonpublic information policy, and the Data retention guidelines, which all use the term, or perhaps the definition should be moved into the Privacy Policy, which already has a definition section. I think that's a better place for it.

Very well.--{{U|Elvey}} ^(t•c) 02:48, 22 May 2014 (UTC)

Two things: one, I'm about to leave on vacation for my brother's graduation, so I can't reply to this in the depth I'd like to. I will try to return to it when I get back.

Two: specifically (but briefly), in response to "here's the CRUX of the matter": as I've said above and in my original explanation, we (including DrDee, who you talked with) made a mistake. The language he talked about with you was not protective enough: it didn't define the term sniffing; it relied on a handful of specific cookies that might be obsolete/insufficient at any point; and it was redundant to promises we'd already made elsewhere about how we'd handle personally identifying information, including sniffing-like information. We should have caught and understood the mistake earlier; ideally before we put it into the policy. I'm sorry that didn't happen. But it was a mistake. The new language will protect users better, protect users longer, and protect them more consistently with the rest of the policy. —Luis V. (WMF) (talk) 00:57, 23 May 2014 (UTC)

LuisV (WMF): Congrats to you and your brother. I look forward to your return, and a fuller response because I feel your response doesn't put to bed the issues I raise. The word cookies doesn't mean what you think it means. You claim it "was redundant to promises we'd already made elsewhere about how we'd handle personally identifying information", and other positive stuff about the policy, but I do NOT see where you quote from anything to support your claims and don't see where you address the negative parts of the policy that I DO quote. Please provide a fuller response, preferably before it's archived. Are you unwilling to see any language added to the policy to make it clearer? I don't think so, so please work with me on developing and agreeing on new language, instead of insisting it's not needed. --{{U|Elvey}} ^(t•c) 02:25, 24 May 2014 (UTC)

Genealogical symbols at German Wikipedia

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.

---

Hello, yesterday I've tried to start a discussion at Wikipedia talk:WikiProject Judaism#Genealogical star and cross in biography articles of the German Wikipedia, concerning the German Wikipedia, and whether wmf:Non discrimination policy applies to the case of using genealogical symbols. Since I think the topic requires a broader audience from outside the German project, but the WikiProject talk apparently is not very active, I wanted to mention the discussion here too, and ask for comments at Wikipedia talk:WikiProject Judaism, Rosenkohl (talk) 18:15, 15 May 2014 (UTC)

German Wikipedia is full of good faith editors who can figure these things out for themselves. If there is a legitimate legal issue involved, which you seem to be implying, then the proper thing to do is contact the WMF, but English Wikipedia has no business telling German Wikipedia what their policies should be, least of all telling them that what may be a traditional and culturally innocuous practice in German practice (cf swastikas in a Chinese WP Buddhism article) is actually discrimination. VanIsaac_WS^cont 19:06, 15 May 2014 (UTC)

So, you have lost a vote on your home wiki and now you try to get support for your point of view here? Sorry, your are not getting support from me. If have seen these symbols in use in several Dutch genealogical magazines for families of all religions, even Jewish and Muslim. I really do not see what the fuzz is about. The Banner talk 19:28, 15 May 2014 (UTC)

I do see what the fuss is about; but, in the past, I have found it fairly annoying when editors from the German Wikipedia have come here and vocally participated in discussions about our practices. It would be hypocritical to turn around and offer my opinion in one of their discussions. --R'n'B (call me Russ) 19:38, 15 May 2014 (UTC)

Aren't you legitimate user in another Wiki if you comment in its own language? As far as I am aware anyone can tell his/her own view in German Wikipedia in German. If you don't know German the problem just doesn't touch you and you don't have a reason to have an opinion about the topic. Fairly simple. --Gwafton (talk) 20:19, 15 May 2014 (UTC)

No, it's not enough to simply be able to write in a language. Unless you are a vested contributor, you shouldn't be flitting over to other wikis to tell them how they should do things. German Wikipedia is a community of its own, and going over there because of canvassing on English Wikipedia is equivalent to anonymous IPs responding to a 4chan or Reddit appeal for intervention here. VanIsaac_WS^cont 21:11, 15 May 2014 (UTC)

Excuse me, where did I imply "legitimate legal issue involved"? I'm not "canvassing" but inviting You to participate in a discussion.

No, I have not lost a vote. On the contrary, I've actively tried to stop and prevent each of the last three polls in 2010 and 2014.

Anyway, the point of any non discrimination measure in a democracy would be to protect the interests of a quantitative minority against the vote of a quantitative majority.

It is not just a problem of the German Wikipedia, but a problem between the German Wikipedia and certain real living people, often either church critics or Jews. A problem in e.g. China does disappear just because you don't know Chinese. The problem of genealogical symbols does not disappear just because You don't know German. If You did not learn to understand German, it does not mean that problems in German speaking countries like Germany, Austria and Switzerland do not exist for You, and that You can't have an opinion about it.

If someone expressly says that he wants no cross symbol in the biography of himself, his family or religious relatives, it is no "traditional and culturally innocuous practice" to put in a cross nevertheless, Rosenkohl (talk) 09:27, 16 May 2014 (UTC)

Rosenkohl The symbol † is not a cross, but a dagger. There is a distinct Christian cross glyph ✝ for those wondering. All the best: Rich Farmbrough, 16:08, 19 May 2014 (UTC).

The dagger is also called an obelisk; and since the "star" mentioned in the first sentence is properly called an asterisk, what we have are asterisk and obelisk. Sounds familiar? That was the inspiration for the names of the characters created by French writers Goscinny et Uderzo. --Redrose64 (talk) 16:43, 19 May 2014 (UTC)

Rich Farmbrough, of course the genealogical cross is a cross, and it is not christian; and I have explained the origin and use of the genealogical cross extensively, Rosenkohl (talk) 13:59, 20 May 2014 (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.

Getting rid of mispelling redirects

Several recent RfD discussions, and the research surrounding them, have brought me to the conclusion that redirects of misspellings no longer serve a purpose. The major search engines have gotten so aggressive about "do you mean..." searching that it can be hard to search specifically for the misspelled text. Therefore these redirects are producing a lot of clutter in the system which in practice is making even very unlikely redirects hard to clean up because they are supposedly "cheap" and therefore we get a lot of WP:USEFUL arguments if anyone makes any attempt to get rid of them. They aren't cheap in terms of time needed to deal with them, and in any case "cheap" is not "free".

I would like to propose that specifically discourage misspelling redirects, and that ideally it would be good to have a bot or some other cheap process to delete those that exist now. Mangoe (talk) 20:51, 15 May 2014 (UTC)

What about when I type an something in the search bar? Mediawiki's built in did you mean really sucks. Werieth (talk) 20:53, 15 May 2014 (UTC)

Which is why I don't use it except for certain specialized administrative searches. And these redirects only help if you happen to do the right sort of typos, which I as a rule don't— and my typing is terrible. Mangoe (talk) 14:39, 16 May 2014 (UTC)

So because it doesnt affect you it should be deleted? Rubbish. Werieth (talk) 14:45, 16 May 2014 (UTC)

The point is that there will always be orders more incorrect spelling variants than could ever be "covered" by redirects - and if someone would try to add them all, it would mess up the whole system. The whole idea of trying to catch misspellings via redirects is an exercise in futility. From the viewpoint of a system's architect, redirects are not the proper tool for this purpose - a proximity-based pattern matching algorithm for the search box would be. Just because some random editor unsystematically misspelled a title when he created an article without much thought should not put the burden on us to maintain a silly redirect forever as it unfortunately happens in many cases. --Matthiaspaul (talk) 19:05, 17 May 2014 (UTC)

A good "proximity-based pattern matching algorithm" is cpu-intensive, and can only be an improved "DYM" engine. If people create redirects when they make a typo, the CPU impact is effectively zero the maintenance impact is almost zero, and the effectiveness is extremely high, because people tend to make the same typos other people make. All the best: Rich Farmbrough, 14:58, 19 May 2014 (UTC).

What about customer care? Those redirects are there to help visitors. The Banner talk 21:16, 15 May 2014 (UTC)

And they don't: that's my point. What helps is the use of external search engines, which do a better job with no overhead on our part. Mangoe (talk) 14:39, 16 May 2014 (UTC)

So I should use a third party resource that tracks my movement and records everything and then sells it to the highest bidder? Again rubbish. I shouldnt have to rely on third party tools to use wikipedia. The use of a known third party that treats privacy as a joke is not something Im willing to do. There are times when I want to read up on a topic without big bother recording what I search for and what pages I visit. Werieth (talk) 14:45, 16 May 2014 (UTC)

No, relying on a third-party resource would not be the right solution to the problem, either. Instead, we should improve the implementation of the search box and its "Do you mean" feature rather than trying to misuse redirects to cover up the problem - which simply can never succeed, unless we would add dozens or even hundreds of redirects from misspellings to each article. The point here is, let's not try to ad-hoc work around a problem manually, which a computer can be programmed to do automatically and much better and more systematically, while remaining easier to maintain and improve upon in the future at the same time. --Matthiaspaul (talk) 19:05, 17 May 2014 (UTC)

I agree. You should improve the implementation of the search box and its "Do you mean" feature. But until then let's keep redirects. 97.94.188.47 (talk) 03:36, 27 May 2014 (UTC)

In most cases, they don't help, but have no positive effect at all, because the probability of someone else misspelling a title in exactly the same way is small - redirects from misspellings exist only for a very low percentage of possible misspellings.

There may be a few very common misspellings (ranking close to WP:ENGVAR), where a redirect from a misspelling may help, but these obvious cases are typically also covered by "Did you mean", already.

Also, it is never good to keep people uneducated about their errors, because thereby they will continue to repeat their errors and even spread them around more. External search engines may pick up such redirects from misspellings as well, multiplying the damage by increasing the number of hits for misspellings in the net. As a result, people seeing those misspellings everywhere, may develop problems to tell correct from incorrect apart. --Matthiaspaul (talk) 19:05, 17 May 2014 (UTC)

Redirects aren't just for searches. They are also there for misspelled wikilinks. While it would be interesting if misspellings ended up as redlinks, it makes for a bad experience on wiki. Having redirects for misspellings, and a template to tag them with, enables bots to go around a fix those misspellings. So having these redirects, and having them properly tagged, actually helps to fix the only problem here, while deleting redirects from misspellings actively thwarts the processes that we have on this wiki for mitigating the problem. VanIsaac_WS^cont 21:30, 15 May 2014 (UTC)

The thing is, those misspelling redirects also exacerbate the problem, because they discourage fixing certain typos by not redlinking them. In any case, if there is a bot which removes these redirects, it can also correct the references as well. Mangoe (talk) 14:39, 16 May 2014 (UTC)

If the redirects are correctly categorized as {{R from misspelling}}, that should make it easier to fix mistaken links. Removing the redirects seems unhelpful. older ≠ wiser 14:59, 16 May 2014 (UTC)

Exactly. And if I knew how to write a bot, there would soon be one going around and fixing them. As it is, we are waiting around for one to appear. But removing the redirects only prevents this solution from ever becoming reality. VanIsaac_WS^cont 21:42, 16 May 2014 (UTC)

• "producing a lot of clutter in the system" – Deleting them will actually add to the amount of "clutter" in the system, because "deleted" pages aren't really removed. They're just made invisible to normal users.
• "They aren't cheap in terms of time needed to deal with them" – What time? You shouldn't have to do anything at all with them. You ought to be able to ignore them completely. WhatamIdoing (talk) 18:13, 16 May 2014 (UTC)

You have to deal with them whenever you check and organize incoming links into an article. They are an annoyance, and they do cost time and energy for maintenance - forever - until they get deleted. --Matthiaspaul (talk) 19:05, 17 May 2014 (UTC)

I'm not sure about the maintenance argument. In the last few weeks redirects with no edits in 8 or 9 years have been listed for deletion. It would be useful, perhaps, to generate some statistics in this regard. All the best: Rich Farmbrough, 14:43, 19 May 2014 (UTC).

• I support the idea of deleting them and instead more systematically create redirects with valid and likely spelling and capitalization variants even an improved search-box pattern matching system may not be able to come up with by itself. Encourage the good, suppress wrongs.

Perhaps we should distinguish between likely and unlikely misspellings. At least all redirects for unlikely misspellings and miscapitalizations should be deleted, whereas those from likely misspellings (that is, which are really entered by a significant portion of the target audience) could be replaced by a soft redirect - like in the German Wikipedia, where a message on the soft-redirect page tells the user that he made an error and suggests an alternative. The user can then choose to click the given link or enter the title again. A deliberate, but mild inconvenience, but it helps people to become aware of their mistakes and thereby reduces the likelihood that they will repeat their error. --Matthiaspaul (talk) 19:05, 17 May 2014 (UTC)

It's already the case that unlikely misspellings are distinguished from likely ones - there's a whole speedy deletion reason for implausible typos (WP:R3). I'm all for improving the search function but I share the sentiments of the editors above who see no need for such a 'clean up'. Sam Walton (talk) 20:27, 17 May 2014 (UTC)

I have long been of the opinion that the {{Redirect from misspelling}} or the Category:Unprintworthy redirects offers the possibility to significantly improve the user interface with respect to redirects. Matthiuspaul's comments above suggest an additional way to utilise this, by suppressing them on "whatlinkshere" listings as a default. All the best: Rich Farmbrough, 14:43, 19 May 2014 (UTC).

Capitalization of titles

I recently moved a couple of articles Security Token Service Credential Service Provider to correct the capitalization of their titles, per WP:NCCAPS. I noticed that almost every article shown on Template:IPstack is non-compliant, and was wondering if there is an exception for technical articles which are more commonly referred to using their acronyms. Or am I possibly interpreting the guideline incorrectly?Timtempleton (talk) 00:36, 17 May 2014 (UTC)

The reason is that the defining documents (RFCs) capitalise the protocol names. Whether this is sufficient reason, I am not decided, but it is not a conflict I wished to engage in when I noticed the same thing a few years ago. If you want more clarity, or to start a decent discussion, you could try the talk page of WP:MOSCAPS I think it is. They may still be punch-drunk from finally resolving the bird common name capitalisation though. All the best: Rich Farmbrough, 23:10, 17 May 2014 (UTC).

Not intending to sound like the bird people, a named protocol is an obvious proper noun, isn't it? The difference between an internet protocol and the Internet Protocol is as big as the difference between an epic movie and Epic Movie. 67.165.188.96 (talk) 00:54, 18 May 2014 (UTC)

The concept of a proper noun, which we all learned at our teacher's knee, turns out to be as slippery and elusive as an eel coated in vaseline to flock of penguins wearing teflon coated mittens. ( "Vaseline"? "Teflon"?) We (English Wikipedia) have, for example, always said "Internet" when referring to the Internet. Common usage seems to be changing to "internet". But you are absolutely right, the protocols are viewed (maybe correctly) as proper nouns and I should have said so - my take on it is still that I am not convinced either way and it is probably best not to worry about it. Another example is Demand Note - I still don't think this is a proper noun but having raised it at the talk page, it did not seem worth pursuing. All the best: Rich Farmbrough, 15:16, 19 May 2014 (UTC).

The RFC are proper nouns, so they should be capitalized. Now, it may happen that a certain RFC name is also used in other propocols. --NaBUru38 (talk) 16:38, 19 May 2014 (UTC)

Certainly the names of the RFCs should be treated as we treat all titles. Just as unambiguously we refer to The Lord of the Rings or in running text about the work the Lord of the Rings, but talking about Sauron we may say "he is the lord of the rings". All the best: Rich Farmbrough, 17:54, 19 May 2014 (UTC).

I wasn't aware of the RFC connection. That would explain it, except (that I'm aware of) for the DSL articles such as Asymmetric digital subscriber line, all spelled with title caps on the RFC [[1]], but spelled using sentence case on the Wikipedia articles (at least on the US versions of the articles). Sounds like the first step would be to modify WP:NCCAPS to explain the exception, and then attack and move all the DSL articles? And while we're traveling down this hyperlinked rabbit hole, why not merge WP:NCCAPS and WP:MOSCAPS? Anyone ever succeed in reducing rather than expanding the number of different style guideline articles?Timtempleton (talk) 18:52, 22 May 2014 (UTC)

Admins are special

"If you suspect sock puppetry by an administrator, or if you need to submit off-wiki evidence for some other reason, you must email the CheckUser team or the Arbitration Committee to open an investigation."

This text is in the header at WP:SPI, it is not something I was previously aware of. Is it now policy that all admin sock-puppetry is the domain only of the arbitration committee? And if so why?

All the best: Rich Farmbrough, 23:12, 17 May 2014 (UTC).

It looks like that language dates back to 2009, from this edit by MuZemike (talk · contribs). Looking at the talk page for around that time, I do not see any specific discussion about incorporation of this note into the instructions. From a practical standpoint is might be a good idea, given the seriousness of the charge (does SPI have the authority to desysop?) and the potentially disruptive nature of admin tool misuse. VQuakr (talk) 00:04, 18 May 2014 (UTC)

The idea is that if there's shenanigans by admins, you need to fast-track the investigation, and not let it sit around on a noticeboard for someone to come along and decide to deal with. --Jayron32 02:29, 18 May 2014 (UTC)

Thanks, those are good points. I'm not sure they carry the day for me. Another point superficially in favour is ArbCom's supposed knowledge of legitimate admin socks, and of clean start accounts. On the flip side combining the words "fast" and "ArbCom" with a straight face is rather difficult. Secondly in the only socking case I have seen them handle they revealed the private information that they had been given, and took no action - turning a potential WP:clean start into a WP:Outing - (a case, though, which handled correctly would have supported the change). Thirdly there are governance issues with the "judicial branch" being the "investigative branch". Fourthly transparency is good - if someone makes a socking claim against me, I would like it to be in the open, so that if it forms a pattern of claims it is documented. Possibly it is reasonable that any sensitive socking case can be submitted to arbcom instead of at WP:SPI, who should then instruct a volunteer SPI/Checkuser to investigate privately.(already says that can be done) Any more thoughts? All the best: Rich Farmbrough, 21:09, 18 May 2014 (UTC).

To answer every one of your questions, there's a distinction to be made with the plain intent of a particular procedure, and the individual people who are tasked with undertaking it. The best intended procedure is not at fault if you have a beef with the individual people who do something you don't like. If your problem is with a person, take it up with the person. Don't argue with the plain intent of any particular procedure or institution. In other words: If you don't like what a person did, tell them. Calling a common sense rule "unjust" is a pointless thing. The rule is intended to handle the problem of admin abuse expediently and quickly by referring it to people who have the tools to deal with it quickly. If you found someone did something you don't like, don't waste your time finding fault with good procedures, instead, take it up with the person who did the thing you didn't like. --Jayron32 23:14, 18 May 2014 (UTC)

Let's say that it is confirmed that some admin has used sock puppets. Does it automatically mean that the admin must cease being an admin, or does it depend on how grave was the fault? Cambalachero (talk) 03:02, 19 May 2014 (UTC)

Several admins - myself included - have more than one account. In the case of Redrose64a (talk · contribs) it's so that I can make tests from the point of view of a registered but not autoconfirmed user - the minimum privileges without actually being logged out. You may notice that Redrose64a has only one edit recorded - I do what testing I can without actually clicking "Save page", in order to avoid becoming autoconfirmed. --Redrose64 (talk) 08:37, 19 May 2014 (UTC)

Cambalachero - no, there are legitimate uses for sock puppets (and multiple accounts). Secondly there are uses that are not specifically listed as legitimate but are not abusive. Thirdly even technically abusive socking might be ignored under WP:IAR. And finally "how grave the fault" might apply. Nonetheless I doubt a significantly abusive admin sockmeister would keep their bit, once discovered.

Jayron32 I have not found a socking admin. I agree it is far better to query "rules" when one is not using them, as one is not perceived as having an axe to grind. This is a council of perfection, of course.

All the best: Rich Farmbrough, 09:47, 19 May 2014 (UTC).

Another reason the existing text may have been worded that way is for users who believe they have been blocked by an admin pursuant to a dispute with a sock of that admin. All the best: Rich Farmbrough, 14:24, 19 May 2014 (UTC).

I propose changing the text to ""If you need to submit off-wiki evidence you may email the CheckUser team or the Arbitration Committee to open an investigation." All the best: Rich Farmbrough, 09:52, 19 May 2014 (UTC).

I don't understand your complaint. It says, "you must email the CheckUser team or the Arbitration Committee to open an investigation" (emphasis added). Your complaint says, "Is it now policy that all admin sock-puppetry is the domain only of the arbitration committee?" The words "the CheckUser team or the Arbitration Committee" do not mean "only ArbCom". WhatamIdoing (talk) 16:16, 19 May 2014 (UTC)

I'm slightly baffled too. The 'or' says that either body may be mailed. Personally, I'd think it best to mail the CU team in the event of suspicion, and would suggest that that wording be left in place. I assume that 'off-wiki evidence' refers to stuff you wouldn't want all and sundry to read concerning goings-on here rather than what Fred said to Dinah on IRC or Facebook. Peridon (talk) 17:42, 19 May 2014 (UTC)

@WhatamIdoing and Peridon:

• You are absolutely right about the "or" - though bear in mind CheckUser is wholly or substantially (I forget) in the gift of ArbCom.
• It's not a complaint, its a query. Note that I have advanced several reasons in support of the wording.
• Yes I read "off wiki evidence" the same way, but you are right it's ambiguous and "evidence off-wiki" would be far better. I'll change my proposal. Any other improvements welcome.

All the best: Rich Farmbrough, 18:06, 19 May 2014 (UTC).

Your characterization of the relationship between Arbs & CUs is incorrect. While Arbs are generally made CUs - unless they ask not to be - there are more CUs that aren't Arbs than there are who are Arbs. So whatever your rather obscure language "in the gift of ArbCom" is meant to insinuate, it ain't so. BMK (talk) 02:10, 25 May 2014 (UTC)

I propose changing the text to ""If you need to submit evidence off-wiki you may email the CheckUser team or the Arbitration Committee to open an investigation." This is simpler, clearer and doesn't discriminate between "admins" and "muggles". All the best: Rich Farmbrough, 18:07, 19 May 2014 (UTC).

• Support This sort of distinction should not exist. I think the rule was in place on the presumption that admins have a conflict of interest to protect other admins. If that happens it is nice to have another channel, but when that is not a concern, I think making the regular channels is the natural choice. Blue Rasberry (talk) 19:30, 19 May 2014 (UTC)
• Support - The distinction can be construed as affording unequal protection. ChrisGualtieri (talk) 21:32, 23 May 2014 (UTC)
• Oppose - Rich, stop screwing around and go back to productive editing. Just because you can't use automation doesn't mean you can't help build the encyclopedia. BMK (talk) 02:11, 25 May 2014 (UTC)

People who are only known for having a rare skill

I'm trying to determine how viable it is for someone to be considered notable if they're only known for having a rare skill. This is in relation to an AfD in which the person in question has many independent secondary sources written about him, but the sources all feel sensationalist in nature and give no indication of importance to the subject other than the rare skill. My feeling is that Wikipedia is not the place for sensationalist articles, even if the usually-reliable secondary sources choose to publish them. I can't find any policies, guidelines or articles that cover this. The AfD in question is here. —gorgan_almighty (talk) 20:15, 19 May 2014 (UTC)

What do you think about Uri Geller? --Why should I have a User Name? (talk) 21:17, 19 May 2014 (UTC)

I think he is "well known internationally as a magician, television personality". He made a public career out of his skill and became a notable entertainer. None of that is true in this case. —gorgan_almighty (talk) 21:35, 19 May 2014 (UTC)

The key to understanding Notability is this... Notability isn't really about what someone does ... its about how many other people (ie sources) have noticed and commented on it. Two people may have the same skill... if person A gets good coverage in sources, and person B does not... then person A is notable while person B is not. Blueboar (talk) 22:07, 19 May 2014 (UTC)

Hmmm, perhaps. I used to believe that as well, but a closer inspection of the GNG suggests otherwise. See my comments on the AfD in question. —gorgan_almighty (talk) 22:17, 19 May 2014 (UTC)

If you're looking for an unambiguously notable example, Kim Peek rightly has an article due to his rare talent for memorizing things. I don't have a strong opinion about the article currently at AfD, but at first glance that guy clearly isn't as notable as Kim Peek. The Blade of the Northern Lights (話して下さい) 21:10, 20 May 2014 (UTC)

How to propose a VP ban

How and where would one go about proposing the banning of a specific editor from Village Pump? For obvious reasons, I will not provide details for now, so don't bother asking and please don't bother commenting if you can't accept that. What venue would be the correct one if the problem isn't related to blatantly obvious policy violations? --89.0.229.165 (talk) 13:13, 20 May 2014 (UTC)

Start by creating a policy that makes it a blatantly obvious policy violation. Than get the policy approved. JeepdaySock (AKA, Jeepday) 15:27, 20 May 2014 (UTC)

The only reason to ban someone from the pump is if they are being routinely disruptive to the various discussions that take place here... and we already have plenty of policies against being disruptive (no need to write a new one). The correct action is to bring the disruptive behavior to the attention of administrators by outlining the problem at WP:ANI. Blueboar (talk) 16:06, 20 May 2014 (UTC)

Probably a topic ban discussion should be raised at WP:AN. Alanscottwalker (talk) 17:39, 20 May 2014 (UTC)

Changes to template {{policy}}

An RFC has been started at Template talk:Policy#RFC for change to this page regarding changes to a widely-used template. Please contribute if you have an opinion. --Jayron32 12:38, 21 May 2014 (UTC)

Proposal to bar IPs and newly created accounts from restarting contentious discussions

There are certain controversies on Wikipedia that invariably spark heated discussion - for example, the multiple proposed moves for Sarah Jane Brown and most recently for Hillary Rodham Clinton, and the neutrality of the List of scientists opposing the mainstream scientific assessment of global warming. Because of the volatility of these issues, they are fertile ground for anonymous trolls to cause trouble merely by proposing a move. For example, User:71.59.58.63 proposed moves at a number of pages that had already been the locus of contentious discussions (Hillary Rodham Clinton, Chelsea Manning, Chad Johnson (American football), State of Florida v. George Zimmerman). I therefore propose that: if a topic has previously been the subject of two or more move requests, deletion discussions, or other such process, then no IP or newly created account shall be permitted to initiate a new effort to carry out such a process. This will not bar an IP from participating in such discussions, or from proposing on the appropriate talk page that someone else initiate the process, but the IP editor would not be able to initiate the process of their own accord. bd2412 T 19:29, 21 May 2014 (UTC)

• Strongly support. Something like this is clearly needed. At the Hillary Rodham Clinton talk page, four move requests were launched this year, all by IPs, three of them known sockpuppeteers. Three of the four proposals were frivolous and were closed fairly quickly; the fourth became a full-fledged discussion that has taken up many hours of Wikipedian time that could be better spent elsewhere. Serial trolling, like that which BD2412 describes above, is all too easy when the proposer can conceal his/her identity behind an IP. IMO a move proposal by an IP is very unlikely to be made in good faith; it is simply not credible that an unregistered user would know enough about Wikipedia to launch a move request, as these IPs regularly do. One thought: Perhaps rather than targeting IPs, we should make it a requirement that only autoconfirmed users can launch move requests, at least for articles whose title has been controversial. (Note that this restriction is already in place for AfD nominations.) BD2412, would you consider modifying your proposal to that language? --MelanieN (talk) 19:47, 21 May 2014 (UTC)
  • Done. It is trivially easy to create an account for the purpose of doing the same trolling one might do as an IP. bd2412 T 20:00, 21 May 2014 (UTC)
• comment Note that the user behind 71.59.58.63 was also using 76.105.96.92, and is now blocked for sock-puppetry, block evasion, and the behavior discussed in this thread. __ E L A Q U E A T E 20:50, 21 May 2014 (UTC)
• Strong oppose unless significantly modified. One of the principles of consensus is that consensus can change. We should not be allowing one consensus to prevent future discussion. Rather, we should be making clear that reiterating contentious discussions is often unhelpful unless new arguments, sources, etc. are brought to light. This might be done by visibly summarizing the contentious arguments involved—perhaps with a talk page template and a talk subpage summarizing the decision? If users attempt to revive a debate, the unproductive discussions can be informally closed as redundant unless there's new material to discuss. I can't more strongly oppose the "IP or newly created account" part, though: the purpose here is to regulate behaviour (promoting the good, discouraging the bad) and not to filter by identity. {{Nihiltres|talk|edits}} 21:14, 21 May 2014 (UTC)
  • In the case of IPs and newly created accounts (particularly newly created accounts that immediately launch into the re-initiation of past contentious discussions), there is no identity to filter; there is only a well-known vulnerability to trolling. Note that an IP/new account can always express their opinion on the matter, and if they have some previously unconsidered evidence or argument to present, they should have little trouble finding an editor to make the actual proposal on that basis. bd2412 T 21:18, 21 May 2014 (UTC)
    • bd2412: The idea that "In the case of IPs and newly created accounts […] there is no identity to filter […]" misconstrues my comment. They have an identity as an IP/new editor, or as an established editor. Requiring some users to jump through an extra hoop to propose something is not only needlessly discriminatory (behaviour is bad or good independent of identity), but also instruction creep. {{Nihiltres|talk|edits}} 21:51, 21 May 2014 (UTC)
• Neutral. It might be a good idea to restrict the re-opening of contentious issues to editors who have built up a bit of experience with the community, and this could help a little bit. However, it still wouldn't prevent a registered editor coming along and starting a new discussion with a trivial rationale, such as "this is a no-brainer", so I don't think it's the best approach.
  I think that we need a more comprehensive solution solution to the management of perennial debates, and this little step might be redundant if the bigger package was in place. Some of the ideas I think worth considering are

1. moratoriums, as implemented on some recent perennial discussions such as Genesis creation narrative
2. a pre-qualification system for re-opening such issues. For example, a nom may need to be endorsed by a given number of editors, or by some approval venue
3. Explicit warning that new nominations may be speedily closed unless they provide very clear grounds for re-opening a perennial discussion

If some combination of that sort of idea is in place, then IPs can be treated just like other editors. --BrownHairedGirl (talk) • (contribs) 21:47, 21 May 2014 (UTC)

I prefer the "explicit warning" (#3) among those options and would probably strongly support it, pending details. The first two options seem like they would result in instruction creep (How ought a moratorium be implemented? What requirements would pre-qualify a discussion?), while the third option seems to focus on making the process simpler by advertising and solidifying what's mostly existing practice. {{Nihiltres|talk|edits}} 22:25, 21 May 2014 (UTC)

• Support Agree with BHG, but as a preventative measure this is a valuable suggestion.--Ubikwit ^連絡 _{見学/迷惑} 22:22, 21 May 2014 (UTC)
• Hesitant support Nihiltres' objection, that this goes against the principle that consensus can change, is off the mark here. This isn't preventing consensus from changing, it is presenting new accounts from rebooting contentious discussions. Once an account has been around long enough that we can tell that a) they understand how the consensus system works, and b) that they're not a drive by troll or sock, there's no need for the restriction. I do have concerns about how this would be enforced, and what constitutes an account that is no longer new though. Should the barrier be autoconfirmed? Something greater? This is difficult to figure. Either way, brand new accounts have no business reopening perennial discussions, as they either don't understand how the status quo came to be as it is, or aren't really new to Wikipedia at all. Sven Manguard Wha? 23:18, 21 May 2014 (UTC)
  • MelanieN suggested autoconfirmed, which is easy enough to police, and with which I agree. bd2412 T 23:44, 21 May 2014 (UTC)

• Support - good idea, and the suggestion of making "autoconfirmed" the threshold is a practical one as well.Volunteer Marek (talk) 23:48, 21 May 2014 (UTC)
• Comment Thinking about this, and reading the comments, I think we can make this a lot simpler and more specific. Say "autoconfirmed". Eliminate "deletion discussions" because AfD nominations are already restricted to autoconfirmed users. Eliminate "other such process" as vague/blank check. Eliminate the requirement that the title be "contentious", which is not obvious (previous discussions may be archived). How about a simple parallel to the requirement for AfD nominations: "Only autoconfirmed users may initiate move requests". I'll put that into a separate heading so that people can comment on it separately and we will know which wording they are talking about. --MelanieN (talk) 00:55, 22 May 2014 (UTC)
• Weak oppose leaning neutral per WP:IPs are people too. Though IPs and socks can cause disruption, and have undoubtedly caused disruption in the cases mentioned above, I believe that they should still have the same rights as other editors when it comes to proposing changes on talk pages. Though the proposed rule would solve the problems listed above, I'm not 100% convinced that it would be a net positive overall. Socks and trolls are easy to spot, especially when they're not autoconfirmed, so it might be better to deal with them on a case-by-case basis. I do agree with the premise that trolls should not be re-opening controversial discussions. ~Adjwilley (talk) 01:07, 22 May 2014 (UTC)
• Oppose I'd like to support, but this seems like the wrong solution to the problem. Socking already covers users hiding behind IPs or new socks to repetitively reopen discussions. By disallowing IPs from reopening perennial discussions, I worry if it will encourage a quick slap on the likely sock instead of investigating for a sock master. It also biases against IP editors. It seems to me a better / more general solution would to consider limiting the frequency of new discussions on failed proposals, especially in cases where either result does not "harm" wikipedia. Closers of repeated failed attempts so be able to request either a time limit for new attempts or better require new attempts to include a novel point, shift in external sources, a policy/guideline change, visible shift of consensus seen in other areas, or the like. With the ability for such discussions that do not clearly feature such a point to be speedily closed. PaleAqua (talk) 01:09, 22 May 2014 (UTC)

• Oppose A fantastically bad idea that is so self-evidently bad that it argues against itself without me adding anything to it. --Jayron32 01:19, 22 May 2014 (UTC)
  • We don't allow IPs to conduct page moves precisely because of our experience with IP trolling/vandalism. Why should this be any different? bd2412 T 16:02, 22 May 2014 (UTC)
    • Because a discussion is not in and of itself the same as move vandalism? IP editors are allowed to edit and they are allowed to become involved in discussions. That one IP editor has made a habit of starting tedious move requests is an issue with that one editor, not with IP editors as a class. Resolute 16:09, 22 May 2014 (UTC)
      • Although we can characterize such issues as being issues with "one editor", with IP editors you really can't tell if one IP is really a dozen people, or if a dozen IP addresses are really one person. bd2412 T 16:14, 22 May 2014 (UTC)
        • A dozen user accounts could also be the same person. Resolute 16:26, 22 May 2014 (UTC)

• Weak support When I pointed out that editors of the Hillary Clinton article had no authority to ban IP editors from starting discussions at a specific article, I noted that I would likely support it as a site-wide policy. Joefromrandb (talk) 05:59, 22 May 2014 (UTC)

• Oppose. I see no reason to think that this will do anything except reinforce the general impression that Wikipedia considers IP's to be inferior contributors. If people are deliberately making contentious move proposals with the intention of stirring up trouble, they aren't going to be deterred from doing so by the minimalist requirements of autoconfirming an account. AndyTheGrump (talk) 16:42, 22 May 2014 (UTC)

• Oppose If someone abuses IPs or sock puppets to open a controversial discussion several times, the available policies are enough to deal with it. It is also possible that several genuine new users may open a common topic of discussion about an article that is in the news or highly popular and has two or more names, or whose name in wikipedia is not the name they may expect because of some other rule (for example, "Pope Francis" and not "Pope Francis I"; or "Nirvana (band)" and not just "Nirvana" for the band). In those cases, we would likely keep the consensus of a discussion which has already been held, but a new user would likely not know about such previous discussions. It may be better to place a banner in the talk page about the perennial discussion, the current consensus and a link to the discussion; as it won't sound as if "you are a lower editor and have no right to even voice your concern". Note as well that talk page discussions and article moves do not have the same potential for harm. If I moved "Barack Obama" to "abcdefghijklm", it would be a huge vandalism to the article, but if I open a move discussion proposing that, it would be silently removed and the article would remain unmodified the whole time. Cambalachero (talk) 17:00, 22 May 2014 (UTC)

• Oppose. Either a proposal is appropriate or it is not. Who makes the proposal should not matter at all. --В²C ☎ 18:05, 22 May 2014 (UTC)

Proposal alt.1

As a parallel to the current rule that only autoconfirmed users can make AfD nominations, I propose Only autoconfirmed users may initiate move requests. For reasons detailed above. --MelanieN (talk) 00:55, 22 May 2014 (UTC)

• Note: There is currently no rule that only autoconfirmed users can make AFD nominations. The paragraph in WP:AFDHOW starting with "Only a registered, logged-in user can complete steps II and III." explains the steps that even unregistered users can use to nominate an article at AFD. GB fan 01:17, 22 May 2014 (UTC)
• (edit conflict) Not exactly true. Anyone can start an AFD, even IPs. They need to request that someone create the page for them, but that is a technical restriction merely because they cannot create pages. Once created (which is usually granted automatically) they initiate the discussion and make the rationale like anyone else. IPs are not restricted from starting AFDs by rule. Regardless, any restrictions on who (IPs or user accounts) can initiate a discussion of any sort at Wikipedia is a fantastically bad idea and runs counter to the very core of Wikipedia's ethos, and for that reason I oppose on that grounds, even ignoring the false premise in the proposal. --Jayron32 01:19, 22 May 2014 (UTC)

Proposal alt.2

Closers are permitted to place limitations on reopening repeated discussions requiring that future discussions include a novel point, shift in external sources, a policy/guideline change, visible shift of consensus seen in other areas, or the like. Attempts to reopen the discussion without such reasoning may be speedily closed, and repeated attempts are to be considered disruptive editing. PaleAqua (talk) 01:09, 22 May 2014 (UTC)

• That's reasonable, so long as the limitations are not confined to any one class of user. Blanket moratoria on reopening discussions for a defined period of time is perhaps the best way to decide this, so long as it's neutral in enforcement (not singling out IPs). support --Jayron32 01:19, 22 May 2014 (UTC)
• Support Closers are already doing this, at their discretion. I like this proposal in that it does not attempt to impose any specific time limits or other requirements, just trusts the closer - and trusts the watchers of the article to enforce it. --MelanieN (talk) 01:31, 22 May 2014 (UTC)
• Oppose, and then some. Jayron's "fantastically bad idea" comment is quite appropriate here. Closers being given the authority to cement a supervote with an ex cathedra "case closed"? No thanks. Joefromrandb (talk) 06:06, 22 May 2014 (UTC)
  • This doesn't prevent closure reviews such as move reviews which would be one of the places to handle super vote abuse, and nothing here blocks other levels of escalation. Normally it is pretty obvious when a topic has reached the state where it has been raised a bit too often, and there will be plenty of comments to assert that that a closer can use to support such a limitation. The other thing is this is actually the defacto practice. I've seen several discussions closed with a moratorium, and attempts to bypass without a good reason results in snow closes. PaleAqua (talk) 06:23, 22 May 2014 (UTC)
    • In any case, closers generally impose this kind of moratorium in response to comment/consensus in the move discussion - not out of the blue. --MelanieN (talk) 18:38, 22 May 2014 (UTC)
• Conditionally support. Sometimes the passage of time itself can lead to changing views, without any tangible change in circumstances that a nominator might put his or her finger on. Furthermore, with hot topics and BLP subjects (for whom this seems to crop up more often), there will always be something new coming out in the news or in print that a nominator could point to as the shift or the novel point. I think that this is a good general limitation so long as it is understood that after some period of months or years, it evaporates. bd2412 T 16:00, 22 May 2014 (UTC)
• Oppose. In the rare extreme cases where repeated pointless proposals are actually a problem, the situation is handled by consensus. See Talk:Sega Genesis for one example of this. But a proposal like this would allow for muting proposals even when that's not supported by consensus. If this was in place a few years ago, Yogurt would still be at Yoghurt and they would still be bickering about it instead of it being at the stable undisputed title Yogurt, as it now is. --В²C ☎ 22:56, 22 May 2014 (UTC)
  • Consensus, even when clear, may be persistently ignored: see Talk:Daybreak (2010 TV programme)#Page Name and the five threads following that. --Redrose64 (talk) 08:31, 23 May 2014 (UTC)

LOL, I can't believe it - yogurt again! Yogurt always and forever in every discussion! I guess "when all you have is a hammer, everything looks like a nail." --MelanieN (talk) 18:17, 23 May 2014 (UTC)

• Oppose per Joefromrandb. Closing a discussion is merely an act of assessing consensus within the current discussion. It's not a supervote, and should never be allowed to overrule the concept that consensus can change. What special authority does the closing admin have that would allow them to make such a decision? We even allow non-admin closures in many cases, so it totally wouldn't work. —gorgan_almighty (talk) 15:34, 23 May 2014 (UTC)

Non-admin closures are irrelevant; NACs should not be happening for controversial proposals that have been through multiple discussions, and that is what this proposal is about. Generally this kind of moratorium is imposed only in response to consensus at the discussion. Sometimes in the course of one of these long-drawn-out, nothing-new-to-say-but-we'll-say-it-anyhow discussions about a title, people will comment or actually propose within the discussion that "some time should pass before we have to go through all this again." And that consensus is what the closing administrator is honoring when they add a moratorium to their closure. Always with an exception for new information or a new (not made at previous discussions) argument. --MelanieN (talk) 18:13, 23 May 2014 (UTC)

• Conditional support Allowing a time break after a discussion is closed is not inconsistent with consensus can change. Indeed, that policy says "On the other hand, proposing to change a recent consensus can be disruptive." I would like a defined and escalating interval between the same proposal being reopened, say starting with 3 months, and adding 3 months each time the same proposal fails. Admins might be given leeway to wave the interval if significant new circumstances are brought forward, e.g. the subject has changed their name to the previously rejected move's version. But individuals whose proposal has not been accepted should not be permitted to try to wear their opponents down by constantly bringing up the same proposal with the same arguments.--agr (talk) 22:54, 23 May 2014 (UTC)
• Oppose too much power to closers, consensus & snowball keeps work. 75* 21:01, 24 May 2014 (UTC)
• Oppose - Per Joe, this would essentially make a closer a sort of topic czar that would have continued authority on the development of the article in violation of WP:OWN. GabeMc ^{(talk|contribs)} 21:27, 26 May 2014 (UTC)

Arbitration Committee review of procedures (CU & OS)

By resolution of the committee, our rules and internal procedures are currently being reviewed with the community. You are very welcome to participate at WT:AC/PRR. Information on the review is at WP:AC/PRR. The current phase of the review is examining the committee's procedures concerning advanced permissions (and the appointment and regulation of permissions holders). AGK [•] 11:22, 24 May 2014 (UTC)

Participate in this review

CU bot

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.

---

For the beginnings of this conversation see Wikipedia talk:Sockpuppet investigations#How about a regular IP audit?

I think a check user bot would help combat socking while increasing privacy protection.

• Privacy - A check user performed by a human compromises the privacy of the account holder because the geographical location of the user is revealed to the CU. An automated CU bot would check an account or accounts for technical similarities while protecting the privacy of the checked individuals. If the CU bot fails to identify the same IP address editing the same page with more than one account no indication of socking will be made, but if the CU bot finds that an IP address is editing the same page with more than one account a red flag will be sent to CU. A CU then decides whether to look further for behavioral evidence.

• Socking - An automated bot would regularly search for violations of WP:MULTIPLE and alert a CU only when necessary while never revealing any IP information to any humans other than CUs who specifically ask for it, thus protecting the privacy of the checked accounts. An alternative to an automated bot that checks all accounts randomly would be to only use it at the discretion of an SPI clerk.

Any thoughts? GabeMc ^{(talk|contribs)} 21:08, 26 May 2014 (UTC)

• It is interesting, but this requires a bot with the CU bit, something that the community has never contemplated before. Granting a bot CU isn't a trivial thing and may require Foundation approval. Also, it can only maintained (and likely written) by someone with the CU bit, else they wouldn't have the access and experience. Who did you have in mind to do the heavy lifting? Dennis Brown | 2¢ | WER 22:07, 26 May 2014 (UTC)
  • I'm not sure who would write it – I certainly can't, but if will help save time and protect privacy then it might be worth pursuing. Why does anyone put hours of their free-time into the project? GabeMc ^{(talk|contribs)} 22:14, 26 May 2014 (UTC)

The main problem I can see is that for this to be useful, it would need to have far more false positives than false negatives (or be perfect). False positives can easily be ruled out when the result is double checked by a human CU. But if there's a high rate of false negatives, then human CUs would have to double-check most of the positive and negative results (i.e. all of the results), which kind of defeats the purpose. Of course, a high rate of false positives would be a bad thing for the second part (routine checks). It would probably need to have 2 different detection routines: A more conservative approach (looking for exact matches) for routine scans and a more complex one (looking for similarities) for targeted scans. The latter would be a lot harder to program as it would probably need to account for things like IP ranges, looking at WHOIS data to determine ISPs, comparing user-agents, open proxy scans, and looking up geographical locations. Mr.Z-man 22:42, 26 May 2014 (UTC)

I think having two "gears" is an inspired idea! The general (1st) for automated scans and the specific (2nd) that would be authorized by an SPI clerk or a CU. GabeMc ^{(talk|contribs)} 22:49, 26 May 2014 (UTC)

• @GorillaWarfare, Stwalkerster, FunPika, and Cyberpower678: do any of you think you could write such a bot, and if such a bot was written, is there anyway that the ACC process could make use of it to allow non-CU tool users to run CU type checks without the CU bit and without releasing any private information to the user? — {{U|Technical 13}} ^{(e • t • c)} 23:51, 26 May 2014 (UTC)
• Forget it. The foundation has already shot down CU bots. I recently had a discussion with the foundation about the idea of giving a bot CU.—cyberpower ^Chat_Online 23:57, 26 May 2014 (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.

"create an account" nag messages

I'm not sure if Policy is the right place for this and not proposals, but here goes. As someone who prefers editing as an IP, I find it very annoying that I'm now presented with a nag screen that suggests I create an account after each edit, blocking the view history button and search bar. Surely most people who can figure out how to click edit can see the create account button above it and are mature enough to make their own decision about creating an account without "helpful" prodding? 97.94.188.47 (talk) 03:27, 27 May 2014 (UTC)