Wikipedia:Village pump (proposals)/Archive 106

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

---

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Change Contents link in Sidebar

It seems a little weird to have "Contents" in the Sidebar (added several years ago in a Sidebar redesign) immediately followed by "Featured content". Not only is the "s" vs. "no s" difference somewhat awkward, but the "Contents" link seems a bit too general in light of the other one. Could we possibly use a more specific label in place of "Contents" that would "go better" with the "Featured content" link right below it? Perhaps one of the following?

1. Content guide
2. Content guides
3. Content overview
4. Content portal
5. Explore our content
6. Explore Wikipedia
7. Reader's guide
8. Get started
9. Start here

(These are numbered for ease of reference, not necessarily because they're in order of my personal preference — although I must say the last two are my least favorites.) Opinions? Suggestions? - dcljr (talk) 20:59, 22 September 2013 (UTC)

I support this idea, and specifically favour options 1 and 4 and 6. –Quiddity (talk) 20:32, 23 September 2013 (UTC)

• Weak Support: Perhaps just simply "Content" would serve. Konveyor Belt express your horror at my edits 21:25, 23 September 2013 (UTC)

Re-name Articles for deletion "Articles for discussion"

As with Templates for discussion, not all discussions on this page result in deletion; they sometimes result in redirects and/or merges as well. I don't have much more to say, but changing it to Articles for discussion reflects a more neutral take on the deletion process. ViperSnake151  Talk  22:30, 23 September 2013 (UTC)

• Oppose:Discussion should take place on the talk page. Afd is not discussion to improve an article, rather it is what it says it is: disussion regarding deletion. Konveyor Belt express your horror at my edits 22:40, 23 September 2013 (UTC)
  • The problem is when talk is limited to the talk page of an article, it limits the audience to primarily those that are interested in the article, typically creating a bias against any proposed change (particularly mergers or redirects) and without the process aspects of AFD, any consensus reached there can be overturned by any editor. I will say that there is currently (as of today) an effort to construct an RFC that addresses the past issue of "Articles for Discussion" being a perennial proposal. --MASEM (t) 22:57, 23 September 2013 (UTC)
    • The editors who are interested in an article are the most natural people to be discussing it. It would be nonsensical to structure discussions to try to attract editors who are not interested. That's the current trouble with AFD - it's mostly random junk and so few people participate. Warden (talk) 23:09, 23 September 2013 (UTC)
      • That attitude creates the walled garden that allows articles to persist despite failing core policies and guidelines. As long as the Deletion Sorting project remains involved to sort this discussions to topic areas by interest, you will get a broad selection of editors - both with opinions for and against the nominations - involved as already happens at AFD. --MASEM (t) 23:42, 23 September 2013 (UTC)
• Oppose We have over 4 million articles and so it would be absurd to try to discuss anything and everything about them all in the same place. AFD already gets little participation and so can't cope with even the current small number of deletion discussions. Warden (talk) 23:02, 23 September 2013 (UTC)
  • If an article gets very little participation at AFD, that likely means that there is no one interested in improving it and deletion is a reasonable option (as state, the onus is on editors wishing to retain material to do the legwork to assure that) --MASEM (t) 23:43, 23 September 2013 (UTC)
• Oppose TfD and CfD can be used for renaming or merger, neither of which are the role of AfD. pbp 23:23, 23 September 2013 (UTC)
  • Er, why would we "pollute" Templates and Categories for discussion to discuss article issues? --MASEM (t) 23:46, 23 September 2013 (UTC)
    • I think he's trying to say that the reason TfD and CfD stand for discussion rather than deletion is because they're intended to allow outcomes for templates and categories other than deletion. He's not suggesting using them for articles. Jackmcbarn (talk) 23:50, 23 September 2013 (UTC)
      • That's exactly what I'm saying. I believe AfD to be serving the correct purpose, and see no point in the pollution you speak of pbp 03:11, 24 September 2013 (UTC)
• Support as deletion is not the only option available to articles submitted to this venue. There have been discussions that have closed as Merge, Userfy, Move, Redirect, and DAB as well. This proposal does not suggest that all articles need to be dragged to the forum to be discussed, it simply neutralizes the tone that it is indeed a discussion. Changing the name of this forum also does not mean that the other process can't, or shouldn't any longer, be used; however, the current name of the forum does imply that the only acceptable option in the forum is keep or delete and I find that unacceptable and contrary to the goal of building an encyclopedia. Technical 13 (talk) 23:34, 23 September 2013 (UTC)
• Support this perennial proposal, for several reasons; though I believe it should be made clear that the name change doesn't insinuate that content discussions should be held at this forum. Rather, it lines up this debate forum with the other namespaces for consistency. Secondly, it makes the important distinction that a discussion is not a black and white case of "should this article be deleted, yes or no?", but instead a grey scale gradient of "What should we do with this article?" Precedence has shown us that many merge, redirect and renaming discussions find their way here, and so there is a clear conflict that requires resolution - do we want the black and white debate that ultimately becomes a vote, or the discussion forum that decides the future of articles? In its current format, the title of this forum is often used as a wikilawyering technique to dismiss nominations which depart from the procedural "this article should be deleted because x, y and z." If the community feels this forum should be limited to black and white debates - with all nominations presented by the party seeking deletion, all outcomes limited to "delete" or "keep", and all other issues discussed elsewhere - then these expectatiosn should be made clearly and inconspicuously on this forum so as to direct irrelevant nominations to Requests for Comment or Dispute Resolution. - Floydian ^τ _¢ 23:36, 23 September 2013 (UTC)
• Oppose per the reasons given at Wikipedia:Perennial proposals#Rename AFD. I wish it were not possible to even post this perennial proposal without ticking a box that says, "Yes, I've read the reasons why this has been rejected six dozen times in the past, but I promise that my proposal will acknowledge and deal with those strongly held objections." WhatamIdoing (talk) 01:06, 24 September 2013 (UTC)
• Support - I've thought about this before. The problem I keep seeing is that proposed merges often hinge on the same determination of independent notability that deletions entail. Merges were originally thought of as article talk discussions because they were viewed as more about form and efficient display, and that is sometimes still the case in some circumstances. But more and more frequently, this has actually not been the case. A merge is often essentially a deletion for lack of evidence of independent notability. AFD is where article existence based on notability concerns should be discussed, and it shouldn't matter whether or not the article title can be viably redirected to an existing article (which is often the only reason we'll call a situation a "merge"). With respect to this being a perennial proposal I think it nevertheless warrants yet another look. equazcion� | 01:18, 24 Sep 2013 (UTC)
• Support as a simple matter of following practice. AfD outcomes can already be outcomes such as "merge", "redirect", or "transwiki", and often are. Black and white "keep" or "delete" arguments are not required to be the only ones made. Seraphimblade ^{Talk to me} 03:19, 24 September 2013 (UTC)
• Mere change of name will not accomplish anything but create lots of work for people who will be implementing it. Some time ago, I have posted here a proposal to spin off a new deletion process from AfD, based purely on WP:V/WP:GNG. And to define more rigorously what does it mean to pass that process instead of relying on vague notions of "consensus" to keep or delete something. (Another venue could be created for WP:NOT-related deletions. Actually I think that would then exhaust all the possible deletion reasons, making a "classic" AfD unnecessary.) I think that could have accomplished something. Keφr 05:29, 24 September 2013 (UTC)
• Oppose. AfD is where one goes for deletion of articles. It is a clear, straight-forward process that matches the name and everyone knows why the page has been nominated. Adding things like merges or redirects will increase the number of discussion (for example, we have ~700 AfDs and 11k merges). Editors will start nominating articles for things other than deletion in mind. At this point, commenting becomes harder, closing becomes harder and overall participation drops. For the TfD/CfD examples, many discussions get closed with no comments by others. Not to mention, deletion is where many new users end up due to their contributions, and it hard enough explaining just the notability guidelines to them. The argument that there are other outcomes does not make sense to me, because the outcome can be 'keep', which is the direct opposite of 'delete' and means the nominator's position did not match that of the community. This happens all the time, so why is it a problem that merge or userfy or redirect happen once in a while? I personally do not see this as a problem. I would support having a separate venue for merges, splits, redirects, etc. While is sounds like bureaucracy, in practice small, directed venues work best and editors like to focus on these. —  HELLKNOWZ  ▎TALK 08:00, 24 September 2013 (UTC)
  • As long as "merge" and "redirect" are valid outcomes from AFD, the above statement doesn't hold true. If AFD was truly a binary choice, sure, but we have various shades of grey in the process. --MASEM (t) 05:34, 26 September 2013 (UTC)
    • AfD is not a binary choice and I didn't say it was. I said the purpose of AfD is and should be unary - deletion. It so happens not everyone agrees when an article should be deleted, and we have many alternatives. I'm not saying those alternatives aren't valid (they are perfectly fine), I'm saying they shouldn't be the nominator's rationale and neither the process nor the name should imply otherwise. If you re-read my argument, you'll see I never say that outcomes should be somehow limited. —  HELLKNOWZ  ▎TALK 08:43, 26 September 2013 (UTC)
• Oppose there are better places to talk about merging renaming or redirecting. The current name clearly gives it purpose. Euphemisms are not needed. Graeme Bartlett (talk) 22:00, 24 September 2013 (UTC)
  • Then you're saying that merging renaming or redirecting are not acceptable outcomes for AfD because that is what the current name clearly says. (I hope you can see the other side of the coin and realize this is not an assumption of bad faith or any such silliness just because I'm pointing out what your comment says to me). Technical 13 (talk) 22:31, 24 September 2013 (UTC)
  • And a problem right now is that merge and redirection discussions, even if they close with consensus to do something, lack the "purpose" that AFD offers, allowing any editor to revert the change without any weight of the consensus mattering. Having some backing decision at a central venue other than the article talk page (eg wide WP consensus) strengthens the weight of these discussions. --MASEM (t) 05:31, 26 September 2013 (UTC)
• Oppose I continue to oppose this idea for one simple reason: the most likely outcome of an afd discussion is deletion. We should not sugarcoat it and pretend it is just a discussion and anything might happen because this might actually discourage newer users from taking steps such as researching better sources and fixing an article that would otherwise have been deleted. in all honesty I have also always thought the whole concept that changing the name would change the way it works is a bit silly. Beeblebrox (talk) 03:45, 26 September 2013 (UTC)
  • Vicisious circle argument (that is, until we try it we have no idea if this is what would happen), and also against practice, since many current AFDs do end in merges and redirection. BEFORE arguments would still apply and problems with that handled in the same way. --MASEM (t) 05:31, 26 September 2013 (UTC)
• Oppose (1) The argument "we can't call it Articles for Deletion because sometimes articles are merged" is fallacious: obviously there has to be some alternative to deletion or why would we have a debate? Should we only call it AfDeletion if all articles are always deleted? (2) The proposer seems to be advocating a change to the name without a change to the procedure: the current procedure is based around deletion (with rules that say you shouldn't propose an article if you think it can be saved). So it couldn't be renamed without reconstructing the AfD procedure. --Colapeninsula (talk) 15:49, 26 September 2013 (UTC)
  • Clearly there would have to be some process changes made, but it doesn't make sense to talk about what those have to be until we have consensus if we should change the concept of the process to begin with. (Eg if consensus was determined tomorrow to make the change, it would probably take a few weeks to distill how it should be done properly). --MASEM (t) 15:53, 26 September 2013 (UTC)
• Support. There are far more outcomes to a discussion than deletion, and the title is overly hostile. Fiddle Faddle 15:51, 26 September 2013 (UTC)
• Oppose (probably again). The change does not explain what the remit would be (which is vital if we don't want every article where these is disagreement taken to it), I don't see it as solving any existing problem. Sure, some articles are merged, that isn't sufficient reason to change the name to one that doesn't represent in any way the current system. DNR is basically "articles for discussion" already. AfD is for when the discussion, or dispute, is about whether the article should be deleted. We already have a system for requesting mergers without deletion. Dougweller (talk) 16:04, 26 September 2013 (UTC)
  • The biggest problem right now for merge/redirects (eg we know we don't want to lose the content/contribution history but the standalone article is inappropriate) is that discussion is limited to the talk page of the page to be merged and the target. Right there, the audience that will see those discussions is nearly always immediately biased against the merge/redirect (not always, but more often than not). Yes, you could carefully get input from associated Wikiprojects as to avoid canvasing but more than likely the projects in question will have the same point. So outside of people that follow general merge discussions, these rarely go through. Merge discussion need a better venue because we are talking about conforming articles to global wiki standards, not project internal ones. DNR would likely falter under the weight of adding merge discussions. AFDeletion is about nearly all the same issues and the same resolution steps exist, in addition to the benefit of having deletion sorting that helps to broadcast relevant discussions to a broader set of topics. We could replicate AFD for "Merges for Discussion" and get the Deletion Sorting teams on that but that seems like duplication of an unnecessary process that is already set up. And since when discussing deletion and merging, the same concepts on sourcing and notability come up all the time, so it seems silly to separate their discussions. --MASEM (t) 16:16, 26 September 2013 (UTC)
• Comment This is not getting consensus in part because the proposed rename is too vague. We primarily, first-stop, discuss Articles on the pages where we Talk about them (that's the purpose of that page). We primarily do not take editing actions by tool use except where necessary. Those wanting this should regroup and revise (for example, why would we have a centralized discussion, at all, if the consensus at the article was to merge). It appears the AfD exists because it and only it requires uninvolved tools, and its inefficient for regular or involved editors to have a discussion about tool use on the talk page, whereas regular and involved editors can merge and redirect. So, perhaps an Articles Organization board with a section for proposals for deletion and a section for proposals for reorganization (the first section (Deletion) requiring no prior discussion, as currently, the second section (reorganization) requiring some prior discussion/consensus editing) -- or at least something that does not mixup what editors can do for themselves and when editors need uninvolved tool use. Alanscottwalker (talk) 17:19, 26 September 2013 (UTC)

Proposal for a new board

How about a new board to supplement the Village Pump - the Village Idiot board? The idea is that this could be where questions are asked that don't really fit anywhere else. Examples: "Why is there a preference to set Monobook screens to green text on a black ground?", and "What is a product manager?". Peridon (talk) 19:03, 28 September 2013 (UTC)

Well, there is a miscellaneous Village Pump. Also, the Help desk, reference desk or Tea house may have a role like you describe. Chris857 (talk) 19:39, 28 September 2013 (UTC)

No, they're all for 'sensible' questions. I'm thinking of something rather more off the wall. Peridon (talk) 20:25, 28 September 2013 (UTC)

• Support - I think we could use something like this, kind of a semi-entertaining yet not totally irrelevant pump for exploring curiosities that people might be hesitant to bring up elsewhere. equazcion� | 20:34, 28 Sep 2013 (UTC)
• Strong Oppose- As a Teahouse host, I am against the idea of directing newbies who know little about Wikipedia to a "village idiot" board. The name itsef is derogatory enough, and there is a more sensible option than yet another abandoned dump message board where newbs will ask a question and promptly get ignored. Konveyor Belt express your horror at my edits 20:44, 28 September 2013 (UTC)
  • Who said this was for newbies? I see it kind of being the opposite, and wouldn't direct newbies there. Either way though, the name doesn't seem derogatory to me, but rather tongue-in-cheek. Kinda has that "Books For Dummies" appeal to it, where people can feel more comfortable asking "silly" questions. equazcion� | 20:54, 28 Sep 2013 (UTC)
• Oppose We already have a place for people to do this. It is called "The rest of the Internet". --Jayron32 20:56, 28 September 2013 (UTC)
• Support per User:Equazcion - We have "Books For Dummies" so why not a "board for dummies!, Seems a brilliant(ish) idea. →Davey2010→→Talk→ 21:14, 28 September 2013 (UTC)
• It has previously been suggested that we rename the current WP:Village pump (Jimbo), perhaps these ideas could be combined? ;)
  More seriously, (a) the 2 example questions are both valid HelpDesk questions (or Refdesk if you don't mean WMF's product managers), and (b) creating new Noticeboards without strong justification just adds to the overwhelming proliferation that a newcomer has to navigate (See Template:Noticeboard links), and (c) a silly-questions noticeboard is likely to turn into a vector for sarcasm and other easily-misinterpretable comments. –Quiddity (talk) 21:58, 28 September 2013 (UTC)
• Oppose This will undoubtably result in users being directed there by less than welcoming Wikipedians. Not exactly a warm welcome. Ross Hill22:23 28 Sep 2013 (UTC)
• Oppose Jimbo's page does just fine (and there is no way of renaming it). We don't need another place no one will answer you. I'm sick of answers at noticeboard being- wrong place. Go to xx." posting to the wrong place is a procedural error and per policy procedural errors do not invalidate someone's attempt at getting help or doing anything. Despite some attempts around her to shut down things based on technicalities.Camelbinky (talk) 16:16, 29 September 2013 (UTC)
• I thought the entire thing was the Village Idiot Pump, with just the 'idiot' part normally left unsaid. And here I find out that I'm apparently not supposed to be acting like an idiot everywhere? Pfft. -— Isarra ༆ 19:13, 29 September 2013 (UTC)

Move editing notes from top of page

To the bottom. The page is what greets public users. Those notes are not for them. Place at bottom of page where editors can check them. (aka Cleanup Templates) (I've only seen past proposals for moving to Talk page) George Slivinsky (talk) 05:36, 29 September 2013 (UTC)

Part of the rationales for placing them at the top, are that they're a call to action (encouraging readers to become editors), and they alert readers to potential problems in the article they're about to read, and they remind (or introduce) readers as to how this project is built. –Quiddity (talk) 05:52, 29 September 2013 (UTC)

I think most if not all of the reasons for rejection in WP:PEREN#Move maintenance tags to talk pages apply to this related proposal as well. Anomie⚔ 11:14, 29 September 2013 (UTC)

Not good editing practice. When you invite guests into your home do you have dirty laundry laying around? George Slivinsky (talk) 17:00, 29 September 2013 (UTC)

Wrong perspective. When you give those guests directions to drive to your house, do you tell them that is a road that may be washed out, or do you just let them drive through it and stall out their car and drown? Do you tell them to walk right through the gate, or do you warn them about the angry pit bull in your yard? And maybe they would like to help with that laundry, if only they knew it was there and that their help would be welcome. Nobody is just a "guest" here, anyone who reads Wikipedia is a potential contributor as well. Hiding problems with articles for those not in the know is out where to look s exactly the wrong approach. Beeblebrox (talk) 18:12, 29 September 2013 (UTC)

Cleanup templates most definitely are for public users. It's an essential part of the critical thinking and "wiki-literacy" that Wikipedia needs to promote that readers should be warned of problems with an article, and shown that the problem could be something that they themselves fix. We don't have a hard distinction between "readers" and "contributors" the way a more traditional publisher does. MartinPoulter (talk) 14:05, 30 September 2013 (UTC)

Wrong perspective. Much too oriented to your editing function. Very overstated reasons. George Slivinsky (talk) 16:37, 30 September 2013 (UTC)

• Wikipedia is not perfect, and should not try to look that way. Since anyone can edit, everyone should know of the problems that anyone can fix. Konveyor Belt express your horror at my edits 16:43, 30 September 2013 (UTC)

I have to disagree with everyone here. Most of the general populace is actually still unaware that they can edit Wikipedia, despite the many "You can edit this" notices. It's a curious phenomenon, but my own explanation is that those messages are dismissed subconsciously by the brain as obviously intended for someone other than themselves; because the notion that I can actually edit this is "too good to be true", and "there must be a catch", because how could any website survive if anyone can edit? It's not apparent to most editors here just how unknown the true nature of Wikipedia is to most others, as once one has started editing, one forgets that one ever didn't realize they could edit. Anyway, the maintenance templates don't help there, if you ask me -- the parts that tell the reader to fix things are again dismissed by the subconscious brain outright as something meant for someone else.

But there's a better reason to keep them at the top: They clue readers in to possible issues they might want to consider in judging the reliability and accuracy of the information in articles. That's it. These templates represent, both literally and figuratively, "notes from the editors", and are of just as much value as such notes would be in other publications. If there's a potential problem or suggested improvement etc., readers are best off reading articles with those in mind. equazcion� | 17:07, 30 Sep 2013 (UTC)

Colored and helter-skelter talk pages

I have two problems with talk pages:

• new contribs are mainly in the bottom of the page, so I have to scroll 10 meter of the page to read the last 10 cm.
• when I am there and the discussion is really heat and with more than 2 editors I must read almost all old contribs, to know which are the new contribs.

My proposals are very simple.

1. Let us agree wikipedia wide to write new contribs at the top of the talk page.
2. Mark newer contribs (say 24 hours) with a (little) different background color.

--Best regards, Keysanger (what?) 19:45, 29 September 2013 (UTC)

We're already working on a fix for those problems. See WP:FLOW. Jackmcbarn (talk) 19:57, 29 September 2013 (UTC)

Proposal for language setting

Many users speak more than one language. Like me German AND English. I often cross-check between articles on the same subject, but in their respective tongue.

However, because so many articles are written in such a large variety of languages, if becomes tedious to find either German or English in the list.

Therefore I suggest, that in the user setting, or even through cookies alone, one can select the his favourite languages and have these displayed on the top of the list. — Preceding unsigned comment added by CGFell (talk • contribs) 09:54 30 September 2013‎

I'm not sure if this is a common enough need, but then again I'm not multi-lingual myself. If you just want to do this for yourself, it can be done pretty easily with a script.

• Edit User:CGFell/common.js and paste this line:
• $('.interwiki-de').prependTo('#p-lang ul');$('.interwiki-en').prependTo('#p-lang ul');
• Save.

You'll need to do this at the German Wikipedia as well (although I'm not sure what the German equivalent of common.js is, you may need to ask there). Also note it'll only work when you're logged in. equazcion� | 10:26, 30 Sep 2013 (UTC)

See also the thread [Design] Making inter-language links shorter and this UX prototype. The suggestion is to extend the mw:Universal Language Selector, which already has some way to propose a selection of languages. However, currently this is just an idea, not scheduled in any development roadmap. If someone wants to help pushing it, mw:Mentorship programs/Possible projects] would be a good start.--Qgil (talk) 20:12, 30 September 2013 (UTC)

Wikimedia Foundation employees are members of the community

Wikimedia Foundation employees are members of the community, arbitrary break

It seems that many conflicts between the WMF and the community arise because the WMF tends to wait until community proposals are nearly or completely over before stating their opposition. They currently see themselves (generally speaking -- I don't want to speak for all of them) as a separate legislative body with veto power. In the best cases, they see the need for a second consensus determination to take place following a community discussion, where the WMF and the established community position are the two sides.

Wherever this notion came from, I think it requires changing. I'd like to create a policy that states, or reinforces (depending on your view), that WMF employees and representatives are community members who can participate in community proposal discussions -- and that they must do so, if they want their opinions to be considered in final outcomes, just as any community member should expect.

The ability to enforce this is, of course, questionable at best, should the Foundation disagree with it. Yet I feel enacting it would declare something important about the community's position regarding the way things are supposed to work, as well as document the source of the conflict, as we see it, that is bound to rear its ugly head in the future, for easy ongoing reference.

This is by no means a well-packaged static proposal. I welcome input on how it could be changed to make it more viable, useful, and perhaps even more likely to be accepted for future practice by the WMF. equazcion� | 00:49, 24 Sep 2013 (UTC)

Interesting. I'm not sure the only reason WMF employees don't participate is because of them as a "separate legislative body with veto powers." A fair number, I believe, don't because of accusations of trying to meddle in local wiki decisions, it is deemed very important to let the wiki be the wiki and (WMF) next to the name carries a lot of weight both for good and for ill. Many are admins on enwiki, but still put a firewall between their (WMF) personas and their established editor ones.

I think more fleshing out of this idea is in order. For instance, how would this statement scale across the hundreds or so wikis out there that are not enwiki? - tychay (tchay@wikimedia) (talk) 01:18, 24 September 2013 (UTC)

I know that I personally don't engage in proposal discussions because of the following reasons:

1. I don't want to be seen as trying to "muscle" a conversation,
2. I often don't feel it is appropriate for me to get involved in a discussion (largely an offshoot of the first reason),
3. I often feel paralyzed about saying anything, because words I say are often read as a "de facto law" because of the staff position, and
4. Many staff - myself included - often feel that any comments we make will be met with extreme hostility and incivility that it's often just best to ignore the conversation entirely and actually just do your work.

We've also been trained that it doesn't matter what we say - someone will always disagree, and usually vehemently. It's very draining and frustrating when you have to keep a smile on your face while people call you an idiot. There's more to it than that, but that's the gist of it.--Jorm (WMF) (talk) 01:35, 24 September 2013 (UTC)

Do you find that people aren't calling you an idiot now? :) (Just making a point about your argument; I'm not calling you an idiot). The point being, I think most of the reasons you specify occur 20-fold and with more dire consequences when you stay out and shoot things down afterwards ("you" being the foundation, not necessarily you personally), as evidenced by recent events. I think with a policy in place that the community establishes on its own based on broad input -- if we can indeed get it established -- we would end up with a generally altered and improved view of WMF employee participation in community proposals. equazcion� | 01:45, 24 Sep 2013 (UTC)

(edit conflict) (Warning: this is going to get a bit rambly and theoretical. Embark at your own risk.) If I'm understanding your point correctly (which I may not be doing), this is, at least theoretically, what the WMF hires Community Liaisons to do. It's the liaisons' job - again, theoretically - to speak for the Foundation to the community, and for the community to the Foundation. If the community holds an RFC on Project X, the Project X liaison's job is to participate in that RFC in an informatory capacity. In practice, this has turned out to be an exceptionally hit-or-miss idea, with CLs tending to publicly take the "side" of the WMF in on-wiki conversations while, I suspect, being shut out from active input into development in intra-WMF conversations. As a result, they're put in a position where they can't do anything the community wants done anyway, and find themselves being painted more and more as WMF shills by the community, which assumes they don't even try to pursue what the community wants. Recent comments by staffers that they feel it's not their place to join in community discussion are, I think, to some extent predicated on the idea that "hey, the codemonkeys code. the managers manage. the talky people talk to the community. when codemonkeys or managers talk to the community, things get screwed up." Which is sometimes true, but just as often, when the talky people talk to the community it's no better, because the talky people can't affect the code, which is what the community wants to talk about.

As far as a solution to that...I don't know. We're never going to get the devs to hold full-fledged RFCs on product features, and even if they could, I'm pretty sure they would refuse to, on the principle that they don't need our permission to work on Mediawiki. One possibility is charging the actual product engineers/managers with speaking for their teams rather than the WMF continuing to use CLs who lack the power to affect much of anything except community ill-will. And I don't mean Manager X telling underling Y "Go tell the community they can't have blah". I mean that the people with actual power to affect the product's development should be talking to us - and listening to us, in return - about the product. This might mean that more engineers/managers/singing porpoises needed to be hired, to pick up slack during the time in which the "liaison" engineers/managers/porpoises interact with the community, but that engagement time has value and should nevertheless be set aside.

Another possibility is increased liaison transparency. If the higher-ups cannot engage with the community themselves, they need to be responsible for engaging with their liaison and, in turn, the community's questions, thoughts, and wishes. Right now, that interaction is a black box to the community, and as a result we see "pushy" liaisons (and yes, occasionally product managers) hammering on WMF's preferences, but almost nothing about whether the actual decision makers are even being told about the community's preferences. We don't know if the talky people aren't passing the message, if they're passing a distorted message, if they pass the message but the managers ignore it, or whether so many people are involved in the game of telephone that what starts as "The community wants a sparkly purple umbrella" finishes as "The pony wants a fish." Quite how a transparent version of this could work, I don't know - CLs logging which messages they pass back and forth, somewhere onwiki? - but it's something worth considering.

At any rate, I think you do have something in your idea that the WMF needs to engage in community processes when it wants the community to accept its proposals. The real question is which part of the Foundation, at what level of power, and in how many voices? And how much does the WMF's !vote count in those discussions, compared to one community member, or to many? A fluffernutter is a sandwich! (talk) 01:45, 24 September 2013 (UTC)

The point is basically that the "codemonkeys or managers" already end up engaging the community with disastrous consequences. They may stay out of community proposals for fear of precisely that, but they end up doing so anyway, and at entirely the wrong time (after the community has come to its decision and feels it should be enacted). I'm proposing that the foundation consider the reality -- that they will be engaging the community, and that it's really only a question of when -- and that doing so during the community discussion is the more constructive option. Anyone at the the foundation who has an opinion on a proposal, and who would need to end up presenting it should a proposal gain community consensus, should instead participate in the discussion while it's ongoing. Limiting that participation to liaisons is not viable because it only provides a PR layer to tell the community what the WMF position is (as I understand it), when a discussion is a give-and-take that must include the possibility of all sides compromising and reconsidering their positions. equazcion� | 01:58, 24 Sep 2013 (UTC)

• If they are, then they need to be banned from the project for disruption: WP:Competence. VanIsaac_{WS Vex}^contribs 02:06, 24 September 2013 (UTC)

  And this is a great example of why we are loathe to comment on anything.--Jorm (WMF) (talk) 02:08, 24 September 2013 (UTC)

  This is a flame-free zone. There are several existing venues where you can go to pile on zings to the foundation. Jorm, and everyone, please take the high road and don't feed the trolls. We're trying to remain constructive here. equazcion� | 02:13, 24 Sep 2013 (UTC)

• I think the piece above is part of the problem. Vanisaac is not a troll, and nor are the rest of us who have been growing increasingly frustrated with the Foundation's heavy-handed treatment. It may not have been phrased in the best or most constructive way, but polite discussion didn't get the Foundation to listen. It took a "Damn it, if you won't do it we will" to get them to do what we unambiguously told them. It shouldn't have taken that kind of push; as soon as the consensus was apparent, that it would happen should have been a foregone conclusion. The same should have been true here, but that still hasn't been done, and the whiz-bang wowie this will solve it "new article interface" put forth as an "alternative" (read: "%@#!* you, we're doing it the way we say") hasn't solved anything. We still speedy hundreds of junk articles every day and delete countless more, and while most of the ones we get are from editors who were not interested in contributing constructively anyway, some are. One of the most recent is at Serenism. Obviously junk, obviously had to go. We were right to delete it. But the contributor was not acting in bad faith. They just didn't understand how it works here. Maybe making a few edits before a creation would have gotten them to understand it, and just maybe we would've retained that editor rather than driving them off. As it is, I'm stuck explaining to them "Well, yes, the article you wrote is junk and does need to go, and the bunch of deletion notices you've gotten are correct, but please do stick around and help us out. Really."
• It's time for the Foundation to realize that the volunteers who do this day in and day out (who they dismissively call "power users" and disregard, and who incidentally built the vast majority of their projects) actually know what those projects need. And apparently, politely telling them doesn't get that across. It's apparently time to show them in stronger terms. That's not trolling, it's the point WMF has brought it to. They've steadfastly refused to listen to asking politely, even with strong consensus. If they don't want the requests to become more strident, they need to listen in the first place.
• And yes, Foundation employees should be considered members of the community, just like every person on Earth is entitled to be. What they should not be is "supermembers", entitled to veto the consensus of the community because they hold technical control. As a means of comparison, I can go delete an article against consensus, or block an editor without consensus to do so, because I have those buttons. But the reason I'm entrusted with them is that the community knows I won't do that. If I start doing it, I'll be relieved of the ability to rather quickly, and I should be. Since WMF won't respect consensus voluntarily, it's apparently time to relieve them of that ability, too, as was done with Visual Editor. That's a shame, and I'm sorry it had to come to that, but it was the right thing to do. WMF is here to keep the lights on and the servers running, not to act as some type of ruling body. WMF cannot keep playing at I didn't hear you and expect anything but severe pushback and a total loss of community confidence and trust.
• As a final note, if WMF doesn't want to be seen as trying to "muscle" a conversation, it would be helpful to not, you know, do that. That would mean to implement the consensus of such conversations rather than throwing them casually to the roadside. Seraphimblade ^{Talk to me} 02:52, 24 September 2013 (UTC)
  • So, can I take that as a "support" for this proposal? equazcion� | 02:56, 24 Sep 2013 (UTC)
    • Absolutely. And in many cases, if WMF were to join a discussion, and say "We would like to commission an expert on this subject, could we suspend this discussion until we provide the community their report in X weeks?", they'd find the community intelligent enough to understand that more data is good and willing to work with that. What the community won't accept, and never will, is these heavy-handed overrules of clear consensus. Seraphimblade ^{Talk to me} 03:10, 24 September 2013 (UTC)
      • "WMF is here to keep the lights on and the servers running" Our monthly reports make it pretty self-evident that our remit is clearly not limited to what you describe, and hasn't been for years. Steven Walling (WMF) • talk 04:05, 24 September 2013 (UTC)
        • @Steven (WMF): If you're going to take that hyper-literally, no, obviously not. Nor did I mean it hyper-literally, and I would hope that was clear. My point was that it is WMF's job to serve its communities, not to rule them, and especially not to overrule them. It is similarly not WMF's place to decide that its existing dedicated volunteers are "power users" to be dismissed and blown off, and that some hypothetical out-there future editors are more important and that the seasoned volunteers do not in fact have any idea what they're doing. That's the exact kind of problematic attitude that's caused the blowups over the past couple of years, and eroded trust almost entirely between the community and WMF. So let me ask you this: What do you see as outside the WMF's responsibility, and how do you think WMF could have handled situations like ACTRIAL and the pushback to VE in a better way? Seraphimblade ^{Talk to me} 04:13, 24 September 2013 (UTC)
          • Point taken about literalism. However, people who work for the WMF and shape its direction, including the Board of Trustees and Sue Gardner (Sue will correct me if I am putting words in her mouth) have unequivocally said the WMF is not the servant of the communities, doing whatever it wants at all times. We are partners, with differing responsibilities and areas of expertise. Just like you don't want to be blown off as a "power user" with nothing to contribute and no say, we don't want to be blown off as a mere "servant of the community", filing paperwork on your behalf and dusting off servers. ;) In any case, I think you are right to ask for greater clarity about roles and responsibilities. This is a much larger and more nuanced topic than I can convey in this reply, to be honest, but characterizing the situation as a partnership, where each group has something to provide and the ability to have an equal voice in the conversation, is something that I think is the ideal. To answer your question about ACTRIAL etc. directly: yes, being equal partners means that sometimes we are going to overrule a bad idea. Other times, like here with rolling back VE to opt-in for registered people and not at all for anons, we are going to acquiesce to something we honestly don't want to do, in the name of not continuing to escalate an issue more unnecessarily. What the VE team wants is to make VE great, and having talked to them today, they sincerely hope that the current state of the configuration will be a step that gives them room to do that, rather than continuing to debate about the previous mistakes in the rollout. Steven Walling (WMF) • talk 04:39, 24 September 2013 (UTC)
            • Well, then, to answer you directly: You didn't overrule a "bad idea" with ACTRIAL. You overruled a good idea with a bad idea (the new article creation interface). If you'll see my above comment, we've still got a flood of junk articles coming in, sucking time out of volunteers and admins and steadily driving off new editors as their attempts get nuked from orbit. The community knew what was needed (experience before attempting creation), and the WMF patted our heads and said they knew better. It's failed miserably, but that's not figured into anything, and WMF is still pretending to have gotten it right. That's the problem with the idea of a "partnership"—even after that abject failure, WMF hasn't turned around and said "Oh, our way really did fail, guess time to try yours." A relationship where one party can unilaterally overrule the other, and is willing for any reason to exercise that ability, is not a "partnership", it is a dictatorship. The only reason VE got changed is because we forced the issue, after the creation of an ocean of ill will and bad blood. The community could force ACTRIAL with the abuse filter, and it may come that we have to do that, too, after the problem continues long enough and you refuse to see your "fix" didn't fix it. That sucks, and it's a terribly poor way to do things, but it seems the only thing WMF responds to is force if what we ask for isn't what you intended to do anyway or at least a minor variant on it. Major deviations from what WMF thinks best, even if strongly supported, get a rote and apparently immutable NO.
            • So, do you want to be partners, and give on major issues that strongly matter to the community even when you don't think they're the decision you would have made? Or would you prefer to hold the power to make an absolute overrule, and continue to grow the rift between WMF and the communities they depend on? You can't have both. Seraphimblade ^{Talk to me} 05:09, 24 September 2013 (UTC)
• Comment I believe it's difficult for WMF employees and contractors to join in discussions because of the animosity directed at them. These are the folks that put in countless hours to keep the servers running, the software updated, add new features, fix bugs, etc. but are often treated poorly. It's difficult to put you blood, sweat and tears in to something and then be criticised for it. I think this same basic problem is a significant part of the reason new editors don't want to join Wikipedia. As an IP, I am very familiar with this. The hostility problem has been around for years. As just one example, see Bullypedia, A Wikipedian Who’s Tired of Getting Beat Up, which lead to the WP:NEWT experiment back in 2009. Things have only gotten worse since then. The media often report on Wikipedia's hostility. People will only take so much abuse before they simply stop participating. Perhaps if we could fix the hostility issue, more people would join in. Just a thought. My contribs for those that have difficulty following the WP:AGF guideline. 64.40.54.225 (talk) 02:55, 24 September 2013 (UTC)
  • The possible wider WP:BITE issue is not something I'm hoping to address here. I think the WMF vs. community issue is a small piece we can maybe bite off and chew sensibly for the time being. There is of course a longstanding rivalry that won't be resolved overnight, but establishing a policy may at least give it a decent start. equazcion� | 03:01, 24 Sep 2013 (UTC)

• I've had the opportunity to meet quite a few WMF staff over the past couple of years. To a person, they *care* about the WMF projects; I don't mean they see them as their livelihood, they really care about what the editors think, about how to make the projects better and easier to use, about trying to understand what makes both editors and projects tick. And a lot of them find the community, particularly the English Wikipedia community, quite overwhelming. I think we have to be honest with ourselves and admit that there have been a lot of examples of poor behaviour on the part of some editors directed at WMF staff; in fact, I've commented on one example tonight and read half a dozen more. Just like in any other communication medium, even if there are 10 positive or neutral comments, the one that everyone remembers is the flame. We need to do more to actively discourage this kind of behaviour, at all levels.

  I was at Wikimedia this year, and the conversation that made the greatest impression on me was one where a young engineer was telling me about his work; I didn't understand half of what he was saying, but I recognized that faraway, dreamy look of a man who loves what he does, is thrilled that it's improved the user experience and can hardly wait to do something else that will have the same effect. I think it's easy to forget that only a few years ago, the total WMF staff would have fit around my dining room table (well, if I put all the leaves in) - and now we have a really robust staff that is working to fix problems that have been identified for years. (Yeah, I know, it's not "our" staff. But most of what they're working on is designed to help *us*, and there are very few vanity projects around.) I think there is a lot of good work being done on a daily basis that we've already grown so used to that we don't even notice it. A lot of things do work better and more consistently and more reliably and more straightforwardly than they did a few years ago. That doesn't happen without people caring about what they're doing. Risker (talk) 06:03, 24 September 2013 (UTC)

  • Risker That's pretty and all, but how bout the proposal? ;) I think talking about how one party in this may have mistreated the other invites comments about who started it, even if placing blame wasn't your intention. I rather look at this as a situation where hostilities were bound to crop up due to errors in the de facto "system". equazcion� | 11:09, 24 Sep 2013 (UTC)

• @ Risker, Equazcion a lot of them find the community, particularly the English Wikipedia community, quite overwhelming – if only we had a modern discussion system that made it easy to comment on proposals instead of having to wade through a wall of text to find where to insert your comment, then calculate how many colons you need in order to indent properly, then persevere through 5 edit conflicts... /me whistles, walks away... :)

But seriously, I think before we have a conversation about getting staff involved in proposals and other community discussions, we should be up-front about the fact that there's a sizable chunk of non-staff community members whose voices aren't represented in these discussions at all. If you take a look at this study of bytes added to various namespaces by cohort of users from a couple years back, you can see that users who joined Wikipedia in 2006/7 are significantly overrepresented in the Wikipedia namespace (WP and WP talk), where the VPs and many RfCs are located. There are plenty of new users and even experienced users who have been editing for years and never get involved in these big meta-discussions; hence they get no say on matters of new feature trial and adoption – and I'm pretty sure it's not because they don't care. Building tools like Flow to make it easier and more inviting for them to voice their concerns/feedback early and often is part of the solution; recognizing our systemic bias (as experienced Wikipedians, as staffers, as whatever) and not getting caught up in an echo chamber is a far more difficult hurdle to leap, but it's just as necessary. Maryana (WMF) (talk) 02:54, 25 September 2013 (UTC)

I'm not sure what this has to do with the current discussion, but saying the technical discussion system is the reason for lack of participation is an assumption, and one I don't subscribe to. I think many people either indeed do not care about certain issues, or at least feel they don't understand them enough to get involved. That's not something a new forum system is likely to solve. Either way, I think this is a bit off point. We're talking about the WMF vs. community interaction for major proposals. equazcion� | 03:06, 25 Sep 2013 (UTC)

On this, Equazcion and I agree. In fact, there is no research that indicates that experienced editors who don't participate in discussions fail to do so because they don't like the format of the talk pages. I think you're trying to make a silk purse out of a sow's ear with that analogy, Maryana. As well, your correlations are faulty: more currently active users joined in 2006/07 than at any other time in Wikipedia history; as I recall, this cohort is pretty much equivalent to all active users who joined in all other years combined on this project. So, I think if you're going to make an assertion that essentially accuses people from the 2006/07 cohort of freezing out all other users, you'd better have some hard data including independent studies that support such an opinion. Given the quality of much of the research that has been done by the WMF, and the rather absurd ways in which some of it is being used (e.g., using data from pre-Vector small-group studies to justify systemic changes in 2013, or even some of the studies being used for Flow), and the amount of digging required to find even the most basic statistical information on the users of the WMF projects, there's good reason not to rely on the data coming from within. Risker (talk) 04:20, 25 September 2013 (UTC)

Okay, how about "The Rise and Decline of an Open Collaboration Community", a paper published in American Behavioral Scientist, co-authored by John Riedl? Two of the authors went on to become WMF staffers later on, but maybe you can find it in your heart to forgive them for this callous misstep? :) If you're still not convinced and believe that this particular discussion we're having right now is perfectly representative of the opinions and interests of all Wikipedia community members (however you define community), and that the people who aren't present are choosing not to participate, I'm afraid the burden of proof rests with you now, as I've given you two sources, and you've yet to provide anything other than anecdotal evidence. Maryana (WMF) (talk) 20:45, 25 September 2013 (UTC)

Risker is only talking about "experienced editors who don't participate in discussions". The research you're citing is about new editors. We have some evidence at the top of this page that even experienced editors can't always figure out where discussions are happening, even if the talk page format is no mystery to them: just look at the proportion of people in the first section who didn't realize that the Notability Noticeboard even existed, even though that noticeboard has been listed at the top of all the administrator's noticeboard pages since 2009, in addition to prominent links at the relevant guideline pages. Even though the talk page format is not a significant barrier for the smaller group of users that Risker is talking about, I don't believe that we are justified in assuming that every experienced editor who wants to particpate in making a decision is actually able to participate. You have to know that the discussion is happening before you are able to participate. Whatamidoing (WMF) (talk) 21:54, 25 September 2013 (UTC)

Maryana, I find it somewhat ironic for people representing flow to be talking about listening. How strong was the feedback to the Flow team that they had to provide the capability to completely expand all wikitext markup, including templates and math, in a Flow-based discussion? Can you point me at any commitment anywhere that states that the Flow project views complete expansion of wikitext markup, including templates and math, as a design requirement? It's possible that I missed a statement on the subject, so I await your reply before proceeding.—Kww(talk) 17:49, 25 September 2013 (UTC)

Kww, You do watch WP:Flow, right? I updated it earlier this week to point to the latest prototype, which fully supports wiki text; there's a set of screenshots on Flow portal talk showing that it handles math and IPA and all that good stuff just fine. This has been out on the wikis for weeks. Finally, it's right there in the MVP doc – take a look. Short of my chiseling this into a stone tablet and/or climbing the Reichstag dressed as Spiderman, anything more you need to clear this up, or are we good? :) Maryana (WMF) (talk) 20:31, 25 September 2013 (UTC)

I would prefer you not to. However, writing it everywhere doesn't seem like a bad idea. Maybe that would silence the critics. Konveyor Belt express your horror at my edits 20:38, 25 September 2013 (UTC)

You pointed me at a discussion that began with "What wikitext will and will not be supported is a difficult question" and a document that contains "allowing users to copy-paste markup for most templates and advanced wiki syntax (math, IPA symbols, etc.) into their comments" (emphasis added). Surely you see the difference between that and a commitment that "the Flow project views complete expansion of wikitext markup, including templates and math, as a design requirement", don't you, Maryana? I think that's my major objection: we express what we view as requirements, and they get phrased as objectives with substantial wiggle-room. After the VE fiasco, I'm suspicious of wiggle room.—Kww(talk) 20:46, 25 September 2013 (UTC)

• • • Seriously? I think it's a fairly horrible idea, given the fact that it only takes one Wikipedian running wild and throwing around ad hominem comments to make any discussion feel like an insurmountable battlefield to WMF staffers, particularly when there aren't a lot of Wikipedians participating (q.v. WT:FLOW). And in discussions with dozens if not hundreds of people participating, it's almost impossible for anyone, including WMF staff, to keep up with the conversation, what's being proposed, what alternatives are going to fly, and so on. Further, it's not unusual for WMF staffers not to be notified of discussions. At the end of the day, there *are* some things that this community really has no business poking its nose into in an authoritative, "you must do things our way" sense (we don't have a place in having the final decision on what's stored on which server or where those servers are located, for example), and plenty of situations where there *has* been plenty of community participation that simply hasn't drawn the attention of the community as a whole (e.g., the move to Lua, and quite a few other changes directed to those who contribute technically but that have no effect on the editing interface). And I do not believe that this single community has the right to direct the work of WMF staff who we do not employ, supervise, recompense, or set objectives for. So no, I don't support the proposal as written, but I do believe that WMF staff are members of the community. Risker (talk) 13:47, 24 September 2013 (UTC)
• To indulge an analogy, this proposal is like saying the continent of Europe is part of the community of the people of the United Kingdom. True, in a way, from an environmental, sociological, etc. perspective but still subject to many other forces then the votes of some of those people, or their representatives at Brussels. And in the end its all still in Europe. Alanscottwalker (talk) 14:11, 24 September 2013 (UTC)
• I have given this a lot of thought over the past year or so, and I haven't arrived at any proper conclusion yet. I would definitely prefer it if the employees of the foundation are part of the wikimedia community. One of the problems is that the WikiMedia community is ill defined. Basically everyone who feels at home with the WikiMedia spirit and works on anything Wikimedia related is a wikimedian. So that makes all employees community members by default. Still I get the feeling they don't often feel it. An indication of this is that WMF employees talk about the community/ies quite often, as if they were no part of them. I feel a lot for the partnership model, but it is difficult to be partners if your partner has the power to overrule any decision if they would want to. At the same time, the employees are governed by the same basic principles we follow that make us all wikimedians. So what I have often asked myself is the following: when trouble stirs, and for example the English wikipedia editing community disagrees with the foundation, what should happen? One thing that is important, at least to me, within the Wikimedia movement is that you own your actions, and you don't do things you think are bad for the project. So when the editing community comes to a point where they want a change to be made, and the technical person they ask to carry it out is vehemently opposed to it, and think it will harm the project, what should they do? As a wikimedian, isn't it their responsibility that they refuse to carry it out, if they believe it is wrong? I think so. But then again, it puts us in a very skewed power balance, where employees of the WMF control the servers that run the content projects, and in the end, what happens on the servers controls everything.
  This has led me to believe that WMF employees should be part - as equals - in more projects alongside non-WMF employees. That might put the balance back again a little. But that leads to another problem: while we can encourage, we can't force anyone to take part in any project. We can also integrate more the other way round: more non-wmf people working on traditionally wmf-led projects: server and network administration, legal, and software engineering. The problem with that is that we try that all the time, but it's not really working. They need almost full time dedication to do right, and if a volunteer is both capable and willing to invest in that, the WMF quite reasonably looks to hire them. So what do we do? I don't know.
  So to your question, I vote support, and, er, good luck with it. Martijn Hoekstra (talk) 12:44, 25 September 2013 (UTC)

Comment from the new product manager at the WMF

I've been working at the Wikimedia Foundation for two weeks now. In that time, I've been taught a lot by my colleagues about the things the Foundation has failed at. I mean this quite literally; it was not a wishy washy discussion, or a discussion spun to suit an corporate agenda, it was explicitly "Here is a list of things the Foundation has failed at". I was very impressed by this attitude. The most echoed of those failings is community engagement. Multiple staff members, including those on the VisualEditor team, have recognised that the Foundation has not engaged enough with the community, and more crucially, that it has not engaged early enough with the community. James has explicitly stated that failing here. In recognising where it has failed, the Foundation has taken the first steps to fixing the problem. The specific next steps aren't clear. Erik has, quite eloquently (pun intentional), laid out a potential course of action that was discussed in the past few weeks. Further discussion is still taking place on our end.

On the other hand, in my opinion, a failing of the community is that some community members are incredibly hostile towards Foundation staff. It's quite easy to forget that almost all of the staff you see on the wiki, responding to the community, are long term community members. I've lost sight of this myself, once or twice. My point is that all of us have the best interests of the Wikimedia projects at heart. Perhaps you adamantly disagree with the actual implementation of that interest. That's fine. In fact, that kind of disagreement is healthy, as it encourages debate. However, letting rage take you over does not help matters, as it often obscures the point you're making. I've always found that when it comes to Wikimedia projects, calmly, concisely stating your point, and providing evidence to back your statements up, is far more effective in convincing people of coming around to your way of thinking than making grand statements about how everything is being done wrong and getting angry about it.

In summary, I think the Wikimedia Foundation recognises its failings, and is interested in ways to move forwards. The Foundation has made new employees such as myself aware of these failings so that we are less likely to repeat them. I am happy that this discussion is taking place, as it's constructively looking at ways that the lines of communication can be improved. There've been quite a few salient points raised already. I'm hopeful that something will come of this discussion.

--Dan Garry, Wikimedia Foundation (talk) 04:09, 24 September 2013 (UTC)

• The Foundation may have internally acknowledged failure, but towards the English Wikipedia, these acknowledgments are always too little, too late, and too wishy-washy. Take the one by JdForrester you link to: while supposedly apologising (but blaming his failure on "off-line comments"), he at the same time states " I'd note that the community has banned users for accusing each other of 'weasel' words in the past, as you just did". Great way to win back hearts, and all this hot on the heels of his (paraphrased) "I have implemented the opt-in because your solution ruined Wikipedia, but you are bad puppies who are wasting the money of our donors". So, in his opinion, the only failing is that he should have told the English Wikipedia earlier that the RfC was a waste of time and that no one was planning on implementing the consensus of it anyway, not that he should have taken the concerns of the English Wikipedia community more to heart and should have recognised the serious and widespread concerns we had instead of giving us a cosmetic pat on the head.

In summary, I don't think the Wikimedia Foundation recognises its failings at all (or at least didn't until we forced them with the opt-in change, perhaps this has changed something), and is repeating them at a high rate over the last few weeks (the amount of comments by WMF employees which blamed things on the English Wikipedia which were entirely to blame on the WMF and the VE instead is staggering). I believe we are interested in ways to move forward as well, but I at least would like some constructive proposals by the WMF. Fram (talk) 14:39, 24 September 2013 (UTC)

• Dan, I think you need to reread James's statement in a more jaded light, and you will see why it got the negative reaction it got. VE is regarded as bug-ridden and a sufficiently major threat to Wikipedia that it needed to be returned to the lab. There's no way to read the RFC and not see that. Our consensus on that was unprecedented: never in the history of English Wikipedia have so many users come to an agreement on anything. The actions I took over the last week are also unprecedented: I'm not aware of any previous event where the community has come together and agreed to modify the scripting files to consciously and intentionally defeat the will of the WMF. We could do that for many things: we could turn article creation off for new users, prevent anonymous editors from editing, all kinds of things, but we don't, and I could never get consensus to do any of those things. I wouldn't even try.

On this topic, though, the community gave emphatic support, and I did the unprecedented. And at that point, the WMF lashed out. It didn't acknowledge that it had been wrong to keep VE deployed. It didn't acknowledge that forcing the community to support its development effort at that level was wrong. No, none of that. It lashed out at me, claiming that I had deployed "known broken software" and had "ignored warnings about the damage it would cause." That's simply false: the software behaved as designed (with one known and relatively inconsequential limitation due to it being on the client side), and every piece of feedback that Catrope supplied about actual damage was listened to and acted upon before deployment. Even yesterday, well after the fact, you can see that the Erik was making statements that reflected an analysis of a week-old version of the code that I floated prior to testing, prior to announcements of impending deployment, and prior to review by anyone. Basically, I was accused of ignoring review when in fact, the WMF was ignoring the fact that I was responding to review and retesting the code carefully prior to deployment.

If you want to improve communication, a big part of that involves acknowledging mistakes and apologizing for them sincerely. One mistake that I'm still waiting for an apology on is being accused of recklessly risking damage to Wikipedia.—Kww(talk) 19:04, 24 September 2013 (UTC)

Well, if you think that some Wikipedians are uncivil towards the representatives of WMF, then act accordingly. Warn them on their user talk pages, report them at WP:ANI, start user RFCs, go to Arbitration committee... Otherwise, if you are doing nothing to stop the incivility you do notice, maybe you shouldn't complain if the rest of Wikipedians do the same thing (and about the incivility they do not notice, or consider to be insignificant - that should be assumed per WP:AGF)..?

Or, if you want appeal to some larger group of editors asking them to change their rhetoric, maybe you should state what you do not like in that rhetoric in a little more detail? And how things could be said better? Try using some examples. That would make your criticism much more useful.

For otherwise I look at the post I am writing here with little idea if you would consider it to be an example of that "incredible hostility" you are talking about. --Martynas Patasius (talk) 00:56, 26 September 2013 (UTC)

Hi Martynas Patasius.

In my observations as a volunteer, I've seen that civility enforcement is already a complex social issue. Warnings for civility are often empty threats, and the effectiveness of civility blocks is questionable. Considering how people are responding to the Foundation at present, and considering that those who are most likely to be uncivil are also those who would be criticising us, how do you feel people would respond to the Foundation responding to this criticism with warnings for civility? I think there would be a large outcry. I'm afraid I don't see how your solution is workable at all.

Examples of things which I think are needlessly hostile are calling for people to be fired and calling Foundation employees names. My solution is simply not to do those things, and comment on the matters at hand instead. This is in line with the long standing practice we have of not commenting on contributors.

With regards to whether your post is hostile, I would say that it is self-evident that it is not. The definition of hostile that I have here is "unfriendly; antagonistic". Your post was neither of these things.

Best regards,

--Dan Garry, Wikimedia Foundation (talk) 11:34, 27 September 2013 (UTC)

Yes, "civility enforcement is already a complex social issue" is not a bad way to explain things... But that's the point: if the community is not very good at keeping any discussions civil, why is it a "special" problem when it is not able to keep discussions with WMF representatives civil? And, from what I have seen, those discussions are not that uncivil - there are much worse cases...

In other words, if you said that incivility is a problem of the ones who are uncivil, you would have made a legitimate point. But when you said "On the other hand, in my opinion, a failing of the community is that some community members are incredibly hostile towards Foundation staff." and ended up creating an impression that you are accusing the whole community for the failings of the few, your point is no longer legitimate. I would recommend to retract or (far more likely) clarify it.

Then let's look at the examples: "Examples of things which I think are needlessly hostile are calling for people to be fired and calling Foundation employees names.". Name-calling is a standard example of incivility and is to be discouraged - at the very least. But then, I do not happen to remember many examples of it. There was something on WP:AN, I think, but, as I remember, it did get a response. I can think of no other clear examples at the moment. On the other hand, I am not sure that "calling for people to be fired" would have to be considered to be uncivil in all cases. After all, the precedent is that it is not uncivil to call for people to be blocked, banned, "desysopped" - by itself (though it can easily become uncivil without justification). Otherwise, we wouldn't be able to actually block, ban or "desysop" anyone. Are you sure that a call for someone to be fired must be that much worse..? (Yes, I think it is an arguable position, but are you willing to argue in favour of it now..? To say that working for WMF is "a big deal"..? I don't think it is a right time for that...) Maybe in some cases it would not be "uncivil", but just, let's say, "unfriendly"..?

And that's a further point: are you really saying that in discussions with "normal" Wikipedians, administrators, arbitrators we must be merely "civil", but in discussions with WMF representatives we must also be "friendly"..? And the requirement is unconditional - just as one must be "civil" even if one's opponent is not? (Yes, when Jorm is saying "It's very draining and frustrating when you have to keep a smile on your face while people call you an idiot.", he seems to be complaining about something expected of all of us.) If so, why should that be the case..? And shouldn't the representatives of WMF be unconditionally "friendly" as well..?

Anyway, if you are not going to do anything about the incivility and unfriendly relations on the community side (with exception of rather general calls for civility), there might be something you can do on WMF side. For example, in this thread (and in WP:AN) we have an instance of a member of community calling a representative of WMF incompetent. In return the representative of WMF has expressed his, er, lack of happiness... Bad idea. By the way, calling someone incompetent is also not uncivil in all cases. It is uncivil without justification. And that is what the WMF representative should have asked for. Let's say: "I am sorry to hear that you think I am incompetent. Could you, please, explain me the problems you see with my competence in more detail..?". Most likely, that would have defused the situation. So, can you get your team to act in that way..? --Martynas Patasius (talk) 19:28, 27 September 2013 (UTC)

Shameless plug for a page I created

It's at WP:Wikimedia Foundation, and it is intended to document/help communication about some of these things. For example, see Wikipedia:WMF#Reception, which anyone can edit, since it's Wikipedia. If we can come to a consensus version of what the Wikimedia Foundation has done in the past that affects the English Wikipedia, that might set up a useful framework to build community discussion upon. WMF employees and contractors are invited to edit the page as well, without prejudice. In fact, I'd argue that if you work for the WMF and you feel like you can't edit the page, then that's part of the problem. Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 11:02, 24 September 2013 (UTC)

I for one don't know what the story is behind the ACTRIAL thing, so could someone incorporate that? Thanks. Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 11:15, 24 September 2013 (UTC)

ACTRIAL (Autoconfirmed Creation Trial) was a proposal to temporarily try disallowing page creation by non-autoconfirmed editors. It was passed by the community but then vetoed by the foundation, similar to the Visual Editor situation -- but in the ACTRIAL case the community didn't have a recourse to move ahead anyway, so ACTRIAL didn't end up happening. Many people were and still are sore about this (it wasn't very long ago). The sequence of events there is one of the prime examples of the issue I described initially. equazcion� | 11:42, 24 Sep 2013 (UTC)

ACTRIAL's objective was to require the WMF to change the actual user permissions structure so that non-autoconfirmed accounts could not create pages in a specific namespace (i.e., article space). This is what the WMF turned down. As well, it was designed to redirect attempts by non-autoconfirmed users trying to create articles to articles for creation, which was a fairly ridiculous concept given that almost nobody works those pages. One of the core reasons for wanting to do this was that new page patrol got backlogged easily and unreviewed changes "fell off" the queue after about 30 days. Instead of doing this, the WMF made major changes to the software for new page patrol, which keeps all unreviewed changes in the queue regardless of the length of time they exist, better tracks the actions taken, allows one-click communication with the article creator, and (surprise surprise) isn't nearly as backlogged as the old NPP system. Their alternative was a much better idea, and it works better for the project. Let's get over ourselves about ACTRIAL. Risker (talk) 13:58, 24 September 2013 (UTC)

I don't think it's helpful for the purposes of this particular discussion to go back to judging the merits of any specific example. ACTRIAL had a broad consensus that the community was excited about and the foundation shot it down afterwards. Whether or not you think it was a good idea, it's an example of how things go badly, and how they'll continue to go badly, unless something changes in the system for WMF and the community addressing each other when major changes are on the table. equazcion� | 14:10, 24 Sep 2013 (UTC)

See now, this is what I mean. You're stuck on "we had a solution we liked, even if it required the entire reworking of the permissions structure of the entire MediaWiki interface, just to deal with an annoyance applicable only to this project", instead of "we got a better solution in the long run". I get the vision that was behind the idea. I also get that the technical solution proposed was a major change that would affect the entire MediaWiki structure. It's particularly true when the "decision" completely ignored the real problem, which was the new page patrol software. The problem wasn't new users creating pages. We shouldn't build (or make major changes to) software for philosophical reasons, and we have to carefully analyse the causes of problems rather than pinning our flags to the first "cool" solution that comes along; I think that should be what the takeaway was there. Risker (talk) 16:43, 24 September 2013 (UTC)

Arguing about past successes and failures of past projects will contribute nothing to the discussion. Konveyor Belt express your horror at my edits 16:53, 24 September 2013 (UTC)

Except that when you are actually trying to use those "past successes and failures" as a rationale for a proposal, it is necessary to assess them honestly. One can't say "Look at how you failed X", then complain we shouldn't look at X when it's pointed out that it wasn't failed to begin with. — Coren ^(talk) 18:28, 24 September 2013 (UTC)

No one's saying "look how you failed". Well, at least I'm not. I responded to mention of ACTRIAL because it's an example of how the system failed. I don't care whether it was a good or bad idea. I don't care if the alternative that came afterwards was better or worse. I don't care who says the community was at fault, and I don't care who says the foundation was at fault. I also don't care who had more of a right to be angry. I just don't care. It's completely irrelevant here. ACTRIAL was simply an incident that deepened the hostilities between the WMF and the community; it's a theme we're seeing repeat itself with VE and there's plenty reason to think it will do so again in the future with other proposals. Disregarding all of your (the general "you", nobody in particular) repeated crap recycled from other discussions that you've all made more than clear ad nauseum already (as have I), let's focus on the systemic flaw that causes these things to happen (and NOT on blaming either party).

Just for the record, at the Default State RFC I supported it remaining open for anonymous users. Think about this before you develop another urge to comment on the wisdom or stupidity of either the community's or the WMF's ideas. It's just not about that. There's something larger to discuss here, and if you can't get your head out of the merits of some proposal or another where one side pissed you off, kindly let others handle this particular discussion. equazcion� | 18:59, 24 Sep 2013 (UTC)

Except that it is ultimately about exactly this; the occasions where the community and the engineering staff clash revolve around two scenarios: either something some segment of the community wants is vetoed by engineering, or something the foundation wants is objected to by some segment of the community. Unless you confront the reasons why that happen, no systemic overhaul can be successful; and you must do that by analyzing the result and fallout of past occurrences. This proposal would have done nothing to change the outcome of that particular incident, for instance, and it's not clear to me that it would have improved the roll out of VE either because it does nothing to address the core issue (that is, different priorities). — Coren ^(talk) 19:25, 24 September 2013 (UTC)

The actual precedent set here is different. If "ACTRIAL" came up again and was scorned by the WMF, the result would probably be that an admin with a RC-watching bot would simply set it to copy-and-dump the new page into the new user's userspace, delete the article, and drop a note on their talk explaining why... all in the name of "implementing community consensus". The WMF botched customer relations just that badly now (remembering that the people who edit are absolutely the client when it comes to the editing interface). --SB_Johnny | ^talk✌ 21:31, 24 September 2013 (UTC)

I don't disagree, but...

So, I've always approached this discussion with an interesting perspective as a community member turned staff member (as are a not-insignificant number of others). I still consider myself a member of the community, so things like transparency and consensus are very important to me. I don't disagree that there can be tension between people when we're on different sides of consensus. In the end I always remember that it'll work out eventually because we're all on the same side and here for the same reason. The one thing I'd like people to keep in mind is the tons of work that goes on by developers (paid and volunteer) that largely goes unnoticed--many many bugfixes and features go out every single week without a hitch. Sure new big things can have hiccups, but that's part of the fun of developing software :) ^demon^{[omg plz]} 18:24, 24 September 2013 (UTC)

For the cases we're concerned with for the purposes of this discussion, things work out in the end because one side overrules another via technical means, with the other remaining quietly embittered. I actually don't consider such results an example of things having worked out, and I don't think anyone should. equazcion� | 19:12, 24 Sep 2013 (UTC)

Count me amongst the "quietly embittered". Eric Corbett 19:16, 24 September 2013 (UTC)

A hiccup is when your text is blue when you wanted it black. I don't consider pushing something out that can't handle basic functions a hiccup. That's something that wasn't ready to go beyond a mid-sized beta test. Intothatdarkness 14:51, 25 September 2013 (UTC)

Things we can do

We can appeal to more editors to volunteer to test the software. We can write an appeal in the Signpost and put appeals for volunteers on noticeboards for WikiProjects and the like. We can ask for volunteers to achieve modest but specific goals ("This week, please make ten edits using the Visual Editor and then put your feedback on the feedback page") and we can increase the prominence of the link to opt in to the Visual Editor.—S Marshall T/C 20:51, 24 September 2013 (UTC)

VE had many testers before it launched to the entire project. Many things were solved, but many were also not solved prior to the launch. At the date of the launch there were somewhere in the hundreds of open, unresolved bugs. Some might've been minor, but as we can see, community (and each of us as individuals) saw how error-prone it was. tl;dr testing doesn't always fix things. Killiondude (talk) 03:38, 25 September 2013 (UTC)

Does testing ever fix things? I thought fixing things fixed things. --MZMcBride (talk) 03:49, 25 September 2013 (UTC)

I'll also note that comparatively little testing was taking place until VE was made the default editor because, absent the ability to use templates or add references, it was not terribly useful. Those two key components were added at the same time as the switch to default, meaning that core functionality had zero beta testing before the switch to production. This was, in and of itself, a major failure to follow even the most basic beta testing practices. Having said that, I do intend to continue to test VE where possible. As Killiondude and MZMcBride correctly point out, though, testing does not equal fixing. Risker (talk) 04:57, 25 September 2013 (UTC)

• That's accepted, folks, but it rather misses the point. We've had conflict between the community and the WMF. What's important is that the conflict ends and we get back to co-operating, and that means listening to the other side's concerns and reacting to them. As I understand it, the WMF's concern that we can do something constructive about right now is that with the Visual Editor set to opt-in rather than opt-out, not enough testing will happen. Therefore what we, the community, can do right now to heal whatever perceived rift might exist, is take constructive steps to get more testing done and more feedback given. It's an attempt at a bury-the-hatchet-and-move-on approach, you see.—S Marshall T/C 08:28, 25 September 2013 (UTC)

• But they are rolling it out to what, 20 new Wiki versions this week? Let them be the guinea pigs for a change, together with the other Wikipedia language versions that have VE and haven't made it opt-in yet (French, Italian, ...). If these wiki-versions combined don't provide enough testing, then I'ld like to know why. Plus, there are anough serious open bugs to keep the developers busy for quite a while before a new, much improved version can be presented for renewed testing anyway. At least, that's what one would expect in a normal environment. Fram (talk) 08:53, 25 September 2013 (UTC)

• Along with the appalling change management proceedures that initially brought it to us all without choice, I found VE unacceptably slow for doing almost anything. I'm always keen to try new things, but am hesitant about VE until it becomes a lot faster. HiLo48 (talk) 09:06, 25 September 2013 (UTC)

• It's only to be expected that many people, for many reasons, will not want to participate in the testing, or will question the technical need for it. I can't participate in the technical discussion because I lack the relevant expertise; but when the WMF representatives tell me the opt-in conclusion is a problem because they're concerned about testing, I'm prepared to (a) accept that at face value and (b) come up with suggestions about how we could try to persuade people to engage with the testing process. I do understand what you're feeling, and I have expressed the same concerns as HiLo48 about the product and the process. Still, there's a rift that needs healing and what we, the community, can do right now to heal it is to take constructive steps to get more testing done and more feedback given.—S Marshall T/C 12:08, 25 September 2013 (UTC)

• Sadly, I no longer accept anything the WMF says at face value. But even believing them, why would I care? I'm concerned about the encyclopedia, the quality of the articles, the quality of edits. IPs testing new software in it on a large scale is not beneficial (in toto, individual edits may of course be beneficial). The WMF have done zilch to heal that rift (enabling the opt-in after we had an opt-in procedure is not something I count as a positive step, certainly not in the way it was presented here); let them make some first attempts. Enough testing has been done, enough feedback has been given (and often ignored); once the major problems have been solved, they can come back and ask us whether we would be willing to open up a bit more again. There is no reason at all to do that now though. When they think they have solved the major nowiki, file, table, ref, redlink, infobox, IE, ... problems, then a new round of more large-scale testing may be appropriate. Until then, they can use the test wiki or any other wiki that is willing to be their playground. Fram (talk) 12:29, 25 September 2013 (UTC)

My personal intention is to wait until the most critical bugs in the backlog are fixed (table editing and some version of cut-and-paste) and then I will start testing it extensively.—Kww(talk) 15:24, 25 September 2013 (UTC)

• Unfortunately, when VE debuts, it will be up to the editors who only edit in source code to clean up the mess of wikimarkup that VE leaves behind. Konveyor Belt express your horror at my edits 15:35, 25 September 2013 (UTC)

MediaWiki forking

I mentioned this once a long time ago, and it seems somewhat relevant again. Another root problem that may be present is the difference between what's good for the generally distributed MediaWiki software and each individual Wikimedia wiki. Whereas once they were one in the same, MediaWiki and English Wikipedia are basically two different projects with perhaps somewhat differing priorities now, and complications may have arisen because they're still managed as one.

This is just food for thought at this point, but I was thinking that large WMF wikis with capable community developers could have volunteer bodies of developers manage their own MediaWiki forks. The Foundation's MediaWiki changes could be reviewed by the fork teams, who would then decide whether to implement which patches into their forks, based on community input and testing. The fork teams could also develop their own patches, which the Foundation could decide whether or not to incorporate into the MediaWiki distributable. equazcion� | 04:37, 25 Sep 2013 (UTC)

MediaWiki and Wikimedia projects are in fact not really managed as one. MediaWiki and Wikimedia projects are released separately, and there's lots of work that goes on which is not driven or owned by Wikimedia Foundation employees or editors of Wikimedia projects. The vision you're describing, where code is passed back and forth between MediaWiki as a general software distribution and Wikimedia projects, is basically the status quo. Steven Walling (WMF) • talk 07:37, 25 September 2013 (UTC)

Well, that's really not the status quo though. English Wikipedia is still not independent of the whims of WMF developers as to whether or not "updates" to the software are implemented or not. The problem with the VE rollout is largely that en.wiki was treated as a testing sandbox for the developers, instead of as an independent project with its own culture and goals that might not be the same as that of WMF. Placing the responsibility for decisions on updates and changes on-wiki would give the largest and most visible wikimedia project the ability to say "we want to enact ACTrial", and WMF would be able to say "let us know when you figure out how to do that". On the other hand, this community could say "hey, VE is not ready for prime time yet, let us know when it has the functionality we need", and WMF can still do its thing through other projects that aren't mature enough to govern themselves, or that have a community more tolerant of experimental tools. As long as the people in charge of implementing changes to the mediawiki software on en.wiki are beholden to the WMF and not this project, there are going to continue to be fiascoes like the VE rollout. VanIsaac_{WS Vex}^contribs 12:41, 25 September 2013 (UTC)

Vanisaac pretty much nails it here. equazcion� | 13:05, 25 Sep 2013 (UTC)

Not quite. You both are missing the larger picture, I think. Currently configuration of Wikimedia wikis is done by editing PHP files directly (exposed at <https://noc.wikimedia.org/conf/>). This includes edit rate limits, enabling extensions, adjusting project logos, etc. If someone were to spend the necessary time and energy to put these settings behind a proper user interface, stewards (or even local bureaucrats) could be empowered to make changes on a per-wiki basis. Forking MediaWiki and other such topics are tangential and probably unhelpful. Giving wikis control over their own settings is the goal, so why not simply do that? mw:Requests for comment/Configuration database has some relevant notes. --MZMcBride (talk) 14:36, 25 September 2013 (UTC)

Developing an interface could offer individual control over certain settings, but would be much more limited. If an individual wiki decided it required a change not predicted by those who developed the interface, they would still have to appeal to the foundation developers, who may or may not see it as something worth the effort to develop for the MediaWiki distributable. Giving individual wikis control to edit the PHP files of their own MediaWiki forks would offer the same control plus a lot more. There's also the question of how the Foundation's MediaWiki patches would be handled in your scenario -- would each change entail a new setting that the individual wikis could turn on and off, and who would decide which patches required such a setting? I visualize there still not being the requisite separation of interests with your scenario. equazcion� | 14:44, 25 Sep 2013 (UTC)

You seem to have a flawed view of how MediaWiki (and Wikimedia) development works. I think you should get involved in order to better understand what you're discussing. :-) --MZMcBride (talk) 14:59, 25 September 2013 (UTC)

I don't think I do have a flawed view, especially as Steve Walling appears to think this is how things work already. Either way your response isn't all that helpful. If you want to point out specifically what you think makes my suggestion infeasible you may attempt to explain your thinking. equazcion� | 15:04, 25 Sep 2013 (UTC)

In order to optimize or improve a system, you have to first understand how the current system works. I don't think you do. There are a number of ways in which to gauge someone's participation in development (e.g., bug reports submitted to Bugzilla, edits to MediaWiki.org, wikitech-l mailing list participation, Gerrit changesets submitted and reviewed, IRC lurking, SVN revisions, edits to wikitech.wikimedia.org, etc.). I don't study you closely and perhaps you're more involved in development than I'm giving you credit for. If so, I apologize.

A cursory examination of your activity—along with your comments here—suggested to me that you're not particularly involved in MediaWiki or Wikimedia development. Consequently, I can't give much weight to your ideas about how to improve it, as quite simply, I don't think you're informed enough (right now!) to offer a valuable opinion. To be clear: I'm not trying to blame or shame you for not being involved, in fact I'm encouraging the opposite. If you spend a few months getting/being involved, I think you'll have a much better understanding and appreciation of the current development process and you'll be able to find (and advocate for) much more realistic means of improving it. --MZMcBride (talk) 15:57, 25 September 2013 (UTC)

What happens to changes that aren't written by the Foundation? It would totally suck if we made our volunteer developers jump through hoops to see their work actually be /used/ by anyone. Also: this makes it sound like every change that goes into MediaWiki needs to be signed off on by the local community. That's not practical. There's dozens and dozens of completely non-controversial changes that go into the code every single day and this bureaucracy would make it impossible to ever get those live. Also, sometimes there's performance or security concerns; the community shouldn't be allowed to hold that up ever.

So I'm totally for increased participation in MediaWiki and I've called for it for years. All of the software is open. All of the mailing lists are public. MediaWiki.org is not a private wiki. Problem is we talk here and then nobody comes to participate with the devs. ^demon^{[omg plz]} 15:22, 25 September 2013 (UTC)

Thanks for posting here ^demon. (FWIW, I have tried to communicate some at mw but I found it impossible to understand: [1]. Has the setup over there changed?) In my mind, people don't get upset about small changes that improve the system. People get upset about big changes create many bugs, usability issues, etc. And it seems, with MZMcBride's comment to Erik here, that this was a mistake coming from management, such as Sue/Erik. On a human level, I'd like an apology from Sue/Erik, so we know what WMF thinks they did wrong and what they'll do to make sure it doesn't happen again. But at the same time, how long did it take the German Wikipedia to switch it off? Days? I guess we at English Wikipedia might have a lesson or two to learn how to be as well organized as them. How did they manage that? I'm sure some of it has to do with their large, well organized, well funded, and tech-savvy chapter, but still. If we could have turned this off in a couple days, then we wouldn't have had this drawn-out drama fest. So ^demon, I'm excited to see what the VE is like after a while of fixing. And I do plan to submit my first bugs or feature requests soon. It took me a little while over to figure out what the difference was between a bug/feature request. At first it was a mystery, with me being a dumb new user. It seemed like when I started going into Bugzilla from mw, that the only option I had was to submit a bug. It was very confusing until I backtracked my way to read more at mw:How_to_report_a_bug#Reporting_a_new_bug_or_feature_request. Maybe we should change the documentation over there? I've tried to explain what I learned over at WP:WMF. Did I do it well? Feel free to edit over there. As for Bugzilla, there's a bit of a psychological barrier in the minds of many here, unfortunately, about taking the steps to submit a bug report/feature request. I'd love to see a friendly YouTube/open licensed video explaining Bugzilla in 3 minutes to people. But still, I should have submitted the bugs I want to submit already. That fault lies with me. By the way, let me know if you see me doing something stupid over in the "territories of the devs", so hopefully I don't repeat my mistakes twice. Thanks again. Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 16:43, 25 September 2013 (UTC)

And ^demon, I figured out how to start mw:User_talk:^demon#I_replied_to_you.2C_FYI_33606 this time without as much trouble over there as I've had before. But did I notice a bug? I'm not sure I've completely gotten my mind around that talk system yet. Maybe it just takes some getting used to. It doesn't seem to be widely used. Does anyone know if that system has any similarities to what WP:Flow is supposed to be like? Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 17:04, 25 September 2013 (UTC)

It wasn't a bug. I had previously watchlisted a page that had this "thread" as a "parent". But I couldn't tell this "thread" was a "child" to a "parent" I actually cared about immediately. I hope I got the terminology right on all that. Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 17:15, 25 September 2013 (UTC)

You're very welcome. I'd rather not speak to VE much--I'm not on that team, I do cool backendy things that hopefully no one ever notices--but let me just say that I'm not 100% pleased with how it was rolled out either. It needed more testing, obviously. The problem is how to engage people? To take a different example (and shamelessly plug my own project), right now we're working on completely overhauling the search engine that powers WMF sites (we've done some cool things if you want to read about it). We want people to test it because we know we've not ironed out all the bugs yet. But not many people are testing yet. I'm open to suggestions here, as I think everyone will agree that the end result is better when people test early and find bugs that can be fixed before wider deployments.

As for Bugzilla and MediaWiki.org... bugs and enhancements both go in Bugzilla (for better or worse), and there's plenty of people who will make sure it ends up in the right place if you misfiled or something. And MediaWiki.org is a wiki, just like any other, pages can always be improved at a later date. Better docs can help, that info you added to WP:WMF looks pretty good to me. I also think that video tutorial idea is really cool so I filed a bug to track it.

While you should be careful around developers, I promise you we're a generally nice group once you get to know us :) ^demon^{[omg plz]} 17:19, 25 September 2013 (UTC)

Thanks! Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 18:10, 25 September 2013 (UTC)

^demon I'm not saying every single patch should need community approval; only that English Wikipedia volunteer developers should make that determination, and present large changes to the community when they deem appropriate -- as well as roll back changes they didn't foresee as controversial, if the community decides it's best. equazcion� | 19:52, 25 Sep 2013 (UTC)

So enwiki runs the same version of MediaWiki that everyone else does plus or minus config differences. We are not going to have a special enwiki-only fork of MediaWiki, full stop. Let me outline our development process (briefly):

1. A change is proposed to MediaWiki/extensions/config/etc via an RFC or Bugzilla or the mailing list
2. Code is written and debate begins on Gerrit
3. Code is iterated on, fixing all problems that have been identified
4. Code is merged by a developer (we have different maintainers for different repositories, and many many non-WMF mergers)
5. Depending on urgency, how its being rolled out and where it lands during the deploy cycle, it can be live on the sites anywhere between a few minutes and a week or so at most (we don't deploy from master, so code also has to be merged to the relevant deploy branch(es) by a shell user)

I'm totally fine with people joining this process (especially the first 3 parts). Where in this process do you see these supposed English Wikipedia Developers having their say-so on deployment? ^demon^{[omg plz]} 20:17, 25 September 2013 (UTC)

This proposal sounds good on paper, but if implemented I strongly suspect that a year later we'd see that a major deployment produces the same negative reactions that we see now, just directed at the "local volunteers" rather than WMF. Someone eventually has to say "deploy now" and go ahead with it, and we simply don't have a working system for ten thousand active users to give commentary on proposed changes before they're rolled out. Andrew Gray (talk) 20:48, 25 September 2013 (UTC)

(edit conflict) That works out then -- After code is merged by a developer into MediaWiki (your step 4), English Wikipedia's developers examine the changes and decide whether or not to merge them here. Only thing is, there would be another smaller-scale set of these steps running in parallel for enwiki's developers to propose, write, fix, and then merge changes the enwiki community wants to see into enwiki's MediaWiki branch. Responding to Andrew Gray (post-edit-conflict), the local volunteer developers would be just that -- local volunteers, established members of this community whose job is to implement enwiki community consensus, rather than to tell us what we need. All developers tend to get flack, but the special brand of flack reserved for WMF people wouldn't occur in my scenario. :) equazcion� | 20:59, 25 Sep 2013 (UTC)

Wouldn't it work out better for these people to insert themselves into steps 1-3 rather than adding a new step and significant complexity to the deployment process? It's a whole lot easier to fix things when they're being debated and written, rather than after the merge. Personally I'm much more likely to respond well to someone saying "hey this isn't going to work for XYZ reason" during the planning/writing stage, rather than as I'm wrapping things up and possibly moving on to the next thing. I'm totally fine with more community members being involved in development--it certainly makes MediaWiki a better product--but I just think it's counterproductive to be involved so late in the process. ^demon^{[omg plz]} 21:13, 25 September 2013 (UTC)

Again this has to do with the difference between enwiki's priorities and WMF/MediaWiki's. Vanisaac explained this better than I could have above. It's similar to the reasons WMF people stated regarding why they don't get involved in enwiki community discussions -- same issue, sort of, only reversed. MediaWiki development isn't, and in a certain sense shouldn't, be tailored around what the English Wikipedia's community wants. They've grown into two different things in many regards, and any solution that nevertheless demands a continuing near-identical development of both will continue to generate conflict. equazcion� | 21:20, 25 Sep 2013 (UTC)

I disagree. This is why we have feature flags for most new things (ability to turn them on/off) and generally make things configurable. It's incredibly easy to handle particular needs when you're doing the initial development--then we end up making it more flexible for everyone. What you're proposing is to continue what we do now, but have a committee of local developers review all changes and say "yay/nay" before they go live. That's never how the code's been written or deployed, ever, and I can't say I think it's a good system. I think it'll break down pretty quickly and create whole different kinds of conflict. I imagine lots of time wasted resolving merge conflicts. I predict a fair bit of confusion about dependencies (heck, we have enough of a time coordinating changes between core and extensions across two wmf branches as it is). Also, who's going to do this? You talk about volunteer developers, but who are you referring to? Do they have any idea how much work they're signing up for...code review is a time-consuming task and there's a lot of changes ^demon^{[omg plz]} 22:00, 25 September 2013 (UTC)

As ^demon has said, we shouldn't try to make things easier by making them more tedious. Konveyor Belt express your horror at my edits 22:08, 25 September 2013 (UTC)

^demon Alright then, how about letting an English Wikipedia team control those flag settings? equazcion� | 22:56, 25 Sep 2013 (UTC)

Within reason, the community is able to control those flags. The configuration is all available in git, and anyone with an account can propose changes. Also, we've always accepted config change requests via Bugzilla. All we want to see is consensus. I don't disagree with MZMcBride that having a UI for it would be nice (I've long wanted to do it), but it's not an easy problem so let's not wait on it. ^demon^{[omg plz]} 23:05, 25 September 2013 (UTC)

^demon So if there's a demonstrated consensus for, say, disabling Visual Editor, we just request that and consider it done? :) You see where I'm going with this... Without any direct control by community people there's conflict. equazcion� | 23:29, 25 Sep 2013 (UTC)

Of course it's never that easy ;-) I've really been trying to avoid talking about VE (it's really really not my thing...), but....I'm only speaking for myself but I personally think that VE is still a little too beta and should be opt-in for the time being for those wishing to test it. I don't think the product is as polished (yet!!) as others do, but I certainly do like where it's going. Direct control of all settings is simply not possible--many settings have massive performance implications if they're turned on or off. Enabling or disabling an extension always needs a shell user to guide it as there are often non-config things that need doing. ^demon^{[omg plz]} 23:51, 25 September 2013 (UTC)

^demon I'm not trying to steer this towards the merits or pitfalls of VE. I was actually for keeping it up, even for anonymous users, and said so at the RFC. But once it was clear where consensus lay, it shouldn't have mattered what either of us thought. If a shell user is needed to guide such changes in a purely technical fashion, that's fine. The "executive" configuration decisions, as it were, for English Wikipedia's branch of MediaWiki, can still at least be codified as ours. equazcion� | 00:11, 26 Sep 2013 (UTC)

As long as there are no technical reasons to oppose or the decision isn't completely insane to our values, I think community consensus should be respected. I've always thought that, being a community member myself. ^demon^{[omg plz]} 00:15, 26 September 2013 (UTC)

Of course, then deciding what or what not is insane to our values must be done by a higher authority. But then if WMF could block anything as "being insane to our values", we'd be back at where we started. Konveyor Belt express your horror at my edits 00:28, 26 September 2013 (UTC)

(edit conflict) ^demon Under this proposal, you would not have the opportunity to "oppose" (except from within the proposal discussions, as a community member) -- and I use quotes there because what you're really referring to is a veto, as opposes from the WMF currently are. You seem to be suggesting that things are fine as they are, but they're not, so we're discussion a possible change. It's not going to be good enough, in the interest of avoiding these repeated instances, to say that we will just continue submitting configuration requests to the Foundation, and they will make them... so long as they're not "insane". Insanity is a vague threshold open to interpretation, and one that both ACTRIAL and the disabling of Visual Editor apparently crossed, by WMF standards. We again need something at the very least codified, that configuration decisions are determined via demonstrated community consensus. Stewards can be required to sign off on and make the larger requests to make sure something truly "insane" doesn't get through, with shell users then being required to make the changes. equazcion� | 00:34, 26 Sep 2013 (UTC)

(edit conflict) Of course consensus should be respected when possible (read: almost always) but technical management of the sites is not a democracy and it never has been. It's always been up to the shell users and WMF to be the final arbiter of what's acceptable on the sites, that's nothing new. ^demon^{[omg plz]} 00:40, 26 September 2013 (UTC)

No one said it was new. It just needs to change, or the WMF and the community will continue to be at each others' throats. And it's good to know that you engaged in this exchange continuing to point out technical problems with the suggestions, when all the while you opposed it on principle as well and were never planning on budging there. You could have saved us both some time by letting me know this was not up for debate as far as you were concerned long ago. I'll remember this for next time. You have not helped here. Quite the opposite. equazcion� | 00:47, 26 Sep 2013 (UTC)

To get it a bit clearer. There are 3 reasons that hold up configuration changes in general.

1. People have not put in the effort to make a change actionable (Still takes more than 15 minutes to process the request (not taking into account execution))
2. A change is technically problematic / unsafe for the stability of the parc of websites
3. A change is politically problematic. (WMF has different view, so WMF employees usually won't volunteer the execution of the change but need to be pressed).

You will never ever get rid of reason 2 is what demon is saying, you might be able to change something about 3. —TheDJ (talk • contribs) 11:51, 27 September 2013 (UTC)

MediaWiki forking break 1

I'm a little reluctant to restart this conversation, but I'm confused about how this is supposed to solve the stated problem ("the WMF and the community will continue to be at each others' throats").

So right now, we have this situation:

• Party A wants X, but Party B wants not-X.
• Party A controls the servers and "wins".
• Party A and B are not happy with each other.

Equazcion wants to change the settings in step #2, so that in a disagreement, Party B "wins", which gives us this:

• Party A wants X, but Party B wants not-X.
• Party B controls the servers and "wins".
• Party A and B are still not happy with each other.

How does this actually solve the problem? I understand how it makes Party B happier, but how does this actually result in Party A and Party B not disagreeing with each other? Is the idea that the people we're calling "the community" will scream about 'losing', but the people we're calling "the WMF" won't mind, or will be too forgiving or too professional to mention it?

I think that if you want real conflict resolution, then you need real conflict resolution, not just a simplistic change in the rules about who "wins" unresolved conflicts. Whatamidoing (WMF) (talk) 20:27, 30 September 2013 (UTC)

Whatamidoing (WMF) If you look at it in terms of winning and losing, yeah, I guess you could describe it this way. That's a little more cynical a viewpoint than what I have in mind. English Wikipedia and MediaWiki have each grown to the point that they have their own goals and initiatives that can come into conflict. Allowing each to develop in their own way should, by all rights, remove the conflict. If you want to predict that the WMF would still be unhappy in that scenario, well, I guess we've seen here that there are grounds to call that an accurate assumption. English Wikipedia certainly wouldn't be unhappy in that scenario ("Party A and B are still not happy with each other"? I don't think so. It would be one-sided at that point.) Nevertheless, even the WMF would perhaps become accepting of the idea if they saw the results. It would certainly be better than the situation we have now. equazcion� | 21:22, 30 Sep 2013 (UTC)

If you assume that The Community is going to be perfectly happy with the WMF when the community overrules the WMF (and so all the unhappiness is one-sided), then why don't you assume that the WMF is perfectly happy with the community when the WMF overrules the community—and so all the unhappiness is one-sided then, too? (And the WMF would presumably be accepting only if it saw good results, as defined by itsself, not just any old results.) Whatamidoing (WMF) (talk) 03:16, 1 October 2013 (UTC)

Whatamidoing (WMF) Relations between WMF and en-wiki should not be a win-lose relationship. If we allow each to develop as its own per equazcion, there shouldn't be as much conflict (I won't say there absolutely won't be) as there is now. I don't see how the WMF loses here, although there is certainly room for argument along those lines. Konveyor Belt express your horror at my edits 21:37, 30 September 2013 (UTC)

While I agree that a win–lose relationship is difficult, I think that your underlying assumptions about the possible solution is wrong. Developing the projects (including, but not limited to, the English Wikipedia, Wiktionary, Commons, and more) is the WMF's purpose. The WMF can't really develop independently of its main reason for existing. "The WMF" and "MediaWiki software" are not the same thing. The WMF isn't just "the software" or "the people who write the software". If that were the case, then whole programs could be simply eliminated as irrelevant. Wikimania could be replaced by Hackathons. You could cancel Wikipedia Zero, Global Education, Grantmaking, and Legal and Community Advocacy if the WMF was just software development.

We could, if people really wanted to, allow MediaWiki to develop without giving any consideration to the needs of the English Wikipedia. I hear that this would make the devs' work (both paid WMF staff and the many more devs who are volunteers) much easier, because writing code that scales to this size is difficult. But I don't think that you would be happy with this: it would mean that you didn't get any support for anything you wanted, including security patches or anything else, unless someone just happened to feel like it. Whatamidoing (WMF) (talk) 03:16, 1 October 2013 (UTC)

I guess we should just consider ourselves lucky that you accommodate us at all, shut up, and say thank you. Or I dunno... maybe you should consider yourselves lucky that we write and maintain the encyclopedia that primarily keeps you in business for free. Or, as a possible third option, when you're ready to drop the attitude and talk as though you were attempting to defuse the power struggle atmosphere, you could let us know. equazcion� | 03:29, 1 Oct 2013 (UTC)

Well, there's no reason to be rude about it....Konveyor Belt express your horror at my edits 16:36, 1 October 2013 (UTC)

Equazcion, I'd like to get rid of the power struggle. But your solution doesn't do that. Your solution amounts to "Equazcion gets all the power. Therefore, Equazcion is no longer struggling for power. Therefore, there is no power struggle (or at least no power struggle that interests Equazcion)." That's not a real solution. The WMF needs editors, and the editors need the WMF. Do you have ideas for shared power? Whatamidoing (WMF) (talk) 16:59, 1 October 2013 (UTC)

You frame this as though the conflict arises from an equal sharing of power, and that I'm requesting a larger power share in order to create a default "winner", thereby averting conflict. This isn't exactly so. If you look at English Wikipedia alone, then yes, we're requesting a somewhat dominant share of the control, but that's not the full story. The WMF controls MediaWiki, as well as many individual wiki projects that use it, of which English Wikipedia is one. English Wikipedia, however, has grown so large as to have its own culture that can often conflict with MediaWiki's umbrella goals. Conflict will continue to arise so long as you fail to recognize what an independent organism it's become. The wise thing may be to let the colony have its independence, in a sense, rather than cling to the notion that it's still more or less one of the many that you can control collectively as one -- because really that's already barely true. equazcion� | 17:45, 1 Oct 2013 (UTC)

All of the projects with more than a trivial number of editors have their own culture, and all of them have editorial independence, not just this one. The WMF doesn't really even control MediaWiki: anyone can write code for it. The WMF only controls what the WMF employees write for Mediawiki and what forms of Mediawiki the WMF employees put on the WMF's servers for use by the WMF's projects.

You aren't really asking for the English Wikipedia to be "an independent organism". Independence means that you pay for everything yourself—servers, ISP charges, devs, ops, lawyers, domain names, trademarks, and so forth. You are asking to be the one with the power, but to keep all of the other benefits you currently receive for free. If you really wanted independence, then you've got that right: you can fork the project any time you want.

I'd like to suggest to you that this is, and should be, a symbiotic relationship, not a relationship between two independent parties. The WMF needs the English Wikipedia, and the English Wikipedia needs the WMF. The other Wikipedias need the English Wikipedia, and the English Wikipedia needs the others. Commons needs the English Wikipedia, and the English Wikipedia needs Commons. We need to work together towards common goals, rather than splintering into little fragments. Whatamidoing (WMF) (talk) 05:38, 2 October 2013 (UTC)

I'm not suggesting that we break off (which is why I tacked on such qualifiers as "in a sense", etc). You framed this as though it were about who has power, so I answered on your terms, even though that's not how I see it needing to be. And why exactly do you guys pay for the servers and all? Is it for the good of a community-run encyclopedia? Or if you hypothetically lost some control over its direction, would you feel the need to throw your hands up? In it for the power maybe? Without that, it's just not worth it? Is that where all this power talk comes from? This isn't meant as an accusation, but an examination of human nature. Sometimes everyone has to step back and get some perspective on what their efforts are supposed to be motivated by. Although, now that you mention it, I think breaking off English Wikipedia into a separate nonprofit might be one option.

Short of that, I'm suggesting something quite symbiotic, if you read my original post. We maintain a relationship by, among other things, passing code back and forth to each other -- only we get to make our own initiatives, and veto yours (concerning only English Wikipedia), when consensus determines there's a need for that (which experience has shown will not be often). And speaking of consensus, despite your again implying this is about "me", it's actually about the community of four million users who run this end of things (and I know full well that there aren't actually four million consistently active, but I think you get my point), and the decisions we're talking about would be a consensus of those as we can best determine it. There are no individuals seeking power here. Maybe it's just about spreading the power a bit thinner, over those four million. Think about it. equazcion� | 05:52, 2 Oct 2013 (UTC)

Actually, I have been thinking about this for several years now.

Speaking strictly on the understanding that I am definitely not a lawyer, or anything close to it, it's my personal belief that the WMF has a purpose that is defined in US federal law as "education". The "community-run" part is optional; the "education" part is not. That is, the WMF must provide an educational benefit, and having a community of editors has been a highly successful means towards that mandatory educational end. But the community is a means to an end, not an end unto itself. The WMF must support education; it may optionally support a community, so long as supporting that community is consistent with supporting education (for example, so long as the community produces educational encyclopedia articles). And it is my personal belief that if the "community-run" part were ever to interfere with the "education" part (something that I emphatically do not believe will ever be the case at the English Wikipedia, but let us imagine that some tiny Wikipedia gets taken over by propaganda-spewing Martians), then IMO the WMF would ultimately have a legal and moral duty to get rid of that education-harming community.

I believe that allowing a small group at one large community to affect everyone is not something that the WMF should permit, if (and only if) the decisions of that small group tend to act to the detriment of the WMF's educational purpose. Using VisualEditor as an example, if the WMF believed that deploying VisualEditor to the English Wikipedia benefitted other Wikipedias or other non-Wikipedia educational projects more than it harmed anyone (perhaps by providing a consistent user interface across multiple Wikipedias to facilitate interwiki translation work), then the WMF should deploy VisualEditor here, even though 0.4% of the active registered editors here signed a page saying that they didn't want it. The English Wikipedia is not an island entire unto itself. That's the nature of symbiosis: sometimes you don't "get to make our own initiatives, and veto yours (concerning only English Wikipedia)", because sometimes these decisions, especially UI-related decisions, don't "concern only English Wikipedia". Sometimes, other projects or other groups need you to make a choice that is much better for them, even if it is not ideal for you. It's about spreading the power to all the users at all the projects, not just to the (vocal) people at this one project.

(Please note again that this is just an example. I don't know whether making VisualEditor opt-in-only here is a big problem for other communities, especially at this time. If the WMF decides that it is, then I'm sure they'll make some relevant changes. But I've heard absolutely nothing about any such plans.) Whatamidoing (WMF) (talk) 18:42, 2 October 2013 (UTC)

MediaWiki forking break 2

User:^demon, is there a sign up sheet for early notifications on anything going on with the EducationProgram extension? =) Best. Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 21:21, 25 September 2013 (UTC)

@Biosthmors: The short term plan with that extension is that we are hiring a contractor in features engineering to make sure it doesn't completely fall apart. In the long run, it's a large, pretty unwieldy piece of software that has created not insignificant cruft in terms of additional namespaces etc. We are just starting to work on a spec for a more lightweight system that could allow us to invite a special group of people (students, editathon participants, whoever) and view their activity as a cohort. This is all very early stages, so I'm all ears about who/where best to discuss the topic further. (The work will be co-owned by the Education program, Analytics, and my team.) Steven Walling (WMF) • talk 21:34, 25 September 2013 (UTC)

Steven, I started Wikipedia:EducationProgram extension and ping to Sage about the page's existence as well. In an ideal world, I think it would be cool to have a prose summary of all the filed bugs with links to them but hey! Just something else to file in the wiki-backlog. Feel free to fix any mistakes I made or clarify anything. Thanks. Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 10:23, 26 September 2013 (UTC)

^demon, to be fair «We are not going to have a special enwiki-only fork of MediaWiki» is in a way a simplification: MediaWiki development definitely is tampered by en.wiki-only or (at best) Wikimedia-only considerations: either stopping good changes just because Wikimedia wikis are not able to handle them; or forcing everyone to swallow changes designed for Wikimedia projects but not good for others. The former happens more often and was discussed e.g. at [2] with no real functioning conclusion.

On the other hand, it's also bad when changes useful for everyone are developed in a way that doesn't share it with all MediaWiki users, and this happens too. So I can only agree with your conclusion that there is no bright line or clear cut separation that can help anything. --Nemo 07:49, 27 September 2013 (UTC)

An RfC on reducing the API edit limit for logged out/IP users to once every 30 seconds

Hi guys, just letting everyone in the proposals department know about an active RfC here that proposes the API limit for logged out users be reduced to 1 edit every 30 seconds.—cyberpower ^Chat_Online 23:44, 2 October 2013 (UTC)

Sidebar overhaul

I'm proposing we work on an update to the sidebar, with a focus on clear prioritization of the links we have, considering removing links we might think are redundant, and adding one new link. Comments and additional ideas are most welcome. I'm not enormously attached to any particular part of the proposal, but I would like us to consider ways to radically simplify and clarify such an important piece of site navigation. Steven Walling • talk 05:43, 3 October 2013 (UTC)

Hover Feature

I propose a feature whereby one may hover the cursor over hyperlinks and get a brief, concise description of the page to which the hyperlink is linked. This would allow users to read and understand articles containing people/places/things they are unfamiliar with without having to click the hyperlink and navigate away from their current page. This feature would be useful when in-depth information is not necessary and users only need the briefest of descriptions in order to continue reading with clarity. Users familiar with the Google Chrome extension Hover Zoom (where thumbnail pictures can be expanded by this same method of hovering) will appreciate the usefulness of this feature.

Of course, these short descriptions will have to be written and those hyperlinks without descriptions will function as they always have. — Preceding unsigned comment added by Laflagne (talk • contribs)

So, kind of like Wikipedia:Tools/Navigation popups? Chris857 (talk) 17:30, 3 October 2013 (UTC)

Yes, but as a default feature that users do not need to be logged in to use.

• Interesting idea - but only if there's a way of turning it off. Who is going to supply all the info for the little boxes? Peridon (talk) 19:24, 3 October 2013 (UTC)

I agree that there should be a way to toggle-off in the preferences but I think it should be enabled as a default. I had never heard of navigation popups and I suspect the same can be said for many casual users. Also, the use of navigation popups requires users to be signed in which is useless for casual users without logins. As far as supplying info, these short descriptions would be created just as regular content is. Knowledgeable users can add condensed descriptions and improve upon existing ones.

Can I ask you to sign your posts with four ~ things, please? It's getting confusing... Peridon (talk) 19:56, 3 October 2013 (UTC)

Sorry, I'm new to this.. Laflagne (talk) 20:46, 3 October 2013 (UTC)

Nav popups is great, and making it more visible to readers would be a very good thing to do (I'd love to see, eg, some kind of "here's cool stuff you can enable" message for newly-registered users), but I think you'd get a lot of annoyance from having it on by default. Even as someone who loves it, it's frustrating sometimes on very link-heavy pages. Andrew Gray (talk) 21:32, 3 October 2013 (UTC)

Wikireference

First, I apologize about my English. My mother language is Portuguese.

I am posting here only to announce the proposal of a new Wikimedia project that could be of your interest. It's about filtering, managing and formatting references. The proposal is already at meta:Wikireference.

I ask people interested in this project to express their opinions, and also sign the Interested List at the end of proposal.

I would be much obliged if someone could improve my english, here and there.

Thanks.

Lauro Chieza de Carvalho (talk) 15:59, 2 October 2013 (UTC)

 Note I fixed his grammar as requested above. —(っ◔◡◔)っ^{Ross Hill} 00:49, 10 October 2013 (UTC)

Stand down?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I miss User:ClueBot NG. It has been reverting about 70% of the vandalism before I could get to it. Now that ClueBot is offline, reverting vandalism is my main job. The slowness of human beings is encouraging more vandalism, I fear.

1) I propose that an old version of ClueBot be placed back online. There's probably some really good reason that this can't be done. I don't need the full explanation!  :)

2) In lieu of restoring an old version, how about semi-protecting everything? The semi-protect would automatically revert in 24 hours, but be renewable until ClueBot gets back online.

3) In lieu of that, fully protect (lockdown) all of Wikipedia. Maybe that will free up some software and personnel resources so the editors working on ClueBot can get it back up faster.

Thanks. Student7 (talk) 18:58, 5 October 2013 (UTC)

Neither 2) or 3) is going to happen, and both would be overwhelmingly negative overall. As to 1), it seems more likely the bot is down because it's crashed rather than because the "new version" is finicky; have you tried speaking to the bot operators? Andrew Gray (talk) 19:02, 5 October 2013 (UTC)

I was once a programmer. The last thing I want to do is to talk to the operators, who (I assume), are doing their best to get it back up and running. I appreciate the bot has "crashed."

Curious why a) there isn't a prior version available that didn't crash, even though it "didn't work as well". Again, I don't really need to know the answer. But more importantly.

b) why there isn't a spokesperson who can interface (one point of contact) with the operators and give us a daily update. There is no active editor with a lengthy watchlist who isn't affected by this. Student7 (talk) 18:39, 6 October 2013 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Categories

• It would be useful if:-
  1. Category pages could be moved; such a move would leave a redirect behind like any other move.
  2. A category page could be a redirect to another category page.
  3. If Category:A is a redirect to Category:B , putting [[Category:A]] in a page (say C) would have the effect of putting page C in category B.

  Anthony Appleyard (talk) 07:31, 10 October 2013 (UTC)

It would require significant MediaWiki changes. Wikipedia:Redirect#Category redirects has a link to bugzilla:3311 - Automatic category redirects. PrimeHunter (talk) 23:10, 10 October 2013 (UTC)

Hover over to display disturbing images

I just read the article on anencephaly as it was mentioned in a news item I was reading. The article itself is well written but I found the first two images to be unusually disturbing. What I would like to propose is that some images, these being a good example, are pixellated and only displayed in full when the user hovers over them (similar to how spoiler warnings are often hidden for plot lines). I would have hovered over the images without a doubt but probably not until I'd read the first few lines of the article which would have prepared me for what I was about to see (a baby with half it's head missing).

I'd like to make it abundantly clear that I don't want to censor the images or in any way, shape or form remove them from the article. I completely agree with the reasoning given in both the "Content warnings" and "Censor offensive images" perennial proposals. I feel this proposal offers a middle ground where a person can choose very quickly and easily whether to view an image. — Preceding unsigned comment added by Wobblycogs (talk • contribs) 13:28, 10 October 2013‎ UTC

That will bring the eternal problem of deciding which images should be affected by the measure, and which shouldn't. A better approach IMHO is to move such images way down and far away from the lede, when editorial discretion suggests it as sensible. This often has been proven an agreeable measure in several articles with the same problem. Diego (talk) 13:37, 10 October 2013 (UTC)

There is meta:Image filter referendum/en. Note sure what came of it. —  HELLKNOWZ  ▎TALK 14:03, 10 October 2013 (UTC)

If editor discretion is enough to deliberately move an image down the page then surely it's enough to have it initially be obscured? The end result is effectively the same. I agree there is a chance of an edit war over whether a small number of images should be obscured but that seems like a weak argument for doing nothing. The image filter proposal feels like a sledge hammer to crack a nut solution and it looks like it went nowhere. — Preceding unsigned comment added by Wobblycogs (talk • contribs) 14:20, 10 October 2013 UTC

It would be possible to write an opt in script, such that if your logged in, certain images would be blocked/obscured. But if you want the default state to be such, it is going to be a major uphill battle. Obscuring the images based on our dislike of, or lack of comfort with the contents is censorship, no way around that. There wouldn't be a conflict over certain images, but over all of them. How is this any different from obscuring an image based on its sexual content, or that it may offend certain religious groups? Monty₈₄₅ 14:28, 10 October 2013 (UTC)

This has the same "who decides what's disturbing?" problem that causes WP:PEREN#Censor offensive images to be rejected. Some people find naked humans disturbing, or homosexuals, or pictures of people that seem to be staring at them, or depictions of certain religious figures, or women showing basically anything except their eyes, or spiders.

But if you want to use a script that will hide almost all potentially-disturbing images (well, unless you find disturbing), see User:Anomie/hide-images. Anomie⚔ 21:56, 10 October 2013 (UTC)

The problem with the consensus argument against implementing something like this is simply that the images on this site are already censored to some extent. Society deems images depicting certain things to be illegal and I'd bet my bottom dollar example of those images won't appear under the appropriate topics and would be removed if they did. Is there a consensuses that those images should be banned by law, certainly not a majority decision was enough. Perhaps a better approach would be to tag images in some way which describes their content and how disturbing the inserter / editor feels they are. The solution doesn't have to be bullet proof just better than the current situation. — Preceding unsigned comment added by Wobblycogs (talk • contribs) 23:03, 10 October 2013 (UTC)

Not all disturbing images are worth doing that to. The baby wasn't dead from having only half a head because the head formed that way naturally. Making that exact image not show unless the mouse goes over it trains future people with a similar condition to elephant man to be very self conscious and not feel comfortable going out into public. Blackbombchu (talk) 21:36, 5 December 2013 (UTC)

No messages have been posted for this user yet...

When you visit a nonexistent page, you're typically given the option of searching for pages with similar names. For example, go to bgorbdoubdohtdubtohtdbhotudbhutd (and remove the &action=edit from the URL) and one of the links goes to Special:Search/Bgorbdoubdohtdubtohtdbhotudbhutd, and Category:nugorduh has a link to Special:Search/Category:Nugorduh. However, this isn't the case for usertalkspace pages. For example, go to User talk:Nyttend Backup; you're told that the user doesn't exist, but you don't have a search button, so you don't have a one-click method of finding your way to User talk:Nyttend backup, which does exist. What if we added such a link? This may require an edit to MediaWiki:Newarticletext, or perhaps to MediaWiki:Noarticletext via {{No article text}}, or maybe to some other page; part of the reason that I'm requesting it here instead of doing the change myself is that I'm not sure which page needs to be edited. Nyttend (talk) 22:35, 10 October 2013 (UTC)

Here is a handy way to see the interface messages used on a given page; in this case, the relevant template is {{No article text}}. Theopolisme (talk) 02:53, 11 October 2013 (UTC)

While the language link actually refers to MediaWiki:noarticletext, that page apparently transcludes Template:No article text, FYI. A little confusing. That language URL is a useful thing to know, thanks Theo. I just created {{sit}} to easily make those links: User talk:Nyttend Backup. equazcion� 03:37, 11 Oct 2013 (UTC)

There is also a gadget under Advanced: "Add a toolbox link to display the current page with MediaWiki message names replacing their text" PrimeHunter (talk) 09:57, 11 October 2013 (UTC)

Monitoring backlog categories

A good idea of User:TheJJJunk: He monitors certain backlog categories using {{User:TheJJJunk/Backlog}}, a template he made:

Backlog status ()

Category	Current status
Pages with missing references list	Not done
Persondata templates without name parameter	Done
Articles with incorrect citation syntax	Not done
Pages with URL errors	Done

which determines if the category is empty or not. He also uses ARA, a script that he developed, to help fix citation errors. --Frze ^{> talk} 17:56, 11 October 2013 (UTC)

Proposal to delete ~300 language shortcut templates

See Wikipedia:Templates_for_discussion/Log/2013_October_12#All_language_icon_child_templates. Someone not using his real name (talk) 19:58, 12 October 2013 (UTC)

Hover over Bulletpoint shows Ordinal Number

Did a quick search and couldn't find anything like this suggested before. I think it would benefit all of Wikipedia if, while hovering your mouse over a bulletpoint in a list, it would display the number of the item on the list. Far too often I am left counting how many items are on a bulleted list (for a variety of reasons). When it is important, I have to copy and paste the list into Excel, and even then the numbering can be imperfect. I strongly believe that this would be a non-intrusive way to provide more information for the UI. Numbers would be shown only when the mouse hovers over the bulletpoint and would revert back to the bulletpoint when the mouse pointer is moved. The coding for this would be relatively simple to implement, in comparison so some of the other suggestions I've seen here. Ideas are welcomed. Thanks. 210.104.119.203 (talk) 07:16, 14 October 2013 (UTC)

• You could always create an account and use my script which will give you a link at the top of many pages with bulleted lists that will allow you to toggle them to numbered lists. Technical 13 (talk) 13:39, 14 October 2013 (UTC)

English settings

We add a feature that allows certain words such color, analyze, math into "colour", "analyse", and "maths" in the general prose of the article when switched to "British English" to separate from "American English". but in order to do this, we might have to stick to just one English to be the default and have a bot fix these issues.

I know what you thinking, there are some names out there that use British English in them such as the artist "City and Colour" in which we just use a tag similar to the nowiki one we already use. I think this is a good idea and will finally put an ease to certain irrational edit wars.Lucia Black (talk) 20:34, 9 October 2013 (UTC)

This is a perennial proposal, iirc, and is generally shot down due to a combination of technical difficulty and implausibility of achieving consensus on which base to use. --erachima talk 20:37, 9 October 2013 (UTC)

That's a shame....i really think it could work if we could gain consensus on it. to me i don't think it's a difficult issue. It just means adding more "notices" and using a bot to have these fixes.

For example: If we used American English as the default. When a British person (or someone from a region that uses British English) a notice on the top of the edit section would show "The default of the prose is American English, it is preferred to use American English vocabulary. If currently not possible, you may choose to write in British English and a bot will fix it."

it's all a matter of choosing a default language. i highly doubt its split 50/50. the majority of the articles are already written in American English anyways.Lucia Black (talk) 20:43, 9 October 2013 (UTC)

At a more philosophical level, forcing everyone to see the mix of American/British/Indian/etc. English across Wikipedia forcibly reminds us that the rest of the world exists. Isn't Wikipedia supposed to expose us all to things we didn't know before? Chris857 (talk) 21:49, 9 October 2013 (UTC)

I know this is not the serious end of the discussion, but I agree with that view. IMHO getting people to understand that the world is a big place full of other people who might do things differently is a very valuable educational service provided by WP:ENGVAR. Johnuniq (talk) 00:32, 10 October 2013 (UTC)

I rather not see things so abstract and to be honest, it's so abstract i find it difficult to take seriously. Wikipedia is just an encyclopedia, and there have been countless minor edit wars over this thing. Having a language setting, won't affect getting to know the world. Can we see this more objectively please?

I really don't like it when something is shot down for what their own personal ideals are in wikipedia.Lucia Black (talk) 00:45, 10 October 2013 (UTC)

Hey Lucia. I think this really is a non-starter for a whole bunch of reasons. Let's just start with a technical problem. There are massive numbers of quotes on Wikipedia. We cannot have any of the language in quotes display differently for different people depending on settings. Source integrity must be maintained absolutely. I cannot even imagine a way to make this affect text only outside of quotes and not affect text inside quotes (without a Turing machine). For that reason alone this is impossible.

Another technical problem is grammar. We cannot have all articles default to one version of English but then inconsistently leave out grammar. But no current computer program (now we're back to Turing) is anywhere near smart enough to fix all the nooks and crannies of grammar differences, like "fixing": "he decided he might do" or "she was going into hospital" to an American equivalent, and having clear British grammar butting up against American spellings and vice versa is odious. This is, of course, barely touching on the larger problem that the issue is not so simple as British versus American English, but rather British versus American versus Australian versus Canadian...

The change to text also has a possible copyright implication: Our content is copyrighted to our users and I don't think it's kosher to have it display in a different way than written. Much more perniciously, anyone quoting our content outside of Wikipedia might or might not take the text as actually written, depending on their settings, which would also result in variable quotes for the same original content — person A posts somewhere what they are seeing, and person B quotes the same block of content but their "version" is not the same. What a mess.

Anyway, were this to start gaining traction (which I cannot foresee – not even a little bit) you think the fight over ENGVAR issues is bad, wait until you see the fight over trying to make one form of English be the default for all our content. The point above by Chris is also well taken, but I would extend the concept: It is unencyclopedic for an article on Winston Churchill to use American spelling and grammar and it unencylopedic for an article on Franklin Roosevelt to use British spelling and grammar.--Fuhghettaboutit (talk) 02:53, 10 October 2013 (UTC)

The "technical issue" is something that can be turned around quite easily. You have to see different ways of programming to make it work. if the nowiki tag makes it so that []{}<> be visible in prose (which is something i clearly covered for article names such as "City and Colour"), than we can still implement a "language setting" without worrying of affecting titles and quotes that use the opposite language. we just have to create someway to allow it and i'm sure we can make a tag or implement one on the quote template so that we don't have to worry. And the grammar isn't a strong issue. the setting is only to change specific words so that editors don't edit war over color/colour generalise/generalize etc.

Yes, there's a lot more things to do just to make such a simple idea work. but its manageable. i really don't see the significance of Australian/Canadian English. It has always been edit warred over the British and American English. I'm sure Canadian/Australian know they are the minority. But here in Kaneva seems to show another. Rather than finding these walls and stopping, we should find all these walls and go around them.Lucia Black (talk) 03:50, 10 October 2013 (UTC)

Having dealt with WP:CONTEXTBOT before, I can tell you that this is not currently technically feasible (for starters, the issues Fuhghettaboutit mentions). While a lot of it sounds fine on paper, it doesn't work when you get down into implementation. Errors are through the roof and there is no way a bot like this would pass a trial. —  HELLKNOWZ  ▎TALK 09:48, 10 October 2013 (UTC)

i think its all on how you look at it. for a language setting? theres multiple ways to make it work.Lucia Black (talk) 00:41, 16 October 2013 (UTC)

I fail to see the value of forcing the user of a particular variety of English as the default. It would interfere with the ability of British editors to edit articles about Great Britain, or South African editors to edit articles about South Africa. Can someone please provide an advantage? Also, having a bot change versions of English may be dangerous. For instance, in an article about Winston Churchill, in British English, a bot would not recognize that a quote by Franklin Roosevelt about Winston Churchill should be in American English. Robert McClenon (talk) 01:27, 16 October 2013 (UTC)

• Support Changing the settings should permanently change which version of English Wikipedia is being used on ones own computer until it's changed back. There's no need to have a default setting. Each version of English should be able to be gotton just as easily as any other with the settings option. I think having the Wikipedia search engine automatically make words with one spelling in one version have another spelling in another version is doable. Blackbombchu (talk) 21:47, 5 December 2013 (UTC)

Idea for today's featured article

Searching through the guides etc. I can't find where to make a nomination for today's featured article, so I'm making my suggestion here, hoping that people will see it.

http://en.wikipedia.org/wiki/Great_Lakes_Storm_of_1913 - This is a well-written article about an event that happened 100 years ago on November 9th.. 22:43, 15 October 2013 (UTC)

See Wikipedia:Today's featured article/requests. There are already two requests for November 9, but perhaps it would be acceptable for the storm article to feature a day earlier or later.-gadfium 23:51, 15 October 2013 (UTC)

• I second gadfium's advice, however, Talk:Great Lakes Storm of 1913 shows that the article was "today's featured article" on February 27, 2005, and the current rules state that once run, and article cannot run again as TFA except in extraordinary circumstances (for example, Transit of Venus ran on the day of the transits in 2004 and 2012, but the previous and next are in 1882 and 2117). That said, I don't see that Great Lakes Storm of 1913 has ever been in the "On This Day" slot, and this could be a good item. You may want to suggest it at Wikipedia talk:Selected anniversaries/November 9 (or maybe Wikipedia talk:Selected anniversaries for more visiblity). Chris857 (talk) 00:17, 16 October 2013 (UTC)

Questioning the practice of tagging all free Wikipedia images for copying to Commons

There's apparently a practice or rule at Wikipedia that any free image hosted here would be better suited to Commons, so all copyright-free images are systematically tagged for copying to Commons (there's currently a backlog of nearly 400,000 of those tagged images). However, I think Commons is already overloaded with useless clutter that makes it difficult to find quality images. I'd submit that tagging for copying to Commons should require at least one human to judge the image as having some potential use for the general public before it's tagged thusly. There should be no discussion. If just one single human thinks the image could be of some use to someone somewhere beyond Wikipedia, it gets copied. Otherwise it does not.

The specific examples that brought me to this suggestion: I upload screenshots with some degree of frequency for use at my userscript description/documentation pages (see them here). As a personal rule I upload them to Wikipedia and not to Commons, because in the totality of the universe I cannot imagine these images being of any use to any man, machine, or as-yet discovered extraterrestrial species for the foreseeable life of our solar system beyond their current singular use at Wikipedia. Yet they still get tagged for copying to Commons. equazcion� 10:24, 15 Oct 2013 (UTC)

• I thought automated processes would only tag files used in articles specifically because of the issue you describe and there would be at least some manual review for everything else. I cannot see how every free image on earth needs to be on Commons. If this isn't the case or isn't enforced, then I support doing so. —  HELLKNOWZ  ▎TALK 10:29, 15 October 2013 (UTC)
• People moving files to Commons should confirm that the files are suitable for Commons before moving them there. Therefore, User:Fbot, User:Svenbot and User:ContinuityBot do not need to do this. --Stefan2 (talk) 10:48, 15 October 2013 (UTC)
  • So are you saying that the tagging is systematic, but a human is intended to make the call afterwards, remove the tag if the image is unsuitable for Commons, and the image will not get tagged again? If so, the wording in the tag doesn't seem to make this clear. It just says the image should be copied over. equazcion� 11:03, 15 Oct 2013 (UTC)
  • I just realized my images were tagged like this: {{Copy to Commons|human=Sfan00 IMG}}. If my proposal is actually supposed to already be the practice, perhaps User:Sfan00 IMG is just not aware of that. equazcion� 11:08, 15 Oct 2013 (UTC)
    • I personally think that all free images hosted on WP should be automatically copied on Commons -then it's up to Commons to decide what to do with them. Given your criteria above ("If just one single human thinks the image could be of some use to someone somewhere beyond Wikipedia, it gets copied."), and given that I am that one single human for every conceivable image, I suppose we can start requesting the bot? --cyclopia^speak! 11:37, 15 October 2013 (UTC)
      • If you honestly thought that every single conceivable free image is of use beyond Wikipedia then yes, but that's not what you're saying; you merely think Commons should be making that call instead of us, and you want to copy all our free images there for that reason. Which I'd have to disagree with. equazcion� 11:39, 15 Oct 2013 (UTC)
        • I kind of personally think so, in the meaning that I find it arbitrary and arrogant that we decide that no one can have a use for a given image. So yes, I think all of them can be useful, in ways that we cannot actually fathom now perhaps, but that we cannot exclude. Second, I also think that the correct project to host free media and decide about them is Commons, not us. We deal with the 'pedia, they deal with the media. --cyclopia^speak! 11:47, 15 October 2013 (UTC)
          • There are two ways to tag a file to be moved to Commons: as a human or as a bot. Bots tag all files which do not have templates suggesting that they are unsuitable for Commons. For example, if a file is marked as unfree, then it is almost always not suitable for Commons, as Commons can't accept unfree files. If you wish to move a bot-tagged file to Commons, you should first check that the file is suitable for Commons. For example, a file might have been tagged as free when it is in fact unfree. In the same way, files tagged as unfree may in fact be free. When a bot guesses that a file is suitable for Commons, it ends up in a tracking category in which humans interested in moving files to Commons can find suitable candidates to transfer.

Some humans also tag files as suitable for Commons. If a human tags a file as suitable for Commons, the human normally checks that there are no outstanding copyright issues. However, if you move a human-tagged file to Commons, it is still a good idea to check that nothing is wrong as humans may make errors. I don't tag files as suitable for Commons myself as I think that this is a waste of time. Tagging two files takes about as much time as moving one file. It is better to leave the tagging to the bots.

Moving everything over to Commons without further checks sounds like a bad idea. Many files are copyright violations or misstagged or have other kinds of problems, and it is better to handle those issues here first instead of exporting our problems to Commons. Also, there is little point in moving unused files which are of no use for either Wikipedia or Commons. Those are typically just deleted instead. --Stefan2 (talk) 13:30, 15 October 2013 (UTC)

• • • • I have a problem with "then it's up to Commons to decide what to do with them". I've seen enough cases where Commons has decided that an image with no ties to Europe must be deleted based on European concerns, or where Commons admins take an approach of mass tagging images for deletion and assuming that some other admin reviewing it later will sort it out, that I don't trust them to do it well. Anomie⚔ 11:49, 15 October 2013 (UTC)
• My understanding was that they do get reviewed by a human when they are moved. The tag is simply for images that are eligible for transfer to commons. I would support a tag parameter decline=username where a user could indicate that although the image may be eligible, it isn't appropriate for transfer to commons, and it gets moved from the {{Copy to Wikimedia Commons}} category to the {{Do not move to Commons}} category. VanIsaac_{WS Vex}^contribs 21:29, 15 October 2013 (UTC)

How to make more Wikipedia edits really good

Wikipedia should have a link that randomly generates an online Wikipedia test that has a large number of questions each of which discusses an edit to an article and asks whether or not that change is a change worth making to the article and only people who pass the test should have the power to approve or deny pending changes with their account. It should also have a page teaching people the information for the test. For each change to an article, Wikipedia should keep of record of how the article went before the change for a few days in case it was a horrible edit that lost a bunch of important information without the person who edited it realizing it. There should also be another type of test that randomly picks a proposed article from the requested article page and asks which section and subsection it should go into and the requested article page should have an option of viewing only requested articles that were requested by somebody who passed that test after they passed it. The test should give marks according to where the requested article in the test question belongs, not where it actually was. That test should also require all other internet windows to be closed to let you begin the test whether the other windows are google chrome or internet explorer and should give you a zero if you open other internet windows during the test so that you can't look at the requested article page to gain an advantage in the test. Wikipedia should also be changed in such a way that pressing escape a second time unpauses animation. Wikipedia should also get rid of the </math> tags for square roots. I don't see why it shouldn't be possible. Putting a square root symbol over an expression is just a type of formatting no different than a superscript. Having square roots not be images also enables copying and pasting into microsoft word. Blackbombchu (talk) 01:33, 16 October 2013 (UTC)

Just FYI, "For each change to an article, Wikipedia should keep of record of how the article went before the change for a few days in case it was a horrible edit that lost a bunch of important information without the person who edited it realizing it." - We already do this, see page histories (click the view history button next to the edit button). Also I'm fairly sure some of your suggestions aren't even technically possible without some invasive applications (i.e. the other browsers being close) and, finally, you shouldn't really be copying straight from Wikipedia into MS Word for your homework. Cabe6403^{(Talk•Sign)} 13:30, 16 October 2013 (UTC)

Technically absurd. Like, all (hah) this requires is for someone to write some code that totally preempts any browser opened on a given computer, as well as any other computers nearby that the user might be peeking at. The user's interest is admirable, but perhaps someone could take him/her aside for mentoring. ~ J. Johnson (JJ) (talk) 19:34, 16 October 2013 (UTC)

To be honest, I wasn't sure this was serious. In any case, oppose as a proposal. This belongs in Idea Lab at best. This is technically impossible, against Wikipedia's free-to-edit spirit, easily cheatable, highly mis-representative of what different types of edits can be, and presents a whole load of other problems. —  HELLKNOWZ  ▎TALK 19:38, 16 October 2013 (UTC)

User:Casliber/Stub contest

Right, am thinking of running a de-stubbing contest (in the vein of the Core Contest). Discuss on talk page. Cheers, Cas Liber (talk · contribs) 13:32, 16 October 2013 (UTC)

Multi language link to same article

I recognized that you can create only one link per article to another one in a different language. I don't see the sense in it as long as there isn't the same amount of articles in every language. There are many situations where you would prefer some more of those links and not less. Especially if it is possible without problem.--Sagehorn (talk) 21:09, 16 October 2013 (UTC)

No reaction? I think it's important --Sagehorn (talk) 22:26, 29 October 2013 (UTC)

Move "Did you know" nomination discussions to an appropriate namespace for discussions.

The vast majority of templates and subtemplates in Wikipedia are designed for transclusion into articles (or into other templates), for which erroneous links in the template (such as disambiguation links) are a serious problem, because they will introduce the error into all of the articles into which the template transcludes. For this reason, the disambiguation project generates regular reports of these errors for disambiguators to go after.

I recently attempted to fix such a disambiguation link at Template:Did you know nominations/Margaret Powell. The repair was reverted by User:Yngvadottir on the grounds that the page was a closed discussion (although the page is not in "Talk" space). At the time that the link, Upstairs, Downstairs, was added to the template, it was an unambiguous link to the article on the 1971 TV series. However, the page on the series Downstairs&action=history was recently moved to "Upstairs, Downstairs (1971 TV series)", and the base page title was changed into a redirect to the disambiguation page, Upstairs Downstairs (this change was done by me, as the closing administrator determining consensus in a move discussion on the topic). Therefore, the page as it stands (1) misrepresents the original discussion, (2) will misdirect readers to the disambiguation page, and not to the article represented in the discussion, and (3) will continue to show up as an error needing to be fixed.

Although I was initially irritated that my repair of this particular disambiguation link was reverted, restoring the incorrect link, I am actually more disturbed at the idea that a system has been set up to use subtemplates (normally used for transclusion into complex templates for further transclusion into articles) as talk spaces. In the discussion that I initiated following this reversion, User:Yngvadottir explained that "this template is not for readers and would be hard for a reader to reach; it's a record of a behind the scenes process", and that "User:Rjanag created the nomination template system so that nominations could be watchlisted - this is not a class of templates that are transcluded in article space". Based on these explanations, these pages are in the wrong space altogether, and should be moved to "Template talk" space, which is the appropriate namespace for "a record of a behind the scenes process", and which is just as easily watchlisted.

For the record, there are about 17,000 such discussions in template space. Of these, only about 80 have existing talk pages, which could easily be addressed if all of these discussions were moved to the space normally used for discussions. I therefore propose that all "Template:Did you know nominations" discussions be moved by bot to their "Template talk:Did you know nominations" pages, in order to avoid the appearance of errors in template space needing to be fixed. Cheers! bd2412 T 15:23, 13 October 2013 (UTC)

Please move this discussion to WT:DYK, as it is not a general community issue, and this discussion is already happening there so it's pointless to make it sprawl over multiple noticeboards. I will respond there. rʨanaɢ (talk) 15:40, 13 October 2013 (UTC)

The placement of a large swath of pages in the wrong namespace is definitely of concern to the general community, and will not be subject to the heckler's veto. One of the great problems facing the community is the development of insular subcultures which set up their own rules that are at odds with the over-riding mission of building an encyclopedia. Sometimes it is necessary, for the good of the whole, for such insular groups to be woken up to their larger responsibilities to the community. bd2412 T 16:01, 13 October 2013 (UTC)

I think Rjanag meant Wikipedia talk:Disambiguation pages with links#Help needed with Template:Did you know nominations/Margaret Powell - no discussion has been opened at Wikipedia talk:Did you know. I am a bit surprised that you would refer to the heckler's veto (although glad to be made acquainted with yet another essay I hadn't seen before). I have merely endeavoured to point out the inappropriateness of referring to this as a reader problem. This template is not transcluded in article space. I regard this as a logical response to your argument, my apologies if it appears, by virtue of disagreeing with your premise, to be heckling. For the record, oppose as unnecessary bureaucratic enforcement of consistency that has no advantage, is rendered unnecessary by common sense, and as has been pointed out in the existing discussion, has at least one disadvantage. Yngvadottir (talk) 16:11, 13 October 2013 (UTC)

Moving a discussion out of the view of the general community, and into an insular project that does not reflect the priorities of the community, in an effort to avoid allowing the community to discuss it, is an example of a heckler's veto. I believe that this community should be allowed to discuss an issue of general concern in this general space. bd2412 T 16:16, 13 October 2013 (UTC)

No one said the community can't discuss it. It's not like the page this discussion was already at is password-protected or something; anyone can comment there. As I said in my first message, what I am objecting to is spreading an existing discussion over multiple talk pages. That's drama-mongering and not constructive. If you want to bring the discussion to more people's attention, then post a link to the original discussion, don't copy it onto multiple pages and cause multiple parallel discussions to happen. rʨanaɢ (talk) 16:25, 13 October 2013 (UTC)

This is the original discussion of this topic, which is a proposal to move these discussions to the appropriate space for discussions. It has begun here, and there is no more appropriate place to discuss it. Therefore, let's get to the substance of the discussion: we have thousands of "closed" talk page-type discussions being maintained in template space, which raises flags for those who use template space for templates, or who repair errors in template space. Apparently, these are not intended to be used as templates, nor even intended to be read by anyone, which raises the question of whether there's really any much reason for them to exist at all, so moving these discussions to the space for discussion should be of no concern. I will concede, looking at the examples of XfDs, and RfAs, that it would be just as good to move them all to project space (which would allow the 79 pages with existing talk pages to keep these as they are. bd2412 T 19:20, 13 October 2013 (UTC)

Oppose Seems like a very complex work for very little gain. Let's better be pragmatic: a "talk page" and its associated rules is not a page located at "talk" namespace, but a page where discussions are going on. In most cases it's in talk namespace, but if it's not... if it's not, a rose by any name still smells like a rose --Cambalachero (talk) 20:54, 15 October 2013 (UTC)

As an alternative, suppose we could move all of these to Wikipedia space, to parallel the treatment of XfD discussions? The work could be done by a bot in a short time; the gain would be having things in appropriate spaces. If these discussions were in article space, there would be no question, and the use of template space is more like article space than like project space. bd2412 T 21:16, 15 October 2013 (UTC)

Comment I have left a note in Wikipedia talk:Did you know about this discussion, so that more users involved with that process take part in this. --Cambalachero (talk) 21:31, 15 October 2013 (UTC)

I am curious as to how this system got set up in the first place. There is one previous discussion that has been pointed out which suggests that the current situation is the result of "Wikipedia-by-committee work" (i.e. chickens running around with their heads cut off). There also seems to me to be a solid majority of editors in that discussion (Alan Liefting, Casliber, Gatoclass, and Mandarax) who would have preferred to move these to Wikipedia space, although nothing came of it. bd2412 T 21:35, 15 October 2013 (UTC)

It is in the wrong place. If a magic wand could sort it all out without any problems then that would be a good thing. Whether a bot could be seen as said magic wand I'm not sure. As noted above it could be a lot of work for little gain, but if it's an easy process that people are willing to work on then I say go for it. violet/riga _^[talk] 22:33, 15 October 2013 (UTC)

Part of the issue, beyond what you've said here, is the effect of how it developed. Initially, if I remember rightly, people simply added longer-than-stub new articles to the template. At some point, someone probably abused it enough that it was decided to have a page where people decided what to add, so the talk page became used for that. This makes sense: when we're changing a template, we should use its talk page to discuss how we're changing it. Eventually, the talk page became so big that people decided to have subpages for each nomination — but for a reason I don't understand, they're in Template: namespace instead of Template talk: namespace, so IPs can't create the pages. Now I'm concerned that such a mass movement of pages might cause unforeseen disruption. How can we be so sure that moving them will cause virtually no problems? I know of no comparable mass-movement of subpages since the time when VFD got renamed to AFD, and that consisted only of movement from "Wikipedia:Votes for Deletion/Subpagename" to "Wikipedia:Articles for Deletion/Subpagename". No namespace changes, nothing complicated such as existing titles at the new titles, and nobody has used the old titles since then. This being a substantially different proposal, I'm really leery and suspect that bigger problems might happen for what's seemingly a minor issue — on top of the fact that this would represent a profound change to something that we've been doing for the majority of our history as a project. Let's hold off unless BD2412 or someone else can produce a careful study showing that this won't cause substantial problems. Nyttend (talk) 00:18, 16 October 2013 (UTC)

There are three issues at play here: past discussions, current discussions, and future discusssions. First, as I noted above, there are about 17,000 of these discussions currently in template space. The vast majority of these are closed discussions, which are inactive, and (so far as I can find) are not transcluded anywhere. These could be moved wholesale by a bot without disruption to any ongoing activity, and the same bot could change all of the links so long as all links to these pages are fixed, and the template-space pages can be deleted without any loss of links or information. 80 of these pages also have talk pages; a bot moving the templates to Wikipedia space would also capture the talk pages. With respect to Template talk:Did you know, which holds the current conversations, there are about 900 discussions listed. These could also be moved by bot, which would also require that the current transclusions into Template talk:Did you know be changed by having "Wikipedia" prepended to them or substituted for "Template" (the transclusions themselves are inconsistent in their inclusion of the prefix). With respect to future discussions, the structure of Template talk:Did you know is virtually identical to other XfD pages. I see no reason that discussions could not begin to be made on project-space subpages instead of template-space subpages immediately, since the target page doesn't know what is transcluding into it. bd2412 T 01:21, 16 October 2013 (UTC)

Oppose, especially the "immediate" notion. There are a number of automated and semi-automated processes used by DYK; to do anything immediately without first determining what might be affected and what the ramifications are is precipitous at best. I'm also not convinced this is necessary or even advisable. BlueMoonset (talk) 04:27, 16 October 2013 (UTC)

How should we go about testing what effects such a change will have? bd2412 T 21:33, 16 October 2013 (UTC)

Why not wait to worry about that? This proposal doesn't seem to be going anywhere. If it gains traction, that's the time to start looking at the various processes involved and how the change—once it's determined what the new namespace should be—might be tested. BlueMoonset (talk) 03:52, 17 October 2013 (UTC)

This seems to create a catch-22 - we can't correct the namespace because support for changing it requires that we first look into how to do it; but we can't even look into how we would change it because doing so requires that we first get support to correct the namespace. bd2412 T 12:27, 17 October 2013 (UTC)

No, it really doesn't. You're skipping the "how would this work" step—the new design for the DYK nomination and review process using something other than the Template namespace—and going straight to the testing plan. There's nothing to prevent you from looking at how things work—the various templates, how they're generated, etc.—and to figure out what you think might be an appropriate alternative, but to start testing or changing namespaces prior to approval, which is where you seemed to be going, is a non-starter. BlueMoonset (talk) 01:20, 18 October 2013 (UTC)

Answers to some questions:

1. "Can all pages be easily moved by a bot?" No. The DYK nomination system has a lot of dependencies--it's a whole bunch of templates that come together like a house of cards. Moving stuff around breaks links and causes things not to work. I'm not saying it can't be done, I'm just saying it is not simply a matter of moving a few pages. A lot of template code will have to be updated if this is done. Not just the transclusions on T:TDYK; there are forms and things like that that have this namespace hard-coded into some links. And as I have already said (I don't remember if it was here, or at the other copy of this discussion that bd2412 opened), I am not the person who is going to take responsibility for making those changes.
   • There is no "other copy of this discussion". There is a separate discussion - unrelated to the question of changing namespaces - on whether disambiguation links created by page moves can be fixed in "closed" discussions, where the link in the discussion was originally to the correct article. Please review the other discussion more carefully. bd2412 T 12:20, 17 October 2013 (UTC)
2. "Why was the system set up this way in the first place?" I think I already explained this somewhere (and thank you Nyttend for also giving some history), but here it is again. All nominations used to be posted to T:TDYK: there was one massive nomination page, and when someone wanted to nominate an article they edited that page, and when a nomination was finished (rejected, or passed to the main page) it was edited off of the page. People didn't like that because it meant that if you want to find the record of a past discussion you have to trawl through a long page history. So, with help from a few other DYK regulars, I set up the current system, modeled off of AfD/MfD, where each nomination has its own subpage and that subpage is transcluded onto T:TDYK. Originally the nomination subpages were themselves subpages of T:TDYK (just to be transparent and to have an obvious link with how things used to work), but then there was a complaint that, since these subpages were in the Template talk namespace, they didn't have associated talk pages (they were occupying the associated talk pages). So everything got moved to the Template namespace to resolve that issue. Anyway, this system was absolutely not set up by "chickens running around with their heads cut off". Every change that was made was in response to some demand from the community, and was discussed and tested at length. Some features were also made and then thrown out after community feedback suggested that they weren't wanted.

rʨanaɢ (talk) 09:15, 17 October 2013 (UTC)

• If your system was "modeled off of AfD/MfD", then why didn't you set it up in the same namespace as AfD/MfD? I participated in the creation MfD; I'm not one of the techie types, but it really wasn't difficult to set up exactly this system in that namespace. bd2412 T 12:22, 17 October 2013 (UTC)
  • Why are you asking again "why was the system set up the way it was and not some other way"? That question was just answered, one comment above this. rʨanaɢ (talk) 23:35, 17 October 2013 (UTC)
    • I am asking about the reasoning behind a very specific element of your explanation. You said you modeled this after AfD/MfD. I want to know why you didn't use the same namespace fr the discussions as AfD and MfD. After all, WP:TfD involves discussion relating to templates, but is not therefore in template space. bd2412 T 01:04, 18 October 2013 (UTC)
      • And the answer is already in what I wrote above. It may not be the answer you like, but it's there. Read my message more closely.
      • By the way, "modeled after AfD/MfD" doesn't mean "exactly the same". It means we imitated some but not all of it. If you actually read my message, you will see that I already explained what the rationales were at the time for putting things in the namespace they were in. rʨanaɢ (talk) 07:39, 18 October 2013 (UTC)
        • I see. In other words the basic namespace error was made when "everything got moved to the Template namespace to resolve that issue" rather than "everything got moved to the Wikipedia: namespace to resolve that issue". I think that it is inevitable that somewhere down the road, this will end up being moved to project space (it was pointed out in the Visual Editor RfC that some people in the WMF seem to be contemplating [getting rid of the template space altogether); it's a matter of "when". bd2412 T 12:51, 18 October 2013 (UTC)

Pending changes

I think all Wikipedia articles should have pending changes. I sometimes see an article with a mistake that looks like it's worth editing but I can never be absolutely sure that I'm not wrong instead. Once, David Eppstein edited the proof of Bertrand's postulate in such a way it's very unclear whether or not that change should have been made and that change seems to have made the proof less complete than it was before. I don't edit an article even when I see I mistake in it because I want my own changes to be pending changes and I'm afraid that they won't be. If the article Proof of Bertrand's postulate had only pending changes with people constantly editing the proof all the time, then the proof would keep on improving all the time and get clearer and clearer to most people without somebody ever mistakenly adapting the proof to be clearer to themself and less clear to almost everybody else without the editor realizing it. To make edits even better, my earlier proposal about only people who pass an online Wikipedia test having the power to approve or deny pending changes should be done too. Having all articles have pending changes might greatly improve Wikipedia. For instance, people would be free to make as large a change to an article as they want including an entire rearrangement of sections, with the same person doing a whole lot of moving information from one section to another and if that change actually makes the article explain its content more clearly, the change should be accepted but chances are, the pending change would only be accepted if it was done by a type of person who would have gotton very high marks in English class. Blackbombchu (talk) 03:31, 17 October 2013 (UTC)

ALL changes are 'pending changes' in Wikipedia; thanks to the undo; rollback, etc. functions. All edits are subject to peer review (especially by those editors having any particular article on their watchlist), and may be reverted. Being reverted is not a bad thing, and reverts should be explained by the editor. That is a learning experience for you. In the meantime, you should probably lurk about a bit more and get a feel for how proposals and discussions get handled here before throwing out ideas that either have already been adopted or that are perpetually being discussed and dismissed as impractical or impossible. Perhaps join a group which can use your particular brand of expertise, whatever that may be. (I'd recommend starting with WikiProject Physics or GOCE based on what you've contributed so far.) In the meantime, if you want to make changes to an article, but don't want to be reverted until you're ready to publish them, use your Sandbox to copy the article to, do your editing thing, and ask for opinions from me, or any of the other thousands of editors you may encounter in your work here, before changing the original article. GenQuest ^{"Talk to Me"} 03:59, 17 October 2013 (UTC)

I thought pending change meant the article doesn't change in the first place until the pending change gets approved, not that the change gets made with a record of the old version of the article kept to change it back if it's a bad change. I think that should be the way pending changes work and before the change gets approved, people should be able to see the pending change by clicking a third link at the top of the article beside the talk link saying pending changes. There should be a pending change link and in the pending change page, all the parts of the article that are different in that page than the article page should have red text. For each pending change in the pending change section, it should be possible to click edit to expand on it and suggest a better pending change thus creating a pending pending change. Each pending change should also have a link at the top of it to view pending pending changes for that pending change. Blackbombchu (talk) 17:59, 17 October 2013 (UTC)

What you are describing was discussed last year, and a system of pending changes was rolled out as a test. It quickly died a quiet death, although there were a few heavily vandalized articles on which the system remained longer, even into the beginning of this year, if memory serves. I think they, too, are now gone. The process added another non-needed step, since we have "Undo". Bad edits don't last long around here, usually; especially on the more popular articles. GenQuest ^{"Talk to Me"} 17:14, 18 October 2013 (UTC)

I think your information is out of date, i.e. it would have been correct had you written it in January or February 2012 but isn't anymore. According to WP:Pending changes#Timeline pending changes was implemented for trial in 2010, disabled in 2011, partially re-enabled in December 2012, and it looks like there's support to re-enable the rest if yet-another-RFC determines the precise criteria for using it. According to Special:StablePages there are currently 722 articles at "level 1" and 8 at "level 2" (despite level 2 not having consensus for general use yet). Anomie⚔ 21:11, 18 October 2013 (UTC)

There were 2 very unclear proofs in the article Mersenne prime that I thought of a way to make much better. They were huge changes so I put them into my sand box instead of editing the article. It's so cumbersome to put them into the sandbox. Another problem with the sandbox is that each person has their own sandbox so different people's edits of the same article will go into a different sandbox making it harder to combine different people's edits of an article together. A good alternative to all Wikipedia articles having pending changes is having a 4th button at the at the bottom of the edit box between the Save Page button and the Show preview button saying Pending changes. Clicking Pending changes after clicking edit should be similar to clicking Save page except that it makes a change that waits pending approval. I sometimes think of a huge edit to an article and don't make it because I don't trust it not to be a bad edit. Each person should have the right to chose for themself to make their own edit be a pending change. That would make me feel free to make as large an edit as I want that I think there's any chance of being a good edit but instead I feel like in some situations, Wikipedia is worse by not enabling the option of pending changes because people sometimes have a really good huge edit that they don't feel free to make. I want to have the freedom to make a really huge edit and have it either get rejected from it being a bad edit or my edit getting modified by an administrator to for the administrator to make a slightly better version of the edit I made and make the modified version of my edit to the article. Pending changes should also be available to be viewed by the public. To the right of each edit link at the top of a section, there should be another link saying Pending changes and clicking it should give a list of all unresolved pending changes for that section that anyone has ever made. Each account should be able to vote for which pending change is the best one. Blackbombchu (talk) 19:19, 5 December 2013 (UTC)

New REFBot

Thanks - Vielen Dank!

DPL bot and BracketBot are the best inventions of Wikipedia. It's time for a new Bot. We need the

• REFBot

If a user contributes a broken reference name, an incorrect ref formating (or a missing reflist), please inform the user who caused this error. It is so outrageously hard work to correct all these errors afterwards, from someone who is not holding the factual knowledge. For example: it took me a week to work up the backlog of Category:Pages with broken reference names - more than 1500 items, some disregarded more than two years. Search with WikiBlame for first entry of ref, making the changes, inform the users... annoying. Thank you very much.
Please discuss on page WP:VPT#New REFBot --Frze ^{> talk} 12:31, 17 October 2013 (UTC)

English Wikipedia needs intermediate adjudication mechanism

The English Wikipedia needs an intermediate level of adjudication of user conduct issues. There are currently three primary methods of dealing with user conduct. First, users can be blocked by one admin, but that is normally a temporary measure, unless there is consensus that the user is a troll, flamer, vandal, or otherwise not here to build an encyclopedia. This mechanism works reasonably well as a temporary measure, except as seen by certain editors who view admins as collectively power-hungry and corrupt. Second, user conduct issues can be dealt with by so-called community consensus at the noticeboards. This works reasonably well for trolls, flamers, vandals, and other users who are not here to build an encyclopedia. It does not work with respect to persistent POV-pushers, chronically uncivil editors who are known to be "content creators", long-standing enmity between editors, and other persistent problems, because there is typically no consensus. The POV-pushers have entourages. The content creators have entourages. These simmering issues go to the noticeboards once, or more than once, and are closed as no consensus. Community consensus is not really an effective method of enforcement, except for trolls, flamers, and vandals. These long-standing issues either continue to cause dissension, or they go to the ArbCom. Third, there is the ArbCom. It has the advantage that it doesn't rely on consensus, but actually votes. In 2005 to 2007, the ArbCom managed to handle a hundred cases a year. It now handles cases more deliberately, and so does not deal with the hundred or more user conduct issues that require adjudication. Fourth, there are the theoretical mechanisms of Jimbo Wales and the Wikimedia Foundation, which (if I am not mistaken) have not been used in this decade. ArbCom enforcement is not perfect, but is a working system. However, what we need is a mechanism for enforcement that is intermediate between individual admins as blockers (who cannot actually ban) and the ArbCom, since "community consensus" is something of a will-o-the-wisp. I propose that there be a mechanism known as Requests for Adjudication, WP:RFJ, that would go to panels of three administrators who have volunteered to be members of these panels. With 1423 administrators, there may be a few hundred administrators willing to take the job of serving on these panels. The admins to serve on the panels can either volunteer after the case is presented, or can be selected randomly. Having the admins volunteer would be desirable. The admins should be fully uninvolved, defined very strictly. These panels should be expected to act within ten days, because they will rely on the diffs and other evidence already on the record or put on the record by the filers, without the need for a formal evidence-gathering phase. They should have the power to topic bans, interaction bans (many of the persistent issues that cause continuing hard feelings are editors who dislike each other who should be interaction-banned), and site bans for up to three months. (Three months seems long enough for what is intended to be summary justice.) I would propose that the decisions of these three-admin panels should be appealable to the ArbCom only. The idea of appealing them to the community would be just a way of letting the will-o-the-wisps lead the travelers. That is my opinion. I think that the English Wikipedia is large enough that it needs an intermediate level of enforcement. Robert McClenon (talk) 01:45, 7 October 2013 (UTC)

Oppose simply on the two grounds. One this idea that admins are "judges" or "police" or of any type of authority figure. Giving them the option to be on a further "civility" board would only increase this misnomer. Admins are no different than regular editors and if an idea like this needs to be done it needs to be open to ALL editors who wish to join, and not a certain clique. Otherwise no admin would ever get action and every non-admin that went up against an admin would find retribution in the future (which already happens). Two- seems at least part of this is aimed at good editors who are a uncivil, but do what needs to be done, most famously User:AndyTheGrump and I see no reason to target those types of editors (unless the personally piss me off, then those that do that you may ban all you want).Camelbinky (talk) 01:55, 7 October 2013 (UTC)

The admin function is a technical one. There is no reason volunteers at your hypothetical WP:RFJ need be admins, and limiting it to that group would preclude many competent, judicious people. I am not crazy about your solution in general, although I agree in general with the problem statement. VQuakr (talk) 03:15, 8 October 2013 (UTC)

The point that the judges do not need to be administrators is a valid one. Do you have a different idea as to how to solve the problem? Robert McClenon (talk) 01:19, 16 October 2013 (UTC)

• I generally oppose having another authority mechanism here - it's actually not a solution, more a problem; we see users get soured by overzealous or biased enforcement and turn into major problems. What we need is to allow ourselves a mechanism to cold-call demonstrably random recent editors to try to get them to serve as volunteers for a jury, to settle issues before a demonstrably impartial audience made up of all those who edit. Wnt (talk) 19:31, 21 October 2013 (UTC)

The Wikipedia Library: Can recipients of free research accounts receive the first edition of our Books and Bytes Newsletter?

Over 1000 editors have received donated research accounts worth hundreds of dollars each. I'd like to send them all the first edition of our newsletter and then have all future deliveries be opt-in only. The newsletter will be the primary way that we announce new account signups and partnership opportunities.

• Here's the recipients list: User:Ocaasi/TWL_recipients
• Here's what they would receive on their talk page: Wikipedia:The_Wikipedia_Library/Newsletter/October2013/Intro

Thoughts? Ocaasi ^{t | c} 15:46, 20 October 2013 (UTC)

I can't see any reason not to send it out to them. They can always request their names be removed from the mailing list later if they wish. John Carter (talk) 16:07, 20 October 2013 (UTC)

A beta version of the entire Wikipedia to test new proposals

Many good proposals don't get the necessary consensus to get implemented because of fears from minorities that it might not work out well. E.g. a proposal to have a de-Admining procedure were not successful because of strong opposition from Admins. What was clear from that discussion is that no such proposal, however well thought through, will never ever get the necessary consensus. The only way it can be implemented would be for Jimbo to do it using the authority he has over Wikipedia. But Jimbo is very conservative about excercising his authority, so this is not likely to happen anytime soon.

Now, there exists a way out of this problem. One could create a beta version of the entire Wikipedia that starts out as an exact copy but where certain rules are different. The differences and the test period are then decided on the basis of consensus. Suppose e.g. that the de-Admining proposal is put forward as a test proposal for the beta-version. Then you would have far less opposition from Admins to implement this in the beta-version. At the end of the trial period, they will have plenty of opportunity to argue that it didn't work. Many other proposals like e.g. reforming the ArbCom system, changing the way AN/I works etc. that could potentially make big improvements but that currently have zero chance of ever getting seriously considered could be tested out in practice this way.

One then does have to deal with crossover effects; editors will make edits to both Wikipedias in the same way. But that usually won't be a problem. If someone is blocked in the main Wikipedia, he can still dit the beta version until he gets blocked there. What is then important is that any Admin in the beta version should only consider what is going on in that beta version and stick to the rules that apply there.

After the trial period, there will be a few options to consider. One can decide to continue with the trial possibly with some changes, one can make some changes to the main Wikipedia based on the outcome of the trial. If the trial is concluded one can consider other proposals for testing in the beta version. Count Iblis (talk) 17:13, 20 October 2013 (UTC)

Support I am fully in favour of this idea. But why stop at one? Let us have a beta, Gamma, Delta, Epsilon version of Wikipedia. Let there be an Omega edition. This way, rather than having endless content disputes and petty squabbles, people can settle in at the Wikipedia that suits them best. The only thing I would perhaps fear is that one day two rival Wikipedias may go for war - ah, and how many must suffer then in such a deadly conflict? Horatio Snickers (talk) 17:30, 20 October 2013 (UTC)

I have some questions regarding how this would work- take the deadmining process for instance. Those admins most likely to face being de-admined would be less likely to go and work at a beta version where they know the !rules are stricter and there's actually consequences for their actions. Really what needs to happen regarding admin abuse is that editors need to stop allowing admins to overrule in discussions and force the change themselves, create a noticeboard similar to an/I but with non-admins as the moderators and we start taking matters decide that those labeled at that noticeboard as "bad" admins are to be ignored in all their "admin powers" and if they aren't stripped formally of their powers we'll ignore any action that admin takes and reverse any actions that admin makes as far as regular editors can do so; and hopefully sympathetic admins would come to join us and revert any use admin-only powers that "bad" admin makes.Camelbinky (talk) 17:45, 20 October 2013 (UTC)

• Umm... Doesn't this already exist? Technical 13 (talk) 18:45, 20 October 2013 (UTC)

• That's only for testing Wiki software. Count Iblis (talk) 20:09, 20 October 2013 (UTC)

• Yes, a pretend Wikipedia where pretend admins can pretend to run amok, and a pretend ArbCom can pretend to desysop them...that should provide useful guidance for policy here. About the only likely benefit of this proposal is that it will give editors who like to play Moot Wikipedia Court a place to go get it out of their systems. TenOfAllTrades(talk) 19:39, 20 October 2013 (UTC)

• Simulation is a power tool. In fact, the evolution of the brain starting from a simple nervous system that primitive animals had, has probably a lot to do with this. All your brain is really is doing is simulating reality beased on a model of reality (that includes your own body) to evalaute the consequences of various possible actions to select the best action. By your logic dismissing "pretend games" we would still be some primitive Cambrian creature. Count Iblis (talk) 20:19, 20 October 2013 (UTC)

• I don't see how this will work. The current environment of Wikipedia is shaped by personalities, agendas, relationships, goals, etc. mixed in with our policies and guidelines. You're not going to get the same mix that leads to conflict and clashes on a "fake" Wikipedia no one cares about. Content changes won't be the same, the participants won't be the same. --NeilN ^{talk to me} 20:29, 20 October 2013 (UTC)
• Like NeilN, I don't see how this can work. It's like creating a full-scale copy of a city, but then only populating it with a small, self-selected group, but assuming that what works in the copy will also work in reality. By advertising it as a test platform for a potential new process you're mainly going to attract people who strongly want to see the process succeed and people who strongly want to see it fail. And we all know what happens when a group is dominated by extremists. Or if too few people participate, they may simply not interact enough to get any results. For the results to be even theoretically valid, you would need to populate it with a fairly large, random selection of users, which is obviously a non-starter since we can't force users to do things. And then there would still be the question of whether or not they take it seriously, since actions there would presumably have no direct impact on the real Wikipedia in terms of things like content. Why spend time engaging in a content dispute over an article that no one will ever read? Mr.Z-man 23:34, 20 October 2013 (UTC)

• If Google doesn't see the difference between the real and the beta version, articles on both versions will have similar page rankings. That would put pressure on editors editing an article to also edit the beta version. Count Iblis (talk) 01:25, 21 October 2013 (UTC)

• If Google doesn't see the difference, what is the difference? How would that be any different than 2 real Wikipedias? Jackmcbarn (talk) 01:31, 21 October 2013 (UTC)

• Yes, it would be like having 2 real Wikipedias. What matters is that editors will watch the same articles in the beta version as in the standard version. So, the editing will proceed pretty much along the same lines, except that on the beta version you have slightly different rules (e.g. instead of RFA you have a different system that allows every editor in good standing to become an Admin; that "good standing" being judged by objective criteria like blocks the past year, edit count etc.). If, say, after a few years the community starts to like the way disputes are dealt woth on the beta version more, then the original Wikipedia can adopt that system and then the beta version can be used to test out some other proposal. Count Iblis (talk) 01:59, 21 October 2013 (UTC)

It wouldn't be as big, if the idea is to test templates and bots. it would help greatly to do proposals we claimed were impossible, because we have the room to do it without consequence.Lucia Black (talk) 02:11, 21 October 2013 (UTC)

• If Google ranks both the same (which I doubt they would do), then this will create massive amounts of additional work. Are you seriously suggesting that in order to find out whether a particular proposal will work, we ask every user to do almost everything twice for years at a time? That's insane. I sure as hell wouldn't do that. Not every user has infinite amounts of time to spend on Wikipedia. Mr.Z-man 02:31, 21 October 2013 (UTC)

I'm wondering why we are discussing something that is going to cost money and will need the Foundation's blessing and funding. It would need massive support to stand a chance.Dougweller (talk) 19:28, 21 October 2013 (UTC)

• I support devising ways to have the Mediawiki software integrate seamlessly between wikis, so that you can start a "second wiki" that mirrors Wikipedia content, fork one article there according to your personal rules, and allow users to rank whether they prefer to read your article or the other according to their own preferences or the preferences of siteadmins (of yet additional sites) that they trust, seeing both as search possibilities if they choose. In other words: think of how sandboxing a module or a template works. You don't literally have to have a copy of everything the module or template calls; but the software acts like it. Wnt (talk) 19:35, 21 October 2013 (UTC)

• Oppose. T'ain't gonna' happen. Per User:Dougweller and User:Mr.Z-man above. GenQuest ^{"Talk to Me"} 21:24, 21 October 2013 (UTC)

It's probably not gonna happen, but it has potential, so I think it is worth discussing further.--SPhilbrick(Talk) 17:00, 22 October 2013 (UTC)

My thoughts on how Idea Lab and Proposal should be used

As an aside, this remind me of one of my strongly held views I haven't yet expressed. I don't think we use the Idea Lab enough, or appropriately.

I'd like us to adopt a convention that this Proposal page is for fully fleshed out proposals, which are then supported or opposed. In contrast, the Idea Lab should be a place to develop proposals, and that page should prohibit oppose (as well as support) votes. The usual sequence should be to bring up an idea at the Idea lab, then work on improving it, and when it seems to be in a decent shape, port it to Proposal for an up or down vote. Obviously, real life is a little more complicated, and contributors to the idea lab might think they are ready, only to find they are not, but no big deal, back to the idea lab for more improvements.

Do I think this idea has challenges? Absolutely, but why not work on improving it, rather than simply dismissing it. I accept that it may need to be dismissed in its present form (too many unanswered questions) so I don't fault any opposes here, all the more reason to port this over to idea lab, and work on the flaws and challenges, then try again.

(Of course, if I followed my own advice, I'd be proposing this first at Idea Lab. However, I thought I'd strike while the iron was hot.)--SPhilbrick(Talk) 17:11, 22 October 2013 (UTC)

Unnecessary Redirection of Pages

Can we have a policy on preventing users from redirecting pages which can/will be created in the near future? This is generally related to movie titles for example, Nightcrawler (film) is already filming but even if i create an article on it, I will not be notified via Special:Notifications if the articles gets added/linked to different pages since technically, I did not create it. One of the user in question, Captain Assassin! has done this to MANY articles. I'm not sure if this should go under proposals but I think they need to stop this from happening in the future. It was OK before but because of the mediawiki software now adding this new "notifications" features, contributors, mainly those that make new articles would like to be informed when their articles get linked and also tools that link the articles a user has created will ignore those articles because it was not "started" by the user..--Stemoc (talk) 06:29, 22 October 2013 (UTC)

That is not entirely correct. Unless you create the article on the redirect page, your draft would move over the redirect, and when that is not possible, because of a more extensive history for the redirect, an administrator will generally delete the redirect to make way for the article's move into Wikipedia's mainspace. Therefor, stifling redirects is a fix to a nonexistent problem, in my opinion.—John Cline (talk) 06:38, 22 October 2013 (UTC)

I don't think you get notifications for an article being linked even if you did create it. Jackmcbarn (talk) 12:35, 22 October 2013 (UTC)

You can add a redirect to your watchlist, just like any other page; you can periodically go there and click "what links here". bd2412 T 13:44, 22 October 2013 (UTC)

You do actually Jack, i used to get notifications for this article for about 2 months, i had to turn the feature off in preference temporarily because of it..lol..tbf, it is a highly viewed article, and on the other hand, i created this page over a redirect, it doesn't appear as one of my articles in the xtool and i'm never notified if it gets linked anywhere. Articles are created on the page they are supposed too, for example, why would i create Nightcrawler (film) elsewhere? The user i mentioned above was warned for just that. I'm just saying that there should be a policy on this and there shouldn't be a need to run around admins to delete certain redirects. People should not redirect pages, maybe along the lines of invoking WP:CRYSTAL. I just did random search for movies currently tagged as "filming" on IMDB and 8 of the 10 movies were redirected by that very banned user months in advance. Lets look at this example by another user. Jedi94 did all the hard work in developing this article but he will never get any notifications on it getting linked to other articles, all he will see is what he see on his watchlist...can we put an end to this "crystallballing redirects"? Currently its not possible to put pages on your notifications and thus if you didn't "create" a certain page, you will not be notified on linkages..@bd2412, how does "periodically" help? Maybe Ok for people with a few pages created but not for those with hundreds.....Whats the use of the new Notification features if you can't actually fully utilise it?...until they come ip with a method to manually add pages to your notifications, this would be a problem...--Stemoc (talk) 13:52, 22 October 2013 (UTC)

If you create User:Stemoc/Nightcrawler (film) as a draft, and then move it to Nightcrawler (film), I beloive you will be listed as the first contributor to (creator of) the resulting article. If people are already searching Wikipedia for a future event/topic, such as a forthcoming film, but we do not yet have an article due to WP:CRYSTAL, such a redirect is IMO often helpful. DES ^(talk) 19:27, 22 October 2013 (UTC)

I tried your idea DES, but as i figured, it didn't work and i get a beautiful

"You do not have permission to move this page, for the following reason: The page could not be moved: a page of that name already exists, or the name you have chosen is not valid. Please choose another name, or use. Requested moves to ask an administrator to help you with the move. Do not manually move the article by copying and pasting it; the page history must be moved along with the article text"

When people search for a future film, they'd rather find the film they are looking for instead of getting redirected to the director/producer of the movie's page. These redirects are a pain in the backside and are very UNHELPFUL to the wiki and article writers. When i search for a film on wiki and I do not find it, If interested, I would try to make that page but If i get redirected to the director's page, how exactly is that "helpful"? Back when i had "global rollback", it gave me the ability to "delete" the page I was moving another page to which is a feature limited to admins upwards only here. Maybe in the future this feature would allow users to move pages to "redirected" pages by deleting them one day...Again, Unnecessarily redirecting pages should be STOPPED--Stemoc (talk) 04:40, 23 October 2013 (UTC)

Agree with User:Stemoc, above, for the need to at least address this specific issue somewhere in the policy manual. (Perhaps at Crystal?). GenQuest ^{"Talk to Me"} 19:20, 22 October 2013 (UTC)

Very well, Stemoc, then that tactic requires admin assitance. I think any admin would be glad to give it, I know I would. As for when such a redir is helpful, it is not to an editor but to a reader. Remember the vast majority of our readers never edit. if they search for a film and get redirected to the page for the director, they will get some information, particularly if any information about the forthcomming film that is available has been added to the director's page (as I would think proper when there isn't yet enough sourced info to create the film's page as per WP:CRYSTAL.

I can see how this situation frustrates you. Perhaps we ought to allow rollbackers or some similar group to do "move over redirect", (esp now that we have added Template Editor showing some flexibility with rights) but that is a different proposal altogether. Consider also the case where a film is announced or predicted, but does not appear until long after the planned date, or at all. There the redirect is potentially quite helpful to readers. I don't think it should be prohibited. DES ^(talk) 15:05, 23 October 2013 (UTC)

I have now done the move on your behalf. DES ^(talk) 15:08, 23 October 2013 (UTC)

Yes but its not over. This should be re-looked at, this hasn't been solved. This type of redirects should no be allowed in the first place and to looks like only a certain few do this. No one owns the articles and should not be allowed to do so. Admins will not understand how big a problem this could becomes they have the tools necessary to fix it....can this be added to the crystal policy--Stemoc (talk) 10:06, 25 October 2013 (UTC)

Wikintelligence - your comments on Meta for a grant proposal

Dear colleagues from English Wikipedia, I have made a proposal for an Individual Engagement Grant: Wikintelligence.

It is a proposal to conduct a feasibility study by a scientific research institute, for using Wikidata in the long-term goal as an open Artificial Intelligence for improving quality of Wikipedia articles. Funding should be for the most part by local authorities or by FFG - Austrian Research Promotion Agency. This could be a model for further funding of Wikimedia research projects, especially of Wikidata, but also for Wikipedia.

Could you please have a look, comment, give me tips to improve it? m:Grants:IEG/Wikintelligence Thank you very much! Kind regards

Edgar

Projekt ANA (talk) 21:10, 22 October 2013 (UTC)

New type of search engine

I suggest Wiki to do a new kind of data base, It will be the first of it's kind in the webthe idea about making search engine for the oppositions, I mean the volunteers should entering 2 opposite items & mention the points of oppositions , then filling the tableof course they should categorize their comparisonhope to get an answer, thanks a lot Caandor@hotmail.com

Notification of RfC: Does Wikipedia need three different CSD criterion for "No indication of importance" or should they all be merged into one?

There has been an RfC started at WT:CSD#RfC: Does Wikipedia need three different CSD criterion for "No indication of importance" or should they all be merged into one? that your participation would be appreciated at. Thank you. Technical 13 (talk) 02:08, 24 October 2013 (UTC)

Generation Wikipedia: Wikimeda Youth Conference Proposal

Hi folks! For the next round of Individual Engagement Grants from the WMF, Keilana and I have proposed Generation Wikipedia, a pilot, week-long summer conference for young Wikipedians and Wikimedians from around the globe, to develop skills, leadership, and community in a safe environment. Please come and check it out: Generaton Wikipedia Cheers, Ocaasi ^{t | c} 02:44, 24 October 2013 (UTC)

Re-imagining Mentorship IEG proposal

Hi all!

An Individual Engagement Grant entitled "Reimagining Mentorship on Wikipedia" is currently under review at Meta. As part of our research into the best approach to take when we work on this project, we are seeking feedback and ideas on how to best achieve this project, and as the Teahouse is one forum that new users utilise a lot, I hope Teahouse hosts would consider giving feedback and comments on our proposal. It would be greatly appreciated! :) Steven Zhang (talk) 03:24, 24 October 2013 (UTC)

User citation templates or global citation templates

Coming from the research community, I was wondering if it would not be possible to allow a system where a user could reuse their own citations. Or is this allowed already? I have created a prototype here: User:K.Nevelsteen/references/deSouzaeSilva2009-Cityscapes and used it on my User page.

• Adv: Inline cites would be much less space consuming, improving overall readibility !!!
• Adv: Less copy pasting between articles
• Adv: Errors in citation can be fix in one place instead of hunting down all uses
• Adv: Multiple cites would take up less space in the Wiki database
• Adv: Citation system could be linked to a source like: Google (web) Google Scholar (publications) or perhaps Archive.org.
• Adv: Allows citations to be tracked back to the users that added them
• Adv: Share common cites with other Wiki users
• Adv: Pull up all pages that are linked to a particular cite.
• Adv: Control for plagiarism and other cite misuse
• Dis: Unless this is a global concept, potentially long user URLs
• Dis: If it is a global concept, name clashes shall occur
• Adv: Name clashes will result in clarity on what is being referenced
• that's all I can think of for now....

A Naming convention would have to be decided upon. BibDesk has the option of "AuthorYYYY-FirstWordinTitle", but another scheme is possible of course.--K.Nevelsteen (talk) 14:10, 18 October 2013 (UTC)

Caution: bit of a ramble {{Cite doi}} and {{Cite isbn}} are somewhat similar in function. For using up less space inline, list-defined references are effective at that. I can't remember off the top of my head where this was, but a WikiProject (I think it was) had set up a page with a bunch of references on it to be transcluded off to articles, but it was slow to load and I think there were a few other problems. (I don't remember how similar that was to this proposal). On a devil's advocate side, a transcluded citation could change unexpectedly causing problems, though a transcluded citation would be more easily updated. Chris857 (talk) 19:49, 18 October 2013 (UTC)

Thanks, I found out how to do ref lists with short inline marker instead of having the ref completely inline. I will look at the Cite doi. Perhaps this proposal was over zealous. Sorry.--K.Nevelsteen (talk) 12:03, 20 October 2013 (UTC)

{{Cite doi}} is interesting. Drawbacks are that not all articles have a doi. If each cite could be given its own template, then even webpage links could be reused. I noticed recently the tiny VTE links on these types of templates: {{Mixed_reality}}. Would be handy to have a tiny link on a cite, so that you can find it and edit it. cites are all over the place now in the article: middle with cite previously, bottom with cite at top, top with cite at bottom. With long cite list, you waste time hunting for them. I think cite templates might remedy some of this. I am not fully aware of all the wikipedia cite options, so this can still be very over zealous. mea culpa.--K.Nevelsteen (talk) 08:19, 21 October 2013 (UTC)

{{Cite doi}} is unbelievably perfect. I just wish it could be applied to a wider range of cites. Cheers!--K.Nevelsteen (talk) 20:57, 21 October 2013 (UTC)

Three more drawbacks to {{cite doi}}: 1) Doesn't allow for differences of presentation, such as where one editor uses full first names and another uses only initials. 2) It is highly aggravating when editing an article or alphabetizing a reference list to see only the doi. 3) Tiny links on citation encourage anyone to screw around with the citation. ~ J. Johnson (JJ) (talk) 22:25, 27 October 2013 (UTC)

Semi-protect all archives

Archives aren't watched by many people, and in some cases they aren't watched by anyone. It might not be logistically possible to do this automatically for all talk pages, but we could do it for the noticeboards and village pumps with a bot. We could start by semi-protecting all their existing archives. Just a thought. equazcion → 03:57, 26 Oct 2013 (UTC)

Oppose No real harm comes if archives are vandalized. It's not like they're highly visible templates, and most people don't ever look at them (and the ones that do are generally experienced in fighting vandalism), so I don't see a need to preemptively protect them all. Jackmcbarn (talk) 04:09, 26 October 2013 (UTC)

People do look at archives, and tell other people to look at them when old proposals are raised in a new guise. Vandalism can be subtle. If this can be done automatically, then why not? --Stfg (talk) 09:11, 26 October 2013 (UTC)

Strong support I look at archives all the time, and always assumed they would be protected, since there is no reason to alter an archive. I rank this proposal on the list of things we should have started doing ten years ago. --NickPenguin_(contribs) 12:22, 26 October 2013 (UTC)

This is a solution in search of a problem, there is no evidence to suggest that archives are subject to any real amount of vandalism--Jac16888 ^Talk 13:32, 26 October 2013 (UTC)

There are several reasons to edit archives: to fix tranclusions, remove images, categories, or other problematic personal or BLP violating content, to give some obvious examples. Vandalism to an archive should be relatively easy to spot, is relatively harmless, and is easy to fix. Most types of vandalism to archives are already controlled with edit filters. I would suggest changes be made to the edit filters to address any demonstrable problems. -- zzuuzz ^(talk) 18:59, 26 October 2013 (UTC)

• I would support PC1 protection on archives (this would make it more obvious to all if vandalism has occurred), no need to semi-protect though in most cases. I agree, this is a solution in search of a problem. Technical 13 (talk) 22:28, 26 October 2013 (UTC)

This is not exactly intended to solve any glaring problem (although I'm not really sure if any problem involving archives would ever be glaring, which is part of my concern). It seems to make sense as good practice though. Archives are a record of past discussions that should remain more or less unaltered, yet we really don't have anything in place to ensure that -- it seems currently that they're actually more susceptible to arbitrary changes than anything else on Wikipedia.

I happen to have noticed an archive vandalism recently, along with its revert (by someone else). It got me thinking of how it was just dumb luck that there happened to have been even one editor who noticed. I disagree with Jackmcbarn's suggestion that it's no harm done if archives get vandalized. The fact that they're not used prominently means changes to them will easily go unnoticed -- even to the people who will eventually need to use them, who themselves might likely not realize content was altered.

Technical 13's PC1 idea might take care of things, I'm just not too familiar with its workings. But whichever level is used... being that archives shouldn't require much editing at all -- and I can't think of too many situations where brand new users would need to -- it just makes sense to use something. I mean, doesn't it? equazcion → 03:45, 27 Oct 2013 (UTC)

• The problem is that archives are indeed rarely watched, and most people do not directly go to archive pages; they instead use the "search" function, and would be unable to find what they're looking for if the specific archive containing the text they're seeking has some unreverted vandalism. There is rarely any reason whatsoever to edit archives except to archive or unarchive a thread, and I do not think it would be problematic if these edits were done only by (auto)confirmed editors. ☺ · Salvidrim! · ✉ 00:03, 29 October 2013 (UTC)
• PC1 or possibly PC2 seem eminently reasonable. I've suggested similarly for project-space redirects (like WP:V, WP:ANI etc.) as I've seen redirect vandalism before and don't think there are many people watching the more obscure redirects. —Tom Morris (talk) 16:01, 30 October 2013 (UTC)

"Evil Empire" as Wikipedia slang for "Wikimedia Foundation"

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I propose we should start using the term Evil Empire as slang for the Wikipedia:Wikimedia Foundation. I think it will be healthy for the community to vent and occasionally poke fun at the WMF with this pejorative, yet silly, but sometimes deserved (at least in the minds of some) moniker. I'd also like to make WP:Evil Empire redirect, as WP:WMF does, to that page. Are there already nicknames, possibly even this one, already in common use? Those could also be redirected. Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 11:20, 30 October 2013 (UTC)

I'd support this if I didn't think it was a detrimental misconception. The problem with the Wikimedia Foundation, as I see it, is not that it's so big that it's become too powerful (it's really not so big or powerful). You don't need to be all that powerful to override this community; you just need to be the guy who runs the server, and that's who they are.

The problem is human nature. We within the community can't get away with vetoing others, and that's often the only reason it doesn't happen here. It's not for any lack of a frequent overwhelming urge to do so. Human instinct is to think one knows better than others. Even the most experienced people here will sometimes fall victim to that instinct when they feel strongly enough. None of us get away with it though, as we simply can't. The WMF can, so they do, because that's what would happen if any particular group had a technical leg up that would allow them to. They may rationalize those instinctual actions as a demonstration of some vague quasi-unwritten-policy, but rationalization is, similarly, mere human instinct.

I feel the admin corps once operated near-similarly, but went through a kind of evolution that took several years and perhaps the WMF may experience as well. I don't think it helps to think of the WMF as "big and bad", even in jest. They're not. As I see it, they simply haven't matured (yet), nor grown into their more visible recent form (the one with the corporate face and the liaisons and product managers and assorted digglybobbs). The WMF is still finding itself, or at least that's my hope, since our hands are pretty much tied until they do. Time will tell. In the meantime, a more healthy sarcastic redirect might be WP:The kids.

And thank you for the opportunity to post this diatribe. equazcion → 15:10, 30 Oct 2013 (UTC)

And thanks for the opportunity to create that redirect. Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 16:17, 30 October 2013 (UTC)

• Not helpful. Newyorkbrad (talk) 15:19, 30 October 2013 (UTC)
• Oppose per Hanlon's razor: never attribute to malice that which can be adequately explained by incompetence. —Tom Morris (talk) 15:45, 30 October 2013 (UTC)
  • No malice intended, and now withdrawn per equazcion. Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 16:17, 30 October 2013 (UTC)
• I agree with Newyorkbrad's assessment. bd2412 T 16:35, 30 October 2013 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I requested deletion of the redirect WP:Evil Empire based upon the direction of this discussion, but I still think I was completely misunderstood. The key is to poke fun at the corporate personhood without poking fun at any person. Any suggestion I was trolling is out of bounds, in my opinion. I was essentially proposing a sarcastic edit to the WP:First sentence of WP:Wikimedia Foundation, which I started out of a failed WMF noticeboard attempt. My post here should be viewed as such. Just because our structured Wikipedia bureaucracy disincentives creativity doesn't mean creative proposals should be slapped down with knee-jerk reflexes. I think that's a Wikipedia-wide issue. Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 09:29, 31 October 2013 (UTC)

This is the last thing we need. I'm embarrassed. Tony (talk) 11:51, 31 October 2013 (UTC)

Well I think it's interesting you're embarrassed. I'm not embarrassed for having what appears to be a bad idea. Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 12:16, 31 October 2013 (UTC)

• Well... If I had gotten to see this before it had gotten BOBSLED closed, I would have supported it as long as it was clear... There is a precedence for this kind of thing, and I see much less harm (developer pride) than I do good (developer realization that they are just a part of the puzzle that makes things "work"). Shame it got misunderstood and shot down so quickly. Technical 13 (talk) 14:06, 31 October 2013 (UTC)

Today's featured portal

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Should the Main page include a weekly slot for a featured portal? This would go once a week (not Mondays) in the place where Today's featured list is on Mondays.

The rationale is that featured portals are the only type of featured content that don't appear on the main page (except sounds which is inactive).

00:33, 30 September 2013 (UTC)

Support (Today's featured portal)

1. As nom. Ypnypn (talk) 00:33, 30 September 2013 (UTC)
2. Support, an excellent proposal, my thanks to Ypnypn (talk · contribs) for this initiative! — Cirt (talk) 03:06, 30 September 2013 (UTC)
3. With 163 featured portals currently available, divide that by 52 weeks, it will take over 3 years to exhaust the selection. So yes, I support. OhanaUnited^{Talk page} 04:24, 30 September 2013 (UTC)
4. Support Anything to showcase another body of work that's been accomplished. I feel this would do well to spur another avenue of development. Thi proposal has come up before, and now there should be no problem with content in the immediate future. --NickPenguin_(contribs) 05:53, 30 September 2013 (UTC)
5. The main page should direct readers to branches of knowledge. What better way than through featured portals? — (っ◔◡◔)っ^{Ross Hill} 20:57, 30 September 2013 (UTC)
6. Support the concept in general, however we should audit the existing pool of FPos to make sure that they're up to standards. As for the comments that the pool isn't that large, or that FPoC doesn't promote enough portals per year, I think that Main Page visibility would spur some interest in the concept. Also, we should be encouraging visibility for portals; I encourage the addition of links to them in related articles all the time. Imzadi 1979 → 23:47, 1 October 2013 (UTC)
7. Weak/qualified support - I'd put them in batches of three alongside the nine links we have at the top. Agree with concerns about currency and we'd need to do a bit of dusting.Cas Liber (talk · contribs) 04:22, 11 October 2013 (UTC)
8. Support if there are enough like Imzadi1979 said above. Before I became an editor I didn't even know Portals existed; maybe "Todays featured portal" could help. RainCity471 13:21, 14 October 2013 (UTC)

Oppose (Today's featured portal)

1. My main concern is the number of current FPs (currently at {{Featured portals number}}), the lack of topics (only 12) and the rate at which new ones are promoted (there are only two candidates currently posted on WP:FPOC, with one dating back to the start of this year). Unless these numbers improve, we are going to cycle through all of them in three years. And it is inevitable that Geography and Places portals may have to appear in back-to-back weeks, or at least multiple times in one of these months -- while the sole Math portal and the sole Reference portal is sort of like a "miss it if you blink". The lack of numbers was one reason why it took a very long time to get TFLs on the Main page in the first place (it took four years from the first TFL proposal to the one that was eventually accepted), and having it only appear once a week was a compromise once their numbers started to increase (there were over 400 FLs when the TFL section was eventually implemented). In addition, nobody yet has proposed how this new section would look on the Main page. Would it consist of a single link, or a full section of prose? Another reason why it took forever to get TFLs on the Main Page was getting a consensus on how that section would look. And there was a three-month trial run for TFL before it actually went live on the Main Page (three months is more than enough time to exhaust all ten of the History and Events featured portals right there). Zzyzx11 (talk) 04:28, 30 September 2013 (UTC)
2. I also question how many of the featured portals meet current standards. It is all-too-easy to set up a portal, add some articles/DYKs/pictures to rotate automatically, get the star and then never edit the portal contents again. (I got P:ENGLAW to FPo standards but must confess it's been a few months since I last checked it over.) Meanwhile, the blurbs go out of date, selected articles fail to reflect changes in GA/FA/FL status, no new content is added to the rotation, no updating tweaks are made, news sections go out of date, etc. I would not be happy to see portals on the main page until a thorough audit of all existing FPos is made. Wikipedia:Featured portal review/Indianapolis and Wikipedia:Featured portal review/Literature, for example, show that it is entirely possible for a featured portal to be in a poor state for at least two years before anything is done about it. However, the idea of main page use of FPos is one worth exploring - but the quality has to be assured first. I also wonder about a weekly appearance, simply because I cannot see FPOC promoting a net 52 portals a year to keep up with demand. Bencherlite^Talk 09:53, 30 September 2013 (UTC)
3. Since the point of portals is the be entry points this seems kinda odd. There is also something of a lack of content.Geni (talk) 13:56, 30 September 2013 (UTC)
4. I agree with Geni. I thought portals were main page alternatives anyway. --BDD (talk) 16:30, 30 September 2013 (UTC)
5. I agree with Bencherlite. I just checked a few random FPos and many haven't seen any significant expansions in years. Portal:Alternative rock was featured in 2007. The only major change its had since then was to remove the "News" section in 2010, which was nearly a year out of date. Portal:British Empire hasn't seen any significant edits since 2010. Portal:Library and information science has only had a couple of pictures added since 2007. Even Portal:New England, which was just featured last October, has only had 1 substantial improvement since then. FPoC was really busy in 2007-8, promoting 3-4 every month. Now we promote 4-5 every year and many of the old ones are unmaintained. I'd be willing to bet that nearly half fail criteria 1d. I'd also need to see how it would look. Most portals are structured similar to the Main Page. They don't really lend themselves to condensing since they are already condensed. Mr.Z-man 17:17, 30 September 2013 (UTC)
6. Contra above, I think there were nearly 2,000 FL's when the TFL section started, not 400. FLC also promotes well, well above the burn rate of 52 a year; FPoC doesn't even come close to that. I don't think we should be starting new sections that we are fully aware are not sustainable for any long-term period of time. Courcelles 22:54, 30 September 2013 (UTC)
7. Oppose as per the burn rate discussed above. Also, it is unclear how one would actually present a portal on the main page, without effectively duplicating the sort of content we see in TFA for the primary topic. Lastly Main Page space is limited, and losing TFP for a second day a week would not be a cost-free choice. --LukeSurl ^{t c} 10:44, 3 October 2013 (UTC)
8. The oppose reasons above seem fairly significant issues to me, leaving aside broader discussions on the significance of portals. Andrew Gray (talk) 19:42, 3 October 2013 (UTC)
9. Nah. Let's just put Wikipedia's best work on the front page, as it is the most visible part to the general public. Andrew Lenahan - Starblind 21:57, 8 October 2013 (UTC)
10. Oppose I've built two featured portals solo and assisted on a third, and in the course of doing that I've had to look dozens of featured portals. Unfortunately, there are a lot of FPOs that achieved Featured status under an old, considerably less rigid, set of standards. The newer ones are great. The older ones are... not so great. Before any talk of getting portals on the main page, I'd at least like to do an inventory of the ones we've got already, decide which ones need improving, and get a better number. The list of portals page itself also needs updating, as it has to be done manually and is years out of date. In short, it's a mess. Perhaps in six months? Sven Manguard Wha? 05:40, 11 October 2013 (UTC)
11. We had an RfC about whether we even needed portals a few years ago and their condition has only worsened. Marcus Qwertyus (talk) 18:10, 11 October 2013 (UTC)
12. Oppose; the main page is overburdened with information as it is. Adding more is not the solution. Ironholds (talk) 05:06, 19 October 2013 (UTC)
13. Oppose per Z-man, Bencherlite etc; most portals aren't updated & many are now old, & featured under older standards. Johnbod (talk) 02:59, 21 October 2013 (UTC)
14. Oppose even if the portals were good, this would likely further validate the formation of factions. The informal ones are already bad enough.--MarshalN20 | ^Talk 21:38, 23 October 2013 (UTC)
15. Oppose. Firstly, we don't have many featured portals; the main page will swiftly run dry. Secondly, the quality is questionable in many cases. Thirdly, I just don't think portals are especially relevant or useful to readers any more, though I recognise that some editors feel portals are a good route to getting stars awarded by other editors, and this has helped keep the concept alive a bit longer. We should focus on articles; that's what readers come here for. bobrayner (talk) 13:04, 27 October 2013 (UTC)
16. Oppose Not very meaningful to readers (as opposed to editors). I would daresay most readers don't know what a portal is. 91.230.41.97 (talk) 09:50, 28 October 2013 (UTC)

Discussion (Today's featured portal)

I tend to kinda question the value of portals. They seem like something that was a logical step in theory at one point in Wikipedia's development, but in view of the way Wikipedia is used predominately, they don't see much practical use and are ripe to be deprecated altogether. This is just based on my personal view and I could be wrong. I'd be interested to see stats on portal views. I checked a few manually and most of them look bleak. In trying to target likely popular topics, I found Film got 126,734 views this month, and History got 99,178 -- nevertheless, those seem to be the exception rather than the rule. equazcion� | 06:13, 30 Sep 2013 (UTC)

I have been using Wikipedia for years and years, and I have probably looked at a portal page about three times. 86.160.87.129 (talk) 13:49, 30 September 2013 (UTC)

Interesting timing Equazcion. I added an item to my to-do list to look at Portal:basketball. It is in terrible shape. It doesn't get many views, but I'm not sure what drives views. I don't really buy into the build it and they will come philosophy, but, coincidentally, I looked at the Film portal page views, and see they get a lot. I've almost never looked at a Portal. I think the concept has some value, but I don't want to put any effort into improving the basketball one, then find out that the Film traffic is unrelated to the quality of the Portal. Who does visit Portals? Is it a Google search result, so it is new readers, or is it internal links? I've been meaning to ask the Film people if they know.--SPhilbrick(Talk) 23:37, 30 September 2013 (UTC)

From the random checking I've done, there seems to be a pretty good correlation between page views and the number of internal article links to a portal. I don't think google results are responsible -- I'm having some difficulty getting one to come up there purposely in searches.

From what I understand, portals were originally intended to be alternatives to the Main Page for those who want to focus on a topic as their bookmarked entry point to Wikipedia. In practice, I get the impression that when they're actually used, it's to research a topic from a broader perspective. However I also get the feeling that they're really not used much at all, but rather, a good portion (if not most) of the page views can be attributed to random clicks out of curiosity. I'd even be willing to place some good odds on the admittedly blasphemous notion that the Main Page itself gets most of its views purely because random logo clicks lead there.

This is mostly speculation, but it's somewhat educated. We all know how Wikipedia is generally used by the population at large -- links to specific articles are found via google practically whenever someone searches for anything, and those links get passed around. People don't come to Wikipedia to check out what's going on in general (except for avid editors, who just go to their watchlists); Many websites were at one point trying to do just that (to be people's "portal", to the internet itself if possible, which is a hope some still cling to), but that concept really died on the table years ago. The Portal namespace likely came about as a result of that trend. Once Google started catering to people's more instinctual urge to use the internet as a tool to find the specific something they need, that was the end of that. equazcion� | 00:32, 1 Oct 2013 (UTC)

Thanks for the feedback. Do we know about outgoing traffic from a Portal? If arrivals are all accidental, but they find it valuable, and then go on to visit another article, it is valuable. If their arrival is accidental, and they back up or close because it isn't useful, then that's another story.--SPhilbrick(Talk) 14:07, 2 October 2013 (UTC)

• A bit of history might be useful here in explaining what has happened with featured portals. As Mr.Z-man points out, they were very popular in 2007-08. That wasn't because people loved making featured portals; if you check around, most of the lead developers of portals for that period made one portal only. They were building them because portals were the easiest type of featured content to make, and at that time it was practically required to have some featured content under one's belt in order to have a successful RFA. Most of those portals were essentially abandoned shortly after the "goal" was reached. Now, this isn't to speak ill of those who contributed the featured portals: many of them continued to be very productive members of the community, some even more so after they were granted the admin bits. The only time I have ever looked at a portal is when I am reviewing a specific user's contributions. Risker (talk) 03:43, 4 October 2013 (UTC)
• I'm in favour of increased representation of the pool of featured portals on the main page, but I agree with the problems raised by Bencherlite & others in the Oppose section. One thing that could easily be done within the current design would be, in the portals link grid (top right), to replace Technology (the only portal there not featured) with a rota of vetted high-level featured portals, either randomly selected or one per week (or month, if there are too few appropriate ones). By "high level", I mean reasonably broad topics such as Feminism, Medicine or Religion, rather than narrow topics such as Barack Obama, Cheshire or The Simpsons. This would give an incentive (1) to improve broad portals that are useful to readers to featured status; and (2) to maintain/update such portals once featured. Espresso Addict (talk) 23:29, 7 October 2013 (UTC)
• Alternatively, you could weekly feature them somewhere in the Wikipedia:Community portal. Cenarium (talk) 14:54, 19 October 2013 (UTC)
• I think it would be better to have a "featured miscellany" in which anything not in the normal categories can be picked out and shown to users now and then, in hopes of raising its profile a little. Sometimes a portal, sometimes a template or a Lua module, sometimes a Refdesk or a Village pump forum, sometimes a sound from the old project or proposed through the new mechanism, sometimes even a dramaboard like the Signpost or Jimbo's talk page. :) Wnt (talk) 19:28, 21 October 2013 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The revert notification encourages edit-warring, consider removing or modifying it

Moved to Wikipedia talk:Notifications § The revert notification encourages edit-warring.2C consider removing or modifying it

Discussion moved to more appropriate place. HelenOnline 15:56, 2 November 2013 (UTC)

Embracing Internet Censorship in the UK

Moved to Wikipedia:Village pump (policy)/Archive 110 § Embracing Internet Censorship in the UK

Discussion already taking place elsewhere, there is no need to have two separate discussions open. --benlisquare_T•C•E 18:30, 25 October 2013 (UTC)

Edit summary when clicking 'New section'

I propose to add the possibility to leave an edit summary when clicking New section. Currently, the only way to include a custom edit summary is to use the Edit tab, but on long talk pages this results in longer load times, a lot of scrolling etc. -- Toshio Yamaguchi 13:04, 6 November 2013 (UTC)

Your new section heading should be a good edit summary, and if it isn't, it is insufficient as a section heading. Adding a new topic to a talk page is too important not to have an automatic edit summary. VanIsaac_{WS Vex}^contribs 13:46, 6 November 2013 (UTC)

I am proposing this because in the task I perform I use a notification template that I put on article talk pages. The heading is already a good summary in my opinion (see User:Toshio Yamaguchi/Template:Article talk page NFCC concerns message). Often, when a talk page is long, the most convenient way (and quickest in page load times) is to use the New section tab, because this avoids the need for the markup editor to load the markup of the entire page and thus leads to increased loading speed, which does matter in a task where tens and hundreds of cases need to be dealt with. -- Toshio Yamaguchi 14:19, 6 November 2013 (UTC)

(edit conflict) If you add an additional text input field named "wpSectionTitle" to the edit form (e.g. with JavaScript) then that will be used for the section title instead of wpSummary when saving (but it won't work right with preview). It's also possible in the API, by using both the sectiontitle and summary parameters to action=edit&section=new. Anomie⚔ 15:14, 6 November 2013 (UTC)

I disagree, Vanisaac. I don't think a good section heading will always necessarily suffice as a good edit summary. Section content doesn't need to be summarized in its heading (as the content is displayed right there underneath them). A heading merely needs to be a title or label, and even a good one often doesn't suffice as a descriptive summary that's as useful as it could be to people seeing the edit in their watchlist or in page histories. This is one of those minor tweaks that would be useful in a somewhat minor way though, and I wouldn't count on a big push for it to occur. File a bug and hope it gets picked up by a dev. equazcion → 15:09, 6 Nov 2013 (UTC)

T20654 or T28312 probably already cover this. Anomie⚔ 15:14, 6 November 2013 (UTC)

Well, smack my ass and call me Judy. That does work. I made User:Equazcion/NewSectionSummary in case you want to just add this for yourself. Thanks for cluing us in Anomie :) equazcion → 15:59, 6 Nov 2013 (UTC)

Very nice. Activated this for my account. -- Toshio Yamaguchi 20:08, 6 November 2013 (UTC)

FYI I think I also just got around the preview issue noted above, so those should work as expected. Refresh your cache if you have this installed already. equazcion → 20:43, 6 Nov 2013 (UTC)

Well, the preview still looks a bit strange. When I enter Heading into the Subject/headline field, Bodytext. into the edit window and Summary into the edit summary field, the heading displays as /* Heading */ Summary as the header in preview and the edit summary is missing. The edit saves as intended though (tested in my sandbox). -- Toshio Yamaguchi 20:57, 6 November 2013 (UTC)

Okay I fixed that (I think) :) It corrects stuff after load though, so you might see the incorrect values flash for a moment. I'll try and get it more efficient. equazcion → 21:15, 6 Nov 2013 (UTC)

The flash only occurred because I was doing a hard-refresh on a preview page, and doesn't seem to occur during a normal preview. Should be good to go. If there are further issues it's probably best to bring them up at User talk:Equazcion/NewSectionSummary. :) equazcion → 21:29, 6 Nov 2013 (UTC)

The Wikipedia Adventure, alpha-testers needed

Hi folks, I've been working for the past 7 months on an interactive guided tour for new editors called The Wikipedia Adventure, as part of a WMF Individual Engagement Grant. The game is an experiment in teaching our aspiring future editors in an educational but playful way.

• This week I need some alpha-testers to kick the tires and basically try to break it. I'm interested in general impressions and suggestions of course, but I'm really looking for gnarly, unexpected browser issues, layout problems, workflow bugs, and other sundry errors that would prevent people from playing through and having a positive experience.

• If you're able to spend 1-3 hours doing some quality assurance work this week, you would have: a) my sincere gratitude b), a sparkly TWA barnstar, c) special thanks in the game credits, and d) left your mark on Wikipedia's outreach puzzle and new editor engagement efforts

• Please note that the game automatically sends edits to your own userspace and it lets you know when that will happen. If you want, you can register a new testing account just for the game, but it won't work properly unless you're logged-in by step 8 of mission 1 when it lets you register on the fly.

If you're interested, please add your name below and have at it. You can post feedback to WP:TWA/Feedback. Thanks and cheers! Ocaasi ^{t | c} 20:51, 16 October 2013 (UTC)

Try out The Wikipedia Adventure

I'm interested and on the bug-hunt. Will report back this week

1. Jackmcbarn (will be using my alt, Jackmcbarn no permissions)
2. K.Nevelsteen
3. GenQuest ^{"Talk to Me"} 22:33, 21 October 2013 (UTC) But, it threw out when it went to the "editing a new user page" section.

• Seems to now be working fine (except for the minor bugs I notified you about at the finish). Thanks. GenQuest ^{"Talk to Me"} 23:52, 2 November 2013 (UTC)

1. Ellin Beltz I tried it and got kicked out when it told me to create or edit my user page, there was no way back to the Adventure! Ellin Beltz (talk) 16:57, 27 October 2013 (UTC)
2. Deadlego

Wikipedia:Reward board guidelines tightening

Wikipedia:Reward board was kept at a recent MfD. I raised a couple of ideas to discuss on the talk page at Wikipedia_talk:Reward_board#As_we_are_going_to_keep_this.2C_do_we_need_to_tighten_the_criteria_a_bit.3F - if anyone has any other ideas now is a good time to stick them in. Cas Liber (talk · contribs) 22:06, 9 November 2013 (UTC)

wikidata: commons & other sister wikis

Hy! "inviting community discussion to show Commons links on the left", as per Wikipedia_talk:Wikidata#commons. also travel, ctionary, etc i'd like, but most importantly commons. right on top of lingo-s. and default open.
[off: talking about the left, where can i customise to include a searchbox there as it were?] --Aaa3-other | Talk | Contribs 19:36, 31 October 2013 (UTC)

In many cases a Wiktionary link would make more sense as the top entry. Praemonitus (talk) 01:59, 4 November 2013 (UTC)

I support adding Commons links to the right bar in every article. --NaBUru38 (talk) 22:26, 4 November 2013 (UTC)

Take a deep breath, relax, and try writing your proposal again. Use punctuation, capitals, and full sentences. Complete your ideas, and explain just what it is you want. Perhaps, then, we'll try to consider whatever it is you are proposing here. Thank you. GenQuest ^{"Talk to Me"} 06:47, 5 November 2013 (UTC)

There's no need to be rude about it GenQuest. Sven Manguard Wha? 06:57, 5 November 2013 (UTC)

You're right. Must have been a bad night. I apologize, User:Aaa3-other. Self flagellation now commences...

Plip!

GenQuest ^{"Talk to Me"} 06:01, 11 November 2013 (UTC)

• Oppose, reevaluate in a few months Wikidata didn't prepare adequately for deployment to Commons, and as a result interwiki links for Commons are still a mess on Wikidata. See this Wikidata thread for details. Sven Manguard Wha? 06:56, 5 November 2013 (UTC)
• Comment For anyone interested this is how the left tab looks on the Spanish wikipedia. There is also a discussion at Wikidata about the best way to link Wikipedia articles to Commons categries or galleries, or both. --ELEKHH^T 10:09, 5 November 2013 (UTC)
  • And it looks great, I think. --NaBUru38 (talk) 14:02, 6 November 2013 (UTC)
    • I agree. I'm just saying that Wikidata needs a few months to figure out how to handle the Commons links it needed to figure out how to handle a few months ago. Sven Manguard Wha? 17:27, 8 November 2013 (UTC)

Conflict of Interest templating bot

Per a VPR COI Template discussion, six weeks ago a trial of 500 insertions of the Conflict of Interest template has been made. The bot is coded up and ready to go. Now's the time to decide if the template ought to be applied more widely. I come seeking consensus: ought this bot task be undertaken more widely? Josh Parris 06:06, 6 November 2013 (UTC)

• So, do you have a link to the trial log that will tell us what the rate of clicking on the edit request button, the removal rate, etc? I can't find it on the bot request page. VanIsaac_{WS Vex}^contribs 06:50, 6 November 2013 (UTC)

Hrm.. I can't think of a good way to measure the trial really. I have found the template to be effective in some cases on articles I contribute to, but they don't always actually click the link. Also, we would need to look at data over at least three months in order to get an annual click-through rate. However, I think User:Addshore was the one that added a tracker to the clicky? and may be able to help us find out if folks are clicking on the link. CorporateM (Talk) 15:26, 6 November 2013 (UTC)

I cant remember this exactly, I also cant remember ot see me adding any tracker anywhere :/ Am I missing something? ·addshore· ^{talk to me!} 13:18, 9 November 2013 (UTC)

I was the one who created the tracker. @CorporateM and Josh Parris: At least two requested edits were made by clicking on links in the bot added notice, see Special:WhatLinksHere/User:Theo's_Little_Bot/coi_tracker/bot. You can find the requested edits on the linked talkpages doing a cmd/ctrl-F for "The above requested edit was made by clicking on a link in an automatically added". Theopolisme (talk) 15:24, 11 November 2013 (UTC)

Seems to me that the next step is to put a COI edit notice on the same 500 pages, with a different tracking link, so that the two mechanisms can be compared. That's what the original RfC contemplated, and with a 0.4% hit rate, the edit notice template doesn't seem super effective. Josh Parris 21:12, 11 November 2013 (UTC)

Proposed amendment to WP:NOT, re: Product release information

There is currently a discussion to amend WP:NOT, a key Wikipedia policy, to extend the prohibition of quoting product prices in articles without sufficient encyclopedic relevance (WP:NOTCATALOG), to also apply to information about how a product is released (i.e. where it is released, what stores it is available from) under the same caveat. You are welcomed to join the discussion. ViperSnake151  Talk  01:34, 10 November 2013 (UTC)

News namespace

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

This idea just occurred to me, based on my experience with articles about recent events in the news and the frequent attempts to nominate them for deletion soon thereafter. Given that it's always hard to tell whether the article topic is notable or not in these cases, since we don't know if the coverage will extend over a long time yet (unless you have a crystal ball), I propose we create a News: namespace for articles about things in the news now, and nominate everything in that namespace for deletion 3 months after the article is created. If it survives the deletion discussion it would be moved into article space. So... good idea or not? (Of course there's a 3rd option--suggest improvements.) Jinkinson talk to me 01:42, 28 April 2014 (UTC)

• Oppose Good idea, but that's what Wikinews is for. --Ahecht (TALK
  PAGE) 01:58, 28 April 2014 (UTC)
• My first impulse is to agree with Ahecht here. This seems pretty close to Wikinews' scope. Novusuna ^talk 02:43, 28 April 2014 (UTC)
• Comment: why should that procedure be implemented via a new namespace? I would think a maintenance template (possibly on the talk page) with an associated category (plus dated subcats) would do a better job. — HHHIPPO 07:16, 28 April 2014 (UTC)

  @Hhhippo: Because if it isn't people will pounce on the article right after it is created to nominate it for deletion and cite WP:NOTNEWS to justify doing so. Also the problem with the template you're presumably referring to is that you are only supposed to put it on articles that are getting edited by many different editors in a short period of time, which doesn't apply to every newsworthy event. Jinkinson talk to me 16:06, 28 April 2014 (UTC)

  Maybe I misunderstood what your actual suggestion is, so just to clarify: Am I right that you don't propose a way to avoid getting articles to AfD that would be snow-kept under current policy but rather a new area for topics that do not qualify for a mainspace article? If so, I agree that Wikinews is a good example for such an area. Others would be the User and the Draft namespace.— HHHIPPO 21:50, 28 April 2014 (UTC)

• Not Needed per Ahecht above. The time spent for editing news would be better spent by editors making more permanent improvements to the encyclopedia. Another news outlet is the last thing anyone needs here, IMO. GenQuest ^{"Talk to Me"} 16:41, 28 April 2014 (UTC)
• Oppose WP:NOTNEWS and Wikinews. --Redrose64 (talk) 18:51, 28 April 2014 (UTC)
• Not Needed. AfD comments citing WP:NOTNEWS are always wrong, and ignore where that link actually goes. Right now there's another batch of agitation for killing Wikinews. We have to remember that our free coverage of news is pressuring a large group of people desperate for a livelihood, so I'm afraid we're always going to be getting pushback telling us to get out of their private reserve, same as we get from the doctors. I might even feel guilty, if it weren't that so many news outlets like AP have a religion against citing their sources (beyond "some researcher in Canada") or giving in-depth or even fair coverage. We should fully integrate new information into our articles as soon as it is obtained without prejudice, just as the policy says. That said, we're still distinct from Wikinews in that we strive to have the most information rather than the first information, and don't have comprehensive reviewing. An illustration of this is that someone at Wikinews can get a complaint that they have "too many" sources, because someone has to review the article very quickly, whereas here we are or at least should be glad to have as many as we can. Wnt (talk) 18:56, 28 April 2014 (UTC)
• Idea: Integrate the In the news main page box with Wikinews. What do you think? --Rezonansowy (talk | contribs) 07:05, 2 May 2014 (UTC)
• Oppose, Its a great idea but as per Ahecht - We have wikinews. →Davey2010→→Talk to me!→ 14:33, 2 May 2014 (UTC)
• Oppose: Instead of the target result it will most likely raise the amount of housekeeping – as if it wasn't already taking too much time. I am also very uncomfortable with automatic AFDs. — Dmitrij D. Czarkoff (talk•track) 03:15, 4 May 2014 (UTC)
• Comment  A fix for AfDs when notability is in flux, or to preempt such AfDs, is Speedy Incubate or CSDD.  See WT:Drafts#Survey, Guideline for CSDD.  Unscintillating (talk) 05:03, 4 May 2014 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal to make "Lead section edit" a default gadget

MediaWiki/Wikipedia has moved [edit] link closer to headers so that people can understand they can edit the page. I am suggesting to make "Lead section edit" a default gadget and be loaded in all accounts by default. --Tito☸Dutta 00:06, 27 April 2014 (UTC)

I think it might confuse people. Why doesn't clicking "Edit source" right next to the title of the page open the whole page? WhatamIdoing (talk) 00:28, 27 April 2014 (UTC)

This sounds like a reasonable suggestion. One way to deal with this might be to rename the first link "edit lead section". --LT910001 (talk) 01:40, 28 April 2014 (UTC)

See bugzilla:156, particularly comment #81 wherein I summarized the problems, with screenshots. –Quiddity (talk) 17:28, 29 April 2014 (UTC)