Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Coldacid (talk | contribs) at 21:39, 6 April 2015 (→Comments?: replies to Opabinia & Biblioworm). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

New ideas and proposals are discussed here. Before submitting:



Should Wikipedia use HTTPS by default for all readers?

Many informative comments on both sides, without any real consensus. The most salient point is that this issue is highly technical and affects the performance and security of the site; therefore it is best left to the paid professionals of the WMF (see WP:CONEXCEPT). Therefore I close this discussion as "wrong forum". Interested parties may like to monitor the relevant workboard where active progress is being made. — Martin (MSGJ · talk) 12:08, 30 March 2015 (UTC)[reply]

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.

{{Request close}} Should Wikipedia redirect all readers (logged in or not) to the secure version of the site by default to help protect readers' privacy? Wikipedia currently supports it, but by default visitors are directed to the HTTP version of the site. Making HTTPS the default setting would prevent governments, internet service providers, and hackers from snooping on visitors' traffic and seeing what a reader is reading. Many major websites, including Google, have already implemented this a long time ago. This would have little effect on the viewing/editting experience, and according to Jimbo, it wouldn't be a difficult change to implement.[1] Tony Tan98 · talk 20:33, 16 February 2015 (UTC)[reply]

References

  1. ^ http://arstechnica.com/tech-policy/2012/09/jimmy-wales-threatens-to-encrypt-wikipedia-if-uk-passes-snooping-bill/

Clarification: This proposal is not asking the community to make a "final decision" about the implementation of this change itself. Instead, it is asking whether the community thinks that the WMF should consider a change from the current HTTP-default mode. Tony Tan98 · talk 19:47, 21 February 2015 (UTC)[reply]

No. Privacy is very important for me, but money (paying 20€ for 5GB bandwidth monthly) beats it. Besides all those wannabe-secure protocols turned out to be insecure snake oil in hindsight. Users should be free to skip this overhead if they don't want it, same idea as "web fonts" and other cruft best handled by Noscript, Adblockers, or /etc/hosts. –Be..anyone (talk) 02:39, 17 February 2015 (UTC)[reply]
Not if it can be avoided. An encrypted page is more difficult to cache, so ISP's can't just serve up a local copy and must go back to the WP servers each time. K7L (talk) 02:49, 17 February 2015 (UTC)[reply]
  • It's so necessary that I use the browser extension HTTPS Everywhere from the EFF which forces an encrypted end-to-end connection if the servers have the capability, which Wikipedia has. Every connection I make here is encrypted and I had forgotten that the default is plain HTTP. - Becksguy (talk) 05:55, 17 February 2015 (UTC)[reply]
If this is simple to implement, as apparently Jimbo said, then I strongly support this, for the reasons given by the OP. In response to Be..anyone, people would have a way to turn it off (create account, set prefs to HTTP) but I believe this change would bring more benefit to privacy-concerned readers who don't know how to or can't install add-ons to enforce HTTPS, than disadvantage to ones who don't want HTTPS for some reason. BethNaught (talk) 08:12, 17 February 2015 (UTC)[reply]
That becomes impossible. If https is blocked (as is likely in some countries), there is no way to create an account and change it to http. They have to get to the site. While Western nations think of this as an increase in privacy, people in totalitarian nations will find it's a reduction of access. --DHeyward (talk) 02:44, 20 February 2015 (UTC)[reply]
I understand what you are saying, but I think it would be an increase of access. If a nation is totalitarian enough to block HTTPS, then it would be at least also filtering HTTP traffic by keywords. If the country is filtering instead of blocking the entire site, it means that while the nation does not want certain articles to be read, it doesn't want to block WP entirely because of the academic articles. By moving to HTTPS by default, it is actually more likely that the government would want to unblock HTTPS than to block off WP entirely because every country has researchers and students that need access to good information, which WP has. China currently has one of the most restrictive firewalls, (besides the countries that completely block off the internet), yet it allows https connections to Wikipedia. It is not just a privacy issue; HTTPS prevents selective filtering and tampering of the site. Tony Tan98 · talk 03:09, 20 February 2015 (UTC)[reply]
No, I don't think it does. If they control the DNS table, network routes, firewalls, etc, they can do MITM intercepts and https gives a false sense of security. Does wikipedia have enough 3rd party trust certification (and does China allow it?). Nokia did this with their browser and proxies and stored the HTTPS requests as clear text on their proxies and played MITM for requests because they could. Once you start to layer on the necessary privacy features, it will limit what works for individual users. http will always work if https is compromised or blocked and should be the default. https is fictional security without 3rd part, trusted certificates. --DHeyward (talk) 04:33, 20 February 2015 (UTC)[reply]
Yes, they control DNS, network routes, and firewalls, but not certificates. This means that any interception will trigger a browser warning. Even if they do control certificate authorities, they would not use it for the purpose of censorship as it would leave undeniable evidence and lead to the revocation of CAs (Certificate Authoritys) under their control. In the case of China, even though they own the CNNIC CA, which is trusted in most browsers, they don't use it because if they illegally issued a false certificate, they will leave evidence (in the form of a saved .crt file) and their CA will be revoked. Thus, in HTTPS they cannot selectively filter content on a website that they do not control because they will not be able to decrypt the traffic or manipulate it without triggering warnings in browsers.
About the "3rd party trust certification," HTTPS uses the public key infrastructure, which is based on certificates issued by trusted authorities. These authorities issue certificates for websites after they verify that the requester is the actual operator of the website. Because Wikipedia currently supports HTTPS, it already has a valid certificate issued by GlobalSign. These certificate authorities are currently used in China for online banking, so they are definitely allowed. By the way, you may find this informational video to be useful. Thanks, Tony Tan98 · talk 04:52, 20 February 2015 (UTC)[reply]
I don't consider censorship to be the main issue. It's snooping. Say a suspected dissident accesses Wikipedia through https; they think it's end to end encryption but with control of the network, firewall, DNS and CA - the dissident is really talking to a government computer that issues a certificate and that government computer (or more likely a hop or two away across a DMZ firewall) is establishing the TLS with WP. WP has no way to verify the request inside the firewall isn't valid (the same way they only see my ISP's IP address, not my local network IP). Dissidents computer has altered DNS table for wikipedia so it thinks it's actually talking to WP and gets a valid TLS certificate from China's CA - if NSA can do it without network control (which they do), China will have no problem. Now all his requests are visible to the government, yet he thinks it's secure. Which is the larger concern? I'd rather they think all requests are visible then a false sense of security that https is "secure". Censorship is not the problem, it's targetting of individuals that they are suspicious of. Wholesale certificate spoofs won't happen but it will most definitely happen to high value targets. --DHeyward (talk) 04:38, 21 February 2015 (UTC)[reply]
Where does China get a valid certificate for wikipedia.org from? CNNIC? When word of that gets out, all browsers will promptly restrict CNNIC certificates to .cn domains if they don't remove CNNIC entirely. This is an attack that only works until it is discovered, then CNNIC's credibility goes to nothing and they will lose the ability to ever do it again. Remember DigiNotar? That's what happens when CAs get caught issuing bogus certificates. Pathore (talk) 05:03, 21 February 2015 (UTC)[reply]

I left a note on Jimmy Wales' talk page about this, since we're quoting his ideas in the first place. BethNaught (talk) 08:19, 17 February 2015 (UTC) [reply]

If I recall correctly, there were issues where some censor organisations block the wikimedia sites over https, but not over http. What's the status on that? Martijn Hoekstra (talk) 11:38, 17 February 2015 (UTC)[reply]
@Martijn Hoekstra:Yes, China used to block HTTPS connections to WP, but it doesn't do that any more. See here. Tony Tan98 · talk 13:45, 17 February 2015 (UTC)[reply]
Well, that's something. How about the others, i.e. Iran, Burma, Emirates, others? Martijn Hoekstra (talk) 13:53, 17 February 2015 (UTC)[reply]
I was thinking about that too. There isn't a lot of information. Censorship of Wikipedia mentions HTTPS only when discussing China, and a Google search for "wikipedia https censor" doesn't return much. If anything, defaulting to HTTPS should only discourage censors. Tony Tan98 · talk 14:27, 17 February 2015 (UTC)[reply]
Keep both available. Defer to WMF on default. I think it's clear that we should preserve the ability of users to access pages in either HTTP or HTTPS according to personal preference, for a number of reasons above. As for which page is the default, this is one of those rare cases where I'd actually prefer to kick this up to the experts rather than attempting a community decision. There are so many quantitative decisions - how much bandwidth, how much potential censorship, how much surveillance, how likely it is that Heartbleed was replaced long before it was made public, how much load on the servers... we need someone who genuinely knows what he or she is doing to make that sort of judgment call. Wnt (talk) 16:45, 17 February 2015 (UTC)[reply]
I have a very strong preference for HTTPS as the default worldwide. But I also agree with Wnt that there are many many complex variables and careful study is needed.--Jimbo Wales (talk) 17:30, 17 February 2015 (UTC)[reply]

Question: How would this even work? If I put en.wikipedia.org/wiki/Metasyntactic_variable in the location bar, most browsers will assume HTTP. If we wanted to change the "default" to HTTPS, we'd need to redirect. But if we redirected, HTTP would no longer be available, which according to Wnt and Jimbo is a Bad Thing. Can someone clarify the technical implementation for me? --NYKevin 00:00, 18 February 2015 (UTC)[reply]

For readers, there are any number of options. For example, one might make http://en.wikipedia.org/ redirect to https, but not change other entry points. Or one might redirect to https whenever someone first enters Wikipedia with an outsider referer specified (e.g. all links from Google trigger https). Or when someone enters the http site, we might provide them with a dismissable popup box asking if they want to move to https and then remember that choice with a cookie. Lots of things are possible, some more reasonable than others. I agree with the above users that a decision like this is really more of an issue for the WMF to try and judge whether https is an appropriate option for most readers, and how to implement that if so. Dragons flight (talk) 00:30, 18 February 2015 (UTC)[reply]
I don't think that Jimbo said it would be a bad thing if HTTP was no longer available, but I agree that we should allow choice. I also agree that the WMF should be making the final decision, but do you (the community) agree that the WMF should consider a change from the current (HTTP-default) mode? Tony Tan98 · talk 02:07, 18 February 2015 (UTC)[reply]

Oppose Initial access should be the widest and most available protocol. That's http. I'd rather have a user start with http and debug https rather than having trying to figure out why their http request failed during a redirect to https. We have no way of knowing what access is available from an ISP or a particular platform. If a government decided to shutdown https traffic to Wikipedia, I don't think it's WP's place to lock that country out or make them debug why it doesn't work. Keep it simple and http the default. --DHeyward (talk) 02:38, 20 February 2015 (UTC)[reply]

While that used to be the case in China, the situation has changed there. There is currently no evidence of any government in the world blocking HTTPS access to Wikipedia while allowing HTTP access, but there is evidence that some governments are filtering keywords in HTTP requests. Thanks, Tony Tan98 · talk 03:15, 20 February 2015 (UTC)[reply]
They don't have to if they control DNS, firewalls and certificates. https and http are the same in that case. --DHeyward (talk) 04:33, 20 February 2015 (UTC)[reply]
They are not the same. Please see my reply in our other conversation closer to the top in this section. Thanks. Tony Tan98 · talk 04:52, 20 February 2015 (UTC)[reply]

Oppose Misconfigured or old proxies tend to interfere with HTTP websocket traffic they don’t understand, but those same proxies will just forward on the encrypted HTTPS traffic. And, what about all the extra load on the servers? The CPU load has been known to increase when we switch to SSL and now only a few people use SSL, imagine if everyone was to use it all of a sudden. --QEDK ♠ T ♥ C 08:26, 20 February 2015 (UTC)[reply]

HTTPS used to cause a lot of extra load on the server many years ago, but now technology (both software and hardware) has improved and the difference is negligible. According to Adam Langley, a Google Security Engineer, "SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead" when Gmail switched to HTTPS default. This website offers more information about TLS performance. If properly implemented with SPDY and HTTP/2, it may even be faster than plain old HTTP. Moreover, the WMF would be the final judge on whether something can be implemented anyways, right? Tony Tan98 · talk 14:11, 20 February 2015 (UTC)[reply]
Yes, you're right, thanks for pointing it out. Most CPUs now can handle 1500 handshakes/second/core or more. But, then, as it happened with StackExchange sites, switching to active/active load balancers (costs money) because sometimes SSL fails to utilise multiple physical cores. Encryption makes caching an load balancing much harder. This might result in a huge performance penalty. But connection setup is really a show stopper for most applications. On low bandwidth, high packet loss, high latency connections (mobile device in the countryside) the additional round trips required by TLS might render something slow into something unusable. And, as recently, uncovered some computers could have been hijacked already, as the recent Superfish incident has shown. Just another generic man-in-the middle attack, where the self-signed certificate allows the software to decrypt secure requests. I'm not citing this as a reason for oppose, just noting something that happened. And also, if people want to enable https when available, they have the HTTPS Everywhere extension. But in the end, it's WMF's call. --QEDK ♠ T ♥ C 15:49, 20 February 2015 (UTC)[reply]
  • Oppose this has made access for me difficult in the past in some countries and if we want to expand our users this is probably not the way to do it. --Tom (LT) (talk) 00:18, 21 February 2015 (UTC)[reply]
  • Agree after HTTP/2 is implemented and proven stable on English Wikipedia server for users in USA. • Sbmeirow • Talk • 04:51, 21 February 2015 (UTC)[reply]
  • Strongly Support Let me list some reasons here:
    1. When security is concerned, allowing both HTTP and HTTPS is not ideal. Since we use HTTP by default for anonymous visitors, if you use Google to search something, you will find that all Wikipedia links are HTTP. The problem is that even if you are a registered user, when you click a Wikipedia link on Google, your browser sends its first request in clear text, so your ISP, government, and any man-in-the-middle still know which articles you have viewed. Even worse, an active man-in-the-middle can modify the server's response so that you never receive the 301 redirect to HTTPS, and most people don't realize the difference. This is especially true for mobile browsers, some of which omit the protocol and lack a lock icon. This is why redirecting HTTP to HTTPS is not so secure. By enabling HTTPS by default for everyone ensures that search engines index HTTPS links.
    2. What we also should do is to enable HTTP Strict Transport Security (HSTS). When browsers receive this header, all future requests to Wikipedia are automatically sent over HTTPS, and users cannot ignore certificate errors. Ideally, we should include Wikipedia in Chrome's HSTS preload list (which is also used by IE, Firefox, and Safari), so that the user's first time visit is secured. But note that whenever Wikipedia is preloaded on the HSTS list, there will be no options for anyone to disable HTTPS on Wikipedia.
    3. Google promotes HTTPS. Websites that use HTTPS get a higher ranking. (HTTPS as a ranking signal)
    4. After we adopt HTTP/2, using HTTPS will be faster than HTTP and this will be especially true for users with high latency. Please have a look at https://www.httpvshttps.com/. My test showed that "SPDY is 56% faster than HTTP". (HTTP/2 is based on SPDY.) Although HTTP/2 standard supports plaintext, at least Firefox will never support plaintext HTTP/2.
    5. China no longer blocks https://*.wikipedia.org, but does block https://*.m.wikipedia.org/ and http://zh.m.wikipedia.org/. I would really appreciate it if Wikimedia Foundation can change the DNS record of mobile-lb.eqiad.wikimedia.org to an IP address which is not blocked in China.
    6. Among Alexa Top 10, Google, Facebook, YouTube, Yahoo, and Twitter require HTTPS on their homepages. If they can require HTTPS, why couldn't we?
    7. W3C and Internet Architecture Board officially encourage websites to use HTTPS by default:

    The IAB urges protocol designers to design for confidential operation by default. We strongly encourage developers to include encryption in their implementations, and to make them encrypted by default. We similarly encourage network and service operators to deploy encryption where it is not yet deployed, and we urge firewall policy administrators to permit encrypted traffic. (IAB Statement on Internet Confidentiality)

    The Web platform should be designed to actively prefer secure communication — typically, by encouraging use of "https://" URLs instead of "http://" ones (although exceptions like "localhost" do exist). [emphasis in the original] (Securing the Web)

    Chmarkine (talk) 10:29, 21 February 2015 (UTC)[reply]
  • Oppose Make it opt-in instead, and redirect only when a cookie is found (set by clicking a banner promoting secure access). This is more conservative in my opinion. Zhaofeng Li [talk... contribs...] 11:13, 21 February 2015 (UTC)[reply]
    @Zhaofeng Li: But the problem is that MITM can remove the cookie if it is not secure. This does prevent passive MITM, but it doesn't work if an active MITM is present. Chmarkine (talk) 11:32, 21 February 2015 (UTC)[reply]
    If unfortunately the final consensus is to make HTTPS opt-in, I hope we implement it with HSTS (i.e. introducing Extension:HSTS, authored by User:Seb35). Chmarkine (talk) 11:42, 21 February 2015 (UTC)[reply]
    Browser usually provide some visual hints when the page is transmitted over a secure connection (a green padlock besides the address bar, for example), and users can easily notice if a crypto downgrade attack is being used against them. The HSTS idea looks good to me, but do note that users won't be able to turn it off easily in case they want the insecure version back. Zhaofeng Li [talk... contribs...] 11:52, 21 February 2015 (UTC)[reply]
    Yes. The indicator is actually obvious, but I worry many users just don't look at it. A research in 2006 concluded "participants who received no training in browser security features did not notice the extended validation indicator and did not outperform the control group." I hope users nowadays are more educated in web security, but I still believe websites should provide best security by default to most users. Chmarkine (talk) 12:11, 21 February 2015 (UTC)[reply]
  • Oppose Unfortunately, I'm not seeing how this proposal actually benefits Wikipedia's mission. Instead, the rational used to justify it is to get around ISPs'/countries' filters that block content they find objectionable. However, I don't believe that it is Wikipedia's place to find bypasses around these filters in the first place. —Farix (t | c) 15:12, 21 February 2015 (UTC)[reply]
That is not the only rationale of this proposal. Governments in most countries (including the USA) are now known to be monitoring internet traffic and putting them in large databases. This means that the articles that each reader reads are likely to be logged. Not only does HTTPS make large-scale snooping very difficult, it also prevents ISPs from monitoring what any given user has read or searched for on Wikipedia, protecting readers' privacy. This is one of the primary reasons that Google switched to HTTPS default for all searches. Tony Tan98 · talk 16:14, 21 February 2015 (UTC)[reply]
I don't believe switching to https will do anything to protect people from spying much less prevent them from being logged. Besides, this falls into the realm of WikiMedia Foundation's Privacy Policy and something that rest solely on the Foundation to decided. This is not something that should be up for discussion among Wikipedia editors. —Farix (t | c) 18:31, 21 February 2015 (UTC)[reply]
@TheFarix: As I stated above, the reasons for using HTTPS include: 1) preventing man-in-the-middle attacks, 2) improving performance (when HTTP/2 is used), 3) getting higher rankings on Google, 4) IAB and W3C encouraging using HTTPS. Using HTTPS on Wikipedia is just like using HTTPS on online banking websites, because "it has become apparent that nearly all activity on the Web can be considered sensitive, since it now plays such a central role in everyday life" (Securing the Web). Chmarkine (talk) 18:36, 21 February 2015 (UTC)[reply]
@TheFarix: It is a well established fact that HTTPS encryption protects people from spying and traffic logging. It is not a matter of opinion or belief. When a user visits a HTTPS secured website, the ISP can only see the domain name of the server, not the actual contents that the user is sending and receiving. In the case of Wikipedia, this means that the ISP will only know that the user is using Wikipedia, but it cannot tell what articles are being read and what terms are being searched for. The protection that HTTPS offers is described in detail in the articles HTTPS and Transport Layer Security, and elsewhere on the internet as well. I also recommend that you read the earlier questions, answers, and comments in this section about HTTPS.
I do agree that the WMF should make the final decision about whether to implement something like this. What this proposal is asking is whether the community thinks that the WMF should consider a change from the current HTTP-default mode. Thanks, Tony Tan98 · talk 19:34, 21 February 2015 (UTC)[reply]
Our purpose is to grant all of humanity access to the sum of human knowledge. If people are being prevented from viewing Wikipedia because of mass surveillance and censorship (regardless of source), then we have a problem that is interfering with our purpose. I honestly do not see the point of writing Wikipedia articles if the people who need the articles' information the most are being prevented from reading them, and feel that any proposal that gives more people access to Wikipedia's content is a good proposal. Spirit of Eagle (talk) 04:07, 25 February 2015 (UTC)[reply]
  • I've been supporting and advocating this move far a very long time now. There's no reason why internet traffic in general should not be encrypted (welcome to 2015, performance is not an issue anymore). And readers' privacy is only one part of the reason. The other is integrity of the data (website) delivered to the client (reader). Only an encrypted connection ensures that the data is not tampered with on it's way to the reader (as, for instance, here). --bender235 (talk) 21:59, 21 February 2015 (UTC)[reply]

Oppose, I'm sorry, I thought wikipedia was for the world and not just the first world countries? not everyone has fast internet speed, we may be in 2015 but internet wise, most countries are still in the 90's ..I ONLY edited on dial-up with my previous account (and not by choice) and because then Wikimedia didn't force people onto https, i was able to edit faster, https as mentioned above is pathetic in caching information, especially scripts which will make the wiki much slower for anyone with low internet speed, I'm on HSDPA and i can barely get a speed on 20kbps on the wiki. There is an OPTION to enable https on Preferences, I urge people who want "safety" to enable that and those that care for performance over security, like me would prefer to stay on, this is an ORGANIZATION, not some underground hacking/torrenting site that needs to be secured from the governments..This is WIKIPEDIA, not WIKILEAKS...All governments spy on people, that doesn't mean we live in fear all our lives..its not like we exchange private information or illegal stuff on Wikipedia that we need to "secure" ourselves from the government.......are we?--Stemoc 23:23, 21 February 2015 (UTC)[reply]

Browsers do cache content over HTTPS. The "2015" mention in bender235's comment was mostly referring to servers and their configurations, not the Internet connection. (You will see that if you click on his link.) Moreover, even though first-world governments are not as concerning, as you mentioned, Wikipedia is for the world, and there are governments in this world that restrict access to the web and filter content on Wikipedia. Not every government in the world is benevolent, and while it is not the primary objective, enabling HTTPS by default can certainly help protect readers and give them better access to information. Of course, like mentioned above, making it default does not mean there will be no way to opt-out. For your specific editing needs, you will still have the option of using HTTP by changing your account settings. Tony Tan98 · talk 00:05, 22 February 2015 (UTC)[reply]
@Stemoc: Totally understandable. But the good news is that only after a few months, you do not have to make the choice between security and performance. With HTTP/2 over TLS, you can enjoy both high speed and security. HTTP/2 over TLS is even faster than HTTP in most cases, in terms of load time and bandwidth. ([1][2] [3]) Since some browsers refuse to implement plaintext HTTP/2, we have to enable TLS in order to use HTTP/2. Chmarkine (talk) 01:54, 22 February 2015 (UTC)[reply]
High speed and security? I tried https a while back, net speed rarely went past 10kbps (thats as worse as dial-up) ..i don't care for security, our government does not care what people post on wikipedia and it definitely does not cache scripts well, reloading the same scripts over and over again everytime you try to make a simple edit or refresh the page is tiring, especially if they take a while to load...btw, anyone that wants to look up information on wikipedia even on countries where its restricted will always find a way to do so (proxies etc), we do not make it hard for everyone else because just a handful are missing out and as mentioned above, I prefer an opt-in option to an opt-out one..I'm just tired of WMF making stupid decision and then enforcing them and regarding the opt-out option, thats absurd Tony, HTTPS should be an OPT-IN option, not an OPT-OUT option and definitely NOT the ONLY OPTION.--Stemoc 02:27, 22 February 2015 (UTC)[reply]
Please check out this image, you can definitely forget the idea that everybody living in some kind of "first" world area can afford Internet connections that do not suck. Just in case adding an oppose, because I forgot that near the begin of this thread. € 0,02 by Be..anyone (talk) 02:38, 22 February 2015 (UTC)[reply]
@Stemoc: I never say https is fast today. I mean https will be faster than http after we adopt http/2, which will be available later this year. I know you don't care about security, but http/2 is faster than http. Why do you still hate it? Chmarkine (talk) 03:03, 22 February 2015 (UTC)[reply]
@Stemoc: Are you able to use Google search through your slow internet connection? Tony Tan98 · talk 03:14, 22 February 2015 (UTC)[reply]
Ofcourse i can use Google search, the shitty speed is only limited to wikimedia wikis which gets even worse on https, my net is slow but bearable but then i'm on Wikimedia more than I google so i do not see the reasoning (even then it takes forever to do google "image" search)..as per Be---anyone, it seems that slow connection is a problem in first world countries too so I really don't see a reason to "force" https on everyone..I think people who are supporting this idea are definitely NOT on slow connection or else they would understand how hard it is to browse, let alone edit wikipedia--Stemoc 04:40, 22 February 2015 (UTC)[reply]
Google uses HTTPS by default. You said that you are able to use Google search (over HTTPS) normally on your slow internet connection. Thus, HTTPS is not the issue that is slowing down your access to Wikipedia. Moreover, editors with accounts will have the option to disable HTTPS if they wish to do so. Also, I spend half of my time in China, and I know what it feels like to use a slow internet connection. Tony Tan98 · talk 05:06, 22 February 2015 (UTC)[reply]
when did i say it did?, I said it makes it worse as and also i generally use Google DNS so google will run faster either i like it or not and also there is a stupid bug on wikimedia created by csteipp which no one wants to fix which automatically FORCES users into https if they edit any page by mistake on https, the only way to get out of it is to clear all your cookies from *wikimedia/*wikibooks/*wiktionary and the 4 other domains and clear all centralauth cookies and log in and they go to all wikis and try logging in... I'm a file mover on commons which means if i fix a file name, my account automatically goes to all the wikis the image is on to replace the file but if i get logged out of a wiki because of this bug, it ignore that wiki which means the file remains unchanged..first they added the "forceHTTPS" cookie without asking for user opinions and now this....I'm part of the SWMT which means on some days i edit over 20 wikis and sometimes more, this flaw is not helping...https may be ok for those who edit only ONE wiki like most of those here, but its a PITA for users like me..you can't revert vandalism on a smaller wikis if you have to wait 30-45 seconds for all the effing scripts (js/css) to load...--Stemoc 06:58, 22 February 2015 (UTC)[reply]
  • Support - I totally agree. In the pre Snowden era, this probably would have been opposed as unnecessary and/or burdensome, although it's now absolutely necessary (per Google, Snowden, and many others) and it's barely burdensome, if at all. Yes there is censorship. But the chilling effect of surveillance has a negative impact on our mission. There are many places in the world in which asking questions about religion, sexuality, women’s rights, abuse, among others, or editing forbidden Wiki articles, can result in actions taken against them by their families, community, employers, or the state (judicial and extra-judicial). Wikipedia is an invaluable resource for information, but not for those that are afraid to access it because big brother or others are looking over their shoulder. - Becksguy (talk) 04:01, 22 February 2015 (UTC)[reply]
  • Oppose for viewing, Support for logging in and editing. Restricting HTTP access to Wikipedia's public content doesn't provide any real security gain, and it makes caching harder. It's also likely to break some older devices, such as the Kindle with free Wikipedia access. However, editing actions and logging in should be secured. John Nagle (talk) 07:55, 22 February 2015 (UTC)[reply]
  • Comment Shall we move the discussion to meta, since this is a Wikimedia-wide issue affecting all communities? Zhaofeng Li [talk... contribs...] 01:11, 24 February 2015 (UTC)[reply]
Doesn't really matter as one of the devs mentioned on IRC a few days ago that we will be moving to https (either we like it or not) ..--Stemoc 01:26, 24 February 2015 (UTC)[reply]
  • Support Everyone should be able to read Wikipedia articles without having to fear government surveillance or censorship. If people who need Wikipedia's information are prevented from getting it because of mass surveillance or censorship, then our purpose of granting people access to the sum of human knowledge is under attack and needs to be protected. Even if this RFC does not pass, I think that we should do a better job of informing readers about HTTPS, and make it easier to switch in. Spirit of Eagle (talk) 01:44, 24 February 2015 (UTC)[reply]
  • Strongly support per Becksguy, at all times. In addition, with attacks that rely on starting with an unencrypted channel, there's more and more reason to start off encrypted to begin with. I question concerns of users who are talking about bandwidth use, as well; I'd like to see some actual numbers showing TLS overhead versus average article sizes before I'd give those comments any credence. // coldacid (talk|contrib) 03:35, 25 February 2015 (UTC)[reply]
    Chmarkine explains it even better, above. Even HSTS can be defeated by a man in the middle if you start with unencrypted communication. Default to HTTPS, the sooner the better. // coldacid (talk|contrib) 03:39, 25 February 2015 (UTC)[reply]
  • Perspective Please don't pretend this is for site security. If we cared about site security, we'd have a password policy. I'm also kind of baffled by this hypothetical use case of someone who has to fear people eavesdropping their Wikipedia reading habits, but is ignorant of the use of HTTPS. Where does this end? Remove public editing histories? A one-way hash for editor names? The whole concept of a Wiki is open and public. Not secure and secret. Gigs (talk) 16:57, 25 February 2015 (UTC)[reply]
No straw men please - you know very well that those things aren't going to happen. For one thing it would violate the license terms, and editors can be pseudonymous anyway if they choose. You're right that this wiki is public, but that only covers overt participation, not reading, where people would have a legitimate expectation of privacy.
Also, I don't think (generally) people are saying this move is for site security, it's for the readers' security. BethNaught (talk) 17:07, 25 February 2015 (UTC)[reply]
Please actually read the above proposal, Gigs. It is (mainly) not intended for site security, but for the security & privacy of readers. No one is proposing to make this wiki secretive; it is and always will be open and public. I genuinely hope that you were actually confused and not trying to make a straw man argument. Tony Tan98 · talk 17:45, 25 February 2015 (UTC)[reply]
This is also another reason to either block editing via Tor or at least include a big "you are not as anonymous as you think" message on the edit pages served to Tor exits: an attacker able to observe your network traffic can trivially correlate bursts of activity with Wikipedia's public edit histories. Edits look different from reading: reading a page is a large response to a small request, while editing is a large response to a large request. If we really want to take the paranoid approach, we should modify the software to include random bits of other articles (as comments) in every page sent over HTTPS. Currently, an attacker might be able to guess what articles are being read by looking at the sizes of the responses from the servers. Pathore (talk) 22:45, 25 February 2015 (UTC)[reply]
@Pathore: While what you are saying (traffic analysis) is certainly theoretically possible, it is currently not an easy task for even a government to use for mass snooping. It is not "trivial." Moreover, Wikipedia does not allow edits from Tor unless the user logs in and has IP block exemption.
The main purpose of this proposal is to prevent mass snooping (and censorship) of readers by upgrading to the HTTPS protocol by default, which is what many other websites such as Google have started to do years ago. As a side benefit, HTTPS also ensures the integrity of data being transferred, so that a user can be certain that the page from Wikipedia has not been tampered with (censored or inserted with ads) while in transit.
We are not trying to take the "paranoid approach" and there is currently no need to "include random bits of other articles." Given the sheer number of articles we have and the current state of technology, it should be very difficult (currently) for someone to use traffic analysis to correlate encrypted traffic to specific articles that are being read. However, because it is trivially easy to sniff unencrypted traffic using tools such as Wireshark, I strong believe that we should enable HTTPS encryption by default for all readers. Since you have not yet stated it, may I ask for your opinion on this proposal? Tony Tan98 · talk 01:49, 26 February 2015 (UTC)[reply]
Correlating public edit histories to network activity is trivial, especially over a longer period of time, and identifies the network location behind an account, fingering an editor.
Identifying pages based on their size is neither trivial nor particularly accurate, but should be a concern if we are really worried about our readers' privacy, given the poor standards of "evidence" associated with mass snooping fishing expeditions. Exactly how accurate such an attack would be depends on the distribution of page sizes given links. (A snoop can guess that users tend to follow links from the page that they are reading; this means that if pages A and B are the same size, but A links to C and B links to D, which are different sizes, a snoop could guess that a user was more likely on A or B, based on a subsequent request that appears to be either C or D. This game of Guess Who? scales, although I don't know exactly how well.)
If I understand correctly, HTTP/2 allows the server to send the client extra resources that have not (yet) been requested. We could use this to return a number of random extra articles (that the client will cache) with each request, further enhancing reader privacy. Even looking at someone's cache wouldn't tell you what articles they were reading, since the server stuffed extras in there at every opportunity. Exactly how to choose those extra items is a good question.
I'm currently unsure of my position on this proposal. On one hand, Jimbo has promised to push Wikipedia towards HTTPS in response to privacy-violating politicians and I don't want to take whatever leverage Jimbo may have for human rights away by pushing that change regardless. On the other hand, the article you cite is from almost three years ago; perhaps the situation has changed and it is now necessary for the community to stand behind making good on its founder's promise. Has this come to pass? Do we need to stand behind Jimbo making good on his promise? Pathore (talk) 03:06, 26 February 2015 (UTC)[reply]
Opposed It'll break links and infrastructure. It breaks caching important for overseas users and increased latency (unless WMF's planning 20+ more data centers). And unless we're padding the payload its still vulnerable to the Google Suggest side channel attack. — Dispenser 18:03, 5 March 2015 (UTC)[reply]
1. I don't understand what you mean by breaking links and infrastructure. Could you please explain?
2. Browsers do cache content over HTTPS.
3. TLS isn't slow anymore. I spend half my time in China, the other half in the U.S., and I use HTTPS; I have not experienced any noticeable latency or slowness. Tony Tan98 · talk 08:20, 10 March 2015 (UTC)[reply]

Just a quick update on where we are with this. Consistent with Jimmy's comments here, we do believe encryption should ultimately be the default for all web traffic, on our sites and elsewhere. That said, we have significant work lined up on improving the performance of Wikimedia's HTTPS infrastructure (phab:T86666, phab:T35890) which we aim to complete in coming weeks. We're also collecting global performance metrics as we tune our setup. We need to fully understand performance impact and other potentially negative consequences before any switchover to HTTPS for all traffic (or a less dramatic solution, such as pointing search engines to the HTTPS version).--Erik Moeller (WMF) (talk) 06:08, 7 March 2015 (UTC)[reply]

The web is inexorably marching toward secure encrypted traffic. See today's NY Times op-ed piece Stop Spying on Wikipedia Users, written by Jimmy Whales and Lila Tretikov, in which they discuss a lawsuit against the NSA. I think that nails it for us here. Offering Transport Layer Security (or TLS/HTTPS) for Wikimedia projects with opt-out as the default is the only way to go. Otherwise, due to human nature, too many readers/editors will not opt-in which results in those using encryption as standing out, and therefore being targeted for increased surveillance. Everyone needs to use encryption all the time and everywhere, such that it becomes the norm. - Becksguy (talk) 15:29, 10 March 2015 (UTC)[reply]

  • Support. Chmarkine's and bender235's rationales above convince me. Using https will make all Wikipedia pages secure, as opposed to fast and insecure; performance isn't really an issue at this point. More and more webpages on the internet are using https. However, https should be opt-in for unregistered users. Epic Genius (talk) 01:37, 17 March 2015 (UTC)[reply]
  • Oppose. Some internet browsers, particularly embedded browsers which receive few updates after their release, may have difficulties with this. I'm sorry, but I just don't see any importance in this. Exactly what on wikipedia needs to be secure? People are arguing for more privacy without considering whether there's anything worth securing. ― Padenton|✉   01:28, 26 March 2015 (UTC)[reply]
    Who the hell is browsing Wikipedia on a phone so old that its browser doesn't support HTTPS? I highly doubt that we'll have people trying to read the site on some circa 2000 feature phone. // coldacid (talk|contrib) 02:04, 26 March 2015 (UTC)[reply]
@Coldacid: A lot of phones don't, even more embedded browsers don't (such as those in TVs or game consoles) ― Padenton|✉   16:02, 29 March 2015 (UTC)[reply]
Could you give a specific example? Most phones today support HTTPS. Tony Tan98 · talk 18:12, 29 March 2015 (UTC)[reply]
Pretty sure every game console of this and the last generation support HTTPS as well. Without some naming and shaming of recent devices by Padenton, I find myself unable to believe their claim. I wouldn't mind if WMF would chip in with some user-agent stats for the past year as well, so we have an idea of how (in)frequently users without HTTPS support even come to Wikipedia. // coldacid (talk|contrib) 18:38, 29 March 2015 (UTC)[reply]
  • This is NOT about securing Wikipedia content (which remains open and available to anyone), rather its about protecting user's privacy in accessing WP, in much the same way a battered women is given anonymity to protect her from reprisals. Something quite different and in the opposite direction from securing WP. - Becksguy (talk) 08:48, 29 March 2015 (UTC)[reply]
@Becksguy: Sorry, I didn't mean to imply anything about applying protection to wikipedia articles. This has nothing to do with battered women. So you're talking about preventing people from knowing what pages a user views? Is there any significant user survey in addition to the arguments above that users want such things? Sadly, there is a systemic bias in any Wikipedia namespace discussion towards active editors. There is already a setting to enable secure connection, and I don't see why that is not enough. ― Padenton|✉   16:02, 29 March 2015 (UTC)[reply]
@Padenton: Internet traffic to Wikipedia has been specifically identified as one of the targets for NSA mass surveillance, and HTTPS can make monitoring by governments, ISPs, or other parties as difficult as possible. HTTPS can also prevent Wikipedia content from being selectively censored or inserted with ads by ensuring the authenticity of delivered content. While there is currently an option for users to use HTTPS, the default is HTTP (plain text), and research has shown that as many as 95% of users don't bother to change the default settings simply because they are not aware. Google, along with many other companies/organizations, has already made HTTPS the default or even the only method of accessing its websites. By making HTTPS the default method for accessing Wikipedia, we can protect those users with almost no noticeable change in experience for them. Tony Tan98 · talk 18:12, 29 March 2015 (UTC)[reply]
@Tony Tan 98: I still don't see how anyone has reason to be afraid of what their wikipedia browsing history shows, what is it you think the government will find out? Google is not Wikipedia, people don't type the same things into Google that they do into Wikipedia. People don't type in "How do I make bomb" or "where can I find child porn" into Wikipedia's search bar. Ad insertion is exclusive to a few obscure ISPs, non-intrusive, and there's a setting to make https the default method for accessing wikipedia in preferences. The 3rd link is irrelevant. People can make their own choices about their own privacy. If you want to propose a banner at the top of the page letting people know about the setting, I wouldn't oppose that. ― Padenton|✉   18:37, 29 March 2015 (UTC)[reply]
If Wikipedia browsing history is useless, why is the NSA targeting it? Such history shows what a user has been reading and what his/her interests are. Its sensitivity can be seen in the lawsuit that the WMF filed against the NSA.
What is the downside of using HTTPS? Usually things are disabled by default only when there are downsides; otherwise they are enabled by default. For example, why not remove airbags from cars and make it an option for people to install it themselves? Surely people should "make their own choices about their own" security? Because the benefits of having an airbag outweigh the virtually nonexistent downside.
This proposal does not prevent people from explicitly opting to not use HTTPS, but simply makes it the default should the user decide to go by the default. The benefits of using HTTPS (protection of privacy, prevention of selective censorship, assurance of authenticity, etc.) outweigh the possible downsides. Tony Tan98 · talk 20:11, 29 March 2015 (UTC)[reply]
  • Oppose If individuals are concerned about governments, internet service providers, and hackers from snooping on their traffic, they may elect to use https as I do. Forcing it on individuals is not appropriate. I would argue that also extends to editors changing links to other sites used as references to secure connections also. Walter Görlitz (talk) 04:10, 26 March 2015 (UTC)[reply]
  • This proposal does NOT force HTTPS on anyone; users are completely free to opt out at anytime. What it does change is the default to secure, rather than insecure. If someone doesn't like it, just opt-out. - Becksguy (talk) 09:00, 29 March 2015 (UTC)[reply]
  • Support – While some might argue that users can choose to opt in, we know that most people are unaware of the issues and will take no action even if they are told of them; defaults should be set in the general best interest for those that will leave it at the default. —Quondum 18:56, 29 March 2015 (UTC)[reply]
  • It appears that one of the reasons for opposing is "I have nothing to hide", so why encrypt. To which some might reply: (1) "I have nothing to hide... from those I trust." Does anyone that hasn't been living under a rock since the Snowden revelations, seriously think in their most optimistic pipe dreams that anyone that snoops on our communications has the slightest concern for our individual best interests or rights, or that those that commit surveillance on us are our friends? With global surveillance, there is so much data gathered about us, stuff that maybe doesn't seem important at the time, that can come back and bite us in the ass. Remember Big Brother. And today this is reality, not paranoia. (2) There are places in which people have very legitimate and real fears about surveillance. Places and communities where, for example, if someone is outed by viewing the kind of information that is taboo or contraband, they can suffer punishment, beatings, imprisonment, and execution, both judicial and extrajudicial. (3) When Windows XP was released in 2001, it had a form of firewall that was off, thus disabled by default (opt-in mode), and these machines were rapidly infected with various malware (viruses, worms, etc.) that also infected other vulnerable machines. Microsoft set the firewall default to enabled (opt-out) in SP2, realizing that users and the internet needed protection. No one manned the barricades when that default was changed. (3) Our mission is to realize "...a world in which every single person on the planet is given free access to the sum of all human knowledge." We will fail if there are those that are afraid or unable to access this knowledge due to surveillance or censorship and the very real and serious consequences thereof. - Becksguy (talk) 02:51, 30 March 2015 (UTC)[reply]
  • Oppose - I'm puzzled by this. If you're in the telephone directory, then apart from your number any Tom, Dick or Harry can see your home address. But if the NSA accesses your IP address, so what? There's no "IP directory" which links that to your name and address. 87.81.147.76 (talk) 10:38, 30 March 2015 (UTC)[reply]
They aren't just accessing your IP address, and HTTPS wouldn't prevent them from doing so. What it does is encrypt all data between you and the server, even what pages you are looking at. Using your example, this would be like the NSA not only being able to know your address and telephone number even if you have them unlisted, they can also read all your mail and hear all your telephone calls. And there is an IP directory, the one that your ISP keeps on you. They also know, and can possibly keep and therefore track, every connection you make through them. Without HTTPS your ISP can see that you visited this page, and all the text that is on it. Jerodlycett (talk) 10:52, 30 March 2015 (UTC)[reply]
There seems to be some synthesis going on here. If I type "google" into my browser and click on "Gmail" the url that comes up is https://www.gmail.com. So are you telling me that even with that "s" on the end the NSA can still read my email? 87.81.147.76 (talk) 11:18, 30 March 2015 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Splitting up the MfD

It has often occurred to me that discussing the deletion of project pages requires to be a more intensive process than discussing user pages. The large number of pages being listed at the MfD are user pages, as a result of which project pages get lost in the mix and don't get adequate attention. Also, while proposing the deletion of abandoned user pages and stale drafts can be a simple process which are closed without too much of discussion, the same is not true for pages in the Wikipedia:, Help: and certain other namespaces. Deleting, or acting upon these pages in other ways, should ideally require community-wide consensus. As of now, there is no centralised place discussing the scope of project pages; any such discussion is carried out on their talk pages which obviously are not watched by many users. In this light, I propose splitting up the MfD into multiple components.

  • Project pages for discussion: This should include pages in the Wikipedia:, Help:, MediaWiki:, and Module: namespaces. Pages in these namespaces require more discussion before deletion, and this page can also be a forum for centralised discussions regarding help and policy documentation, and attempts to discuss the scope and imrove the quality of help pages. This is especially feasible because the quantity of project pages nominated for deletion is fairly low. This can also provide a boost to currently inactive WikiProject Manual of Style. As with the AfD and MfD currently, each entry should have a separate page.
  • User pages and drafts for deletion: As with the CfD and RfD, entries should not have a separate page. If deemed necessary, two different sections may be provided for listing pages in the two namespaces. Alternatively, we may have a Drafts for deletion for listing both pages in the Draft: namespace as well as userspace drafts. (In this case, user pages that are not drafts can be listed at MfD. If it is unclear as to whether a user page is a draft or not, it can still be posted here as reviewers at DfD would be competent enough to handle them.)
  • Miscellany for deletion: This page should be retained for discusing deletion of pages in other namespaces, such as Portal:, Book:, TimedText: and Topic:. (As per this requested move, calling this page Miscellany for Discussion is not necessary.)

Please be free to suggest variations to this proposal. SD0001 (talk) 06:46, 22 February 2015 (UTC)[reply]

I see this as a lot of confusion for not much benefit. And when project pages do get nominated for deletion, they get plenty of attention, thanks to the big fat "we might delete this" message on top. Oiyarbepsy (talk) 08:41, 23 February 2015 (UTC)[reply]
I do not think this would make things any more confusing. These new pages are just like the existing AfD, RfD, CfD and TfD. Where is the confusion? Well, those banners are good enough. The problem arises when the pages are not popular enough. SD0001 (talk) 18:23, 24 February 2015 (UTC)[reply]
I suppose I could support splitting off the user space ones (due to the newish guidelines on drafts, etc. increasing the workload there), and leaving the rest at MFD. But make it ...for discussion. - jc37 08:50, 23 February 2015 (UTC)[reply]
But I don't think we would ever need to discuss user pages and drafts. Minimalistic discussion (such as whether a draft should be deleted or submitted to WikiProject Abandoned Drafts) can be carried or on the deletion page itself. SD0001 (talk) 18:23, 24 February 2015 (UTC)[reply]
Seeing as neither modules nor MediaWiki: pages are really project pages, I'm not sure about the "PfD" grouping. I think it would make a lot more sense if Lua modules were covered by the existing WP:TFD. I agree that only splitting out "UfD" would already help solve the described problem. SiBr4 (talk) 21:39, 23 February 2015 (UTC)[reply]
Covering modules at the existing TfD is a good idea. But I don't see any fault in including the MediaWiki: pages along with the project pages. SD0001 (talk) 18:23, 24 February 2015 (UTC)[reply]
I don't think project pages need to be separated out from MfD; as Oiyarbepsy said they get lots of attention anyway. I can see the benefit of splitting out user pages and drafts to a different process though, possibly managed by WikiProject Articles for Creation. But they have some serious backlog problems right now; best to wait for their input. Ivanvector (talk) 21:48, 23 February 2015 (UTC)[reply]
  • I think these should be grouped by subject matter rather than namespace. I may support creation of a draft for deletion page, for drafts and more generally pages whose predominant content is intended as forming (part of) an article, whether in Draft, User or Talk namespaces. TimedText, which are basically subtitles, should go to WP:FFD since this is multimedia-related. Module and mediawiki pages should go to WP:TFD since these are transcluded content, interfaces or technical-related. Topic is kind of like talk and can remain at MfD. The rest can be divided in two subject matters : project and help pages on one hand (concerning the project itself and its inner workings), and portals and books on the other hand (mainly about showcasing content). That being said, the volume for both of those twos if insufficient to justify a split, so they should stay together at MfD. Judging from the January 2015 archive, it's even debatable if we need a separate draft for deletion page since they form most of nominations and if these get removed, MfD would only get a few nominations per week. So at this time, I'd suggest only making the move of TimedText to FFD and Module/MediaWiki to TFD. Cenarium (talk) 00:35, 25 February 2015 (UTC)[reply]
Sure, here is a list of which parts of it I would be opposed to:
  • The entire idea at its core.
  • End of list.
I hope that has clarified my position sufficiently. Beeblebrox (talk) 21:04, 28 February 2015 (UTC)[reply]
  • There are often suggestions for splitting this or that up. Of course, there are often also suggestions for merging this , that, or the other. However, most of these suggestions are solutions looking for a problem, and this is one of them. This idea would just create more bureaucracy and more picking of low hanging fruit leading longer backlogs in some areas. --Kudpung กุดผึ้ง (talk) 13:25, 6 March 2015 (UTC)[reply]
I've proposed moving "Drafts" of any sort to another forum (including Draft: and drafts in user: space) - thinking that these are content not misc. pages--and a different audience may be interested in the discussions. — xaosflux Talk 04:22, 8 March 2015 (UTC)[reply]

I have created a failed proposal documentation page for WP:Project pages for discussion. It does not look too strong to me, though. SD0001 (talk) 18:40, 8 March 2015 (UTC)[reply]

  • If anything, we should have less deletion forums, not more. The more we break them up, the less people will participate in them. There's like literally 5-10 regulars at most of the smaller deletion forums that keep the things running. You really want to split that even more? It seems to me that when an MfD is contentious, it does just fine attracting additional attention, either through the page notice, or through appropriate canvassing. Gigs (talk) 19:38, 17 March 2015 (UTC)[reply]

Templates

I would absolutely put Modules with Templates, since they are templates, just templates programmed with a different language. I would also put MediaWiki: interface pages with templates, since they are also "back-of-the-house" code and just make more logical sense to be with other code than with userpages, etc. – Philosopher Let us reason together. 23:53, 24 February 2015 (UTC)[reply]
  • I agree, per my above comment.  Cenarium (talk) 00:37, 25 February 2015 (UTC)[reply]
  • Support, as per my comment made above. SD0001 (talk) 14:05, 25 February 2015 (UTC)[reply]
  • It makes sense to keep computer code separate from content meant for humans. I don't think very many modules or MediaWiki pages are being discussed at MfD, so I'm not sure it matters, much. Note that changing the venue for modules has been discussed at TfD, before. I left a note at WT:TFD about this discussion. —PC-XT+ 14:44, 25 February 2015 (UTC)[reply]
    • Modules have been MfD'd just 7 times. Out of these, while four were deleted as per CSD criteria, two (this and this) did not see any comments at all. Doesn't this show that MfD is unfit for modules? SD0001 (talk) 19:48, 25 February 2015 (UTC)[reply]
      • No, it shows that optimizing how modules are deleted would be a waste of time. Please describe the actual problem before proposing a solution. More pages means more confusion. Johnuniq (talk) 00:31, 26 February 2015 (UTC)[reply]
        • The problem is this: As demonstrated, in particular by this listing, deletion discussions of modules at the MfD fails to attract the relevant audience which might be available at the TfD. I agree that is not a major problem because modules are rarely nominated, but I see strong reasoning in Philosopher's comment that modules are templates and thereby support the proposal. SD0001 (talk) 17:27, 26 February 2015 (UTC)[reply]
          • That's a fair comment but people scan MfD and would be quick to raise the issue somewhere if a deletion proposal looked like it needed specialist attention, and modules that are needed can always be undeleted. The problem with TfD is that it has too much noise and drama (plus there are too many purists who would edit war to ensure it is renamed "WP:Templates and modules for discussion" or worse). While the example you linked looks bad, those familiar with the situation know that the nominator is one of a very small number of experts whose judgment can be relied on, and there is no reason to comment about an unused and pointless module. Johnuniq (talk) 01:54, 27 February 2015 (UTC)[reply]
            • The "noise and drama" at TfD is hardly relevant to the question of whether templates should be split between fora based on the coding language. I would further note many "modules" and "templates" are built together as one unit, so discussing them in different venues is quite odd. – Philosopher Let us reason together. 02:13, 27 February 2015 (UTC)[reply]
            • There is certainly no question of an edit war occurring over the page name since the page is move-protected, and will always be. If anybody wants to rename the page, they can begin an RfC RM. The question of the page name is not relevant to this discussion. Besides, I cannot agree with your observation that there was "no reason to comment about an unused and pointlless template" simply because the nominator was trustworthy. Wikipedia's deletion policy requires consensus for pages to be deleted. If any person with the expertise to tell if the page was pointless had seen the nomination, they could have added a simple "Delete, per nom" there. SD0001 (talk) 18:48, 27 February 2015 (UTC)[reply]
  • The audience for TfD is very small. Merging TfD to MfD for the wider audience seems preferable to me than moving modules from MfD to TfD, but what we do with deletion proposals for models is probably not worth the bytes of the conversation. Strong whatever. Martijn Hoekstra (talk) 14:27, 6 March 2015 (UTC)[reply]

It won't be bad idea to have some more formal !voting to obtain input from more editors. The question is: Should modules be nominated at WP:TfD instead of at WP:MfD? Vote as 'Support', 'Oppose', or 'Neutral'.

@Cenarium, Philosopher, PC-XT, and Johnuniq: Just pinging users who participated in the discussion above but have not cast their bolded votes yet. SD0001 (talk) 12:22, 6 March 2015 (UTC)[reply]

  1. Support per above. SD0001 (talk) 11:16, 1 March 2015 (UTC)[reply]
  2. Support – modules do the same thing as templates (being invoked on other pages and returning some output), and moving them to TfD makes it easier to nominate modules together with the templates that wrap them. SiBr4 (talk) 11:33, 1 March 2015 (UTC)[reply]
  3. Support Modules are templates, just written in Lua rather than wikitext. Pathore (talk) 01:12, 3 March 2015 (UTC)[reply]
  4. Weak support, because it makes sense to discuss them together, but we don't really have enough MfD module discussions to determine if there is a problem, or how bad it is, if so. —PC-XT+ 21:12, 6 March 2015 (UTC)[reply]
  5. Oppose Mediawiki: moving to TFD, no real preference on Module (they are rarely XFD'd). — xaosflux Talk 04:20, 8 March 2015 (UTC)[reply]
  6. Support per above, since my John Hancock seems to be wanted here. – Philosopher Let us reason together. 20:42, 3 April 2015 (UTC)[reply]
  7. Support Mod's & Templates. Oppose Mediawiki Mlpearc (open channel) 22:48, 3 April 2015 (UTC)[reply]
  8. Support Moving modules to TfD makes sense to me, as TfD is more likely to attract technically-minded editors than MfD, and templates and modules are often related to each other. Although, as others have said above, it doesn't seem to be too much of a problem in practice. I would also support moving Mediawiki-namespace pages to TfD, as they also fall into the general category of "technical things". If a name change is desired, we can work that out later. — Mr. Stradivarius ♪ talk ♪ 12:10, 5 April 2015 (UTC)[reply]
  9. Support for reasons of similarities, mentioned passim. -DePiep (talk) 13:07, 5 April 2015 (UTC)[reply]

Draft PROD?

One of the main problems with MFD is the large number of WP:STALEDRAFT deletion discussions, that nobody comments on clogging up the system. Searching for the words "STALEDRAFT" brings up 34 matches on the MFD page, and in almost all of these cases there is no actual discussion being had (and no discussion to be had) about the drafts up for deletion. I think a PROD system for drafts would be beneficial for clearing up MFD, speeding up overly slow processes and solving backlog issues.Bosstopher (talk) 21:39, 15 March 2015 (UTC)[reply]

These are some of the least commented on types of nominations, in closing it is hard to determine if there is "no consensus" or just "no one cares". — xaosflux Talk 00:52, 16 March 2015 (UTC)[reply]
Whether the scope of G13 (which is essentially a PROD with the timespans usually involved) could be expanded to cover this is another queston - if people want to keep drafts, one minor edit every 6 months is hardly onerous.... Mdann52 (talk) 12:11, 16 March 2015 (UTC)[reply]
That's never gained consensus before. Too many active editors like myself have some drafts hanging around in our "get to it someday" pile. Gigs (talk) 19:35, 17 March 2015 (UTC)[reply]
This is why I believe a PROD would be better than a speedy. Would allow active users to keep their drafts hanging, while drafts by people who haven't edited in 5 years can be gotten rid of if necessary. If I want to propose this do I have to draft up a page for it and everything?Bosstopher (talk) 19:30, 19 March 2015 (UTC)[reply]
Probably a good idea to write up a proposal for discussion, if only to bring attention to the issue. I doubt there'd be anyone really against it, but at least if it comes as a surprise to somebody who doesn't pay attention to goings-on, you'd have something to point to if a dispute came from it. // coldacid (talk|contrib) 21:19, 19 March 2015 (UTC)[reply]
Ok I have created a proposed page at Wikipedia:Proposed deletion (drafts). I would welcome any feedback/opinions/edits to make it less messy. Bosstopher (talk) 20:41, 21 March 2015 (UTC)[reply]

Other than a technical fix for the template links, I think it looks good. I'm certainly in support for that. // coldacid (talk|contrib) 02:21, 22 March 2015 (UTC)[reply]

Looks good and seems like a sensible proposal. I think the second bullet point in "before nomination" should include semi-automated cleanup runs and things like deleted templates/categories being removed, but I can't think of a succinct way to word that so I'll leave it to someone better with words than myself. Sam Walton (talk) 10:46, 23 March 2015 (UTC)[reply]
Agreed. Bosstopher, maybe we could have an RFC on the same and propose the new page there? That seems like a reasonable approach to move forward with this matter, given this solution pretty much solves plenty of MFD issues. Soni (talk) (Previously TheOriginalSoni) 08:45, 1 April 2015 (UTC)[reply]

Alternative

A better alternative to a Draft PROD would be a small policy tweak to the MfD. A Prod would only encourage the deletion of more and more drafts, which we do not want. Rather, we can have a new rule that administrators be allowed to delete stale drafts that have gone uncommented at MfD In 7 days. Of course, editors can still vote keep to stop the deletion. This combines the advantages of a prod system and an XfD system and solves the problem described by Xaosflux. I believe there are many who keep a watch at the MfD to pick up drafts for improvement. A draft prod would just result in many behind-the-curtains deletions. SD0001 (talk) 10:39, 23 March 2015 (UTC)[reply]

I dont think it would necessarily create a behind-doors situation. If something similar to WP:PRODSUM is created for DraftPROD, there would still be a page for people to watch to save old drafts. Also while it would encourage the deletion of old drafts, the prospect of imminent deletion is exactly the sort of thing that would galvanize editors to work on these drafts and make them into actual articles.Bosstopher (talk) 18:21, 25 March 2015 (UTC)[reply]
I'm opposed to allowing the deletion of drafts, aside from one that match the existing speedy criteria or that go through MFD. The whole point of drafts is that they can sit there, immune from un-discussed deletion unless they have major problems or unless they're demonstrably abandoned. However, I like SD0001's idea; we can simply treat the un-discussed draft MFD as a delete. Nyttend (talk) 18:26, 25 March 2015 (UTC)[reply]

RfC on Draft PROD policy proposal is now live

You can discuss this proposal on this page. Do policy change RfCs need to go into that centralised discussion box thingy? Bosstopher (talk) 12:18, 3 April 2015 (UTC)[reply]

Permanent Semi Protect/pending changes protect

(non-admin closure) Consensus is clearly against this proposal. wctaiwan (talk) 17:42, 1 April 2015 (UTC)[reply]

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.

Wikipedia's problem is that if a page is semi protected , its mostly for a short period of time .Unfortunately even requests are made in protected page requests to remove the semi-protection . People like administrators don't think about the problems faced by us constantly dealing with IP vandal or some kids looking for fun. The user TheRedPenOfDoom is working so hard to keep WP safe , including Cyphoidbomb . Please relieve the work load from them , even if they don't complain.

Pages with high levels of vandalism should be permanently semi-protected and no requests should be made to remove the semi-protection but request can be made for permanently pending changes request .

Permanent Semi protection or permanent pending changes protection is very necessary right now for all those pages which faces constant vandalism .


All those pages related to biographies of living persons(popular politicians , Prime Ministers , Presidents , Popstars, actors) , latest political conflict , latest popular movies are constantly vandalized.

We must also make rules about IP edit policy . Opening a Wiki account is very easy . If any editor wants to contribute , I don't think opening an account will discouarge him to contribute positively. Right now 60 to 70% of IP edits are vandal edits. An account helps in identifying sock puppets , but IP socks are difficult to catch. Yes I agree that anybody can edit WP. But Everybody should have an account at least. I have seen sock puppet investigations case pages ,Check users block sock accounts but 90% of times they refuse to block IP socks for obvious reasons.

So either WP must ban IP edits or a semi protected page should never be unprotected. If any one of the rules is followed it would benefit WP--Cosmic Emperor (talk) 04:47, 26 March 2015 (UTC)[reply]

And also permanent pending changes review cam also be considered and talk pages be unprotected , so anyone can edit be followed along with page protection . But we must stop thiese IP edits . --Cosmic Emperor (talk) 05:53, 26 March 2015 (UTC)[reply]

I am not going to discuss anymore . Al Last I will say create more bots which fights IP Vandals, The bots must have more AI . And there must be bots with high knowledge of Grammar and punctuation. Bots which easily identifies negative edits like this 19 September 2014 and this--Cosmic Emperor (talk) 09:13, 26 March 2015 (UTC)[reply]


  • Oppose Wikipedia is the encyclopedia that anyone can edit. This would fundamentally change that. See WP:FIVEPILLARS #3. Walter Görlitz (talk) 14:00, 25 March 2015 (UTC)[reply]
  • 5 vandal edits per what? Hour? Day? Month? Ever? There are plenty of admins who still do anti-vandalism work and plenty of them who did it before they became admins. As someone who's been here for close to a decade now, I can say without hesitation that between rollback, Huggle, edit filters, and ClueBot NG, dealing with vandalism is easier than it has ever been. We're all volunteers. No one is forcing people to do things they don't want to do. Changing one of our core principles to reduce the workload on people not complaining about their workload doesn't really make any sense. Mr.Z-man 14:18, 25 March 2015 (UTC)[reply]
  • Oppose There are plenty of people that come on Wikipedia reading, notice a problem and, as an IP, fix it. Remember, most people want to help the project, making it harder (even if making an account is really easy) is just going to discourage the good faith editors. If you require accounts to edit Wikipedia I doubt that someone who wants to vandalize Wikipedia is going to hesitate to make an account and if that account is blocked I doubt they'll hesitate to make a sock. With an average of around 100 edits per minute on Wikipedia, putting even a small percentage of those changes into pending changes would result in a backlog. PhantomTech (talk) 16:28, 25 March 2015 (UTC)[reply]
  • Oppose. From WP:PROTECT, "Wikipedia is built around the principle that anyone can edit it, and it therefore aims to have as many of its pages as possible open for public editing so that anyone can add material and correct errors." I am against overuse of protection, and simply protecting a page after five instances of vandalism (regardless of the time period between them, I gather?) is almost unquestionably overuse. This is coming from a person who has done a good amount of anti-vandalism, and it is hard, even when you have convenient tools like Huggle. Our slogan, "The free encyclopedia that anyone can edit", is displayed prominently on the main page. And then, on our introduction page, we expressly say that "anyone can edit almost every page", and it further encourages the reader to do so. If a person who has just discovered Wikipedia reads this, and then finds out that he is unable to edit the better part of our pages, he'll probably imagine that our slogan is just a big lie. In fact, when I was looking at articles (before I registered my account), I was quite surprised to discover the amount of pages that could not be edited. We don't want to make that problem even worse by instituting some arbitrary threshold, thus making us even more government-like. --Biblioworm 14:38, 25 March 2015 (UTC)[reply]
Considering your statement "And then, on our introduction page, we expressly say that "anyone can edit almost every page", and it further encourages the reader to do so. If a person who has just discovered Wikipedia reads this, and then finds out that he is unable to edit the better part of our pages, he'll probably imagine that our slogan is just a big lie."I can agree with the part that let everyone edit but please let them have an account , And I will put pressure on – NO IP EDIT– . If WP don't have such rules, then it has to change for good.Cosmic Emperor (talk) 16:10, 25 March 2015 (UTC)[reply]

Maybe in USA there are large number of editors, but in other countries there are a few , so you don't know. I have seen lots of pages where articles are written without proper source still no correction for a long time . For example in this biography of a living person Kartik Tiwari its stated that Kartik Tiwari aka Kartik Kumar is an Indian actor who appears in Bollywood films. . Nowhere you will find any reliable reference that he is known as Kartik Kumar . I think the above example is best to prove my point. The edit was done 19 September 2014 . Now what were all those volunteers doing . So will you support the strange case "its better to have wrong info on Wikipage than have a registered user not just an IP editor"Cosmic Emperor (talk) 16:10, 25 March 2015 (UTC)[reply]

"If anyone can edit it" at least make sure that it's a registered account , not some IP address . Now allowing IP to edit is also WP fundamental principle? . Why can't you people make E-Mail verification compulsory . The current policy is an open invitation to IP socks and sock account. Opening an account is child's play. Its as if let people create socks and disruptive editing , we are here to revert and rollback .You said "I can say without hesitation that between rollback, Huggle, edit filters, and ClueBot NG, dealing with vandalism is easier than it has ever been." It sounds like a manager of a bank who says"We will allow thieves steal money by keeping the bank locker open , we have voluntary policemen who will catch the thief later on." Cosmic Emperor (talk) 15:59, 25 March 2015 (UTC)[reply]
@PhantomTech: Till now i have seen more Ip vandals than IP contributers,Walter Görlitz (talk),@Mr.Z-man:I am not asking for every article , only those which have high rates of vandalism, maybe only 5 acts of vandalism as stated by me before is not enough for permanent semi protection . So I came up with this idea of four rules four permanent semi-protection

1)-50 acts of vandalism in one last 16 monthsor 5 vandal edit in a week

2)-The article is not a stub , and also the article is

3)-Properly sourced ,

4)-The article is minimum 5 years old(from the date of creation) and has gone through minimum 200 edits.(that means even if the article is 6 years old with 199 edits and 4 years old with 500 edits but still can't be permanently semi-protected)

@Biblioworm: If all the four above mentioned qualities are found in any article , then it should be permanently semi-protected or permanently pending changes review . Let the new users and Ips use talk page to discuss , I hope this time you will agree with me as I have changed my views Cosmic Emperor (talk) 16:10, 25 March 2015 (UTC)[reply]

The concern raised by Cosmic Emperor is quite genuine. Even I have many a times felt that there are more editors here who just revert vandalism than editors who contribute content. But disallowing IP editing is not something for which consensus can be achieved by any simple discussion like this. I have to disagree with PhantomTech when he says that "most people want to help the project", as I feel that more IPs are here to vandalise than to make constructive edits. Remember, WP:AGF was written a decade ago, when Wikipedia was much less popular and hence the fun of vandalising it was much less.
P. S : User:Carrite is an old-time opposer of IP editing. SD0001 (talk) 17:19, 25 March 2015 (UTC)[reply]
@SD0001 and CosmicEmperor: Even if there are more IP editors that do harm than good, it is quite easy to find most bad faith editors using IPs and I don't think there's much of a problem when it comes to finding and reverting that vandalism. Think about who would be stopped from editing if you were required to make an account, people who don't feel it's worth the time to pick a username and password. While this could stop many vandals that put little effort into their work, ClueBot deals with those without a problem. I highly doubt that a significant amount of people who come to Wikipedia to vandalize it would be stopped by having to make up a username and use "password" or something similar as their one time password. On the other hand, this would discourage readers who notice a small problem from trying to fix it. SD0001 is probably right about there being more editors that revert vandalism than those who contribute to articles but is there really a problem with that? I think most of the vandal fighters here do so by choice, not because even though they'd rather be contributing to articles they feel some obligation to fight vandalism. If all the vandals just disappeared one day I think a majority of the users who only fight vandalism would just become less active or leave, not start contributing to articles more than they would have before. PhantomTech (talk) 19:40, 25 March 2015 (UTC)[reply]

@PhantomTech and Biblioworm: Phantom Tech believes that an IP vandal who wants disruptive editing will eventually open an account and will open sock account if the first account is blocked , so according to him blocking IP edit will discourage good faith editors who IP edits. Likewise , I believe that a good faith editor will open an account if he really wants to contribute. A new user with good knowledge will never let a page with wrong info. I don't think making account edit compulsory will discourage good faith editors. Its an assumption by Phantomtech that good faith editors are too lazy to open an account.

And I don't know how many times I will state that I am not asking this rule for every wiki page.Most people opposing are thinking that I am asking every wiki page to be permanently semi-protected. Please read the four rules mentioned above once againCosmic Emperor (talk) 04:35, 26 March 2015 (UTC)[reply]

@CosmicEmperor: To your 5 points, if every article that met those requirements in say the last year was permanently semi-protected a significant percentage of Wikipedia articles would be permanently semi-protected. I'm excluding the age requirement (but not the edit count requirement) there because I've never checked how old an article is so I don't know exactly how that would affect the number and because an article can be a good article and a target for vandals without being around for a few years, it doesn't make sense to me to involve age in protection. The reason I don't think as many good faith IPs will be willing to make accounts as bad faith IPs is because vandals come here with a purpose, to vandalize, and they seem to be quite persistent about achieving that goal, making up a password for one time use isn't a big deal. On the other hand, a good faith IP editor usually comes here to read, if they notice a problem they might try to fix it but if they get asked to make an account they might decide that it's not worth their time, especially if they're told they also have to wait a few days and make 10 other edits first because the page is semi-protected. To effectively remove IP vandals you would have to make getting an account harder and you can't do that without pushing away good faith editors in the process. PhantomTech (talk) 04:56, 26 March 2015 (UTC)[reply]

PhantomTech (talk) We can give them instructions to write on talk page , And I want talk pages should never be semi protected, only the artcle be permanently semi-protected.They will read the edit notice . And there is proof to your statement that IP vandals are more aggressive than good faith guest editors . One or two person don't speak for everybodyCosmic Emperor (talk) 05:42, 26 March 2015 (UTC)[reply]

@CosmicEmperor: Yes, there is proof that vandals are more aggressive than good faith editors. WP:LTA is great evidence of how persistent vandals are, and remember that the ones listed there are just the most extreme, there are plenty of vandals that act over a few days or weeks that don't make it to LTA. There are LTA cases where users have over 100 sockpuppets, think of how many well known good faith IP contributors there are and how many of them would be willing to go through the effort to make even a fraction of those accounts. (of course as good faith editors, they wouldn't actually make the accounts, this is just to try to put into perspective what each group is willing to do to edit) Vandals come back all the time but that isn't how good faith contributors work, they might only ever edit Wikipedia once or twice and the only reason it makes a difference if they're gone is because of how many people do that. If you want some data to support that look at IP edits in the recent changes feed, when you see a clear vandal look at their list of contributions, when you see a good faith edit look at those contributions, compare the number of different days each has contributed and you'll find that vandals come back more often than good faith contributors. You could say that this is inaccurate because IPs move from person to person but with a big enough sample size the only explanation would be that for some reason vandals are assigned IPs that were previously used for vandalism, but they're not, IPs are assigned without relation to Wikipedia activity. PhantomTech (talk) 06:27, 26 March 2015 (UTC)[reply]
  • Oppose on principle, but interested in seeing some expansion here. I would perhaps be willing to a well thought out ProtectBot that can minimize damage to articles without locking out valid modifications usually. — {{U|Technical 13}} (e • t • c) 17:53, 25 March 2015 (UTC)[reply]
  • Comment. If we block IP editing, we'll move one step closer to being like Citizendium. With all due respect to Sanger's efforts, visit Citizendium's website and see how spotty their articles are. There are some very well-known topics that don't have articles there. That's what happens when you make it hard to edit a wiki. Do you want that to happen to us? --Biblioworm 17:55, 25 March 2015 (UTC)[reply]
  • Oppose - The most easiest option here is to ban IP editing altogether, I appreciate this is a "anyone can edit" website but at the end of the day the vandalism here is getting worse and worse and worse and IMHO... Something needs to be done about it, Sure some IPs edit constructively .... but most don't. –Davey2010Talk 03:31, 26 March 2015 (UTC)[reply]
  • Yikes. Oppose. In my opinion, permanent semi-protection is already very much overused, and most articles that have been semiprotected for over a few years already should be unprotected in case the vandalism doesn't come back. Allowing everyone to edit is important, protection should be an absolute last resort. --Yair rand (talk) 07:22, 26 March 2015 (UTC)[reply]

This is funny , if a page is semi-protected how can it be vandalised by IP vandals. A semi protected page must be unprotected if not vandalised. They had the intention but couldn't do it due tos emi-protection. It can be done only for those pages which is under watchlist of minimum 10 editors with rollback rights

Unfortunately we can't see how many respectable editors have kept the page under watchlist. But those pages which are not under watchlist of 10 editors with rollback rights/administrators/auto patrollers should be protected. But still IP edits must be banned . Its a nuisance Cosmic Emperor (talk) 07:59, 26 March 2015 (UTC)[reply]

  • Oppose - I think we're overusing semi-protection. Semi-protection isn't the main method for dealing with vandalism; RBI is (where, in the case of IPs, the "B" is as short as possible). In order for RBI to keep working, we need to keep up with recruiting more users - and semi-protection of the articles which they are most likely to want to use for their first edit is a good way to scare them away. עוד מישהו Od Mishehu 17:42, 26 March 2015 (UTC)[reply]
  • Strongly oppose - at one point or another every page gets semi-protected, so before you know it the whole project will be. This is clearly not what we want to do (scaring away IPs and preventing them from editing) and after a page gets removed from semi-protection under the current system often vandalism doesn't resume. Kharkiv07Talk 03:27, 27 March 2015 (UTC)[reply]
  • Comment Wikipedia:IPs are human too#Common misconceptions says: 80.2% of vandalism was done by unregistered editors. But 81.9% of edits by unregistered users were not vandalism. --Fauzan✆ talk✉ mail 05:43, 27 March 2015 (UTC)[reply]
  • Strong oppose per WP:ANYONE and WP:NOTFINISHED. This goes against the very spirit of the project. Just to note as well that pages highly susceptible to vandalism already can be permanently semi-protected by request at WP:RFPP. Ivanvector (talk) 12:01, 27 March 2015 (UTC)[reply]
See also Wikipedia:Perennial proposals#Prohibit anonymous users from editing. Ivanvector (talk) 19:16, 27 March 2015 (UTC)[reply]
  • Oppose - No page should be permanently semi - protected, in the same way that IPs are not indefinitely blocked. Cosmic Emperor says 60 to 70% of IP edits are vandal edits. The study shows that 81.9% of IP edits are not vandalism. We should lift the bar on IPs starting articles. The traffic is not so great that new page patrollers could not comfortably vet all articles started by IPs. Why do you think that shop windows are largely glass? Because if they weren't nobody would go inside (because they like to see what they are getting into). All Wikipedia clones are largely deserted because they don't offer the facility to "try before you buy" which is what makes Wikipedia so successful. Pending changes should be done away with (it only hangs around because the developers couldn't be bothered to disable it after the community voted it down) - every article has watchers who will revert any vandalism within minutes. The time spent by pending changes reviewers would be better spent reviewing articles started by IPs. 87.81.147.76 (talk) 16:16, 27 March 2015 (UTC)[reply]
  • Oppose, there is no "unfortunately" in "not everybody can see which pages are unwatched", and the theory that administrators don't think about other abuse fighters is bizarre. –Be..anyone (talk) 17:05, 27 March 2015 (UTC)[reply]
  • Oppose - Semi-protection should be limited, because in any given period of time, either the IPs can be blocked, or the IP block can be blocked, or the vandals will go somewhere else. I disagree with proposals to make it easier for unregistered editors to edit, but that isn't the subject. Robert McClenon (talk) 17:16, 27 March 2015 (UTC)[reply]
  • Strongest possible oppose - Wikipedia is the encyclopedia that anyone can edit, and having articles permanently protected is contrary to the spirit of that philosophy. Remember that "indefinite" and "permanent" are, at least in theory, not synonymous. Also, the section Wikipedia:Perennial proposals#Protecting Today's Featured Article on the main page may be of interest, as both that proposal and this one have similar arguments. Narutolovehinata5 tccsdnew 15:35, 31 March 2015 (UTC)[reply]
  • Strong Oppose P-Permanent!!??? So you trying to kill the spirit of Wikipedia, that Wikipedia can be edited by anyone?--AldNonUcallin?☎ 10:12, 1 April 2015 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

A tool to synchronize lists & categories

I think a tool to synchronize lists & categories is badly needed if it doesn't yet exists.

For example I'd like to syn this category: Category:Science_fiction_horror_films with this list: List of science fiction horror films

(It should check all links on the list and compare it to all links on the category [and in this case its sublists])

--Fixuture (talk) 21:38, 26 March 2015 (UTC)[reply]

Support S a g a C i t y (talk) 08:10, 30 March 2015 (UTC)[reply]
Support Sounds like a good idea. Psychotic Spartan 123 02:11, 31 March 2015 (UTC)[reply]

Proposed change for headers (allowing parenthesis texts to be used at reduced sized)

I have just converted this thread as an RfC. This is since my initial presentation of this thread here, and following notification of a route by which this proposal could be actioned which was requested here. GregKaye 17:52, 28 March 2015 (UTC)[reply]

Examples of parenthesis at WP:PRECISION include Leeds North West (UK Parliament constituency) and M-185 (Michigan highway) with the parenthesis, in both cases, not being necessary for disambiguation.

An (outdated) example to disambiguation is Energy (physics) (which now redirects to energy).

Pages are currently presented as:

Leeds North West (UK Parliament constituency)
M-185 (Michigan highway)

Thanks to input from PrimeHunter below it seems that they can be presented as follows:

Leeds North West (UK Parliament constituency)
M-185 (Michigan highway)
Energy (physics)

Code formats:

{{DISPLAYTITLE:Leeds North West <small>(UK Parliament constituency)</small>}}
{{DISPLAYTITLE:M-185 <small>(Michigan highway)</small>}}
{{DISPLAYTITLE:Energy <small>(physics)</small>}}

Recently I've been making some regular reference to Britannica and have noticed that their articles make regular use of subtitles which are used more for the purpose of description than disambiguation. An example of their presentation is found at http://www.britannica.com/EBchecked/topic/528623/Arnold-Schwarzenegger which gives an approx appearance as follows:

Arnold Schwarzenegger
American politician, actor, and athlete
Written by: The Editors of Encyclopædia Britannica [ I C O N S ] Last Updated 2-5-2015     READ EDIT VIEW HISTORY FEEDBACK
Arnold Schwarzenegger, in full Arnold Alois Schwarzenegger (born July 30, 1947, Thal, near Graz, Austria), Austrian-born American bodybuilder, film actor, and politician who rose to fame through roles in blockbuster action movies and later served as governor of California (2003–11). ...

A similar method of presentation in Wikipedia might appear:

Leeds North West
UK Parliament constituency
M-185
Michigan highway
Energy
physics

At the moment parenthesis is used for little more than minimalist disambiguation with little emphasis on the provision of additional information. Perhaps one of the reasons for this may be the large size of presentation of the title texts in parenthesis.
GregKaye 11:31, 28 March 2015 (UTC)[reply]

I don't think that this is possible; the only way to get part of the title to appear on a second line is to create a title that's so extremely long that it flows onto the next line, e.g. this redirect to Darwin's Origin of Species. Nyttend (talk) 12:32, 28 March 2015 (UTC)[reply]
It would be a terrible idea to abuse parenthesis text for that. But, note that the mobile team will be experimenting with using description labels from Wikidata as subtitles link. —TheDJ (talk • contribs) 13:44, 28 March 2015 (UTC)[reply]
It's possible to change size or font of part of a DISPLAYTITLE. As a test I have added {{DISPLAYTITLE:Energy <small>(physics)</small>}} to the redirect at Energy (physics), but I don't support such a system. It's not possible to change characters so if the real pagename is "Leeds North West (UK Parliament constituency)" then it cannot display as "Leeds North West, UK Parliament constituency", but it could if the real pagename was changed to "Leeds North West, UK Parliament constituency". You could mess around with position to display part of a DISPLAYTITLE in another place (see Template:DISPLAYTITLE#Examples for placing it outside the screen), but I don't know whether there is a reliable and stable way to move it down a line, and I don't support it. PrimeHunter (talk) 14:38, 28 March 2015 (UTC)[reply]
PrimeHunter Thank you. I personally think that the idea could have a lot of mileage and I'd encourage editors to take a look: [Energy (physics)].
My impression is that editors at WP:RM have a general dislike of parenthesis often on the basis of WP:NATURAL with the result of misrepresentations of central title content. I recently put a few "John Smith"s in for RM. In cases middle names had been used yet I didn't see reference to these references being in uses in the lifetimes of the people concerned. A reduction in the size of the parenthesis content might make other forms of disambiguation more palatable. I have changed the title of this thread to give an example of use. GregKaye 16:23, 28 March 2015 (UTC)[reply]
Looking at the Arnie example, I would even go one step further and allow <br/> in {DISPLAYTITLE} to accomodate dual-line rendering. W\|/haledad (Talk to me) 01:58, 30 March 2015 (UTC)[reply]
It's a TITLE, not a SUBTITLE. Stop using things for purposes that they were not intended to fulfill. —TheDJ (talk • contribs) 06:03, 30 March 2015 (UTC)[reply]
TheDJ, granted. It is a title that is there to provide explanation. In the use of parenthesis some of that information, I think, can be regarded as clarification information and, in many cases, I think that this parallels the use of subtitles. I think that all we are doing is considering terminologies but I think that, if Britannica were to have an article on "Leeds North West" then something along the lines of "UK Parliament constituency" would act the subtitle. An example of a Britannica article is John Smith with subtitle "British Explorer". As you may guess Britannica has a number of articles entitled "John Smith" and in a related listing, produced by the query "John Smith", the "subtitle" (which is my description of this content) is presented as (British Explorer) in a very similar fashion to our format. I don't know if we are in disagreement.
The section title WP:PRECISION is really about precision and clarification but, in the context of talk of disambiguation, I think this can get lost. GregKaye 12:51, 30 March 2015 (UTC)[reply]
I don't care about any of that. The only reason we use disambiguation parenthesis is because an article title needs to be unique. If that limitation was not there, parenthesis likely would not be in the title at all. A subtitle seems like a nice idea, but then you should change the software to separately register and keep track of a specific subtitle field. It is not a good idea to abuse one data field in a system for two totally separate purposes. This is why the mobile team's subtitles are good, because they are treated and handled as a separate datapoint, in this case from WikiData. So if you want to do this, I suggest the way forward is to first experiment with a Javascript gadget for the desktop site, that ueries wikidata and that hides whatever is in the parenthesis (or better suggest's it as an entry for wikidata). Do not plan new features from what you got, but primarily base it on where you need to go. —TheDJ (talk • contribs) 14:28, 30 March 2015 (UTC)[reply]
  • I think it would be nice, all other things being equal, if parentheticals in titles were typographically set off somehow. All else being equal. It's not a big deal, and in no event should it be achieved at the expense of adding any kind of hack to the machinery. Likely this should be added to the list of Things To Do Sometime In The Distant Future When The Opportunity Presents Itself To Do Them Absolutely Cleanly. EEng (talk) 00:42, 3 April 2015 (UTC)[reply]

Proposal: creation of "style noticeboard"

A user has proposed the creation of a "style noticeboard" (Wikipedia:Style noticeboard) at the MoS talk page, similar to the likes of the reliable sources noticeboard. He described the noticeboard in this manner: "a place where editors can raise and discuss specific situations, and get opinions on how to interpret the policy or guideline in the context of those specific situations". Such a noticeboard does not currently exist, and style issues are dealt with across a wide variety of labyrinthine MoS pages. The goal of the noticeboard is to allow for the centralised discussion of specific style issues at specific articles, so that users can come to consensus on how to interpret a specific piece of style guidance in our policies and guidelines, such as WP:AT and WP:MOS. Should such a noticeboard be created? RGloucester — ☎ 18:10, 28 March 2015 (UTC)[reply]

Support: style noticeboard

  1. Support – There is no reason for there not to be such a noticeboard. The present system is not very good. Discussions are scattered across tens of MoS pages, article talk pages, Wikiprojects, &c. The creation of this noticeboard would allow for centralised and organised discussion of style issues, so that they can be quickly resolved. As we already have a series of similar noticeboards, such as WP:RS/N and WP:OR/N, I believe that this proposal should go forward. I have created the proposed noticeboard page, modelled on WP:RS/N. Please see Wikipedia:Style noticeboard. RGloucester — ☎ 18:15, 28 March 2015 (UTC)[reply]
    At this edit you originally opposed this idea. Can you explain whether this is a change of heart, or a different proposal, or what? Dicklyon (talk) 00:22, 29 March 2015 (UTC)[reply]
    It is merely a thought process. RGloucester — ☎ 02:01, 29 March 2015 (UTC)[reply]
  2. Support it would be helpful to have a place for people to ask specific style questions other than wt:mos. I think a central noticeboard is better than a giant "request for style guidance!!!!" template on talk pages throughout wikipedia, both for ease of management and for ease of locating past discussion, which is what I understand PBS to suggest. Not sure what's going on with the numbering here. AgnosticAphid talk 17:20, 29 March 2015 (UTC)[reply]
  3. Mild support I have no problem whatsoever answering people's questions at WT:MoS, but a noticeboard might be easier for people to find. Darkfrog24 (talk) 18:29, 29 March 2015 (UTC)[reply]
  4. Support – I think WP needs a different venue for discussions about MoS issues. Often the discussions on talk pages (such as MOSNUM talk, in particular) can become overly long, and they can easily wander too far from the supposed topic of the talk page: changes to the MoS. Many threads on that talk page, indeed, have been about how editors should understand the existing MoS text, rather than proposals for changes to it. But as it stands, there is simply nowhere else to go to ask such questions. Archon 2488 (talk) 21:16, 29 March 2015 (UTC)[reply]
  5. Support - A centralized noticeboard would be beneficial to getting help with style questions and getting outside opinions in style disputes.- MrX 21:28, 29 March 2015 (UTC)[reply]
  6. Support Good idea, so long as it's watched by active knowledgeable editors. §FreeRangeFrogcroak 21:47, 29 March 2015 (UTC)[reply]
  7. Support - A noticeboard would be easier for newbies to find and maybe a little easier to patrol, once we get past the initial re-routing posts to the new board. Mlpearc (open channel) 21:52, 29 March 2015 (UTC)[reply]
  8. Support creation of this noticeboard; there were times I would have used it myself – had it been an option in my time of need. I am familiar with the cadre of personnel who generally comment on questions of Wikipedia styling and they are a competent creed who engender great confidence. Because of their collective professionalism, I expectantly anticipate that this noticeboard will quickly become the go-to example of a Wikipedia-thing "done well". Also, when you consider the stifling effect that discretionary sanctions have brought to so many talk pages, it becomes more apparent that neutral "sanctuaries of discourse" like this are needed things. Ironically, even Wikipedia talk:Manual of Style is subject to discretionary sanctions which cements my belief in the need for this noticeboard. Consider mine: strong support.--John Cline (talk) 03:33, 30 March 2015 (UTC)[reply]
  9. Support – It would be a nice change to have a better, centralized place to bring up discussions concerning the Manual of Style rather than starting threads on one of the many different style talk pages. Dustin (talk) 00:39, 31 March 2015 (UTC)[reply]
    Comment - I'm abstaining, but it's worth noting that a note at the top of WP:VPP says: If you have a question about how to apply an existing policy or guideline, try the one of the many Wikipedia:Noticeboards. It says nothing about WT:MOS or any other talk page. ―Mandruss ☎ 01:57, 31 March 2015 (UTC)[reply]
    Apparently that's as it should be, the MOS talk pages are for discussions about the MOS pages, not for general help with MOS applications. WP:PNB and {{noticeboard links}} list teahouse, help desk, etc. and also don't mention WT:MOS. –Be..anyone (talk) 00:32, 2 April 2015 (UTC)[reply]
    The first line at WP:PNB kinda sums it up. Mlpearc (open channel) 00:40, 2 April 2015 (UTC)[reply]
  10. Support: Makes for more organized discussion of style guidelines, which are one of the most discussed areas of Wikipedia editing. Esquivalience t 03:13, 31 March 2015 (UTC)[reply]
  11. Support as an attempt to centralize discussions which currently get spread all over the place. — {{U|Technical 13}} (e • t • c) 17:14, 1 April 2015 (UTC)[reply]
  12. Support: I understand this as a proposal to create a place to help people who have writing style questions. At the top of WT:MOS, it says: "This is the talk page for discussing improvements to the Manual of Style page" but it has also served as a place to answer style questions. I think it is good to separate out those two functions. Inevitably there will sometimes be disagreements there, but it is good to keep them separate from discussion of what the MoS should say. It could turn into forum shopping, but better to expose style questions to people with an interest in writing style than leaving them on a seldom watched talk page. The people opposing seem to be talking about something else. If I'm missing something - let me know.  SchreiberBike | ⌨  00:47, 2 April 2015 (UTC)[reply]
  13. Support: great plan. It will help bring consistency. Atsme☯Consult 18:32, 2 April 2015 (UTC)[reply]
  14. Support Per the above; obviously a good suggestion.--Ubikwit 連絡 見学/迷惑 19:09, 2 April 2015 (UTC)[reply]
  15. Support: WP:Reference desk allows users to seek specific factual information that they may have trouble finding themselves in our articles. The proposed noticeboard would do the same for style guidelines and best practices. —174.141.182.82 (talk) 02:00, 4 April 2015 (UTC)[reply]
  16. Support, let's give it a shot, there seems to be enough people who are willing to volunteer. Kharkiv07Talk 02:14, 4 April 2015 (UTC)[reply]
  17. Support It sounds like a good idea. A place to get answers about style based on policy from uninvolved editors. AlbinoFerret 02:57, 4 April 2015 (UTC)[reply]
  18. Support WT:MOS is a place to discuss the MOS itself, not an (official) place to ask questions. --Fauzan✆ talk✉ mail 14:38, 4 April 2015 (UTC)--Fauzan✆ talk✉ mail 14:38, 4 April 2015 (UTC)[reply]

Oppose: style noticeboard

  1. Oppose per WP:CREEP, WP:NOTFORUM and de gustibus non est disputandum. Andrew D. (talk) 21:49, 29 March 2015 (UTC)[reply]
  2. Oppose. For style questions relating to individual articles, the place to encourage discussion is not on a new noticeboard, but on the talk pages of the relevant article (or template, category etc.). We should also encourage style-related questions to be raised within the various WikiProjects. I also agree with Andrew D.'s concerns, noted above. Neutralitytalk 23:34, 29 March 2015 (UTC)[reply]
  3. Oppose We don't need yet another place to drag users and berate them when we disagree with them. If someone is being disruptive over style issues, we already have places to discuss that. If people want to have genuine, non-confrontational discussions of style issues, we already have places for that too. This board is unneeded, and more "noticeboards" are merely magnets for more drama. No thanks. --Jayron32 00:04, 30 March 2015 (UTC)[reply]
    Jayron32, your comment rests on a false premise. You must surly speak in jest when you suggest such nefarious motives; underpinning the creation of this noticeboard.--John Cline (talk) 04:06, 30 March 2015 (UTC)[reply]
    No where in my post did I mention any motive for creating this board. I don't really care why you want to create it, or what your motives are, and my oppose isn't based on what your motives are, because I am not a mind reader, and have no way to know your motives. I merely based my opposition the expected result of creating the board, based on the action at literally every other board at Wikipedia titled "noticeboard". What users do at anything named "noticeboard" is drag their enemies in for a good kangaroo court session. I could care less why you want to create this board. But because that's what every other single "noticeboard" is at Wikipedia, we don't need another one of those. I can only judge the likely future by the patterns of the past. And those patterns tell me this will be nothing except another dramah bord. No thanks. --Jayron32 02:42, 2 April 2015 (UTC)[reply]
    Thank you.--John Cline (talk) 03:36, 2 April 2015 (UTC)[reply]
  4. oppose per Andrew D., WP:RS is a respected guideline, WP:MOS is a maze of twisty little passage, all alike, mainly existing to keep the contributors busy on something that won't cause havoc in the main namespace. –Be..anyone (talk) 10:08, 30 March 2015 (UTC)[reply]
  5. oppose - This is interesting in theory, but I fear problematic in practice. I've worked in places where creative efforts and processes are reviewed often and the derision and debate is endless. Trained artistic professionals sometimes debate vehemently, and we want to invite a bunch of anonymous amateurs to do this?! I feel that creating a board where "artistic differences" are discussed will devolve into something that will make WP:ANI A.K.A. The Drama Board pale in comparison. --Scalhotrod (Talk) ☮ღ☺ 17:11, 30 March 2015 (UTC)[reply]
  6. Oppose per above It's a good idea, but I feel Wikipedia_talk:Manual of Style is "a place where editors can raise and discuss specific situations, and get opinions on how to interpret the policy or guideline in the context of those specific situations" in relation to the WP:MOS. If you ask a MOS-related question there about MOS someone will answer. --Psychotic Spartan 123 02:08, 31 March 2015 (UTC)[reply]
  7. Oppose since in light of his comment here, I can only interpret RGloucester's proposal as an attempt to prevent the MOS from influencing style decisions. WT:MOS serves the purpose, and if we want more central style guidance, trying to move that role further from the MOS makes no sense. I would consider the original proposal more favorably. Keep in mind that RGloucester has made his contempt for the MOS very clear and explicit; so what kind of style guidance does he have in mind; he says his edits are directed by God, so I suppose that's his source of style guidance, too? Dicklyon (talk) 06:37, 1 April 2015 (UTC)[reply]
  8. Seems like more bureaucracy and arguments. Stifle (talk) 09:25, 1 April 2015 (UTC)[reply]
  9. Oppose we already have the teahouse, help desk and village pump pages to ask at. We do not need the helping volunteers to be further spread out having to look at more pages. Graeme Bartlett (talk) 11:20, 1 April 2015 (UTC)[reply]
  10. Strongest possible oppose One of the most frightening proposals I've seen. "Neutrality" (near the top of this section) has it exactly right: changes to guidelines should be discussed on the respective branches of Talk:MOS, and questions about individual articles belong on the talk pages of those articles. When and if a particular issue proves itself to be wasting editor time on multiple articles, then it's time for that issue to come up at MOS for a possible change in the guidelines, to end that waste of time. What we DO NOT NEED is another place for disgruntled style warriors to forum-shop. If it matters enough for broad discussion, then that discussion should take the form of a consideration of a change to MOS; if it can't be expressed as a possible change to MOS, then it doesn't need broad discussion and should be discussed on the talk page of the article in question. EEng (talk) 15:06, 1 April 2015 (UTC)[reply]
    @EEng: We don't seem to be on the same page. The noticeboard is meant to address cases like this one: [4]. Lots of people show up to WT:MoS asking "What should I do?" "What's correct?" "Does Wikipedia have a rule about this?" The noticeboard would be for these questions, not for suggested changes to the MoS. Blueboar and RG have both confirmed below that this is what they meant. Darkfrog24 (talk) 17:54, 1 April 2015 (UTC)[reply]
    I guess I was imagining this as mostly as a place where disputes would be brought, rather than (as in your example) simple, probably noncontroversial inquiries. That feels less objectionable to me, but still I wonder whether Village Pump isn't enough. What's the volume of such inquiries? In fact, that gives me an idea... how about if those who see a need for this new board link to a half-dozen recent inquiries (somewhere...) that would have been better handled under this proposal. If there's really a need for this, that ought to be easy. EEng (talk) 18:48, 1 April 2015 (UTC)[reply]
    The concern that the creation of the noticeboard would address is that there might be many more people with questions who simply don't know that they're supposed to go to WT:MoS to ask them. It's not that creating a noticeboard would improve the quality of the answers (which is already quite high); it's that it would improve accessibility. If a new Wikieditor has heard about the RSN noticeboard and the V noticeboard then he or she is more likely to suppose that there might be a style/English/writing mechanics noticeboard (and vice versa) than that he or she should go and ask at WT:MoS. As for examples, I did provide a few links in the discussion section below, but the list is certainly not exhaustive. I just picked an archive page more or less at random and looked around for something representative. Darkfrog24 (talk) 21:40, 1 April 2015 (UTC)[reply]
  11. Oppose; this is a recipe for more bureaucracy, disputes, drama, and chaos - all of which this area has historically managed to attract even without a dedicated noticeboard. Ncmvocalist (talk) 15:17, 1 April 2015 (UTC)[reply]
  12. Oppose There are existing venues for asking for help with style. A noticeboard to discuss and establish consensus about style is likely to contribute to the divisiveness and unlikely to be beneficial. wctaiwan (talk) 17:32, 1 April 2015 (UTC)[reply]
    Agree, and melding what you say with what I said earlier, we shouldn't have two tiers of MOS-like guidance -- some actually embodied in the text of MOS, and some embodied in some vague consensus you can only find by trawling through discussions on this new noticeboard. If we want to do something a certain way projectwide, that should be memorialized in MOS, and the various branches of Talk:MOS are the place to decide on that. EEng (talk) 17:57, 1 April 2015 (UTC)[reply]
    If one looks at the noticeboard, it makes it clear that its answers are not policy. They are merely third opinions. These would not constitute a body of precedent, or whatever. The purpose of the noticeboard is to allow people to ask questions about style guidance, just as with WP:RS/N and reliable sources. This is not about "memorialising" or "changing" the MoS. It is about directing people to obscure MoS pages, showing them the guidance, and explaining it to them, in reference to particular piece of text. It is about answering people's questions in a centralised and easy to access location. This is a great misinterpretation of the proposal. WP:RS/N does not override WP:RS. RGloucester — ☎ 18:00, 1 April 2015 (UTC)[reply]
    Oppose, unless I'm missing something, this seems like something that's best to gather consensus for on the talk page of the article. Kharkiv07Talk 00:52, 2 April 2015 (UTC)[reply]
    Moving to support Kharkiv07Talk 02:13, 4 April 2015 (UTC)[reply]
    I think you may well be missing something. The noticeboard is meant to be for asking style questions in specific instances, e.g. "I was working on article X, and found X. I was wondering if Wikipedia has a guideline about how to present this text, as the present styling seems off". It is not meant as a substitute for article talk pages, just as WP:RS/N is not. RGloucester — ☎ 01:02, 2 April 2015 (UTC)[reply]
    The proposed noticeboard is meant to address cases like this one [5], not proposed changes to the MoS or other pages. Darkfrog24 (talk) 03:48, 2 April 2015 (UTC)[reply]
  13. Oppose - The Manual of Style is a beacon attracting obsessive sorts from far and wide to fight over dashes and capitalization. This new notice board would give them increased leverage over productive content writers who may disagree with their idiosyncrasies and compulsions. We have adequate mechanisms for ensuring reasonable consistency of form already, this new noticeboard would be CREEP towards disruption. Carrite (talk) 15:13, 2 April 2015 (UTC)[reply]
  14. Oppose - What Wikipedia needs least is another drama board. Guy1890 (talk) 02:49, 4 April 2015 (UTC)[reply]
    I think that's overly cynical, fundamentally at odds with Wikipedia's bedrock principles, and unconstructive. If I'm wrong, those who feel that way are doing the project a major disservice by failing to actively and seriously advocate the elimination of all "drama boards" (I'm talking about an RfC at WP:VPR, not randomly placed negative comments). Sorry for being blunt, I don't wish to start trouble, but I think it really needed to be said. It also applies to many other discussions, past and future. ―Mandruss ☎ 03:07, 4 April 2015 (UTC)[reply]
    Since when does opposing the addition of yet another drama board mean that one must oppose all drama boards? Quite frankly, when you've been editing here more than a year or so, you'll eventually come around to one of two opinions...that many (not all) of Wikipedia's drama boards help Wikipedia move forward with improving an online encyclopedia or they hinder its further development. Live & learn my friend... Guy1890 (talk) 22:38, 4 April 2015 (UTC)[reply]
  15. Oppose per Carrite mostly. Other 'drama boards'are at least in theory supposed to relate directly to content issues - the distinguishing characteristic of most MoS-related drama is how little it actually matters to readers, who one can safely assume are more interested in relevant information than they are in whether an article does or doesn't conform to a self-contradictory 'manual' that could usefully be reduced to half a dozen short pages. Or to a simple instruction to write for the expected readership. Get that right, and 'style' issues are generally of little real consequence. AndyTheGrump (talk) 03:50, 4 April 2015 (UTC)[reply]
  16. Oppose because of flawed premise. Instead, policies and guidelines should be kept as simple as possible, and use clear language. Samsara 08:54, 4 April 2015 (UTC)[reply]
  17. Oppose If you are so concerned about MOS that you think a new noticeboard is needed try upping your meds, instead. I'm not handing anyone a cudgel to go along with their obsession. Chris Troutman (talk) 13:22, 4 April 2015 (UTC)[reply]
    Does WP:RS/N imply an "obsession" with RS? Does WP:NOR/N imply an "obsession" with no original research? It is simply a matter of answering questions. It seems like many editors here are challenging the existence of the MoS at all, and if that's the case, they ought do something about it. Otherwise, given that we have an MoS and that it is a guideline, we must provide clarity. RGloucester — ☎ 13:57, 4 April 2015 (UTC)[reply]
    Verifiability, of which reliable sourcing is an essential component, and No original research, are fundamental content policies, along with several others. Having noticeboards to discuss in central places such critical content matters is a necessity. On the other hand, while having a MOS is nice, and some of the suggestions in it are good, it's not so fundamental as to require a noticeboard. It's not critical if some obscure MOS advice is not exactly followed, it's a minor inconvenience at best; the same cannot be said about NPOV, BLP, V and such essential policies. Cenarium (talk) 18:13, 4 April 2015 (UTC)[reply]
    The people who come to WT:MoS asking for help with style issues think that those issues are important enough to be worth their time. Here's one case: [6] Don't they deserve a place to do it? What about the people who want help but don't know that WT:MoS is the unofficial place to go? Wikipedia funnels new users with questions toward noticeboards, and we've already seen that they work. Darkfrog24 (talk) 21:31, 4 April 2015 (UTC)[reply]
    For people who need help? Surprisingly, there is WP:HELPDESK. Alanscottwalker (talk) 21:38, 4 April 2015 (UTC)[reply]
    Yeah but it doesn't seem to be drawing the style questions. I plugged "spelling" and "punctuation" and "engvar" into its archive search and they don't seem to deal with those issues the way we see them at WT:MoS. Did I miss something? Darkfrog24 (talk) 23:10, 4 April 2015 (UTC)[reply]
    Direct them to help, we have a whole desk for it, if you don't want to answer there. You can even put up a banner. Alanscottwalker (talk) 23:13, 4 April 2015 (UTC)[reply]
    Actually I don't mind answering on WT:MoS. The problem that the noticeboard would solve is that the newcomers and even veteran Wikieditors might not know that WT:MoS is the place to go for style help. A noticeboard would be easier for them to find. As for the help desk, what about the part where 39 out of 40 help desk requests have nothing to do with my area of expertise? We don't make NPOV specialists wade through three dozen style, R, and V threads. That's what noticeboards are for. Darkfrog24 (talk) 02:03, 5 April 2015 (UTC)[reply]
    Experts? What experts. Helpful people fine, but experts? Don't help those you don't want to help, help those you do. Alanscottwalker (talk) 07:21, 5 April 2015 (UTC)[reply]
  18. Oppose, per WP:CREEP and reasons stated by Neutrality.--RightCowLeftCoast (talk) 19:08, 4 April 2015 (UTC)[reply]

Discussion: style noticeboard

I will oppose this proposal if it includes WP:AT as there is a perfectly good process for discussing Article titles Wikipedia:Requested moves and having a second place to discuss such things is a bad idea. -- PBS (talk) 20:23, 28 March 2015 (UTC)[reply]

This is not about moving an article. This is about asking for clarification on style guidance, just as RS/N is for asking clarification as to whether a source is reliable. RGloucester — ☎ 21:04, 28 March 2015 (UTC)[reply]
Yeah... I could see a style question that relates to an article title being raised at the new noticeboard... and what WP:AT says would logically have to factor into any answer to that question (Since a title is involved). Like other noticeboards, the proposed noticeboard is for asking questions and getting opinions... it won't issue "rulings". Blueboar (talk) 02:09, 29 March 2015 (UTC)[reply]
I have similar thoughts. To me, it isn't a problem that someone might ask a style related question at this noticeboard that they could have asked at a number of other places, like: the article's talk page, the teahouse, or Wikipedia:Requested moves – what matters is that they receive accurate information they can understand, and properly use. For example if their query did relate to a desire to move a page to another title, a quality answer would invariably include mentioning that Wikipedia:Requested moves is the correct page for advancing such a request. I do not see anything counterproductive with this noticeboard rendering such service.--John Cline (talk) 08:36, 29 March 2015 (UTC)[reply]

Another example showed up in the past twenty-four hours: [7]. This should serve both as an indicator of the kind of problem that this noticeboard might solve and the efficiency with which such problems are currently handled. The way I see it, the advantage of a noticeboard is that it might be easier to find. While the Wikieditors who come to WT:MoS with questions of this kind see them answered promptly and thoroughly, it might not occur to everyone that it is okay to ask such questions at WT:MoS. What I expect is that if this noticeboard goes up, we'd do the exact same thing but just do it there instead of at WT:MoS. Darkfrog24 (talk) 19:28, 30 March 2015 (UTC) @Mandruss: raises a good point. I think that if this motion does not carry, we should modify the note at the top of VPP to direct users with style questions to WT:MoS. That would make the status quo more official. If WT:MoS is then drowned in new questions, we can revisit the noticeboard idea. Darkfrog24 (talk) 17:35, 31 March 2015 (UTC)[reply]

Oppose – That's not what the MoS page is for. It isn't a noticeboard, and it cannot be listed amongst noticeboards. It is only for discussing changes to the MoS. Instead, I would suggest that people be redirected to the help desk. RGloucester — ☎ 03:59, 2 April 2015 (UTC)[reply]
@RGloucester: Maybe you should remove the bold "oppose" from your comment. Someone skimming the conversation might think that you are opposing the creation of the noticeboard. I am not at this time formally proposing that we direct style questions to the MoS but I plan to if this motion does not carry. As for said line or two, we already answer style questions there and it doesn't much disrupt regular business. As you can see from my comment, it would also allow us to collect information that could be used to revisit the creation of a noticeboard. Darkfrog24 (talk) 23:40, 2 April 2015 (UTC)[reply]
Oppose – Unacceptable. Style questions do not belong at the MoS talk page. RGloucester — ☎ 23:43, 2 April 2015 (UTC)[reply]
Well we got another one there just today [8]. It doesn't seem to be hurting anything, though I agree that a centralized, well-publicized noticeboard would be a better place. Darkfrog24 (talk) 01:40, 3 April 2015 (UTC)[reply]
Darkfrog24 is correct, it's potentially misleading to use a boldfaced "oppose" as a substitute for "I disagree with the preceding comment", which you've now done twice, RGloucester. ―Mandruss ☎ 01:52, 3 April 2015 (UTC)[reply]
I oppose his proposal. This discussion is not about support for my proposal. RGloucester — ☎ 03:19, 3 April 2015 (UTC)[reply]

Opinion: If this noticeboard is created and then goes horribly wrong, it will likely be because its respondents had the same mindset as the opposers here—that they’re not there to simply answer questions, but to make decisions. Which they shouldn’t. —174.141.182.82 (talk) 02:11, 4 April 2015 (UTC)[reply]

Where to place the discussion

Another issue is the style that the proposed notice board can take, I suggest that it would be better to follow the method used for WP:RM/RfC, rather than the WP:RS/N. Ie the discussions remain on the talk page of the articles rather than being placed in a central area. -- PBS (talk) 20:23, 28 March 2015 (UTC)[reply]

That's not the purpose of this noticeboard. RGloucester — ☎ 21:04, 28 March 2015 (UTC)[reply]
Can you further explain this suggestion? Exactly what sort of notice board do you propose? Is what you suggest that if someone has a style question about the article "pizza" that they put their suggestion at Pizza:talk/noticeboard? That seems like it defeats the purpose of creating a centralized place that people can ask style questions. AgnosticAphid talk 21:58, 28 March 2015 (UTC)[reply]
Exactly, AgnosticAphid. I cannot understand this suggestion. The purpose of the proposed noticeboard is to allow for editors to request a third opinion on style-related questions in a neutral space, as with RS/N. RS/N is of great use for this purpose, and I see no reason why this similar page would not be of such use. Discussion on article talk pages are important, but third opinions are essential to resolving localised disputes. RGloucester — ☎ 22:04, 28 March 2015 (UTC)[reply]
I am not sure what a style noticeboard would achieve that isn't already covered via Wikipedia:Requests for comment/Wikipedia style and naming. GregKaye 10:35, 29 March 2015 (UTC)[reply]
GregKaye the current RfC you mention is for proposals like this, things that would change the styling manuals or naming conventions. Typically they take place at WT:MOS or whatever. Those RfC are not intended to discuss how implementing MOS would affect the content of a specific article. -- PBS (talk) 15:53, 29 March 2015 (UTC)[reply]
An RfC is not practical in every situation, of course. Many editors can resolve their discrepancies within days of receiving accurate information within collegial discourse. They do in fact, often use any of a number of noticeboards, they resolve issues in a few days, instead of thirty, and then they move on. Also, before selling too many shares in RfC efficacy, let me say that I filed an RfC a few months ago. One editor responded, and an admin closed it after 30 days; opining that the one response was reasonable, of which I agreed. When you consider all of the specialized noticeboards that are currently in productive use,[9] It is counter-intuitive to speculate that something as specialized as "Wikipedia styling" wouldn't benefit from a noticeboard as equally as the others aforelinked, and counterproductive to impede forward progress for the sake of obstruction; in my opinion at least.--John Cline (talk) 13:12, 29 March 2015 (UTC)[reply]
John Cline my experience of the reliable sources notice board is one is lucky if a conversation involves more than a handful of editors eg the last one I initiated:RN/N § Tudor Place -- PBS (talk) 15:53, 29 March 2015 (UTC)[reply]
The way RM works is that a template is placed in a section on the article's talk page. It is then listed by the bot onto the RM page (see WP:RM#Current discussions). People who like to participate in RMs are presented with a current list to watch, while those who are interested in the article will be watching the talk page, so it encourages more input from both those interested in the issue in general and by those interested in the article. RM is similar to that of an RfC in that discussions are not centralised but placed on the article's talk page. I am not suggesting using either RM or RfC, for this proposal, but the RM model is I think superior to that of the notice board as the conversation is kept close to the subject of the conversation and it is easily available for future reference either on the talk page of the article or in its archives. -- PBS (talk) 15:53, 29 March 2015 (UTC)[reply]
I strongly agree with PBS that a RM model would provide an efficient way of providing a central point of reference to relevant discussion some of which might even be located on the talk page of the same project page. Perhap it is relevant to note that issues of style in wiki are something that go beyond Wikipedia. I would be interested if an RM model could be extended to cover content such as commons. I wouldn't be surprised if there may be plenty of commons and other editors who would appreciate the existence of this type of notice board, either of a form that just covered Wikipedia or that worked across projects. GregKaye 16:19, 29 March 2015 (UTC)[reply]
An "RM" model defeats the purpose of this proposal. An "RM" is about a request for a change to a specific article. This noticeboard is about requesting third opinions on the interpretation of style guidance in a neutral space away from a dispute. The whole purpose of this noticeboard is to avoid the "closeness" you are speaking about, as it is that closeness which leads to disputes. Please note that the proposed noticeboard, WP:SNB, requires that a link to the noticeboard discussion be placed on the relevant article talk pages. All editors will be informed. RGloucester — ☎ 16:57, 29 March 2015 (UTC)[reply]
RGloucester , the "neutral space away from a dispute" idea gives me the heebee jeebees as I think that this could be used in behaviours like forum shopping. The RM format might simply state the nature of the discussion with indication being given to the location of the discussion. GregKaye 13:09, 30 March 2015 (UTC)[reply]

Right now, people come to the MoS talk page asking, "Should I hyphenate this? Where?" "Should I capitalize this or use lowercase?" "Does the MoS have a rule about this?" Here are some examples: [10] [11] [12] I'm guessing that this noticeboard would be for people with these questions. Frankly, I don't mind answering them at WT:MoS (though Wavelength usually beats me to it, heh) but a noticeboard like the RSN and V boards would probably be easier for people to find. RG, Blueboar, other proponents, is this what you mean the noticeboard to do? Darkfrog24 (talk) 18:17, 29 March 2015 (UTC)[reply]

That's correct. Instead of having discussion scattered across WT:MOSNUM, WT:MOS, MOS:BIO, &c., have one centralised noticeboard for asking such questions as these. RGloucester — ☎ 18:48, 29 March 2015 (UTC)[reply]
Ecactly. Blueboar (talk) 00:31, 30 March 2015 (UTC)[reply]
  • @Neutrality: No one is suggesting a depreciation of talk pages. However, many and most talk pages have few watchers, if any. It is also true that disputes often require third opinions if they are to be resolved. Talk page discussion is always the first step, but what is the next step? That should be the style noticeboard, which would provide a neutral space watched by many editors for specific style questions, just as RS/N does. RS/N does not supplant talk page discussion, and neither would this noticeboard. As it is, people are already seeking advice across many guideline and policy talk pages, as mentioned above. The noticeboard would provide a transparent and strictly defined space for people asking for such advice. RGloucester — ☎ 00:06, 30 March 2015 (UTC)[reply]
RfCs last thirty days, and are not useful for answering quick style-related questions. Wikiprojects can be useful, but do not provide a structured and quick format for answering such questions, and are inherently non-neutral spaces. 3O, once again, is not structured to help with the specific problem that this noticeboard is trying to solve. This proposal is for something more like the reference desk or help desk, not a request system for direction intervention in the article in question. It simply an attempt to centralise discussions that are already occurring in outlying MoS pages. RGloucester — ☎ 04:17, 30 March 2015 (UTC)[reply]
  • @Dicklyon: It is very odd that you think that I "hate" the MoS, given that I spend most of my content work time on copyediting and enforcing MoS recommendations in various articles. This proposal will obviously not reduce the "impact" of the "MoS". Nothing could "reduce its impact" other than a stripping of guideline status, which no one in his right mind would even consider. The purpose of this noticeboard is to ensure that the MoS is clear, and that its prescriptions are followed. However, I think there is a fundamental problem, and that's that you are interpreting "MoS" to mean a group of editors who support your interpretation of the MoS. The proposed noticeboard sits in a neutral space. It must be in such a neutral space, or else it will loose credibility to petty squabbles amongst different factions. Disputes about style rage across the encylopaedia, and have done since time immemorial — the response to these disputes is not to continue with such attacks as the one you've written into your "oppose" comment. The goal of this noticeboard is serve as a reference desk for style questions, nothing more. Wikipedia policy and guidelines do not change because of this proposal. It will merely be easier for editors to access the MoS, which is a dense document spread out over tens of pages. RGloucester — ☎ 06:54, 1 April 2015 (UTC)[reply]
The best way to ensure that your voice is heard is to support the formation of the noticeboard and provide answers to the questions of those seeking them, not to squelch the proposal for the sake of vengeance. I can assure you that I will not be answering questions at WP:SNB if it is formed, as I recognise that my name is tainted. RGloucester — ☎ 06:57, 1 April 2015 (UTC)[reply]

Volunteers are obviously needed

Without volunteers watching this page; prepared to respond, this noticeboard cannot be the resource envisioned. For those so comprised, please consider adding Wikipedia:Style noticeboard to your watchlist now, and let's hope to see more than thirty who are willing[13] Thank you.--John Cline (talk) 09:15, 29 March 2015 (UTC)[reply]

What this board would actually do

I was against this idea at first, but then I got confirmation about what it actually is.

Right now, people already come to WT:MoS with questions like "Does Wikipedia have a policy about this?" "Another editor is doing X; is that against the rules?" "Why did so-and-so revert my changes?" "What's the right way to present this word in this variety of English?" While we've been having this conversation, two such individuals have raised such issues at WT:MoS. [14] [15]

So if you're concerned about drama... 1) You'll notice that their questions were answered clearly, briefly and without debate or argument. This is typical. 2) They're asking about things like whether "modeling" has one L or two; making the MoS shorter wouldn't help with that. 3) The demand for a noticeboard isn't coming from MoS regulars and style experts; it's meant to serve the demonstrated needs of those who wish to consult MoS regulars and style experts. This is about replacing an unofficial system with an official one, using a format that we've already seen to be effective on WP:RSN and WP:NPOVN. 4) It's the threads about changes to the MoS that tend to get everyone's back up, and the noticeboard would not be dealing with those. Darkfrog24 (talk) 14:04, 4 April 2015 (UTC)[reply]

Precedent for precedent's sake

As you can see at Wikipedia:Articles for deletion/Abhay Vidhya Mandir Senior Secondary School, Hindaun City there are 2(3 if the speedy counts) votes for delete, one vote for keep, and two for keep because of precedent.

I'm proposing we drop the idea of precedent for precedent's sake.

A school existing should not be a reason to have an article on it. It should have to be notable, just like everything else on here. This seems like a really strange exception to me. While I understand precedent, I feel that it should only ever be used to end something quickly, or if there is no consensus reached. Right now when the AfD closes it would be deleted if not for the votes for precedent. If on the other hand there was no consensus then the closing admin could use precedent to close as keep. In the legal system a judge uses precedent as a guide, not a rule. We should do the same here. Jerodlycett (talk) 04:19, 30 March 2015 (UTC)[reply]

I'm no expert, but it seems to be that the whole argument from prededent is really a short-hand way of saying "the factors that are relevant to the current matter have been debated before, and come to a satisfactory conclusion, so there is no reason to expect a different conclusion this time." And that's fine if the old and new matters are the same, but there are always differences. By analogy to the legal situation, I believe it is better treated as persuasive precedent, not as binding precedent. Look at the old case, and decide what, if anything, from that discussion is pertinent to the current. It may or may not lead to the same decision.--Gronk Oz (talk) 05:34, 30 March 2015 (UTC)[reply]
Thank you for the comment. Jerodlycett (talk) 14:30, 30 March 2015 (UTC)[reply]
  • False premise, cannot oppose or support: "Precedent," except in the form of very recent consensus or policy or guidelines, does not exist here. Indeed, the concept of it not existing is enthroned at Wikipedia:Arguments to avoid in deletion discussions#What about article x? An argument at AfD citing "precedent" is, really, an argument that the outcome is a common outcome, see Wikipedia:Articles_for_deletion/Common_outcomes#Schools. In short, it's an argument that "though in theory these can be deleted for lack of sources, as a practical matter these never get enough "delete" !votes to actually be deleted so this is a waste of time". The "rules," namely NHSCHOOL, are clear that schools have to establish notability through multiple sources, but there is sometimes a disconnect between what the notability guidelines say and what actually happens in deletion discussions. That's okay, of course, because consensus can change, both generally and on a case by case local exception basis. The point that should be made in the AfD discussion is that there is no such thing as precedent and "usual outcome" is not a substantial argument for retention. Regards, TransporterMan (TALK) 14:11, 30 March 2015 (UTC)[reply]
There are two arguments on the example I gave that state precisely that precedent is the reason for keeping. I don't know if the solution is a huge banner on common outcomes or on AfD stating that, but it's irritating to think that the article would have otherwise reached consensus and been deleted, but due to votes of precedent it may not be. The reason I put out an RFC is to try to get comments on this matter mainly, not necessarily votes, so thank you. Jerodlycett (talk) 14:30, 30 March 2015 (UTC)[reply]
  • Agree with TransporterMan. Precedent means nothing at Wikipedia, every single discussion should be decided on its own merits, based on consensus-based discussions in accordance with Wikipedia's core principles. All discussions stand on their own. That does not stop people from making bad arguments based on existing "precedent", but that doesn't mean we have to give those arguments any weight. --Jayron32 14:16, 30 March 2015 (UTC)[reply]
If this is true, then the article should close as delete per the consensus set there, correct? I'm not willing to make the bet that it will be. Thank you for your comment. Jerodlycett (talk) 14:30, 30 March 2015 (UTC)[reply]
No, consensus is assessed by the weight of the arguments. Admins are free to (and encouraged to) ignore arguments which are based on unsound principles or spurious rationales. --Jayron32 02:43, 2 April 2015 (UTC)[reply]
  • I also can neither support nor oppose because the practice of precedent for precedent's sake is not occurring, per se. WP:SCHOOLOUTCOMES is based on prior discussions which have often led to a common result, and the common result is that schools of a certain level are almost always eventually found to be notable according to WP:ORG, unless they don't actually exist. However, each case is evaluated in isolation; one school isn't notable because another one is, and there is no inherent notability for any school. This is better described at WP:WPSCH/AG#N. Ivanvector (talk) 16:14, 30 March 2015 (UTC)[reply]
I'm not sure what you mean that it isn't happening, as it is. Even an administrator is doing so. Thank you for the comment. Jerodlycett (talk) 17:40, 30 March 2015 (UTC)[reply]
What I mean is that there is a better justification for this practice than simply "precedent" or "we've always done it this way". Ivanvector (talk) 20:13, 30 March 2015 (UTC)[reply]
  • As far as "precedent" boils down to "essay" trying to outsmart a "guideline" ignoring the "essay" as it recommends at its top might be good enoough. Deleting the essay as nevertheless misleading and not helpful might be better. What exactly do you propose here? I'm tempted to add support, but I'm not sure what I'd support. –Be..anyone (talk) 16:51, 30 March 2015 (UTC)[reply]
It seems the problem isn't exactly what I thought it was, so I'm waiting on more input to see. I'm beginning to think you have the best solution for what seems to be the exact problem, that essay. Thanks for the comment. Jerodlycett (talk) 17:40, 30 March 2015 (UTC)[reply]
This particular schools a borderline case. We should;t use such cases to change established statements of practice, or we will have no stability at all, and no basis for consistent decisions. We can;t be expected to be perfectly consistent, but we should at least try. DGG ( talk ) 19:48, 30 March 2015 (UTC)[reply]
"A foolish consistency is the hobgoblin of little minds." We should strive not for consistency, but propriety. We do what is proper to the specific situation, not what has been done in other situations merely because of some random points of coincidence. --Jayron32 02:46, 2 April 2015 (UTC)[reply]

Proposal after comments

Thank you who left comments assisting in this. My proposal is now as follows.

I propose deletion, or rewrite to indicate use only for assistance when no consensus is found, of WP:OUTCOMES.

It is being quoted as the reason to keep a subject that isn't notable on its own. While I gave one example above of it being used that way, and the results from it, you can see the discussion at WikiProject Christianity which shows it is considered a guideline, not an essay. Jerodlycett (talk) 03:55, 2 April 2015 (UTC)[reply]

  • Comment: I think the page itself, in its lead and first section, already does that well enough. Also, I think what you’re desiring is for precedent itself to be considered irrelevant in such cases, rather than this page that attempts to document it. As for WT:XNB, I see only that it’s considered a relevant page in the context of that discussion. —174.141.182.82 (talk) 02:32, 4 April 2015 (UTC)[reply]
  • Support, this wannabe-essay trying to overrule guidelines not in the form of a WP:AFD subpage is harmful, intentionally misleading, and pointy. –Be..anyone (talk) 02:05, 5 April 2015 (UTC)[reply]
  • Support marking WP:OUTCOMES with {{historical}}. It is a fantastically unhelpful page that hamstrings proper discussions of articles on their own merit. We should be discussing each article individually, not pointing at OUTCOMES and saying "Nope, can't delete it... precedent says we can't" We don't normally delete such pages, but we should tag it as historical and that it should not be used for resolving deletion discussions. --Jayron32 02:11, 5 April 2015 (UTC)[reply]
  • Oppose I believe the example this proposal is based on is being misunderstood by the nominator. At a first level, schools are notable in the same way bridges and train stations are, as elements of infrastructure and public service - and we've included coverage of some very minor bridges and train stations. Motivation for this proposal seems to amount to WP:IDONTLIKE. Samsara 08:19, 5 April 2015 (UTC)[reply]

Discussion moved to Wikipedia:External links/Noticeboard. SD0001 (talk) 17:04, 31 March 2015 (UTC)[reply]

Proposal for new redirect tagging template {{R with history}}

Please comment on Wikipedia:Requested_templates#.7B.7BR_with_history.7D.7D. Thanks, SD0001 (talk) 19:14, 31 March 2015 (UTC)[reply]

History - UK & Europe Royal Family Tree Generator

Hi Wikipedia,

I have just published a new free Royal Family Tree generator website that produces on-screen family trees for the major royal families in Europe - handling those tricky issues about formatting descendants and ancestors in what I hope is an easily viewable and attractive way.

Wikipedia appears to use many manually created trees to show the same type of information, with no ability to interact or navigate around.

I was wondering if you would consider the possibility of linking to my site from appropriate Wikipedia pages? Of course I would reciprocate.

If this is of interest to you, I would certainly be open to improving and enhancing my site in line with any recommendations you might make. The website works on generic display logic, so there is no problem adding further royal families and family members, as required. It could be extended, for example, to include noble families, additional European countries, etc. I must emphasise that this site will remain free, with no plans to raise revenue from it.

The site is www.royaltrees.co.uk.

Best regards,

Tony White

tonywhi@gmail.com

I don't see the problem with what we have. They link to the other articles on the subjects and work in MediaWiki. By definition we try to be neutral. If we promoted your generator, we'd be biased as a whole towards your website. It's the same reason that we don't have ads; by definition they violate neutrality. Besides, I looked at your website and it wasn't quite clear; what do the checkmarks do next to each name? Origamiteⓣⓒ 13:02, 1 April 2015 (UTC)[reply]

I have tried to keep the screens uncluttered, with explanatory detail on the help screen. The checkboxes (in conjunction with the DEL button) allow the user to remove entries from the display and so taylor the tree as they wish. I haven't seen an equivalent facility in Wiki and thought it might be useful. I understand your principle about neutrality (although there is no commercial motive behind the site). I would just say that if it was thought to be a useful facility is there any feasible way or approach for it to become useable within Wiki? Regards, Tony White.

I know zero about the surrounding issues, but my guess is that this would be most useful to the project if it could be used as a tool whose end-product is an image that can be statically captured for use in articles. EEng (talk) 16:23, 2 April 2015 (UTC)[reply]

Static capture of a screen is technically very easy: right click on a display and View Page Source. What you see is a fully rendered HTML Page which can be copied and re-used. Some work would be needed to fit it within a page rather than being a page on its own. I have no objection in principle to Wikipedia using these pages as you wish. As I said above I am also open to modifying what I have in line with your needs - in terms of how data is displayed and in terms of adding more people to the database. Regards, Tony White Further point - the copied HTML page would allow the viewer to continue to interact with it as now. However, I could program a 'display only' option which would take you to a non-interactive page which could be copied as-is.

I suggest you make a post at Wikipedia talk:WikiProject Royalty and Nobility. EEng (talk) 19:46, 2 April 2015 (UTC)[reply]

RefToolbar: Show parsed preview by default?

I've had no response to this suggestion at Wikipedia_talk:RefToolbar#Show_parsed_preview_by_default.3F, so trying here - if this isn't the right place, please advise.

Originally posted at Wikipedia_talk:RefToolbar:

Every single time I click "Preview" I then need to click "Show parsed preview" to see what I really want to see, which is "What does this reference look like?". It's irritating. I'm sure I'm not alone. I prefer to check my refs before hitting "Insert", especially as when I'm editing a section I don't see them when I hit "Show preview" for the whole edit, and the system makes me click on what seems an unnecessary link every time.
Could I suggest one of the following:
  • Show the parsed reference by default (what problems would this cause, if any?)
  • Have two separate buttons: "Preview" and "Preview code", where the first one shows the Parsed version as well as the code, and the second shows the current setup
  • Have a preference or similar whereby I can opt to see the Parsed version automatically
  • Have a preference or similar whereby anyone who doesn't want to see the Parsed version automatically can switch it off and remain with the current version, but the editors who want to see the Parsed version (possibly the vast majority?) are shown it by default.
Any thoughts? PamD 12:09, 5 January 2015 (UTC)[reply]
No replies, so no objections (well, not many people watching this page, I guess). Is there anyone technical out there who could implement this change (by any one of the four routes suggested above, or any other means to the same end)? PamD 09:21, 11 February 2015 (UTC)[reply]

Any thoughts here? PamD 23:10, 2 April 2015 (UTC)[reply]

Protected Page Editing Exceptions

If a page is fully protected, some administrators* may grant to an autoconfirmed user the right to edit the page. Administrators may revoke that right at any time. Typically, a user who has made one or more successful protected edit request would be granted editing rights, although administrators would have discretion.

  • This could either be the administrator responsible for protecting the page, or any administrator.

Dingsuntil (talk) 04:21, 5 April 2015 (UTC)[reply]

@Dingsuntil:, how do you propose the mechanics of this work? Would these users be getting this permission per-page, or are you proposing a process for granting (editprotected) access to individual users? — xaosflux Talk 15:52, 5 April 2015 (UTC)[reply]
per-page. Presumably, I could be able to be reasonable and NPOV-ish about one subject, but a different one makes me so angry that I compulsively vandalize it. Dingsuntil (talk) 21:17, 5 April 2015 (UTC)[reply]
  • I'm interested in this as well, as based on the discussions I've had with developers it is currently not possible to edit fully protected pages without the (protect) userright. I've done a lot of research and asking to try and figure out ways for Template editors to be able to edit PINKLOCK pages that happen to have cascading protection for whatever reason. — {{U|Technical 13}} (e • t • c) 15:59, 5 April 2015 (UTC)[reply]
    • Has this been test on tesiwiki or elsewhere? Is there a bug on this? (Something like "Protected pages are not editable by users with editprotected permissions unless they also have protect permissions") - Or have you only noticed it on cascade-protection? — xaosflux Talk 16:03, 5 April 2015 (UTC)[reply]

Read-only edit filter permissions

A proposal to create read-only access to private edit filters is taking place at Wikipedia_talk:Edit_filter#Edit_filter_helpers, input is welcome at that page. — xaosflux Talk 15:48, 5 April 2015 (UTC)[reply]

Synonyms Available in Wikipedia

[copied post removed] — Preceding unsigned comment added by Shanus444 (talk • contribs)

This was also posted to Wikipedia:Village pump (idea lab)#Synonyms Available in Wikipedia. Please only start a discussion in one place. PrimeHunter (talk) 10:23, 6 April 2015 (UTC)[reply]

Discouraging biting the newbies

Background

We are short of new editors, particularly women. If a new editor is "bitten" as soon as they start their first article, they may give up on Wikipedia in disgust. Often a newbie is uncertain that they are allowed to start an article, so their first save may be little more than a placeholder. Once they see that has worked, they start to flesh out the details. A "bite" may range from hastily tagging the article with a minor cleanup template such as {{tone}} to a speedy deletion nomination. Although technically the tag or nomination may be justified, it will be very disconcerting to a newbie who does not understand how Wikipedia works. A note on their talk page, with follow-up only if they ignore it, would be much more welcoming.

I first became very aware of the problem a few years ago when my wife started her first article, Calton weavers, which was rapidly nominated for speedy deletion as "a blatant and obvious hoax ... where the deception is so obvious as to constitute pure vandalism." She would have given up, but I encouraged her to try again, and it got into DYK. Still, the experience soured her on Wikipedia and she has not done much more. Recently she pointed out a speedy deletion request on Natalie Smith Henry that managed to get attention from the New York Times and BBC News, and a year later from Huffington Port. We do not need this sort of publicity, which may discourage potential new editors from even starting.

To confirm that these were not isolated incidents, I registered an alternative account (User:Bymatth2) and started four articles that were on my "to do" list, in each case saving a first version that I thought might be typical of a newbie's first tentative version of an article. They were Ralph Biasi, John Payne Jackson, Colonne Fabien and Jean Troisier (the last is very similar to Natalie Smith Henry). Each had some context and some indication of significance, but weak. A web search would have shown that each topic was backed up by many sources, but all were quickly nominated for deletion. There is no requirement for the nominator to undertake a search. The nominators did nothing wrong – but if User:Bymatth2 really had been a newbie, he would have been profoundly discouraged.

Wikipedia:Please do not bite the newcomers gives some general behavioral guidelines. Wikipedia:New pages patrol#Be nice to the newbies advises editors not to be too hasty. Wikipedia:Deletion policy#Alternatives to deletion explains some other options. Wikipedia:Criteria for speedy deletion offers some cautions. But none of these policies or guidelines defines persistently biting the newbies as Wikipedia:Disruptive editing: "a pattern of editing that may extend over a long time or many articles, and disrupts progress towards improving an article or building the encyclopedia."

Some of the editors who do a lot of new page patrolling maintain logs of the articles they have nominated for speedy deletion. Typically 5–10% of these articles show as blue links, meaning the CSD submission was declined, or the article was recreated and survived. A spot check shows that the author of the blue link article often does not do much more, as was the case with my wife, user:jomillsjo. Presumably some of the redlink articles could in fact have been expanded into valid articles, as with the four test User:Bymatth2 articles, but the newbies turned away in disgust. We are short of new editors, particularly women. Hasty CSD nomination may be causing great damage in turning away new editors, with questionable benefits.

Aymatth2 (talk) 15:57, 6 April 2015 (UTC)[reply]

Proposal

Various possibilities suggest themselves, such as imposing a delay between article creation and tagging (assuming the article is not an attack or otherwise immediately damaging to Wikipedia), using the newbie's talk page rather than clean-up templates to suggest improvements, and sanctioning editors who are consistently very aggressive to newbies. This is to propose that we first agree on a general statement of principle, to be added to Wikipedia:Disruptive editing and to Wikipedia:Please do not bite the newcomers, saying,

Actions that tend to discourage newcomers, such as hastily nominating new articles for deletion or tagging new articles with clean-up templates, may be considered disruptive editing if constantly repeated without first exploring alternatives on the article creators' talk pages.

Aymatth2 (talk) 15:57, 6 April 2015 (UTC)[reply]

Comments?

  • A better solution would be to nominate all of WP:UWT for deletion. The worst thing we do to bite newcomers is slap some arcane template on their talk page. No one reads form letters. If we want to keep them around, we should be talking with them, not yelling at them. --Jayron32 16:09, 6 April 2015 (UTC)[reply]
  • Just trying to get agreement on a first principle: persistent biting is disruptive. If that is accepted, we can discuss what other changes would naturally follow. Aymatth2 (talk) 16:22, 6 April 2015 (UTC)[reply]
  • I disagree about there being no requirement to check; see WP:BEFORE for steps that editors are expected to carry out before nominating an article for deletion. I feel that editors who consistently fail to carry out these steps, and/or who badly misinterpret the speedy deletion criteria, should be restricted from nominating articles for deletion, because while we can undo the frivolous nominations, we can't undo biting a new user. The second and third of your articles were badly tagged: A7 doesn't apply when an article makes a clear claim of significance, and the patroller clearly didn't understand what that means. The patroller's misjudgement was disruptive to the project, despite being in good faith, and if it is a pattern then we should not allow it to continue. Ivanvector (talk) 16:49, 6 April 2015 (UTC)[reply]
  • Read WP:POINT lately, and considered how it might apply to your actions here? Breaching experiments are frowned upon, no matter how noble the goal. WP:ILLEGIT would appear to apply to your use of the Bymatth2 account, as well. Any justification for the second account that would conform to policy?—Kww(talk) 16:53, 6 April 2015 (UTC)[reply]
I'll offer an WP:IAR on this one. This is an obvious good-faith effort to improve the encyclopedia, and added four decent articles in the process without really harming anything (that wasn't going to be harmed anyway). Ivanvector (talk) 17:12, 6 April 2015 (UTC)[reply]
Support that nothing was harmed and a good point was made. I think IAR applies.  SchreiberBike | ⌨  17:39, 6 April 2015 (UTC)[reply]
  • As stated in Wikipedia:Sock puppetry#Legitimate uses, "long-term users might create a new account to experience how the community functions for new users." That is why I did not use my main account. The main and alternative accounts are linked and categorized as such on their pages, have very similar names and have the same email, so there is no attempt to conceal the connection. The alternative account Bymatth2 did not contribute to any discussions. There was no Wikipedia:Sock puppetry. The alternative account did nothing disruptive and made no point. It just started four routine articles. If it had indeed been a newbie, it would have been an unusually productive newbie, stubbornly focused on adding new content. Aymatth2 (talk) 17:40, 6 April 2015 (UTC)[reply]
  • You intentionally created four articles that you knew did not comply with WP:V and one that did not comply with WP:BLP. You knew that the articles were unacceptable when you created them, and that they would consume other editors' time and effort in getting rid of them or cleaning them up. That's a WP:POINT violation.—Kww(talk) 18:23, 6 April 2015 (UTC)[reply]
  • Maybe we should be concerned not just with newbies getting bitten, but more experienced editors, too. Don't act as if new editors never violate verifiability and BLP policies when creating new articles, or that their articles never have to be cleaned up. What Aymatth2 did was useful and necessary if we're to improve the treatment of new editors and bring in more fresh blood; what you're doing is material support for keeping the newbies out. // coldacid (talk|contrib) 20:54, 6 April 2015 (UTC)[reply]
  • This is a good idea. It's very difficult to "unbite" a new user and they are a precious resource. I'm also sure it is difficult to deal with the rapid flow of bad new articles that sweep in every day. This idea swings in the right direction though. I have notified Wikipedia:New pages patrol to get their input.  SchreiberBike | ⌨  17:39, 6 April 2015 (UTC)[reply]
  • Yes newbie biting is a problem, and there are lots of incorrect tags done at speedy deletion. But I'm not sure we need a rerun of WP:NEWT to tell us that. My suggestions would include, more eyes at CAT:SPEEDY declining the minority of incorrect tags that come there. Dealing with some of the bitey stuff that we can all agree is worth resolving, such as tweaking the software so that adding a template or category doesn't cause an edit conflict to the newbie trying to add their second sentence. More controversially, those templates that we don't need to use to warn the reader should be replaced with hidden categories, uncategorised and dead end being prime examples; Yes we need to find them, but no we don't need to disfigure the article with them. Ideally I'd like to see us resolve the divide between those who consider we have moved from a policy of verifiable to one of verified, and those who don't; Either we need to change the software and instructions to tell all new page creators that every article needs at least one source and widen BLPprod to all new unsourced articles, or we reaffirm current policy and stop people reverting edits and deleting articles simply for being unsourced. Perhaps we can compromise by introducing BizProd for all new articles on commercial operations that don't have an independent neutral reliable cite. In my ideal world we'd replace most speedy deletion categories apart from the G ones with a system whereby only logged in editors could see new unpatrolled articles, and only people with the autopatroller right could create articles that were instantly published, but I'm not holding my breath on that one. We do insist on a delay before A1 and A3 tags are applied, but historically it has been difficult to get consensus to widen that to other tags - there is a limit to the number of patrollers we have and in order to screen out G10s we do need to look at articles as fast as they come in. ϢereSpielChequers 18:17, 6 April 2015 (UTC)[reply]
  • As always, I pretty much reject the concept that an unacceptable article is anything but an unacceptable article. I will support the concept that templating anyone is disruptive, and offer my old essay WP:Don't template anyone as my solution.—Kww(talk) 18:19, 6 April 2015 (UTC)[reply]
  • I would say all articles, and in fact all content, should be sourced. Newbies are unlikely to understand that, and will often start articles that are poor quality, particularly their first save. It they are welcomed and given guidance, they may become productive. If they are slapped in the face after their first save, they are likely to walk away. This proposal is simply to ask that we agree on the principle that persistent biting is disruptive. If that is accepted, we can move on to more specific remedies. This is just asking for the first baby step. Aymatth2 (talk) 18:37, 6 April 2015 (UTC)[reply]
  • I don't think that anyone would disagree that biting, let alone persistent biting, is disruptive. But in my experience we disagree as to what constitutes biting. Just look at WP:NEWT to see an argument as to whether those of us who did that were biting the newpage patrollers or whether we were demonstrating that new page patrol was biting newbies. I would consider that we are biting newbies by having a defacto standard of sourcing that is stricter than the system warns them of, others disagree. If we are to make progress we don't need to reaffirm that which we all already agree on, we need to hammer out some compromises so we can change things. ϢereSpielChequers 19:00, 6 April 2015 (UTC)[reply]
  • The idea is to get the broad principle that persistent biting is disruptive spelled out in the policy, without being too specific. If we can get that agreed, we can move forward to next steps: to clarify what is unambiguously considered biting, and how to apply sanctions against biters. A key issue is that the bitten newbie is very unlikely to complain, other than in the press or external blogs, and that an experienced editor is unlikely to be bitten and very unlikely to make the effort to build a case against a particular biter. I think there are ways to handle that, but first we need the basic principle to be defined. Aymatth2 (talk) 19:09, 6 April 2015 (UTC)[reply]
  • You have proposed an unacceptable solution as your first step, by proposing that unacceptable content be retained for some specified period of time.—Kww(talk) 19:49, 6 April 2015 (UTC)[reply]
  • Since we already have consensus that biting newbies is disruptive, changing that to "only persistent biting is disruptive" would not be a great move in my opinion. However I doubt that's your intention, and I'd reiterate that the difficult thing is to identify a way to make the site less bitey that has both consensus here and if necessary resource from the WMF. For example I doubt if anyone here would object to some of the bugs being implemented that would reduce the edit conflicts that bite newbies. But good luck in getting the WMF to focus on that. ϢereSpielChequers 20:23, 6 April 2015 (UTC)[reply]
  • (edit conflict) I agree that we shouldn't bite newbies, but we must be reasonable and strike a balance. We can't allow poor content to stick around just because we're afraid of biting new users. I'll tell a story from my own personal experience. When I edited wikiHow (I'm actually not active there any more, for rather complex reasons), I saw a very poor new article on "How to Use NutriBullet" come through RCP. I had vaguely heard of the product before, so I did a bit of research and improved the article. It's in rather good shape now. So, not too long after, when I started editing Wikipedia, I was trying to find an article to create. I decided to create an article on the product. From what I recall, the article was tagged for speedy deletion almost instantaneously. It was definitely frustrating that the patroller just slapped some tag on my talk page and didn't explain anything. The tag was declined, however, and the article was sent to AfD, where the discussion was relisted multiple times. It's very difficult having to endure such a drawn-out AfD. In a sense, I was almost relieved when it was finally deleted. It was a rather mixed experience. I was inevitably upset over the instantaneous CSD tag and what seemed to be an endless AfD discussion. On the other hand, I now understand why it was deleted, and it was a learning experience. After almost eight months, I'm still here with no plans to quit, and I feel that I've become a rather productive editor, although I've certainly made my fair share of blunders. ;)
However, this isn't the case with all newbies. Some just decide that Wikipedia must be a hostile place and quit immediately. So, I think we should find a way to control the inflow of poor content without biting too much. For example, we could promote personalized messages rather than templates (that takes much longer, though), or could try to make the templates more friendly, etc. --Biblioworm 20:03, 6 April 2015 (UTC)[reply]
    • CSDs and instantaneous accusations of sockpuppetry or meatpuppetry are probably the two biggest ways that newbies get bitten and decide that Wikipedia isn't for them. Without some heavy guns (figuratively speaking) I don't think there's much that can be done right now about the latter, but for the former we could probably at least change policy so that barring WP:BLP issues, a new article must be at least x hours old (say, 48-72) before they can be CSD-flagged. AfDs would be more difficult, but perhaps making it clearer that an article could be moved to userspace for reworking could relieve some of the pain around those, too. Steps like those would probably go a long way in keeping new editors around longer, until they're more comfortable with our Byzantine ways. // coldacid (talk|contrib) 20:48, 6 April 2015 (UTC)[reply]
  • Leaving spam and self-promotion sitting around on the servers for days is unlikely to be a good or widely accepted solution. It's also bitey in a different way to let a newbie create an article and walk away thinking they're finished, and then silently delete it days later. Opabinia regalis (talk) 21:28, 6 April 2015 (UTC)[reply]
  • I'd say at least 24 hours. I doubt any but the most dedicated editors actually stick around for 6 hour editing sprints, and we'd at least want to give the newbies a chance to respond to a CSD, PROD, or AfD for their shiny new articles. That, or on successful deletion, move the article to the editor's userspace instead of actually deleting it, with a comment about what happened on their talk. // coldacid (talk|contrib) 21:39, 6 April 2015 (UTC)[reply]
  • Does anyone have any data on what kinds of edits newbies who stick around are most likely to make? One way of refocusing the question of what constitutes biting is to identify where a bite is likely to do the most damage. I try to catch newbie-created articles in my areas of interest, clean them up, and then leave the creator a message explaining the changes - but I probably intend to do this three times as often as I actually get around to doing it. Opabinia regalis (talk) 21:28, 6 April 2015 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=655250718"