Wikipedia:Village pump (proposals)/Archive 108

WebCite is used in 48000+ articles and on ~7000 project pages. They have announced that they may stop accepting new submissions next year, which may possibly lead to them closing down for good. I'm not sure what should be done, so I'm putting up a few ideas for discussion.

• Inform Wikipedians. Especially those like me who use WebCite routinely when citing the web might be interested.
• Helping with the fundraiser
  • Put up a banner on the pages.
  • Ask the WMF, they might be willing to share.
• A project/bot converting WebCite's to archive.org cites.
• Maybe our own archiving project?
• Do nothing and complain about it later.

Regards, Paradoctor (talk) 18:28, 23 November 2013 (UTC)

Well, a discussion about this very issue has been plodding along on meta since at least February. Chris857 (talk) 23:03, 23 November 2013 (UTC)

Thanks. Paradoctor (talk) 00:33, 24 November 2013 (UTC)

archive.org is inferior to webcite; two things I've noticed is that archive.org makes all captures unavailable as soon as the robots.txt says to, and it doesn't cope well with cookies. Josh Parris 23:16, 24 November 2013 (UTC)

I don't cope well WITHOUT cookies. Sorry, couldn't pass up the opportunity for that joke.Camelbinky (talk) 21:26, 27 November 2013 (UTC)

It would be a great mistake to let WebCite die. It is obviously useful for rankings, scoreboards, climate stats and other data that are regularly updated at the same URL. It is also valuable for sourcing controversial claims about living people and litigious companies, particularly where the subject of the article controls the source and may have a vested interest in changing or removing it. Arguably it should be invoked by a bot for all {{cite web}} and web-based {{cite news}} references, so that the correct version of the source is captured automatically. - Pointillist (talk) 12:17, 3 December 2013 (UTC)

Indeed it would. And what alternatives do we have? Potentially blacklisted sites like archive.is? Sigh. Wbm1058 (talk) 16:31, 5 December 2013 (UTC)

As we are all aware, there is a problem with the current

1. People are scared of rejection and don't apply.
2. People apply to soon(
   WP:NOTNOW
   ), get rejected and this puts them off applying again.

One way I feel this could be combated is by creating a pre-RfA page. Editors could almost run a 'mock RfA' where users can give them feedback without consequence. If an editor were to 'pass', they could then run for a real RfA and if they 'failed' they would know what to improve on before running for adminship.

While many hold a failed RfA in the past against a future RfA, this pre-RfA would not have the same affect as it is simply users looking for feedback. Also, if a user could pass this, it may remove the stigma of a self nomination as users can show that they already have support from other editors.

Of course, not all editors would want to do this and it should not be a pre-requisite for RfA. The traditional root would still be available but this would serve to help encourage editors who may not otherwise think of entering an RfA. Oddbodz - (Talk) (Contribs) 14:09, 24 November 2013 (UTC)

• See
  WP:ER. Editors there asking for review who are contemplating RfA. I don't think we need a dedicated specialist area for pre-RfA purposes. If want-to-be candidates have not read the mass of available material on RfA, compared themselves to recent successful and unsuccessful candidates via the main RfA page or obtained some feedback from other editors one-to-one then one must question their suitability. Not keen on dress rehearsals. Leaky Caldron
  14:39, 24 November 2013 (UTC)

I have noticed

WP:ER. Perhaps we could try publicising that more because many requests are there for over a month without getting a response. Oddbodz - (Talk) (Contribs

) 15:03, 24 November 2013 (UTC)

Yeah,

WP:AfC is another, IIRC), it's horribly backlogged and almost useless now. I don't see a specialized pre-RfA page to be useful, it would get even less visitors. Ansh666

23:08, 24 November 2013 (UTC)

• Support we need to be willing to try new solutions for RfA's problems. As far as I know, you can start up WikiProjects without consensus approval and I might be willing to help with this project if it is implemented, at least to get it off the ground. As for ER, I don't think it is effective enough to be useful here (Speaking from personal experience, I once opened an Editor Review for myself and it was open for almost a month before I got any feedback).
  AutomaticStrikeout (₵) – Rest in Peace, Jackson Peebles
  15:53, 25 November 2013 (UTC)

AutomaticStrikeout, thats an idea - I hadn't thought about the possibility of a WikiProject. I've create a draft page at User:Oddbodz/WikiProject Admin Recruitment and I'll see where that goes. If you'd like to help in its development, that would be great. I'd like to see what the rest of the community think of this though. Oddbodz - (Talk) (Contribs

) 22:59, 25 November 2013 (UTC)

I have thought about a Wikiproject, and proposed one here. I was surprised how little interest it received, but still think there is no hope for meaningful reform without such an organized approach.--S Philbrick(Talk) 17:06, 27 November 2013 (UTC)

In my opinion, the scope of your proposed Wikiproject is far too narrow. However, you already have one member, and I got none, so maybe I'm wrong.--S Philbrick(Talk) 17:10, 27 November 2013 (UTC)

Regardless of whether or not there's a need, I learnt that it's generally advisable to create a formal proposal if contemplating a new WikiProject. -- Trevj (talk) 15:23, 28 November 2013 (UTC)

• I think
  WP:ER serves the purpose adequately already, but it needs more exposure. Kudpung กุดผึ้ง (talk
  ) 01:29, 28 November 2013 (UTC)
• Comment In the UK, the Government some years ago wanted the quality of teaching to be assessed. So they introduced the SATS tests to see how well the teachers were doing. What happened? Most teachers proceeded to teach the kids to 'pass' the tests, and the parents put pressure on to get the kids through the tests. The kids got stressed. The teachers got stressed. Still do, but I think they're going to get rid of it. And no valid information came out of the exercise. A pre-RfA 'test', to my mind, would suffer similar problems. Unlike a car test (MOT), RfA is not a question of certain yes or now tick boxes. A pre-MOT inspection can get you avoiding a fail. A pre-RfA will soon be regarded as a preliminary test to be passed rather than being a source of information. At the RfA itself, people will say, yeh, they passed that, we'll !vote for them. Or not bother to come, because they passed already, didn't they? Peridon (talk) 14:53, 29 November 2013 (UTC)

I concur entirely with Peridon. While new admins of the right calibre are deperately needed, we want to avoid editors setting adminship as their main goal for participation in Wikipedia. We have more than enough advice pages for prospective admins and they are linked to from as many pages as possible, and if they can't be bothered to read them, they shouldn't be surprised if they fail. Kudpung กุดผึ้ง (talk) 01:55, 5 December 2013 (UTC)

• Who enjoys public rejection? Editor review is just another forum for potential public rejection. I'd think that email or chat, while perhaps not entirely secure and private, are still better ways to put out inquiries to determine whether a potential candidacy would be viable. Wbm1058 (talk) 16:08, 5 December 2013 (UTC)

In the article Sinc function, I saw an obvious mistake in the introduction that has persisted for many years without anyone noticing or fixing it. It said the definition of the Sinc function was ${\displaystyle \mathrm {sinc} (x)={\frac {\sin(x)}{x}}\,\!}$ but that can't possibly be true for x = 0 because you can't divide by 0. For anybody who wants to train themself to be a better Wikipedia editor, there should be an online Wikipedia test that takes articles and adds in mistakes to already existing articles and displays those articles with the mistakes in them to the person doing the test and the task of the person doing the test is to see if they can find those mistakes on their own without being told what they were. Those mistakes shouldn't change how the article looks for everyone, just for the person doing the test during the test. Administrators should take already existing articles and try hard to think of what types of mistakes to add in that are as indistinguishable as possible from natural mistakes because they know exactly what mistakes they're testing other people's ability to find on their own and purposefully adding in mistakes and notifying people at the end of the test which mistakes they missed noticing trains them to be better at finding mistakes in Wikipedia articles. The same article should not add in the same mistake for everybody who happens to be given that article in the test.

I suppose the test could also include testing the ability to find natural mistakes in an old version of an article that no longer has that mistake, especially the ones that are the toughest to notice. To make it more of a challenge, some of the Wikipedia articles in the test should have no mistakes that the person taking the test is tested to find without being told that that article has none because it's harder to find mistakes in an article that has mistakes when you don't know for sure that it has any mistakes. Another type of mistake that people should sometimes be tested on finding is one where a physics or mathematical formula is missing a 2 in the formula. Blackbombchu (talk) 00:35, 2 December 2013 (UTC)

Well, to your specific point, the article mentions that "In both cases, the value of the function at the removable singularity at zero is understood to be the limit value 1.", because for sin(x)/x, as x approaches 0, the expression approaches 1, as can be seen at L'Hôpital's rule#Examples. So, I don't see the issue there. *No comment on the rest* Chris857 (talk) 02:36, 2 December 2013 (UTC)

Editors wanting to work on their error detecting abilities can just examine real articles and try to find the errors which are usually there. Looking for deliberately added errors in copies of articles sounds like a poor use of time when it isn't part of some exam prospective editors are required to pass (I would oppose such a requirement). PrimeHunter (talk) 03:17, 2 December 2013 (UTC)

Is it your expectation that if such a series of tests were created, editors would have to pass them in order to get permission to edit? If so, that flies in the face of some fundamental principles.--S Philbrick(Talk) 14:07, 2 December 2013 (UTC)

No, it was just meant for those who wanted to make themselves really good editors. Reducing the number of people who can edit probably will make Wikipedia articles not get better as fast. On the other hand, it might be a good idea to follow my earlier proposal titled Pending changes where a change doesn't get made in the first place until the pending change is approved. The reason for that is that that way, people fell free to make as huge a change to an article as they want risk free. One such change might be rearranging the information all over the entire article to express the information in a clearer way and if that person is a really good English writer, that pending change will probably get accepted. The only possible advantage I can see to requiring people to pass those test in order to edit is so that really huge edits that rearrange an entire article can be done but I was more thinking of them being optional tests for people who choose to make themselves really good editors. Blackbombchu (talk) 14:52, 2 December 2013 (UTC)

Maybe the test should be able to ba taken by anybody and people should be required to pass it to have the power to approve or reject pending changes. Blackbombchu (talk) 14:57, 2 December 2013 (UTC)

Didn't you propose something like this already? There is never going to be some kind of external test required to edit Wikipedia. —  HELLKNOWZ  ▎TALK 15:08, 2 December 2013 (UTC)

There is no editor who is competent to edit articles on every subject in Wikipedia, so even if such a test could be made, no one could pass it. Also, even creating a limited test would be extremely complex and error prone, because there are many creative ways to fix even a simple error in an article —Anne Delong (talk) 15:33, 2 December 2013 (UTC)

Maybe there could be separate types of tests for each subject or specific area of a subject. Each person who wants to become a really good editor could make a guess which subject they would be best at pick a test that tests their ability to notice mistakes in that subject. For instance, a math expert might pick a test that tests noticing math mistakes such as stating that all twin primes are of the form (6n - 1, 6n + 1) when (3, 5) is not of that form and an English expert might take a test that tests their ability to rearrange the information in an article to express it in a clearer way or the failure of an article to give the definition of a not very well known term that the article is refering to. Blackbombchu (talk) 16:23, 2 December 2013 (UTC)

It sounds like a good idea in some ways, but... Have a look at the History page and the diff for my edit at

Dendrocnide photinophylla. I'm not a qualified botanist or a resident of Australia. I've never even seen one of these trees. But I am fairly expert in the English language. So should I be barred from editing this article through lack of qualification in the subject of the article? I found mistakes in both the English and German versions of a publication about tropical reptiles - while proof reading it. I knew nothing about the reptiles, and don't regard my knowledge German as anything brilliant, but the authors accepted all my proposed changes. Not everyone is a specialist. But we can remove junk, and correct the wording. And, may I ask, who is to write and administer these tests? How do we know that the people setting the tests really know all about the subjects? A lot of us are anonymous for personal or professional reasons. Peridon (talk

) 18:18, 2 December 2013 (UTC)

I never even once wrote in this proposal that anybody should be banned from editing certain articles. You're mixed up with me making a breif suggestion about all articles waiting pending approval to get changed. That doesn't mean certian people are forbidden to edit certian articles. It means they're free to guess what edits might be good and make them even if they're very unsure because they know that their edit will wait for pending approval and not risk harming the article. What I really suggested was that anybody at all could edit any article they want and the sole purpose of the test was for one who by free choice chooses to make oneself a much better editor. The only thing I even made the slightest suggestion about people having to past the test to do was having the power to accept or reject pending changes, not editing an article. Blackbombchu (talk) 01:44, 3 December 2013 (UTC)

This is a good example of a suggestion which would be better in the Idea Lab. I think of the Idea Lab as a place to brainstorm ideas, with the goal of developing a fully formed proposal, which might then come to the proposal page. I think there's value in doing some of what you suggest, but by repeatedly calling it a "test", you leave the impression that there are some consequences if you don't pass the test. I can see value in create a suite of pages with errors, and using actual examples, prior to being corrected, has some value. However, it isn't clear to me how they should be used, or where they should exists, so those are some of the details that can be worked out in the idea space. Presenting it as a proposal means that readers are likely to reject, rather than suggest modifications.--S Philbrick(Talk) 14:06, 3 December 2013 (UTC)

I was thinking of not passing the test being treated like never having taken it in the first place where people can keep doing the test as many times as they want. Your ides is good too. I fell like having a test that only tests noticing already exising mistakes before they get corrected is better than having no test. Such a test could just as easily result in somebody finding a mistake other then the one they were tested on finding that no one ever noticed before mistaking it for the mistake they were tested on finding. The new discovery of mistake from doing a test would also have a huge advantage of future tests done by other people then randomly happened to get that article being tested on finding that same mistake that was not tested before. New mistakes discovered by doing a test should not be removed from the article right away. Keeping those mistake a short time for testing will probably eliminate more mistakes in other articles later than the number of mistakes that would have been removed by removing them right away because it will train people really well on noticing mistakes. Finding a mistake in a test should not remove it from the article instantly because some people judge a certain change in an article to make the article better when it actually makes it worse. Blackbombchu (talk) 01:31, 5 December 2013 (UTC)

It's just occurred to me that the Toolbox has a link to the user's log whenever we're on any userspace/usertalkspace page, but the same is not true for any other namespace. Why not? What if we would add [https://en.wikipedia.org/w/index.php?title=Special:Log&page={{FULLPAGENAME}}] to the toolbox for every page, in between "Related changes" and "Upload file"? I'm not sure if local admins can implement this change; if we get consensus for it, I understand that a bug request might need to be submitted.

The toolbox "Logs" link on userspace pages is for logs of the user and not for the viewed page, so there is no concept of "the same" for other namespaces. History pages have a "View logs for this page" link. That's the same for userspace and other namespaces. I think page logs are a little technical to place in the toolbox for everybody including unregistrerd users, when they are only one click further away on the history page. But it would be possible for local admins to do it. Individual users can also do it for themselves with code like below in Special:MyPage/common.js. The gadget "Add page and user options to drop-down menus on the toolbar" at Special:Preferences#mw-prefsection-gadgets adds log links and many other things to a tab. PrimeHunter (talk) 02:40, 6 December 2013 (UTC)

mw.util.addPortletLink(
  'p-tb',
   mw.util.wikiGetlink('Special:Log')+'?page='+wgPageName,
  'Page logs',
  't-logs',
  'View logs for this page',
  null,
  '#t-info'
);

I have seen editors cite this essay almost as if it is a guideline or policy when it comes to deletion discussions such as Wikipedia:Articles for deletion/List of Mobile Suit Gundam Unicorn mobile weapons. My issue is that where do we stand on the whole Fictional elements of a work of fiction? Is there a way to draw a line on what is acceptable and what is not? A list of fictional weapons I can see as being off but Characters in Romeo and Juliet or character lists I can see being okay. - Knowledgekid87 (talk) 18:45, 8 December 2013 (UTC)

I could see a list of fictional weapons if delineated by a franchise or story arc. Dlohcierekim 18:49, 8 December 2013 (UTC)

Well do you think there could be a guideline put into place to draw some sort of a line? - Knowledgekid87 (talk) 18:52, 8 December 2013 (UTC)

Character lists are generally always okay as the work of fiction revolves about them, but when it comes to any other fictional element, we should be guided on how secondary sources approach the work, even if they dont' necessary break down every element. This, for example, allows one to argue the include of Mythology of Lost because those elements of the story have been the subject of some discussion, even if not all of them. If the only people that talk about the elements are fan sites or the primary work, it is probably not appropriate for WP. --MASEM (t) 18:58, 8 December 2013 (UTC)

What if, instead of watching an entire page for changes, you could watch only a certain section of this page, so that you would only be notified when someone edited that section, rather than if someone edited anything on the page? I think this would be very useful on pages like this one, where you often don't care about responses to any of the threads except for a few. If there is a technical problem that would make it hopelessly impractical to do this, then forget it (this isn't my area of expertise here), but otherwise I can't see any reason why this is a bad idea. I could be wrong though, I certainly have been wrong here before.

Wikipedia:Perennial proposals#Watchlist changes says: "While many users support the use of such a feature, the technical implementation of this feature is difficult, if not impossible with the current version of MediaWiki." PrimeHunter (talk) 03:06, 10 December 2013 (UTC)

This is, pretty much exactly, one of the major benefits of

Flow.--Jorm (WMF) (talk

) 03:20, 10 December 2013 (UTC)

• Except that
  Flow wouldn't work on these noticeboards which aren't in talk space. Is that correct Jorm? Technical 13 (talk
  ) 03:32, 10 December 2013 (UTC)

No; Flow will be able to be enabled on any page. Eventually. Not in the initial roll-outs.--Jorm (WMF) (talk) 03:43, 10 December 2013 (UTC)

Surely not in article space? I don't see how that makes sense at all. --Trovatore (talk) 03:55, 10 December 2013 (UTC)

Right, he probably meant talk spaces + project space I assume. Legoktm (talk) 04:08, 10 December 2013 (UTC)

Flow will be able to be enabled on ANY page, regardless of namespace. Eventually. Talk/not talk; doesn't matter.--Jorm (WMF) (talk) 04:22, 10 December 2013 (UTC)

You guys understand that namespaces are artificial constructs, right? The software doesn't care. At all. We can say "don't allow it to be enabled in mainspace". Or we can allow that. It's all configurable.--Jorm (WMF) (talk) 04:24, 10 December 2013 (UTC)

Oh, from a software point of view, I imagine that makes sense. I just don't think there's any plausible use model for Flow in article space. Unless I've completely misunderstood what Flow is. --Trovatore (talk) 04:29, 10 December 2013 (UTC)

I agree: on the Wikipedia projects, I can't see much use for it in the main namespace, no. I'm not willing to concede that for other projects or namespaces, however. --Jorm (WMF) (talk) 05:30, 10 December 2013 (UTC)

(edit conflict) I think the plan is to eventually enable Flow across the board on all talk pages, but manually on any other individual pages that are used for discussion -- such as the village pumps, everything in {{noticeboard links}}, and any other page used for discussion. It probably won't happen to any article-space non-talk pages, unless one of those happens to get used for discussion for some reason. I don't know that there's any real need for a namespace restriction. I doubt enabling will be performable by any old user. equazcion → 04:26, 10 Dec 2013 (UTC)

Hello. I recently stumbled into an ambush (continued here, here) over at

Regardless of how one feels about who was "right" in this dispute (and, to be crystal clear, I'm not here to prolong that debate), the bitterness and the resulting damage would likely have been avoided if we had a guideline on tagging: when tagging is appropriate, when it's not, how to do it, when to remove tags, and how to resolve disputes. The only essay I'm familiar with on this subject is

I am sympathetic to the problem. I've worked with many newbie editors, and many of them make a reasonable, but incorrect assumption about tags. They create their first article, then see a couple tags identifying problems. They attempt to address the problems, then sit back to await the removal of the tags, confident that whomever placed them will be monitoring the article, and will remove them as soon as the issue is addressed. That often does not happen, so they reach out to the Help desk or the Teahouse or other venues to ask why their fixes were deemed inadequate.

We permit drive-by tagging (and I'm not inclined to support a prohibition) but that leaves an awkward situation, as the newbies assumption is plausible. I've occasionally mused about how to address this, but had not come up with anything.

I had not seen the essay

Wikipedia:TAGGING

before, and think it is a good start for a potential guideline. And specifically, it has some suggestions on addressing the problem I just described. While I am not inclined to prohibit driveby tagging, I would consider supporting a requirement that a tagger add a comment to the talk page. If nothing else, remember that many newbies do not yet know how to look at the article history, so do not know how to identify who added the tag by insisting that the editor who adds a tag add a comment to the talk page, the newbie can at least see who to contact. In an ideal situation, the talk page note might say, "This article is missing references for claim A in paragraph 2, claim B in paragraph 3, and claim C in paragraph 5. If those claims are referenced, anyone can remove the Needs More references tag". Another good situation would be "This article seems biased because of the inclusion of item A and no mention of item B. If you made an edit to address this, let me know and I'll reconsider whether the tag is still needed."

The fact than anyone can remove a tag if they address the problem is not something that newbies know. Even those of us that know it, might not know exactly what the tagger was concerned about, so an explanation will help if a tthird party is trying to determine whether to remove the tag. --S Philbrick(Talk) 22:36, 4 December 2013 (UTC)

Thanks for the response. There seem to be many different assumptions and expectations about tags, and I wasn't aware of the one you mention. In the tagging dispute at Edward Snowden the tension seemed centered around (i) whether the tagging editor needs to do independent research to verify his/her concern before tagging, and (ii) whether the tagging editor is expected to fix the problem him/herself after tagging. --Dr. Fleischman (talk) 00:00, 5 December 2013 (UTC)

I agree with everything I read in WP:TAGGING, which I've never seen before right now. However, we already have too many rules here; instruction creep (and its enforcement, particularly) is not good for attracting newbies and keeping oldies. Instead of changing the status of WP:TAGGING or any other essay, let's do the following. (1) When we see someone "violate" WP:TAGGING, leave a note at the user's talk page saying something like "Hi, I'm not sure what you meant by [edit]. Would you please go to the article's talk page and explain your reasoning? [[WP:TAGGING|Explaining your tags]] helps others understand the tag a lot better". This isn't bitey for newbies. (2) Treat it as disruptive and begin seeking sanctions against people who wilfully don't explain their edits. However, this should be used in extreme situations, when a page is really and truly being hurt by someone who's been reminded many times that tag explanations are needed, yet refuses to provide them; a good sign of this is if unexplained and non-obvious tags are removed, yet the tagger edit-wars to restore them.

talk

) 01:45, 6 December 2013 (UTC)

I made a suggestion ages ago to add a link on each maintenance template for "how to resolve this issue" with a link to a help page (not a policy page) and one for "how to remove this notice" that links to a help page. --  Gadget850 ^talk 23:52, 9 December 2013 (UTC)

Not a bad thought. Can you dig up that discussion? What was the outcome? --Dr. Fleischman (talk) 18:52, 10 December 2013 (UTC)

Hi, reading this article [4] which mentions a few things i would like to propose a few possible improvements, The first mention is to shift funds from the chapters to volunteers, i think this discussion is now finished with the recent discussion about paid editing on Wikipedia is a no go. i think we learned a lesson from the paid editing Google KNOL[5] project as well, so the question arises, how is this with paid projects on Wikipedia and does wikipedia need paid for projects ?? In early stages life was simple, we had 5 devs who did mainly MediaWiki implemetations on request and now we have 175 people who do projects not only for Wikipedia but also for sister projects, let me first state that i think that we all agree that after the split with Wikipedia to protect us from claims the WMF had remarkable success with its Charity fundraising drive, as for the split from Wikipedia with the chapters so PR could be handled more professional we see the chapters developing other paid for projects from which some are very success full, remarkable is a license change in Dutch musea for art works to be reused freely and projects for our sister project Commons [6]] to get more photo's and no doubt there are more of such Chapter projects, very nice projects, but not Wikipedia projects, now after so many years in progress and testing the new model, the second mention in the article mentions that the influence of volunteers on the chapters is not working as desired, in the founding of the chapters a clear split with roles between the volunteer Wikipedias and the chapters was intended, however it turned out that a trias was formed on Meta blurring the lines between paid for contributions and unpaid volunteer work.

Proposal

To max this split on the short term i propose that every member with a paid income from a chapter ads similar to (WMF) a (WMFC) at the end of the login name, and second reclaim the META channels to Wikipedia volunteer only, as a channel to combine all Wikipedia related issues only, all sister projects, WMF and Chapters are moved to a new channel METAWMF, in this way hopefully unpaid volunteers stay in this project as their morale is more supported as we are all unpaid on this project, instead of paid project guiders and unpaid volunteers. In short its not an attack on any project, but an attempt to create clear lines from which each project can decide at its own merits based on their contributor base instead of a mixed interest playing field.Mion (talk) 21:33, 10 December 2013 (UTC)

I don't understand..quite a bit of the above, although I'd note that the register is mostly staffed by trolls. In any case, there's an unspoken convention that paid chapter staff who need to edit wikipedia have the appropriate chapter abbreviation as a username postfix already (see User:Lydia Pintscher (WMDE) as an example). Ironholds (talk) 22:11, 10 December 2013 (UTC)

thank you for clarifying the first part of the proposal, i didn't know such unspoken convention for naming already existed, but maybe we should make that a "rule" on every Wikipedia as many might not be aware of it.

Reformed proposal

Reclaim the META channels to Wikipedia volunteer only, as a channel to combine all Wikipedia related issues only, all sister projects, WMF and Chapters are moved to a new channel METAWMF, in this way hopefully unpaid volunteers stay in this project as their morale is more supported as we are all unpaid on this project, instead of paid project guiders and unpaid volunteers. In short its not an attack on any project, but an attempt to create clear lines from which each project can decide at its own merits based on their contributor base instead of a mixed interest playing field.Mion (talk) 22:19, 10 December 2013 (UTC)

Could you explain what you mean by "META channels"? If you mean the Wikipedia referred to by the essay

talk

) 22:27, 10 December 2013 (UTC)

yes, [[7]] is exactly what i mean, all Worlwide Wikipedia's should be combined with their own META channel for Wikipedia projects only, it turns out that if its mixed with other projects we get to much influence from paid for (by WMF or WMFC contributors as compared to volunteer input. Mion (talk) 22:38, 10 December 2013 (UTC)

MediaWiki*. Legoktm (talk) 22:39, 10 December 2013 (UTC)

I don't think you really understood what that article, Sue's comments, and the paid editing proposals are about... because they're really not related at all. The paid editing issue stemmed from the

Wiki-PR editing of Wikipedia incident and is mainly about corporations and PR firms editing Wikipedia, not Wikimedia chapters. Sue's comments and the Register article were about how best to spend WMF money. The issues are really not connected at all. Sister projects and chapters are not the same thing. Sister projects are things like Wiktionary and Wikibooks, which, like Wikipedia, are volunteer-run. Chapters are organizations like Wikimedia Deutschland and Wikimedia NYC. They do things like outreach activities with libraries and museums. There is little clear division between chapters and volunteers, as most chapter members are not paid employees (many chapters even have a fee to become a member), but are just regular volunteer editors from the various projects. Mr.Z-man

23:09, 10 December 2013 (UTC)

The core of the story was that the chapters turn out to run projects not from the Wikipedia, and in so the population of these chapters are only minimal represented by unpaid volunteers from Wikipedia also because they raise entry fees and such. This mixed project population decides that paid members should do active coaching of volunteers on Wikipedia and such without any Wikipedia project wide consulting of these volunteers, and yes, i named that coaching a "paid for project"Mion (talk) 23:26, 10 December 2013 (UTC)

The question arises, why dont you pay all small projects in Wikipedia ? and not like now only a few ?Mion (talk) 23:28, 10 December 2013 (UTC)

The core of the "story" is a gross distortion of what Sue actually wrote. I'm not sure what you mean "chapters turn out to run projects not from the Wikipedia" - That's kind of the purpose of chapters. Chapters are not supposed to just be clubs for local editors. They do outreach activities to try to get potential new editors interested in editing or to start collaborations with local educational institutions. Again, most of the people involved in chapters are volunteers. I'm not aware of any project that is paying people to "coach" users. Even the Register article doesn't mention that. Perhaps instead of vague references to things you assume we know, you could provide some specifics as to what they're doing that you think is problematic? Mr.Z-man 03:16, 11 December 2013 (UTC)

• I am finding the language in this proposal hard to parse. The use of the word "channel" is confusing, the only WMF "channels" I am aware of are on IRC, but this does not seem to be in reference to that. And I am unclear as to who it is being proposed be paid. I would also note that chapter staff that I have spoken to have indicated that they are not permitted to edit Wikipedia while on the clock as that is not what they are being paid for. I think this proposal needs to be completely re-written if it is to have any chance of success, currently it does not make much sense.
  talk
  ) 01:53, 11 December 2013 (UTC)

I agree. I read the whole proposal, but I don't understand it.--S Philbrick(Talk) 13:54, 11 December 2013 (UTC)

See

WP:TOPRED. It is updated every week, although it's had some problems in the last month or so. VanIsaac_{WS Vex}^contribs

21:12, 16 December 2013 (UTC)

If

Wikipedia:Most missed articles can redirect to it. - Pointillist (talk

) 22:06, 16 December 2013 (UTC)

I've created a bot (

This sounds problematic. Which stub tag will you add? Just the uninformative {{stub}}? Have you talked with Wikipedia:WikiProject Stub sorting? How do you plan to distinguish stub articles and mainspace pages which cannot be called articles? PrimeHunter (talk) 19:13, 7 December 2013 (UTC)

To quote WP:STUB, There is no set size at which an article stops being a stub. Where does the 1500 character mark come from? I'm not sure stubness is something that can be determined by a bot (or at the very least, not just based on size). Writ Keeper ⚇♔ 19:33, 7 December 2013 (UTC)

@PrimeHunter: I'm not sure. Maybe someone at WikiProject Stub Sorting knows.

@

Scream about the things I've broken

) 19:45, 7 December 2013 (UTC)

Are you saying that your bot filters out all wiki/html/css formatting before checking it against that 1500 character DYK, which I'm not comfortable accepting overrides

WP:STUB, threshold? Technical 13 (talk

) 21:47, 7 December 2013 (UTC)

WP:DYKSG#D7 and D11 for more information. BlueMoonset (talk

) 00:40, 17 December 2013 (UTC)

I tend to agree with PrimeHunter, I'm not sure this is something that can be reliably automated. I'm sure you could come up with some detailed set of criteria to get things that would be an actual stub 99.9% of the time, but you're going to miss a lot, and trying to figure out which stub template to use besides {{stub}} is going to be very difficult. A human will still have to add other categories, add any maintenance templates, and use a more specific stub tag, so I don't really see what value this adds. Mr.Z-man 21:36, 7 December 2013 (UTC)

Yes, it would be almost impossible to reliably sort stubs with a bot. I thought that might be a problem. I also see that

Scream about the things I've broken

) 22:14, 7 December 2013 (UTC)

Where do you get your 1 in 10000 false positive rate? —  HELLKNOWZ  ▎TALK 22:46, 7 December 2013 (UTC)

Random estimate. I have never seen an article that was referenced but had none of the things I mentioned. --

Scream about the things I've broken

) 22:47, 7 December 2013 (UTC)

Then please go to Actual malice, where you will see an article that contains inline citations but does not properly collect those citations in a separate section, and Reversible error, which contains such a section, but it uses <references /> rather than the reflist template, and ==Notes== rather than ==References== for the section heading.

In the other direction, see Brief (law), which contains one of your elements but is actually unreferenced. Due to the Article Creation Wizard, your script would miss a lot of unreferenced articles.

Finding these articles did not take me very long. WhatamIdoing (talk) 20:06, 9 December 2013 (UTC)

@

Scream about the things I've broken

) 20:25, 9 December 2013 (UTC)

By "external links", I had assumed that you meant ==External links== section, since it was in a list of other section headings.

The Article Creation Wizard is not only for AFC. The wizard can be used to create articles directly in the main namespace. WhatamIdoing (talk) 20:36, 9 December 2013 (UTC)

@

biting the newbies. GoingBatty (talk

) 00:12, 8 December 2013 (UTC)

@

Scream about the things I've broken

) 00:32, 8 December 2013 (UTC)

Every time I come to Wikipedia and am not signed in, I get some sort of popup asking for money. There is nothing more irritating or user-unfriendly on a web site. I would much rather see advertising or decreased services than popup solicitations. I propose an absolute ban on popups. Apollo (talk) 14:02, 10 December 2013 (UTC)

I think if you gave the WMF a large enough donation so they never had to ask for money again, you could solve that problem.--Jayron32 14:42, 10 December 2013 (UTC)

There is an optout in , I think, preferences. Mayhap when I win the Mega-super-duper-set-for-life lottery, I will remedy the need fro pop ups. Better than the adds that beset some other projects. Dlohcierekim 15:51, 10 December 2013 (UTC)

If you hit the big "X", it'll go away. Legoktm (talk) 19:04, 10 December 2013 (UTC)

part of the problem i have is that it overlaps some of the other features. it does get annoying at times.Lucia Black (talk) 19:07, 10 December 2013 (UTC)

Solution = Preferences --> Gadgets --> [checkbox] "Suppress display of the fundraiser banner". Dlohcierekim 19:21, 10 December 2013 (UTC)

That optout doesn't work when you are not logged in, as IPs don't get preferences. LeadSongDog come howl! 20:43, 10 December 2013 (UTC)

Hi Apollo, how often is this happening (once a day? once a week?)? Different computers? Different browsers? I don't know what the current state of fundraising is, but earlier in the year, it was supposed to be only like one in a thousand logged-out users, and never more than once in the same computer/browser. If you're getting it a lot more often than that, then let me know, and I'll figure out who the right person is to talk to. Whatamidoing (WMF) (talk) 19:43, 10 December 2013 (UTC)

Also, are we talking about a true popup, or is it just a banner? LeadSongDog come howl! 20:43, 10 December 2013 (UTC)

Yep, I've never seen a true popup on the site. Those I might have a problem with. Banners are a dead horse. --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 04:39, 12 December 2013 (UTC)

December is the annual donation drive. IPs should be able to click the "X" which will set a cookie, to prevent further display (so if you clear your cookies, you'll see it again). See m:Fundraising 2013 for details, and reports bugs at m:Talk:Fundraising 2013. –Quiddity (talk) 21:16, 10 December 2013 (UTC)

Note that m:Fundraising 2013#Campaign Launch Update December 2, 2013 states "Banners will run to 100% of English readers in the US, UK, Canada, Australia, and New Zealand". GoingBatty (talk) 01:43, 12 December 2013 (UTC)

Or just keep yourself logged in. --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 04:39, 12 December 2013 (UTC)

• The banner requires javascript. If you don't have javascript, you won't see the banner. Like Quiddity says above, if you clear your cookies you will see the banner multiple times. @Whatamidoing (WMF): I haven't taken a look recently, but I recall the fundraising team was experimenting with the 1 out of X users idea to see how well it worked as opposed to the December fundraising drive. Unfortunately it requires cookies, so those that clear cookies will see the benner multiple times. While on other computers, I see the banner after 2 to 7 clicks. For example, I go to a page on Wikipedia, I click a link to another article and see the banner. The most clicks I could do before seeing a banner was about 7 and the least was 2. I never saw a banner on the initial click. Because I'd click to multiple articles, I always see the banner. So in that sense it's a 1 to 1 ratio. IMHO, readers that clear cookies (or have them disabled) will skew the results the Fundraising Team will see. You might want to mention that to them. Thanks. 64.40.54.101 (talk) 06:20, 13 December 2013 (UTC)

  Yes, this is a known problem. If you disable cookies, then you're not supposed to get it at all. But if you accept cookies and then clear them (e.g., when you close your browser), then you look like a "new" person. (Does anyone else wish that Firefox had a "clear cookies after X days" setting, rather than "now or never"? I don't mind cookies hanging out for a week or a month—I really wish WMF cookies [and therefore login session length!] lasted longer than 30 days—but I'm irritated by the twenty-year expiration dates.) Whatamidoing (WMF) (talk) 18:06, 13 December 2013 (UTC)

• When using Wikipedia only to view (on machines other than my personal one and therefore not logged in), I've seen just how excruciatingly awful the banner is. Not only does it clash with Vector's (extra web 2.0) feel, but it also annoyingly changes to a mini-banner and maintains location on the top left of the screen as you scroll past the obnoxious one at the top (if you don't close it). Really, fundraising team? Killiondude (talk) 22:52, 16 December 2013 (UTC)

I was wondering why we're using the Alexa ranking to describe websites, when there are several much more accurate and reliable services out there than can supply that data. — Preceding unsigned comment added by Noamsp (talk • contribs)

Such as... - Ypnypn (talk) 16:24, 11 December 2013 (UTC)

I was hoping for some examples. Dlohcierekim 14:16, 13 December 2013 (UTC)

Our article on

Nielsen NetRatings. If there actually are "several much more accurate and reliable services" they should be listed in that article. A web search on "alternatives to Alexa" brings up several candidates. --Guy Macon (talk

) 17:14, 13 December 2013 (UTC)

This is the only edit by Noamsp who didn't sign so I don't know how serious this is. I guess it refers to the alexa parameter in {{Infobox website}}. If you have an actual proposal then you can post it to Template talk:Infobox website. The alexa parameter has been discussed before. PrimeHunter (talk) 18:30, 13 December 2013 (UTC)

I think the basic question is, is the Alexia ranking really all that important? In the early days of the web, many website's would bragged about their Alexia ranking. But now, it is almost never mentioned. So what really is the point of providing the Alexia ranking in an article about a website? It doesn't tell the general reader anything about the website, but is a meaningless number to the general reader. 24.149.119.20 (talk) 23:17, 15 December 2013 (UTC)

A global ranking like Alexa or SimilarWeb produce is relevant for understanding the relevance of high profile sites (Facebook, Google, Wikipedia, Yahoo etc.) but not as much if you're looking into smaller sites, like most of the sites in the list. But, showing the actual traffic number is more interesting and indicative IMHO. For example, both services will indicate that Wikipedia's global ranking is 7, but SimilarWeb can also estimate the actual number of visitors (in Wikipedia's case, 2.4B)

Its pretty simple but I think we can benefit from it. Since the options are merged when we're looking at the history page or in our watchlist, why do we keep them separate when we edit? I think this'll save ppl a lot of time when they are precatious but want to finish it as fast as possible.Lucia Black (talk) 05:30, 16 December 2013 (UTC)

I would object to merging them, as it would move the preview down the page, but I would support having the show changes button act like the compare histories function and show both the changed code as well as a preview of the page/section. VanIsaac_{WS Vex}^contribs 05:52, 16 December 2013 (UTC)

The opposing isn't as strong as the support. I personally don't mind. Sometimes the change is needed to be seen before the preview. Perhaps collapsibility for change option in both proposed merger and those that are already merged such as the preview link in history pages, and the diff link in our watchlist.Lucia Black (talk) 05:56, 16 December 2013 (UTC)

I don't want this. It's difficult to manage large articles this way, especially if you make changes in several places.

However, I thought that there was, once upon a time, a (rather unpopular) prefs setting or script that provided this option for people who wanted it. I can't find it now. WhatamIdoing (talk) 20:09, 16 December 2013 (UTC)

• I oppose this also. Nine times out of ten, all I want is preview, and I don't want the diffs on the screen. The one time I want to show changes, what I'm most interested in is the changes, usually because I've substituted a word or something technical, and then I don't want the preview. They're two separate tools, and I don't see what's to be gained by merging them for the general population. —C.Fred (talk) 20:15, 16 December 2013 (UTC)

I agree with WhatamIdoing. Doing a diff+preview for a lot of changes for a large article can be a lot of stuff to scroll through. Note that there is a "Do not show page content below diffs" preference option which makes it so diff links on watchlist/history will only show the diff, not the page. The reason there are 2 buttons is because they do 2 different things and you don't always need to use both. Mr.Z-man 20:24, 16 December 2013 (UTC)

Would you all support it if the diff was collapsible for both proposed editing space and diff/prev space? What's to be gained is if someone made largescale changes and needs to see both preview and difference, it would be needed. For someone who constantly makes typos or such. Or if someone made a mistake in citations. The diff sometimes doesn't show the flaws right away. But I'll compromise. We should have the option to see both at the same time.Lucia Black (talk) 21:08, 16 December 2013 (UTC)

No. It still has to generate the diff and send the data for it, which takes time. Or if I only want the diff, it still has to generate the preview. You still seem to be suggesting that everyone be forced to use a system that's more efficient for only a few people, and slower for everyone else. If someone wants to make a script to do this, that would be fine. But the only way I would support this in the software would be if there was a user preference for it, disabled by default. Mr.Z-man 21:42, 16 December 2013 (UTC)

• Speed has never really stopped a proposal in the past. Are you saying that it'll make the page go significantly slower? I'm suggesting we should offer options anyways. Let's not make this into it catering you. So you will only support if it was a preference disabled by default? That knd of thing wouldn't be disabled by default. But does it hurt to change the preference? Again...I feel strong opposition basing off of flimsy reasons.Lucia Black (talk) 21:51, 16 December 2013 (UTC)

  Speed has killed quite a number of proposals in the past. Perhaps you just don't remember them. And, yes, this would make reviewing edits on pages significantly slower, particularly for people who only want to see the diff. Right now, a diff at

  WP:User script to do this yourself. However, I strongly object to you revoking my access to diff-only reviews.
  Finally, whether to request this sort of change is normally determined by the wishes of the people who show up for a discussion, and so far, only you support this idea without reservations. Rejecting your idea is not an example of catering to Mr.Z-man; instead, accepting it would be an instance of catering to you. WhatamIdoing (talk

  ) 22:43, 16 December 2013 (UTC)

• No. The system is already slow for numerous reasons; we don't need to add another. Killiondude (talk) 22:46, 16 December 2013 (UTC)

Not really, the general idea is to save time. And even if you did wanted to see the diff only, that can be arranged too by keeping it optional. But let's be realistic too. Let's say you edit Barrack Obama article from the opening post down to the very reference page. It would take more than 12 seconds, just to be sure that there weren't any mistakes in just the diff, especially if you're adding in citations, preview would be needed more. Also let's consider how long it really takes, realistically from looking at the barrack obama page, it would take even less time then wha you claim. If it takes longer, its not to just get it done, its because you'll be using both sides to it and looking at it thoroughly.

But I would like your support out of selflessness, afterall the compromise now is to have the option. Its not "catering" me if you support because its not about me, its about those who need it. On the otherhand, somehone making unrealistic conditions such as being optional and automatically disabled, is like saying only if I never get to fix it.

Me? I find it useful enough, a nuissance? Maybe at first. But others might see the need for it. I'll take If you want both, then I've got no objection to you getting both. Feel free to learn how to code, so you can write a

Killiondude. It maybe your internet provider or computer, but everything here runs smoothly. Plus its an option that technically already exists.Lucia Black (talk) 23:00, 16 December 2013 (UTC)

lol. Killiondude (talk) 23:03, 16 December 2013 (UTC)

I can look into coding a userscript for this a bit later today. I know I'd find it useful, and I don't think it'll be too hard. I don't know that it needs to be a gadget or otherwise default feature of the site though. Writ Keeper ⚇♔ 23:05, 16 December 2013 (UTC)

Could there somehow be a pair of checkboxes, so that a user could specify a diff, a preview, or both, as the user's case might suggest? Or some other interface for making the choice on a case by case basis, perhaps with a preference for the default. DES ^(talk) 00:42, 17 December 2013 (UTC)

@

bypass your cache, if necessary. You'll see a third button, next to the current "show preview" and "show changes" button; the script still lets you choose one or the other, if you want. Let me know what you think. Writ Keeper ⚇♔

10:56, 17 December 2013 (UTC)

Ok thanks. I appreciate this. Still, is there a way to advertise the script to others? in case they get the same idea?Lucia Black (talk) 15:19, 17 December 2013 (UTC)

There is currently an RFC opened at the village pump to clarify current consensus and policies about the controversial pseudo-namespace redirects that you might want to participate in. TeleComNasSprVen (talk • contribs) 23:48, 20 December 2013 (UTC)

Article Incubator

Hi,

There is an RFC at Wikipedia:Article Incubator/RfC to close down Incubator to close down the Article Incubator. Please join the discussion there.

talk

) 07:33, 23 December 2013 (UTC)

Automatically hide categories on Draft pages

Right now, we have some articles that have now been moved into the draft namespace. In the old days, you might have them under article titles like, "User:XYZ/Something." Now, they are under titles such as, "Draft:XYZ." In the days when everything was in the userspace, Articles for creation space, and wherever else people placed their submissions, it was harder to nullify the categories. Now that we have them in one space (well, in theory anyway), would people be adverse to having the categories either automatically nullified or have a bot do this work, so that we can remove potentially unnotable persons/places/things from general categories? It would remove a lot of the clutter that currently exists in these categories, which often contain half-worked on articles and ideas, and it would help to clean up the site. Plus, when the articles are moved, the site could be set up to automatically include these categories, like what goes on in the AFC submission process right now.

talk

) 07:14, 24 December 2013 (UTC)

Discussions about the new Draft namespace are usually at Wikipedia talk:Drafts. PrimeHunter (talk) 11:27, 24 December 2013 (UTC)

Template vandalism with images

Over the past couple of days, there have been several reports of vandalism or "hacking" at

WP:ANI

regarding template vandalism. The vandals target highly used templates that will transclude on lots of articles by placing images in the template to catch readers off-guard and shock them with nudity or something gross. There's obviously very little we can do other than revert the vandalism, protect the template, mark the image as a "bad image" and block the editor as of this moment.

My proposal is short, though the technical aspect of implementing it is a bit more complicated: To add images to the template namespace, an editor must have the autoconfirmed right. After filing a bugzilla and requesting it be changed, when the save button is hit, if the edit would transclude an image in the template namespace, the software would perform a check on the account and if it doesn't have autoconfirmed on their account, then the save will be stopped and brought back to the preview window with a message telling them they do not have the proper rights.

The result would be:

• There would not be any IPs adding any images to templates, which is almost always reverted anyways because most unregistered users do not understand how to either correctly places images in template syntax or they don't understand that images are not a common thing in the template namespace. In regards to the problem, a majority of the vandalism comes from IPs as well. Forcing autoconfirmed for saving images would force them to at least create an account.
• Brand new accounts with the intent to add images to vandalize wouldn't work either, because the autoconfirmed permission means they have to wait about four days and make ten edits, which makes template vandalism almost pointless if they have to wait for days and make edits that won't get them blocked. Vandals get bored that way.
• To users who aren't brand new, it doesn't change anything.
• The only potential collateral would be a brand new, well-intentioned user who is trying to insert a legitimate image into the template namespace and not being able to, and that is going to be a fairly low number of users who experience this problem.

Regards, — Moe Epsilon 04:17, 19 December 2013 (UTC)

There's too many ways someone could get around that (not discussing how per

WP:BEANS; if you want to know I'll email you). It'd be almost impossible to completely prevent it without effectively semi-protecting all templates. Jackmcbarn (talk

) 04:30, 19 December 2013 (UTC)

See Nirvana fallacy#Perfect solution fallacy. --Guy Macon (talk) 11:02, 21 December 2013 (UTC)

It's not intended to be a solution that will end the problem, there's effectively no way to end any vandalism outside of full protection so only administrators can edit the page. Of course there's ways to get around it, but it will still stop the majority of it. It's intended to slow down the problem, not to be complete prevention. It's becoming a daily occurrence, and we need to change something other than just wait it out and have readers stumble across an image of a woman peeing again. Regards, — Moe Epsilon 04:40, 19 December 2013 (UTC)

Support this proposal as a mostly effective countermeasure. --

Need Help?

• 04:45, 19 December 2013 (UTC)

• Actually, there are two other pieces of collateral not mentioned: 1) regular editors editing from an insecure connection, where logging in could compromise their account, and 2) regular editors without an account. Both of these groups would be adversely effected by a semiprotect-esque edit filter on the entire template namespace. So I would have to oppose something like this. I would, however, be supportive of looking at expanding WP:High-risk templates to draw up criteria for semi-protecting semi-widely transcluded templates, including mature wikiproject infoboxes and expansive navboxes. VanIsaac_{WS Vex}^contribs 05:13, 19 December 2013 (UTC)

"Regular editors without accounts" — this is a perennial (almost hallowed) objection to any suggestion of restricting IP access. How many of these are there? How is "regular" defined, and how substantial are their collective contributions relative to the work not done because time and effort spent cleaning up after irrregular IP editing? ~ J. Johnson (JJ) (talk) 22:01, 20 December 2013 (UTC)

How many long-term IPs are there? I've encountered enough that when I see a proposal like this, I think "but that would keep regular IP editors from doing X", but few enough that when I run into an issue with an IP, I don't give more than a passing thought to the possibility that they are actually a long-term IP editor. But you chose to ignore the possibility of other lines of inquiry - about expanding the high-risk template definitions to bring in default semi-protection for the kinds of templates where this could be a problem - so I don't know whether you are actually taking any of this seriously, or whether there's something else going on entirely that I'm not seeing. VanIsaac_{WS Vex}^contribs 12:30, 21 December 2013 (UTC)

The proportion of IP editors that are "regular" (good? serious?) is small, just because of the large base, and I suspect their total number as well. But what I am curious about is: how substantial are the supposed contributions of these purported "regular IP editors" relative to the work necessitated by not having everything semi-protected? ~ J. Johnson (JJ) (talk) 20:27, 21 December 2013 (UTC)

Quite frankly, I don't know, and I'm not sure that anyone can even make an educated guess on it. You usually don't ever follow up on figuring that sort of thing out unless there is a conflict of some kind, which horribly biases personal experience, and tools can't see through dynamic IPs. We're actually dealing with five different populations here, and it's almost impossible to distinguish between many of them, let alone make any sort of comparitive enumeration: 1) single incident IP vandals 2) short-term IP editors involved in edit conflicts 3) short-term, productive IP editors not involved in edit conflicts 4) long-term, productive IP editors involved in edit conflicts 5) long-term, productive IP editors not involved in edit conflicts. Because IPs get dynamically allocated, there is no tool that can tell us the difference between #2 and #4 or #3 and #5, there is basically no means of ever really being able to notice #3 or #5, or determine whether you have seven different #3s or a single #5, and #1 is the only group that you are trying to target, but #2, #3, #4, and #5 are all getting caught in the crossfire. I don't know the answer, but I would certainly argue that making a blanket ban on editing templates with an image tag in them is an overreaction. VanIsaac_{WS Vex}^contribs 21:57, 21 December 2013 (UTC)

One of the only things that Visual Editor was good for was providing a peek at behavioural choices. When given a choice, new accounts used Visual Editor about 25% of the time, IPs about 10% of the time, and established editors about 8% of the time. A little bit of number crunching on that factoid would indicate that about 80% of IP editors are experienced editors. Certainly not a number to quote as gospel truth, but an interesting indicator nonetheless.—Kww(talk) 00:37, 22 December 2013 (UTC)

Yes, I found that stat quite interesting. But "experience" does not necessarily correlate with "good"; it may mean nothing more than most vandals are experienced. I think it tells us nothing about all the good work IP's allegedly do. ~ J. Johnson (JJ) (talk) 00:44, 23 December 2013 (UTC)

• Oppose as this hasn't been much of a problem for years. That tells me that for years, IP editors have been adding useful and proper images to templates with only an occasional vandal mucking with things. That leaves me the impression that this would leave way too much collateral damage to be worth doing. This would also prevent an IP from making edits to templates that include an image (even if they didn't place it there). So, if they wanted to update a flag icon template for example to adjust the range of years or correct a typo of a country name in a rarely used version, they would be unable to and be required to submit an edit request. This is too tedious and I think is a bad idea. Technical 13 (talk) 12:59, 19 December 2013 (UTC)

• This is actually been a problem for a years, it's just that vandals get more creative with time, it's the whole reason why the page for high risk templates exist and has existed for so long. Finding gross or nudity-laced images and pluging them into templates to shock readers has been a long-standing vandal tactic. It's just a matter of finding an image that isn't marked as "bad" and finding a new template that hasn't been protected yet, and a vandal as of late has just been exploiting less high-risk templates that still spread to hundreds of articles, forcing us to protect things that are not high-risk. Also, your fear that IP editors wouldn't be able to edit a template with an existing image is not needed. When you click the save button, the software identifies what text needs to be changed, shown in diffs in the history and not surrounding text unrelated to the edit. The proposal is to have the software interpret new text being inserted and if it would render [[File:imagename.extension]] or [[Image:imagename.extension]] successfully, a check of permissions for the user would be done. Existing images would not be an issue, and the fear of high collateral isn't really warranted either. Images are not highly used in the template namespace, and outside of regular editors logged out, most IP editors would not know when or how to insert an image that wouldn't be reverted. Regards, — Moe Epsilon 17:42, 19 December 2013 (UTC)

• The problem is that figuring out whether it would render [[File:imagename.extension]] or [[Image:imagename.extension]] is extremely hard to do (impossible, actually, since the Halting problem is unsolvable). There'd either be a ton of false positives, effectively semi-protecting all templates, or a ton of false negatives, making the protection worthless. Jackmcbarn (talk) 17:53, 19 December 2013 (UTC)

• See Nirvana fallacy#Perfect solution fallacy. --Guy Macon (talk) 11:02, 21 December 2013 (UTC)

• Uh, how is that related to the halting problem? It's just a regex search for whether added_text contains /\[\[(File|Image):[^\]]+\]\]/, (or something like that). Writ Keeper ⚇♔ 18:01, 19 December 2013 (UTC)

• I've emailed you a response. I'm not posting it publicly due to
  WP:BEANS. Jackmcbarn (talk
  ) 18:31, 19 December 2013 (UTC)
• To clarify, if someone just sticks [[File:imagename.extension]] straight into a template, that's easy to detect, but there's ways they could add an image (poke me if you want an example emailed) without doing that, which we wouldn't be able to detect. Jackmcbarn (talk) 18:49, 19 December 2013 (UTC)

• Special:AbuseFilter/599. We'll see how that goes. Legoktm (talk) 18:37, 19 December 2013 (UTC)

• Special:AbuseFilter/599 doesn't seem to prevent anons from posting images to "Template:". Technical 13 (talk) 19:14, 19 December 2013 (UTC)

The filter code is hidden from public view but in order to reduce false positives, it only activates under certain conditions (which we don't want determined vandals to know) and it doesn't prevent the edit, it only logs it (the linked edit wasn't logged). PrimeHunter (talk) 19:33, 19 December 2013 (UTC)

By "false positives" I mean loggings of non-vandalism edits. PrimeHunter (talk) 19:38, 19 December 2013 (UTC)

• Sympathetic to the proposal but this discussion is way too technical for me Johnbod (talk) 22:05, 20 December 2013 (UTC)
• Question - Is this a case where some variant of Pending Changes (something like Pending Changes 2 perhaps) for these high risk/high use templates would be useful? If it stops the vandalism going live across Wikipedia then it takes away the point of it - and it may also help to minimise the potential for people accidentally brwaking high use templates.Nigel Ish (talk) 23:35, 21 December 2013 (UTC)

• Alas, pending changes Level 2 is not an option.

Extended content

Interaction of Wikipedia user groups and page protection levels   Unregistered or newly registered Confirmed or autoconfirmed Extended confirmed Template editor Admin Interface admin Appropriate for (See also: Wikipedia:Protection policy) No protection Normal editing The vast majority of pages. This is the default protection level. Pending changes All users can edit Edits by unregistered or new editors (and any subsequent edits by anyone) are hidden from readers who are not logged in, until reviewed by a pending changes reviewer or admin. Logged-in editors see all edits, whether accepted or not. Infrequently edited pages with high levels of vandalism, BLP violations, edit-warring, or other disruption from unregistered and new users. Semi Cannot edit Normal editing Pages that have been persistently vandalized by anonymous and registered users. Some highly visible templates and modules. Extended confirmed Cannot edit Normal editing* Specific topic areas authorized by ArbCom, pages where semi-protection has failed, or high-risk templates where template protection would be too restrictive. Template Cannot edit Normal editing High-risk or very-frequently used templates and modules. Some high-risk pages outside of template space. Full Cannot edit Normal editing Pages with persistent disruption from extended confirmed accounts. Critical templates and modules. Interface Cannot edit Normal editing Scripts, stylesheets, and similar objects central to operation of the site or that are in other editors' user spaces. * In order to edit through extended confirmed protection, a template editor must also be extended confirmed, but in practice this is almost always the case. Other modes of protection: Create protection Move protection Upload protection Office protection Cascade protection view talk edit

--Guy Macon (talk) 00:23, 22 December 2013 (UTC)

Why isn't PC2 an option? That RFC only said not to use it (normally; there have been a very small number of accepted exceptions) for six months or so after PC1 was available. There's nothing there that says PC2 may absolutely never be used—and even if it did, then

WP:PROPOSAL to do so. WhatamIdoing (talk

) 18:14, 23 December 2013 (UTC)

It's a technical issue, not a policy one. Pending changes protection doesn't work through transclusion. The latest version is always transcluded, even if it's not accepted. Jackmcbarn (talk) 18:23, 23 December 2013 (UTC)

• I think that because an administrator is no longer needed, the threshold for what constitutes a "high-risk template" should be lowered. Perhaps we should start at half of the transclusion count of what it was for full protection? What was that threshold exactly anyways, does anyone know? I've seen as low as about 2,000. Comments? Complaints? I'm sure there will be both to this idea, so we might as well get them now. Technical 13 (talk) 05:52, 22 December 2013 (UTC)

• I'm not exactly sure. The high-risk templates guideline says each template was considered individually, which might need to be individually re-evaluated. Obviously a high transclusion count matters, but templates that are highly visible and not cascade protected and templates substituted often are also high-risk. Likewise, one-time targets for hit-and-run vandalism and transclude on a small number of pages should not have been semi-protected. I'm curious how abuse filter 599 is doing, since I can't view what it is logging. Regards, — Moe Epsilon 07:49, 22 December 2013 (UTC)

• Oppose This completely violates the template editor RfC. "It should be understood that the standards for what constitutes a high-risk template should remain unchanged and not be expanded, despite this newly created protection level and rights group." Jackmcbarn (talk) 16:19, 22 December 2013 (UTC)

• I'm not proposing to change it solely on the bases of there being a new userright. I'm proposing changing the threshold because there is now evidence of vandalism on templates with a lower level of transclusion. There is a big difference there, I do hope you see it. Technical 13 (talk) 00:06, 23 December 2013 (UTC)

• You said above, "because an administrator is no longer needed". That's exactly equivalent to being because of the new userright. Jackmcbarn (talk) 17:08, 23 December 2013 (UTC)

• In a section titled "Template vandalism with images", so "because an administrator is no longer needed" is not the sole reason. Technical 13 (talk) 17:52, 23 December 2013 (UTC)

• Yes, I seem to recall that during the Rfc there were a number of editors who opposed the new right because they believed that over time those with the right would find reasons to gradually protect more and more templates, causing frustration for those without it. —Anne Delong (talk) 05:51, 23 December 2013 (UTC)

• I'd rather see a solution that added history information for transclusions, and if possible a summary added or removed images to the history pages. For example if article used template:Infobox_Foobar then the most recent changes to that template should be shown in the history. It wouldn't need to show the full history for the templates, just the most recent one for each template with a link to the full history. PaleAqua (talk) 08:26, 23 December 2013 (UTC)

• We have that now. User:Anomie/previewtemplatelastmod Jackmcbarn (talk) 17:08, 23 December 2013 (UTC)

• I'm familiar with that script. It's why I think doing this for history page should be doable. The history page is seems to me to be a better place than the preview page for dealing with vandalism. The first check I make when noticing a page has been vandalized is the history page, I assume that this is fairly common. Furthermore, the editors that wouldn't automatically consider that a template change might be a cause, would likely also not be the ones to add a custom js script to common.js file. PaleAqua (talk) 18:09, 23 December 2013 (UTC)

All this really needs is a fast method of discovering and reverting template vandalism. Most of the complaints have been slow to be fixed because people have trouble discovering them. Like, is it any harder than using "Related changes" on a vandalized page and limiting to template namespace? If not, then instructions should be part of the AN/ANI editnotice. People are still going to run to ANI and associated boards as soon as an article shows some sign of vandalism, whether it's from a template or not, because they're not comfortable editing Wikipedia. —/Mendaliv/^2¢/_Δ's/ 08:43, 29 December 2013 (UTC)

• As one of the editors who dealt with the fallout of one of the instances of this vandalism, there is anoher factor that I noticed coming into play here. Even after the template was reverted, several editors reported seeing the old vandalised template on several articles. (This, despite the fact that I was unable to see the same).

This had something to deal with purging of pages, and though I do not understand the technicalities of it, we must make sure our vandal-fighters know of this to make sure a vandalised version is not shown to some of the readers.

talk

) 11:17, 29 December 2013 (UTC)

The technicalities are thus: pages are purged automatically when a dependent template is changed, but it's not immediate (as it is when you hit the action=purge button on such a page). They go to the bottom of the job queue. Perhaps there should be a mechanism for bumping template vandalism reversions to the top of the job queue (e.g., the person who reverts would probably post a request at AN/ANI, and an individual with advanced permissions would be authorized to force such a cascading purge), though I imagine this would take developer intervention at the MediaWiki level. —/Mendaliv/^2¢/_Δ's/ 11:25, 29 December 2013 (UTC)

talk

) 12:45, 29 December 2013 (UTC)

A script would probably work, but I think there are issues approaching

WP:BEANS territory. I'd really rather see something implemented at the developer level that both handles this and blocks what activity I'm concerned about with scripting. —/Mendaliv/^2¢/_Δ's

/ 12:52, 29 December 2013 (UTC)

• Given the recent spurt of planned template vandalism, I have reason to believe that we need some sort of restrictions on IPs editing templates, even if as an interim/temporary measure. I agree there would be collateral, but we can deal with them using some sort of {{
  talk
  ) 11:17, 29 December 2013 (UTC)

• I have started an RFC at
  talk
  ) 19:46, 29 December 2013 (UTC)

Wiki.png

As New Year is coming soon, so I'd like to propose that we adopt special New Year-theme appearance for our File:Wiki.png for only two days – 31/12'13 and 01/01'14. As I can see from file upload history, this wasn't a practice before. (Maybe it didn't occur to anyone.) But why wouldn't we make our Wiki space nicer with special holiday details? I have no doubts many of us were extremely hard-working this year, so we have so much to celebrate. Don't you think? Alex ^{discussion ★} 08:57, 26 December 2013 (UTC)

Great idea! I'm in for a party hat. --NaBUru38 (talk) 21:21, 27 December 2013 (UTC)

@

FP etc., though I personally would be sympathetic to sometimes changing the logo as a fun, light-hearted way of marking secular, non-controversial and apolitical events (whatever they may be). Sorry to be a party pooper, but I'd think we'd need general consensus on changinng the logo for events in principle rather than just for this specific New Years Day. Also, it's a little late - could we get a decent logo mocked up and decided on in time? I doubt it, unfortunately. :( Acather96 (click here to contact me

) 22:33, 27 December 2013 (UTC)

• Completely agree with what Acather said. I like the idea of changing our logo for specific occasions, but we need widespread consensus for the given select events (and designated alternate logos) before we implement that. Certainly an idea to be pondered over for a longer discussion.
  talk
  ) 00:11, 28 December 2013 (UTC)

• I agree with what Acather has said, but I would like to add that since I like this idea (and something along the same lines is something that I actually set up on DDOwiki) I would be willing to write a userscript that would be available to anyone that would like to see this be something available. I actually have another script that changes that image to symbolize that there is something going on on a page that is .sysop-show (a hidden section designed for admins and template editors) so that a setting can be toggled to show or hide those comments and notes. So, if I can find someone willing to create the proper sized .svg images for this proposal, I would be happy to write a script that will change the image on the correct days for whichever holidays or events that have available images. I could have it customized so each user could define a list of holidays in their userspace. Let me know if this would be an acceptable alternative to forcing holidays/religions/events on all readers and editors alike on Wikipedia. Happy editing! Technical 13 (talk) 01:44, 28 December 2013 (UTC)

FYI - there's a holiday logo in Wikipedia:Wikipedia_Signpost/2013-12-25/Discussion_report. GoingBatty (talk) 05:20, 28 December 2013 (UTC)

Following that image to commons and looking through the cat structure, there aren't a lot of holiday logos currently... I see one for Christmas, Halloween, Valentine's, St Patrick's, but none for other holidays such as New Year's, Hanukkah, Easter, Thanksgiving, Independence day (of any nation), etc... Anyone that is good with such things want to volunteer to make some logos? Technical 13 (talk) 01:57, 29 December 2013 (UTC)

RFC on Template protection

Hello,

There is an RFC at Wikipedia:Village_pump_(policy)#Template_Vandalism to protect templates inorder to deal with template vandalism. Please participate in the discussion.

Thanks,

talk

) 19:47, 29 December 2013 (UTC)

Need "Like & Comment" options in all Wiki articles

Dear Wiki Team,

I suggest that there should be some "Like & Comment" options in all Wiki articles. Just like Facebook, these two options make articles more attractive.

Thanks & Regards, Vinod Patil — Preceding unsigned comment added by 41.194.23.4 (talk • contribs) 10:55, 2 January 2014 (UTC)

See

talk on every page. --Rezonansowy (talk • contribs

) 13:16, 2 January 2014 (UTC)

Proposed changes to

WP:LEAD

I have proposed two changes to the guideline on leads which need some input from other editors. They are at Wikipedia talk:Manual of Style/Lead section#Four-paragraph lead and Wikipedia talk:Manual of Style/Lead section#Scope of article. SpinningSpark 00:23, 7 January 2014 (UTC)

Merge-and-delete accounts

Have we ever considered implementing mw:Extension:UserMerge? Apparently it's already being used by at least one WMF project, so it should be doable here from a technical perspective, and the idea sounds good. Nyttend (talk) 01:22, 7 January 2014 (UTC)

This was only enabled for Wikivoyage wikis when they were being imported, so we could properly merge users from the Wikivoyage databases and the rest of WMF wikis. It's basically a non-starter though as-is, as it doesn't respect CentralAuth (which it'd need for any usage wider than what we deployed it for). ^

^{[omg plz]}

 02:02, 7 January 2014 (UTC)

Make it impossible to undo an undo

It would greatly reduce the number of edit wars if only administrators could undo an undo, with the exception that anyone can undo their own undo. If that casues too much of a problem because the person who undid the edit made a mistake and undid a good edit, then mayby instead, just certian people could just be blocked from undoing undoes rather than totally blocked for a certain period of time after it's discovered that they did an edit war. Blackbombchu (talk) 04:38, 7 January 2014 (UTC)

This would simply make it harder to remove vandalism. And editors who are edit warring can still go to the old version of the article and click save. --NeilN ^{talk to me} 04:44, 7 January 2014 (UTC)

Non-starter. Reason: see what NeilN said. GenQuest ^{"Talk to Me"} 05:34, 7 January 2014 (UTC)

VE on Wikipedia: namespace

Can we enable Visual Editor on Wikipedia: namespace? --Rezonansowy (talk • contribs) 17:29, 1 January 2014 (UTC)

It is technically possible, if people want to do it. However, VisualEditor doesn't know how to sign posts, which means that it would not be especially useful for a page like this. Whatamidoing (WMF) (talk) 19:25, 1 January 2014 (UTC)

Wikipedia pages don't cover only talk, they contains many article-like pages, that's why I think it will be a good idea. --Rezonansowy (talk • contribs) 13:14, 2 January 2014 (UTC)

Does anyone else have an opinion on this? Whatamidoing (WMF) (talk) 21:34, 2 January 2014 (UTC)

To the extent that the main focus of VE is to encourage new, inexperienced editors to contribute to article space, I don't see the point. If some experienced editors would find it useful, and we can avoid the previous main-space issues, then maybe. We don't really want newbies making many edits in WP: space, do we? Wbm1058 (talk) 21:47, 2 January 2014 (UTC)

But

WP:Draft namespace is another story. That could be the perfect place to beta test VE! Wbm1058 (talk

) 21:51, 2 January 2014 (UTC)

If a new user has something worthwhile to say in the Wikipedia: namespace, they should go right ahead and do it. To me, the problem with enabling VE in WP space is that it's a mixture of article-style and talk-style pages, and VE just can't handle signatures yet. As for Draft: namespace, VE appears to already be enabled (as it should be in my opinion). Novusuna ^talk 22:02, 2 January 2014 (UTC)

But to use VE, even in Draft: namespace, I need to enable it in my user preferences. I'm suggesting, as was controversially implemented last summer, that this is the one namespace where the WMF might be able to get consensus for enabling VE to be the default editor. – Wbm1058 (talk) 22:26, 2 January 2014 (UTC)

So, what now? --Rezonansowy (talk • contribs) 20:03, 3 January 2014 (UTC)

At this time, it is not technically possible to do this. However, I can write up the request at Bugzilla, if people want to do it, and we could see whether they would make it possible. Whatamidoing (WMF) (talk) 23:26, 3 January 2014 (UTC)

Whatamidoing (WMF), I'd appreciate it if you could create a bug to track the issues relevant to enabling it in the Draft namespace. I suspect bugzilla:50172 is one of the problems. John Vandenberg ^(chat) 11:08, 8 January 2014 (UTC)

I created T61885 for you. I haven't yet found anything else that needed to be added to it. Whatamidoing (WMF) (talk) 22:05, 9 January 2014 (UTC)

My opinion is that Visual Editor should be abandoned and certainly not made the default for any aspect of English Wikipedia anywhere. You did ask. Carrite (talk) 03:04, 4 January 2014 (UTC)

• And why would it be so?
  talk
  ) 03:17, 4 January 2014 (UTC)

Carrite, The power of Wikipedia is that you have always choice. You can use VE or edit the code, or even switch from VE editing to code directly. That's a power of the community project, nobody decides for you what you're using. --Rezonansowy (talk • contribs) 10:21, 4 January 2014 (UTC)

Whereas this statement is correct for VE, it is not correct for FLOW.--Ymblanter (talk) 15:28, 4 January 2014 (UTC)

Not only does VE not allow signatures to be added (bugzilla:51154/bugzilla:51899), it also corrupts existing ones (bugzilla:59229). It also can't efficiently edit sections (bugzilla:48429). There is an enhancement request to allow VE to be enabled on specific pages (bugzilla:50883), for example a sandbox in project space. I have started a tracking bug for related issues. See bugzilla:59818 John Vandenberg ^(chat) 11:05, 8 January 2014 (UTC)

Adding editnotices to date format and language templates

I don't know whether this is practical as it might require some software changes or an extension, but could the date format and language templates (e.g. {{Use British English}}, {{Use American English}}, {{Use dmy dates}}, etc) be configured to display an editnotice on pages which transclude them? It could be quite a neat way to let users know which format to use without them having to look for a template on the talk page, the bottom of the article body, or an obscure hidden category. --W. D. Graham 11:15, 7 January 2014 (UTC)

I just created a new sub-category

English dialects. It could be a good task for a bot to just walk everything in that category, and create the appropriate edit messages—only admins and template editors can create or edit these messages. But I think there is confusion about the purpose of these templates. Are they designed as an advisory message for articles that already consistently use a single English dialect, to prevent editors from introducing other dialects to the article, or are they designed only for tagging articles that have mixed or incorrect dialects, intended to be removed once the problem is corrected, as categoring by date implies, e.g., Category:Use American English from December 2013. – Wbm1058 (talk

) 18:05, 7 January 2014 (UTC)

I think that rather than using a bot for this, JavaScript could be used to inject editintros, the same way it does for BLPs now. Jackmcbarn (talk) 18:13, 7 January 2014 (UTC)

The documentation for {{use dmy dates}} states that they are intended to "assist in maintaining consistent formatting within an article. It is not a temporary "cleanup" template". One of the original purposes of the templates was to guide bots, although I am aware of several users - myself included - who also look for these templates when editing. I thought it might be a good idea to make them more visible - such as through an editnotice - to guide users who may not be familiar with them or know where to look. --W. D. Graham 18:13, 8 January 2014 (UTC)

Right, I think it makes sense for both to just be permanent advisories. An editor noticing the wrong date format or the wrong dialect should just fix it right there rather than tag it for someone else. Given that, I don't think we really need to sub-categorize Category:Use dmy dates or any of the Use English categories by month as there is no backlog to work through. Wbm1058 (talk) 22:48, 8 January 2014 (UTC)

Oh, sorry, I get it now. The dates are for bots to use that periodically visit and fix date formats or dialects, so you know the last time that a bot passed by to check for date or format inconsistencies. Wbm1058 (talk) 22:52, 8 January 2014 (UTC)

• Would adding a parameter (or two) to {{
  Edit notice}} that would put a note on the pages work? It wouldn't be automatic (although if the template is on the page itself, the maint bots could add it to the edit notice if it was in at least TE group or submit an edit request automatically otherwise). I would be happy to work up that in the sandbox. Technical 13 (talk
  ) 22:39, 8 January 2014 (UTC)

  You mean like Template:Editnotices/Page/International Space Station? But editing International Space Station, I see that it also has a {{Use British English}} template. How can we avoid that redundancy and still have both the edit notice and the cats? Wbm1058 (talk) 22:58, 8 January 2014 (UTC)

• That is just ugly... But, yes, something similar only it would be a parameter instead of an entire new editnotice template. Anyways, why would it be redundant? The template doesn't seem to actually display anything (maybe I have something turned off which is why I'm not seeing it?) Technical 13 (talk) 00:43, 9 January 2014 (UTC)

  The link I gave is just what you see when you're editing the edit notice. When you're editing the article, it's this. Looks nice to me. Keep in mind the original poster's question. Can we make any page with a {{Use British English}} tag just automatically have that edit notice? Needing to make a separate edit to the notice is what's redundant. The most promising answer above was the suggestion to "use JavaScript to inject editintros, the same way it does for BLPs now". I should learn how to do that sometime. Wbm1058 (talk) 04:24, 9 January 2014 (UTC)

• Found it! – Use an Edit Intro with these templates, rather than an edit notice. That's the ticket! See
  WP:EDITINTRO. Wbm1058 (talk
  ) 05:09, 9 January 2014 (UTC)

• That's the same thing as Jack said above, the trick to that is getting community consensus to add the required code to MediaWiki:Common.js, which may be like pulling hen's teeth. Technical 13 (talk) 05:37, 9 January 2014 (UTC)
  • Right, except he didn't give the link to
    WP:EDITINTRO which makes the details more clear. Is this something we could test by letting editors opt in by editing their common.css or common.js? Might be easier to get consensus if people have the opportunity to road test it before !voting. BTW I haven't even created my common.css yet. I trust your idea re {{orphan}} above really does work, otherwise some may have a point if they say "disruptive". Wbm1058 (talk
    ) 14:09, 9 January 2014 (UTC)
    • Looking at how the BLP and DAB notices are implemented, it looks like there needs to be either a central category or an html element for the javascript to latch onto. We might need to put an invisible html element - such as <div id="UseXXEnglish" style="display:none;"></div> - into each template to trigger the script. --W. D. Graham 14:56, 9 January 2014 (UTC)
      • I created the central category, Category:Use English templates, maybe that's useful. Wbm1058 (talk) 15:35, 9 January 2014 (UTC)
      • More likely something like <span id="UseEnglish" data-which="XXX"></span>. The script would look for that id and read out the data-which parameter. Anomie⚔ 01:12, 10 January 2014 (UTC)

• I believe that Edokter or Mr. Stradivarius is the one that suggested common.js/css as a way to fix the orphan discussion above. I think it can be just as easily solved in-line through the lua module for multiple issues and the message box template that {{Orphan}} uses. I would much rather try to do it without common.js/css because I know what a pain it is to get consensus to add something to those pages. As to your question about testing, we can most certainly create it as a userscript, if that gains popularity it can most certainly be nominated to be a gadget to get a wider range of use (it can be set as default off or on based on what the community thinks). Technical 13 (talk) 15:04, 9 January 2014 (UTC)
  • Right, I guess the implementation path might be userscript → optional gadget → mandatory gadget and that last hurdle may be the hardest as so far only disambiguation and BLP have risen to that level.
  • (sidebar) remember there are two issues: (1) provide orphan patrol editors text they can import to common.css that makes {{orphan}} always visible. We could be testing this right now with {{orphan/sandbox}} and common.css code that works with the sandbox template. {{orphan/sandbox}} would be invisible by default, even inside {{multiple issues}}. This piece I consider mandatory. Do you have {{orphan/sandbox}} and common.css text ready for me to test? Issue (2) is making it visible by default when in {{multiple issues}}. I consider this piece optional, and maybe still even potentially controversial. - Wbm1058 (talk) 15:35, 9 January 2014 (UTC)
  • (more sidebar) oh, sorry. (pulling foot out of mouth) I should have tested days ago. Returning to on-topic locations... Wbm1058 (talk) 20:39, 9 January 2014 (UTC)

Right click a file to view it at full resolution

I think right clicking any image file in any Wikipedia article should make a full resolution version of the image cover the article and both right clicking it a second time and moving the mouse of the image should make the image disappear off the screen. That avoids the cumbersome 2 clicks to view it at full resolution and another 2 clicks to go back to the article. If one of the dimensions of the image is larger than that dimension of the computer screen, left clicking the image should swap between screen fitting and full resolution and when view it at full resolution, there should be a hand symbol for dragging the image so that one or both of its dimension can take up an entire cropped part of the screen without a scrolling bar or the top of the browser reducing how much of the image is on the screen, or the entire screen if both of its dimension or bigger than those of the computer. That poses a problem of being unable to open the file in a new tab during editing without losing your edit. The problem can be solved by left clicking any link in a preview automatically opening it in a new tab. Even typing in the search bar during an edit then clicking the magnifying glass symbol should automatically open the search results in a new tab. Blackbombchu (talk) 20:24, 7 January 2014 (UTC)

I forgot, left clicking is used both for dragging the image with a hand symbol and for switching between screen fitting and full resolution which is impossible. One solution to that propblem is to make it so that left clicking can switch from screen fitting to full resolution but not the other way around. Those people who want to see the screen fitting version of the image can just not left click it in the first place. Another solution is to make it so that once you left click the full resolution version of the image that's larger than the screen, the - symbol where the mouse is doesn't turn into a hand until the mouse moves at least 1 pixel during left clicking. Blackbombchu (talk) 20:35, 7 January 2014 (UTC)

Right clicking has always been reserved for browser and other application context menus, not to mention those that don't or can't support it, and further not to mention accessibility. Overriding right click functionality breaks all existing browser functionality, which in no way outweighs proposal issues. Almost every modern browser supports all the above actions with standardized controls. —  HELLKNOWZ  ▎TALK 23:17, 7 January 2014 (UTC)

I'm proposing that hovering over a file look something like this

with no edges around the image making it look like a popup window. Blackbombchu (talk) 02:38, 8 January 2014 (UTC)

Honestly, your proposal for adding all that functionality into mouseclicks sounds like a solution looking for a problem, as encapsulated by the phrase "the cumbersome 2 clicks". And am I reading correctly that you are proposing that hovering over an image makes it pop up? I honestly hope that anything like this is never implemented. By the way, relax a bit with the proposals. There are far more productive and efficient ways to improve Wikipedia than by writing a lot of proposals that don't seem to gain traction with the community. :) -Well-rested^Talk 06:59, 8 January 2014 (UTC)

Maybe a better solution would be to have right clicking bring you directly to the page that shows the image all by itself instead of its description page with right clicking once performing the same function as left clicking twice. That way, the back button also only has to be clicked once. Blackbombchu (talk) 14:54, 8 January 2014 (UTC)

An even better solution would be for links to files to include a hyperlink titled file. Blackbombchu (talk) 15:10, 8 January 2014 (UTC)

Maybe the best solution is for images in Wikipedia articles to look something like this:

Blackbombchu (talk) 16:39, 9 January 2014 (UTC)

I agree with Blackbombchu that having to load the file page for accessing the full image (two clicks + a page load) is a problem. But using right click or hovering seem the wrong solutions. A left click on the image should show display the expanded image in a lightbox, which is currently the standard behavior of images on the web; and the lightbox should include the link to the file page, thus reversing the order of actions and making the frequent interaction the easy one. Only with Javascript disabled should the image include a direct link to the file page. Diego (talk) 11:01, 8 January 2014 (UTC)

If this were a thing, could it be opt-in/out? Because I personally enjoy the way images act now on this site. - Purplewowies (talk) 14:30, 8 January 2014 (UTC)

Isn't this already a thing? That sounds more or less like the Media Viewer, available in the beta page of user preferences. Novusuna ^talk 16:40, 8 January 2014 (UTC)

W00t! Thanks for pointing that, I wasn't aware of the Beta preferences. Diego (talk) 17:23, 8 January 2014 (UTC)

Welp. XP Makes sense I didn't know about it, as I don't often go to my prefs, and even less often to the beta part. - Purplewowies (talk) 04:22, 9 January 2014 (UTC)

Allow any verifiable information at all in Wikipedia articles

The original purpose of requiring information to be verifible was so that almost all information in Wikipedia articles would be true, not so that almost all of it would be verifiable, because without it, some people would be adding in information they thought was true but wasn't. All verifiable information should be allowed even if the method of verification that can be done is different from viewing a source. For instance, information stating that YouTube is a website for watching videos shouldn't have to be removed even if no sources can be found for that information because it's verifiable by going to YouTube. On the other hand, stating that YouTube has a bell symbol at the top isn't quite true because it doesn't have it for people who aren't signed in, so if such untrue unsourced information is found in an article, instead of removing that information, it might be better to replace it with the true information that YouTube sometimes has a bell symbol at the top. Blackbombchu (talk) 22:56, 7 January 2014 (UTC)

What you are proposing is making conclusions not directly supported by sources, which is basically

WP:OR and is excluded for very good reasons. —  HELLKNOWZ  ▎TALK

23:12, 7 January 2014 (UTC)

(

You don't need to cite that the sky is blue. What sort of verifiable information that we now exclude would you want to include? DES ^(talk)

23:13, 7 January 2014 (UTC)

Something like the fact that Bing feedback has a limit of 400 characters, which is super easily verifiable by almost anyone, which I proposed including in Google Feedback after it gets renamed to Feedback (internet) but that type of information seems to be opposed in Wikipedia:Articles for deletion/Google Feedback. There might be enough other facts about that topic verifiable in that way to have the amount of information sufficent to write an article on. Blackbombchu (talk) 00:51, 8 January 2014 (UTC)

As a tertiary source, we're supposed to summarize, not detail, information. That Google allows feedback for its services is important, but how many characters you can include is not, unless for some reason that facet is called out by secondary sources. Even though you can validate the 400 character limit by looking at it, it's not really a needed point. --MASEM (t) 01:02, 8 January 2014 (UTC)

Looking at your picture on your user page doesn't prove that you have white hair because it could be a picture of someone else. On the other hand, verifying that Bing feedback has a limit of 400 characters proves that it has a limit of 400 characters. Blackbombchu (talk) 22:41, 9 January 2014 (UTC)

WP:V. KonveyorBelt

23:22, 7 January 2014 (UTC)

Moreover, a fact like "YouTube is a website for watching videos" is likely to be easily verifiable with reliable sources; the fact that sources discuss it is not only proof that it is true, but is also an indication of its significance. bd2412 T 00:07, 8 January 2014 (UTC)

WP:Verifiable says "All quotations, and any material whose verifiability has been challenged or is likely to be challenged, must include an inline citation that directly supports the material." It does not say every fact has to be referenced. Rmhermen (talk

) 00:13, 8 January 2014 (UTC)

WP:WEIGHT, etc. None of which establish "truth". Nor should they. We only report what others have determined. Or at least said they had. ~ J. Johnson (JJ) (talk

) 01:10, 8 January 2014 (UTC)

Blackbombchu, the issue that has been raised regarding Google Feedback isn't verifiability, it's notability. —Largo Plazo (talk) 11:58, 8 January 2014 (UTC)

Don't have titles of articles bolded in the introduction of the article

The reason why not to bold them is because I believe the way it originally started was by editors making accidental mistakes. I believe the way the bolding of articles titles started is that sometimes when somebody added the title into the body of the article, they made a mistake by writing [[Name of the article]] forgetting that people were already on the article and so didn't need a link to it then later on, that caused other people to make a mistake and think bolding was the way it's normally supposed to work so they did the alternate method of bolding by writing '''Name of the article'''. Blackbombchu (talk) 00:30, 8 January 2014 (UTC)

Blackbombchu, enthusiasm is great, but please scale back the number of proposals you're making. None of them seem to be gaining any traction. --Floquenbeam (talk) 00:33, 8 January 2014 (UTC)

I think that your "history" here is incorrect. But even if it were correct, boding the subject at first mention is now the Wikipedia standard, and changing it would involve changing almost all of our over 4 million articles, to no particular gain that I can see. I also agree with Floquenbeam above, slow down. DES ^(talk) 00:40, 8 January 2014 (UTC)

+1 → DES : bolding the topic name is now a standard practice, regardless of its origin. The question in my mind is whether any of the language-pedias go a different way and do not have this as a standard practice. --User:Ceyockey (talk to me) 01:02, 8 January 2014 (UTC)

Your guess at the origin is wrong. Back in the day, you couldn't actually link to [[Name of the article]]. The wiki used

CamelCase due to technical limitations, which had no brackets. Putting the title in bold-faced text became a convention very early on—possibly at exactly the same moment that putting the title in the first sentence caught on (because originally, you didn't do that). See this for the switch from CamelCase to free links; see here for the addition of the title to the first sentence, complete with standard bold-face. (These examples are taken from one of the oldest continuously surviving articles on the English Wikipedia.) WhatamIdoing (talk

) 05:19, 8 January 2014 (UTC)

I disagree with the change. As DESiegel says, there is no benefit for the change. --NaBUru38 (talk) 23:28, 8 January 2014 (UTC)

Disagree: The bolding of article titles helps emphasize what the subject is. WhisperToMe (talk) 23:46, 9 January 2014 (UTC)

An aside: looking at a couple of examples outside Wikipedia

I was curious how other encyclopedias and "encyclopedic" resources might treat this, so I took a look:

• Encyclopedia Britannica appears to do the bolding in the way that Wikipedia does (e.g. marmoset)
• Encyclopedia of Military Science, though, does not do bolding (e.g. Drug Interdiction)
• Stories in Stone: A Field Guide to Cemetery Symbolism and Iconography does not do bolding (book on my bookshelf; e.g. entries for "stone" and "hibiscus")
• print dictionaries always appear to bold the word as there is no dichotomy between entry and page ... if we look at Wiktionary, the words within an entry are bolded (e.g. wikt:landing)
• The classic textbook Biochemistry by
  Lehninger
  has quite a few sections which are single topic, such as "Trisaccharides" (pg. 263) and "Exitation-Contraction Coupling" (pg. 763); bolding of first use of the topic phrase does not happen in this textbook (another book on my bookshelf)

--User:Ceyockey (talk to me) 01:02, 8 January 2014 (UTC)

The proposal does not explain how there is any advantage in changing this.--Charles (talk) 10:19, 8 January 2014 (UTC)

Indeed. There is zero benefit to making a change to the bold title of an article. In fact, having to go through 4 million articles (even with a bot) to implement any such change would only be a mammoth waste of time and effort. Resolute 14:37, 8 January 2014 (UTC)

What portals, if any, are appropriate at Prometheus (2012 film)?

Previous discussions on this matter did not take place on the article talk page. Instead, they took place here:

• Wikipedia_talk:WikiProject_Film/Archive_46#Use_of_Portals_in_film_articles
• Wikipedia_talk:WikiProject_Film#Cross_WikiProject_relations_and_decisions_about_portals
• Wikipedia_talk:WikiProject_Portals#Questioning the need of portals when categories exist

What portals, if any, are appropriate at Prometheus (2012 film)? There are four opinions I have found in the archives that pertain to this film, so they can be thought of as four proposals: 5 portals, no (0) portals, no more than the number of relevant portals belonging to three WikiProjects, and 5 portals (with one being different than the first).

• Proposal A: I had included the following portals see diff:
• 2010s - Decade that the film was released
• Film - General portal on film (I had mistakenly added this portal twice in the diff)
• Film in the United States - Since some production companies are from the United States
• United Kingdom - Since other production companies are British
• Science fiction - Genre

• Proposal B: User:Darkwarriorblake argued that no portals are appropriate, and removed the portals I had added. Diff #1, Diff #2 which removed remaining portals - As of writing Prometheus_(2012_film) has no portals.

• Proposal C: User:Betty Logan stated at Wikipedia_talk:WikiProject_Film/Archive_46#Use_of_Portals_in_film_articles (Diff): "The Film portal is listed twice at Prometheus! For what it's worth though, I don't think portals belonging to other projects should be installed on articles that do not come within their scope. Prometheus belongs to the Film, Alien and Science Fiction projects, so at the most should only have portals belonging to those projects." (Note: the film portal listed twice was a mistake of mine) WhisperToMe (talk) 01:51, 29 December 2013 (UTC)

• Proposal D: User:Nihonjoe argued (See diff): "Apparently at least one person thought that was excessive. I added the Alien portal to the Alien footer template on that page (which is where it belongs). I think the 2010s portal might have been a little excessive, but the others seemed fine. It isn't unusual for some articles to contain multiple portal links. Certainly, Film in the United States, Science fiction (which actually redirects to the science fiction section of the Speculative fiction portal), and (what should have been, if it actually existed) Film in the United Kingdom are not just tangentially related, as Darkwarriorblake implied with his removal of the portals." - What "that" means is the number of portals I mentioned in the first "proposal"

So what portals are appropriate for this article? Which proposal should be selected? Or should another one be used? WhisperToMe (talk) 01:41, 29 December 2013 (UTC)

What, if any, portals are appropriate. I know you didn't mean to make your question clearly leading. There is an ongoing discussion at the above links and I believe this new one to be an example of canvassing and forum shopping for support. As of writing, Prometheus has no portals, portals are not a requirement of articles, it isn't a requirement of getting to GA or FA status either which Prometheus has done. We have interwiki links, more specific and directly related categories, and nav templates, which makes most portals, including the ones that were added, redundant, and the others have no link to the film and can offer a reader no insight at all or further reading on the immediate topic at hand. But discussion should continue at the above 2nd link where it started, instead of now the third or fourth place WhisperToMe has opened this debate. Darkwarriorblake (talk) 02:03, 29 December 2013 (UTC)

Please review Wikipedia:Canvassing. It is acceptable to notify other editors of a discussion as long as it isn't set particularly to any one side ("In general, it is perfectly acceptable to notify other editors of ongoing discussions, provided that it is done with the intent to improve the quality of the discussion by broadening participation to more fully achieve consensus." (emphasis mine)). What under the heading "Inappropriate notification" has happened in this instance? Also there is a parallel discussion of Should the WikiProject Film have the authority to say no articles in its jurisdiction should have portals or Should WikiProject Film entirely control the use of Portal:Film, prohibiting it from articles at the WikiProject members' say (My impression seems to be that different members have different ideas). WhisperToMe (talk) 02:10, 29 December 2013 (UTC)

By the way, blake, one thing I did do was make clear above that one proposal calls for zero (0) portals. WhisperToMe (talk) 04:05, 29 December 2013 (UTC)

Also I altered the title of this proposal and leading question to add "if any," making it clear zero (0) is an option for this article. WhisperToMe (talk) 04:40, 29 December 2013 (UTC)

Talk about portal spam. Keep to the most relevant portals, Films and Science Fiction. Any more than that, it would be excessive. If you add Films in the United States, then you should remove the Films link. Links to the decade portals should never be in an article unless the article itself is about the decade. (ex. 2010 in film) 24.149.119.20 (talk) 12:12, 30 December 2013 (UTC)

Comment: Honestly I'm fine with omitting Film since there would be "Film in the United States". However keep in mind pop culture products and current events are associated with decades.

Beavis and Butt-head after all is associated with the 1990s. ThunderCats (1985 TV series) is associated with the 1980s. Restricting decades to decade portals would not match the public perception of "decade nostalgia" which associates specific shows/films/etc produced in a particular decade with that decade. Remember that some articles simply are associated with multiple topics and multiple genres. I agree that the set of portals should be condensed as much as possible compared to the number of WikiProjects. Compare Talk:World War II to World_War_II#See also because a dedicated portal was made specifically for World War II. The more specific portals made, the fewer portals needed for each article and the more relevant each one is. Also, I added UK because it is not strictly an American film but a co-production. Some topics are more complex than others. However I'm happy to start a Portal:Film in the United Kingdom to cut around that issue. WhisperToMe (talk

) 19:58, 30 December 2013 (UTC)

• My general statement on what portals to include is "If it would be reasonable for the article to be used as a 'selected article' in the portal, it is reasonable to link to that portal in the article". I think that this would work as an entry in
  Wha?
  22:23, 30 December 2013 (UTC)
  • I created the decade portals myself but the idea comes from the French Wikipedia, where they've been established. I think the concept behind those decade ones is to match the public's perception of how culture and events transpire within a decade and the "decade nostalgia" that comes with them. A film/novel/television show from a decade could be seen as a "product" of that decade so I can see it as a "selected article" of that decade portal. WhisperToMe (talk) 00:07, 31 December 2013 (UTC)
    • If there is no further comment here, within 7 days I would like to re-establish only the Film in the United States portal and Alien (as Alien is deemed a more specific portal) though I would be happy to write a portal for Film in the United Kingdom for this article. Also I would like to explain the importance of the decade portals so the Wikipedia community understands why I believe they should be widely used. WhisperToMe (talk) 12:53, 3 January 2014 (UTC)

NO, NO, NO! You do not make the decision to close this in the way you would like—and certainly not by invoking a silent consensus after wearing people down. Leave that to an uninvolved editor (preferably an admin) to make the decision to close and to decide what the consensus is. - SchroCat (talk) 19:48, 10 January 2014 (UTC)

You know, SchroCat, yesterday I thought I'd go over to Talk:Gone with the Wind (film) and give my two cents about the proposal to include one portal link on that page... and it was so filled with you bickering that I decided not to bother even looking at the article to form an opinion. If you want comments from other people at that RFC, then let me encourage you to stop re-re-re-re-re-posting your own views. In fact, I'd suggest that all of that pointless argument be blanked or hatted, and that both you and WhisperToMe should resolve not to say a single word in or about the RFC for a while. If this sounds uncannily similar to the advice you were giving WTM in that RFC, then I'll suggest to you that what's sauce for the goose is sauce for the gander. WhatamIdoing (talk) 19:59, 10 January 2014 (UTC)

WhatamIdoing, I don't know who you are, or how little you know of this (not much, given your comment above), but considering I have walked away from three discussions involving WTM, including the walls of text on my two article talk pages and on my own page (twice: I have had to archive them both to close the discussion down), then perhaps you could be just a little less judgemental when I am trying to stop someone taking a provocative and irregular step. In addition, next time, perhaps you could also get your facts straight: I have made one made no comment in the Gone with the Wind RfC (since it was an RfC, only when it was a discussion), one comment on the Prometheus thread on this page (this is only my second) and only one on the GwtW thread on this page. Thanks for being so judgemental and pissing me off more that WTM has managed to do. - SchroCat (talk) 20:16, 10 January 2014 (UTC)

If you need some sort of "credentials", then you will likely find these two links to be informative: [8][9]. I've been involved in a lot of these "My WikiProject

WP:OWNs

that article" discussions, including several of the ones leading up to this particular RFC.

As for the instant "discussion", you have made six comments in that thread, and most of them are basically irrelevant (Could some other, unrelated film, with "only" an American screenwriter, an American producer, an American distributor and seven American Academy Awards, possibly be considered an "American" film in any way, if the American producer technically used a British corporation for the production) or unhelpful (e.g., accusations that WTM is "missing the point entirely" and "ignoring" other people's comments by requesting them). Whether these were posted before or after the RFC tag was added is irrelevant, since the discussion was originally advertised in other ways.

And on the relevant point: whether to add a link—any link—to a specific article is best decided on a case-by-case basis by the editors at that article, not in general discussions about whether, very generally speaking, links of this type are usually a good idea. The decision to link, or not to link, this link at that article needs to be made over there, after

considering all the facts and circumstances, by the people who are working on that article. That talk-page discussion isn't trying to create a policy about links. It's trying to get uninvolved people (i.e., neither of you) to express opinions about one link in one specific article. WhatamIdoing (talk

) 22:41, 10 January 2014 (UTC)

I'm not sure what your boast about the credentials is all about, or why you feel the need to blow your own trumpet on this. If you have something useful to say, then get on and say it, rather than pissing other editors off. (For the record, I'm not a member of any project - a slight nod to the Bond one is the closest, but nothing else). Your second point is unhelpful, unnecessary and off topic (try to focus not on me, but at the point I made about whether the proposer of an RfC should be the one to close a discussion, based solely on people not responding to them. If you don't have an issue with that then there is more concern for your judgement than I first thought). Thirdly I am well aware of how and where such a discussion should take place, I'm slightly bemused by you calling me "involved": I have made only three edits to the article and only ever commented on that one thread. Perhaps you could examine your attitude next time you want to talk to someone and stop being so judgemental and patronising. Perhaps you could also get a few of the basic points right about what my role in this is (I've already explained that I have disengaged from WTM, and strongly suggest that you disengage from corresponding with me in future). I'll let you get back to owning the pump and trying to dictate who can interact where and when. - SchroCat (talk) 23:15, 10 January 2014 (UTC)

Make it clear when there is no change to articles in your watchlist, compared to a zero byte length change

The watchlist is currently clever enough to show (10 changes | history) . . (+505)‎ when there are multiple changes, and (diff | hist) . . (-2)‎ when there is only one. However, when you have a (4 changes | history) . . (0) you don't know if it's a edit then a reversion to the original version, or a real change without any change to the article length (ie changing a date of birth from 1980 to 1940 or the name from John to Bill etc). You then have to do a diff check or popup/hover to see what, if anything, has actually changed. Could the watchlist be made smarter to show something like (4 edits, no net change | history) . . (0) when the current version is exactly the same as the original version? That would then make it very clear which article changes can be safely ignored. The-Pope (talk) 14:21, 4 January 2014 (UTC)

My watchlist doesn't do this. What gadget are you running? WhatamIdoing (talk) 15:52, 4 January 2014 (UTC)

You get it by both enabling "Group changes by page in recent changes and watchlist" at Special:Preferences#mw-prefsection-rc, and "Expand watchlist to show all changes, not just the most recent" at Special:Preferences#mw-prefsection-watchlist. PrimeHunter (talk) 16:24, 4 January 2014 (UTC)

I agree this would be a really useful feature. Because I don't care whether the article is getting longer or shorter. I do care how much it is changing. A measure of how many bytes differ (or rather, of the least number of bytes that differ, since you must account for insertions/deletions), between the current version and the last one I saw, would be much closer to what I want. (Although it would still not satisfy me perfectly: for example, a word that negates the meaning of a sentence might be more significant to me than swapping the ordering of two existing subsections. What I really want is closer to the algorithm used for computing the molecular-clock time-of-divergence between two DNA sequences, accounting for not only point-mutations but also large-scale mutations, and which involves finding the minimum or "most-parsimonious" possible-trajectory connecting the two versions.)

Obviously, this is computationally much more expensive than what we currently have (because simply comparing page-lengths is absolutely trivial). I'm not sure whether it would be prohibitively so. Cesiumfrog (talk) 23:10, 4 January 2014 (UTC)

It isn't necessarily a good thing to make watchlists more efficient, lest they help contributors to "

own" articles or categories. Apart from paid editors, no-one should have so many pages watchlisted that they need extra functionality to help. Ideally, pages should automatically drop off watchlists within a couple of months anyway. - Pointillist (talk

) 23:44, 4 January 2014 (UTC)

That's a really odd assertion. Right now I have 17,171 pages on my watchlist. Why do you think it's a problem for an administrator to pay at least cursory attention to a broad range of articles?—Kww(talk) 23:55, 4 January 2014 (UTC)

It isn't necessarily a good thing that you've edited 19,858 unique pages over the past seven years and you are still watching 86% of them (I don't see how being an administrator is relevant). The whole idea of "anyone can edit" is that individual contributors don't control article content, so if a subject isn't notable enough to have many eyeballs continually reviewing it, it will eventually be trashed in ways that ClueBot etc can't easily detect. If young adults don't want to maintain their Dad's Wikipedia, the solution isn't to build new watchlist functionality just to help an aging population of sports fanatics more efficiently ride shotgun on articles about retired minor athletes, is it? - Pointillist (talk) 01:14, 5 January 2014 (UTC)

What a bizarre view. Clue bot and edit filters don't always pick up the subtle changes. if established editors don't have big watchlists, who will notice subtle vandalism, whether to "serious" articles or to Dad's retired minor athletes - many of whom are still living, so

WP:BLP trumps OWN. Anything we can do to help make watchlists more effective must be a good thing. Or are you trying to fork this proposal into a criticism of NSPORTS? The-Pope (talk

) 01:47, 5 January 2014 (UTC)

It's also possible to watch an article to revert vandalism and make formatting fixes without OWNing it. People might also want to watch this page for more than a few months. GoingBatty (talk) 01:55, 5 January 2014 (UTC)

There are many valid reasons for a large watchlist. It's very odd to view it as an ownership issue. Many users have enabled "Add pages and files I edit to my watchlist" at Special:Preferences#mw-prefsection-watchlist. That can cause a huge watchlist if you don't spend time removing old entries. PrimeHunter (talk) 02:50, 5 January 2014 (UTC)

I don't see a problem with vandal-fighters keeping track of many pages, except perhaps for the effect on server kitties, and PrimeHunter's checksum suggestion would be a good way to detect data vandalism in statistics, climate tables etc. It's contributors who want to police their content in perpetuity who I feel shouldn't necessarily be assisted by providing extra features. I've nothing against coverage of sportspeople and other "temporary celebrities" either—except that I doubt the next generation of editors is going to be interested in maintaining those articles. - Pointillist (talk) 13:19, 5 January 2014 (UTC)

Correct. Very bizarre. If you are a regular vandal fighter, and wish to deal specifically with articles dealing with subjects about which you are familiar and comfortable with, you will inevitably have a large watchlist. My watchlist has article watches which are set to expire "never." For those others that aren't necessarily of huge interest to me but that I've helped anyway, I tend to periodically remove them from the watchlist once the spate of vandalism (or whatever) that originally drew my attention to it moves on, but several hundred articles of interest to me are ALWAYS on it. There are hundreds of thousands of articles that need that kind of oversight at Wikipedia. That's NOT ownership—that's taking care of articles that are important to Wikipedia and/or just of particular interest to me or any other vigilant editor. GenQuest ^{"Talk to Me"} 04:20, 5 January 2014 (UTC)

• I personally try to keep my watchlist under a 1,000 pages, I agree that a zero byte change is different than a null byte change. Let's ask the
  Lead Software Architect if there is something the developers can do about this, and if it is possible, I'll happily put in the Bugzilla ticket myself. Technical 13 (talk
  ) 04:40, 5 January 2014 (UTC)

I have often missed a page history feature to mark identical revisions, not just to the current revision. If a hash value was stored for each revision then it should be cheap. PrimeHunter (talk) 04:52, 5 January 2014 (UTC)

• Have you had any feedback from the
  Lead Software Architect or the devs as to whether this is possible to do? The-Pope (talk
  ) 09:12, 9 January 2014 (UTC)

• I have not heard anything from
  Brion or any of the other core developers (AKlapper (WMF)—Steven (WMF)—Whatamidoing (WMF)—Anomie—Magnus Manske). I just pinged some more (I'm guessing Brion has notifications disabled or isn't on here much). Technical 13 (talk
  ) 15:52, 9 January 2014 (UTC)

I am not a core developer. :) --AKlapper (WMF) (talk) 04:32, 10 January 2014 (UTC)

In principle one could change the software such that some sort of 'changed character count' based on a diff is generated at save time. (It would be too expensive to calculate on the fly on display; the current 'change size' is calculated simply by subtracting the old from the new text size in bytes, which is recorded at save time.) I'm not sure it's a high priority for folks, though, and finding a good replacement metric might be a bikeshedding nightmare. :) --

talk

) 19:28, 9 January 2014 (UTC)

Proposal to add Portal:Film in the United States to Gone with the Wind (film)

There is a discussion at: Talk:Gone_with_the_Wind_(film)#Is_Portal:Film_in_the_United_States_tangential_to_this_article_or_not.3F.

Please comment at the article talk page

I want to propose the addition of the Portal:Film in the United States. I created this portal as an adaptation of the fr:Portail:Cinéma américain. Some editors believe this portal (Portal:Film in the United States) is tangential to an article on an individual film and are only relevant to general/overall topics, and therefore this portal should not be included. I argue that this film has been perceived as one of the best examples of American film by reliable sources and therefore this portal is relevant and not tangential. Since there has only been a limited number of editors in this discussion, I am putting this forward as an RFC. Discussion may take place in the article talk page. Some relevant discussion is located here: Wikipedia_talk:WikiProject_Film#Cross_WikiProject_relations_and_decisions_about_portals WhisperToMe (talk) 23:10, 9 January 2014 (UTC) Oppose. Proposal has been made by an editor who apparently doesn't want to hear a consensus that doesn't favor their POV. DonIago (talk ) 01:26, 10 January 2014 (UTC) Comment: Doniago is referring to a general opposition to portals, in varying degrees, in members if WikiProject Film. I have received guidance on the matter here: Wikipedia_talk:WikiProject_Council#Do.2FShould_WikiProjects_have_the_power_over_how_the_portals_in_their_scope_are_used.3F The user pointed me to Wikipedia:Advice_pages#Advice_pages (a Wikipedia guideline). Since it is a guideline it is generally to be followed, but allows for exceptions and for common sense. Anyhow, once I notified the project of this, one Film project member argued that a WikiProject should still be able to make decisions on the WikiProject page. In response the user who gave guidance stated that decisions can be made on the WikiProject page but they may not only involve the members of the WikiProject. Advice pages states: "However, in a few cases, projects have wrongly used these pages as a means of asserting ownership over articles within their scope, such as insisting that all articles that interest the project must contain a criticism section or must not contain an infobox, and that editors of the article get no say in this because of a "consensus" within the project. An advice page written by several members of a project is no more binding on editors than an advice page written by any single individual editor. Any advice page that has not been formally approved by the community through the WP:PROPOSAL process has the actual status of an optional {{essay}}." (I have bolded the relevant parts) My impression is that the members believe that if major contributors to certain articles don't want portals in their articles, then portals should stay out. I have heard the following sentiments: One user: Does not believe in portals at all, and argues on the generalities of why portals should not be included as a rationale for removing all portals from Prometheus (2012 film). He referred to this linking of portals as "portal abuse" and removed all portals stating they are unnecessary and tangentially related - I started another village pump proposal RFC on this: Wikipedia:Village_pump_(proposals)#What_portals.2C_if_any.2C_are_appropriate_at_Prometheus_.282012_film.29.3F. The editors who responded who were not originally part of the discussion argued that the number I included at first was too many, but proposed including a smaller number of portals. Another user proposed that Portal:Film in the United States should only be added to an article if three editors per article agree on including that portal. Another user argued that the users of WikiProject Film should have the right to decide how Portal:Film is used and that WikiProject Film and WikiProject United States collaborate on how Portal:Film in the United States is used. The same user stated: "Portals are NOT a requirement of articles, and if they are opposed, they are opposed." The same user asked me "Despite the opposition points raised, which are actual points against their inclusion, you have not raised counter points, your argument seems to boil down to simply that because a portal exists it should be added to an article regardless of its relation or usefulness." Considering what the above states about the powers of WikiProjects, I think these views should be formally proposed to the community so the relationship between the WikiProject and the portals under its scope are clarified. I have offered the project to write its own, but if it does not wish to do this, I will present these views in a proposal written for the project, so the community will decide. In summary, I am convinced that matter is for the wider community to decide, and that this is the best course of action. No policy or guideline says portals must be included but in reality the community should decide which articles have portals, not only a small group of editors. If the community consistently supports adding even one portal to each regular article then this would mean de facto an article would have to have a relevant portal. DonIago, would you mind explaining why this particular article shouldn't have this portal? Or is this only about what AdvicePages is talking about? WhisperToMe (talk) 01:45, 10 January 2014 (UTC) My reasons have already been verbalized by other editors at the linked discussions. That you're choosing to keep pushing this despite despite numerous editors disagreeing with you is, at this point, only reinforcing my feelings that you're more interested in forwarding your own edits than working with your fellow editors. DonIago (talk) 02:34, 10 January 2014 (UTC) Take a look above: the editors are saying different things, and there are different threads of discussion (Prometheus (2012 film), Gone with the Wind (film) and this) with different people saying different things. There is no unified message from the WikiProject members about how portals should be used, only a general aversion of portals. However, what has frustrated me was one user's insistence that portals should not be in any project, and has refused to consider the inclusion of at least some in Prometheus (2012 film) (this is distinct from his belief that I added too many portals to the page). This insistence was not spoken against, and his repeated messages insisting on debating whether portals are necessary at all (even though this question has been discussed elsewhere and portals are being systematically used throughout Wikipedia) have shown up in many places, including an outside source discussion over whether portals have any use that categories don't jave: Wikipedia_talk:WikiProject_Portals/Archive_2#Questioning_the_need_of_portals_when_categories_exist The use of this general belief against portals to obstruct placement of portals in specific articles, have very much frustrated me, leading me to conclude that an ultimatum was needed, and therefore a village pump proposal is needed for his specific view of no portals if he insists on it. I have advocated for a proposal to be made to settle whether this user should continue obstructing the placement of portals in articles out of his belief that portals are not necessary. Therefore his proposal would either succeed (portals are abolished) or fail (portals remain, discussed on an article by article basis) and he would instead have to discuss the merits of a particular portal in a particular article as he is supposed to. DonIago, please consider that Wikipedia:Essay unless the wider community approves it. Please also consider the messages given to me here at the WikiProject Council: Wikipedia_talk:WikiProject_Council#Do.2FShould_WikiProjects_have_the_power_over_how_the_portals_in_their_scope_are_used.3F WhisperToMe (talk ) 02:42, 10 January 2014 (UTC) I already have considered it, thanks. DonIago (talk) 03:04, 10 January 2014 (UTC) You are welcome. Since you understand what the guideline says: If I file such a proposal affecting many articles (remember this proposal talks about one portal for one article and is not a broad proposal for many articles) what may happen is that the wider community may approve or allows the practice of the WikiProject Film to restrict usage of the portals involved, which means it will satisfy Wikipedia:Advice_pages#Advice_pages. Having this question settled is something that the Advice_pages encourages. WhisperToMe (talk ) 03:23, 10 January 2014 (UTC) Comment I don't quite understand why there is a proposal to add a portal to the "Gone with the Wind" article here. I've read through the introduction at the top of the page twice now and I still don't really know what this board is for, but I'm pretty sure it's not for discussing Gone with the Wind. If there is to be an RFC affecting GWTW it should be filed at the GWTW talk page and tagged in the appropriate manner. Betty Logan (talk) 03:25, 10 January 2014 (UTC) Comment: Wikipedia:Request_for_comment#Publicizing_an_RfC states that an RFC can be publicized in several ways, and one of them is using this village pump. I had also stated at the top "Discussion may take place in the article talk page." If you think I should use another way of doing so, please advise. WhisperToMe (talk ) 04:09, 10 January 2014 (UTC) Yes, I should have added the RFC tags, so I went ahead and did so. Thank you for telling me that needed to be done. I am accustomed to listing discussions at a noticeboard and therefore hadn't used the RFC tags. I went ahead and belatedly added the RFC tags for the Prometheus discussion. WhisperToMe (talk) 04:18, 10 January 2014 (UTC) Unfortunately, I don't think I can both assume good faith regarding Whisper's intentions and comment on that. DonIago (talk) 03:45, 10 January 2014 (UTC) Comment: As stated to Betty this board is one of the options for using an RFC but I am happy to hear of another method of doing it if this better. Now, do you want to know why I did an RFC? The discussion was going on here. At some point, the user stopped responding in the discussion. I asked about a possible way of proposing this to the community to get further feedback. The other party made a choice to stop communicating and suggested: "Archiving and moving on. I've explined my position, others have explained theirs and I'm not sure you're listening. I suggest you WP:DROPTHESTICK and move on". I made the choice to do an RFC based on this matter. WhisperToMe (talk) 04:09, 10 January 2014 (UTC) Yes, I'm aware. Might I suggest you let uninvolved editors chime in at this point? DonIago (talk) 04:12, 10 January 2014 (UTC) I would be happy to. WhisperToMe (talk) 04:18, 10 January 2014 (UTC) Oppose any addition of content, portals, categories, etc. that are not pertinent to the article. In fact, I see little advantage in having portals AND categories in articles as they can pretty much cover the same territory and give the same information on connected articles. Many articles, IMO, have for the last few years been getting clogged with major info-boxes, minor-info-boxes, templates, portals, categories, long lists of "See Also's"; external links, and more. Anybody who has edited here for a while knows this to be true. Call me an exclusionist, but sometimes enough is just enough. GenQuest "Talk to Me" 06:12, 10 January 2014 (UTC) Oppose These generic portals are a waste of time and add no value to the article. All these tags are found on the talkpage, and I see no value in an article having a link to a "film portal" or a "1980s portal". Spam under a different form. Lugnuts Dick Laurent is dead 08:41, 10 January 2014 (UTC) Oppose, as per all the very good reasons above. It's also overkill and stretching the point of the portal too far. I'll also add that this seems to be forum shopping by WhisperToMe. After receiving no consensus for the inclusion WP:IDHT-ish territory now. - SchroCat (talk ) 10:11, 10 January 2014 (UTC) Oppose The portal is not "topic relevant". WhisperToMe seems to want to treat portals like categories but I disagree with this approach since categories do this job just fine. Yes, Gone with the Wind is a great American film but the article itself is not actually on the subject of American film. I believe portals should follow the principle of all internal wikilinks in that they should inform the reader on the subject of the article. For example, it would be ok to include something like the Star Trek portal on the Star Trek articles because other Star Trek content informs the subject matter of the article. In the case of Gone with the Wind I don't see how other articles about the American film industry would be particularly relevant to a reader; other Gone with the Wind articles would be relevant and we do have {{Gone with the Wind}} for that purpose. I accept that portals have their place but they should be used judiciously. Linking to other material on Wikipedia should be focused and relevant, since over-facing a reader with too many links can be counter-productive in assisting them in finding the information they want. Betty Logan (talk) 12:54, 10 January 2014 (UTC) Guys, it would be really nice if especially those of you who are "uninvolved" would please post your views at the RFC that Betty suggested above. Please remember that the question at the RFC is about a specific portal being placed on a specific article, not about whether portals in general are spammy or a waste of time. And if you've been arguing with WTM about this for days or weeks now, would you please not post for a while, or if you really can't wait, could you post your views in the nicest, least confrontational manner possible you can manage? RFCs are usually open for about a month. It'd be nice if we could get views of completely uninvolved people, and we've proven many times here at the English Wikipedia that they won't respond if they think that people will yell at them. I've hatted the argument between two editors about whether some other film is truly "American", so I think the RFC has a chance, but you can really help by making a friendly space for outside editors to comment. WhatamIdoing (talk) 22:57, 10 January 2014 (UTC)