Wikipedia:Village pump (proposals)/Archive 106

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

--

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

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: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,

--

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)

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)

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 :) ^

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

^{[omg plz]}

 15:22, 25 September 2013 (UTC)

Thanks for posting here

U

}}) while signing a reply, thx 16:43, 25 September 2013 (UTC)

And

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.

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

^{[omg plz]}

 17:19, 25 September 2013 (UTC)

Thanks!

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? ^

^{[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. ^

^{[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 ^

^{[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. ^

^{[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. ^

^{[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. ^

^{[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)

(

^{[omg plz]}

 00:40, 26 September 2013 (UTC)

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)

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)

Hi guys, just letting everyone in the proposals department know about an active RfC

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)

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)

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)

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

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)

When you visit a nonexistent page, you're typically given the option of searching for pages with similar names. For example, go to

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

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)

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

Backlog status (Purge)

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

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)

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)

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)

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)

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

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

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)

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)

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)

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)

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

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)

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)

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

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)

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)

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.

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)

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

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

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

Crystal?). GenQuest ^{"Talk to Me"}

19:20, 22 October 2013 (UTC)

Very well,

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

crystal policy--Stemoc (talk

) 10:06, 25 October 2013 (UTC)

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)

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 [email protected]

There has been an

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)

Hi all!

An Individual Engagement Grant entitled "

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)

{{

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)

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

I requested deletion of the redirect

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.

U

}}) while signing a reply, thx 12:16, 31 October 2013 (UTC)

• Well... If I had gotten to see this before it had gotten
  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

Closing per request at

Main page. Armbrust ^{The Homunculus}

07:42, 2 November 2013 (UTC)

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

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

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

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

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

WP:SNOW. Wikinews appears to already fulfills this proposal. --Mdann52talk to me!

08:29, 12 May 2014 (UTC)

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

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)

  @

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

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)