Wikipedia:Village pump (all)

From Wikipedia, the free encyclopedia
Jump to: navigation, search

This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.

Click here to purge the server cache of this page (to see recent changes on Village pump subpages)

Village pump sections

post | watch | search
To discuss existing and proposed policies

post | watch | search
To discuss technical issues. For wiki software bug reports, use Bugzilla

Dialog-information on.svg
post | watch | search
To discuss new proposals that are not policy-related. See also: perennial proposals and persistent proposals.

Dialog-information on.svgNuvola apps package development.png
Idea lab
post | watch | search
To discuss ideas before proposing them to the community and attempt to find solutions to issues

post | watch | search
To post messages that do not fit into any other category

View all village pump sections at once

It can only be speculated that, like the modern office water cooler, the village pump must have been a gathering place where dwellers discussed ideas for the improvement of their locale.
Other help and discussion locations
I want... Where to go using Wikipedia Help desk find my way around Wikipedia Department directory
...specific facts (e.g. Who was the first pope?) Reference desk
...constructive criticism from others for a specific article Peer review resolving a specific article edit dispute or making a user conduct dispute complaint  Requests for comment comment on a specific article Article's talk page view other Wikimedia projects Wikimedia Meta-wiki learn about citing Wikipedia in a bibliography Citing Wikipedia report sites that copy Wikipedia content Mirrors and forks ask questions or make comments Questions


Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).


WP:BRD as essay

As far as I can tell, there is pretty wide agreement that WP:BRD is a good thing, that things work a lot smoother when it's followed by all parties. Why, then, is it defined as only essay? When someone deviates from BRD in a contentious situation, and someone else calls him on it citing BRD, and he says, "Well, that's only an essay", what are the appropriate response and reaction to that? Do we have to go to talk just to establish consensus that BRD is to be followed? ‑‑Mandruss (talk) 15:51, 6 October 2014 (UTC)

WP:BRD is supposed to limit edit warring, but still encourage editors to be bold. As when you're bold, and it turns out to be good thing when it's discussed, it stays in the article. But if you're bold, reverted, and then you discuss it (WP:BRD), the real reason it was excluded begins to come to light and you attempt to convince the other editors that it would be beneficial to add to the article. Why it's not a policy or a guideline is because it has not passed a formal RfC to make it such. I'm not exactly sure of the process of adding a new rule or guideline, but I'm iffy on including it as a guideline or a policy. Just because of unforeseen circumstances and consequences which my mind seems to be missing atm. Tutelary (talk) 20:46, 6 October 2014 (UTC)
WP:BRD doesn't work very well for contentious content, while there is some ambiguity whether or not to discuss before reverting. If each contending party only comments on the talk page after reverting, well, what you get is a thinly veiled edit war (and WP:BRD has been used in defence of such practices). I'd deprecate WP:BRD rather than uplifting it to guideline. Also, there is a viable alternative, the flow chart pictured & explained in WP:CONSENSUS#Reaching consensus through editing. WP:BRD could be made a shortcut to that policy section.
Otherwise said, the current WP:BRD will not become more than a somewhat dubious essay, as long as its position w.r.t. consensus-seeking (or: its positive effect in the frame of Wikipedia:Dispute resolution) remains unclear. --Francis Schonken (talk) 11:13, 7 October 2014 (UTC)
Also, please read WP:PGE, and remember that BRD itself tells people that they shouldn't use BRD all the time. WhatamIdoing (talk) 18:40, 8 October 2014 (UTC)
Yes, WP:PGE is a good example of an environment that, in its desire to be flexible, seems designed to encourage counterproductive and self-defeating conflict. Aside from perhaps MOS matters, there isn't clear guidance on much of anything, the rules themselves are largely matters of opinion and interpretation. But I suspect I'm not the first person to have figured that out, so I'll leave it there. ‑‑Mandruss (talk) 11:26, 9 October 2014 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Here's why I believe BRD should become part of the edit warring policy.

  1. It helps to stop edit warring.
  2. It encourages discussion of controversial edits.
  3. It leads to establishing consensus.
  4. It establishes collaboration by stopping contentious solo editing.
  5. It's nearly always the only known method for figuring out exactly who started an edit war, and the exact diff for when it happened. (The edit which starts an edit war is well before 3RR.)

While it's good to write "follow BRD" in an edit summary, because BRD doesn't have the weight of policy it's often better to also write "don't edit war", because that is the consequence of the first violation of BRD.

It's spelled BRD, without exception, and it's that second B in a BRB sequence which is the first shot fired in an edit war, and that second B should not have happened. I have seen many admins wisely use this sequence of events to pinpoint the most guilty party in an edit war. They don't even have to cite BRD, but can with certainty say "You started an edit war here (diff), and you failed to edit collaboratively. That's very disruptive." Determining "who started it" does matter.

Sure, there are exceptional situations where BRD isn't perfect (the same applies to all our PAG), but it usually works as intended, and that's important enough to give it policy status. That's why I'd like to see it become part of the edit warring policy. -- Brangifer (talk) 14:56, 9 October 2014 (UTC)

And here's a list of reasons why we shouldn't:
  1. It discourages improvements to pages by favoring the status quo ante. The reverter's dislike of your changes is privileged over the good-faith contributions of the bold content creator. Change is bad.
  2. It encourages WP:OWNership by giving the reverter an unfair advantage: you can make a bold edit (or even a timid one), but if I revert it, then all subsequent edits by you (even if unrelated) will be thrown in your face as proof that you're "not following BRD". This is very handy if I want to make sure that nobody else gets to edit "my" article.
  3. It does not require the reverter to do anything except revert. As a bold editor, you can show up on the talk page, but there's nothing requiring the reverter to participate in discussions, to explain why I reverted you, or to be reasonable or collegial.
  4. It encourages needless discussions on talk pages instead of collaborative editing and efficient use of edit summaries. Example: Someone added a line, an editor made a good partial reversion, I reverted it for reasons that seemed good to me at the time, and my edit was re-reverted by someone who knew better than I. By my count, that's BRRR, with zero talk-page discussion, and definitely a good, efficient outcome.
  5. It leads to reverters claiming that bold editors are not allowed to make any other changes unless and until you can document "consensus" (defined as their personal agreement) on the talk page. This is very handy if I'm a POV pusher who thinks that the status quo ante is The Right Version™.
  6. It prevents collaboration by encouraging the second editor to revert instead of to offer their own bold adaptation of your edit.
  7. It's never necessary for figuring out who started an edit war, and often not useful. Look at the example above: I count it as BRRR, but you could also legitimately count that as BBRR, especially if you noticed the dates on those first two edits, which are more than two years apart.
  8. It assumes that there are only two editors. In fact, BRD explicitly encourages bold editors to focus on the objections of a single person instead of trying to please an entire group. My example shows four.
  9. Reverters don't read BRD. WP:Nobody reads the directions in general, but reverters, taken as a group, really don't seem to understand BRD. BRD is advice written for experienced editors who are trying to find a path forward when things are stuck. The steps are: make a bold edit, wait until someone objects, and then find out why that specific person objects before trying to edit again. Some reverters hear about BRD, never quite bother to read the page, and somehow conclude that BRD requires them to revert bold changes that haven't been discussed (even when they agree with the changes!).
I could go on, but I doubt that it's necessary. WhatamIdoing (talk) 18:05, 9 October 2014 (UTC)
Fine, if BRD is a bad thing, then an enormous part of the real-world community hasn't gotten the memo. If there is community consensus against BRD, then a big note needs to be added to the top of WP:BRD: This essay is contrary to community consensus. Please see X instead. Yes, you would think its mere-essay status would be enough, but it's clearly not. If community consensus does not exist, I can't think of anything more important than seeking one, as difficult as that may be. You can't allow alternate sets of laws to exist and expect a community to survive very long, let alone thrive. We must agree on the ground rules. ‑‑Mandruss (talk) 18:44, 9 October 2014 (UTC)
We do agree on the ground rules. The ground rules are in the policies WP:Editing policy and WP:Edit warring. BRD is merely one of many, often equally valuable, ways of complying with the actual policies. WhatamIdoing (talk) 19:16, 9 October 2014 (UTC)
I have to concur with Francis Schonken and WhatamIdoing on this. BRD is overrated, because it's too easily gameable to sugar-coat an editwar. It's been my experience that a large number of combative, PoV-pushing, WP:OWNish editors refuse to abide by it, when they're they one trying to make a controversial change, until essentially forced to by 4 or more editors shouting them down, while the same editwarrior will insist on BRD, and revertwar incessantly against changes they don't like, always declaring that not enough D has happened to satisfy them. BRD is too often a tool of, not against, strife.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  12:13, 14 October 2014 (UTC)
My point is that BRD is both widely used and widely contested, resulting in a ton of counterproductive conflict. WhatamIdoing asserts that we agree on the ground rules, but it's obvious enough that we as a community do not. You can say all day that those who misapply BRD are simply wrong, but that does very little to address the conflict. There must be clear community consensus on this, and that consensus must be made clear to all editors. The amount of conflict is all the evidence I need that the ground rules are insufficiently clear and inadequately communicated. I think a majority of editors will attempt to follow the ground rules as they understand them. ‑‑Mandruss (talk) 12:25, 14 October 2014 (UTC)
It can't be policy; policy is something that should always apply. Even a guideline is probably too strong. Quite simply, BRD is very good advice, but there's far too many exceptions for it to be given enforceability. Adam Cuerden (talk) 12:42, 14 October 2014 (UTC)
Mandruss, I'm not quite sure what problem you're thinking of. I tell you that we have two widely supported policies that lay out the ground rules for editing. You say that we don't agree on the ground rules. Exactly which rules (or non-rules) are we disagreeing about? Do you think some editors disagree with the WP:Editing policy? Do you think some editors mistakenly believe that WP:BRD is a policy? Which ground rules are unclear and/or uncommunicated? WhatamIdoing (talk) 17:42, 14 October 2014 (UTC)
  • The first sentence at [WP:Edit warring#What edit warring is] states, "Wikipedia encourages editors to be bold, but while a potentially controversial change may be made to find out whether it is opposed, another editor may revert it. This is known as the bold, revert, discuss (BRD) cycle."  Unscintillating (talk) 01:14, 19 October 2014 (UTC)
    • That sentence needs to be fixed. The "D" in BRD is not silent. Bold-Revert is not the same thing as Bold-Revert-Discuss. (Also, it might not be BRD at all; it might instead be Bold-Revert-Revert-Revert-Revert-Block, or Bold-Revert-Give up, or Bold-Revert-Timid, or several other patterns.) WhatamIdoing (talk) 01:00, 21 October 2014 (UTC)

WP:OR and Comparison of Foo articles

Wikipedia contains many articles of the style Comparison of Foo, where Foo may refer to (eg) a class of software, or a method of engineering. Many of these articles are broadly unreferenced. Almost always the features list when comparing Foo Vendor A's product with Foo Vendor B's product are entirely unreferenced. By definition these are WP:OR. They have come from research performed by the editors maintaining the articles. Often even primary sources are not offered. WP:PRIMARY suggests that this might be a valid place for them to be deployed.

I recall putting one such up for AfD once, or offering an opinion in such an AfD. I can't recall what or when. It was stoutly defended with arguments such as "But it's encyclopaedic!" not exactly policy based.

So, my question is, how does Wikipedia not apply a policy requiring no original research to obviously useful but broadly unreferenced Comparison of Foo articles? Why are they deemed to be acceptable by consensus when the No OR rule is created by consensus? Fiddle Faddle 23:02, 9 October 2014 (UTC)

Because sometimes the consensus is to follow our WP:Ignore all rules policy. Blueboar (talk) 16:32, 10 October 2014 (UTC)
I'm kind of late to the party, but a bot asked me to weigh in, and, basically, I have to strongly agree with Timtrent (Fiddle Faddle). Ignore all Rules is just recipe to add crap and do nonsense without any logical reason for doing so. It's the last refuge of people who know they shouldn't be doing something but emotionally want to anyway. Wikipedia should be better than that. There may be some comparison topics with solid reliable sources establishing notability. Otherwise they should be deleted outright, like any other article that fails to meet basic standards. DreamGuy (talk) 00:26, 22 October 2014 (UTC)
  • I think such articles should be strongly discouraged. They are usually very badly sourced, and full of original research and synthesis. They are also frequently thinly-veiled advertisements "Wowzerz! Product A can do foo, bar, and baz but Product B can't do any of those!" My opinion is that such articles need to be viewed very skeptically, and should only generally be allowed if there are substantial, neutral sources that explicitly compare those products. Reyk YO! 00:34, 22 October 2014 (UTC)
  • I don't know. Although useful, they probably should be discouraged somewhere if they are not verifiable and notable. Some of these topics are regularly covered in reliable sources, and articles that compare/contrast a range of competing products are fairly common in tech journalism. However, topics which receive no coverage probably should be nominated for deletion. If someone wanted to, they could probably write/rewrite some of these articles to paint an extreme POV, such as prominently highlighting multiple missing features in popular software products. This is definitely a problem, but I guess existing due weight concerns can alleviate it. That, of course, depends on the existence of coverage reliable sources, which is something that we have established may not exist for some of these articles. NinjaRobotPirate (talk) 18:22, 22 October 2014 (UTC)

Moves from Main to Draft: Namespace

I am perplexed by this. Take the following situation:

New user creates an obviously poor article in the main namespace, so poor that WP:AFC reviewers would have pushed it back for improvement instead of accepting it. It is an obvious failure, perhaps unreferenced WP:OR. Prior to the Draft: namespace existing it would be an obvious CSD candidate (if a relevant category existed) a PROD, or AFD.

A wise admin might well have userfied the material after/in place of deletion, but deleted the item form the main namespace

Now we have Draft: what are the rules?

  • May only admins move main namespace articles to Draft:
  • As a non admin, may I do it?
  • Under what circumstances may such a move take place? Must a discussion happen to empower the move? May it be done when it seems reasonable, or must we have a formal consensus each time?

When you examine this please look at it from the perspective of being a caretaker of Wikipedia's portfolio of articles, and then look at it as if you were that new user. Will your thoughts be different depending upon where you view it from?

What are the rules, here? Fiddle Faddle 09:45, 10 October 2014 (UTC)

Has the bad article been deleted?
If not, then simply improve the article (it sounds like a total re-write is in order).
If so, then I think the best option would be to act as if the previous (now deleted) article never existed... start over from scratch and create a completely new article that happens to be about the same topic as the failed (now deleted) one. I would suggest starting with a "draft" in user space - Work on that "draft" (to the point where you think it would survive an AfD challenge.)... and when you think it is ready for prime time, it can simply be copied over into main space.
The only question is what title to give the new article... If you want to use the same title as the failed (now deleted) article, you may need to ask an admin to "free up" the old title for use by your completely new article. Blueboar (talk) 12:19, 10 October 2014 (UTC)
@Blueboar: Your advice is sage, but I think I am asking a different question from the one you are answering. "The" article is a theoretical article, so does not exist as a specific example. Fiddle Faddle 12:44, 10 October 2014 (UTC)
My advice would stand even for a theoretical article.... how you deal with the issue of a poor quality article depends on whether the poor quality article has actually been deleted or not. If so, then the solution to is to start over and write a new reasonably good article on the topic. If not, then the best solution to a poor quatlity article is simply to fix whatever is wrong with it.
If, on the other hand, a deletion is pending (ie the article has been nominated for deletion, but has not yet been deleted) then we have a choice... we can either 1) simply let it be deleted... 2) keep and try to fix it in place ... 3) userfy and let the article creator try to improve it... or 4) move it to draft space in the hope that multiple editors will be able to improve it. Which of these options is the most appropriate, however, depends on the specific article. Blueboar (talk) 13:18, 10 October 2014 (UTC)
  • The instruction you want is at WP:Drafts#Incubation, "* Articles are incubated as a result of i) a deletion discussion, ii) an undeletion request, iii) userification, or iv) a bold move from article space."  Like other bold edits, other editors may have differing opinions.  Unscintillating (talk) 00:22, 19 October 2014 (UTC)

Reform for Wikipedia

There is an ongoing discussion over at User talk:Jimbo Wales#WP needs to evolve that involves a proposal to revamp policies already put into place.

Proposal 1

I will quote Ihardlythinkso here:

"For God's sake, the solution is obvious. (Jimbo, I plead you, for inspiration watch: Star Trek: The Motion Picture!) WP needs to evolve. Said evolution will solve all these bickering, "unsolvable" problems. (It means radical restructuring. What restructuring? I don't know, but there are 10 editors who do: The top 10 content contributors, elected by the WP community. [Put them to work. Want to "reform" Eric? {I don't believe he needs reformation, but let's assume.} Then put him with nine other top content contributors, to restructure how WP operates to maintain and grow articles. They will work it out, they can't do otherwise. They have too much devoted already, too much love of this project, to possibly do any harm. Now Jimbo, I know you like to retain "The encyclopedia anyone can edit" slogan. That's political/marketing/guidance that is good. Let's make it a condition that the panel of top 10 content writers, retain that basic premise. {Hello, they might decide that anyone can edit/create articles, save FA articles. But then the "anyone can edit" still holds essentially, doesn't it!?} The top 10 content writers know what the problems are -- all of them -- and they know what the solutions are. Let them work it out. Give them the responsibility. That is what this project is about {quality articles, maintenance & develeopment}. The consensus model is maintained by election of top 10 content contributors -- just like Arbcom is elected today.])

This is the solution. It is appropriate, and guarantees a bright future. There is no chance for failure with it. Just the courage to restructure, rather than suffer the countless problems exacerbated by the current structure. (E.g., suggestions that Eric is a great content contributor but "just cannot control himself" is bogus and absurd. The fact is, he's enormously capable and intelligent, and is simply responding to the current dysfunctional structure full of flaws and hypocrisies. Put him to work with other top writers to solve/evolve out of the current conundrums. Given time/discussion such a team will work it out. Elect 15 so there are 5 backups if RL considerations cause any of the elected 10 must drop out. Not all top content contributors will want to offer their services {they may just want to continue to devote themselves to writing}, but many probably will, since their investments to-date dictate instinctive perservation of all the good that has been wrought from the wonderful seed of idea to make a comprehensive encyclopedia free to the world. {I suggest too, to get Neil deGrasse Tyson as spokesperson-partner for the ongoing efforts of everyone. I'm sure he will agree to do, free-of-charge, happily! <Because he is a good man, with eye on the future.>}]) Sincere"

Proposal 2

From Wnt:

  • Set up a random jury system for deciding "verdicts" in "judicial" matters, rather than relying on the impartiality of arbitrators/admins. That way they can stick to interpreting the rules narrowly, and the impartiality of decisions is clearer, or at least randomer. (Further information)
  • Set up a work-based path to adminship, no votes and politics. You put in the effort and do (a), (b), (c), (d) without getting "convicted" of some sort of misconduct, you are qualified as a good enough editor all-around to do adminly tasks. Setting up some a la carte admin privileges ("unbundling") can be part of this.
  • Remove every invocation of "editorial discretion" from policy. Editorial discretion doesn't make sense in an environment anyone can edit - it's like a flag in a video game. As long as there are flags, people fight for them; as long as editors are encouraged to use broad latitude to exclude information based on discretion, rather than clear policy guidance, they will fight over whose POV commands the gray area. Policy should be simple and focus on the basics of verifying the facts and handling them neutrally.
  • Do not encourage templating. No one should have an expectation or duty to read and comprehend a message that a human being didn't take the time to write personally to him. Much of the incivil attitude on Wikipedia doesn't actually originate from human beings; it is people echoing and reechoing attitudes that ultimately began, one way or another, in a machine.

Seeing this would involve all of Wikipedia I figured I would bring this to the community's attention for some input on the matter. - Knowledgekid87 (talk) 20:47, 16 October 2014 (UTC)

Ihardlythinkso's suggestion seems contradictory - is he saying we should select people because they are the 'top ten content producers' (defined how?), or we should elect people, and define them as a 'top ten content producer'? Are they elected, or appointed because they meet some predefined criteria?
And as for randomly appointed 'juries', how are they to be selected? At random from everyone who has ever contributed to Wikipedia? And what happens if someone doesn't wish to serve on a 'jury'?
As for removing editorial discretion, that has to be about the most brainless suggestion I've ever seen proposed - we use discretion all the time, and it is actually impossible to write intelligible prose without doing so. If content is to be based on nothing but rules, we might as well remove the human element entirely, and get the bots to write the articles. AndyTheGrump (talk) 22:04, 16 October 2014 (UTC)
@Andy, no contradiction, by "top 10" I mean based on content contribution considerations -- quality, quantity, experience, collaboration. (People already have their favorites. E.g. many admire Eric due to his high level of all these: research, writing, editing, number of FAs/GAs, helping others & collaborating to take articles thru FAR/GAR.) Arbcom members are (presumably) elected on their qualities to fairly/wisely weigh/resolve intractable disputes according to policy. This would be different, election based on content considerations. Ok, Ihardlythinkso (talk) 01:56, 17 October 2014 (UTC)
If you have an election, people will vote based on what they personally consider relevant, and not on predefined 'considerations'. That's how voting works... AndyTheGrump (talk) 02:06, 17 October 2014 (UTC)
I've added a link to some detail I came up with about the jury system before. Wnt (talk) 02:24, 17 October 2014 (UTC)
@Andy, of course. (I never thought different.) But I don't know you you're meaning to imply something!? (Arbcom elections seem to work, with !votes cast on what they personally consideer relevant, too. Just in this case the elected would be given responsibility to restructure WP operations via 10-member team consensus.) Ihardlythinkso (talk) 10:40, 17 October 2014 (UTC)
I'm not implying anything other than that you seem to be suggesting that people would vote for certain individuals based on specific criteria, and furthermore that if they did so, a certain named individual would be amongst those elected - and that his election would result in a specific outcome, which you see as desirable and therefore good grounds for having the election. To my mind, that is questionable logic. Personally, if there were to be an election held to select a team responsible for 'restructuring WP operations', I would expect candidates to state in advance what their proposed 'restructuring' would entail, and vote accordingly. Though why such an election would be required at all is open to debate, since we could vote on proposals directly. What exactly is the objection to this? And why do we need to elect individuals at all? It is entirely open to anyone (top-ten content contributor or otherwise) to make proposals regarding reform right now, for the community to decide upon. If there is support for 'restructuring', then the community itself should decide what form that 'restructuring' should take. AndyTheGrump (talk) 16:06, 17 October 2014 (UTC)
Speaking of unbundling, unbundle this. There is too much change here to sell as a package, so pick one piece that is most likely to sell, and sell it. I would buy the admin selection reform, but it would have to be done without grandfathering, meaning a lot of resistance from admins who wouldn't make admin under the new system. ‑‑Mandruss (talk) 22:39, 16 October 2014 (UTC)
Done I have made two subsections. - Knowledgekid87 (talk) 23:01, 16 October 2014 (UTC)
I've taken the liberty of restoring formatting to my quote above. These were in fact four separate ideas, not needing to be taken as a package. Wnt (talk) 02:15, 17 October 2014 (UTC)
Okay no problem ,and it looks like you are getting feedback here which is a good start =) - Knowledgekid87 (talk) 02:16, 17 October 2014 (UTC)
I don't see how we can have a comprehensible discussion of four proposals in one subsection. It's hard enough with one. ‑‑Mandruss (talk) 02:25, 17 October 2014 (UTC)
If @Wnt: wants to split them up then feel free, I am curious on what the community feels about the ideas and would like to get this ball rolling. - Knowledgekid87 (talk) 02:29, 17 October 2014 (UTC)

when is it acceptable to remove 'external links' warning?

There is an 'external links' warning posted on the top of this article. It has been there since 2012, but the article has long since been cleaned up.

Is it acceptable to remove the warning now, or does a wiki bot or a certain person need to remove it?

Spinlock55 (talk) 23:20, 16 October 2014 (UTC)

@Spinlock55: If you think a notice no longer applies, feel free to remove it. --NeilN talk to me 23:24, 16 October 2014 (UTC)

@NeilN Thanks for the feedback.Spinlock55 (talk) 23:32, 16 October 2014 (UTC)

narrow vision

search for background on a non profit organization ISIS only led to an article with funny links ... if your idea of ISIS is so important to you give it a bold link but dont leave out information which might mean something to others too ... this has definitely changed my view about WIKI in general ... thanks for this eye opener ... — Preceding unsigned comment added by (talk) 05:26, 17 October 2014 (UTC)

Which ISIS non-profit are you looking for? There are multiple non-profit organizations known by the acronym ISIS, you can see some of them at Isis (disambiguation), so I'm not sure which non-profit to direct you to. Can you give us more information about which one you are looking for? Do you remember what it's un-abbreviated name was? --Jayron32 00:56, 19 October 2014 (UTC)
It is true that some degradative assumptions in the structure have created a mess here. We redirect ISIS and ISIL to one page, which necessarily has a more confusing hatnote, which redirects people to Isis (disambiguation), where upper and lower case are confounded. Also, "disambiguation" is not exactly basic vocabulary, and I admit some skepticism as to whether it even counts as an English word, making that navigation more difficult. Conceivably we could have some technical solution, like making ISIS not a redirect but a page that transcludes Islamic State of Iraq and the Levant after an ISIS-specific hatnote, going to an ISIS-specific disambiguation page that doesn't contain, or only transcludes at the end, the Isis disambiguation. Wnt (talk) 18:15, 20 October 2014 (UTC)
Google Dictionary, Merriam-Webster, and think it's an English word. That usually has to suffice for me, as I don't have a copy of the OED. ‑‑Mandruss (t) 19:16, 20 October 2014 (UTC)
Good research; still, the latter two trace its origin to around 1963, which puts it kind of on the same level as "grody" and "twerking". I bet some people look at that jargon and don't even have a thought to what it means. Wnt (talk) 19:58, 20 October 2014 (UTC)
"McCarthyism" dates to 1950, which puts it kind of on the same level as "cool it" and "back seat bingo". ‑‑Mandruss (t) 21:05, 20 October 2014 (UTC)
Most people looking for "ISIS" right now porobably do want the article on Islamic State of Iraq and the Levant (it's been one of the top 25 loaded Wikipedia articles for a while now); anyone who wants something else can follow the link at the top of the page to the relevant disambiguation page, where what they are looking for can be found (if we have an article about it). עוד מישהו Od Mishehu 13:19, 22 October 2014 (UTC)


Watchlist option when moving pages

When moving a page, one has an option to tick or untick the "Watch source page and target page" box. However, more often than not, I am finding myself in need of watching only the target (i.e., where the article is being moved to) but not the source (which will become a simple redirect). Is there a technical reason why the source and the target can't be unbundled into separate boxes? It's somewhat annoying to have to go through an extra step of going back and watching the target (if the box was not checked during the move) or unwatching the redirect (if the box was checked). Surely I'm not the only one feeling so?—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); October 17, 2014; 14:03 (UTC)

Watchlists can have thousands of entries and redirects are rarely edited so I don't see a problem in adding the redirect to the watchlist. Maybe some users would like the option but it doesn't seem significant enough to clutter the interface and ask for developer work. Note that if others move a page on your watchlist then the new title is also added to the watchlist without removing the old title. PrimeHunter (talk) 15:49, 17 October 2014 (UTC)
I have no problem with the old title being kept on my watchlist when others move a page—in this case retaining the redirect in the watchlist actually helps see that the article has been moved, especially if consequent edits are done to the target before the move is seen on the watchlist. But keeping unnecessary (to me) records of redirects on my already overly long watchlist does not seem to be useful at all. If I kept every such redirect, my watchlist would not be just difficult to edit (as it is now, with 14,000+ entries and counting), but extremely so (I did have browsers on older PCs crash and hang when trying to open my watchlist in edit mode). And just how much of developers' time would splitting the option in two take, anyway? Ten, fifteen minutes? :) And if both options ("watch source", "watch destination" are placed on the same line, the cluttering is going to be minimal. Come to think of it, the "leave a redirect behind" seems a lot less useful than what I'm proposing. Yes, occasionally there is a need to suppress the creation of a redirect when moving a page, but does that really happen so often we need a separate option for that? Anyone else cares to chime in?—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); October 17, 2014; 17:11 (UTC)
"leave a redirect behind" is only seen by admins. I often use either option there. Non-admins only have one checkbox on the move form. Many of them may not realize that anyone can change the redirect, and watching the source will inform them of such changes. PrimeHunter (talk) 17:35, 17 October 2014 (UTC)
The ability to suppress redirects by unchecking the "leave a redirect behind" box makes some history merges and swaps much much easier, and I would vociferously object to the removal of that check box. Graham87 08:52, 18 October 2014 (UTC)
Well, OK, I'm not here to advocate the removal of that box; it's just something that came up during the discussion (I personally don't care either way). Any opinions on the proposed split of the "Watch source page and target page" box, though?—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); October 21, 2014; 20:09 (UTC)

Error when searching for template "a"

This query results in the error message "An error has occurred while searching: The search backend returned an error:". Other single-letter templates are found just fine, maybe someone should take a look at this. Paradoctor (talk) 08:56, 18 October 2014 (UTC)

When that happens, I try to get to the bare URL, as in – Paine Ellsworth CLIMAX! 14:31, 18 October 2014 (UTC)
It works when I enable "New search" at Special:Preferences#mw-prefsection-betafeatures. I think New search is planned to become the default or only search and there is limited interest in using resources on fixing such problems with the old search. PrimeHunter (talk) 14:39, 18 October 2014 (UTC)
No sweat, it's just something I noticed and thought might be of interest. Paradoctor (talk) 17:45, 18 October 2014 (UTC)

Xtools / edit counter

Does anyone here know the status of the Xtools edit counter? I have been unable to access the tool for several days, and this does not appear to be one of the usual temporary service interruptions. Does anyone know anything about this? Dirtlawyer1 (talk) 14:12, 18 October 2014 (UTC)

All Xtools have been down for some days. See #Wikimedia Tool Labs and bugzilla:72104. PrimeHunter (talk) 14:18, 18 October 2014 (UTC)
I have mentioned it's down in the interface message Template:Sp-contributions-footer.[1] I did the same yesterday for MediaWiki:Histlegend.[2] PrimeHunter (talk) 14:27, 18 October 2014 (UTC)
If you go to the Github report you see: "Labels: None! No milestones! Nobody assigned!" The Bugzilla thread is equally discouraging: "Unprioritized! Assigned to nobody!" Except for Wikiviewstats, trying to use any of these tools does not even produce an error message, just a blank screen endlessly showing "Waiting for". (See the thread above, "Wikimedia Tool Labs", for some of the problems caused for users). Well I think this is not good enough for a facility used by many thousands. How do we jog Wikimedia to get going and resolve this?: Noyster (talk), 08:43, 19 October 2014 (UTC)
@Dirtlawyer1, PrimeHunter, Noyster: Looks like the counter is operational again. GoingBatty (talk) 15:16, 19 October 2014 (UTC)
Great! I have removed the down messages from Template:Sp-contributions-footer and MediaWiki:Histlegend after testing the three linked xtools. PrimeHunter (talk) 16:14, 19 October 2014 (UTC)

@GoingBatty: I'm a writer/editor, not a wiki-coder tech guy. When there are problems with X tools (or other Wikimedia Lab Tools), where is the appropriate interface to go with questions? Once upon a time, we could go to X!'s talk page . . . . Dirtlawyer1 (talk) 15:29, 19 October 2014 (UTC)

@Dirtlawyer1: This page seemed to work pretty well for you. GoingBatty (talk) 15:38, 19 October 2014 (UTC)
  • (edit conflict) For X! tools, there are a few maintainers... The best ways to do it is post the issue on bugzilla (phabricator soon replacing this), on github (here), or ask a maintainer: Cyberpower678, Hedonil and Tparis (may be more, not sure). — {{U|Technical 13}} (etc) 15:41, 19 October 2014 (UTC)
  • One more question: pardon my ignorance, but what is the relationship of Phabricator and Bugzilla to Wikimedia Labs? I don't wander outside of English Wikipedia or Wikimedia Commons very often, so all of these support groups are a bit of a mystery to me. Dirtlawyer1 (talk) 15:53, 19 October 2014 (UTC)
Bugzilla is the old system for reporting bugs (including feature requests and random ideas). Phabricator is the soon-to-be new system for reporting bugs and also lots of other things that could be done in Bugzilla, but which Bugzilla is not exactly very convenient for, like figuring out what's going on or planning projects. In the old (aka current) system, you find a problem on wiki, you report it at Bugzilla, some (volunteer or staff) dev decides to fix it, the dev's code goes to Gerritt, and then (with luck, assuming that the rather picky Jenkins bot doesn't reject your code, etc.) it somehow shows up in the MediaWiki software that we're using. Bugzilla is going to "go away" Any Day Now™, meaning probably within the next few weeks. Unless it doesn't.
WMF Labs is the replacement for Toolserver. It's a place to put useful or interesting stuff that people are using. NB that people specify "WMF Labs" to prevent confusion with "Beta Labs", which is a test wiki. will take you to a partial copy of the English Wikipedia, where you can see what some of the devs have broken this week are working on right now. Whatamidoing (WMF) (talk) 00:37, 21 October 2014 (UTC)
The replacement for Toolserver is specifically Tool Labs; Wikimedia Labs is the larger project that Beta Labs, Tool Labs, and a large number of other non-production services and test servers are a part of. Anomie 11:43, 21 October 2014 (UTC)
  • Well, perhaps this is the problem: TParis has lost access to their account, Cyberpower687 has been on WikiBreak for two months, and Hedonil hasn't made an edit since 20 August. I guess this won't get fixed any time soon. Curly Turkey ⚞¡gobble!⚟ 06:18, 23 October 2014 (UTC)
  • Well someone has gotten my attention about this issue, so I will be taking a look over the next few days. ALSO IT IS IMPORTANT TO NOTE THAT GITHUB IS THE BEST PLACE TO REPORT BUGS AS IT IS THEE WE CAN MOST EASILY KEEP TRACK OF THE BUGS. I am no way shouting, but making trying to make that statement standout for future bug reports.—cyberpower Temporarily OnlineTrick or Treat 11:48, 23 October 2014 (UTC)
  • {{fixed))—cyberpower Temporarily OnlineTrick or Treat 14:04, 23 October 2014 (UTC)


Can anybody work out what the "-2" in Template:FeaturedTopicSum is for? I've been trying to convert this template to Lua at Module:FeaturedTopicSum, because it will be used in Module:Article history, but I can't work out why the current template code is the way it is. The template takes a topic name as {{{1}}}, returns {{{2}}} if the topic is a featured topic, and returns {{{3}}} otherwise. Now, one of the featured topic criteria is that 50% or more of the articles in the topic are featured articles. This criterion is translated into the following template code:

{{#ifexpr:{{PAGESINCATEGORY:Wikipedia featured topics {{{1}}} featured content}} >= ({{PAGESINCATEGORY:Wikipedia featured topics {{{1}}}}} + {{PAGESINCATEGORY:Wikipedia featured topics {{{1}}} good content}}-2)

For a figure of 50% or more, I would expect the calculation to be "featured >= good + other", not "featured >= good + other - 2". Am I missing something here? — Mr. Stradivarius ♪ talk ♪ 18:11, 18 October 2014 (UTC)

Also, I should leave a ping for User:Ucucha, who made the most recent edit to the template. — Mr. Stradivarius ♪ talk ♪ 18:12, 18 October 2014 (UTC)

My guess: "Wikipedia featured topics ... good content" and "Wikipedia featured topics ... featured content" are subcategories of "Wikipedia featured topics ...", so subtracting two from the {{PAGESINCATEGORY:Wikipedia featured topics {{{1}}}}} term ensures that these subcategories are not included in the article count. SiBr4 (talk) 18:49, 18 October 2014 (UTC)
(edit conflict) It appears the reason for this adjustment is that the page:
  • Category:Wikipedia featured topics *
contains both category pages:
  • Wikipedia featured topics * featured content
  • Wikipedia featured topics * good content
I expect the "-2" is to adjust for this inclusion. A quick look at the first category in the list shows:
— Makyen (talk) 19:12, 18 October 2014 (UTC)
Indeed, see mw:PAGESINCATEGORY. An alternative would be to use {{PAGESINCATEGORY:Wikipedia featured topics {{{1}}}|pages}}, which doesn't count subcategories. — HHHIPPO 19:19, 18 October 2014 (UTC)
Aha, that makes sense. I was getting messed up because the equivalent code in Lua doesn't count subcategories. (Or more accurately, you can specify whether you want it to count pages, subpages, files, or all three.) Thanks, everyone. — Mr. Stradivarius ♪ talk ♪ 19:50, 18 October 2014 (UTC)
And looking at the PAGESINCATEGORY docs, I see that the parser function works that way as well. The option to specify pages only came in MediaWiki 1.20, though, which would be why the template didn't use it. The last update to the template was in 2010, and 1.20 was released in 2012. — Mr. Stradivarius ♪ talk ♪ 19:57, 18 October 2014 (UTC)

Creation of the "Special talk:" namespace

Template:CoNo to speedily insert <code><nowiki>...</nowiki><code> markup

For your coding pleasure, try out {{subst:CoNo|1=your code here}}.

This has been a bit of a wiki-Grail of mine for years, because I hate manually typing out "<code><nowiki>...</nowiki><code>" all the time. {{CoNo}} stands on the shoulders of the giant Zenexer, whose {{Nowiki}} finally makes this work.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  23:30, 18 October 2014 (UTC)

Glad to see my coding hacks put to good use! I wish I could remember who taught me the trick that I used, but it was a long time ago. —Zenexer [talk] 00:07, 19 October 2014 (UTC)
Not to take anything away from anyone here but isn't simple stuff like this the reason User:s can add there own toolbar of useful/repetitive "inserts" using the CharInsert gadget via one's common.js file? Once in place there is no need to type anything - just highlight the target text and select the tags from your custom menu of stuff.

For example; if you add the following to your common.js file....

/* CharInsert specific */
window.charinsertDontMove = false;
window.editToolsRecall = true;
window.charinsertCustom = { User: ' |  =  {\{+}}  [\[+|]]  —  Æ  æ  Œ  œ  <code><nowiki>+</nowiki></code>  {\{ping|+}}' };
if(window.updateEditTools) window.updateEditTools();
... A new menu labeled "User" containing your custom inserts will appear in the menu of CharInsert (EditTools). Hope that made sense -- George Orwell III (talk) 00:38, 19 October 2014 (UTC)
There is a suggestion at MediaWiki talk:Edittools#Individual customization? to add it for everybody like meta already does. PrimeHunter (talk) 00:47, 19 October 2014 (UTC)
This doesn't actually work. For example, {{subst:CoNo|~~~~}} generates a nowiki'd version of my signature wrapped in <code> tags, rather than 4 ~s. For this functionality to work, it would have to be done in JavaScript in the edit window, rather than in the parser. Jackmcbarn (talk) 03:27, 19 October 2014 (UTC)
Inserting <code><nowiki></nowiki></code> can already be done - but in two clicks, not one. Make sure the dropdown menu below the edit box set to "Wiki markup" rather than "Insert"; I never leave mine on "Insert", because everything in there is also available in "Wiki markup". --Redrose64 (talk) 07:30, 19 October 2014 (UTC)
Some of our sister projects have a single button for this; could we not do so also? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:35, 19 October 2014 (UTC)
Ideally, would this be <kbd> or <code> tags in most cases? WhatamIdoing (talk) 00:46, 21 October 2014 (UTC)

Login problems on IE9 Vista

I'm currently having problems logging into my account using Internet Explorer 9 on Windows Vista. I'm having no problems using this wiki when not logged in, but when attempting to log in, I get a "Internet Explorer cannot display the webpage" error; any attempt to refresh quickly regenerates the error screen, as if it's not even trying to load the login screen. I really prefer to be logged into my account whenever possible, so it is possible to do something about this issue? Thanks. -- (talk) 00:09, 19 October 2014 (UTC)

Found out what was wrong. I didn't have a specific value turned on--I had "Use TLS 1.0" off when it should have been on ("Use SSL 2.0" and "Use SSL 3.0" were already on, anybody else who's going through what I went through might want to check those as well). Shouldn't have a problem logging on now...-- (talk) 06:10, 19 October 2014 (UTC)
You were using SSL 3.0? See #SSL 3.0 discontinued, above. ~ J. Johnson (JJ) (talk) 20:44, 19 October 2014 (UTC)

Custom CSS

"Code that you insert on this page could contain malicious content capable of compromising your account. If you are unsure whether code you are adding to this page is safe, you can ask at the appropriate . The code will be executed when previewing this page."

This is shown when I preview the CSS page. "you can ask at the appropriate ." seems to be unintended and something is missing. I post here to make you aware of it in case you want to change it. Iceblock (talk) 01:06, 19 October 2014 (UTC)

I see MediaWiki:Jswarning which says "Code that you insert on this page could contain malicious content capable of compromising your account. If you are unsure whether code you are adding to this page is safe, you can ask at the appropriate village pump". The text "village pump" is a link to this page, but it displays bold here instead because it's a link to the page itself. Are you sure you have nothing after "appropriate"? If you see a large space but cannot make out any text then it may be a textcolor versus background color problem on your computer. Try holding your mouse over the space. And did you copy-paste the text with your browser or retype it manually? PrimeHunter (talk) 01:24, 19 October 2014 (UTC)
Thanks for your reply! It's my fault, it was hidden because of some settings on my computer. I have resolved it. Iceblock (talk) 01:43, 19 October 2014 (UTC)

Checking custom tables of contents

Does anybody know of an automated or partially automated way to check the accuracy of the table of contents on pages like List of birds of French Guiana? I've been checking them by clicking on each heading to see if it has a target, then generating a normal table of contents and visually comparing it to the list to see if any headings have been missed. It is tedious and there are hundreds of articles in the series List of birds of ... which I'm hoping to clean up. SchreiberBike talk 03:40, 19 October 2014 (UTC)

Page in "edit" mode is broken

Page in "edit" mode is broken, left side navigation bar is pushed down, no WP logo. --TitoDutta 23:22, 19 October 2014 (UTC) Here is a screenshot (use "zoom") --TitoDutta 23:27, 19 October 2014 (UTC)

Have you tried to clear your entire cache? PrimeHunter (talk) 02:52, 20 October 2014 (UTC)

Creating a Help article

I would like to create an article named Help:Automatically generated reference list, and copy into it the information in this draft page, per the discussion at Help talk:Footnotes. But whenever I search for the not-yet-existing new page, I get "An error has occurred while searching: The search backend returned an error:". Does creating a page in the Help namespace require some kind of administrator privileges? – Margin1522 (talk) 02:32, 20 October 2014 (UTC)

@Margin1522: Nope, this looks like a search bug rather than a page creation bug. If you click on the link you've made above you should be able to create the page. — Mr. Stradivarius ♪ talk ♪ 02:47, 20 October 2014 (UTC)
Yes, this has unfortunately become a common error for the default search engine. At Special:Preferences#mw-prefsection-betafeatures you can choose "New search" which doesn't have the problem. Clicking the red link also works fine. PrimeHunter (talk) 02:50, 20 October 2014 (UTC)
Success! Thank you both very much. Now I will go and select the new search engine. – Margin1522 (talk) 03:10, 20 October 2014 (UTC)
Another time, it would be more appropriate to WP:MOVE the draft to the new location. Doing so preserves the edit history, which is what is used to attribute the work and comply with the licensing model which Wikipedia uses. Even though it is (mostly) your work (there is one edit of the draft by BattyBot), preserving the edit history is one of the things that demonstrates that it is the work of the people credited in the history. Having a history that shows the development of the content is much stronger than having a fully formed version appearing in a first edit. — Makyen (talk) 06:05, 20 October 2014 (UTC)
Actually most of the content on that page was developed on the Help:Footnotes page. I just expanded it a bit and added some formatting and examples. I should have mentioned that in the edit summary. Now that you've reminded me, I will mention it on the Talk page of the new article. (The rest of the history on the draft page, including BattyBot, is for a completely different article, Bettina von Zwehl, which is why I copied it instead of moving it.) – Margin1522 (talk) 07:58, 20 October 2014 (UTC)
@Margin1522: If you made the new page by copying text from another page, WP:SPLIT applies and attribution is still required. --Redrose64 (talk) 15:13, 20 October 2014 (UTC)
Thanks. There was a template {{Copied}}, so I added that. Essentially it duplicated information already on the talk page, but if there is a standard format it's better that way. – Margin1522 (talk) 22:05, 20 October 2014 (UTC)

Tech News: 2014-43

13:48, 20 October 2014 (UTC)

Duplicate parameters

The tracking category will be set by MediaWiki:Duplicate-args-category and defaults to Category:Pages using duplicate arguments in template calls. Duplicate parameters will only put the page into the tracking category. It will not mark the specific template, so it will take some digging to figure out the duplicates. --  Gadget850 talk 01:08, 21 October 2014 (UTC)

Also, the report uses the present tense, but actually this feature isn't yet active on enwiki. It should start working on 23 October. — Mr. Stradivarius ♪ talk ♪ 02:00, 21 October 2014 (UTC)

External link CAPTCHA, PMID, and protocol-relative URL

If an anonymous editor adds an external link to a page, a CAPTCHA interface is normally triggered, this is to protect against spambots. In 2012, I suggested a whitelist for links that are never going to be used for spam. This was implemented in 2013, and is at MediaWiki:Captcha-addurl-whitelist.

One of the items on the list is, which houses PubMed, and is linked to in Template:Cite journal when a PMID number is provided, and in Template:PMID. In the latter template (and I assume in the former as well), the link is in protocol-relative form, i.e. like so: // For me, this triggers the CAPTCHA interface, whereas does not. Is there any way to allow protocol-relative URLs in the whitelist? Or can anyone think of another way of remedying this in the templates? (talk) 15:36, 20 October 2014 (UTC)

This is a bug in mw:Extension:ConfirmEdit, and is being tracked as bugzilla:61556. I don't see any activity at the bug page since it was filed back in February. — Mr. Stradivarius ♪ talk ♪ 16:05, 21 October 2014 (UTC)
Thanks, Since there is seemingly no interest in fixing the bug, should the templates be changed? Is the benefit in using protocol-relative URLs in these templates such that using it would be the lesser of the two evils? (talk) 16:33, 21 October 2014 (UTC)
It would be better to fix the bug, I think. All it takes is for one person to submit a patch (and for another person to review it and commit it to the repository). Any PHP coders in the house? :) — Mr. Stradivarius ♪ talk ♪ 16:46, 21 October 2014 (UTC)
I submitted gerrit:168074 to fix this. We definitely should not break external SSL for all our readers just to save new editors a little bit of hassle in the meantime. Jackmcbarn (talk) 14:14, 22 October 2014 (UTC)

I'm signed in/I'm not signed in

On a computer with Firefox, for the past several months, if I accessed Wikipedia from a search engine after signing in, it would appear that I was not signed in (and my skin would be different). If I remained on Wikipedia after signing in and searched for the appropriate article there, I remained signed in. Another option was to use a link from an email containing "https:", which is not found in the URL of an article accessed from a search engine. Inserting "https://" before "en" fixed the problem. Now, the problem appears to have been fixed, although for some strange reason at home, where I have IE9, this happened to me once and I don't remember what I did. I actually never use search engines at home.— Vchimpanzee • talk • contributions • 21:50, 20 October 2014 (UTC)

Edits cannot be made to Sankar Chakraborti


OTRS agent here, and was trying to make changes to the above article, but I definitely cannot edit it for some reason. While I can enter the edit window (edit source), I cannot submit changes. The button appears, but clicking on it yields no response. Any reason why this might be the case? I, JethroBT drop me a line 00:04, 21 October 2014 (UTC)

It works fine for me. AndyTheGrump (talk) 00:09, 21 October 2014 (UTC)
Also works for me. JethroBT posted more at Wikipedia:Administrators' noticeboard#Editing and other functions disabled at Sankar Chakraborti. A tested null edit in Monobook gave me no problems. There are only three transcluded pages beyond those used in {{notability}}. Have you tried to clear your entire cache? PrimeHunter (talk) 00:55, 21 October 2014 (UTC)
Works fine for me too. If you still have problems after clearing your cache, could you please specify if you can edit other articles? Thanks! GoingBatty (talk) 01:08, 21 October 2014 (UTC)
Clearing the cache worked, thanks. I, JethroBT drop me a line 01:49, 21 October 2014 (UTC)

Extracting PMIDs

Hi folks, relaying a question from a Stanford Medical researcher:

"Do you know if it is possible to extract [all] PubMed ID (PMID) or PMCIDs from Wiki references? Furthermore, could you dump those IDs out into a list for analysis?"

Thanks, Jake Ocaasi t | c 03:53, 21 October 2014 (UTC)

Hey Ocaasi. Seems like an easy job. Can you give me a few examples of PMIDs in articles and talk to me about the form they take (e.g. always a 25 digit number -- or something like that)? --EpochFail (talkcontribs) 22:37, 21 October 2014 (UTC)
After a bit of searching around, it looks like they can be extracted with a regex pretty nicely. E.g. /\bpmid *= *[0-9]+\b/i Does that seem right? --EpochFail (talkcontribs) 22:42, 21 October 2014 (UTC)
@EpochFail: I don't know regex but something like that should work. We'd want to know which PMIDs came from which article ideally. And then we'd need to dump it all in a list. Any idea what the workflow/toolset needed for something like this would be? Thanks and cheers, Ocaasi t | c 02:41, 22 October 2014 (UTC)
Yes check.svg Done I've finished a crawl over the XML dumps for 2014-10-08. You can find it here: It includes page_id, page_namespace, page_title, rev_id (most recent), pmid in TAB separated values. --EpochFail (talkcontribs) 12:24, 22 October 2014 (UTC)
edit Fixed the link to the dataset. --EpochFail (talkcontribs) 13:44, 22 October 2014 (UTC)
User:EpochFail, can you combine that with a list to the ones that use URLs in the format, or to PubMedCentral pages? There are multiple ways to link these papers. WhatamIdoing (talk) 21:26, 22 October 2014 (UTC)
Hey WhatamIdoing. Just so that I understand, are you asking me to also extract PMIDs that appear in certain types of URLs? If that's right, I'd be happy to, but I'd request that someone else do the digging for the different URL structures. I can update the regular expressions as necessary so long as I have examples. --EpochFail (talkcontribs) 12:43, 23 October 2014 (UTC)

Can't edit my /skin.js subpage

Pretty much exactly what it says on the tin. Also, it's stuck in "WikiText mode" (as opposed to "JavaScript mode"). For reference, I use IE 11. --User J. Dalek (talk | contribs) 05:09, 21 October 2014 (UTC)

Works fine for me. You may want to try not using Internet Explorer. --(ʞɿɐʇ) ɐuɐʞsǝp 06:36, 21 October 2014 (UTC)
The tin doesn't say what goes wrong. Users with wikEd enabled at Special:Preferences#mw-prefsection-gadgets sometimes have problems editing js and css files. The usual problem is that the edit box goes blank, and temporarily disabling wikEd on the icon WikEd logo.png at the top right solves it. PrimeHunter (talk) 16:35, 21 October 2014 (UTC)
@PrimeHunter: I don't have wikiEd enabled, and I can still see the text, I just can't edit it (sorry for not being clear before). Also, for some reason It now gets stuck in "JavaScript mode", and if I click "show preview", the box goes blank. --User J. Dalek (talk | contribs) 22:23, 21 October 2014 (UTC)
Do you mean you can see the text in the edit box after clicking edit, but before clicking preview? Can you place a cursor in the edit box by clicking there? Do you literally mean "/skin.js" as in User:UserJDalek/skin.js. It should for you be a redirect to a page for your skin like User:UserJDalek/vector.js (others will redirect to "User:UserJDalek/theirownskin.js" which is an odd feature). What is your browser and skin? Can you create a css page like User:UserJDalek/common.css? PrimeHunter (talk) 23:00, 21 October 2014 (UTC)
@PrimeHunter: To answer your first question; yes, it's exactly like that. For your second, no, it doesn't work. Third, no, I do mean my /vector.js page. Fourth, as I already said, I use Internet Explorer 11, and my skin is vector. Finally, no, I can't create the CSS page either. --User J. Dalek (talk | contribs) 02:50, 22 October 2014 (UTC)
OK. I have no problem in IE9 but cannot test IE11. Have you tried to clear your entire cache? Does work? It would probably work to temporarily disable JavaScript in your browser but that can be cumbersome and doesn't allow you to test the code until you have saved and enabled JavaScript again. You can also ask an admin to edit the page if you don't think it will require many tweaks. PrimeHunter (talk) 03:27, 22 October 2014 (UTC)
It works now, but (for reasons I can't explain here), I'm now using a different computer that runs IE10. --User J. Dalek (talk | contribs) 22:26, 22 October 2014 (UTC)
Please ignore the above message, I'm back with the old computer, and yes, it works with MonoBook. --User J. Dalek (talk | contribs) 01:45, 23 October 2014 (UTC)

Layout problems

May be something on my side only, but here goes.

At 2009 UCI Cyclo-cross World Championships (and other articles in the same series, like 2008 UCI Cyclo-cross World Championships or 2010 UCI Cyclo-cross World Championships, or related ones like 2007 UCI Track Cycling World Championships, but not on unrelated articles), I get ridiculously large "edit source" and "edit beta" links next to the title and section headers, and a "Jump to: navigation, search" link beneath the standard "From Wikipedia, the free encyclopedia" line. At the bottom I get a line like "Retrieved from "" " and the categories in some strange huge box, one above each other, instead of next to each other.

Any ideas? Fram (talk) 09:17, 21 October 2014 (UTC)

I don't see this. But I have seen it on about two other pages in the last month. I suspect a server issue. --Redrose64 (talk) 09:39, 21 October 2014 (UTC)
It's gone for me now a well, someone has super-rapidly corrected the error (or, more probably, it is some server issue indeed). Fram (talk) 09:59, 21 October 2014 (UTC)
The sometimes visible "Jump to: navigation, search" is also discussed at Talk:Main Page#Did something change? I can see it in Firefox with the procedure there: Click on "From Wikipedia, the free encyclopedia" and then press Tab. Or by just pressing Tab three times (more if there is a banner). The html source of rendered pages also says <div class="printfooter">Retrieved from ...</div>. Maybe people see these messages if their browsers don't load classes supposed to hide them by default. PrimeHunter (talk) 19:32, 21 October 2014 (UTC)
@PrimeHunter: A visible "Jump to: navigation, search" is not the main problem here, which is a font size of approximately 150% on certain elements plus a malformed cat box. The latter I suspect is due to the styling of the hlist class going missing. --Redrose64 (talk) 19:48, 21 October 2014 (UTC)

Get list of edited articles

Is it possible to get list of every Wikipedia article, I contributed to? I don't mean the Contributions page where every edit is present but a list of every article. It would be very handy to have something like this. --Rezonansowy (talk | contribs) 12:43, 21 October 2014 (UTC)

Use the edit-count tool. click here. Then look at the section 'Article' near the bottom. If you forget the location of the edit-count tool, there is a link to it from the bottom of your Contributions page. EdJohnston (talk) 14:59, 21 October 2014 (UTC)
Thanks! I forgot this tool's feature. --Rezonansowy (talk | contribs) 15:09, 21 October 2014 (UTC)
The edit-count tools appears offline; whenever I access that URL, all I get is a blank page. At least that's the case when I try to access it form behind my workplace's firewall, which wasn't so when I used it a month or so ago. -- llywrch (talk) 22:21, 21 October 2014 (UTC)
This might be a temporary problem at wmflabs. Just now none of the tools in are working for me. The edit counter was working at 15:00 on 21 October. EdJohnston (talk) 02:37, 22 October 2014 (UTC)
I get it too. --User J. Dalek (talk | contribs) 02:51, 22 October 2014 (UTC)

Search for special chars

Is it possible to request search queries for phrases containing special chars? For example: HTML tags, like <center>. --Rezonansowy (talk | contribs) 14:23, 21 October 2014 (UTC)

Any ideas? --Rezonansowy (talk | contribs) 12:10, 22 October 2014 (UTC)
The only way I know to do this is to download the database then use AWB to search. Goggle, Bing and the others just plain ignore punctuation marks. --  Gadget850 talk 12:58, 22 October 2014 (UTC)
You can use CirrusSearch's insource:// syntax to perform a regex match against the page source. Unfortunately its pretty busted right now from a performance standpoint. Fortunately I'm in the process of making it much faster. I imagine that'll take a week or so to finish though. If you need it sooner I can see if I can do some juggling to get it better just for enwiki. I don't imagine I'd be able to do the juggling faster then about 24 hours though. NEverett (WMF) (talk) 20:24, 22 October 2014 (UTC)
I tracked a little bug on it. --Rezonansowy (talk | contribs) 20:42, 22 October 2014 (UTC)
I replied to the bug with more in depth information. Filing the bug with the link to here is what got my attention in the first place. NEverett (WMF) (talk) 21:51, 22 October 2014 (UTC)

Can auto archives include a noarchive or if command....

Example: |noarchive = User talk:Name#DYK for Alligator gar ? There are certain posts I don't want archived automatically, and I'm not sure how to go about it. Any help would be greatly appreciated. AtsmeConsult 14:57, 21 October 2014 (UTC)

@Atsme: Template:Do not archive until does this job; see its page for instructions. The template goes in the relevant thread, not in the archiving instructions. -- John of Reading (talk) 15:37, 21 October 2014 (UTC)
John of Reading - thank you! AtsmeConsult 16:05, 21 October 2014 (UTC)

Why data are store after the power off

In non volatile memory the data are store in digital form (+ve volt and -ve volt). if power is off then data are erase because data are store in the form of digital(+ve volt and -ve volt). THAN WHY DATA ARE STORE AFTER THE POWER OFF

HARE KRISHNA RAI — Preceding unsigned comment added by (talk) 15:39, 21 October 2014 (UTC)

You want Wikipedia:Reference desk/Science. This is the place to discuss site features. Ian.thomson (talk) 15:47, 21 October 2014 (UTC)

Allow me to explain. It's stored on someone else's computer (the Wikipedia servers). --User J. Dalek (talk | contribs) 02:08, 23 October 2014 (UTC)

Toollabs down?

Can we get a dev update on the status of toollabs being completely down? I'm trying to run a copyvios check with The Earwig's tool. — {{U|Technical 13}} (etc) 15:54, 21 October 2014 (UTC)

Well, why do you think that toollabs is "completely down"? #wikimedia-labs on Freenode IRC or the mailing list might be more places to ask. --AKlapper (WMF) (talk) 09:55, 22 October 2014 (UTC)
  • For about 5 hours yesterday I got an "Internal Error" when I tried to use any tool hosted on toollabs (even the page that is suppose to list all the tools had no tools listed). Whatever the cause was, it resolved itself. — {{U|Technical 13}} (etc) 03:13, 23 October 2014 (UTC)

Meta-Wiki watchlist... a bug?

Hm, why do I see the same page twice in my Meta-Wiki watchlist? Aren't pages supposed to appear once per watchlist? Is that some kind of a bug? As a note, this appeared today, newer saw it before. — Dsimic (talk | contribs) 19:58, 21 October 2014 (UTC)

I am encountering something similar on Commons. Has the preferences checkbox "Expand watchlist to show all changes, not just the most recent" always been there? It seems that (on Commons) it has been switched on, whereas I think it was off previously (assuming it was an option prior to now). Wikipedia also has this checkbox, but it defaults to off. Dustin (talk) 20:01, 21 October 2014 (UTC)
Just twice - is that all? I see m:Meetup/English South Coast 1 59 times, all are different edits. But that's what I would expect, since it's been edited 59 times in the last 30 days. BTW "Expand watchlist to show all changes, not just the most recent" has been an option for as long as I've been around (over 5 years), and yes I do have it set - otherwise I miss stuff. --Redrose64 (talk) 20:08, 21 October 2014 (UTC)
Regardless, I am suddenly seeing multiple edits on single articles with Commons (rather than just the most recent edit), and the checkbox is suddenly checked (which is why I thought it might be connected). See The help desk at Commons appears no less than 29 times total. In any case, is the proper place to discuss this? Is there a better place to continue talking about this? Dustin (talk) 20:11, 21 October 2014 (UTC)

Yes check.svg Done, I've just deployed a configuration patch that fixed this. Cheers, Hoo man (talk) 20:43, 21 October 2014 (UTC)

Thanks, now it works as expected. By the way, "expand watchlist to show all changes" wasn't ticked in my preferences, I've disabled that option long time ago. — Dsimic (talk | contribs) 20:48, 21 October 2014 (UTC)

bibleversefinder tool not working

As the headline says, links to are not working. And they are in, like, all Bible-related articles!

It just gives me a blank page. I checked the source code and there is nothing there. At all.

How come this hasn't been noticed until now? Fix it ASAP!

Kiazore (talk) 00:33, 22 October 2014 (UTC)

The links I examined were made with {{Bibleverse}} or {{Bibleverse-lb}}. It was reported an hour ago at Template talk:Bibleverse#Broken again ? PrimeHunter (talk) 00:48, 22 October 2014 (UTC)

Width hack in Template:Article history

I'm trying to figure out why there's an empty <td/> tag near the end of Template:Article history. It has the comment "width hack", and I don't see why it's necessary, but if it's not included the template doesn't have the correct width. I'd like to find out if there's a better way to do this, or if I have to use the hack again when converting the template to Lua.

Here's a reduced example:

With this code:

<table class="tmbox tmbox-notice ">
    <td style="width:100%;">Foo</td>

We get this output:


But with this code:

<table class="tmbox tmbox-notice ">
    <td style="width:100%;">Foo</td><td/><td/>

We get this output:


Is there a better way of constructing the HTML to get the proper width? — Mr. Stradivarius ♪ talk ♪ 00:46, 22 October 2014 (UTC)

Those extra <td /> tags get converted to <td></td> which is an empty cell.

<table class="tmbox tmbox-notice">
<td style="width:100%;">Foo</td>

I'm not sure if this is done by HTML Tidy or Sanitizer.php.

The issue is that there is no table width set:

<table class="tmbox tmbox-notice" style="width:100%;">
<td >Foo</td>

--  Gadget850 talk 01:03, 22 October 2014 (UTC)

Hmm, with the main table width set to 100%, the table extends off the screen for me, but a width of 80% gets it looking right. Setting the width to 80% inline doesn't work for small message boxes, though. Looking through MediaWiki:Common.css, it seems that that "messagebox" is the class to use to set the proper width, as it has a "width: 80%" rule. And everything appears to work if we have a main table tag of <table class="messagebox tmbox tmbox-notice"> for large message boxes and <table class="messagebox tmbox tmbox-notice mbox-small"> for small message boxes. So I'll use that in the new module (please correct me if this is the wrong approach). I'm still a little mystified as to why one table cell would produce the wrong width, but adding two extra empty table cells would make the width appear correct, however. — Mr. Stradivarius ♪ talk ♪ 02:34, 22 October 2014 (UTC)
I'm sure it can be figured out, but it involves digging through volumes of HTML specifications on table behaviour. But as Gadget850 mentions, using the messagebox class will solve the problem. -- [[User:Edokter]] {{talk}} 08:11, 22 October 2014 (UTC)
Can you point me to a live example of where this hack is actually needed? Because if there aren't any, I'm simply going to remove this hack. -- [[User:Edokter]] {{talk}} 08:33, 22 October 2014 (UTC)
@Edokter: It's currently used in Template:Article history - search the source for "<!--width hack-->". But we will be able to remove the hack if we add the messagebox class to top table element. I've already fixed that in Module:Article history, which isn't yet deployed. (It will probably be ready in a week or two.) I haven't seen it used anywhere else, but you never know. — Mr. Stradivarius ♪ talk ♪ 09:15, 22 October 2014 (UTC)
Mr. Stradivarius, that's not what I mean... are there any instances of {{Article history}} being used on any page that require this hack? If there aren't any live examples, then this is just a case of overzealous preventative coding. -- [[User:Edokter]] {{talk}} 09:58, 22 October 2014 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── @Edokter: Ah, I see. Yes, it happens on quite a few pages, for example Talk:Artificial intelligence with the following invocation:

{{Article history
|action1date=12:27, 6 August 2009
|action1link=Wikipedia:Peer review/Artificial intelligence/archive1

If I remove the hack from the expanded wikitext, it looks like this:

August 6, 2009 Peer review Reviewed

There were a few other instances in the test cases too. — Mr. Stradivarius ♪ talk ♪ 10:25, 22 October 2014 (UTC)

I've 'normalized' the hack to remove the invalid tag. I don't quite how to handle this otherwise. Using the messagbox class may intoduce some redundant CSS, so I'd like to avoid that as well. Perhaps just add an empty cell for now as the template does now? -- [[User:Edokter]] {{talk}} 14:13, 22 October 2014 (UTC)
Probably better would be to set the module to set an inline style of "width:80%" for large templates, and omit this style for small templates (and add the "mbox-small" class). That's more readable than adding an extra empty cell, although it is a bit of a hack in and of itself. — Mr. Stradivarius ♪ talk ♪ 14:32, 22 October 2014 (UTC)

Image problem

Does anyone has any idea, why File:US Navy 120209-N-XD935-302 Mass Communication Specialist 1st Class Shane Tuck, assigned to the Expeditionary Combat Camera Underwater Photo Team, c.jpg won't display on the English Wikipedia? Armbrust The Homunculus 13:29, 22 October 2014 (UTC)

It works at full size but a thumb gives another url than at Commons. I don't know why. The thumb example below gives the url:
Clicking it says "The given path of the specified thumbnail is incorrect". At Commons the same code gives the url:
Note the file name is repeated in the url. It displays the image at Commons and also when you click it. I think the same code at Wikipedia and Commons usually gives the same image url. Here are two others from Category:Featured pictures with the same error:
PrimeHunter (talk) 14:03, 22 October 2014 (UTC)
US Navy 120209-N-XD935-302 Mass Communication Specialist 1st Class Shane Tuck, assigned to the Expeditionary Combat Camera Underwater Photo Team, c.jpg
Could it be because the filename has comma(s)? -- [[User:Edokter]] {{talk}} 21:20, 22 October 2014 (UTC)
@Edokter: I think you're on to something - I came across another file with the same problem, and it also contains commans (File:1801 Cary Map of the East Indies and Southeast Asia ( Singapore, Borneo, Sumatra, Java, Philippines - Geographicus - EastIndies-cary-1801.jpg). ~SuperHamster Talk Contribs 21:25, 22 October 2014 (UTC)
Whoop, I somehow entirely missed that PrimeHunter already provided that example. ~SuperHamster Talk Contribs 21:26, 22 October 2014 (UTC)
Same problem at Elizabeth II#Continuing evolution of the Commonwealth for File:Queen Elizabeth II and the Prime Ministers of the Commonwealth Nations, at Windsor Castle (1960 Commonwealth Prime Minister's Conference).jpg. DrKiernan (talk) 21:36, 22 October 2014 (UTC)
The pattern is files with filenames between 140-159 bytes long. It appears to be due to an accidental change in a setting when a different setting was changed. It should be fixed soonish (Definitely by tomorrow once people at wmf offices are at work). Bawolff (talk) 02:48, 23 October 2014 (UTC)
User:Cscott got the change deployed. Issue should be resolved now. If any pages still have broken images on them, doing a ?action=purge to the page should fix it. Bawolff (talk) 03:09, 23 October 2014 (UTC)

Can't fix a bad URL in a citation

I can't fix the citations in the article 165th Street Bus Terminal. According to Help:CS1 errors#bad_url "The URL field is checked to ensure it includes either a colon (:) or the double forward slash (//). Further validation is not performed." The website in question does have those features, and the link is still broken. Why can't I fix them? ---------User:DanTD (talk) 16:13, 22 October 2014 (UTC)

I see that you've cured it by including the http:// which weren't there before. --David Biddulph (talk) 16:26, 22 October 2014 (UTC)
Yes, because evidently I was looking in the wrong places for them. ---------User:DanTD (talk) 16:47, 22 October 2014 (UTC)

Xtools 2: Electric Boogaloo

The problem with the timing out was fixed, but it is now 404ing. KonveyorBelt 03:45, 23 October 2014 (UTC)

404 error also with the edit count tool, which has been occurring for many hours. BlueMoonset (talk) 05:32, 23 October 2014 (UTC)
404 continues. TParis says his "access is apparently screwed up", and recommends asking Cyberpower678 (last enwiki post 6 weeks ago) or Hedonil (last post on dewiki 7 weeks ago), for whom I left a message. Is there something "political" going on with this important toolset? —[AlanM1(talk)]— 11:06, 23 October 2014 (UTC)
My attention has been diverted here. Let me see what's going on.—cyberpower Temporarily OnlineTrick or Treat 11:43, 23 October 2014 (UTC)
  • My attempts to connect to labs have been unsuccessful. There's apparently more than dead tools going on here. "A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.". — Preceding unsigned comment added by Cyberpower678 (talkcontribs) 11:51, 23 October 2014‎
  • Fixed

Bug in Minerva Beta (Mobile Site)

When on the mobile site, when I clicked on the user page, and then clicking the talk button, it is empty. Additionally, the Wikilink leads to "User talk:User:THEUSERNAME". Do you think it is a bug? - gacelperfinian(talk in - error? Start a new topic) 06:53, 23 October 2014 (UTC)

The Jewish Encyclopedia's internet address

The Jewish Encyclopedia's internet address has changed - all links should be fixed. See, for example, in Apion. Liadmalone (talk) 10:46, 23 October 2014 (UTC)

That's likely a DNS goof. There is occasionally reason to have separate and servers, but the is almost always the one that is commonly used by the public. I'll ask them. —[AlanM1(talk)]— 11:13, 23 October 2014 (UTC)

Article count tool

The Xtools article count tool (the one linked from user contributions, not the WMF labs one) is down and showing a 404 error message. I don't know who runs it, so I thought I'd post here in case people weren't aware of the problem. G S Palmer (talkcontribs) 13:46, 23 October 2014 (UTC)

Yes it is known, see Bugzilla: 72104. Darkdadaah (talk) 14:00, 23 October 2014 (UTC)


Media Viewer RfC Question 1

We have a previous RfC consensus that Media Viewer should be default off. That RfC was never implemented due to the Superprotect controversy and a WMF Community Consultation process on Media Viewer. That community consultation process has ended and the outcome can be viewed here. I think it is time to review that outcome and determine whether we still want Media Viewer to be disabled by default. Alsee (talk) 17:33, 3 October 2014 (UTC)

(Note: There is a second question further down the page.) Alsee (talk) 17:53, 5 October 2014 (UTC)

Question One. Should we reaffirm and implement the previous RfC: WP:Media_Viewer/June_2014_RfC#Consensus.2Fdisapproval_has_been_established There is a clear consensus that the Media Viewer should be disabled by default for both logged-in (section link) and non-logged-in users (section link).

Support (Media Viewer RfC Question 1)

  1. SUPPORT as RfC author. The WMF's Community Consultation Process on Media Viewer resolved essentially none of the objections raised in the previous RfC. I believe our original image page is better than Media Viewer. Alsee (talk) 17:41, 3 October 2014 (UTC)
  2. Support Obviously nothing has changed, the default should still be off unless specified by editors (i.e. if an editor wants the mediaviewer used for galleries, etc). Not that it matters. I have zero confidence in the WMF's respect for consensus at this point. 0x0077BE [talk/contrib] 16:01, 5 October 2014 (UTC)
  3. Support as the attribution problem has still not been sufficiently addressed. This is a show stopper. --AFBorchert (talk) 16:13, 5 October 2014 (UTC) P.S. I think that is an inherently difficult problem, take File:Carentan Église Notre Dame Vitrail Baie 07 2014 08 24.jpg as example with a very complex copyright case which cannot be represented in any simplified manner.
  4. Support. Unless the consensus has changed, we should not allow the WMF to continue to avoid the issue of enablement, and at any rate we should not leave them with the impression of acquiescence. BethNaught (talk) 16:33, 5 October 2014 (UTC)
  5. Support - I still prefer the old one and probably always will, - At the end of the day the community decided it should be off, Period. –Davey2010(talk) 16:52, 5 October 2014 (UTC)
  6. Per AFBorchert.--Aschmidt (talk) 17:28, 5 October 2014 (UTC)
  7. Support, although this wasn't needed; community consensus has already been formed to disable it. Consensus-changing attempts are appropriate, but that would be the only reason for having such a discussion. Let me remind the closer that "no consensus" defaults to pre-discussion, which is unambiguously "off". Nyttend (talk) 19:29, 5 October 2014 (UTC)
  8. Support: The most frequent piece of feedback that WMF removed was "turn this to opt-in" and the WMF intentionally and purposefully ignored all such feedback [10][11][12]. Since the consultation was a sham, I see no reason to wait for any results.—Kww(talk) 20:09, 5 October 2014 (UTC)
  9. Support. It seems to me to be common sense that WMF should care what the editing community says. --Tryptofish (talk) 20:15, 5 October 2014 (UTC)
  10. Support. It's inherently inferior to the existing file page, and the community spoke after due examination of the two. Yngvadottir (talk) 21:06, 5 October 2014 (UTC)
  11. Support. I don't know why we are having this discussion again. We already know that 1 a large majority of editors prefer the pre-existing system, and 2 WMF people ignore and misrepresent our views. Maproom (talk) 21:46, 5 October 2014 (UTC)
  12. SUPPORT. It has already been demonstrated that a majority of the community do not like or want the new Media Viewer, so continuing to debate the subject only proves that WMF does not really care what the community thinks, and will keep asking the question until they get the answer they want. To repeat what I (and many others) have already said: The use of this new Media Viewer should be "Opt-IN" only -- it should never be on by default for anyone. FireHorse (talk) 22:20, 5 October 2014 (UTC)
  13. Support. Looks like they made a prototype ([13]) and I don't see anything important that has changed. The page seems to imply (meta:Special:PermanentLink/9840243 - "Screenshot of the Media Viewer's new design prototype") that that's how things will look. And we know that is what has been rejected. I doubt there is much point in giving WMF more time - it is pretty clear that they are not going to do anything else with it. Also, "Consensus can change" - if a miracle happens and they create something good, we can simply change our minds. But let's let them develop something good first and deploy it afterwards, not vice versa... --Martynas Patasius (talk) 22:29, 5 October 2014 (UTC)
  14. Support BUT - I want that Media Viewer on Commons On Commons should be left there. It is a great help on commons, but there is no text there. Please do not disable it on Commons. On Wiki it is kind of irritating. Hafspajen (talk) 23:24, 5 October 2014 (UTC)
  15. Support. WP:Consensus can change, but it is up to someone else - and WMF is certainly invited to do so - to make a new RfC to see if that's the case. Until then, we have a consensus, and it needs to be implemented properly. VanIsaacWScont 00:06, 6 October 2014 (UTC)
  16. Support. Absolutely. Nothing but an irritant (on the plus side, though, I must say that its combination with the typography change makes it impossible for me to ever forget to log in). Double sharp (talk) 01:33, 6 October 2014 (UTC)
  17. Support. Even the most optimistic reading of recent poll data, which shows that a plurality of users find media viewer userful for viewing images, only had 49% choosing that option. Note that the question is not "Is Media Viewer better than previous image pages", but is it useful for viewing images. If less than half, or even half, or even only two thirds of people find that it is useful in serving it's main purpose, that is to view images, then it is seriously unready to be the default. If only 50% of people that used a car found it "useful for getting from place to place" it would be seen as a lemon, but somehow 49% of people finding media viewer "useful for viewing images" is a good thing. The performance of the media viewing is still seriously lacking on underpowered hardware and older browsers that many people are forced to use, and the unlabeled icons are extremely difficult to figure out for a casual user of the site that doesn't want to have to learn a new UI just to view the details on an image. --Ahecht (TALK
    ) 02:30, 6 October 2014 (UTC)
  18. Support. I understand the need to make images easier to view, but I'm not convinced that MediaViewer is significantly better than the existing system at even that. And, as almost everyone can agree, it is far worse for viewing and editing image descriptions. As a reader of news websites, I'm not a huge fan of images that, when you click on them, occupy the whole screen against a black background. -- King of ♠ 02:38, 6 October 2014 (UTC)
  19. Support. — al-Shimoni (talk) 03:45, 6 October 2014 (UTC)
  20. Support: All the reasons above, my own gripe is that not only does it make editing a pain, and is hard to turn off, it also is SLOW; I can stream video faster than load a photo on the theing. Montanabw(talk) 04:15, 6 October 2014 (UTC)
  21. SUPPORT Assuming lowly anonymous readers are allowed to vote. MediaViewer is still an ugly, intrusive, invasive kludge. It does _nothing_ better than the old Wikimedia Commons webpage. — Preceding unsigned comment added by (talk) 01:50, 6 October 2014
  22. Support: Even after all the changes that have been made Media Viewer is a a clear step backwards in functionality, usability, and performance. Despite the WMF's assertion that this is a feature for the so-called "readers", every IP that chimed in was against keeping Media Viewer enabled by default. The WMF's own survey showed that fewer than 50% of English-speaking respondents who never edit found Media Viewer useful for its intended purpose. CONEXCEPT does not apply as the obvious intent of the policy was to check actions that went against the philosophy of the movement or that presented technical issues. Neither apply. For all all the aforementioned reasons, the RfC should be affirmed and Media Viewer should be returned to opt-in by default. Furthermore, if the WMF refuses to implement this consensus, I support administrators taking any technical or legal actions to make sure the consensus is in fact implemented. -- (talk) 06:38, 6 October 2014 (UTC)
    Not sure where you're getting your statistics, but they don't seem to agree with the ones I've seen, which show over 60% approval by English readers. Kaldari (talk) 07:24, 6 October 2014 (UTC)
    The 60% number is if you cherry pick the last two weeks of the survey, where responses trickled down to nothing. I was rather disappointed to see the Multimedia team be so dishonest with their data. I can't find the spreadsheet at the moment with the final results, but the cumulative reader approval rate over the whole survey was a smidgen below 50% at that time. I seem to remember looking very hard for it because the Multimedia team didn't post it in an obvious place. The last full results I can find right now puts reader approval at 37% in English, but I know I saw a similar spreadsheet that had the final results. I've removed your plots because they're misleading. The English reader plot only shows the last two weeks. The two global plots predate the English Wikipedia rollout and don't represent the opinions of readers and editors of the English Wikipedia. -- (talk) 08:00, 6 October 2014 (UTC)
    Discussion of the statistics is worthy of an entire section. Please take it to the discussion area. This is a bad place to debate what numbers are valid and what numbers are misleading.
    Notice: Three images added by Kaldari were removed by I consider it it entirely appropriate to remove images from this section. The diff and images can be viewed here. Alsee (talk) 10:11, 6 October 2014 (UTC)
  23. Support--Oursana (talk) 09:15, 6 October 2014 (UTC)
  24. support -jkb- (talk) 09:19, 6 October 2014 (UTC)
  25. Support Ealdgyth - Talk 12:35, 6 October 2014 (UTC)
  26. Support: Awful tool, unwanted, unwarranted and a technically backwards step that worsens the experience for editors, whether logged in or not. - SchroCat (talk) 12:36, 6 October 2014 (UTC)
  27. Support. I think that MediaViewer is promising—in the long term it can become a useful functionality. However, it's not ready. In particular, it does not reliably render information from the file pages in ways that are easily predictable, and when it fails, it fails in ways that disadvantage the reader—especially the casual reader who may not know about the old-style file description pages, which are problematically obscured in its design (a "More details" button does not suffice). This disadvantage comes about because the underlying functionality—semantic file metadata—isn't properly available yet (as far as I know). Redesigns will not solve that fundamental problem. My distaste for lightboxes means I don't plan to ever enable MediaViewer personally, but I would like to be able to support its use by default. However, I can't support it until those problems are fixed.

    I am separately disappointed with the community for being oppositional to the WMF, and the WMF for the shameful "superprotect" fiasco. The community and WMF need to work together. The WMF needs humility—if the community says no, that should be enough to shelve a feature, despite the time and money and emotions invested in it. On the other side of the coin, the community needs to trust the WMF's good faith, because the situation in which the WMF isn't trusted by the community is nothing short of toxic. Hopefully this RfC will help smooth both over. {{Nihiltres|talk|edits}} 13:38, 6 October 2014 (UTC)

  28. Support The ignorance from the WMF regarding the valid RfCs from enwiki and dewiki and corresponding bug reports is rather telling and I doubt that they will respect them now. However, substandard software with which the Foundation knowingly supports license violations is not something that should be ignored, no matter how bad the relationship with the editorial communities. Please fix this now, review your senior staff's behaviour and competence (or rather lack thereof) and get back to all negotiating tables with the communities. That is of course, only if the Foundation's goals are still aligned with the core principles (recent comments from board members suggest they are not). --Millbart (talk) 14:19, 6 October 2014 (UTC)
  29. Support: At present it is hideous to look at, worse to work with; it may improve over time. Even if we accept good intentions, it was insensitive and arrogant on the part of WMF to impose this on editors without prior discussion, trial or feedback. In a recent phone interview with the WMF politburo I formed an impression that addressing editor concerns was high on their agenda; I hope I was not misled. Brianboulton (talk) 15:04, 6 October 2014 (UTC)
  30. Support – It is an utter disaster, at present. It is awful, and is completely outside the spirit of Wikipedia. It is our job to be no frills, bare-bones, like a encyclopaedic Gandhi, dressed in simple white cotton garb. This is emblematic of our goals, our mission, and all of our principles. To implement such technology as this is, useless and badly designed as it is, is to forsake what Wikipedia does right. RGloucester 16:16, 6 October 2014 (UTC)
  31. Support although WMF doesn't recognize community consensus. Chris Troutman (talk) 17:17, 6 October 2014 (UTC)
  32. Support, per AFBorchert, Kww, Nihilres, & others.

    In an ideal world, what would happen is that Media Viewer would be made opt-in for all users, the staff at WMF would prioritize the defects described & fix them, & once it was shown it was solid & useful, the community would then agree to set it back to opt-out for all users. But based on experience, what will happen is that the WMF will dismissive to the community's objections as if we were all children, do their utmost to force an alpha-stage software upon us, then six months later wonder at reports about increased numbers of veteran Wikipedians leaving. As Nyttend points out, this second RfC should be unnecessary, but certain people at the Foundation insist on ignoring what the volunteers on the ground have been telling them. -- llywrch (talk) 06:00, 7 October 2014 (UTC)

  33. Support. It doesn't work. What I am usually looking for is the file name, and it doesn't show you that. Worse, they don't tell you how to disable it. Even if you do figure out how to disable it, it is not disabled across all wikipedias, only the English one, so you if you are browsing images in a language you don't speak, and where the media viewer is enabled, you will not be able to find the file name or disable the media viewer in that language. —Neotarf (talk) 23:20, 7 October 2014 (UTC)
  34. Support, But let's face it! -- there have been several RfC's, Notice board issues and Media Viewer's own feedback page showed a clear disapproval. Further, their own statistics revealed that MV was not wanted nor needed, on English and German Wikipedia (it's redundant, a glorified 5th wheel and something of a flat tire, given all the bugs -- and here we are months later and they're still tinkering around with this thing). They continue to misrepresent approval. Here is what their own findings say:
    approval breakdown by language: French 71%, Spanish 78%, Dutch 60%, Portuguese 81%, Hungarian 63%, English 29%, German 26%.
    (The numbers fluctuate, but overwhelming disapproval on English and German (most of) WP remains constant.) They admit that approval is very low for English Wikipedia. What they don't want you to know however is that the number of articles, editors and readers for English (and German) Wikipedia dwarf all other such numbers in the other Wikipedias. Look at the numbers at the bottom of the Wikipedia main page. ( ! duh ? ) Since English and German Wikipedia are the largest by far, then it goes that there is overwhelming disapproval overall. All this redundant/buggy viewer is really doing is wasting server resources while amusing certain individuals on the software development team. Their "approval", such that it is, is largely based on the feedback of naive, uninformed and occasional visitors to WP. i.e.How does anyone who is familiar with all the faults and bugs in MV lend their approval?? Easy math. I know I speak for (very) many editors when I say I have lost almost all faith for certain individuals in the WMF. Apparently they see consensus as an invasion of their turf and a challenge to their authority. Get a load of the TOC on one of the archived M.V. talk pages. Good luck guys. -- Gwillhickers (talk) 22:18, 9 October 2014 (UTC)
  35. Support. I dislike it, but could live with it. However, when last I used it it was a non-starter because every image viewed through it violates our duty to provide proper, accessible copyright information, in a manner that is well suited to inform third-party re-users of their attribution obligations. Everything else is secondary.--Fuhghettaboutit (talk) 00:14, 10 October 2014 (UTC)
  36. Support. I don't object to MediaViewer in principle, but as currently implemented it has so many issues - unlabelled buttons, no copyright info, inability to view full-size - that it's unfit for purpose. Mogism (talk) 00:20, 10 October 2014 (UTC)
  37. Support, this new thing is quite clunky and unwieldy and slows down efforts to contribute and edit. — Cirt (talk) 12:50, 10 October 2014 (UTC)
  38. Support - I have disabled MV on and, so I can see images as it used to be before MV was launched. Whatever the improvements are which supposedly have been made, anytime I read Wikipedia while not logged in, and want to see an image I get reminded by MV that it still doesn't function properly. Kraxler (talk) 18:51, 10 October 2014 (UTC)
  39. Support, again, no evidence has been presented that Media Viewer is an improvement from the file page. Either way, the reader sees a larger version of the file after a single click on the file. The Media Viewer eliminates important information about the files and about the context of the surrounding text. On the other hand, the file page gives all of this info. One thing I would support is making files automatically open in a new tab, since 9 out of 10 times a reader will want to go back to the article after viewing the file. StringTheory11 (t • c) 19:07, 11 October 2014 (UTC)
  40. Support. Especially the brutal force to implement such a buggy, unwanted bling-thing was absolutely disgusting. --♫ Sänger - Talk - superputsch must go 10:32, 12 October 2014 (UTC)
  41. HELL YES Never have so many been so upset at so few, but in this process - which I'm sure will ultimately be devoutly ignored - we have a chance to right a wrong, and maybe, just maybe, get back to the way things were: happy editors, happy readers, and happy fact checkers for articles and images. TomStar81 (Talk) 11:37, 12 October 2014 (UTC)
  42. SupportWasell(T) 19:40, 12 October 2014 (UTC)
  43. Suppport (everything has been said already above and elsewhere). Ca$e (talk) 19:56, 12 October 2014 (UTC)
  44. I'm more of a reader than an editor these days, and I turned the thing off as soon as I figured out how to do so. The file pages are informative, and educate readers about how images are contributed to an open-source educational project. It wasn't broken, it shouldn't be fixed. It shouldn't take umpteen RfCs to get Mr. Möller's department to roll this back. --SB_Johnny | talk✌ 23:51, 12 October 2014 (UTC)
  45. Support. This entire affair has been unhappy for many people, and has certainly left me severely disillusioned. I have cut my contributions to Wikipedia as a result of the events surrounding the Media Viewer, and am unlikely to return to my earlier contribution level unless their is clear evidence that the WMF are paying more attention to editors' concerns. RomanSpa (talk) 05:38, 13 October 2014 (UTC)
  46. Support keeping Media Viewer disabled by default for both registered and unregistered editors. Anyone who wants it can turn it on. As several previous editors have said, it isn't an improvement on the existing situation. Robert McClenon (talk) 18:58, 13 October 2014 (UTC)
  47. I support the RFC as a sub optimal response. But I'd prefer not to have media viewer available as an option on sites that allow Fair use images. Either that or stop hosting Fair Use images. The idea behind Media Viewer seems to be dropping the boring stuff about copyright as a large proportion of humanity doesn't take that seriously. That's annoying to those of us who contribute photographs and especially those who take copyright seriously and think that this site should continue to do so. But it isn't likely to get people in trouble, except where Fair Use images are concerned. We regularly bite newbies for misuse of Fair use images, others are entitled to bite them for it in real life. If we are going to continue to allow Fair Use images the least we can do is leave the warnings about them in place, rather than on a separate link. You could of course amend Media Viewer so that it gave appropriate licensing info when displaying a Fair Use image, but then why have Media Viewer at all? ϢereSpielChequers 13:43, 14 October 2014 (UTC)
  48. Support Progress has been made with the Media Viewer, however I still prefer the non-Media Viewer page. Also, it's difficult using the back button because I can't tell when I'm "on the same page" versus when I'm "on a new page". Overall, at this time I don't believe it's ready. Crazycasta (talk) 01:08, 15 October 2014 (UTC)
  49. The Community Consultation Process on Media Viewer was a sham. I get the feeling we are bashing our heads against a brick wall here though. MER-C 01:54, 15 October 2014 (UTC)
  50. Support - Media Viewer has only gotten worse since it was first released. What used to be a minor inconvenience has become a moderate inconvenience to the editing process. Carrite (talk) 13:54, 15 October 2014 (UTC)
  51. Support. Everyking (talk) 03:42, 19 October 2014 (UTC)
  52. Support. People who like it can opt in. They should not be forced into using it by default. A later RFC could establish that there's consensus to enable it by default, but we are clearly not there yet. NinjaRobotPirate (talk) 00:19, 20 October 2014 (UTC)
  53. Support. Ahsoous (talk) 11:30, 20 October 2014 (UTC)

Oppose (Media Viewer RfC Question 1)

  1. Not really clear why this RFC is required at the current time. Development work is still ongoing to make Media Viewer more acceptable to communities and respond to feedback. A better time for an RFC would be when a planned deployment is put on the table, and the version of Media Viewer that is proposed for deployment is available for evaluation. At the moment, there isn't really anything more to discuss beyond what was already said last time.
    On another note, I'm not sure that RFCs of this kind are helpful. They feel somewhat antagonistic to me, and seem to bring out a vocal minority of technical Luddites within this community who don't always understand the subtleties of the issue at hand. — This, that and the other (talk) 11:35, 5 October 2014 (UTC)
  2. Not within the framework of WP:CONEXCEPT, section 1 and/or 4. I will add that any legal objection regarding attribution is incompetent, as coming from persons without verifiable credentials or responsibility. It is also absurd to make such claims, when practically every page on Wikipedia (eg. Main Page) has no visible origin information for images. Alanscottwalker (talk) 16:26, 5 October 2014 (UTC) I also agree that this is just a VOTE, the only practical rationale offered by the RFC is, 'if you do not like it, vote support for confronting the WMF.' Alanscottwalker (talk) 16:16, 6 October 2014 (UTC)
  3. This is the wrong time. According to the outcome of the consultation process, as referenced above, We plan to complete all “must have” improvements by the end of October and deploy them incrementally, starting this week (that was on 11 September 2014). The end of October will be the time to start a thorough discussion, which may go better if editors aren't weary from a long RFC now. NebY (talk) 17:53, 5 October 2014 (UTC)
  4. What TTO said. Also this really isn't an RfC, it's just a WP:VOTE. Legoktm (talk) 18:31, 5 October 2014 (UTC)
  5. Per NebY. If they're currently working the feedback they have from us into the software and will have that done soon, a random RfC now on the basis of old discussion and an old software version is pointless. Discussion about the tool's future status should happen when there's actually something new to discuss. A fluffernutter is a sandwich! (talk) 18:44, 5 October 2014 (UTC)
  6. It's long past time to deploy this improved file-page interface, especially for non-logged-in readers who likely don't care about the cruft that we editors do. Powers T 19:21, 5 October 2014 (UTC)
  7. It looks like improvements are still being made and many of the problems of the initial version have already been fixed. Kaldari (talk) 19:54, 5 October 2014 (UTC)
  8. Per NebY. Wait until they get it fixed, and then if we still don't like it, turn it off. Jackmcbarn (talk) 20:20, 5 October 2014 (UTC)
  9. The WMF have made an attempt to address some of the concerns of the community, we should at least wait until they are addressed before holding an RfC. I also agree with Legoktm that this is not an RfC, it's a vote. --Tom (LT) (talk) 22:57, 5 October 2014 (UTC)
  10. The concerns expressed in the original RFC are already pretty much resolved. An actual RFC on this topic would review the work that has been done, and discuss it, not just have a vote for the sake of voting. And editors who don't like it can change their preferences. Risker (talk) 01:49, 6 October 2014 (UTC)
  11. Keep media viewer The media viewer is a significant benefit to our readers. Yes, it does get in the way of editors, but editors have the ability to turn it off, and they do just that. Our defaults must be oriented for readers, who don't have such options. Oiyarbepsy (talk) 02:16, 6 October 2014 (UTC)
  12. Oppose I agree with most of the comments above. PaleAqua (talk) 15:07, 6 October 2014 (UTC)
  13. Per Risker, and the fact that this isn't an RfC. Ed [talk] [majestic titan] 19:56, 6 October 2014 (UTC)
  14. The media viewer is a useful tool for readers, and readers don't have the ability to adjust their preferences. --Carnildo (talk) 02:15, 7 October 2014 (UTC)
  15. Good enough. Not perfect, but helpful to readers and usable for editors. And I see the WMF is doing active development in a useful and rapid manner. DGG ( talk ) 07:16, 7 October 2014 (UTC)
  16. For an image editor or reviewer the additional clicking and disorganized image information makes efficient and quick work simply impossible. No feature should cater only to one portion of the community, be it readers or editors. All features need to be usable efficiently by all parts of the community and readership. However this RfC is too early, it's better to wait for the results of the current improvement drive. GermanJoe (talk) 08:17, 7 October 2014 (UTC)
  17. Keep Mediaviewer. Improvements are ongoing, think of MV as an extended thumbnail view. Viewers will be able to go to the file description page easily. Even if the attribution does not work perfectly, I do not consider this a "showstopper". The complex cases, where MV fails are almost impossible to grok for human as well, so not much is lost here. We should rather focus on making the meta data more accessible for humans and software alike. --Dschwen 16:18, 7 October 2014 (UTC)
  18. Per Risker this can be changed in preferences.This appears to more of an vote rather than an RFC.Pharaoh of the Wizards (talk) 02:47, 8 October 2014 (UTC)
  19. Keep Mediaviewer per all the comments above. MV isn't perfect but it is an improvement, especially for readers, and the WMF is still working on MV to address the concerns of the community. If people don't like it, they can opt out individually. It is clear to me that the issue isn't MV itself but the relationship between some of the community and the WMF. Unfortunately, this RFC does not appear to be an attempt to improve that relationship or to collaborate with the WMF, instead coming across as antagonistic and unhelpful. Ca2james (talk) 16:05, 10 October 2014 (UTC)
  20. Oppose. Since something has to be default, I don't see it shouldn't be the media viewer. It is quite possibly true that it's not the best way to view image details for editors or heavy readers, but that has little to do with anything -- those people can just disable the default (I myself have it disabled, partly because I just don't like change). For casual readers -- which is what we're mainly talking about here, I think -- my uneducated guess is that when they click on an image they probably mainly want to see a larger version or at any rate a full-screen view. And I'm not convinced that the Media Viewer isn't, or can't be made to be, just as good if not better for that than the old way. I'd like to see an actual study of casual readers and new readers and see what they like, and it shouldn't be too hard to run one. Absent that, I'm opposed to the question. Herostratus (talk) 17:43, 12 October 2014 (UTC)
  21. Keep Mediaviewer I still don't understand the big fuss about all this. Seems to me, most readers would want to see an expanded view of the media when they click on a thumbnail – it's standard practice all around the internet. For the people who don't like it, namely editors, it's very easy to figure out how to disable it (the "disable media viewer" link at the bottom of the media viewer). I'm a fan myself, and had it enabled before it went live to all users. Like the reader, I more often than not just want to see media, not work with it. I can't say I've ran into any bugs either. — MusikAnimal talk 18:31, 12 October 2014 (UTC)
  22. Oppose Even in its current imperfect state the MV already seems an improvement for the readers, whose interests should be central to our efforts. Additionally, editors who don't like the MV can simply opt-out, so where is the problem? Given that the improvement process of the MV will last through the end of October the timing of this vote is ill-considered and not constructive. --Wolbo (talk) 21:29, 12 October 2014 (UTC)
  23. Oppose June was 4 months ago and that's quite a lot of development time. No doubt MV has changed quite a bit since then and in any case consensus can change. Therefore the results of that 4-month-old RfC should not stand. WaggersTALK 09:49, 13 October 2014 (UTC)
  24. Oppose Per WP:CONEXCEPT, software development is beyond the purview of the community. Confronting WMF is unproductive, unhelpful and unnecessary. Hawkeye7 (talk) 19:51, 13 October 2014 (UTC)
  25. Oppose. The Media Viewer is intended for improving the experience of the millions of silent readers out there, and a consensus of a very small self-selected set of editors here can not possibly be representative of those people. For situations like this, I think Wikipedia's consensus model is not appropriate and such decisions should not be made this way. For better or for worse, the decision should be left to the Wikimedia Foundation. Neatsfoot (talk) 07:57, 14 October 2014 (UTC)
  26. Oppose Yes, it was a pain to have to find and click on that button to get to the original screen. But the arguments that it benefits new and non-editing users, and that it's still being tweaked, are enough for me to put aside my own selfish considerations. Drop the stick. Carolmooredc (Talkie-Talkie) 13:15, 14 October 2014 (UTC)
  27. Oppose The Media Viewer appears to be good enough for default use and can be disabled by users who do not want it. Making it opt-out rather than opt-in gives it the exposure necessary for testing and improving it. Kind regards, Matt Heard (talk) 01:15, 16 October 2014 (UTC)
  28. Oppose per Risker and the RfC format concerns. Mike VTalk 18:19, 19 October 2014 (UTC)
  29. Oppose. Media Viewer certainly has rough edges (which the WMF is addressing), but on the balance I think it's already a real step forward, particularly for readers who just want an easier way to see large versions of images—and personally, I'm a big fan. For those who find it bothersome, opting out is pretty easy.—Neil P. Quinn (talk) 16:56, 20 October 2014 (UTC)

Neutral (Media Viewer RfC Question 1)

  1. I dislike Media Viewer and disabled it wherever it irritated me, but I see the point of those who say "Let's see the new improvements first." LynwoodF (talk) 18:42, 5 October 2014 (UTC)
  2. Abstain Please review the WMF's mission statement. The question of whether MV "empowers" people or not is a matter of opinion. The role of the WMF with respect to RfC's is not. Lila, the Board, and anyone under employment with the WMF has no obligation whatsoever to make decisions based on a community RfC alone. In this case, Lila is following what is widely considered a best practice for online services: if there is a workaround to new issues (clearly there is here in disabling the feature), then avoid creating new problems with a roll back. The path Lila has chosen is to work with the community in improving MV, instead.
    Some may dismiss this as the WMF prerogative with a rock-solid argument behind them using the founding documents of the WMF. I won't. I recommend taking Lila and her team directly to task by demanding answers in to what went wrong here. Let's demand something we might actually get: a post mortem on the initial MV rollout. What changes have been made to prevent this happening in the future? I can get things started by mentioning that we have a new VP of Engineering at the WMF, for example. What forward-looking promises can we get from the WMF and Lila that we can actually hold them to? And, more importantly, how can we help them back up these promises up for the good of the entire community and our users? There's been so much talk around MV; it's time for everyone to start walking the walk. I'm going to start by getting back to editing WP with time I'd otherwise waste on these pointless petitions. -wʃʃʍ- 20:48, 7 October 2014 (UTC)
  3. I am pretty much neutral on Media Viewer itself, but one of the many who are put off by the condescending comments of people such as User:Fabrice Florin (WMF), and more generally the WMF as a whole. The WMF should listen to the community, rather than consistently dismissing it by referring for instance to "self-selected RFC discussions." Like it or not, RFCs have long been among the principal ways in which the Wikipedia community seeks consensus on important issues. And if you don't like it, it's not the community that should fork (per User:Wllm), it's the WMF employees who have lost the plot. --jbmurray (talkcontribs) 16:34, 8 October 2014 (UTC)
I'm confused. Are you suggesting that the WMF fork instead of the community? I'm not sure that's even possible, but it would follow the pattern of people at the WMF actually doing stuff while some disgruntled members of the community waste everyone's time on toothless petitioning that puts nobody's skin in the game.
As I've said many times before, people should start walking their talk. If that means part of the community leaves to work on their own fork, I believe that would be for the best for their personal well-being and the Wikimedia projects as a whole. Why waste your time complaining about the WMF in these ridiculous petitions? Put your time and effort in to a new encyclopedia if you think you can do it better. I'm gonna stick around to see where the WMF is taking this story. -wʃʃʍ- 00:38, 9 October 2014 (UTC)

Reserved for official comments by WMF employees (Media Viewer RfC Question 1)

(Please do not edit here if you are not WMF)

Hello @Alsee: Thanks for following up about Media Viewer. As stated last month, we are now making a range of improvements to Media Viewer, based on the results of the recent community consultation and our usability research.

For example, we just released these new features, which were announced last week:

Early indicators suggest these improvements are working:

  • Enlarge feature: You can now click on an image to enlarge it in Media Viewer, to support a frequently requested zoom function. We now log about 1 million clicks/day for that feature across all sites -- a dramatic 20x increase from ~50K clicks/day for the previous ‘View original file’ button (see metrics dashboard).
  • File: page button: You can now click on a more prominent ‘More details’ button to go to the File: page, a frequent community request. Since this feature was launched last week, global usage has tripled, surging up to ~60K clicks/day (from ~20K clicks/day on two separate links)
  • Download button: You can now click on a separate download button that's easier to find. Since launch, global usage has tripled to ~66K clicks/day on the new icon (from ~20K/day for 'Use this file' downloads)
  • Disable rates: Since these improvements were launched, global opt-outs by anonymous users have decreased by 60%, down to ~800 disable actions per day (from ~2K/day before new features).

This is consistent with our expectations, based on the latest round of usability research for the recent prototype.

Next, we plan to work on these other improvements:

This incremental improvement process will last through the end of October, using this standard development cycle: 1) design features based on data and user feedback; 2) prototype them; 3) validate them through usability studies; 4) build the features; and 5) measure their impact.

Once we have collected and analyzed those metrics in November, we can discuss next steps based on that information. As a rule of thumb, self-selected RfC discussions are not an effective way to determine default configurations about software -- and without usage data for the latest versions of the features, they are largely based on speculations, rather than factual observations.

Finally, we are also preparing a metadata cleanup drive to address remaining issues with missing machine-readable data that result in Media Viewer (and other tools) displaying incomplete information. This is the first time the Wikimedia Foundation has taken on this type of project -- and we invite community members to contribute to this cleanup work.

You can track our progress on the Media Viewer Improvements page, where we will post regular updates in coming weeks. Sincerely, Fabrice Florin (WMF) (talk) 12:33, 7 October 2014 (UTC)

Discuss and comment (Media Viewer RfC Question 1)

Yes check.svg Done: Sending notifications to everyone who participated in previous discussions on the same topic. Alsee (talk) 15:49, 5 October 2014 (UTC)

  • I see some comments about this RfC being too early, that the items in the Media_Viewer_consultation outcome have not yet been implemented. I based my personal position on the assumption that everything in that list does get implemented. I guess I assumed other people would interpret it the same way, but I'm not going to re-write the question. The RfC clearly asks people to review that consultation outcome, and people can intelligently respond based upon that consultation outcome. It was determined four three months ago that "There is a clear consensus that the Media Viewer should be disabled by default". I see no point is stalling this another 4 months 3 months... or stalling this another 999 months in "eternal development" if there exists a consensus against Media Viewer regardless of the proposed development. We do not allow someone to shove bad content into an article and then engage in tendentious discussion about "improving" that content when there is a clear consensus that no amount of "improvement" is going to permit it stay in. Alsee (talk) 22:11, 5 October 2014 (UTC)
I don't know where you get 4 months, Alsee, it was closed on July 9, which is less than three months ago. Risker (talk) 02:01, 6 October 2014 (UTC)
My apologies, I accidentally my used the July-RfC-start instead of the June-RfC-end in my quickie mental count. I corrected my comment above. Alsee (talk) 08:52, 6 October 2014 (UTC)
I think this makes it clear there is no claim of WP:CONEXCEPT here. The WMF withdrew it's hasty and unconsidered application of Superprotect, and explicitly asked that we not disable Media Viewer. Alsee (talk) 21:10, 5 October 2014 (UTC)
Clear Conexcept issue: 'WMF: don't do it'. They do not need to apply superprotect that they still have, as long as it's not done. Like the community, which does not apply protection, when it does not need to, either. That is why it's never been applied on EnWP. Alanscottwalker (talk) 22:48, 5 October 2014 (UTC)
Can we agree that we disagree, and agree not to battle on a hypothetical? The issue is moot if this RfC doesn't pass, and the issue is moot if the WMF doesn't assert Conexcept as ground to reject it. The WMF decided that Superprotect as a Bad Idea, and perhaps they will decide that trying to claim Conexcept here is also a Bad Idea. Alsee (talk) 09:05, 6 October 2014 (UTC)
No. The WMF has already said where they stand. [15] ("MV" stands for Media Viewer) [16][17]. So, the only Bad Idea is this RfC, which is actually a WP:VOTE, and which is contrary to Policy. Alanscottwalker (talk) 23:17, 6 October 2014 (UTC)
  • No idea who added the Files from the Media Viewer Survey (I can find it in the history, but can't be bothered to check), but files from a survey with so many errors shouldn't be used to influence an RfC. Just look at the survey. The second graph has 100% of editors who never edited Wikipedia, and then additional percentages of people who did, going way over the number of respondents and over 100% obviously. The summary at the top ("Media Viewer Survey results from English readers in the last 2 weeks of the survey show significant increases in the percentage of users who find Media Viewer useful, compared to the first results right after launch. From June 24 to July 8, more English readers found Media Viewer useful (62%) than not (25%), based on 496 responses for that period.") also contradicts the box at the top right, "496 responses - 201 days (March 20, 2014 - now)". And of course, the survey says nothing about Mediaviewer as compared to standard File views, so even if a majority things it is useful, we don't know whether they actually find it any better. Please don't add such files without the necessary caveats, and please indicate who added them. Fram (talk) 08:20, 6 October 2014 (UTC)
The images can be viewed here. Images do not belong in the SUPPORT/OPPOSE section. The figures in the image are based on the last two weeks of limited survey data, and I distinctly recall seeing the WMF explaining that data was exceptionally unreliable due to dismal response rates. I will say [citationneeded] in the hopes that someone can provide the cite.
The complete survey data can be viewed in this spreadsheet. The WMF summary of that data is "A majority of global respondents find the tool useful for viewing images (56% response average, 60% average across surveys), as shown on this spreadsheet. Cumulative approval by language: English 36%, French 70%, Spanish 78%, Dutch 59%, Portuguese 81%, German 30%, Hungarian 63%, Catalan 71%"". I added bolding on the English results. Furthermore their claim of "A majority of global respondents find the tool useful" is (probably unintentionally) extremely misleading. If you survey 900 bald people and 100 not-bald people you do technically obtain "90% of respondents say combs are not useful". That is also a flagrantly warped result. I recalculated the survey results to, as best as possible, accurately represent the results for global Wikipedia visitors. When weighted to match global Wikipedia readership for each language I get 39% found Media Viewer "useful", 50% found it wasn't, and 10% were not sure. Anyone who wants to check my results can see the analysis I posted at mw:Talk:Multimedia/Media_Viewer/Survey#Survey_Renormalization_To_Match_Our_Readership 6 weeks ago. And of course the survey question itself is garbage. For example mw:Talk:Multimedia/Media_Viewer/Survey#Bias: "I actually hate the interface, but I answered yes. Because it is "useful." Had I known they were using this as an approval survey I would have said no." I saw a similar comment in one of the survey text-field responses, and I have no doubt that many of the other negative text-responses would paired with "useful" votes if we could view the text-responses matched up with "useful/not useful" responses.
The WMF also has this lovely Media Viewer - English Opt-in and Opt-out Events Graph - June 27 - July 20 2014.png. The rate of opt-outs is nearly five times as high as the number of opt-ins. And I have to wonder if those opt-in results are badly inflated. When I was testing Media Viewer I toggled it off, on, off, on, off, on, off. Realistically that should be one opt-out, but it sounds like that sort of thing triggered three bogus opt-in events. Alsee (talk) 12:20, 6 October 2014 (UTC)

If I may ask: Why do people who personally would prefer to use the traditional file description pages oppose making this new media viewer an opt-out feature? Surely setting a preference once and never needing to worry about it again is a small price to pay? Powers T 14:17, 6 October 2014 (UTC)

My reasons: 1) Because all the data we have shows that the feature isn't liked by a majority of all English-speaking groups. 2) The opt-out, at least for anons, is broken. 3) Even if the opt-out for anons worked, I'd have to set it on every computer I used. 4) Even if the opt-out worked, people now link to the media viewer when linking to images, so I can't avoid the damned thing, even if the opt-out worked. 5) There is a clear consensus that it should be disabled by default. -- (talk) 14:45, 6 October 2014 (UTC)
In my case: all of that plus the fact it is inferior—making something inferior the default serves only those who developed it—it gives me an actual headache when it does its jiggling, flickering load; and I have been having to disable it on multiple-language Wikipedias, finding my way to and through the preferences in Kannada, Finnish, Latin ... it's a hassle and a half. Yngvadottir (talk) 15:38, 6 October 2014 (UTC)
It is also almost always unnecessary (it was clearly designed with galleries in mind, and most images in an article are not galleries), and actively defeats user expectations about what will happen when they click an image as well as messing with the web history. It muddles both navigation and attribution, reducing the quality of the site overall. After a few revisions, it's a lot better than it was, but the fact of the matter is that it's the wrong tool for the job. It would work much better if under image thumbnails there were a little icon you could click for something like, "Preview image", while clicking the image still brings you to the image file page. This wouldn't re-define existing behaviors, but it would allow MediaViewer as an option without enabling it in preferences. Of course, we have no leverage for a compromise, because WMF has shown that they don't give a fuck about what we think. It's really making me re-assess my monthly donation. 0x0077BE [talk/contrib] 16:25, 6 October 2014 (UTC)
Well, among other reasons, why should majority "pay the small price" instead of minority..? Also, if you really think this is no big deal, why are you still arguing instead of giving up and letting the ones who think it is somewhat bigger deal win..? I'm afraid I don't see much merit in reasoning behind your rhetorical question... --Martynas Patasius (talk) 19:31, 6 October 2014 (UTC)
  • Should we have a third RfC that; there would be an RfC after WMF completes the implementation of the outcome of community consultation? --Fauzan✆ talk✉ mail 17:25, 6 October 2014 (UTC)
  • @Fabrice Florin (WMF): Thanks for commenting. What I see missing from your thoughts is what, exactly, "Once we have collected and analyzed those metrics in November, we can discuss next steps based on that information" means. That is, let's say it's November. You've made your changes and collected your metrics. You have new numbers in hand. Now...what do you plan to do? Will you present them to the community and say "now, based on these, decide whether you want the software"? Will you have a point in mind where, if the metrics don't rise to X% of Y group, the software will be withdrawn and reworked again? What people here want to see in the discussion, I think, is a concrete course of action from the WMF. "We're reworking and re-evaluating" is great to hear, but it means little if it can't or won't be followed up with "...with X goal in mind, and if X doesn't happen, then we do Z".

    Similarly, you say that self-selected RfCs are "not an effective way to determine default configurations about software". I pretty much agree with you on that...but but but. If this type of RfC isn't going to work for you, in what manner do you want the community to comment on and support or oppose software changes in regards to this project, in particular? Petitions? Letter-writing campaigns? Skywriting "Enwp wants the WMF to change Product Q" over San Francisco? People are fighting to find, in these software deployment cases, what will get the WMF to listen to the community's will (or to their own personal opinions), and so far the WMF's response to that has been mostly of the type "Oh, you want to know how to get software recalled or paused? Well, let me tell you about the next deployment date and changelog instead!" Interesting stuff to hear, but not actually an answer to the question the community is asking, you know? I think you'd get fewer people willing to die on this hill if you gave them a sense of what they can do to change things other than dying on this hill. A fluffernutter is a sandwich! (talk) 13:49, 7 October 2014 (UTC)

@Fluffernutter:: Good to meet again, and thanks for your interest in this project.
In response to your question, our goals for Media Viewer in the next few weeks are to:
1) complete the 'must-have' tasks we identified from our community consultation;
2) verify through user research and metrics that they are working as intended (using the same methodologies as reported in previous Media Viewer updates, such as the above response);
3) fix any critical bugs for Media Viewer and these features;
4) review these results with the community;
5) wrap up development on this project.
So far, about half of the 'must-have' tasks have been released, as listed in my previous response. Here are the ones that are still in development, which we plan to release in coming weeks:
  • Easy Disable/Enable Settings from Media Viewer (#836)
  • Re-enable Media Viewer from a File Page (#719)
  • Show caption above the fold in Media Viewer (#589)
  • Pre-render thumbnails in all sizes on the back-end (#301)
  • Move license label after source (#833)
  • Make MediaViewer text larger in Monobook (#876)
You can track our progress for these tasks on our current sprint wall.
As for your other question (how the community can comment on software changes), that was the primary purpose of our widely-promoted Media Viewer consultation. We asked for community feedback, we received a lot of great suggestions, we prioritized them and developed the 'must-haves'. This consultation process seems effective for limited releases like this one. (Note that we are also exploring other ideas for community participation, as described in my response to Alsee below.)
However, please keep in mind that our multimedia team is urgently needed on other high-priority projects like Upload Wizard and Structured Data. Once the most critical tasks listed here are done, we will switch our attention to these critical projects, which have been explicitly requested by the community. But we will continue to share our Media Viewer findings with the community in coming weeks, and look forward to reviewing them together in mid-November. Thank you. Fabrice Florin (WMF) (talk) 23:22, 9 October 2014 (UTC)

  • Thanks Fabrice Florin (WMF) for your friendly and helpful post in the WMF section. I fully trust the WMF to implement 100% of the improvements that the WMF says it plans to make, and my intent with this RfC was for people to take into account all of those promised improvements. I encourage people to fully consider your post before responding to this RfC.
Nonetheless, I am very troubled that the Community Consultation process was deaf by design to any community input that did match what the WMF wanted to hear. The WMF director, Lila, promised a Community Consultation process "with no predetermined outcome". The consultation outcome looks pretty predetermined to me. If this RfC passes I think it means the consultation was a failed, broken process. The nontraditional bottom-up wiki governance and the traditional top-down WMF governance models are clashing. I sincerely hope that all of us can find a better way to bridge that gap. Alsee (talk) 18:38, 7 October 2014 (UTC)

@Alsee: You make a reasonable point that there is some tension between the community’s bottom-up governance model and the more structured decision-making process of a software development organization like ours. But as you can tell from the comments above, it is not possible to design software that will satisfy every point of view. As much as possible, we strive to make our designs consistent with evolving user interface standards, easy to understand, and responsive to the needs of our broad user base.
We have already invited community feedback, extending our development time by an entire quarter to address the most important requests. The consultation outcome was not at all pre-determined and we carefully evaluated every community suggestion before making a final selection. We focused on specific calls for improvement where we could make a difference, based on some great suggestions from our community. And we were very clear from the outset that requests to turn off the software were outside the scope of this consultation.
Going forward, we are building a more robust, quantified process for measuring the success of our projects and for gathering feedback early in the planning cycle, based on some of the ideas discussed in this separate consultation about process. We look forward to evaluating all these suggestions with our product group in coming weeks, and you should be hearing from us soon. Fabrice Florin (WMF) (talk) 23:22, 9 October 2014 (UTC)
"The consultation outcome was not at all pre-determined [...] And we were very clear from the outset that requests to turn off the software were outside the scope of this consultation." These two statements are inconsistent. In light of the latter statement, the former is mendacious. It's clear from your statement that it was a predetermined outcome that Media Viewer would remain enabled no matter what happened with the "consultation." The WMF has never given a compelling reason for insisting on imposing this predetermined outcome despite a clear consensus to the contrary. A consultation isn't a consultation if you're going to declare anything you don't want to hear as out of scope. A question that has been asked many times before but never answered: "What would it take for the WMF to disable the Media Viewer in conformance to the clear consensus on the English Wikipedia, the German Wikipedia, and the Commons?"-- (talk) 23:36, 9 October 2014 (UTC)
@Fabrice Florin (WMF): The IP address beat me to it, but I still need to say it. "The consultation outcome was not at all pre-determined" combined with "clear from the outset that requests to turn off the software were outside the scope of this consultation" is insulting. It's offensive. Statements like that just inflame the situation. Alsee (talk) 07:42, 10 October 2014 (UTC)

To people saying that since people can opt out, this isn't an issue: wrong. People on other sites are now linking to media viewer pages, not the file page. Even if you never want to see media viewer, it's thrown in your face if you browse the web with any regularity. Also, if you don't have an account, the opt-out periodically breaks. You also have to opt out on each computer that you use. There is also the issue that a lot of people don't know how to get to the file page. Some people don't even know what they're missing, with the version history and the full description. And finally, stop talking about the readers. Not a single reader has chimed in to support media viewer. -- (talk) 03:00, 8 October 2014 (UTC)

@Fabrice Florin (WMF):"The consultation outcome was not at all pre-determined [...] And we were very clear from the outset that requests to turn off the software were outside the scope of this consultation" is just a short way of saying "we will only listen to people that agree with our predetermined outcome". Do people at the WMF wonder why we consider the statements from WMF staff to be intentionally deceitful, or do you just sit back and laugh after you write nonsense like that?—Kww(talk) 04:54, 12 October 2014 (UTC)

Media Viewer RfC Question 2

The WMF made this statement when deactivating Superprotect:

Dear German Wikipedia community,

We’ve been talking a lot with many of you and at the WMF about the current situation regarding Media Viewer and site-wide JavaScript changes.

Restricting edits to MediaWiki:Common.js was a difficult decision for us. We regret that we missed opportunities to do our part in avoiding a conflict that no one wanted. At the same time, we cannot fulfill our responsibilities as the site operator when users take it upon themselves to disable functionality by editing site-wide JavaScript that is executed for all users.

We learned that the use of superprotection unintendedly created the impression that we don't trust the community. This is not the case, so we have therefore removed the restriction.

In doing so, we are investing our trust and goodwill in every community member that you will work together with us before making changes to site-wide JavaScript. And we are specifically asking you to not change site-wide JavaScript to deactivate Media Viewer or to make it opt-in.

Our commitment to you is to address open technical issues with Media Viewer based on a global community consultation process beginning tomorrow. The consultation page will address the scope, intent, and timelines of the consultation will be announced on all projects and will be open-ended. We will update here with the details when the page is live and will support German language participation.

We ask you to work with us in good faith in the upcoming month and through this effort define a better, closer way of working together in support of our common goals.

Sincerely, Lila & Erik

Question Two. In light of the statement above, should Question One carry the following implementation terms:

  • Place a 7 day hold against Community action to implement this RfC.
  • Officially deliver the closing results to the WMF.
  • Express our desire to work together with the WMF before making changes to site-wide JavaScript.
  • Express our desire to work with the WMF in good faith, and our hope for a better closer way of working together in support of our common goals.
  • Formally request the WMF to implement this configuration change for English Wikipedia.
  • 7 days after this RfC closes our JavaScript experts and other admins are directed to take any steps necessary to implement this RfC, if such steps are still needed.

NOTE: Question two shall have NO EFFECT if question one fails. You can oppose question one and still support question two, just in case question one passes.

Support (Media Viewer RfC Question 2)

  1. SUPPORT as RfC author. I want to make every effort of develop a more collaborative relationship between the community and the WMF. Alsee (talk) 18:01, 3 October 2014 (UTC)
  2. Support. First we should try to work with them, FWIW. Then, when that will fail, fiat justitia ruat caelum. BethNaught (talk) 16:36, 5 October 2014 (UTC)
  3. Support. The seven days give WMF sufficient time to implement this. Features that are switched on by default and problematic in regard to copyright law (two clicks to access complete copyright information) lie within the domain of the community. How can we with good conscience use images at en:wp if, by default, this feature hides essential copyright info? This is a problem of the community as many of them work with their real names and have consequently a different perspective than the WMF who sits in the safe harbour. --AFBorchert (talk) 17:58, 5 October 2014 (UTC)
  4. Support. This seems a reasonable proposal. LynwoodF (talk) 18:47, 5 October 2014 (UTC)
  5. Support. I can't see why this would controversial at all. Powers T 19:23, 5 October 2014 (UTC)
  6. Of course. We should try to work with them, but community consensus must be enforced as long as it's technically possible. Nyttend (talk) 19:31, 5 October 2014 (UTC)
  7. Support. I don't know about all the details, but I'm coming from a position that we, editors and WMF, are all in this together. --Tryptofish (talk) 20:17, 5 October 2014 (UTC)
  8. Support per BethNaught. Double sharp (talk) 01:40, 6 October 2014 (UTC)
  9. Support. We should try to work with the WMF since we're all in this together. -- King of ♠ 02:43, 6 October 2014 (UTC)
  10. Strong Support -- CONEXCEPT clearly was never intended to apply to this kind of situation. This does not implicate any basic principle of the movement, nor is there a compelling technical reason to oppose a return to how things were for over a decade. I disagree with the time frame. We've been stuck with this terrible, shoddy, ill-conceived software for what, five months now? It needs to be returned to opt-in immediately. The anonymous opt-out is broken and it keeps on returning. This has gone on far, far, too long. -- (talk) 06:42, 6 October 2014 (UTC)
  11. support -jkb- (talk) 09:21, 6 October 2014 (UTC)
  12. Support. It would be nice to have more options, but no one suggested anything else and this option does seem to achieve some balance between conciliatory and antagonistic approaches... If WMF wants to reconcile with us, they have 7 days to do something, and if they do not, why should we give up just because resisting makes their life harder? If they do not act as friends with us, why should we act as if we were friends with them? Of course, it is to be understood that simply turning off Media Viewer for everyone is perfectly acceptable - if WMF doesn't like it, they are free to offer us an alternative we would prefer. Or, if they really want to use their legal rights (that some opposers discuss), they are free to ban everyone at the price of a public relations disaster (I'm pretty sure the editors will survive, I am not so sure about WMF). Somehow, I doubt they will actually do so, thus legal rights seem to be a red herring here... --Martynas Patasius (talk) 21:45, 10 October 2014 (UTC)
  13. Support. The putsch by WMF against its employers, the communities, that generate all donations with their content creation and maintenance, was extremely hostile and must never happen again. --♫ Sänger - Talk - superputsch must go 10:35, 12 October 2014 (UTC)
  14. Support And also go so far as to request that certain of the provisions such as official presentation of results be made regardless of question 1.

Oppose (Media Viewer RfC Question 2)

  1. Per my my oppose and policy (WP:CONEXCEPT section 1 and 4) above, and to repeat AFBorchet's argument [18] (and similar) shows a misunderstanding or incompetence regarding law, and does not accord with current layout. Moreover, if you think the Foundation is doing something illegal, than the remedy is not an RfC or a WP:Vote, per WP:LAWSUIT. Alanscottwalker (talk) 18:43, 5 October 2014 (UTC)
    While I don't agree with many of the things the WMF is doing, when it comes to legal issues I think it is always best to defer to them. They have a team of professional lawyers working for them who were hired for their expertise. If they believe that MediaViewer does not violate licensing requirements, then I trust them. -- King of ♠ 02:43, 6 October 2014 (UTC)
  2. I'd support this if only the first 5 bullet points were present, but I can't support it given "7 days after this RfC closes our JavaScript experts and other admins are directed to take any steps necessary to implement this RfC, if such steps are still needed." Jackmcbarn (talk) 17:50, 5 October 2014 (UTC)
  3. The WMF is supposed to serve the projects, not the other way around. Their removing the super-protection is too little, too late, and they should not be setting conditions. Their forcing software changes on the projects that impair our ability to execute our mission here is indefensible and is yet another indication that they have forgotten what we are here for and what they are supposed to exist for. No negotiation. Throw this thing out. Yngvadottir (talk) 21:11, 5 October 2014 (UTC)
  4. Per Jackmcbarn I agree with all but the last bullet. While I think Mediaviewer should not be the default, I don't think that we should be tempting the WMF to reinstate something like super-protection. Whether we like it or not, these are still their servers, and while WMF policy gives users wider latitude for making major site changes than just about any website I can think of, I don't think we should push it. There has to be a better diplomatic solution before we declare war. --Ahecht (TALK
    ) 02:34, 6 October 2014 (UTC)
  5. The 6th bullet point seems like the wrong approach. The others would be okay if the first passes ( granted I am opposed to that at this time as well ). PaleAqua (talk) 15:12, 6 October 2014 (UTC)
  6. Bullet 6 as it stands is a bad idea; we should not commit to this until we know it will work. That is to say, we shouldn't hold this RfC until we've already written and approved a JS script that will accomplish this. Frankly, I'm not sure that any solution we come up with will be good enough. This is putting the cart before the horse. Writ Keeper  21:50, 7 October 2014 (UTC)
  7. A declaration of war against the WMF if they fail to comply will just lead to the return of superprotect or mass blockings. This isn't a major enough issue to justify an internal civil war. Mogism (talk) 00:24, 10 October 2014 (UTC)
  8. Per Jackmcbarn, Mogism, etc. There's no need for any party to be antagonistic here. — This, that and the other (talk) 10:12, 10 October 2014 (UTC)
  9. Per the above comments. Giving the WMF 7 days to do what you want isn't collaborating; it's tantamount to a declaration of war. A war is a waste of energies and will end up damaging the project, which seems a little like cutting off one's nose to spite one's face. Ca2james (talk) 16:21, 10 October 2014 (UTC)
  10. Not only is the sixth bullet point not technically feasible (see below), but it is also absurd and objectionable to talk of directing all admins and Javascript experts to take any steps necessary to implement this. What will we do to any that don't snap to attention and rush into action - denounce them as enemies of the Party? NebY (talk) 19:24, 13 October 2014 (UTC)
  11. Per WP:CONEXCEPT. This whole proposal is muddle-headed and wrong. Hawkeye7 (talk) 02:12, 15 October 2014 (UTC)

Neutral (Media Viewer RfC Question 2)

  1. I don't care how the WMF is informed, how Media Viewer is disabled, or what schedule is followed. I just want Media Viewer disabled by default for all users (including anonymous readers) within a month of the RFC being closed. Assuming, of course, that the decision is "disable by default" or "remove it entirely". Or even "kill it with fire" but that last one presumably violates the rules about civil discourse. — Preceding unsigned comment added by (talk) 01:54, 6 October 2014
  2. "Good faith"? This is not a question of "faith". The community disabled the media viewer AFTER they saw what it was doing. —Neotarf (talk) 23:38, 7 October 2014 (UTC)
  3. Neutral - The hostility is unfortunate. It may be that the WMF started out by taking a hostile attitude toward the community, but we don't need to perpetuate that hostility. Robert McClenon (talk) 19:08, 13 October 2014 (UTC)
  • Abstain. This is pointless. First off, there is no obligation implied or otherwise that the WMF comply with any RfC in their charter or bylaws. Second, there have been many highly substantive changes at the WMF, including a new Executive Director that has yet to oversee a full development cycle and a brand new VP of Engineering that has yet to oversee anything at all.
Please, consider this; is it the community's will that we don't give them a chance? I would like to see what these leaders at the WMF can do before everyone dogpiles on them- especially Lila. 2-3 months should be more than enough to see which direction they plan to lead the community in. Or maybe we'd prefer the immediate gratification of cutting off our nose to spite our face? Here's an alternative plan: as a community, let's give them the support they need to accomplish our mutual goals. If we step up; they will either step up with us or fall down the staircase. So how bout we step up and see what happens? -wʃʃʍ- 00:36, 8 October 2014 (UTC)
  • "...see what happens"? This is what we've been doing for months now. And thanks for lending support to the nose thumbing directed at consensus by your pat referral to "by laws". Most governments of the free world are subject to the same laws as are the people -- but evidently not here at Wikipedia, something that is supposed to be a pillar of community team work. -- Gwillhickers (talk) 23:55, 9 October 2014 (UTC)
By "months," you're talking about the 4 months the new ED has been on the job? Sure. And while we're at it, I'd like a full list of substantial changes the VP of Engineering has made in the several days we've been waiting after he started.
This is absurd. It took years for these problems to build up. The community demanded change, and it got it. Now you expect the new management to clean things up yesterday? Give them a little time. Or continue to push these half-cocked RfCs while everyone else gets back to work with renewed vigor as the true benefits of the changes the Board and Lila have made become apparent. Worst case scenario, change doesn't happen fast enough or goes the wrong way, and you can get back to these toothless and skin-free RfC's in 6 months or so. Why not give them a chance and see where they take things? -wʃʃʍ- 21:23, 14 October 2014 (UTC)
Wllm, please stop discussing things as if you are "from the community" and not "from the WMF". If you want to see what the leaders of the WMF can do, just go home, where you have every opportunity to observe that. Don't pretend to be "one of us" with your "we" for the editors here, and "they" for the WMF, when all you are is a WMF mole. Fram (talk) 10:42, 10 October 2014 (UTC)
I'm a WMF mole? No, Fram, I'm a human. Just like you. And I show you the respect that every human deserves. I'd appreciate it if you would reciprocate by not trying to exclude me from community debates.
I am part of this community, whether you like it or not. On the flip side, I am not part of the WMF and don't represent them in any way. No doubt many WMFers would find your suggestion that I'm some sort of mole as ludicrous as I do, considering my outspoken criticism of certain aspects and actions of the WMF in the past. I'll go toe to toe with you about the "merits" of these silly petitions, and I can do it without resorting to bad-faith attempts at discrediting you. -wʃʃʍ- 21:02, 14 October 2014 (UTC)
  • Erm, I dunno. If I'm reading this correctly, the general thrust is "Let's see if the community is OK with the Media Viewer as default, and if it is, nothing much happens, but if its not, we'll make it the not-default using Javascript, OK?". Right? I think I'm reading the intent right. Hrm, don't know about this... I'm a little unsure if the community should be doing this, and here's why: the community that is voting on Question 1 is basically editors, mostly long-term heavily involved editors. Not entirely but skewed in that direction. It's only human nature for people to want to have an environment that is best for them personally and to conflate that with the best environment generally, and also only human nature for people to have difficulty getting inside the shoes of people who are very different from them. "'It's a good thing we don't all like the same things', said the Scotsman -- 'think of what a shortage of oatmeal there'd be!'" is, after all, funny because there's a kernel of truth in there.
To avoid the first and do the second takes effort, practice, and the proper mindset. It's not something that everyone can do. That is why they don't just grab the nearest programmer to do the user interface design and so forth. So I guess one of the questions on the table is: Who is best qualified to suss what Mrs Pinckney Pruddle of Sandusky, Ohio, probably expects to happen when she click on an image.. Is it the community of experienced Wikipedia editors? Is the WMF? Is it someone else? I don't know, but I'm not confident that it's the community of experienced Wikipedia editors as opposed to the WMF. Herostratus (talk) 15:01, 13 October 2014 (UTC)

Reserved for official comments by WMF employees (Media Viewer RfC Question 2)

(Please do not edit here if you are not WMF)

Please see our response to the first question above.

Discuss and comment (Media Viewer RfC Question 2)

(The following thread was split off of #Neutral (Media Viewer RfC Question 2) by Alsee (talk) 14:54, 9 October 2014 (UTC))

We've given the WMF months. We're still stuck with the shoddy, ill-conceived software that is Media Viewer. We've told them we don't want it. They responded by saying, "Hey, we're listening to you. Give us suggestions." And then when they summarize what we said, they ignore the dominant feedback that people don't want Media Viewer, instead focusing on little details but pretending they've made vast improvements. It still stinks. It shouldn't be replacing the file page for anyone. The community is the project, not the WMF. The WMF is a useful legal entity to do the things that the community can't. But they've deluded themselves into thinking they're the boss and they aren't. This is unacceptable. They absolutely are bound to abide by an RfC of this nature. Their whole purpose is to serve the community, like it or not. The community has given the WMF months to do the right thing. It shouldn't give them even another hour because it looks like the WMF still doesn't get it. Disable Media Viewer immediately. And if the WMF pulls another Germany, ask the stewards, on behalf of the community, to lock the WMF out so that community consensus is honored. The WMF has burned all their good faith. It's time that the nightmare that is Media Viewer ends. -- (talk) 02:56, 8 October 2014 (UTC)

I doubt that most of those who don't like MV would support such a dramatic approach to the issue. And, when it comes to WMF being the boss, there are very few assets in this project that aren't given away for free. Those assets include the domain names. The WMF and the domain names are not sold separately. If you don't like the way the WMF is running things, and you feel you've given an organization with a new chief executive just 4 months on the job enough time to fix everything, your most productive path is to fork the project. Please. There are plenty of people who want to get back to building a great encyclopedia on, and I venture to say that anyone who isn't interested in working constructively with the WMF won't be missed much.
It's time to call all bluffs: work with us or fork off already. In either case, please stop wasting people's time on these silly and ultimately toothless petitions and RfCs. -wʃʃʍ- 06:34, 8 October 2014 (UTC)
You're not calling any bluffs. I have no interest in working with anyone on Wikipedia and as evidenced by my refusal to actually create an account. I've never expressed any interest. You've lost nothing no matter what I do. I'm not pretending otherwise. I'm not at a point in my life where writing or editing an encyclopedia—or working on any wiki—holds any attraction for me. I'm just sick of the disaster that is Media Viewer being justified in the name of people like me who just read. I'm sick of the complete deafness in the WMF to any feedback about Media Viewer that doesn't fit with the "Multimedia vision" some middle-manager at the WMF came up with one day and now it's the plan, hell or high water—without any any meaningful community consultation. All this, while pretending they're listening. I'm incensed that the community that is actually the heart of the project is being ignored by the legal organization created to serve them when the community spoke with a clear and unambiguous voice that they didn't want this product. And I'm livid that the organization which no longer represents the community it was supposed to is raising funds in the name of that community in order to do more of the same but implying that the money is needed for infrastructure. This is deeply misleading and offensive.
Lila had plenty of opportunity to deal with this better at a very early stage. The negative feedback after the initial rollout was swift and overwhelming. It would have been a good time to rollback and reevaluate. Instead, delay, delay, delay. Let's lock a community out of its wiki when it does something we disagree with—and let's write an emergency software patch on a Sunday morning to do it. Oh, it's been out for months now... we can't roll it back now. It's a rigged game and it's bullshit. And I can't believe Lila, no matter how new she was, had no idea what she was doing.
I'm sick of Media Viewer. I can't get rid of it. Broken opt-out for people without accounts—supposedly the people that this was written for. Media Viewer showing up in external links to the site which I can't fix, even when the opt-out is working. If I cared about the mission, I might be upset about forcing this down the throats of other people similarly situated. But realistically, never show it to me again, and while I'll still think the WMF is rotten, I won't think of it until I see a stupid, misleading advertising banner asking for money the WMF doesn't need. Or the next stupid piece of software that nobody outside the WMF asked for is rolled out and makes the site more annoying to use. -- (talk) 07:40, 8 October 2014 (UTC)
@Wllm: Supporting this IP. They are bang-on right. I have actually raised the issue of forking. I believe it's long past time. The WMF is a ridiculously inflated appendage that is swinging the project around - WP:FLOW will be even more of a disaster, and yet the WMF refuses to stop. The train of mistrust of the WMF left a long time ago thanks to this string of unjustifiable and mismanaged software changes. Yngvadottir (talk) 19:03, 8 October 2014 (UTC)
@Yngvadottir: I'd like to hear your reasoning in the current context, not that of "a long time ago". The Board realized there was a problem. 4 months ago Lila took over as Executive Director. Just days ago a new VP of Engineering was introduced to the community. We already see things changing, although we haven't yet seen a full product cycle in which communication and trust is established from the get-go as they should be under these 2 leaders. This is the current context, and it's quite different from previous situations. Please explain why it makes more sense to fork during this period of great change, rather than giving these people and the Board a chance to fix what's broken. -wʃʃʍ- 00:22, 9 October 2014 (UTC)
I've seen no evidence of even a single change, just lots of marketing mumbo jumbo. I tend to agree with Yngvadottir that the time for a fork may be fast approaching, particularly as Jimbo has said that he's prepared to pay for the necessary server(s). Eric Corbett 00:28, 9 October 2014 (UTC)
I've got to agree with Eric here - if there is institutional change going on as far as how the WMF will plan, deploy, and approach the community about software, that change hasn't come through to the community yet that I've been able to see. I don't doubt that they're probably trying to change, but if you're saying "But things have already changed for the better, and will keep changing like that", and we can't see any change...I dunno. Maybe they need to change harder? A fluffernutter is a sandwich! (talk) 00:39, 9 October 2014 (UTC)
I've been spending a lot of time on the wikimedia servers and even talking with the WMF director. She hasn't had the job very long, and she was honestly blindsided by the community reaction to Superprotect. In her last job as Chief product officer it was perfectly natural for management to lock down the javascript like that. She's been getting a crash course in who we are and how we work. She is planning some change in MWF approach to things, but I can't tell yet whether she plans to collaborate with us or whether it's going to be more bogus "Community Consultation" like they had on Media Viewer. I suggest lowering the pitchforks until we see what happens next. Alsee (talk) 03:57, 9 October 2014 (UTC)
But it's well beyond time for things to change, hence the pitchforks. Eric Corbett 04:23, 9 October 2014 (UTC)
I started this RfC, I'm lugging around the biggest heaviest pitchfork here. I suggested lowering the pitchforks, not dropping them. I don't want to get jabby if we can avoid it. Within a week of RfC closing, probably sooner, we'll know whether the WMF is escalating or de-escalating the situation. Alsee (talk) 16:24, 9 October 2014 (UTC)
Here are two examples of changes of a very different nature. Let's start with something very concrete. Lila hired a new VP of Engineering. If we're talking about change WRT the software the WMF develops, it doesn't get much better. Now for something a bit less tangible. I just skimmed over Lila's talk page. It looks nothing like Sue's. Lila is clearly listening, asking questions, and taking action on the feedback, which is apparent in what she's said there about the Flow project.
I think you guys are talking about not seeing the benefits from change yet. Well, big changes have happened with more to come, no doubt, and they will turn in to results in a few short months. Is it really unreasonable to suggest we wait that long before we pick up the pitchforks and light the torches? -wʃʃʍ- 00:51, 19 October 2014 (UTC)
The only concrete change I want here is Media Viewer being disabled by default, as per consensus. This ugly baby needs to die and the people who forced it down our throats need to find new employment. That would be concrete change, not the organizational lip service you've talked about. -- (talk) 02:14, 19 October 2014 (UTC)
@Wllm: First I've heard of anything except the change in Executive Director. Of course you intend to stay around and see what the WMF does - you came in with her, into the WMF. The thing is, the WMF is not the management of the projects - it is a service adjunct to them. We are the ones who do the work. If your partner was "blindsided" as Alsee says, then she did not research the job. The Visual Editor debacle and before that the community's response to the removal of OBOD without providing IP editors with any replacement notification of posts to their talk pages should have provided ample history regarding the community's response to their work environment being mucked up in the name of - full employment for programmers? poorly defined change for change's sake? - and the manner in which the volunteers here reach decisions was surely in the briefing sheet (this is the second time I see you referring here to "wasting time"). For that matter, I understand the WMF refused some time ago to implement a change in respect to creation of new pages that had been decided upon by English Wikipedia. And preparations to force WP:FLOW on us are still barreling along. No, I don't see any changes on the WMF's part. The one recent piece of news I am aware of is that Jimbo insulted all of us at the latest con. Yngvadottir (talk) 04:11, 9 October 2014 (UTC)
I'm sure Jimbo did so thoughtfully and with kindness though. Eric Corbett 04:38, 9 October 2014 (UTC)
Was that when Jimbo said something to the effect that those who aren't here to build an encyclopedia in good faith should find something else to work on and leave the rest of us to do what we love to do in a constructive environment? I can't say I agree with everything Jimbo says, but I'm 100% on board with that. The petty politics and nastiness that is apparent in all too many comments on this page has got to go. -wʃʃʍ- 21:35, 14 October 2014 (UTC)
  • Which "javascript experts" are we talking about here? The self-appointed ones? The ones who took a class once and totally know what they're doing? The ones who have admin rights, and thus must know what they're doing? The ones who heard about this piece of js from someone who totally knows what they're doing, so the code must be ok? The whole reason the js-editing debacle turned into such a disaster last time is because we don't have a designated team of "javascript experts" in the lay community; instead we have a team of admin-type people who have the technical ability to edit mediawiki pages but who may or may not have the slightest idea what they're doing. If a mediawiki dev(s) or other actually-provably-qualified-to-edit-mediawiki-code person is willing to write javascript that will a) enact the community's will and b) not be buggy, prone to breaking things it shouldn't, or otherwise degrade site performance, then yeah, let's talk about the cases where the enwp community will use that code, and how we're going to limit the ability to edit that code to that person or people. But unless you're going to limit this implementation to those qualified people only (perhaps through limiting editing of mediawiki space to those actually responsible for the mediawiki software? oh, wait...), we're just going to land back in a case where a well-meaning person throws in a hack, breaks things sitewide, and has to be reverted while everyone gets very angry and shouts rude words. A fluffernutter is a sandwich! (talk) 18:57, 5 October 2014 (UTC)
If I'm not mistaken there's significant precedent of community management of Javascript, and I trust we have competent people for the job. Nonetheless, this RFC already explicitly designed to address your concerns. You can OPPOSE question one and SUPPORT question two. Alsee (talk) 21:29, 5 October 2014 (UTC)
Well no, this isn't addressing any of my concerns, because my concern in this case is that Question Two is written in a way that's just unworkable, and I'm worried to see people voting either way on it without thinking about that. The last time around, we had someone who didn't know javascript "fix" mediawiki to match the community's will by breaking it, and there's nothing in this proposal that stops the same thing from happening again: "The community said to do X, so even though I don't know if this patch will work, I'm going to put it into our local setup, because the community's will must be done, and right now!" If we want to play hardball in this way - forcing through software changes to do what the WMF won't, taking responsibility for producing our own code that supplements or replaces theirs - then those software changes had better be absolutely bulletproof and implemented according to best practices, not hacked together by whoever happened by and volunteered themselves, whether they knew what they were doing or not. The "our javascript experts" in this proposal will end up being "whoever shows up" unless you have actual mediawiki or javascript experts who have pre-emptively signed themselves up to be in charge of this software change. A fluffernutter is a sandwich! (talk) 22:22, 5 October 2014 (UTC)
    • I think instead of focusing on the "who" and instead on the "what" would be helpful here. I think it would be good policy that soon after starting an RfC that you send a notice to the WMF developers that there is an RfC, and that X is the code we currently will use to implement it. This means the initiator of the RfC needs to either supply the code or find someone who can write it fairly early in the process. If there's anything wrong with the particular code - will it break something else - then we'll gladly work with any feedback from the developers. But it's not an invitation for WMF to overturn or alter the results of the RfC, but rather is an invitation for them to give feedback and help the community implement the RfC without disrupting anything else. VanIsaacWScont 00:01, 6 October 2014 (UTC)
I think it's safe to say that the WMF has been notified, chuckle. I'm a programmer, but I haven't worked with Javascript specifically. During the Superprotect event German Wikipedia made a very hasty change which fully disabled Media Viewer rather than setting it to Opt-In. I'm sure that javascript has been widely examined and the opt-in version is well known by now. I did consider adding something to the RfC setting up public review process, but I didn't want to complexify the RfC. Alsee (talk) 19:41, 7 October 2014 (UTC)
Do you know of a JS solution to this? I don't know if I'd be considered a Javascript expert or not, but I am also a programmer, and I have worked with Javascript quite a bit, including here on Wikipedia; I haven't heard of a JS solution yet, and I don't really think one is possible that will be good enough. The problem is that the current MV opt-out preference is in a place where we can't really do much to it. We can look up its value, or change it with an API call, but the problem is that it is on by default right now, and we can't change that directly through JS (since it's not a gadget). We also can't distinguish through JS between people who have deliberately checked it and people who just haven't touched the setting at all(I think we can through the DB itself, but both cases look the same to the JS), so we have no way of telling the difference between someone who has slready opted in and someone who has just registered and has simply not changed the default setting. We could create our own on-by-default gadget to physically disable the MV, but then there are two different settings on two different pages that both have to be enabled to use MV, which is bad (though undoubtedly the two-key approach will appeal to some in the audience...). I'm not sure there's any good way to do this without something more heavy-duty than JS. Writ Keeper  21:50, 7 October 2014 (UTC)
Yeah, I wasn't referring to this matter specifically, but to a general principle of conducting RfCs in the future. If an RfC will require a change to site code or settings, we should have that code established early on, so that the developers can submit any feedback on unintended consequences of the proposed code or settings changes. VanIsaacWScont 05:10, 12 October 2014 (UTC)

I'd say we should consider more than one option... For example, what is going to happen, if the answer to this question will be "No."? Will nothing be done, or will someone disable MV without informing WMF? Also, perhaps we have more "creative" ways to do something (like, just to "brainstorm", showing a link to the "Open letter" whenever a request for donations is shown)? --Martynas Patasius (talk) 22:48, 5 October 2014 (UTC)
Oppose getting into stupid pissing contests with WMF. The terms of Use we all agreed to make it clear WMF controls and decides what the technical infrastructure is. There's nothing wrong with having discussions about how software features impact our editorial work and conveying the consensus of such discussions to WMF, nor in criticizing there actions collectively or individually (as allowed by the "good faith criticism that does not result in actions otherwise violating these Terms of Use or community policies" clause of those terms). But intentionally making edits to alter the function of the software in a manner known to be contrary to WMFs wishes is wrong. NE Ent 21:38, 13 October 2014 (UTC)

Could you, please, cite the actual text to that effect? I don't see anything that could be interpreted as a promise to obey WMF on software matters without question. Of course, I might have missed it... Or, perhaps, I have looked at a different version ([19])... --Martynas Patasius (talk) 22:02, 13 October 2014 (UTC)


  1. Add a toggling "unwatch"/"watch" link to the "diff|hist" links at the start of each entry (and use a dot/interpunct as the separator between them rather than a pipe?);
  2. Means to view/reorder the list in reverse, i.e. according to how long pages on the list have remained unchanged.

I don't think these are persistent / perennial or already possible, but apologies if either or both are either or both (and please indicate how/where I should look). Sardanaphalus (talk) 11:54, 8 October 2014 (UTC)

  1. Have a look at User:Js/watchlist.
  2. That's not trivial, since the watchlist is getting its data from the recentchanges table, which only covers the last 30 days. So for showing anything older than that you would need not just a change in sort order, but a different way to extract these data from the database. It's probably possible, but would be less efficient. — HHHIPPO 21:41, 8 October 2014 (UTC)
  • Thanks for your responses and sorry for the time before this one. I've just installed User:Js/watchlist – which looks interesting – and, yes, I wondered if the "reverse/inverse watchlist" might be relatively demanding. On the other hand, if the software has to work through a watchlist to see which items have been changed in the past N hours/days, wouldn't it be looking up when each item had last been changed and so would only be a step or two away from producing a list which it could then present in reverse..?
Regards, Sardanaphalus (talk) 23:02, 15 October 2014 (UTC)

Proposal Trusted Tester user group

On 20:39, 14 May 2013 (UTC) I suggested WMF to create "trusted testers" user group. Someone from WMF called that a good suggestion. After that, I don't know what happened.

I can see someone has started an RFC in this page on MediaViewer. I clearly support that RFC, but, I am too reluctant to write there. Does WMF care?

Anyway, currently when WMF makes a change (call it VisualEditor, MediaViewer etc.), it is forced on all/thousands of editors and for next many weeks, hundreds of editors report dozens of errors, and WMF keep on fixing/improving those.

Can't we create a "trusted tester" (TT) user group like Google or Microsoft? The trusted testers (TT) will be the first editors to test a feature and report good" or "bad" or anything. --TitoDutta 17:41, 13 October 2014 (UTC)

I don't think there was any shortage of people testing MediaViewer - the complaints about it started when it was in beta and have not stopped to this day. One of the biggest problems with MediaViewer is that it's been imposed not without consultation with the community, but rather over the community's vigorous protests. I'm not sure why we need a separate "Trusted Tester" user class when people can always opt in to the beta features from the WMF labs. 0x0077BE [talk/contrib] 17:53, 13 October 2014 (UTC)
Agree, no need for a usergroup that gets forced features that can just be handled by opt-in. I don't see a problem where "unauthorized" testers were using beta features that caused harm. — xaosflux Talk 18:11, 13 October 2014 (UTC)
The reply said:
"That's a good suggestion :). I know that Erik (Eloquence) is very keen on the idea of deploying things in a beta on enwiki, in future, rather than testing elsewhere; hopefully this will allow us to discover problems 'natively' before they become a problem for many users. Okeyes (WMF) (talk) 20:49, 14 May 2013 (UTC)"
Beta came six months later: Wikipedia:Village pump (technical)/Archive 120#Introducing Beta Features and Media Viewer. PrimeHunter (talk) 00:31, 17 October 2014 (UTC)
I see no benefit from a user right here. There is already far too much software-enforced hierarchy. If a group of "neutral" testers is to be identified so that "people who just want to find fault in everything" can be ignored, you can do that socially. To deny random users the opportunity to test and comment on beta features before they are made mandatory would be yet another major step backward in terms of community input. Wnt (talk) 21:36, 17 October 2014 (UTC)

This is not a user right. This is a user preference. Add a checkbox to the preferences panel "Always enable new experimental features." Oiyarbepsy (talk) 00:48, 23 October 2014 (UTC)

"Notable residents"

I suggest that any person who is listed as a "notable resident" (or similar) in any article should be removed from the article unless that person has an article named for them. There are far too many of these "notable residents" who are mentioned in many articles without justification. If they don't have an article named for them then they are not notable and therefore not "notable residents". Jodosma (talk) 19:27, 14 October 2014 (UTC)

I'm amenable to a third-party source discussing the individual as an indicator of notability, but if there's no article or sourcing, I can't imagine why they'd be listed. DonIago (talk) 19:36, 14 October 2014 (UTC)
All over Wikipedia individuals are mentioned as if they are "notable", e.g. in articles about colleges or schools or minor authorities (councils and the like), the tutors and senior members of the staff (or council) are often mentioned, in many cases stated in the article as being "notable", as if the statement that they are notable makes them notable. I would like to remove all of these if they don't have an article named for them. When these people are named then the person naming them should first of all create the article about them. This kind of thing also occurs in many articles about businesses or companies, with no justification. Jodosma (talk) 19:57, 14 October 2014 (UTC)
I think it is fine if a no-article notable resident is listed along with a third-party reference that establishes their notability. This sort of entry aligns with WP:REDLINK, the expansion of the encyclopedia. Binksternet (talk) 22:13, 14 October 2014 (UTC)
I agree with Binksternet. We do not tell WP:VOLUNTEERs that they must first create an article to be permitted to make a small improvement to another article. Your definition of WP:Notable is wrong: a person is notable when s/he qualifies for a separate article on the English Wikipedia. You can be notable for decades before anyone actually starts writing the article.
If there's no source for such an entry, then please find one yourself. If you're not willing to make that much effort, then add a {{fact}} tag, and check back in a couple of months (yes, months, not days) to see whether anyone has done so. Don't just blank them because you don't like them and can't see the value in them. WhatamIdoing (talk) 22:19, 14 October 2014 (UTC)
If red links obviously merit an article leave them. In most cases they do not and should be removed there and then.Charles (talk) 22:26, 14 October 2014 (UTC)
Comment: Red links in articles are different than those found in links lists. The ones in articles probably have a chance of being expanded someday, probably by the person who put it there to begin with. Lists are different, however. Any name can (and repeatedly are) added to lists that are never, ever going to be notable, or are actually tagging/vandalism. If they are in a list, the name, item, or whatever needs at least a reliable source citation if there is not an existing article in Wikipedia. Red links in wiki-lists are meaningless. PS: "Notable Residents" sections are, imo, list sections. GenQuest "Talk to Me" 23:30, 14 October 2014 (UTC)
The Notability standard only applies to creating an article. The standard for including information in an article is a lot lower. Alsee (talk) 10:32, 16 October 2014 (UTC)
On the other hand, many of these additions are supposedly living people. I say supposedly because they could be someone's boyfriend, dog, worst enemy, whatever. With no sources we simply don't know and such entries may be WP:BLP violations if not simply promotional. A fact tag isn't enough to prevent a BLP violation. Dougweller (talk) 16:10, 16 October 2014 (UTC)
I agree that they are essentially lists, which on Wikipedia are advised to have inclusion criteria so they don't become indiscriminate, and all content on Wikipedia is required to be verifiable. Often content in lists is verifiable via the bluelink, so if an entry in this sort of list is redlinked or not linked at all, it is probably non-verifiable and should be flagged; however Dougweller is right that such entries in lists of people are likely enough to be information about living persons (who are alive unless confirmed deceased) which is to be removed immediately if not verifiable. You may also be interested in WikiProject Laundromat which is aimed at cleaning up such lists. Ivanvector (talk) 16:28, 16 October 2014 (UTC)
If someone wants to put a non-linked name in a list, it is incumbent on them to show why that name belongs on the list. Otherwise, it is OR and should be immediately removed as such. Lists inclusions are different from inclusions in articles; per the the comments above. GenQuest "Talk to Me" 01:20, 17 October 2014 (UTC)
No, that's not OR. "Original research" involves material that has never been published, anywhere on the planet, at any time. "Uncited" is what we call material that someone has added without showing why that name belongs on the list. WhatamIdoing (talk) 19:31, 17 October 2014 (UTC)
I should've also included "Uncited" above, as both apply. In either case, those entries can be removed immediately, no tagging necessary, per BLP. GenQuest "Talk to Me" 22:41, 17 October 2014 (UTC)
The above discussion appears not to consider the situation where a good, referenced source document says "Bloggs, Smith and Jones did a very important thing (X)" but only Bloggs and Smith have WP articles, AND Jones was otherwise so non-notable that no WP article for him is even likely. IMHO his name (without a redlink) belongs in the articles for Bloggs and Smith (and for X if it has one) It also belongs (with ref but no redlink) in a list of people related to X, or of people in an occupational group etc related to X. Downsize43 (talk) 10:37, 19 October 2014 (UTC)
I think in a case like this it belongs in the article; it does not belong in a list of people associated with the subject. Article content does not have to be notable. The best rule for people in such a list is that they either have to have an article or be obviously qualified for one--with a reference. DGG ( talk ) 18:31, 20 October 2014 (UTC)

Blank or Delete the User Talk Pages of: Users Who are Banned Indefinitely, Users who are Revoked Talk Page Access Indefinitely, Accounts Associated with those who frequently attack Wikipedia

I was thinking if somebody designed a bot to blank un-used/unusable User Talk Pages (such as some of the ones referenced in the headline) it could save Wikipedia's servers some space in the long run (the content of the pages might add up, trolls might realize they could waste Wiki resources by creating a very large or resource intensive user talk page and then purposefully get banned to decrease the likelihood of such content being deleted, etc). Thoughts? — Preceding unsigned comment added by (talk) 03:02, 16 October 2014

Actually, that would slightly increases storage usage. Blanked and deleted pages are still stored in history (even if that history isn't visible to normal users). The proposed edit would just be adding to the page history. Alsee (talk) 10:41, 16 October 2014 (UTC)
A blanking might remove other things like link table and search index entries. I don't know the net effect but see Wikipedia:Don't worry about performance. It's best to keep the talk page content if some of their actions are examined later. PrimeHunter (talk) 11:07, 16 October 2014 (UTC)
Also, indefinite blocks are not necessarily perpetual; they just don't expire automatically. It's not unusual for an editor to appeal an indefinite block and return to making valuable contributions. They should be able to do so with their talk pages intact. Furthermore, some editors return by socking; old talk pages help us deal with that. NebY (talk) 11:12, 16 October 2014 (UTC)
@67, you may discusss this if you wish, but you are not permitted to unilaterally implement your proposal. I just reverted a change you made to a blocked (not banned) user.--Bbb23 (talk) 14:00, 16 October 2014 (UTC)
We used to do this, but stopped as it was kind of pointless. Mr.Z-man 15:08, 16 October 2014 (UTC)
Bad idea. It makes it more difficult to handle (and report handling) long term abuse by not-logged-in editors and by sockpupperts, if we cannot point to the user who was blocked and the reasons he/she/it was blocked. — Arthur Rubin (talk) 16:27, 16 October 2014 (UTC)
I support doing nothing at all. Just let them exist, and do nothing about them. --Jayron32 23:18, 16 October 2014 (UTC)
This looks like an example of the classic "solution in search of a problem", thus it's pointless. Indefinite ≠ Permanent. Roger (Dodger67) (talk) 10:51, 18 October 2014 (UTC)

You're probably thinking of something like WP:OLDIP. Deleting these user pages has been explicitly rejected at criteria for speedy deletion - see Wikipedia talk:Criteria for speedy deletion/Archive 33#U4. These are absolutely necessary for various reasons, most importantly spam tracking - A spam patroller, seeing a spam link added, will check if users have added that spam link before, and if another account has been warned for the exact same spam, they can dispense with warnings and block immediately. This is not possible is the pages are deleted. If you want to blank an IP page for the benefit if the IP address's future owners, feel free to do so, but never delete them. Oiyarbepsy (talk) 00:54, 23 October 2014 (UTC)

TWL volunteers needed

The Wikipedia Library is seeking volunteer Account Coordinators to help manage new and ongoing partnerships. We are interested in having both active local volunteers and those with cross-wiki experience (particularly in non-English Wikipedias). It requires a commitment of a couple of hours per week, on average. To apply, visit Wikipedia:TWL/Coordinators/Signup. Nikkimaria (talk) 16:53, 16 October 2014 (UTC)

Tables with collapsible columns

I would like to be able to collapse (hide) certain columns of tables, sometimes. For example, when I (double-)click on the third column on the following table ("Motor vehicles"), to hide the fourth and the fifth column, because the third column is the sum of the fourth and fifth. And then, if I click it again, to show them. Sometimes tables can have too many columns and then, when you first look at the table, some columns would be better to be hidden, in order for the reader to see the essential. Then, if the reader wants, they should be able to able the not-so-essential columns.

Did anyone think about implementing such a feature?

Vehicle production of SouthVulcania (millions):

Year Bycicles Motor vehicles Trucks Cars
2010 30 100 80 20
2009 29 90 70 20
2008 28 80 65 15

 Ark25  (talk) 22:23, 17 October 2014 (UTC)

Judging from MediaWiki:Common.js, section Collapsible tables, it should be possible with a little Javascript, but implementation will need a fair bit of testing. Adam Cuerden (talk) 10:35, 18 October 2014 (UTC)

I would find it useful. Keep in mind, per MOS, that columns should be open initially, but I could see value in giving the reader the option to close some columns. Please also note that in the case of a sortable table, one sorts simply by clicking on the column heading, so it the table is to be sortable and allow column hiding, one have to think through how to do each option separately.--S Philbrick(Talk) 21:56, 19 October 2014 (UTC)

Repeal Wikipedia:Spam

At this instant, Wikipedia:Spam is severely undermined by the AfD-process. No matter how spammy an article is, they are hardly removed for that reason. A common reasoning with that is spam and advertising can be solved by normal editing, but nobody does the actual editing. Effect is that Wikipedia is slowly undermined by spammers and talking-but-not-acting-good-willing editors. latest example in my experience is Wikipedia:Articles for deletion/Mydala.

This makes WP:SPAM a hollow phrase and repealing it should be best. The Banner talk 05:17, 18 October 2014 (UTC)

I hope I have addressed most of your concerns about the article with my recent copy edit of the piece. No need to throw the baby out with the bathwater. Regards, GenQuest "Talk to Me" 08:38, 18 October 2014 (UTC)
Thanks for the edit but it happens so often. The Banner talk 09:55, 18 October 2014 (UTC)
Absolutely oppose This proposal is like suggesting that because all burglars are not arrested red-handed at the scenes of their crimes, burglary should no longer be a crime. WP:SOFIXIT is the usual cure for failure to act on the result of discussion. Roger (Dodger67) (talk) 11:12, 18 October 2014 (UTC)
Strongest oppose, obviously. AfD is not cleanup. Respectfully, Banner made exactly two edits to Mydala: flagging it for speedy deletion (rejected with the note "not even close"), and flagging it for AfD, which was snow-closed as an obvious keep when not a single editor !voted delete. We have a speedy criteria for articles that are obvious spam, and as for the repeated failures of your nominations at AfD, maybe you should take it as an indicator of community consensus that your spamming of the process with apparent pattern of frivolous nominations is itself undermining AfD. Ivanvector (talk) 14:30, 18 October 2014 (UTC)
You are exactly using all the bogus arguments used in AfD's nominated as advertising in order to keep the spammy article. The Banner talk 15:46, 18 October 2014 (UTC)
But when I nominate an article for deletion as advertisement, I don't ask for clean up. I do ask for deletion. But nearly all the time I get replies as "AfD is not for clean up", something I am not asking for. The Banner talk 20:01, 18 October 2014 (UTC)
Right. "AFD is not cleanup" means "If the article could be cleaned up don't nominate it for deletion." AFD is used primarily for articles whose subjects don't deserve a Wikipedia article. If the subject deserves an article, but the text of the article is substandard (i.e. it is "spammy") then AFD is inappropriate. --Jayron32 01:11, 19 October 2014 (UTC)
The main problem is that after closure of such a AfD in most cases absolutely nothing happens and the dodgy and/or spammy article stays in place. With all the advertising problems, conflicting with WP:SPAM, still there. In effect, "AfD is not for clean up" acts as protecting promotion and advertising. By now, the only way to enforce WP:SPAM is by means of AfD or CSD and get the article removed, as the editing part to enforce WP:SPAM is hardly done. A policy without means to enforce it, is useless. The Banner talk 15:12, 19 October 2014 (UTC)
in most cases absolutely nothing happens WP:SOFIXIT applies. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:32, 19 October 2014 (UTC)
Ever realised that AfD is also a way to fix spammy articles, but by deleting them? The Banner talk 03:04, 23 October 2014 (UTC)
If "nearly all the time" people tell you you're getting it wrong, try not doing the same thing again. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:32, 19 October 2014 (UTC)

New bot suggestion

I am not sure that this is the correct forum for such a suggestion. But I would like to suggest that a bot who combines duplicate references are created, such a bot would come in handy for editors who creates new articles or find it hard to combine references overall. One such bot is not operative at the present.--BabbaQ (talk) 15:20, 19 October 2014 (UTC)

@BabbaQ: The venue you're looking for is WP:BOTREQ. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:29, 19 October 2014 (UTC)
Yes, sorry I found it right after posting here. Made a request there now. --BabbaQ (talk) 15:30, 19 October 2014 (UTC)

Request for community input on IEG proposal: editor interaction data sets and visualizations

As you may have heard, Editor Interaction Data Extraction and Visualization is an individual engagement grant proposal. I am working on this proposal with volunteer assistance and advice from Aaron Halfaker (WMF), Haitham Shammaa (WMF), and Fabian Flöck (Karlsruhe Institute of Technology).

We would greatly appreciate your comments on whether you support or oppose the general concept of this project, and any suggestions about how to refine the proposal.

Additionally, we would like to hear from you about which sets of editor interaction data, and what visualizations of editor interaction data, would be most relevant to your interests. We intend to prioritize our outputs with your comments in mind.

Please comment on the proposal talk page. Questions and feedback, both positive and critical, are helpful to us as the proposers, and also help the Individual Engagement Grants Committee [1] to assess the proposal.

Regards, --Pine 18:29, 19 October 2014 (UTC)

[1] I am a member of the Individual Engagement Grants Committee. I am recusing from reviewing proposals in this funding round.

Shortcut T for Template namespace

I see in this previous RFC there was a rejection of using "pseudo-namespace shortcuts" such as T: for Template: namespace. I didn't read the whole RFC but I do know that I get tired of typing "Template:" into the search box each time I want to find a template. The name space "T" is unused so I don't see why there can't be a change made where this could be implemented. Comments? ~Technophant (talk) 03:35, 20 October 2014 (UTC)

More reading material for you: Wikipedia:Perennial proposals#Create shortcut namespace aliases for various namespaces. When re-making a proposal for something that has already been repeatedly rejected, you really should address the reasons for it being rejected previously. Anomie 10:38, 20 October 2014 (UTC)

Better idea

How about changing the search box so that if I type in {{infobox}}, the search box is smart enough to suggest Template:Infobox? That would address @Technophant:'s issue - they could just copy and paste it from the wikicode. Oiyarbepsy (talk) 01:03, 23 October 2014 (UTC)

Creation of the "Special talk:" namespace

It's not obvious where to discuss Special pages, but it seems the typical place for them is Wikipedia:Talk:Special:Foo. On the other hand, sometimes they are at Help:Talk:Special:Foo, so it's not even consistent. In my view, this should instead be Special talk:Foo, and Special:Foo should have a discussion tab just like any other page. This would give a place for people to discuss special pages that they would actually be able to find. Oiyarbepsy (talk) 18:48, 18 October 2014 (UTC)

Note: Please see Wikipedia talk:Criteria for speedy deletion#Proposal to update R2 criterion for "Special talk:" redirects for the discussion that prompted this one. Steel1943 (talk) 18:52, 18 October 2014 (UTC)
  • Per my comment in the other discussion Steel linked to (please respond there), creating a NSA for the "Special talk:" to point to "Wikipedia talk:Special:" is pretty easy. To get a "discussion tab" on Special pages would be more difficult to do in core because, as I understand it (which isn't always the way it is), special pages aren't normal pages in a normal namespace (hence the NS number of -1); that said a gadget could be created that would simulate a "discussion tab" on most special pages (there are a couple where .js won't run for security reasons). — {{U|Technical 13}} (etc) 21:41, 18 October 2014 (UTC)
Struck-out text that is no longer pertinent to the current discussion, but has been retained here for historical purposes. Steel1943 (talk) 15:31, 22 October 2014 (UTC)
I wonder if the Special_talk.php from this very old bug report [20] is still a going concern? This was referenced in Wikipedia:Village pump (technical)/Archive_61#Enable Special talk.php. jni (delete)...just not interested 20:33, 20 October 2014 (UTC)
  • As I said below in the discussion before this became a RfC: "Special:" is a technical namespace, and it will be easier to create a technical solution (which had this RfC not been started could have been implemented within a week or so I'm sure, but now should wait until this has concluded) than it will be to add this exception and then enforce it. As such, I oppose the creation of this CNR where a NSA[disambiguation needed] would do a much better job. For those that might not be clear on what this alternate proposal is exactly: I'm proposing to make an actual namespace alias that will load "Project talk:Special:" when "Special talk:" is given for a namespace just like "Wikipedia talk:" and "WT:" both take us to "Project talk:" themselves. Doing this means there will be no redirect involved at all and none of that hassle or issues that come with it.

Support the creation of the "Special talk:" namespace

  1. As proposer. — {{U|Technical 13}} (etc) 14:56, 22 October 2014 (UTC)
    Support, as above. Steel1943 (talk) 15:22, 22 October 2014 (UTC) I would rather see this as an actual functional namespace than an alias. I don't know why this discussion has had to be reconfigured as so. Now, the fine line between an actual functional namespace and an alias has been totally blurred. Steel1943 (talk) 19:51, 22 October 2014 (UTC)
    • It will be as much of an actual namespace as the Wikipedia namespace (which is an alias of Wikipedia:Project namespace). It can not be configured any other way. Since "Special:" is Namespace -1, there cannot be an actual "Special talk:". Before you say it could be -2, that is already taken by "Media:" (allows you to link to a file instead of using ":File:". — {{U|Technical 13}} (etc) 21:17, 22 October 2014 (UTC)
    • @Technical 13: I get how it works, and I still have my preference for an actual namespace. The "NSA" is my option in the event that it can't be done, but it's definitely not my first choice. Steel1943 (talk) 21:23, 22 October 2014 (UTC)
  2. Support Oiyarbepsy (talk) 00:45, 23 October 2014 (UTC)
    • Comment The use of abbreviations is excessive and completely out of hand. I have no idea what NSA is (a bunch of spies? Don't insult yourself?) Please write stuff out, and also, check your links, since I'm pretty sure that NSA does not mean No Self Attacks. Oiyarbepsy (talk) 00:45, 23 October 2014 (UTC)
  3. Support --Fauzan✆ talk✉ mail 05:11, 23 October 2014 (UTC)

Oppose the creation of the "Special talk:" namespace

Discussion about the creation of the "Special talk:" namespace

Alternate proposal 1: update speedy deletion R2 criterion for "Special talk:" redirects as exceptions

I propose that that the wording of the R2 criterion be updated to include this wording at the end as an exception to the criterion:

...and redirects titled "Special talk:Foo" that target the "Wikipedia talk:" or "Help talk:" namespaces.

I'm proposing this since the "Special talk:" namespace does not exist, and I have on multiple occasions found myself in a situation where I wanted to discuss the function behind a tool in the "Special:" namespace, but could not find its discussion page. I recently discovered that the naming convention for these talk pages seems to be "Wikipedia talk:Special:Foo". It makes sense for the talk page to be in the non-existent "Special talk:" namespace, but since the namespace doesn't exist, creating a page in that namespace defaults it into the main namespace, which would currently make it eligible for speedy deletion for this criterion if the "Special talk:" title was made a redirect. Steel1943 (talk) 16:49, 18 October 2014 (UTC)

Support the wording of the R2 criterion be updated to add an exception for CNRs from "Special talk:" to "Wikipedia talk:Special:"

Assuming Steel1943, as proposer. I'd rather see the creation of the namespace as a whole, as stated in the above sections. Steel1943 (talk) 15:22, 22 October 2014 (UTC)
  1. Assuming Thryduulf, per discussion below.

Oppose the wording of the R2 criterion be updated to add an exception for CNRs from "Special talk:" to "Wikipedia talk:Special:"

  1. Oppose creating as a CNR. Please see alternate proposal. — {{U|Technical 13}} (etc) 14:56, 22 October 2014 (UTC)
  2. Assuming Jni, per discussion below.
  3. Assuming Oiyarbepsy, per discussion below.

Discussion about the wording of the R2 criterion be updated to add an exception for CNRs from "Special talk:" to "Wikipedia talk:Special:"

  • Exactly, which is why I'm trying to propose that it be made an exception. And as for this being a pseudo-namespace, if that's the case, then essentially "Wikipedia talk:Special:" is a pseudo-namespace in an actual namespace. The fact that these redirects currently don't exist is essentially harmful. The only other option I see is a proposal to actually create the "Special talk:" namespace. (I'm trying this route first, since it doesn't require an update to the actual function of the Wikimedia software built on the English Wikipedia.) Steel1943 (talk) 18:11, 18 October 2014 (UTC)
    • I'd actually rather see it implemented as a NSA. This is a technical solution that doesn't require a namespace to be created (that really can't exist as I understand it). Prevents all drama. @Steven (WMF):, can we get a little input from the developers, please? I'm sure Jackmcbarn could put this up for merge in Gerrit (or phab, if we are using that now).  :) — {{U|Technical 13}} (etc) 19:59, 18 October 2014 (UTC)

I'm okay with this temporarily, but for the long term I oppose, since this exception is a hack. The real solution is a Special Talk namespace, which probably should exist. I'll bring it up at Village Pump Technical. Oiyarbepsy (talk) 18:43, 18 October 2014 (UTC)

Wikipedia:Village pump (technical)#Special talk namespace. Oiyarbepsy (talk) 18:48, 18 October 2014 (UTC)
@Oiyarbepsy: Essentially, I agree with your reasoning. Thanks! Steel1943 (talk) 18:50, 18 October 2014 (UTC)
I think that the exception to R2 should be something along the lines of "other than approved pseudo-napespaces", and not mention any true namespaces; at the same time, we approve the CAT:, H:, MOS:, Special talk:, etc. Any subsequent discussion about topics like this would then go to WT:Shortcut. עוד מישהו Od Mishehu 19:46, 18 October 2014 (UTC)
  • Support this exception. Such redirects can still be nominated at RfD and discussed on their individual merits (or lack of merits) balanced against any harm that it does (or doesn't) do. Just because many CNRs are harmful, does not mean that all CNRs are or that being a CNR is harmful in and of itself (hence the need to have exceptions in the first place). Thryduulf (talk) 01:15, 19 October 2014 (UTC)
  • Oppose this exception. This is just WP:BURO rule creep. Not needed in practice. No harm is done if we just wait for Special talk: namespace (the correct solution). All admins already know about "Wikipedia talk:Special:Foo" talk pages and therefore can make a smart decision on the spot, if there is a need to speedily delete a redirect pointing there. It was recently noted in Template_talk:Db-r2 that the R2 warning template had had inconsistent namespace applicability instructions compared to CSD policy itself for over four years, and nobody noticed or cared. We will get more inconsistencies like that if start inventing detailed rules and exceptions for every marginal use case of our wiki-editing tools. jni (delete)...just not interested 10:45, 19 October 2014 (UTC)
  • How is this instruction creep? The basis of this proposal is the usefulness of the creation of such redirects that are intended to target the talk pages for the discussion of pages in the "Special:" namespace. At the present time, there are no redirects titled "Special talk:Foo" that exist, (obviously, given my statement in the nomination.) Also, just because administrators, in practice, should know about the existence of the "Wikipedia talk:Special:" titles (I'm certain that several administrators do not know about that standard naming practice), the ability to find these pages should be easy to find by all editors who may need to discuss a page in the "Special:" namespace, admins and non-admins alike. However, I do agree that I'd rather just see the creation of the "Special talk:" namespace; however, as stated above, there is the possibility that it would not be technically possible due to how the "Special:" namespace is programmed in the English Wikipedia. Steel1943 (talk) 16:40, 20 October 2014 (UTC)
  • I agree that it is instruction creep actually. It's an attempt to introduce wording to a social method of moderating what does or does not happen on wiki when there is a much simpler technical approach. I see no objection to adding the NSA here, and will request it added on bugzilla tomorrow afternoon (about 28 hours from this post) if it remains unopposed for the simple technical solution. The technical solution makes adding it to policy unnecessary and moot. — {{U|Technical 13}} (etc) 17:01, 20 October 2014 (UTC)
  • It's not necessarily instruction creep if the technical resolution is not possible. Steel1943 (talk) 17:12, 20 October 2014 (UTC)
  • In regards to if the technical resolution is not possible, I assure you the technical resolution is not only possible, it's easier than trying to impose a change to existing social sanctions. Since your if clause is false, then it is reasonable to assume that it is indeed instruction creep. I can't see a use case where "Special talk:" shouldn't take the user to a talk space where they can talk about a "Special:" page (even in cases where "Wikipedia talk:Special:Foo" for "Special:Foo" where "Wikipedia:Special:Foo" doesn't yet exist). I welcome cases I may not have thought of, if you have any. :) — {{U|Technical 13}} (etc) 18:45, 20 October 2014 (UTC)
  • It is instruction creep because exactly 7 such pages have ever existed (at least after last time the deleted revisions were purged from database - and last time that happened was before I was made admin here close to 10 years ago!). No redirect with prefix "Special talk:" targeting the Help talk namespace has ever existed. 3 of the deleted pages were not redirects at all and were deleted per G2 (or close to it) reasons. Details are in User:Jni/Special talk redirects review, for benefit of non-admins participating to this discussion. For the 4 redirects, some of which were deleted multiple times, 2 deletions were done without citing a specific criteria, R2 was cited 2 times and G6 was given as reason 3 times. Note the prominence of G6; I would use it instead of R2 for deleting this kind of weird artifact relating to pseudo-namespaces myself. Your proposal seems to silently limit applicability of G6, making the already convoluted and somewhat arbitrary set of CSD rules even harder to remember or apply correctly. There have indeed been some misunderstanding about this matter - see logs for Special talk:Cite where Rossami makes a circular argument, claiming that his invalid use of admin's restore tool (assuming R2 was the same as today in 2007) invalidates a later G6 CSD as well. Overall, there has not been any need for this exact kind of redirect because only 4 were ever created during last decade. If something has hardly ever existed, there is no need to make special rules for it's deletion! jni (delete)...just not interested 19:04, 20 October 2014 (UTC)
  • Rossami's argument is not circular and actually is the heart of speedy deletion - if it's controversial, it should not be speedy deleted, period. Oiyarbepsy (talk) 19:34, 20 October 2014 (UTC)
  • Oiyarbepsy, I called his argument circular ("dubious" would have been a better word), because there was a five year gap between the two deletionsrestores. The controversy, if any, cannot last for that long and later day admins are allowed to take a fresh look and are not bound by some very old actions of their peers. Besides, a really detailed analysis would require understanding the deletion policies, CSD rules and unwritten conventions as they were during each and every of the events in the log. jni (delete)...just not interested 19:53, 20 October 2014 (UTC)
  • On taking a closer look of several speedy restores Rossami did ~7 years ago (we all have important investigations like this going on from time to time, right?), it seems the then-controversial matter was eventually settled in RfD and consensus that "Special talk:Foo" redirects are not needed was established. Now it is proposed here to override this earlier consensus, but is this talk page or exception to CSD R2 really even the right forum or mechanism for this? jni (delete)...just not interested 19:50, 20 October 2014 (UTC)
  • (edit conflict) @Jni: I did not see it above, so would you be able to provide a link to the RfD discussion where consensus was formed (in one way or another) deeming the usefulness (or lack thereof) of "Special talk:" titles? (I'm, more or less, quite curious to see it, given that I had no idea that any form of consensus was established for this very matter in the past. I'm in no way saying that this changes my opinion at the present time.) Steel1943 (talk) 20:10, 20 October 2014 (UTC)
By the way, your question about if this is the right forum for this discussion, I'm actually wondering that as well, given that this discussion has turned into something more than just trying to add an exception to the R2 criterion; this discussion is turning into a discussion about whether or not a "Special talk" namespace (or an pseudo-namespace namespace alias, as Technical 13 has eluded above) should exist. If this discussion continues as it has, I'm thinking the whole discussion may need to be moved, and maybe even converted to an RFC if it continues to gain as much momentum as it has in the past day alone. Steel1943 (talk) 20:24, 20 October 2014 (UTC)
  • I've never said it should be a PNR, and I would oppose it being a PNR. What I've said, multiple times, is that it should be a NSA. A pseudo-pagename is a case sensitive combination of a Cross-namespace-redirect and a shortcut; A namespace alias is an actual case-insensitive virtual namespace just like WP or WT or Image. — {{U|Technical 13}} (etc) 21:01, 20 October 2014 (UTC)

Looking at the deletion logs for those seven pages, it's pretty much adds a lot of strength to the idea that we need Special talk. Almost all of them were either redirects to a corresponding Wikipedia talk page or were the type of material that you'd expect to see on a talk page. The fact that these pages are so rare is because the special pages don't link any talk pages, so the majority of users just get lost and give up trying to discuss them. Others guess Special talk and either post a comment or make redirects. Oiyarbepsy (talk) 20:02, 20 October 2014 (UTC)

Requesting community input on suggestions for DYK/Stats

Hi, I posted a set of suggestions here a week ago and have only been able to get responses by pinging people. Basically it boils down to this:

  1. - I think the talk page should have an archive
  2. - I think the DYK alert templates should link to the official versions of the rules in projectspace instead of the outdated version of the rules in userspace.
  3. - I would like to make corrections to improper calculations based on the outdated rules.

I'm happy to do all of this myself if given the greenlight. Please review my suggestion and weigh in. Thanks in advance. -Thibbs (talk) 14:25, 23 October 2014 (UTC)

Idea lab

Major nonprofit search engine

I'm becoming more conscious of the corruption for-profit endeavors are prone to. E.g., the major SEs (search engines) are right now arguably pirating imagery. They bring up wonderful full-quality images scraped from websites in wispy efficient UIs that let's the user download whatever they want without needing to visit the original webpage. (Most people don't even tag their images with logos or include their site in the filename, so once it's saved to disc from the SE, there's no clue of where it came from.) They also allow purely image scraper sites to manipulate their systems, hence even when an SE displays a link back to the original webpage, that link might be back to a scraper site that already harvested your original image and may be even less likely to credit the original original page. Even further, there are actually fake anti-scam sites that come up when you investigate, giving the scraper sites A+ scores and listing no complaints.

The thing that really nags me is that it's not one but all 3 of the major SEs (Google, Bing, & Yahoo). It almost sounds like a conspiracy theory but really, they're all doing it. I keep wondering how the this could possibly be? The only answer I can think of is that the type of endeavor (for-profit search engine) is just prone to this type of corruption; however, SEs also provide an incredible service: they drive incredible traffic to your site. I've tried to play devil's advocate and say now wait, do the benefits they provide still outweigh these perceived violations? The answer may be yes (Google has the case well, without us, you'd barely be getting any traffic at all), but then again, it's a nasty theoretical, because things might have evolved differently if they had begun in the pattern of what they're doing now.

What if this unsaid contract with the SEs had begun way back as a nonprofit endeavor? What if we had said you know, why don't we build a way to search the whole internet for free!! Then the SEs wouldn't be prone to corruption, right? In other words, why aren't SEs like Wikipedia? Could we build such? Squish7 (talk) 23:47, 19 September 2014 (UTC)

Wikia tried this once. It didn't end well :\ ^demon[omg plz] 23:01, 20 September 2014 (UTC)
Wikia is for-profit company, I don't understand how this relates to a nonprofit endeavor. Anyway, nothing great was ever achieved by trying one time then quitting. We're on a planet of 7+ billion people. If everybody tried twice at something, that's 14 billion tries!
With great respect to all editors, I've often noticed that people with a large body of knowledge will reply to a proposition by quoting information, not necessarily thinking creatively. People constantly tell me "Oh, they've already done that" as if everything in the world has been done and there's no point in going on with anything at all. Hence let me revise my question(s): Does anyone have any ideas on getting people together to start a major nonprofit search engine? What similar projects/methods have succeeded, or what has failed (within the context of how the failure might be used as a learning experience)? Squish7 (talk) 15:16, 26 September 2014 (UTC)
It may be too late. Remember all that news about Google, Samsung and Apple going to court about patents and stuff like that? One of the patents was the ability to lock a phone using a symbol traced on the screen. But a lot of them, and the least reported, were about how search engines display results. Basically, like life, its function is now subject to intricate copyright. I'm not sure of the exact implications, but when a search box doesn't seem to find or display the results in a very clever way, I am reminded how these laws went in, practically unannounced on the back of Apple vs Samsung. You can bet, if you take business from Google, there will be a court day of the sort that could cripple the site. You'd have to understand this ~ R.T.G 12:42, 9 October 2014 (UTC)

Search links to other WMF sites

I was searching for a phrase in WP and it didn't come up and it occured to me it would be handy to have links at the top of the page, "Search Wiktionary for this query" and Commons and Wikisource and stuff like that, much in the same way we add the templates to articles linking categories on other sites. Probably been suggested before, not sure what it would be called in the archives, ~ R.T.G 15:26, 6 October 2014 (UTC)

@RTG:, you may be interested in the Other projects sidebar in beta testing. Click on the beta link in your user toolbar and it's one of the options you can switch on near the bottom. I've been using it for a while and have had no trouble. Jason Quinn (talk) 14:46, 11 October 2014 (UTC)
@Jason Quinn:That's interesting in another way also. There is a discussion going on about disallowing onsite redirects in foreign languages, the theory being that such redirects are not conducive to learning the language, i.e. English. I don't hold with that, but such a bar that you have shown me here could become a standard feature some day if it is already on and I am sure the discussions outcome would have implication on interwiki links. Thanks for the info, ~ R.T.G 14:54, 11 October 2014 (UTC)
@RTG: Could you post a link of that discussion? I'd like to look at it. Jason Quinn (talk) 17:48, 11 October 2014 (UTC)
LOL yes that would help Wikipedia_talk:Redirects_for_discussion/Redirects_from_foreign_languages#Try_again.3F. Maybe it hasn't got a lot of momentum. I didn't fully read and there's only ten or twenty contibutors but they were talking bout making it a policy. Thanks again o/ ~ R.T.G 18:02, 11 October 2014 (UTC)

Wikipedia bingo

As a fun way of encouraging people to develop WP articles - the WP equivalent of Bingo (Commonwealth) - lists of (for example) 10-12 articles, possibly themed/category of improvement required. People can pick up one (or several if they have the inclination) - and those who have improved the most by a given date 'win' (Other versions can include getting one of the entries to GA/FA status etc). See the current mainpage talkpage discussion on MM for one variant. (Not all articles need be 'those sitting in improvement categories') Jackiespeel (talk) 21:25, 10 October 2014 (UTC)

Hi, please also note my point on integrating with crypto currencies as per my proposal below. It could be a related idea. Thanks :)Willibs (talk) 00:02, 19 October 2014 (UTC)

Is it possible to block edits that trip the "possible vandalism" tag?

If you click here, you'll see a large list of edits that have tripped the "possible vandalism" tag. I've noticed that this tag is incredibly accurate. Almost every edit that it tags as vandalism is vandalism. Instead of going through the trouble of reverting these edits, why don't we just block them in the first place? If my memory serves me correctly, edit filters have the ability to do this. (Of course, edit count fanatics won't like this proposal, because they won't have as many edits to revert...) --Writing Enthusiast (talk | contribs) 21:43, 10 October 2014 (UTC)

It is certainly possible, the place to discuss this is at Wikipedia talk:Edit filter. There are multiple filters that are hitting this tag, such as 432 and 491. Edit filters allow for differing actions, including "tag" - but specific filters could be changed to "prevent the edit" if warranted. The more likely a filter is to have a false positive, the less likely we would want to block the edit. — xaosflux Talk 23:53, 10 October 2014 (UTC)

Article creation and pending AfC submissions

Given the severe backlog of AfC submissions, I would like to know whether Wikipedia software alerts an editor who is about to create an article in mainspace with a name that already exists in the draft namespace. If I'm not mistaken, I currently have three pending submissions and it would be rather painful if another editor would go through the trouble of creating an article about one of those subjects unaware of the existence of my work. Obviously the same goes for other drafts. I think it's safe to say that not all editors check for drafts before they start bashing keys. -- (talk) 16:47, 13 October 2014 (UTC)

Checklist for closing discussions?

Rather long time ago I ran into a problem when a closer of RFC discounted some opinions about merger of an article, because he thought that some major changes of that article changed the situation significantly, while missing a discussion (that ended up in the archive) where those changes were discussed (the article has been deleted by now, and so is the RFC). After that I have prepared (without publishing) a "checklist" that would list some steps that might be worth considering while closing discussions (like looking at the discussion, article and its history, archives etc., making a list of participants, arguments etc. and the like). The obvious problem with that is that I have yet to close a single discussion... So, I'd like to ask: would such "checklist" actually have any use..? --Martynas Patasius (talk) 00:27, 14 October 2014 (UTC)

Is there any reason that you haven't tried out your checklist by closing some discussions? There are usually dozens at WP:ANRFC, because someone's taken it upon himself to list almost every single expired RFC, regardless of whether the RFC participants actually need or want a formal closure. You don't need to be an admin to close those discussions (especially the easy ones). WhatamIdoing (talk) 17:36, 14 October 2014 (UTC)
Well, I guess I should try to do so... Eventually... Although it is not easy to find a discussion that is interesting enough to give me a motivation to close it, where I didn't participate, and easy enough to close that I would be willing to have it as my first close, yet sufficiently complex that it would be possible to try out much of the "checklist" (I guess it will become clearer after looking at it - User:Martynas Patasius/Things to check while closing discussions)... I do remember finding one - yet I soon found out that I was not the only one who felt motivated enough to try...
And I guess that if I didn't get a flurry of responses like "No, anything like that would just scare potential closers away for little gain.", publishing it as a "user essay" might not cause that much damage... --Martynas Patasius (talk) 00:01, 15 October 2014 (UTC)

Help the Wikipedians to live closer to each other, if/when they wish that

Hello there,

I am a wikipedian with more than five years of activity and more than 10,000 edits. For some privacy reasons I decided to create a new user and to post my message with it. Since a long time ago I was thinking that I would like to live closer to other wikipedians. There are two proposals I have for Wikimedia Foundation (WMF):

1) Help the wikipedians to find apartments to share. Since many years, I live in a flat, where I rent a room. I pay 300 euros / month to the owner of the apartment for that room. But I would like to find other wikipedians in my city who are interested to share a flat. And then, three wikipedians for example can rent an apartment together. The advantage consists in sharing the house with people who share your passions and in feeling more comfortable and safe. It's less likely that you will have problems when you live with people who are trying to build a better world, than when you live with people you find in a newspaper. I know, I can contact the wikipedians in my country (I think such a group already exists), but WMF can better help people to find each other for such purpose. WMF can promote this so the people better get the idea, and it can involve a bit in some very big cities, where there are many wikipedians.

A group of six wikipedians can rent two apartments next to each other, making the situation even more interesting. Twenty wikipedians might be able to rent an entire small apartment building, and so on. For me, it would be very nice to live in a Wipedia community. And I dare to think that I'm not the only one who thinks like that.

2) Rent rooms/studios/apartments/houses to wikipedians - and not only to wikipedians. I know WMF is not a real estate agency, but there is an undeniable fact: people make donations to WMF, and in the future, before or after passing away, they will live their wealth and houses to Wikipedia. Maybe such things already happened. I am one of those people who will live a part of their wealth to Wikipedia at the end of my life - at least 20% but maybe even 50% or 90%. And then, Wikipedia can rent those houses to wikipedians, at the market price, having a steady source of income forever. Instead of renting to random people, WMF should try to rent it to wikipedians first (but no discounts for them), so they can be closer to each other, if that's what they wish.

I suggest that WMF should also try something like this to see how it goes: buy a house somewhere in the suburbs of a big city where there are many wikipedians (let's say New York or Los Angeles). A house that needs a bit of reforming (and which is cheaper because it needs reforming). Maybe some wikipedians will volunteer to help with reforming. Or maybe some wikipedians will convince their family or friends to volunteer. And then, after reforming it, WMF can rent it to wikipedians. It is a one-time investment but it generates income forever. Or WMF can raise a cheap building (open source plans, open source techology) with small studios and rent them. If WMF would start such a project, I am more than happy to put 300 euros to support buying or raising a building for renting it. Maybe I would put even 500 euros. I am quite sure that I am not the only one to support such an idea. Many people (will) realize the fact that renting housing can generate revenues forever and it's one of the best ideas for funding a foundation. The money for the building can be raised in a campaign anywhere, even on Kickstarter.

In case that renting to wikipedians can be problematic (like some of them asking for a free rent in return for their work on Wikipedia), then the flats should be rented to non-wikipedians, who don't create such problems. Or there can be strict rules in place, to make sure such problems can't rise.

Many times I wonder why big charities like Red Cross or World Vision are not doing things like that. Many people live their houses to such charities in their testaments. Why they refuse to rent those places to the people, to generate a steady revenue, it's a big question for me. The only answer I can imagine is that they struggle very hard to keep it fake. Instead of paying 30 euros / month to Red Cross as a supporting member, I would prefer to pay them 300 euros / month for a room that they already have. It would generate 10 times more revenue (from me) that can be used to help the poor. But in this world, the things are the way they are..

I would accept to pay the same money that I am paying now for renting a room, even if it's further from my work than the place where I live now, if I can share the flat with more interesting and safe people. And I'm quite sure I'm not the only one who thinks like that.

This kind of things should have been done a long time ago, by the charities who have millions of members worldwide. Therefore, the idea should be expanded to rent not only to wikipedians, but to all wikians in general, and even to members of charities who are (being misleaded into) trying to improve the world: Red Cross, Vorld Vision, Action Aid, World Food Programme, etc. Those members who participated for a minimum while, of course.

In the end, I would like to bring into your attention the fact that the Red Cross in Kenya owns a five star hotel, that is generating a constant revenue. So this idea is not completely new. And renting real estate is easier and safer than owning businesses like hotels, restaurants, shops or other kind of for-profit activities, which can go up but also can go down anytime. As an activist, I would feel much better to live close to other activists than living close to strangers.

I think WMF should definitely try those things out.

Thanks for reading all the words above. Yours sincerely, --- WikiHousing (talk) 13:56, 16 October 2014 (UTC)

GIS data in Wikipedia

Hello, I am an occasional contributor to Wikipedia, and I really think Wikipedia could use some sort of centralized geographic information system of it's own, that editors could enrich articles with, and could make information a lot more accessible and clear to the readers. Does such a product exist at the present? does the Wikimedia foundation consider to create such a solution in the future? or nobody has ever thought of it yet?

I would like to elaborate on the matter: imagine an article like religion in Africa (for example), this specific article contains at the moment some sort of map in picture format that displays the different religions in Africa by different colors. the map is not too easy to interact with, the data is extremely simplified, and readers who want to research the subject further will probably use another service like Google maps, that allows them to manipulate the geographic data more easily (but would require the reader to also use some other source for the actual information on the specific subject).

I imagine some sort of simple to use inter-Wikipedia application, that would allow users to use existing Rasters and polygonal Geo-referenced layers saved on Wikipedia's servers or some other free to use sites, and only manipulate the attributes of the data relevant to the specific article. I imagine the Wikimedia foundation could reach some sort of agreement with Google to use it's maps services, or if that involves too much complications, ask for help from it's vast bank of volunteers - some of which are inclined to be programmers. And as for the data and raster layers themselves, use open sourced data across the internet as a basis, and allow editors to link to free-to-use data themselves, or contribute their copyrighted data.

I would appreciate your reply on this subject, Bigtk (talk) 11:38, 17 October 2014 (UTC)

@Bigtk: we do have {{Attached KML}} in use for a lot of road articles. The KMLs attached to those articles are used to specify a line on a map, which can then be overlaid on Google or Bing Maps or displayed on the WikiMiniAtlas accessible from the globe at the top of the article. Other types of articles (railways, rivers) have used KMLs for a similar purpose, and I think there are some using polygons to show areas. This is all in addition to the mapping abilities through {{Coord}}, which is limited to single point data. Imzadi 1979  00:37, 19 October 2014 (UTC)
@Imzadi1979: I looked into List of Attached KML subpages, and couldn't find any polygonal kmls. I tried to display some polygonal kml I've found online [21] on google maps, and got an error message "could not be displayed because it is too large." I am talking Large-scale here, I want to be able to display states and continents, and use data that exists in tables to change the ways the polygons are displayed (in reference to the example above, color Muslim majority countries in one color and christian majority countries in another etc.). furthermore, I want the data to be more accessible i.e. not linked to another service like google or bing maps. can't we use some sort of template to display the relevant map on the same article? we could use background maps already saved on Wikipedia- Wikipedia:Blank maps. Bigtk (talk) 08:41, 20 October 2014 (UTC)
I do believe there was a polygonal KML used for an article on a tornado outbreak last year, but I could be mistaken. The KML template already inserts a globe in the upper right corner of the article, and that globe pops up the WikiMiniAtlas with the content of the KML overlaid onto a map. There are currently limitations in that WMA doesn't use the colors specified by the KML. Also, there are limitations in total file size allowed by the servers involved. Imzadi 1979  22:09, 20 October 2014 (UTC)

Integration with Digital Crypto Currency Platform

I have recently began observing developments in the cryptocurrency world and have determined several ideas of great import and potential relevance to the Wikimedia foundation.

Perhaps it would be useful to explore the idea of developing a crypto currency that integrates into the crowd sourced framework of Wikimedia foundation knowledge where contributors are compensated for their efforts - in effect, coins are created (mined) and distributed in accordance with user contributions. This way all contributing users will have the additional benefit of receiving economic compensation for their efforts, and thus contributors will have a greater incentive to contribute, and can even singularly dedicate their time to compiling their knowledge online with secure assurance that an income will also be generated. Perhaps the currency could be named WikimediaCoin, which will be one of the first knowledge backed currencies - literally, a first in decentralised knowledge based economies. For an example scenario, a user would be generate a coin for every 10000 words contributed. Administrative/Moderators/Peer review users could also be compensated in some way, say perhaps they are apportioned a flat percentage of 5% of the coins generated from every new contribution that is reviewed. In general, an appropriate coin distribution system needs to be implemented that acknowledges everyone's honest collaborative input, while also having some quality assurance systems in place that protect the wiki from being abused for personal gain and thus ensuring integrity in the value of the crypto currency and the knowledge which is contributed. This idea could also provide massive benefits to free education platforms such as Wikiversity, in enabling itself to propel forward the mass dissemination of knowledge for free, and also for a freely generated income.

Alternatively, it may be a hard sell to transform the established Wikimedia foundation in such a way, therefore perhaps a new start up may be essential which might go by something like "Cryptopedia", "Cryptoknowledge", or "Distribmedia" etc, which could also be stored on a decentralised crowd cloud computing network such as MaidSafe - which brings me to another point. Would Wikimedia's administrative costs benefit from adopting a decentralised crowd sourced cloud server platform? (Such as MaidSafe, once MaidSafe is launched and becomes a thriving platform) Could it even enhance Wikimedia's services?

I wish to leave you all with these stimulating thoughts and hope that they do provide some excitement in terms of prospective potential. Please, everyone contribute to the development of this idea, throw in your eggs of innovation whatever they may be, whether you're a total expert or only have an inkling, the more ideas we can link together, the greater, more effective, self-sustainable, and self-propagating the platform will be. — Preceding unsigned comment added by Willibs (talkcontribs) 22:57, 18 October 2014 (UTC) Willibs (talk) 23:04, 18 October 2014 (UTC)

Reuse of sandbox when creating articles

Dear editors: Often new users who don't know how to create user subpages write draft articles in their sandbox. In fact, they are encouraged to do so by Wikipedia talk:Simple guide to creating your first article and the video at WP:USERSUBPAGE, and likely other places.

Inevitable, the draft articles need to be moved out, either to Draft space or to article space, leaving a redirect, with one edit attributed to whoever did the move. The user will then delete the redirect and start a new article. This has unintended consequences; for example, today I was notified that a draft I had created, Wikipedia talk:Articles for creation/Mikiea Perkins, was about to be deleted. Not only had I not created the article, but I had never edited that article; my only contributions was to move a draft article that had at some time previously been in the same sandbox. This led to the actual creator of the draft not being notified.

This also leads to distorted article attribution in the contributions statistics. For example, XTools lists me as the creator of Sharmin Ali, Atacama B-Mode Search, Healey Silverstone and several others which I have never edited or even seen before.

Since new users are immediately able to create pages in their own userspaces, would it be appropriate to minimize the problem by changing various instruction pages, help videos, etc., to encourage new users to create their first article draft in a user subpage with the intended title rather than one called "sandbox"? Or would this cause other problems that haven't occurred to me? The only one that I can think of is that the user might forget what they had called the page. —Anne Delong (talk) 17:25, 20 October 2014 (UTC)

I see the problem, although it's quite a minor issue really. I've sorted out Healey Silverstone, by deleting the earliest revision. The history now appears correctly. This is not a real answer though. Using unique draft pages for each article would certainly help, but this would be much harder to explain to newcomers. — Martin (MSGJ · talk) 19:16, 20 October 2014 (UTC)
Well, the problem starts to happen when the editors aren't really newcomers any more, since they have already created one draft article, had it moved out of the sandbox, and then created a second draft which was also moved out. Maybe somewhere in between the use of named subpages can be explained. Right now, when pages are moved out of sandboxes, an "R from move" template is left on the page. Could there be an alternative template, such as "R from move sandbox" which would display a message such as "Click here to find out how to create a special page in your user space for your next article. (It's okay to remove this message.)"., and include a link to a page that explained how to create and name a user subpage, the option of creating a page in Draft space instead if they planned to invite others to help with the draft, and maybe a pointer to the WP:Teahouse. —Anne Delong (talk) 03:41, 21 October 2014 (UTC)
  • Another problem with encouraging beginners to use the sandbox to create articles is that this leaves the redirect to the final article sitting in the sandbox. To a new user, this looks as if the sandbox doesn't exist anymore. I had this problem myself, but luckily I had an invitation to the Teahouse and was able to get help. If the new user does manage to figure out how to follow the tiny link back from the article to the sandbox and reuse it, this removes the link to the article, and the (fairly) new user has no obvious way to find the article again if they don't remember the exact title. (This relates to another post I have made further down this page about making it easier for users to find a list of their subpages.) If, instead, the sandbox redirect was a "soft" redirect, with the message suggested above, so that when I went to my sandbox to make a second article I was encouraged to create a subpage, it would be less confusing and avoid all of the attribution mix-ups mentioned above. —Anne Delong (talk) 12:12, 21 October 2014 (UTC)

Idea: replace the "Sandbox" item at the top of the page with "Subpages"

Dear editors: I don't know about you, but I rarely use the generic sandbox associated with my user name. I often have a number of things going on at once in my user space, so I keep them on separately labelled subpages. Instead of the link to the Sandbox, wouldn't it be handy to have a link to a list of user subpages instead? I know that one is available by clicking on contributions, scrolling to the bottom, and then clicking on "Subpages", but it was a long time before I discovered this, and it's not as convenient. Out of sight, out of mind, you know. I realized recently that there were several incomplete projects that I had forgotten about. The sandbox is there on the list of subpages, so for those who really do use the generic sandbox a lot it's only one more step, or it could be bookmarked in their browser. Any opinions about this? —Anne Delong (talk) 17:44, 20 October 2014 (UTC)

Sorry, but where do you see this sandbox item? I don't recall such a link existing, though my personal interface tweaks could be interfering with that. {{Nihiltres|talk|edits}} 18:14, 20 October 2014 (UTC)
Enabled by Preferences → Gadgets → Appearance = Add a "Sandbox" link to the personal toolbar area --  Gadget850 talk 18:17, 20 October 2014 (UTC)
Subpages is also available through the sidebar at "Page information" - in the first box, bottom row, click the link "Number of subpages of this page". --Redrose64 (talk) 18:30, 20 October 2014 (UTC)
I quite like this idea. Going User page -> page information -> subpages seems like a lot of work to find the pages I'm working on. It could additionally include Draft articles that you've started, and be more of a 'my drafts' sort of thing. Sam Walton (talk) 19:11, 20 October 2014 (UTC)
Also including Draft articles might be challenging to implement cleanly in JavaScript, unless there's a convenient MW API call available for pages started by namespace. This sounds like a potential MediaWiki feature rather than just a gadget or userscript. Regardless, I'd add that such a list page ought to include easy links or "helpers" for starting new user subpages or draft pages. {{Nihiltres|talk|edits}} 19:52, 20 October 2014 (UTC)
I have this in my JS to add links to the sidebar:
mw.util.addPortletLink ('p-tb', wgServer+wgArticlePath.replace("$1", "Special:PrefixIndex/"+wgPageName+"/"), 'Subpages');
mw.util.addPortletLink ('p-tb', '/wiki/Special:PrefixIndex/User:Gadget850', 'My subpages');
--  Gadget850 talk 19:31, 20 October 2014 (UTC)
Sidebars are good, but you have to first navigate to the page; the toolbar at the top is available at any time. Also, the link on the sidebar is pretty well hidden. First, I have to scroll down in order to see this option, which is off the page at my preferred zoom; then when I click on it the option, a list appears, and one of the items says "number of subpages to this page" (not list of subpages of this page). How many editors even know that they could get to their subpages this way? (I didn't.) Also, a link on the toolbar should be easy to implement, because the function already exists, and it should be just a matter of adding a link to it in the same that the "Sandbox" link was made, and sending the function a pointer to the appropriate user space. —Anne Delong (talk) 04:02, 21 October 2014 (UTC)
@Anne Delong: Try this code, if you want to add it to your personal toolbar, in the same location as the sandbox link (and turn off the gadget, to remove the sandbox link):
mw.util.addPortletLink(	'p-personal', '/wiki/Special:PrefixIndex/User:Anne Delong', 'Subpages', null, null, null, '#pt-preferences');
You can also add links to any of the boxes in the sidebar, or to the "More" dropdown menu that usually just contains the "Move" and admin links. Let me/us know if you'd prefer one of those alternatives, and specify where exactly you'd like it located within the area. (Or if preferred, deduce via looking at the section id names (via HTML-source), and the docs at mw:ResourceLoader/Default_modules#addPortletLink) HTH :) Quiddity (talk) 05:28, 21 October 2014 (UTC)
Sidenote: There's also mw:Extension:SandboxLink in development, which aims to turn the Gadget into an Extension, and amongst other benefits will prevent the "bounce" as the "Sandbox" link is added to the personal toolbar. Quiddity (talk) 05:28, 21 October 2014 (UTC)
Quiddity, what do I do with the above code? I tried putting it in User:Anne Delong/common.js, which is what I presumed you meant by "JS", but I was given an error message. -- Anne Delong (talkcontribs) 11:28, 21 October 2014‎
@Anne Delong: Does this edit fix it? JavaScript is very sensitive to missing and misplaced punctuation. --Redrose64 (talk) 11:56, 21 October 2014 (UTC)
Yes, now it works. Thanks, Redrose64. My, my, wouldn't I have liked to have that 50,000 edits ago... —Anne Delong (talk) 12:58, 21 October 2014 (UTC)
I don't like this suggestion, since the "sandbox" link is intended for newbies. People who know enough to want to use subpages likely know enough to disable the gadget and add something like what Quiddity posted to their common.js (or to ask at the Village pump to find out how to do that). Anomie 10:30, 21 October 2014 (UTC)
Anomie, in response to your objection:
  • Yes, I had forgotten that the Sandbox link was a gadget and not a default setting (I don't remember enabling it, but that's not at all surprising). I apologize for suggesting that it should be replaced. Just making a new gadget that would do the same for subpages would be better.
  • I'm personally happy to find out that I can paste some javascript code and get the same result, but I disagree that it's a good thing to wait for each new editor to have the idea that they could modify the interface and ask about it at the village pump (or even figure out that there is such a thing as the village pump) to do such a basic thing as finding a list of their subpages. Having to deal with javascript instead of just a checkbox would make a lot of less technically minded editors uncomfortable, and we should try to make the Wikipedia interface as friendly as possible so as to retain these content creators.
  • Encouraging new users to create articles in their sandboxes, rather than just using them for experimentation as intended, has negative consequences (see the thread above this one), including users not being notified when their articles are nominated for deletion, and users wondering where their sandboxes went because they've been redirected. —Anne Delong (talk) 12:35, 21 October 2014 (UTC)

esperento ido

–As as esperento and ido are closly similar contributions to one wikipedia should be added to the other wikipedia as well thru machine translation — Preceding unsigned comment added by (talk) 00:59, 21 October 2014 (UTC)

Proposed Change to Closure of RfC's

I have a possible policy proposal and I was wondering if anyone had any suggestions on how to make it better.

Sometimes there are very contentious RfC's with lots of people on both sides of the issue. Sometimes the number of votes, for instance, comes down to 55% on one side and 45% on the other. Now a uninvolved editor trying to close this RfC lets say they could reasonably choose that there is a consensus (in favor of the 55%), or that there just is no consensus (its close enough between the two sides). The person making the decision on how to close the RfC in that case is very important, and they are unlikely to be overturned (as they could decide either way). So here is what I propose:

  1. Any involved editor can require that an uninvolved administrator panel of 3 editors to close the RfC.
  2. Any involved editor can require that the RfC run for (up to) at least 30 days. (assuming it is not snow closed)

Any closure done after this requirement is added to the RfC and in violation of it would not be valid and could be overturned on review.

To help make this clear going forward, I created a sandboxed modification of the RfC template that has two additional options "admin=yes""panel=yes" turns on the requirement to close the RfC. And "days=x" turns on the requirement that it be closed after x days (this is incase maybe people don't need the full 30 days or everyone wants more then 30). Here is what it looks like:

Additionally I propose that for the most very complex cases, that a request can be made that a 3 administrator panel decide how to close the RfC. That accepting it be discretionary (the closing administrator can choose to get 3 or not), unless there is a consensus in favor of a 3 administrator panel.

The good things about this are 1) that admins area panel is much more likely to carefully review the closing decision then a normal editor. (Admins tend to have put in a lot of time and effort in establishing a good reputation of being fair and will not want to ruin that.) 2) the adminspanel are less likely to be advocating one side in the dispute or conflict of intrest, or otherwise not have a neutral point of view on the subject. 3) Its far too easy for an involved editor to create (or have) a sockpuppet close the RfC on their behalf without anyone finding out, this would prevent that. (Yes there are other ways to look and try to find who is a sock puppet but they are not full-proof if they use a different IP).

The disadvantages of such a system are that it increases the amount of work that admins have to do. Secondly that it increases the power of administrators over normal editors.

The disadvantages would be 1) that it would be harder to close some RfC's 2)that it would be difficult to figure out who should be on the panel (especially if there is not consensus).

What are your thoughts on this and how it might be improved?

--Obsidi (talk) 01:17, 21 October 2014 (UTC)

As discussed at a recent ANI thread, we have a tension between the notion that an admin is just like any other editor, except for access to some tools, which are usually unrelated to RfC closure, and the notion that closure of contentious issues ought to be done by highly experienced editors with a solid understanding of policy in general, and consensus issues in particular. Of course, there are non-admins with such a skill set, many who are better at it than some admins, but we have no formal way of identifying them. One possibility is that we ought to identify such individuals, although that sounds like a challenge in itself. If we could do so, or even if we could not, I'd like to consider the possibility that the default closure process for contentious RfCs ought to be a three editor panel, possibly with a requirement that one be a non-admin, possibly that some situations it might be fine to choose three non-admins. If we follow our usual process for selecting three editor panels, that is, a couple editors put their hand up, a little discussion ensues and a panel is selected by consensus, we could do the same, just allow non-admins to put up their hand, and one's who are clearly not suitable would not be selected. --S Philbrick(Talk) 01:52, 21 October 2014 (UTC)
I wouldn't have a problem with that if everyone could actually agree on who the closure individuals are. Maybe its easier then I suspect, but I suspect there will be times that people just don't agree. Also there is still a lot of wiggle room about if it was "really" contentious or not. Would you suggest switching the "requires admin" part to "requires a three editor panel". That might solve the problem, after you got to figure out who these three people will be before you can close in that case. That is likely going to mostly be by consensus at least. It seems unlikely that 3 editors would just randomly start working together to close, and although its possible that you would have one editor and two meat puppets it would be a bit more obvious then a single sockpuppet. Would you still accept that ANY involved editor can require the 3 editor panel to close? (or maybe one involved editor proposes a panel and it requires a 2nd involved editor to second the requirement of a panel) And would you require consensus on who the 3 people are or merely suggest it? --Obsidi (talk) 03:04, 21 October 2014 (UTC)
FTR, I urged Obsidi to start here, even though this is a proposed policy change, because I think it works best to threash out wording and ideas in one palce, and then do voting in another. If everyone thinks the existign wording is fine (even if they are opposed) we can move to Village Pump Policy, but it wording tweaks are need, it is complicated to do after voting starts. My hope is we work on wording here, then vote up or down at VPPolicy.--S Philbrick(Talk) 01:58, 21 October 2014 (UTC)
  • I see no reason to make admins even more "special" than they already are. They're supposed to be just regular editors with more technical abilities. Jackmcbarn (talk) 02:12, 21 October 2014 (UTC)
Isnt it usually admins that close the very close RfCs anyway? This just codifies that and makes it a requirement if it is asked for. --Obsidi (talk) 02:56, 21 October 2014 (UTC) I'm coming around to the idea of instead of it being an admin, that it require a 3 editor panel to close (see above). Then admins would remain equal to regular editors. Still lots of details to work out though on how they are selected. --Obsidi (talk) 03:11, 21 October 2014 (UTC)

@Jackmcbarn: Please read the top of this page, which is also emphasized at the top of the editing window:

This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.

I specifically urged Obsidi to post here, rather than Policy, because I thought the idea needed some work. My post specifically addressed the concern you have, identifying a way to use non-admins even in difficult closes. --S Philbrick(Talk) 13:01, 21 October 2014 (UTC)

Fixed. Jackmcbarn (talk) 15:29, 21 October 2014 (UTC)
I am concerned that the proposed change would invite certain abuses. It seems particularly vulnerable to filibustering – any single involved editor can demand a one-month delay on content that they don't want added to an article – and to drama-generation—forming mutually-acceptable three-judge panels is a potential can of worms. In my experience, you start with a small nucleus of bickering editors on a talk page, an RfC notice is posted, a bunch (or a handful, or a couple, depending on the topic) of outside editors drop in and post a few comments in the subsequent days, and a week later the talk page is back to the original nucleus of bickering editors. Having three weeks of additional fighting amongst themselves on the talk page probably isn't going to advance the discussion much, and it will be pretty effective at driving the less-involved, more-independent voices away.
This strikes me as a very heavy-duty process: time-consuming and labor-intensive. If I'm not mistaken, variations on this theme have occasionally been used in the past on an ad hoc basis to resolve very-long-simmering otherwise-utterly-intractable disputes, but they've always been a great deal of effort to set up and to close. Generally they've worked when the discussion has come down to making a decision between a limited number of choices; polls and discussions that spawn multiple new options and open-ended choices tend to fizzle and end in non-decision. Moreover, in those previous instances I believe there has generally been "buy-in" from the major players: a grudging but good-faith agreement and willingless to accept (or at least tolerate) the outcome. If we're going to formalize such a process – and I get nervous about writing a policy that will be used in edge cases, because it may encourage a lack of flexibility in structuring and facilitating such discussions – then the trigger needs to be much harder to pull.
Incidentally, I freely admit that my recollections on ad hoc structured RfCs are just that – my personal, fuzzy recollections – and it would probably be helpful for the proposer (or someone!) to dig up some of those past instances of large-participation, extended-time, highly-structured, 'facilitated' RfCs to examine how they have worked (or not) in the past. TenOfAllTrades(talk) 13:52, 21 October 2014 (UTC)
I share your concern about over doing the process. Any proposal which makes it easy for a single editor to invoke a time-intensive process will be ripe for abuse. We need to find a way to triage, something we are not always good at. I hope we want a light-weight process for issues that are not of great importance, or generate only a modest amount of controversy, but we ought to be willing to use a more time-intensive process on issues that are a bigger deal. I don't know how to identify objective criteria for the importance aspect, but I'll throw out something for the second aspect—rather than allowing a single editor to insist on a three editor panel at any time for any reason, maybe there has to be some minimum number of participants to justify the request?
On structured RfCs, I'm a big fan, but I think they conflict with some aspects of Wikipedia culture (anyone can say whatever they want almost anywhere). I have some thoughts on how to eat our cake and have it too, but I see the need for buy-in first.--S Philbrick(Talk) 14:38, 21 October 2014 (UTC)

I can understand that this process would be time consuming and difficult to figure out who the panel would be. One mitigating factor is that the closing panel does not need to get consensus first (although that would be nice), but as long as it is three uninvolved editors agreeing to close. The second thing we could consider is to have a minimum number of editors required to request it before it becomes mandatory. If a single editor would be too easy, how about 2? Or 5? How many editors agreeing the process is needed do you think to minimize the times that it occurs to the really important ones. What I don't want is just that it requires consensus (if you have that you can do whatever you want), it should be some fixed number, so if there are a lot of people in a big discussion then it should require the extra protections. --Obsidi (talk) 17:58, 21 October 2014 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── In my experience, these conflicts can run deeper and deeper into WP:DR processes, with things like RfCs being a process associated with the early stages of a dispute. That is to say, it's very rarely the case that an RfC which closes in a contentious area is definitive. It is impossible to resolve larger disputes with an RfC, and once it becomes clear that the problems are larger than that scope, other dispute resolution avenues are available, including third opinion, dispute resolution noticeboard, other noticeboards, mediation, and finally arbitration. This proposal seems to be trying to push RfC further down the pipe of dispute resolution processes. It's not clear that we need to burden the RfC with heavier processes when such a need indicates that other more formal dispute resolution may be needed. aprock (talk) 19:56, 21 October 2014 (UTC)

RfC's are fairly early in the process of dispute resolution, but they are also are usually fairly definitive as far as content disputes go. A third opinion is at least imo earlier then an RfC (it only involves one outside editor, not lots like an RfC). Noticeboards are great, but they don't always resolve anything (not like an RfC does usually). Mediation is nice, but entirely voluntary, and many times people don't want to go to mediation (and why would they if they win the RfC?). Arbitration is there, but they almost never take content disputes. Mainly they step in if there is disruption of the process occurring, and do not resolve content disputes. So outside of RfC's there are NO strong closure to content disputes. As such we need some way to make sure RfC's do their job accurately when it is a "close call". --Obsidi (talk) 21:31, 21 October 2014 (UTC)
We currently do have a way to "make sure RfC's do their job accurately": WP:CLOSECHALLENGE. aprock (talk) 21:41, 21 October 2014 (UTC)
Yes but that is only reviewable if the closer made an obvious mistake. If its a "close call" between 55-60% = consensus in that direction or no consensus, then that isn't reviewable. In those cases, where it isn't reviewable, it is better to have it decided right up front. --Obsidi (talk) 23:12, 21 October 2014 (UTC)



Hello, there's an RfC here that might be of interest to the wider community so I'm posting it here. The question is:

Should the French name Médecins Sans Frontières be used or should the English translation Doctors without Borders be used in the article?. The article is Ebola virus epidemic in West Africa.

I'm posting here per the RfC publicizing section which allows it. Thanks. SW3 5DL (talk) 16:57, 12 October 2014 (UTC)

I think that the French title should be used throughout seeing as most of the world uses the french version. Perhaps one should include the english translation in brackets after the first use of it, ie Médecins Sans Frontières (Doctors without Borders). Schuy B. (talk) 21:30, 20 October 2014 (UTC)
@Schuy B.: The post by SW3 5DL above is a notification, it is not the discussion itself. Per WP:MULTI, please discuss on the actual RfC, which is at Talk:Ebola virus epidemic in West Africa#RfC. --Redrose64 (talk) 22:48, 20 October 2014 (UTC)
@Redrose64: Sorry about that; thank you for the clarification. Schuy B. (talk) 00:04, 21 October 2014 (UTC)


The answer to my question probably exists 'somewhere' but I have limited time to wade through various topics.

I would like to translate some pages from Spanish into English, or at least to expand certain English pages by adding information from the Spanish page. In all cases I have in mind, these are pages about Spanish cities or communities where there is frequently miminal information in English but mountains of history, geography, topography, gastronomy, famous people, and town sporting clubs, etc., on the page in Spanish.

Question 1: how do I attribute the information from the Spanish page (which probably has many editors) to either the correct author, or to just the wiki page I am working from?

Question 2: is there anyone overseeing translations? I am not bilingual but am at the Master's level in Spanish language, linguistics, and phonetics. This, however, does not suggest my translations are perfect.

Question 3: is there anyone within the Spanish wiki with whom I should be talking?

Any help or suggestions appreciated. — Preceding unsigned comment added by Amaling (talkcontribs) 05:09, 16 October 2014

'Somewhere' appears to be Wikipedia:Translation#How to translate.
  1. There are multiple options for crediting the original. A link to the original in your first edit summary is typical (just like you'd do if you WP:SPLIT an article on the English Wikipedia). There's a template to mark translated pages. You can even request that the entire (Spanish) page's history be imported for full, detailed credit, although people don't usually do that (especially if an article already exists here). See Wikipedia:Translation for a list of options.
  2. Not really. You could see if Wikipedia:WikiProject Translation is active. Your translations don't need to be "perfect". It's not a test of translation skill. You just need to produce a good encyclopedia article.
  3. Not really, although if you told them which article you might do next, then you might discover a partner who would check it over for you in advance.
Good luck, and thank you for doing this! WhatamIdoing (talk) 05:47, 16 October 2014 (UTC)
@Amaling: See also Wikipedia:Local Embassy#español (es), es:Wikipedia:Embajadas, and Wikipedia:WikiProject Spain. And don't forget to use {{lang}} for any Spanish text (titles, quotes, etc.) which is not translated. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:09, 17 October 2014 (UTC)

Thanks for the information. I'll look at your links, find a page to work on and see what happens. — Preceding unsigned comment added by Amaling (talkcontribs) 14:32, 21 October 2014‎
It appears the WikiProject Spain page is where I should start. Thanks again.Amaling (talk) 00:02, 22 October 2014 (UTC)

A Nobel Prize?

Just a thought for possible future action, but Nobel Prizes can be awarded to organizations. Wikipedia is an organization (or, at least, the Wikimedia Foundation is formally one). Engaging in the free distribution of knowledge provides an invaluable resource in favor of world peace. I would also dare say that Wikipedia is a great producer of literature (the Prize is not limited to fiction; Winston Churchill won for his historical and biographical writings); and acts as an important positive force in the fields of physics, chemistry, medicine, and economics by giving the average person access to information about these fields. bd2412 T 16:37, 17 October 2014 (UTC)

"possible future action" by who? As far as I'm aware, the Nobel committee does not accept self-nomination, and it would be grossly improper to canvass for nomination. As for Wikipedia being "a great producer of literature" I can only suggest that opinions are likely to differ on this (it will also depend on whether one looks only at the best of Wikipedia, [22] or on more typical content [23]). Anyway, while I suppose that given the propensity of the Nobel committee to hand out peace prizes apparently at random, or possibly as some sort of post-modernist satire, one can't entirely rule out the possibility that Wikipedia might one day receive one, I don't think we should be making plans right now as to what we will do with the prize money... AndyTheGrump (talk) 17:04, 17 October 2014 (UTC)
Possible future action by anyone who is eligible to take action, which includes "University professors of history, social sciences, philosophy, law, and theology...". I'm sure we have a few of those among our ranks. Although people generally don't canvass for Nobel Prizes for themselves, they are often canvassed for by others (the Peace Prize, after all, has a nomination process; anyone doing the nominating would be "canvassing" for that nominee). The professors who nominate organizations for such prizes are likely to have some affiliation with the organization, even if is just as a cooperative volunteer. bd2412 T 20:20, 17 October 2014 (UTC)
what we will do with the prize money I was thinking of spending my share on a holiday... Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:02, 17 October 2014 (UTC)
A bucket of ice cream for me. And do we each get to keep the medal for a week? -- Derek Ross | Talk 00:01, 21 October 2014 (UTC)
If we limit it to editors who are highly active, and if we can assume zero transportation time, then we could probably each keep it for an hour a year. WhatamIdoing (talk) 00:22, 21 October 2014 (UTC)
I propose that the top twelve editors each get to keep it for one month of the year. bd2412 T 01:48, 21 October 2014 (UTC)
How do we get it from person to person each month without it melting on the trip from (say) London to Sydney? --Redrose64 (talk) 06:44, 21 October 2014 (UTC)
I think BD meant the medal, not the bucket of ice cream. -- llywrch (talk) 23:09, 21 October 2014 (UTC)
I'll give you my ice-cream when you pry it from my cold, sticky hands -- Derek Ross | Talk 06:26, 22 October 2014 (UTC)

Maybe the Nobel Prize is a long shot (for this coming year). How about a Pulitzer Prize for Public Service? Surely we can find some set of noble articles to merit consideration for that honor? It's not as though Wikipedia is bereft of awards. bd2412 T 19:25, 22 October 2014 (UTC)

Why go for these puny awards, why not go directly for the Oscar, Lifetime Achievment Award for best Drama any year. Just submit any talk page to the Academy. w.carter-Talk 20:27, 22 October 2014 (UTC)

Drawing of Kim Jong-un

We need a lead image. So, why not find an artist here at WMF who can draw a picture of him based on several photos? If it clearly resembles him, and the community thinks so, then it could become the lead image here and at other language Wikipedias. Thoughts? Anna Frodesiak (talk) 02:30, 21 October 2014 (UTC)

Suggest JNW Hafspajen (talk) 00:35, 22 October 2014 (UTC)
User-contributed drawings have been removed from articles as visual WP:OR, rightly I think. Johnbod (talk) 01:12, 22 October 2014 (UTC)
Hi, Johnbod. You may have a point there. But Wikipedias can draw a gear and that's fine. What about a species of plant leaf? Probably acceptable. So, what about a shrew? Still okay, maybe. So, why not a person if it looks just like him and is really professional? My point is, shouldn't it be case-by-case? Anna Frodesiak (talk) 01:21, 22 October 2014 (UTC)
Well, it's not without precedent; see Hassan Nasrallah. Tarc (talk) 01:28, 22 October 2014 (UTC)
Thanks, Tarc. And that image is accepted at 15 Wikipedias. Anna Frodesiak (talk) 01:43, 22 October 2014 (UTC)
Previously drawn images of Kim Jong-un have been removed due to being derivative works of press photos, making them non-free, and as Jong-un is still alive, unacceptable per NFC. --MASEM (t) 14:42, 22 October 2014 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────Hi Anna Frodesiak, while browsing about this caught my attention. I mentioned it at lunch to my boss, who is an artist, joking that maybe she could draw one. Sure enough, she took a pencil and drew a sketch, scanned and tweaked it! :) She has an account at the Commons so I asked her to upload it. I don't know if it's good enough for the Wiki, but it was a fun lunch and the pic is yours if you want it: File:Kim Jong-un sketch.jpg Best, w.carter-Talk 10:43, 22 October 2014 (UTC)

Hi, W.carter. Many, many thanks. :) That is a very nice drawing she did. I like it. For the article, I think the community may only approve of a piece that conveys more than a sketch can. I am not sure, though. Anna Frodesiak (talk) 14:37, 22 October 2014 (UTC)
No problem, it was all done just for fun. In fact her words were: "Hope this doesn't make me a new Lars Vilks now!" ;) w.carter-Talk 14:50, 22 October 2014 (UTC)

RFC - Mainstream scientific assessment of climate change

Opinions of neutral uninvolved eds eagerly sought!
We have a

Discussion of the latter article is often chaotic, as many editors talk about diverse issues in the same breath. However, the issue I'm trying to present is laser-focused on the leads of the two articles.
The lead of the main article tries to summarize the mainstream scientific perspective. To comply with WP:FRINGE's requirement to establish the context for fringe statements, the lead of the latter article does that too. However, for a long time they have been out-of-synch, using overlapping but different text and sources. A poll question has been posted asking

Given that the mainstream assessment is summarized on the basis of the RSs with greatest WP:WEIGHT at the main article "Scientific opinion on climate change", would a neutral uninvolved editor reasonably expect the same sources to be used to present the same summary [at the sub-article "List of scientists opposing..."] unless there was a really good RS-based reason to do something different?

Please offer your thoughts in the thread located at the subarticle via this link. NewsAndEventsGuy (talk) 13:12, 21 October 2014 (UTC)

Linking to audio pronunciation of names

I ask for the opinion of experienced and authoritative members. When a name contained in an article has no information about correct pronunciation, or when there is just the IPA transcription (not transparent to all users), it would seem an improvement to provide audio pronunciation by means of an audio file with the correct reading of the name (performed by native speaker under supervision of someone scholarly trained in phonetics or the like). Best is obviously to upload that file to Commons. But, in case this is impossible because the file belongs to some other institution, what is the best way to link to the URL where the file can be listened to? --- EdoLV (talk) 16:42, 21 October 2014 (UTC)

Perhaps use the {{external media}} template? The alternative would be to link to it in a footnote or reference, but that would easily be missed. Qwfp (talk) 20:36, 22 October 2014 (UTC)

RfC - Suitability for a Watchlist notice? (29 Oct - 2 Nov)

Hi! I wonder if I could get views on the suitability of a potential Watchlist notice to run between Friday 29 October and Sunday 2 November ?

It would be to support a campaign to use an an online index that's been created on Commons to systematically go through the one million public-domain images the British Library has uploaded to Flickr and add the Flickr tag 'map' to every image that represents a map or a ground-plan. This means we will then be able to run them through the British Library's crowd-sourced georeferencer project, and upload the identified and geolocated maps to Wikimedia Commons. (more information).

The project is going to kick off with a day-long Digital maps Halloween tagathon event at the British Library on Friday 29 October -- for which there is already a Watchlist geonotice running, currently being seen by users in the southern half of the UK as a line of text above their watchlist. (So if anyone is going to be free in London that day, please do sign up and come along).

But it's going to take more than that opening tagathon to get the job done. It would be fantastic if we could really make inroads into it over that weekend, because (i) the BL Labs group is holding its annual review symposium on Monday 3 November, so it would be great if we could show the attendees a real concrete win from the BL having worked with Wikimedia; and (ii) the critical thing for making the images uploadable to Commons is getting them georeferenced, but the BL will only start their next round of georeferencing once the maps have all been identified. So the sooner after the 31st that we can get them all found, the better.

It would therefore be great to be able to run something like the following watchlist notice, across the board, over the weekend from 29 October to 2 November:

This weekend, give us an hour (or half an hour) to find the remaining maps in the #BL1million. See project latest status.

Most of the index is divided into blocks of about 15 books, each one linked to a page of images on Flickr for people to scan, tag the maps, and then remove an UntaggedMaps template from the wikipage. So even in half an hour, one can do a good bitesized bit.

The reach of the collection can be judged from this map locating 3000 maps on the globe that have already been identified and georeferenced. Each red dot can be clicked on to reveal a map, which can also be laid over a modern map for comparison, like this. It also gives an idea of the global distribution of non-map images in the collection, which is similar (accessible through the same index pages). As yet unidentified, it's been estimated that there may be a further 10,000 maps in the collection, still to be found.

If enough people are ready to give the project a half hour, it should be possible to blitz through the collection, and find all those maps in really not very much time at all. But it means getting the word out. According to the keepers of the keys of the watchlist notices (and quite right too), an across-the-board watchlist for something like this should only be run if the community has said it's okay. So here I am asking: in your view, would a notice like the above be acceptable for the weekend of Friday 29 October to Sunday 2 November?

Thank you for your thoughts. Jheald (talk) 02:30, 22 October 2014 (UTC)

Best promo videos

I'm in need of a couple of short videos, promoting Wikipedia and its sister projects, to show at an event. It's surprisingly hard to find them!

We have lots of videos in Commons:Category:Wikimedia project videos, but many, while no doubt useful for their educational content, are not the kind of things to show to a lay audience - either the quality is not high enough, or the content is too specific.

I'm looking for things with impact, like File:Open Letter for Free Access to Wikipedia - three months later, MTN responds.webm

Suggestions, please! Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:39, 22 October 2014 (UTC)

New tax on Internet traffic in Hungary

The Hungarian government proposed to impose a new tax on Internet data transfers from 1. January 2015. The draft tax code contains a provision for Internet users to pay a tax of 150 forints (50 Euro cents) per gigabyte of data traffic.

The internet tax put a great restraint on Internet access. The Hungarians would now access the services they have used much more expensively, or in an extreme case, not at all. Up to present only dictators has controlled the Internet either financially or with raw power.

This is a great restraint for the Wikipedia users too. First of all the contributors access will be notably expensive. Please support the Hungarian wikipedians and internet users!

More: in Reuters

--Texaner (talk) 15:37, 22 October 2014 (UTC)

RfC on the Vietnam war

RfC: Should the lead for the article Vietnam War state "War crimes were committed by both sides"? Please add your views :)OnBeyondZebrax (talk) 00:01, 23 October 2014 (UTC)

The RfC is at Talk:Vietnam War#RfC: Should the lead state "War crimes were committed by both sides"?. OnBeyondZebrax, please make sure that you include a direct link to the RfC itself, otherwise people may comment in the wrong place. --Redrose64 (talk) 09:46, 23 October 2014 (UTC)

RfC: Should the lead's coverage of French history be broadened?

RfC: Should the lead's coverage of French history in the France article be broadened? Please add your views on the France talk page.OnBeyondZebrax (talk) 00:05, 23 October 2014 (UTC)

The RfC is at Talk:France#RfC: Should the lead's coverage of French history be broadened?. --Redrose64 (talk) 09:52, 23 October 2014 (UTC)

RfC opened on meta on how to credit the contributors when translating or copying an article to another Wikipedia

Since enwiki is the biggest source for translations to other wikis, you might be interested in this RfC I have opened on meta: m:Requests for comment/Wikipedians and the CC-BY-SA license. Elfix (talk) 08:26, 23 October 2014 (UTC)