Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

New ideas and proposals are discussed here. Before submitting:

• Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
• Consider developing your proposal on Wikipedia:Village pump (idea lab).
• Proposed software changes should be filed at Phabricator (configuration changes should have gained a consensus).
• Proposed policy changes belong at Wikipedia:Village pump (policy).
• Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.
• Proposed new articles belong at Wikipedia:Requested articles.

« Archives, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Should Wikipedia use HTTPS by default for all readers?

Template: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. Tony Tan⁹⁸ · talk 20:33, 16 February 2015 (UTC)

References

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 Tan⁹⁸ · talk 19:47, 21 February 2015 (UTC)

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)

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)

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

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)

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)

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 Tan⁹⁸ · talk 03:09, 20 February 2015 (UTC)

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)

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 Tan⁹⁸ · talk 04:52, 20 February 2015 (UTC)

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)

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)

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)

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)

@Martijn Hoekstra:Yes, China used to block HTTPS connections to WP, but it doesn't do that any more. See here. Tony Tan⁹⁸ · talk 13:45, 17 February 2015 (UTC)

Well, that's something. How about the others, i.e. Iran, Burma, Emirates, others? Martijn Hoekstra (talk) 13:53, 17 February 2015 (UTC)

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 Tan⁹⁸ · talk 14:27, 17 February 2015 (UTC)

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)

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)

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)

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)

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 Tan⁹⁸ · talk 02:07, 18 February 2015 (UTC)

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)

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 Tan⁹⁸ · talk 03:15, 20 February 2015 (UTC)

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)

They are not the same. Please see my reply in our other conversation closer to the top in this section. Thanks. Tony Tan⁹⁸ · talk 04:52, 20 February 2015 (UTC)

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)

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 Tan⁹⁸ · talk 14:11, 20 February 2015 (UTC)

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)

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

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

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

  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)

  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)

  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)

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

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 Tan⁹⁸ · talk 16:14, 21 February 2015 (UTC)

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)

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

@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 Tan⁹⁸ · talk 19:34, 21 February 2015 (UTC)

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)

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

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)

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 Tan⁹⁸ · talk 00:05, 22 February 2015 (UTC)

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

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)

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)

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

@Stemoc: Are you able to use Google search through your slow internet connection? Tony Tan⁹⁸ · talk 03:14, 22 February 2015 (UTC)

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)

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 Tan⁹⁸ · talk 05:06, 22 February 2015 (UTC)

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)

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

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)

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

  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)

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

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)

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 Tan⁹⁸ · talk 17:45, 25 February 2015 (UTC)

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)

@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 Tan⁹⁸ · talk 01:49, 26 February 2015 (UTC)

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)

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)

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 Tan⁹⁸ · talk 08:20, 10 March 2015 (UTC)

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)

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)

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

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

  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)

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

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)

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)

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)

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)

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)

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. SiBr₄ (talk) 21:39, 23 February 2015 (UTC)

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)

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)

• 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)
  • I agree with the proposal to cover modules and MediaWiki pages at TfD and TimedText at FFD. But at the same time, I feel that WP:Project pages for discussion provides some unique benefits. It provides a much-needed forum to discuss improvements to multiple project pages at once, mergers etc. SD0001 (talk) 14:05, 25 February 2015 (UTC)

• I don't like this idea. It looks like something that would almost certainly increase administrative backlogs with little to no tangible benefit. Beeblebrox (talk) 17:58, 27 February 2015 (UTC)
  • Could you specify as to which parts of the proposal you oppose? SD0001 (talk) 18:57, 27 February 2015 (UTC)

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)

• 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)
  • @Kudpung and Beeblebrox: This appears to be a very common problem indeed, so I have written a new WP:Solutions looking for a problem essay. You might want to improve or expand it as you must have listened to many more of these solutions-looking-for-a-problem, and your experience far outstrips mine. BTW what do you think about the other proposal below? SD0001 (talk) 17:06, 7 March 2015 (UTC)

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)

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)

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

Templates

• New sub-header for Templates, as that discussion seems different than the main MfD discussion. – Philosopher ^{Let us reason together.} 23:53, 24 February 2015 (UTC)

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)

• I agree, per my above comment.  Cenarium (talk) 00:37, 25 February 2015 (UTC)
• Support, as per my comment made above. SD0001 (talk) 14:05, 25 February 2015 (UTC)
• 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)
  • 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)
    • 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)
      • 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)
        • 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)
          • 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)
          • 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)
• 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)

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)

1. Support per above. SD0001 (talk) 11:16, 1 March 2015 (UTC)
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. SiBr₄ (talk) 11:33, 1 March 2015 (UTC)
3. Support Modules are templates, just written in Lua rather than wikitext. Pathore (talk) 01:12, 3 March 2015 (UTC)
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)
5. Oppose Mediawiki: moving to TFD, no real preference on Module (they are rarely XFD'd). — xaosflux ^Talk 04:20, 8 March 2015 (UTC)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

Proposed permissions change: Edit Notices

Currently we restrict the ability to create or edit notices project-wide (except User/User_talk: space) via the MediaWiki:Titleblacklist to administrators and template editors. I propose loosening or removing this restriction. A technical discussion (Wikipedia:Village_pump_(technical)/Archive_135#Editnotice_permissions_by_namespace) reveals this can be accomplished without software changes.

A range of options is available including:

a) Removing the restriction entirely

b) Allowing edits but not creations

c) Removing the restriction by namespace (e.g. allowing for all namespaces except Article)

In all situations, standard protection could be deployed to protect any specific edit notice.

Proposed: — xaosflux ^Talk 21:53, 7 March 2015 (UTC)

Discussion (Edit notices)

Prior to any sort of !voting, would like to have an open discussion period, please contribute below. Thank you, — xaosflux ^Talk 21:53, 7 March 2015 (UTC)

I think the current situation is (b) that people can edit it once created. They do create another opportunity for vandals to be disruptive. Also they are not that useful, so I think the current situation is OK. Graeme Bartlett (talk) 22:01, 7 March 2015 (UTC)

• Note: Currently only template editors and admins can edit, due to the noedit argument included in the blacklist. — xaosflux ^Talk 23:39, 7 March 2015 (UTC)

• Remove the restriction – No reason to place a restriction on edit notices. If a restriction isn't absolutely needed, it should not remain. In events where disruption occurs, protection can be applied, as with all other Wikipedia pages. RGloucester — ☎ 22:04, 7 March 2015 (UTC)
• Keep current system Our purpose is to build the encyclopedia, not exercise free speech through creative use of edit notices. What problem is this proposal addressing? Is there an example of a problem to the encyclopedia from an inability to tweak edit notices except by discussion followed by an edit request? Johnuniq (talk) 01:22, 8 March 2015 (UTC)

What should be in question shouldn't be what is gained from removing protection but what is gained in invoking it. Ours is a free encyclopedia and our default state is "yes", not no, so please justify your !vote in those terms. ResMar 01:53, 8 March 2015 (UTC)

I would suggest that the right is reduced to auto-confirmed on request, one page at a time rather than in mass. If there is a very highly-visible page, it should remain template-protected, but most should eventually be opened up to auto-confirmed editors. However, no rush. Oiyarbepsy (talk) 03:32, 8 March 2015 (UTC)

• I would generally be OK with loosening the restrictions to autoconfirmed and higher. Any kind of vandalism on these notices would not affect our readers, just the editors. Edit notices don't seem to be a highly-visible target and we can always protect edit notices of high traffic pages or policy pages if needed. What's the volume of edit requests to these notices that would be reduced if the restrictions were lessened? Nakon 03:58, 8 March 2015 (UTC)
• We should treat edit notices the same way we treat talk page notices or article notices (both of which are way more visible): editing should be allowed by all users by default. If there's a specific reason to restrict editing of a particular page, that can be handled via the normal means (page protection, user blocks, AbuseFilter, etc.). --MZMcBride (talk) 05:25, 8 March 2015 (UTC)
• This would probably result in the unnecessary creation of too many unnecessary editnotices. But allowing autoconfirmed users would not be a bad idea, considering that my edit request for the editnotice of this page is still pending! SD0001 (talk) 07:18, 9 March 2015 (UTC)
  • It wasn't pending because there was no-one to look at it or carry it out, it was pending because it is an incomplete request. Was there a discussion and consensus? It seems like it is questionable to add the requested text, and there will need to be. — {{U|Technical 13}} (e • t • c) 13:19, 9 March 2015 (UTC)
    • This delves in to the realm of "Should we require discussion and consensus before ANY edit notice is created/edited" - in which case admins and template editors shouldn't be editing them either without the same process. — xaosflux ^Talk 14:27, 9 March 2015 (UTC)
      • I'm not sure ANY is the word I would use, I see no reason that user editnotices should require a discussion and consensus for example (not that they are protected or require it now, although I would like to see them protected in a similar way that user .css/.js is only it should be TE/full or the user's own (I think user .css/.jss should be TE/full as well, but that is a different discussion)). I think obvious and clear changes for typos or whatnot are also fine "please replace accept with except in the sentence 'Do not add new items to the list accept for cases where there is a clear consensus'". Requests like "Please keep the discussion constructive. Off-topic comments should generally be avoided. If it is really necessary to add off-topic comments, please use collapsible boxes." are all generic things that apply to all pages (except for the collapse sentence that would require consensus since it might cause an accessibility consern). This specific request was also for WP:Village pump (proposals), which is a high traffic page and any change should be discussed before being implemented. — {{U|Technical 13}} (e • t • c) 15:33, 9 March 2015 (UTC)
      • @Xaosflux : It should be, and in practice is, like usual mediawiki messages. Noncontroversial is good to go (otherwise nothing would get done), if unsure ask on talk page to see if there's any objection, and if likely controversial then seek consensus.  Cenarium (talk) 21:31, 9 March 2015 (UTC)
• If everybody and her dog including me can edit this spam we'll get more spam. Doesn't sound like a good idea for me, why do you think it's fine? –Be..anyone (talk) 10:00, 9 March 2015 (UTC)
  • Be..anyone: I don't understand your comment here. Can you please elaborate? How does what you're saying here not apply to the rest of Wikimedia? Any page is a potential (a)venue for spam. Nearly anyone can add a visible notice to a talk page or to an article. The edit screen is comparatively less visible, so I don't see why we would erect extra restrictions for it. --MZMcBride (talk) 20:23, 9 March 2015 (UTC)

    Most edit notices I saw were distractions, added by the owners of a page as some kind of private policy not related to real policies. E.g. edit notices on commons telling me that all system messages are documented on mediawikiwiki, which turned out to be untrue when I read it for a local system message. E.g. edit notices telling me to use some TemplateBox on commons instead of the template data manager, because that was in fact state of the art some months ago. So far tspan style="color:#00FF00;">Talkhe feature never failed to be a nuisance for me, limiting the write access to Brion might be a better plan. –Be..anyone (talk) 20:46, 9 March 2015 (UTC)

• Six years ago, I invented the use of the Mediawiki:Titleblacklist for protecting edit notices. At the time, I was in favor of semiprotecting them rather than applying full protection, basically in the spirit of allowing more editor freedom. However, most of the other people that participated back then believed that edit notices were too much a part of the interface to allow generic editors to touch them, so we ended up with full protection. Personally, I'm still in favor of relaxing restrictions on per-page edit notices. For those, at most only one page at a time could be vandalized, so it doesn't seem like a big deal to me. Dragons flight (talk) 19:07, 9 March 2015 (UTC)
• I would oppose any relaxation of restrictions in mainspace, since as I mentioned at VPT, some editnotices can be incredibly biting to newcomers and a major dissuasion to editing, totally uncalled for or violate assume good faith. This is by far the biggest danger, not vandalism. Vandals are spotted quickly, but this can go unnoticed since editnotices aren't as visible as page content, and cause much more harm in the long term. For this reason, I consider these editnotices high risk templates. As such, only users trusted to edit such templates, i.e. template editors and admins, should be able to edit these. As for editnotices in other namespaces, the same holds for many pages, probably dozens in Wikipedia namespace, those aimed for new editors mostly. I wouldn't object to a decrease in restriction to autoconfirmed for editing but only if these pages are identified and their editnotices placed on template protection. I would still oppose creation since we can't know in advance which page is going to be sensitive and template-protect their editnotices. However it should be noted that this may be a hassle to implement.  Cenarium (talk) 21:31, 9 March 2015 (UTC)
• Keep current system - effectively, edit notices are a part of the interface. While we did decide to relax it for the userspace (giving users the right to decide what their own edit notices look like), I see no advantage to relaxing it elsewhere - there are OWN issues (completely irrelevant for a user in his/her own space), issuess of potential for vandalism in these sensitive locations, etc. עוד מישהו Od Mishehu 10:20, 10 March 2015 (UTC)
• Allowing a large group of people to change the edit notices, even for some articles, would create a lot of problems with vandalism and edit warring. Experienced users are much better at deciding where edit notices should be and what they should say. PhantomTech (talk) 05:44, 11 March 2015 (UTC)
• I would prefer keeping the current system, though I do have a proposal to create (yet) another user group that has the technical ability to override the title blacklist for the purposes of creating and maintaining editnotices on my list of things eventually to do. --L235 (t / c / ping in reply) 19:50, 11 March 2015 (UTC)

I'd just allow it as a legitimate reason for getting TE status, bar security risk. There is such a thing as too much un-bundling and the cases where this would be necessary are even narrower. ResMar 04:50, 13 March 2015 (UTC)

@Resident Mario: I'd personally argue that the level of trust for template editors is (far) higher than the level of trust for simply creating and editing editnotices, because template-protected pages are usually quite high-risk with much disruption possible from a rouge template editor, so under the principle of least privilege people that just need to edit editnotices should not have the (unrelated) ability to edit highly technical templates. And this is coming from a template editor who was granted the right just for creating Arbitration-related editnotices- see my user rights log. Then again, maybe it's just me. I'll get around to proposing it at WP:VPR... eventually. --L235 (t / c / ping in reply) 22:38, 14 March 2015 (UTC)

 Lixxx235: I was the editor in question who inspired this particular proposal, hehe, because I needed to be able to create and maintain editnotices in the Signpost domain. The reason I say that it'd be too much is that there would be too few cases where it'd be necessary to justify the additional paperwork, IMO. We only have 99 template editors and it's been two years; we'd have maybe 6 editnotice editors. It's just not practical. ResMar 22:41, 14 March 2015 (UTC)

@Resident Mario: Ah right, my bad. :P Ignore my last comment then :) --L235 (t / c / ping in reply) 22:44, 14 March 2015 (UTC)

• I would support a proposal to remove the restriction all together. Page protection can be used as needed, and good faith editors would be freer to improve Wikipedia; subject to her consensus. I suspect angst will carry the day, however; as it too often does.--John Cline (talk) 11:27, 23 March 2015 (UTC)
• Per my test on testwiki:MediaWiki:Titleblacklist, I support adding "autoconfirmed" to the TBL listing so that anyone who is autoconfirmed can edit these while protecting them still from anon/new account vandals. I can't see any reason someone who is a new account or an anon would ever have for changing these outside of what an occasional request for an edit on their behalf (just like any other semi-protected page) wouldn't be able to handle. — {{U|Technical 13}} (e • t • c) 12:11, 23 March 2015 (UTC)

Paid Editors - Charging Facebook for using our content

My fellow editors, I have looked in the Perennial Proposals section and it seems to be historic now so I hope you will forgive me for raising it again. Also I have a variation in mind and a two part proposal. 1. I believe that there should be new category of Wikipedia editor, somewhere between a regular editor and an administrator, a Trusted Editor, and that these editors should receive some kind of meaningful financial recompense for their work, if they apply for it. As should Administrators. Some editors are financially comfortable and some are not. I am long-term unemployed, have mental health issues and will probably never have a regular job again. If I could make some money out my work here it would make a big difference to my life. I think I can fairly claim to have made a contribution to this shared project of ours as my user-page shows. Surely I cannot be the only poor Wiki editor and this would help others like me. Poverty kills thought, as has been pointed out. I don't think I am being unreasonable. There should be some kind of probationary period for this Trusted Editor status and it could be revoked if the Editor does wrong. 2. Linked to the above I believe that we should charge Facebook for using our content. Not much and I don't have a specific figure in mind but just a tiny amount for each time one of our articles is 'liked' on Facebook would generate a lot of revenue. I know that Wiki is 'not for profit' and I respect that, but Facebook has a revenue of $12billion while here on Wikipedia there are perpetual requests for donations. Surely that can't be right? That's not natural justice. If the funds generated by such a charge are redistributed to poor editors here that would not hurt our 'not for profit' status, would it? Jimmy Wales is worth $1million so life can't be so hard for him. I have had to go to a food-bank once in the past and may have to again. So what do other editors think? SmokeyTheCat 10:15, 11 March 2015 (UTC)

As to the second, all content on Wikipedia is released under a license which allows reuse by absolutely anyone, under specific conditions that don't include payment, so it would be illegal. As to the first, Wikipedia has enough trouble getting enough money as is, so I doubt that it would be doable. עוד מישהו Od Mishehu 09:15, 11 March 2015 (UTC)

So why can't we change that license? Do you not share my sense of injustice that Facebook, which so vastly wealthy, uses our content for free, while we rely on donations? SmokeyTheCat 10:08, 11 March 2015 (UTC)

We are not here to earn money, for that editors can go to Britannica or the like. We are here to make information available and freely accessible for everyone. Second the license can't be revoked, something that has been released under the current license stays under that. So we shouldn't and can't change the license. For the first idea, what yardstick should editors' contributions be compared with? Some create content; GAs, FA's, DYKs, FPs, etc. Others work behind the scenes and maintain SPIs, enforce arb sanctions, etc. Others do simple copy editing. Others like me patrol new pages and tag some for deletion. Secondly, there would be a mad rush for this "trusted" usergroup. So definitely no. --Fauzan^{✆ talk}_{✉ mail} 10:43, 11 March 2015 (UTC)

Oh well, I guess it's back to the Food Bank I go ... :-( SmokeyTheCat 16:47, 13 March 2015 (UTC)

Od Mishehu got it slightly wrong, it's not violating any license to charge for WP content. However, the license effectively lets them get it for free, so it's not likely Facebook would bother paying for it. Gigs (talk) 20:07, 20 March 2015 (UTC)

Days of Year and individuals to list on the pages

the Wikipedia:Days of the year has been "cleaning up" the days of year articles removing individuals who are not "internationally recognized". The problem with that is they have no clear criteria for determining what that means. It's not listed on their project page at any rate. It's also not clear to them. Here is an example:

• Editor 1 removed "entries for those who are not internationally known"
• Editor 2, supposedly using the same criteria, removes even more
• Editor 1 again removes even more using the same criteria

They clearly have no idea and are being capricious in he application of their supposed criteria, or worse-yet, making it up as they go along. I'm not saying the pages shouldn't be cleaned-up, but the criteria must be clear before starting, and the results of applying it should be similarly clear to any editor. WP:N is sufficiently clear for most other stand-alone lists, so I'm not sure why it would create recentism in this project. I'm also not sure how "three or five articles", a current proposal from project members, doesn't suffer from creating another problem. A category would be sufficient for most subjects (born on August 2 or died on August 2) or even allowing a bot to deal with the care and maintenance of such a list. I don't even mind their proposal to move all births and deaths from the date pages and onto stand-alone pages. However, their discussion as a project has been ongoing in their smaller circle, and I believe it has implications to many other projects and the English project as a whole, so I'm bringing it up here. Walter Görlitz (talk) 18:01, 13 March 2015 (UTC)

This does not seem to me to be an appropriate place for these comments. However, those who are interested can find the details of the actual discussion and constructive proposals for criteria here - Wikipedia_talk:Days_of_the_year#June_11_and_removal_of_entries_by_Deb.Deb (talk) 16:13, 15 March 2015 (UTC)

Of course. You're the one who has been opposing me at every turn. The actual discussion can take place here just fine. There have not been any constructive proposals there, only alternate ones. Walter Görlitz (talk) 04:07, 20 March 2015 (UTC)

Walter, I think you might want to look into Wikidata. Their entries should record the complete birth date for every person, and it is supposed to be fairly easy to search for "anyone born on August 2". Then you could put a link to that query in the August 2 article, and readers will have immediate, constantly updated access across all wikis, without needing to create enormous categories here. WhatamIdoing (talk) 19:36, 23 March 2015 (UTC)

How many readers of Wikipedia are going to go directly to Wikidata? Similarly, a category page would do the same. We're not discussing category pages but articles. Walter Görlitz (talk) 14:23, 24 March 2015 (UTC)

Hybrid editor

The visual editor has received mixed reception, for familiarity and functionality reasons. However, I think many of the issues could be solved if you could run the visual editor side by side with the traditional source code editor. Adding a word in the source would show up immediately on visual editor, and changes with the visual editor would modify the source mid-edit. This has several benefits:

• Helps explain the functions of the code visually for those who are unfamiliar with it.
• Makes checking the "show preview" button unnecessary for everyone; the changes are apparent immediately.
• Provides an easy learning curve for new editors: they can gradually do more work in the source code as they get more familiar with it.
• Helps smooth out new feature adoption for experienced editors: putting visual editor in wider use makes it easier for veterans to see/learn new features.

This wouldn't require any totally new features. The aim would be to simply integrate the two editing modes that are already in place. As far as I know, this has not been proposed: "hybrid editor" brings up only one comment on bringing source editor features into visual, rather than running them in parallel. Forbes72 (talk) 04:15, 16 March 2015 (UTC)

I know that Wikia has an editor like this - as VE has been developed with them, maybe it is possible, I guess server load may be an issue. Even if just hosted on Toollabs, this would be good. I often use VE, and if I am doing anything major, I do switch to source code and check out what it's done. Mdann52 (talk) 12:18, 16 March 2015 (UTC)

Support I believe this is a great proposal, especially for new editors. They get to learn better in the hybrid editor, in my opinion. What would complement this is if the changes are highlighted, as in the differences shown when you cick on "diff" in the history section of each article. Sam.gov (talk) 12:57, 16 March 2015 (UTC)

Support An interesting idea. I like it. Do that. --Jayron32 13:01, 16 March 2015 (UTC)

Support as opt out gadget. Also, an integrated live diff engine would be good too. --Fauzan^{✆ talk}_{✉ mail} 12:40, 18 March 2015 (UTC)

Support I've never seen this done in a browser as opposed to a program so I'm not sure how it would deal with long pages, but something can be figured out I would be a great tool. If implemented, it shouldn't be the default editor for all users since, according to a discussion on forcing https, there are a lot of Wikipedia users who use older technology to browse and edit Wikipedia. If https will cause them problems then having to work with an editor constantly generating previews will be a nightmare, however everyone should have easy access to it by default so that new editors don't have problems finding it. PhantomTech (talk) 15:41, 18 March 2015 (UTC)

Support; this would allow us to get the best of both editors. Wikitext editor is currently best for most stuff, while VisualEditor is good for adding columns to tables (which is extremely tedious in wikitext). This would allow users to add columns with VisualEditor, while actually populating the cells with the wikitext editor, without having to make a bunch of edits. StringTheory11 (t • c) 21:50, 19 March 2015 (UTC)

VisualEditor in 2011

I can ask the product manager about this. However, as a point of fact, this was done in the original version, and it was basically declared to be a disaster. WhatamIdoing (talk) 19:39, 23 March 2015 (UTC)

Proposal:Move protect ITN articles

Recently, the Villa Castelli helicopter crash article appeared on ITN. During its time there, it was moved twice. I have no issue with the moves, or the editors moving them, as both moves were made in good faith and were not problematic as such, although the did mean that the link from {{ITN}} was a redirect, not a direct link.

It is rare that an article will need to be moved with any great urgency whilst it appears on ITN. Therefore I propose that all main (i.e. bolded) articles listed on ITN be move-protected at Admin level for the duration that they appear on ITN. In practice, a one week protection should cover most appearances. If there is a pressing need to move an article, WP:RM will be available. This proposal could be extended to cover all articles linked from ITN, but I'm not sure that there is a real need, as most of the other links will be to relatively stable, established articles.

Discuss. Mjroots (talk) 20:49, 16 March 2015 (UTC)

What problem would this solve? ―Mandruss ☎ 21:00, 16 March 2015 (UTC)

@Mandruss: having a link to a redirect from the main page. Mjroots (talk) 21:13, 16 March 2015 (UTC)

Why is that a problem? Beeblebrox (talk) 23:22, 16 March 2015 (UTC)

AFAIK, it is an accepted convention that links to redirects are avoided from the MP. Mjroots (talk) 18:49, 17 March 2015 (UTC)

Is it? Can you point to where this convention is written down somewhere? TFAs are specifically move-protected, but that may be for different reasons. I was unaware that every link on the main page (especially those articles still being developed or in states of flux) were immune from being moved to a more proper name. Can you point me to where your read this? --Jayron32 05:23, 18 March 2015 (UTC)

No, you got it wrong. It is perfectly acceptable to link to redirects from articles. See WP:NOTBROKEN, as well as the various usages of {{This is a redirect}}. SD0001 (talk) 17:37, 25 March 2015 (UTC)

TFAs are already move-protected for the period from their selection through the date they appear on the Main Page as the TFA. I wouldn't see a problem with extending this convention elsewhere regarding Main Page content. Imzadi 1979 → 04:09, 18 March 2015 (UTC)

Oppose. Linking to a redirect is OK. A direct link looks slightly better and the main page is high profile so we generally make direct links when the content is written but if a page is moved later then it's no big deal to have a redirect until the link is updated. ITN items often don't have an established name yet, and new developments may necessitate a move. Let's not add bureaucracy to that. I'm not aware of a widespread problem with bad moves of ITN items. PrimeHunter (talk) 00:43, 19 March 2015 (UTC)

Fix problem with references on talk pages

Tracked in Phabricator
Task T70324

I would like to propose that someone should fix the long-standing design flaw whereby references are automatically expanded at the bottom of talk pages. Initially these references would appear to an editor be correctly positioned, but as the talk page subsequently develops, they inevitably end up appearing to be attached to a totally unrelated later thread, far away from the place where they are relevant. References on talk pages should be expanded only as a result of a deliberate editor directive placed at the appropriate point on the page. In this way they will remain in the correct place. 31.51.134.71 (talk) 22:07, 17 March 2015 (UTC)

This template {{reflist-talk}} remedies that problem. When placed within the thread containing the references, the references are positioned only at the bottom of that particular thread rather than the bottom of the talk page.--JayJasper (talk) 22:57, 17 March 2015 (UTC)

T70324 --  Gadget850 ^talk 23:10, 17 March 2015 (UTC)

It doesn't remedy the problem. The references should be expanded ONLY if {{reflist-talk}} is present. Adding this should be the responsibility of editors who want the references to appear. The burden of discovering {{reflist-talk}} and inserting it in the appropriate place should not fall on uninvolved editors who later contribute to a talk page, only to find spurious references appearing next to their comments. 31.51.134.71; 00:47, 18 March 2015 (UTC)

I agree this is an annoying phenomenon. However, it wouldn't be if people would just use links on talk pages and not format them as refs. Why anyone adds the extra code to make something into a ref when they know they are on a talk page is something I will never understand. Beeblebrox (talk) 18:30, 18 March 2015 (UTC)

The devil's advocate in me says "why should someone have change formatting solely to make talkpage look nice for material copied from (or destined to be copied to) articles while discussing the article content, which is the only reason we have article talkpages at all?" DMacks (talk) 18:41, 18 March 2015 (UTC)

If the poster is presenting information that they would like somebody else to insert into a locked article, then including references is preferred behavior. If the reference is conveniently formatted in the correct manner, then that is even better. Hence, I don't think we should be deterring people from posting citations just because it is a talk page. Praemonitus (talk) 18:43, 18 March 2015 (UTC)

The goal of the interface feature is that refs should be findable, which is critical on article pages. But I agree confusing on talkpages if you're using the current last section on the page that gets refs from previous sections. But it *still* means those footnote marks (in the previous sections) work correctly, which is pretty important IMO. Maybe the interface should put the automatic reflist at the end of the major section (h2 level) rather than at the end of the page for talk namespaces. That also prevents possible archive-bot confusion that could result from a template being placed after the last actual item in a talkpage section (it would have no datestamp at the end). DMacks (talk) 18:51, 18 March 2015 (UTC)

Re:my earlier comment: I meant that the template {{reflist-talk}} "remedies" the problem from a technical standpoint, when it is utilized. I agree with the OP that adding it should be the responsibility of the editors who actually insert the references to begin with. I like DMacks' suggestion that the interface should place the automatic reflist at the end of the section, rather than the bottom of the talk page. If such a thing is doable, I would heartily support it.--JayJasper (talk) 22:02, 18 March 2015 (UTC)

From what I have seen, a lot of this occurs when an editor copies a chunk of text from the article onto the talk page for discussion and it includes refs. Before the introduction of the AGRL, we had namespace detection and did not show an error on talk pages. --  Gadget850 ^talk 22:27, 18 March 2015 (UTC)

FYI, Wikimedia is working on a potential replacement for our current talk page system, WP:FLOW. In Flow, references appear and the bottom of the particular post. Here is what it looks like. Oiyarbepsy (talk) 14:52, 25 March 2015 (UTC)

revision numbers

When someone uses the undo link, the automatic summary confusingly uses an unexplained, mysterious revision number instead of the time stamp of the reverted edit. This often makes it very hard or impossible to find the reverted edit in the history. I suggest the following changes:

• the revision numbers should be displayed next to each edit
• the automatic undo summaries should at least also display the time stamp or only that
• the automatic summary should include a link showing the difference between the versions

--Espoo (talk) 08:35, 19 March 2015 (UTC)

I don't knoiw if this is possible - just FYI, we're talking about MediaWiki:Undo-summary, where $1 is the revision number and $2 is the name of the user. עוד מישהו Od Mishehu 14:06, 19 March 2015 (UTC)

A "difference between the versions" is just a diff of current vs previous-to-current, and that's already there. I don't support revealing the revision number in the normal history display (too technical and rarely useful). But it would be easy to write a gadget or bit of userland .js to do so, since it's just parsing/adjusting the display of data that is already present. DMacks (talk) 14:16, 19 March 2015 (UTC)

Espoo also posted to Help talk:Page history#missing info on revision numbers. I moved that discussion to MediaWiki talk:Undo-summary#Missing info on revision numbers before seeing it was also posted here. I suggested a link to the old diff in the automatic summary. Please only post the same in one place, or link other posts to a chosen page for the whole discussion. PrimeHunter (talk) 14:21, 19 March 2015 (UTC)

Perhaps we might change "$1" to "[[Special:Diff/$1|$1]]", and thereby include a link to the relevant version? It's a minimal difference, but it might be helpful… {{Nihiltres|talk|edits}} 16:56, 19 March 2015 (UTC)

I was about to propose exactly that change until I read your comment. If character count is a concern, could we make single-character redirects to the relevant pages? Or will that not work without software changes? If software changes are required, I propose making S:D and S:C aliases for Special:Diff and Special:Contributions, respectively. Pathore (talk) 20:20, 19 March 2015 (UTC)

If you're familiar with diff IDs, the revision number isn't mysterious at all, and it's quite useful because you can go directly to the revision by changing the URL or using Special:Diff. If we follow Nihiltres' suggestion and add a link to Special:Diff, confused people should be able to understand a lot better. Nyttend (talk) 18:10, 25 March 2015 (UTC)

Bring back recognition to mobile WP version!

Before in the mobile edition of Wikipedia, it showed at the top the hours or days since last revision and the user name. Now the username is not there. Bring it back and even consider it for the full desktop version. That is how we encourage people to update this site and not think some editorial board does it. — Preceding unsigned comment added by Newbie 93 (talk • contribs) 02:15, 22 March 2015 (UTC)

must have been a glitch because it now is the way it used to be. — Preceding unsigned comment added by Newbie 93 (talk • contribs) 03:31, 22 March 2015 (UTC)

I still really dislike the inclusion of the last editor to revise the article. It doesn't in any way encourage people to edit the site -- in fact it looks more like the opposite, implying that a particular editor WP:OWNs the article. It may even encourage pointless editing just to get someone's name splashed across the top of an article (by the same sorts of people that clog up so many comments sections on other websites with "first post!" and the like). --Ahecht (TALK
PAGE) 14:09, 23 March 2015 (UTC)

I'm confused by your comment. You're saying that "it doesn't in any way encourage people to edit the site", but it may "encourage pointless editing". Which is it? Kaldari (talk) 20:50, 23 March 2015 (UTC)

It would be great to see any data about this, or at least some example edits. I haven't seen any edit (in dewiki), which was made just to push the name to the article, but maybe i just don't see them :) --Florianschmidtwelzow (talk) 19:15, 24 March 2015 (UTC)

@Newbie 93: In beta and experimental mode of the website, this line is now undergoing a test in which it is placed at the bottom of the page instead of the top of the page. Perhaps that is why you think it is gone ? —TheDJ (talk • contribs) 19:17, 23 March 2015 (UTC)

Permanent Semi Protect/pending changes protect

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)

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)

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)

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

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)

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)

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

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

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)

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

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

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

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)

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

• 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)
• 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)
• 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. –Davey2010^Talk 03:31, 26 March 2015 (UTC)
• 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)

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)

• 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)
• 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. Kharkiv07^Talk 03:27, 27 March 2015 (UTC)
• 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)
• 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)

See also Wikipedia:Perennial proposals#Prohibit anonymous users from editing. Ivanvector (talk) 19:16, 27 March 2015 (UTC)

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

Deceased Wikipedian

{{Deceased Wikipedian}}, by default, displays a generic chunk of text: "Their userpage...their memory". However, if you link the username, the template will detect the user's gender (if it's been specified) and reword accordingly; see it in use in a test on my userpage. Using "His" and "Her" seems to be a bit more respectful, and a bit more personal, than a generic message, if it's possible. What if we redid the template so that it automatically detected gender unless told otherwise? For example, if we did this and then placed {{deceased Wikipedian}} on my userpage, it would look just like what my userpage does now with {{deceased Wikipedian|Nyttend}}. By "told otherwise", I mean that we could set it so that it only does this when neither the |note nor the |message parameters are used, since obviously we wouldn't want to override a customised message. We could have it ignore the |page parameter, since that simply changes "user page" to something else.

I've made this proposal here, rather than at the template's talk page, because I expect to get broader input here than there. Note that I've advertised it at the talk page, however. Nyttend (talk) 18:18, 25 March 2015 (UTC)

• Nyttend, you might want to fix your link on that talk page to come to this page instead of a non-existent section on WP:VPP. — {{U|Technical 13}} (e • t • c) 20:25, 25 March 2015 (UTC)
• Egads,why are you trying on your userpage? It does not look good. Anyway. yes, I totally agree with you. Using parameter might be an option. Was not there a way/template to know a user's gender (from their preference)? --Tito Dutta (talk) 03:07, 26 March 2015 (UTC)
• We can use templates like {{his or her}}, or hard-code it using {{GENDER:{{{1|{{PAGENAME}}}}}|male text|female text|unspecified text}} to do it. And yes, we should definitely make the template so that. עוד מישהו Od Mishehu 17:36, 26 March 2015 (UTC)

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)

A tool to import a category or list into another language

I think a tool to import a list or category into another language is needed just as much as a tool to sync lists & categories (see the upper section).

It could be used when creating a new category or list (e.g. in German) that already exists in another language (e.g. English) or for extending an existing one.

The tool would scan through the category/list equivalent of another language (eventually also multiple languages) and check if an article in the own language-space exists.

If so it wouldn't add those articles automatically but present the results to the user so one can decide which entries are actually appropriate.

--Fixuture (talk) 21:44, 26 March 2015 (UTC)

A tool to scan for links to questionable journals

Anyone know a way to automate scanning for links to the journals listed at: http://scholarlyoa.com/publishers/

©Geni (talk) 01:04, 27 March 2015 (UTC)

• You can do a search: insource:/Abhinav/
• Or use Special:LinkSearch: [4]

-- Gadget850 ^talk 02:00, 27 March 2015 (UTC)

Note that the author of the list, Jeffrey Beall, goes by the username Denverjeffrey, although he's not been particularly active lately. Nyttend (talk) 12:20, 27 March 2015 (UTC)

Proposal for title parenthesis to be used as reduced sized subtitles

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

In all these cases I was wondering whether, at the top of pages whether these titles might be displayed in a way such as:

Leeds North West (UK Parliament constituency)

M-185 (Michigan highway)

Energy (physics)

or:

Leeds North West, UK Parliament constituency

M-185, Michigan highway

Energy, physics

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. At present we present:

Leeds North West (UK Parliament constituency)

M-185 (Michigan highway)

Energy (physics)

GregKaye 11:31, 28 March 2015 (UTC)