Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

New ideas and proposals are discussed here. Before submitting:

• Check to see whether your proposal is already described at Perennial proposals.
• Consider developing your proposal on Wikipedia:Village pump (idea lab).
• Proposed software changes that have gained consensus should be filed at Bugzilla.
• Proposed policy changes belong at Wikipedia:Village pump (policy).
• Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.

« Archives, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

Transferring over "filemover" tool

There is a discussion above about unbundling vandal fighting tools and creating new admin-lite packages. Whatever I think of the idea, I don't think that the community will go for unbundling some of the core items of admin rights. In the above conversation, I suggested unbundling or transferring over "filemover" onto Wikipedia, which is not a core part of admin rights, however the conversation was dominated by vandal fighting, so I'm moving this down here.

The "filemover" tool exists on Commons, and allows trusted users to move pages that exist in the file namespace (images, sounds, videos, MIDI compositions, PDFs, others). Period. It does not have any other function. There is a small but competent and talented group of editors that work heavily in files, myself included, that could benefit from this tool, and the risks of importing this over are low. It would allow people that work in files and backlogs to keep such things as Category:File renaming clear, and the only risk would be that users would make inappropriate moves. In reality, since any autoconfirmed user can move non-file pages, and there is already an effective way of tracking that and dealing with it, combined with the fact that this tool would be given to people that already work with images and have to demonstrate trustworthiness, I don't see the risks as being at all large. Meanwhile, Category:File renaming has 150 items, some of which are pending since December. Had I the ability to, I could clear that in less than two days.

Thoughts? Sven Manguard Wha? 19:38, 20 February 2011 (UTC)

That would get my support, yes - it sounds like it would boost productivity, and sounds low risk. -- Boing! said Zebedee (talk) 19:42, 20 February 2011 (UTC)

It has worked fine on Commons, and I would support it here too. I think this is a conversation for the Village Pump though, not here. NW (Talk) 19:52, 20 February 2011 (UTC)

Agree with Nuke—propose it on VP and then link it from here. Der Wohltemperierte Fuchs^(talk) 20:13, 20 February 2011 (UTC)

Moved to Village Pump (from Talk:RfA). Sven Manguard Wha? 21:14, 20 February 2011 (UTC)

For those of us not familiar with what exactly the tool does, could you elaborate a little bit? Specifically, my question is exactly what are the possible risks? That is, I have a fairly good idea of what could potentially happen if someone with the "block" button went bad, and so feel like it's important to make sure admins are well vetted. But, in this case, while your description of the tool seems mundane, I'm wondering if there is anything really serious that could go wrong. Or is this really just the File equivalent of the page-move ability that all autoconfirmed users have? If the latter, I would certainly support unbundling this from the admin tools. Qwyrxian (talk) 21:25, 20 February 2011 (UTC)

Okay, so essentially it is exactly "just the File equivalent of the page-move ability that all autoconfirmed users have" as you put it. It also logs as a move, which can be tracked through the move log (it's rare, being only a fraction of the move log, but here's Magog the Ogre's log which is full of them. The issue is that he seems to be the only one that does it consistently that I could find.) The risk is exceedingly minimal, it's easy to revert if there's a problem, and we would be giving it to people who already display competency in files and trustworthiness, and enough knowledge of the processes involved to know to ask. I can't see how this would result in any problems, honestly. Sven Manguard Wha? 22:19, 20 February 2011 (UTC)

In that case, it sounds very much like something that shouldn't be reserved for admins. Would you recommend having a request page like is currently done for reviewer and rollbacker? Qwyrxian (talk) 02:19, 21 February 2011 (UTC)

I suppose that would work. The upside of having that type of request system is that it makes it easy for the people that would have use of it to find it. The downside is that dozens of people that don't have any use for it and have no intention of moving files will clamor for it, under the mistaken impression that it's a status symbol. I suppose that as long as those users don't abuse the tool, it won't be a problem though. Sven Manguard Wha? 05:25, 21 February 2011 (UTC)

• Sounds reasonable to me. Having trusted non-admins do this work might free some admin time for clearing out the F8 backlog. 28bytes (talk) 22:48, 20 February 2011 (UTC)
• Template:Support This works on Commons and it should work here. TBH, tho, most of the files in that category should be moved to Commons. Mono (talk) 01:03, 21 February 2011 (UTC)
• I'm not experienced in working files, so my opinion here should be given proportionally small weight, but, having reviewed the docs at Commons and seeing that this would still be controlled by a separate right, this seems constructive, prudent and sensible. --j⚛e decker^{talk to me} 01:41, 21 February 2011 (UTC)
• I'm in the same boat as Joe. The risk that exists is a risk that we already face for article moves. But by having a lightweight requests process similar to reviewer/rollbacker, I'm pretty certain that this would be a net positive. —WFC— 04:57, 21 February 2011 (UTC)
• Support. I deal with a lot of files, both here and on Commons, this tool will definitely come in handy. And as W says, it will be a net positive. Although, I do think more focus should be made on moving "eligible" files to Commons. Rehman 10:06, 21 February 2011 (UTC)
• This sounds reasonable, but it could be granted as on commons, on the opinion of an admin, rather than people clamouring for it. Those that have put in good requested move requests could be the ones to have it granted. Also I would want the persone to know all about fair use and FURs. Graeme Bartlett (talk) 10:56, 21 February 2011 (UTC)

  I believe that there is a request page for filemover on commons as well, not instead of "at admin discretion" but in addition to. Here on en.wiki those request pages (for auto-patrolled, rollback, reviewer, etc.) seem to coexist with admins also doing some amount of granting things separately, I got rollbacker here originally without ever having asked for it (although I was asked if I'd want it, the admin who discovered me figured I'd get constructive use of it), and there's in fact an organized effort to grant autopatrolled to people to reduce the NPP load. I guess I was imagining that that'd end up be the case here. --j⚛e decker^{talk to me} 19:36, 21 February 2011 (UTC)

• Support. davidwr/(talk)/(contribs)/(e-mail) 16:37, 21 February 2011 (UTC)
• Support. Der Wohltemperierte Fuchs^(talk) 19:34, 21 February 2011 (UTC)
• Support This can't hurt. But I suspect it will be low-risk/low-reward as very few users will have any use for it. Along the same lines, though it's probably not doable technically, it would be safe to give reasonably experienced editors the ability to do {{db-move}} on their own. Pichpich (talk) 21:19, 21 February 2011 (UTC)
• Support. Looks like a sensible idea to me. bobrayner (talk) 02:38, 22 February 2011 (UTC)
• Support Sounds fine. It's worked well on Commons, and it should work well here.

  I just did a small test on Commons, and it appears that files that are fully move-protected aren't movable by filemovers. That's a good idea, I think, and we should keep it that way. NW (Talk) 05:06, 22 February 2011 (UTC)

  • Oops. I forgot to mention that earlier. Yes, Filemover can move semi-protected files, but no it cannot move either fully protected files or move protected files. Again, this is exactly the same set of rules that governs moving non-file namespace pages. As this would ideally be a simple code borrowing, I don't foresee that changing, nor would there be any reason for it to do so. Sven Manguard Wha? 06:27, 22 February 2011 (UTC)
• Support Yes please, that would we be useful. I had planned to propose this myself, but never got round to it :) Acather96 (talk) 19:26, 22 February 2011 (UTC)
• Support No big deal. -FASTILY ^(TALK) 22:22, 22 February 2011 (UTC)
• Comment - I was asked about the technical feasibility of this. From what I interpret as the proposal, that'd be a trivial change. It's a very simple configuration change that the admins know how to do. (X! · talk)  · @227  ·  04:27, 23 February 2011 (UTC)
• Support, kind of I've never really liked Commons' filemover system. No, it's not really dangerous  ... but enwiki has many more rights-hungry users who won't even understand what the point of it is. I would definitely prefer bundling this with some new right that includes a few useful features (e.g., merge accountcreator, add filemover, and move-without-redirect, etc.) for trusted and established users—not at all how we hand out rollback; it's like free candy. Is there a pressing need for more filemovers here? It seems like only a very small number of users would benefit from it, which is why I think bundled rights is better than creating more single-right usergroups. /ƒETCHCOMMS/ 03:44, 24 February 2011 (UTC)
• Note: added to Template:Cent. /ƒETCHCOMMS/ 03:48, 24 February 2011 (UTC)
  • Well I know of about half a dozen users that would have use for the filemover tool, and I'm sure that there are half a dozen other people that each know a half dozen people that could use it. I'm not sure how many people work in predominantly in files, and of them how many of those are already admins, so yeah, by best guess is that it would be around 36 or so people that would have legitimate use for the right. To some degree it's very easy to tell who does work in the file namespace and who does not. It would ultimately be up to the admins to make sure that the people that get the right are the people that need it. On the plus side, however, X! literally showed me what would have to be done to import the right. It takes two changes to one configeration page, so around 27 seconds to implement. That's one key argument against bundling, this is just such an easy change to make and it will be highly beneficial for the file gnomes. Sven Manguard Wha? 04:42, 24 February 2011 (UTC)
    • Hmm ... 36 isn't really a lot. Yes, it's an easy configuration change, but I don't think bundling takes that long, either (at least, it's a two-minute deal on my personal wiki). I'm not opposed to it, but we need to draft up fairly strict guidelines for handing it out—to users who would actually use it, such as you. /ƒETCHCOMMS/ 04:56, 24 February 2011 (UTC)
      • What would be the benefit to bundling? You mention the account creator right, but I know there are some people who consider the existing account creator/edit notice editor bundling to be a bug rather than a feature. 28bytes (talk) 05:07, 24 February 2011 (UTC)
        • (edit conflict) Well I got my Commons filemover right because an admin there thought I'd be able to put it to good use and knew how to use it. While I don't want this to turn into a cabal type activity, I would say that the easiest way to avoid this becoming candy is to just quietly inform admins like Magog who do filemoves themselves to be on the lookout for non-admins that make lots of good requests, are trustworthy, and display clue, and just hand them out that way. It's not a pretty option, but it would reduce the likelihood of people gaming the system for a shiny new right. It's either that, or people will game the system.
        • We could bundle the right with a few other more potentially dangerous ones, like move without redirect, but while that would force the standards to be higher, it would not reduce the whole "gimme gimme" factor.
        • At the very least, I think we can all agree that even if it does get out of hand, there are systems in place to remedy the issue, and moving files, especially if they automatically leave behind redirects, has a much lower potential for causing mayhem when abused than, say, rollback does. I really don't have an answer for you on this. Sven Manguard Wha? 05:18, 24 February 2011 (UTC)

(edit conflict) If we bundle, we should make sure that all the users which are given the right are checked thoroughly. Not through a process like RfA, but basically the admin should spend some time on the contribs, etc. That way, the right can be considered as a "trusted user" flag. Also, bundling will encourage account creators to help at file moves and vice versa. ManishEarth^{Talk • Stalk} 05:29, 24 February 2011 (UTC)

(edit conflict) I'm against bundling those two groups. Strongly so, in fact, because of how fundamentally different they are. Through my work at AfC I've had a chance to talk to several accountcreators, and have come to realize that they neither understand nor have any great desire to work in the areas I work in (files and the smaller namespaces) and I neither understand nor have any great desire to work in account creation. Wikipedia has a number or esoteric areas of work, and several of those areas have various types of userrights (account creator, OTRS access, toolserver access, abusefilter, etc.) Yes, there is overlap, but that's because a particular user in question works in several of those areas. Bundling any of these rights together would just give people additional tools that they don't need or know how to use, and will increase the chances of things going wrong. Right now, with the exception of rollback and reviewer, these userrights serve as tools of the trade for users that are a part of that trade (craftsmanship metaphor.) Combining them into a "trusted user" userright turns them from that into a sort of upper level caste below admins and above everyone else. This isn't their intention at all, and would, for a lack of a better term, be very bad. Sven Manguard Wha? 06:02, 24 February 2011 (UTC)

• • Can I ask why everyone is so opposed to a tangentially related proposal I just noted here? I'm not even trying to push bundling that much, just pointing it out as an alternative to consider later. At any rate, I'd like to see a clear policy on how this would work before supporting this proposal; it seems that very few users would need this so we must have requirements set. /ƒETCHCOMMS/ 16:13, 24 February 2011 (UTC)
• Who cares - Is being able to move files any more dangerous than being able to move any other pages? IIRC, the right was initially given only to admins because it was a new feature and only lightly tested, so use was controlled. Given the absence of major bugs, I don't see why it shouldn't just be given to all autoconfirmed users. Mr.Z-man 06:00, 24 February 2011 (UTC)
  • There's that option too, I guess. I'll have to think on that. Sven Manguard Wha? 06:02, 24 February 2011 (UTC)
• Support Oh yes! This will make the moving of images that much easier. No longer will I have to make up some sappy rationale to get an image moved uncontroversially. Kevin Rutherford (talk) 06:09, 24 February 2011 (UTC)
• Support Very good idea. Armbrust ^Talk _Contribs 06:44, 24 February 2011 (UTC)
• Oppose bundling of Account Creator As an ACC User and Developer, There are several reasons that account creators have their own permission group. Some of these reasons include that the group allows members to override most blacklists, some abuse filters, anti spoofing checks and rate limits (these are all seperate permissions). These permissions are given to account creators to allow them to create lots of accounts that sometimes blacklists would normally block. If it were to be bundled a person who has nothing to do with ACC wil able able to bypass (ALL) blacklists that are there for good reason for purposes other than to help create accounts for others. Secondly the group is there to help identify those people who are creating lots of accounts specifically for ACC so other people know they are not creating accounts for sockpuppeting, spamming, vandalism or other malicious purposes, rathor as part of thier work with ACC. ACC users are held to strict guidelines regarding how they over-ride anti-spoof, the same guidlines would not be enforced if it were given to non-ACC users. I have to agree with one of the comments above, why would you bundle permissions that have nothing to do with one another? Why create a "lesser admin" group? The current groups are there to serve specific roles and they serve them well.   «l| Promethean ™|l»  (talk) 13:13, 24 February 2011 (UTC)
  • Hmmm, that's a valid point. Another thing is that accountcreators have the 'noratelimit' right, which could be abused through the API (Basically, the user could mass-blank/mass-vandalise stuff and cause a headache for the rollbackers). So I redact my support above for the bundling... ManishEarth^{Talk • Stalk} 13:33, 24 February 2011 (UTC)
    • Yes, Manishearth, because fifty good users turn bad every day. We should not give admins access to Special:Nuke because I might decide to delete all the pages created by Alansohn or someone, right? Your rationale makes no sense. /ƒETCHCOMMS/ 16:07, 24 February 2011 (UTC)
      • Well, the filemover tool bundling would widen the range of users, and, by the looks of it (As my personal opinion is that filemover isn't too dangerous), filemover shouldn't be too hard to get (maybe a bit harder than rollback, but then again, rollback is "free candy"). ManishEarth^{Talk • Stalk} 06:42, 26 February 2011 (UTC)
  • Prom, the problem I'm seeing now is people who still want to acquire as many rights as possible—ACC is an example of this. Obviously, bundling doesn't solve that problem, but in reality, we don't need these separate userrights: ACC can be handled fine by enwiki admins only, as can file moving. It's just more convenient otherwise. /ƒETCHCOMMS/ 16:13, 24 February 2011 (UTC)
    • ₣etch this is a slightly different tune you are singing now that you got admin on ENWP. Have you noticed how few ENWP admins come around to ACC regularly? Right now there are none logged in to the system and i am not on irc to see if any are there. Content writing could be done by admins. It would eliminate the need for most everything else if the wiki was read-only for non-admins. Those wanting all rights will still come around. I still haven't got importer, abuse filter editor, founder, bot, IP block exemption, oversight, checkuser, bureaucrat, steward, or administrator but i hope to get some of them as birthday presents :P
      I thought it was 73 good users who turn bad every day for each user who promises to not vandalise any more if unblocked ;) delirious & lost ☯ ^~hugs~ 07:18, 25 February 2011 (UTC)
      • I have to agree with deliriousandlost on this one, it's funny how quickly one forgets the workings of smaller groups like ACC and why certain things are the way they are when one becomes an admin. In any case Fetch you have failed to address any part of my lengthy reasons as to why it is seperate. And to counter your claims regarding the accountcreator user right being flagwhored, you seem to quickly forget that anyone requesting it has to be an active member of ACC who frequently hits the 6 accounts per day rate limit or needs to create an account that antispoof is blocking which makes it hard to flagwhore, you either need it or you don't. Information about ACC users is publicly viewable on the ACC tool [1] and if Administrators (such as yourself) aren't checking that before giving the right to users then that is a failure of Administrators to follow set precedure and your fix of bundling the right will also fail because admins won't follow set procedure and hand out the bundled right to everyone. To me, the notion of giving out a right that allows users to bypass blacklists, rate limiting and anti spoofing to users who dont explicitly need it is the stupidest thing ive heard from an admin or otherwise. Please re-read my reasons above this comment and address them if you wish to discuss this with me further so I dont have to repeat myself. You talk about reality and yet you seem to be very out of touch with it.   «l| Promethean ™|l»  (talk) 01:39, 26 February 2011 (UTC)
        • I know alot of non-sysop users who are getting more experience by using the ACC tool. I'm getting more experience using the ACC tool, deliriousandlost, a tool admin at ACC, a non-admin here has alot of experience on ACC. Mlpearc, a non-admin, is a tool admin and many others such as Alpha Quadrant JoeGazz84 etc. Are you trying to say that just because we are not sysops on enwiki we are not capable of managing the ACC tool? Are you trying to say that we should remove a large handful of fully-capable and responsible users from the tool? --Addihockey10 ^e-mail 03:29, 26 February 2011 (UTC)
          • Addihockey, I think fetch is trying to say that he is to good for us since he is an admin now. Only admins are capable of anything because we are all just worthless people since we do all the hard stuff and all he does is pull out a damn block page and block some users. We write the content, we handle the stuff you don't want to do. No admin is active on ACC except for stwalkerster. It is ultimately his tool, you can't change who he gives access to, so you can't say that admins only handle requests, he won't stand for that, I know him. Many more users, like Addihockey, Alpha_Quadrant, and Mlpearc and the rest of the team, are WAY more capable at many more things than the admins. Personally, I think most of the admins are lazy, you get the sysop bit, so some easy stuff, most you do is automated. We do the hard work. We are more capable. Fetch, you are not the decision maker. You don't say now just because you are an admin that this doesn't matter. If you were in our spot, as an editor, you would be saying the SAME thing we are trying to tell you. Think about it. _{I am turning into a Delirious here... ( in a good way )}  JoeGazz  ▲  15:01, 26 February 2011 (UTC)
• Oppose bundling of Account Creator pretty much for what PromCat said; somewhat surprised that Fetch would raise this proposal since i would have thought him to be one to come out against such an action. delirious & lost ☯ ^~hugs~ 14:06, 24 February 2011 (UTC)
• Support filemover, but oppose the addition of the account creator rider. Filemover won't likely be used too much, but it can't hurt to give this right to trusted users — after all, Pagemover has been activated for all active users for several years, and moving around an article is generally more likely to be disruptive than moving around a file. Experience at Commons shows that this isn't likely to be misused. Nyttend (talk) 14:30, 24 February 2011 (UTC)
• Support filemover per above, and oppose the addition of the account creator rider per Nyttend. --Highspeedrailguy (talk) 17:59, 24 February 2011 (UTC)
• Support giving this permissi,ion to all autoconfirmed users — why does this need to be a separate permission group at all? Moving a file shouldn't be any different than moving any other page. If someone abuses the ability for vandalism, do the same thing we would do with standard pagemove vandalism: revert the damage and block them. *** Crotalus *** 19:27, 24 February 2011 (UTC)
• Support any option that gets ability to users beyond just sysops, either through a separate flag, or bundling it on some other (reviewer would work). But not account creator, please, that one gets "hacked" enough with the ability to bypass the title blacklist and create/edit edit notices. Courcelles 20:52, 24 February 2011 (UTC)
• Support - it'd lessen the workload for admins, which is a good think since admins have more important things to do than to move a file because of a simple misspelling. —Ancient Apparition • Champagne? • 9:20am • 22:20, 24 February 2011 (UTC)
• Support filemover, but oppose the addition of the account creator rider per Nyttend. I have filemover on Commons and create accounts here, and agree that they are too different to be bundled.   — Jeff G.  ツ 03:42, 25 February 2011 (UTC)
  • Whatever we decide to do, let's please test it on Test Wikipedia first to make sure that the mechanics are sound.   — Jeff G.  ツ 04:02, 28 February 2011 (UTC)
• Support filemover, per above. Basket of Puppies 04:48, 25 February 2011 (UTC)
• Support filemover but only if it doesn't go to everyone, for reasons I've explained below. Magog the Ogre (talk) 03:24, 26 February 2011 (UTC)

(edit conflict)

• Oppose bundling of Account Creator - I also agree with Promethean and on a side note am surprised also Deliriousandlost. Mlpearc powwow 03:32, 26 February 2011 (UTC)
• Disclaimer For those in doubt, the bundling of Account Creator was not, is not and will not become a part of this proposal. —WFC— 08:09, 28 February 2011 (UTC)
• Support as independant useright Sounds like a good idea to me. I would be more then happy to do work with this--Guerillero | My Talk 14:52, 2 March 2011 (UTC)

Implementation Proposal: Three month trial as userright

While it hasn't been a week yet, there is an overwhelming consensus to do this, and there are three suggested methods of doing so, as a straight up user right, as part of the autoconfirmed package, and as part of some other rights package. The third option does not necessarily have to be the already panned accountcreator right, it could be another one, however no one has suggested one that received support. Therefore, I'm going to make a proposal that encompasses both of the more accepted ideas.

Since this would be such an easy changeover to make, I suggest that we start off on March 1 by making filemover a requestable userright. The threshold would be that the requesting user can demonstrate a history of either a high level of substantive and useful work in the file namespace, a number of substantive and useful file page move requests, or a history of substantive and useful page moves, as well as the general trustworthiness component that goes with all userrights. This would be on a request only system for three months (all of March, April, and May.) on June 1 another RfC will be opened to assess the successes and failures of the trial, analyze any abuse if it occurred, and decide on whether or not to expand the right to all autoconfirmed users. That seems like a sensible compromise to me. Thoughts? Sven Manguard Wha? 22:41, 24 February 2011 (UTC)

• Support I see no reason why this shouldn't be implemented. I think we should address the oppose votes above in that they give incredibly valid concerns about why this shouldn't be bundled with another right. I don't think there is any harm letting this be its own right but if we put it in with the account creator right, we are asking for trouble. I know that the support votes above didn't really address bundling the right, but I feel as though Delirious and Promethian's worries are quite valid so we should take them into consideration when deciding whether or not to bundle this. Kevin Rutherford (talk) 01:27, 25 February 2011 (UTC)
• Support with a suggestion that confirmed filemove activity on another wiki like Commons be considered as a part of the process.   — Jeff G.  ツ 03:45, 25 February 2011 (UTC)
• Let's not bundle this for now. Let's also not bother with a follow-up RfC; this isn't going to be controversial, and I don't think we need to worry about expanding it to anyone (it's not a big backlog or anything, and Commons' system works fine). I say, go for it but have a drafted policy page up first. Who wants to start that at Wikipedia:Filemover? /ƒETCHCOMMS/ 03:52, 25 February 2011 (UTC)

I agree strongly with FC's request to have a solid (and agreed upon) page put together before we go live. I ripped the heart out of a copy of the autopatrolled page, stuck in a couple different numbers I made up out of my own head, just to have something to start from. Heck, I've used file stuff so rarely that my usage of terms around it is probably not idiomatic. Sven, FC, folks, could someone take a better shot at mine at what the guideline for granting this userright should be? --j⚛e decker^{talk to me} 04:27, 25 February 2011 (UTC)

I had the same idea but didn't act upon it. As far as it how it reads, it's pretty good right now, as it was written by file people on Commons, I'm sure. I've been tweaking it, but yeah, it'll work. Sven Manguard Wha? 05:52, 25 February 2011 (UTC)

• Oppose as process creep. I don't think anyone has actually said why this is or might be more dangerous than regular pagemoves. Why go through this elaborate process, or even a minor process like keeping it as a requestable right when there's no actual justification for it? Mr.Z-man 05:09, 25 February 2011 (UTC)
  • There might not be justification for it not being a default, we'll find out during the trial. I would note, however, that almost no one agreed with you when you brought this up the first time, so I'd say that at the moment, there are at least some reservations about just opening the floodgates. Sven Manguard Wha? 05:52, 25 February 2011 (UTC)
    • Did anyone disagree? And if they did, did they provide any reasons? This looks like a convoluted attempt at a pre-compromise to satisfy one side of a possible dispute that may not actually exist. We should start with the simplest possible proposal, then add extra processes iff we don't get consensus. Mr.Z-man 16:06, 25 February 2011 (UTC)
      • I just disagreed, but I might be completely off-base in my concerns. See below. --j⚛e decker^{talk to me} 21:52, 25 February 2011 (UTC)
• For whatever it's worth, I'm mostly with Mr.Z-man on both posts he's made to this thread. If people abuse moving abilities (vandalising or whatever) we have ways to deal with it currently (warning, blocking, etc.). I don't see how moving local files should be too much of an issue. Commons is a different matter because it serves content to all of Wikimedia's wikis (in their various languages, etc.) as well as any wiki running MediaWiki with the proper configuration to use Commons' files. Moving files on enwiki shouldn't be something you have to jump through hoops to be able to, especially since the ability is readily available. Killiondude (talk) 07:44, 25 February 2011 (UTC)
• Weak oppose for now per Mr.Z-man's argument. There really is no need for a whole new userright. However, this could will lead to more vandalism (i.e., file move vandalism) as a result of bundling with autoconfirmed. Guoguo12--Talk--  21:17, 25 February 2011 (UTC)
• Support I'd like to answer the concerns of a few of the opposers and explain my (possibly incorrect) concern about attaching this to autoconfirmed. As I understand it, and you are all encouraged to mock me if I've got this wrong, files such as image files essentially share the same space of names between Commons and Enwiki. It is my assumption that in the case of a conflict (that is, the filename existing on both Enwiki and Commons), that articles asking for a file that exists in different forms on both will pull the Enwiki version. The concerning scenario for me is a filemover renaming a file that did not previously exist on Enwiki but to a filename of a different image that already exists on Commons. This is not so much a matter of vandalism (although that could happen) but simply of namespace collisions. Some article, Cats We Love uses Commons/MyCat.jpg. An Enwiki user moves JoeTheCat.jpg to MyCat.jpg on Enwiki. The Enwiki article is now broken (showing the wrong image), and the user who broke it doesn't know he or she has broken the article, and the user who broke it doesn't have the ability to fix the problem they created without an administrator to fix it. Do I have that right? If I have it wrong, and there aren't other unforeseen circumstances, I would support bundling it to autoconfirmed, I'm just not convinced it's precisely as safe as article-move for the above reasons. --j⚛e decker^{talk to me} 21:38, 25 February 2011 (UTC)
  • Only administrators have 'reupload-shared' userright, which allows them to upload a file with the same name as on commons. Users with without this right will be unable to move a file to a target that exists on commons. Ruslik_Zero 18:13, 26 February 2011 (UTC)
    • Ruslik0, to make sure I understand you correctly, the filemove code as it is now, when run on Enwiki, would know to require reupload-shared for files that preexisted on either Enwiki or commons? If that is the case, and the code already works, then that would address my primary concern with the broader proposal. If we can safely give this right to all autoconfirmed users, I'm entirely in favor of it, but I do want to exercise all due care. --j⚛e decker^{talk to me} 18:31, 26 February 2011 (UTC)
      • It should require the reupload-shared right in order to move a file over an existing commons file. (I do not know what you mean by "preexisted on 'Enwiki'".) I have not read the code but it is a reasonable assumption that it should work in this way, otherwise we just discovered a serious vulnerability. (See also below) Ruslik_Zero 18:51, 26 February 2011 (UTC)
        • Okay, let me explain again, and thanks for your patience. Filemover code, when run on Commons, only really needs to check if there's a preexisting file of the same name on Commons to do the appropriate tests. That's one check, at most. When we run Filemover code on Enwiki, we need that code to do two checks: there may already be a file of the same name on Commons, and/or there may already be a file of the same name on Enwiki. Note that the code needs to (possibly) do subtly different things depending on which of the two systems it is run on. You're right to say that if that code doesn't work, that's a serious vulnerability, but not necessarily a vulnerability if the code is only run on Commons. Now, maybe that "just works", and it's quite possible that's the case. It's quite possible that I'm worrying unnecessarily. But I'm not willing to assume that without better assurances. I would love to cheerfully support releasing this to all autoconfirmed users, that is my preferred outcome. But for me to really support the wider deployment, I'll want to hear from a developer or someone else close to the source that that extra code is in place and tested, *or* that filemover is already in place and deployed to all users on another language wiki. (Heck, if Dewiki or the like has been giving filemover to autoconfirmed users already, that would handily answer my concerns.) --j⚛e decker^{talk to me} 19:46, 26 February 2011 (UTC)
          • • Struck the above, Z-man tested the case I was concerned with, the code prevents overwrite appropriately. Ruslik0 and Z-man were correct. --joe decker^{talk to me} 16:38, 1 March 2011 (UTC)

My only concern is in regards to a point Joe raised on my talk page, that Commons and Wikipedia file pages layer. If commons has a file with a specific name, it will appear on all other projects with the same name. Take File:Brown treecreeper jan09.jpg from today's main page. It's a commons image, but it appears on English Wikipedia as well. If you created a page with the same name on English Wikipedia, it would overlay the content on the Wikipedia (that's how the FP tags appear on the local page but not the commons page.)

Now the issue becomes what happens if someone moves a different image into something with the same name as a Commons image. I honestly don't remember at the moment what it does, but I'd have to assume it would be a mess.

Finally, if we do allow file moves for all autoconfirmed users, we must remember to protect file pages locally as well as on commons when they appear on the main page, which isn't always done right now, even though it should be. Sven Manguard Wha? 21:51, 25 February 2011 (UTC)

• Support: I however would like to see it be its own group, not all bundled with Account Creators, that is the worst idea I have seen yet. I speak for me and probably most of the team when I say, we are here to create accounts, that group identifies us. We don't need a non-related right bundled with us. It also allows others to get Account Creator and not use the account part of it, which allows us to override lots of restrictions, which is dangerous for users who do not need it.  JoeGazz  ▲  03:21, 26 February 2011 (UTC)

• Support. I understand and respect Mr.Z-man's position, but I don't see much of a downside to trying it out on a smaller scale (i.e. editors who specifically request the flag) first, rather than just granting it to everyone regardless of whether they need or want the ability to move files, or have any idea when and when not to do so. I've had to clean up after good faith but poorly-thought-out page moves, and cleaning up after good faith but poorly-thought-out file moves doesn't sound like a good use of anyone's time. That's not even considering image-move vandalism, which is a very real concern. 28bytes (talk) 23:11, 26 February 2011 (UTC)
• Support. Agree that it should be in its own group, apart from Account Creators. Swarm ^X 03:48, 1 March 2011 (UTC)

Implementation Proposal: Enable for all autoconfirmed users

Since some people seem to think it's not a big deal, I figured I'd formalize this option. Do see my concern above regarding commons though. Edit: see my vote below. Sven Manguard Wha? 21:51, 25 February 2011 (UTC)

• Strong oppose - no no no bad idea. Users could then overwrite an image that's on commons, which would be a mess to clean up (moving the image back wouldn't work because it would require an administrator to delete the redirect left afterwards). IIRC, they can't do that (anymore) just by uploading a file on enwiki. Not to mention the disruption caused by multiple moves would be more significant. Take File:Evolution-tasks.png (now deleted) for example
  • In November, it had 5000 redirects (I'm sure there are images with more, but this is the only one I know of). Now say an autoconfirmed user comes along and moves the page, and then vandalizes the redirect to a giant penis.
  • The Mediawiki software must now render all 5000 of those pages again. This probably creates an ugly burden on the software.
  • 5000 pages now all have a giant penis image on them. This is far worse than 5000 redirects, because users don't immediately click the redirect, but they do immediately see the image.
  • A non-admin cannot undo this vandalism. The user will have to place a {{db-g3}} tag on it (whereby the 5000 pages will again be rerendered and this time break the image altogeter) until an admin comes along and can undo the vandalism.
• Additionally, there are problems with overwriting images that exist on commons. For anybody who's been here for a while, they will know that there are enough clueless editors that don't pay attention to message boxes like "pretty please make sure you know what you're doing before you overwrite the commons image." This could create all sorts of mess for an administrator to clean up, as the admin would have to move the file to a correct location, delete the underlying redirect, then sort through the existing transclusions to figure out which ones are correctly pointing to the commons image, and which were pointing to the incorrectly moved image, and change the latter by hand.
• This is a bit that should only be given to users that really really know what they're doing (like it is on commons), and which can be revoked due to poor management or mischief. Magog the Ogre (talk) 23:44, 25 February 2011 (UTC)
  • If users can move over an image that they can't upload over, that's a bug that should be fixed. The rest of the issues are not specific to files. For the case of an image used in 5000 pages, the same thing could happen for a template used in 5000 pages. The solution there is to protect the template, why would it be different for an image? Mr.Z-man 00:45, 26 February 2011 (UTC)
  • Which is why we protect those templates. It sure would be an unnecessary burden to have to protect a bunch of images. Frankly, this is a bad idea guys - moving files should only be done with the utmost care. And n00bs are far too careless with this sort of thing. Magog the Ogre (talk) 03:23, 26 February 2011 (UTC)
    • Why does it need to be done with more care than moving any other type of page? If this vandalism risk is actually real, any non-commons image used in hundreds of pages should already be protected because any autoconfirmed user can already vandalize them in a much less convoluted way, by simply uploading a vandal image over them. Do you have any evidence to back up your assertion than new users are too careless with moving pages? There are currently around 100 local images used in more than 500 pages that are not currently protected. The "burden" of protecting these would be minimal. Not that it's necessary though, since there's already over 5000 templates that are used in more than 500 pages that are not protected that we don't seem to have any significant vandalism problems with. Mr.Z-man 17:38, 26 February 2011 (UTC)
• Support, in consistency with my oppose !vote above. Mr.Z-man is right again; image moving should be be consistent with page moving. Guoguo12--Talk--  01:29, 26 February 2011 (UTC)
• Support. Filemoving was assigned to administrators only for testing purposes. It has always been an assumption that once all bugs are fixed the ability to move files will be given to all autoconfirmed users. Ruslik_Zero 18:26, 26 February 2011 (UTC)
• Support - There are no serious risks associate with this that can't already be exploited by regular uploading or moving non-file pages. Pagemove vandalism is an uncommon event and there is no reason to think that there will be a major uptick with the ability to move files. Mr.Z-man 19:41, 26 February 2011 (UTC)
  • Actually, there are. I'm not concerned with vandalism, I'm concerned with people moving images to areas where commons already is using the name, thus blocking out the commons name. Please read the comment above by Magog. This has the potential to cause massive messes, and it's worrisome. If it were a choice between only admins having the right and everyone having the right, I'd choose only admins. The middle ground of a userright is acceptable because in order to get those rights the users have to display clue. Again, I'm not worried about malice, I'm worried about well intended people that don't know how the commons/enwiki interaction works moving things in spite of the warning and messing things up. Sven Manguard Wha? 21:10, 26 February 2011 (UTC)
    • See the comment by Ruslik0 in the section above. This shouldn't be possible, and if it is, it's a major bug that should be fixed before it's given to anyone. Mr.Z-man 21:59, 26 February 2011 (UTC)
      • What would convince me, and might settle this for one or two other people, is a developer or someone familiar with the code saying "yeah, we tested and/or deployed this on a system that isn't Commons", or other evidence it's been deployed outside of Commons, (any system where the code would have to check both for overlapping names locally and separately on Commons). Or a developer saying "yeah, that needs to be fixed, but it's a one-liner and I've got it covered." Any idea of how to approach getting that reassurance? Because we're that close to my supporting the wider release. Sorry to be a pain, but a full-scale zero-to-few hundred thousand users deployment better be precisely right before flip the switch. (Which sounds like a sentiment we're in complete agreement on, we're just quibbling about a few details.) --j⚛e decker^{talk to me} 22:22, 26 February 2011 (UTC)
• Strong Oppose Serious concerns over inexperienced users causing damage due to the overlap issue discussed above and at my talk page. Sven Manguard Wha? 21:04, 26 February 2011 (UTC)
• Second Choice Support While I'd like the comfort of being able to test it for three months as an unbundled feature, (as it right now has never been separated from the 'reupload-shared' right anywhere except for on commons where 'reupload-shared' is moot,) I agree that without the 'reupload-shared' tag, this can't do too much harm. Now mind you we had better make sure that everything works right or there's going to be some chaos. Ultimately, my primary concern is with things that need to be done getting done, so this, I guess, is acceptable. Sven Manguard Wha? 05:52, 28 February 2011 (UTC)

  It may be that the code protects against that issue, we just need to actually get a real answer as to whether it does or not. --j⚛e decker^{talk to me} 22:24, 26 February 2011 (UTC)

  The answer came from Magog, and is on my talk page. From there "If you try to move a file over one that exists on commons, as an administrator you will get a warning about moving on top of a file that exists on a shared repository. If you click continue anyway, it will move it on top, and the underlying file is no longer visible to enwiki. An administrator can undo this by deleting the existing file, or moving the file and suppressing/deleting the redirect. If non-administrators were allowed to move files, they would not have the ability to undo this, because they would have to tag the subsequent file as {{db-g6}} with an explanation."

  So as you can see, it is a problem. Sven Manguard Wha? 22:52, 26 February 2011 (UTC)

  Administrators have a right (reupload-shared) that allows them to upload over a commons file locally. Other users do not, so they shouldn't be able to move over a commons file. Mr.Z-man 23:01, 26 February 2011 (UTC)

  I just checked on my local test wiki; users without the reupload-shared permission cannot move over a file on a shared repository (Commons). Users with the right (admins) get a warning but can override it. Mr.Z-man 23:23, 26 February 2011 (UTC)

  Rockin'. You have my support, then. --joe decker^{talk to me} 06:47, 1 March 2011 (UTC)

• Oppose, partly per Magog the Ogre's concerns. I support Sven's proposal of granting this right on request, rather than to everyone regardless of whether they want it, need it, or know how to use it. Maybe there wouldn't be any problems granting it to all autoconfirmed users, but why not try it out in "pilot mode" first with a smaller group of editors, to uncover and fix any potential issues? I'm concerned that there are things we're not fully considering here, especially regarding potential image-move vandalism. Is someone going to move-protect all the images on the bad image list, for example? I think that's the kind of thing that ought to be considered and decided before expanding the right to all autoconfirmed users. 28bytes (talk) 23:21, 26 February 2011 (UTC)

  All significant technical bugs should be worked out by now; the feature has existed in MediaWiki since January 2009. I'm not sure when it was enabled for admins. There are only 25 images on the bad image list that exist locally (the rest are on commons), so it would not be difficult to protect them. But as I said above, evidence shows it isn't necessary. There are over 5000 templates that are used on more than 500 pages (2 are used on more than 100,000) that aren't protected above semi-protection. Yet, amazingly, they're not targets for vandalism.

  Additionally, if we only give it to people who demonstrate competency when dealing with images, what useful information does that give as to whether it could be turned on for all autoconfirmed users? It's like having a new software interface tested by computer programmers. Their experiences are not going to be very relevant to determine how the general public will react, unless it's so bad that the experts can't use it. But we already know it's not from the rather extensive testing by admins and filemovers on Commons. Mr.Z-man 23:42, 26 February 2011 (UTC)

  All reasonable points. Personally, I'd prefer the right be given to anyone who asks for it rather than people who've demonstrated proficiency; that wouldn't stop vandals, but it would hopefully slow people down who just don't know what they're doing. I've just spent the last couple of days clearing out "== Headline text ==" and "== Heading text ==" from articles, so there is a legitimate concern, I think, about the cleanup that would be required if we enable it by default. 28bytes (talk) 23:51, 26 February 2011 (UTC)

  That's not really a good comparison. Adding "== Heading text ==" in an article is a single button on the toolbar that even an anon can do. Test edits like that are rather common. Users would still have to be autoconfirmed to move an image, so presumably the desire to just randomly press buttons would be much less once they've already created an account, made 10 edits, and been here for 4 days. The easiest way to determine how much cleanup might be required would be to look at how often regular pages are moved incorrectly by people who don't know what they're doing. Mr.Z-man 00:05, 27 February 2011 (UTC)

  I wonder if there are stats available someplace to show reverted page moves. That wouldn't show bad moves of pages that didn't get noticed, of course, but it might be a useful data point. 28bytes (talk) 00:26, 27 February 2011 (UTC)

• Oppose for now, at least. The issue with moving files is that, to prevent an overwhelming number of useless file-space redirects, we'd need to have all images re-linked (I think this is protocol on Commons?); there is no need to get "exact" titles for files, unlike article titles. Simply put, for most files there is no reason to rename them, other than to create more trouble in the future. Yet, I find it difficult to believe that users will abide by a policy that says, "Do not rename File:RandomBuildingUSA.jpg to File:Random building in the United States.jpg" because it defies common sense at first sight. There's no need, really. /ƒETCHCOMMS/ 21:33, 27 February 2011 (UTC)
  • What? Who cares if there's redirects in file-space? That said, we trust that users will abide by every other policy that exists. Why are non-highly-experienced users so inherently untrustworthy when it comes to file moving that we're practically throwing AGF out by saying "We don't trust you to not screw it up"? I asked a similar question before and never got an answer. Mr.Z-man 22:12, 27 February 2011 (UTC)
    • I'm going off commons:Commons:File renaming, which says "In general, Commons aims to provide stable file names as there might be external file clients and file moving involves significant human and computing resources. Thus renaming should be used with caution." I see no reason why enwiki should not aim to provide stable file names as well (although we don't support several hundred other projects). Also, I think too many useless redirects are bad because commons:Template:Rename directs users to have a bot delink the files in addition to the rename—and if redirects weren't an issue, I don't know why this would be a real problem. Non-highly-experienced users are so inherently untrustworthy because I have seen so many of them not bother to even read policy before doing a score of bad actions, and because my own experience shows that there is so little need for moving files (compare the rename category with RM) that we simply don't need to give it to almost everyone. I don't trust many users with this, just like I don't trust them to rollback or adminship, either. My experience with some users must differ from yours. /ƒETCHCOMMS/ 17:52, 28 February 2011 (UTC)
      • You basically say why we don't have as much of a need to provide stable file names - we don't support hundreds of projects. If people on other sites want to hotlink our images, they already do so at the risk that they may be deleted with little warning. Your argument mainly seems to be "we should do it this way because Commons does it this way." Having a bot go around and bypass the redirects is just stupid. I have no idea why Commons is doing that. If that bot is running on enwiki, it should be blocked immediately for a blatant violation of the bot policy. The "human resources" to move a file are exactly the same as to move any other page, so that doesn't even make sense. If server resources are an issue, the sysadmins will tell us. There's little need for lots of things, but outside of an actual risk, that isn't a good argument for restricting them. This is a wiki, it should be as open as possible. Mr.Z-man.sock (talk) 17:21, 1 March 2011 (UTC)
        • How are double redirects handled in filespace? I can foresee a user moving A.jpg to B.jpg and someone else moving it to C.jpg. Will the image stop appearing on articles that use "A.jpg" when they do that? 28bytes (talk) 18:20, 1 March 2011 (UTC)
  • Yes, I believe the image will stop appearing. I'd just like to see a trial of this with a separate user group, first, before letting all autoconfirmed users do it, however; it seems like a reasonable compromise. /ƒETCHCOMMS/ 04:02, 2 March 2011 (UTC)
    • Yes, file redirects function exactly like article redirects, but we have a bot that fixes them. Ruslik_Zero 20:05, 2 March 2011 (UTC)
• Weak Support per the test of Mr.Z-man - giving this right here is safer to English Wikipedia than giving this right on Commons, and we need to AGF. People do upload files with really bad names, here and on Commons, and we don't have enough admins (or enough attention and inclination from current admins) to deal with such files (dealing with the uploaders is a separate issue). That having been written, the ability to track what the filemovers have done (via the log requested in bugzilla:27709) would be really helpful before implementation.   — Jeff G.  ツ 03:35, 28 February 2011 (UTC) "Weak" in favor of enabling for rollbackers below.   — Jeff G.  ツ 03:58, 28 February 2011 (UTC)
• Strong Support I'm against elitism here, and Mr Z-man has shown that the major concerns are non-issues. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 04:08, 28 February 2011 (UTC)
• Oppose This can make a bigger mess than moving pages, with having to consider Commons conflicts. I'd honestly prefer a separate flag, so we don't end up hacking another flag like account creator already is to let folks mess with edit notices. Courcelles 06:39, 28 February 2011 (UTC)
  • See my discussion with Sven above. There is no issue with Commons conflicts. Mr.Z-man.sock (talk) 15:51, 28 February 2011 (UTC)
• I think it was already intended to be this way eventually. Support. PeterSymonds (talk) 08:19, 28 February 2011 (UTC)
• Listen to Mr.Z-man. There's no reason to have a new user group and there's no reason that moving files should be any different than moving pages. --MZMcBride (talk) 08:23, 28 February 2011 (UTC)
• Per Mr.Z-man's posts (and what I said above). Killiondude (talk) 08:31, 28 February 2011 (UTC)
• Oppose Would prefer a separate flag with a trial run, see my support in the above section. Swarm ^X 03:51, 1 March 2011 (UTC)
  • Your original post commented on the potential misuse (vandalism). Well currently any autoconfirmed can misuse pagemove abilities in any namespace besides File and Category (and MediaWiki, unless you're an admin, of course). It doesn't make much sense to oppose on those grounds if they can move articles, etc. Meh. Killiondude (talk) 06:19, 1 March 2011 (UTC)
    • The potential for misuse is the same as page moves now, which is precisely why I refactored it ("rewd" meant "reword", though I can understand if it came off as "rude"). I still base my opposition on the fact that I would rather see a trial run in a more limited scope, if you'd like to reply to that position you're more than welcome to. Swarm ^X 19:52, 1 March 2011 (UTC)
      • That's not really a position that can be argued against. Now that you've removed the bit about potential damage, you're arguing for a limited trial, but you're not saying why we should do that instead of this. Mr.Z-man 02:08, 3 March 2011 (UTC)
• Support, as my concern is apparently unfounded. For those who missed it, Z-man tested the case that concerned me, and (barring being an admin or a reupload right), filemovers on wikis like are not permitted to move files to destinations whose name matches an existing file on Commons. --joe decker^{talk to me} 06:58, 1 March 2011 (UTC)

Implementation Proposal: Enable for all rollbackers

It's dead. Drop the stick and step away from the horse.
The following discussion has been closed. Please do not modify it.
This would be a middle ground. We already trust rollbackers more than autoconfirmed users, and autoconfirmed is such a low hurdle. If this goes well, we can always extend to autoconfirmed users.   — Jeff G.  ツ 03:58, 28 February 2011 (UTC) Oppose File moving is not related to anti-vandalism efforts. If the community opposes bundling as per above, I see no reason for this bundling either. /ƒETCHCOMMS/ 17:45, 28 February 2011 (UTC) Oppose. I appreciate the intent behind the compromise proposal, but as above, I don't see bundling with an unrelated right as ideal. 28bytes (talk) 18:01, 28 February 2011 (UTC) Oppose. Finding similar trust levels makes sense, but rollbacking isn't really related to file moving. Guoguo12--Talk--  21:29, 1 March 2011 (UTC) Oppose - no need to bundle things when they can remain unbundled. Especially something that requires wildly different skills. Magog the Ogre (talk) 21:56, 3 March 2011 (UTC)

Implementation Proposal: One week testing period as userright then automatically enable for all autoconfirmed users

Withdrawn Idea
The following discussion has been closed. Please do not modify it.
I might be getting needlessly complicated, but I'd like to propose yet another compromise that will hopefully make everyone happy. If nothing changes right now, my guess is that filemover is going to become enabled for all autoconfirmed users. Since Wikipedia from a technical standpoint is unique from other wikis, even those sharing most of the code, things are a bit less fragile than they appear (see the recent signpost artilce on the HTML5 conversion if you have any doubts.) What we're proposing has never been done before, and could therefore break in unexpected ways. I think, therefore, that giving a dozen or so users a week to do testing (with a mandate to intentionally push the boundaries and try to break stuff) will give the people worried about the technical or logistic aspects the satisfaction that they need, and will give the plurality calling for the filemover right to be released to all autoconfirmed users the outcome they desire. This option would also give the coders any grace period they need. To make things clear. At the end of the week, barring the testers coming back and reporting a list of things that are broken (which mind you would be discovered anyways if we don't do this, but in a less controlled setting) the changeover to all autoconfirmed users would happen automatically. The testing phase would be available to anyone that wanted in, however they would be asked to log (somewhere centralized) anything that might be a problem. I know a few admins have mopless alts for public computers, those would be welcome as well. Really this is the equivalent of sending a test vehicle across a newly built bridge. Every responsible business or institution does this, precisely because the earlier problems are found the less costly they are to fix. The last thing I want to see happen after all this is for the floodgates to open only for the right to get taken back after something big breaks. Thoughts? Strong Support Sensible, ensures stability while delaying consensus only a week. It's waited years, we can afford a week to make sure things get done right. Sven Manguard Wha? 07:30, 3 March 2011 (UTC) Oppose - There's no way it'll actually go this smoothly, config changes often take weeks or even months before they're implemented. It's also unnecessary. File moving is not a new feature. It has been in the software for more than 2 years and has been tested rather extensively since then by developers, admins, and filemovers on commons. It was considered relatively stable enough to include in the 1.16 release of MediaWiki 7 months ago. I highly doubt we would learn anything new in one more week of testing. Mr.Z-man.sock (talk) 19:25, 3 March 2011 (UTC) I was worried that it was never used on a WMF project apart from it's related suite of tools, except for on commons which operates differently. Also I'm pretty sure that the implmentation for this would take, oh, 37 seconds to do. X! showed me what had to be done, it was just changing four lines of text. Either way, withdrawn. Sven Manguard Wha? 20:28, 3 March 2011 (UTC)

Compromise

It is actually possible to create a separate usergroup for filemover, which is automatically assigned (and implicit) as the autoconfirmed usergroup. However criteria may be more stringent—for instance, 30 days and 100 edits. These can be tweaked later. In the future we can get rid of this usergroup if everything goes smoothly. Ruslik_Zero 20:10, 4 March 2011 (UTC)

That's even more complicated than what I had proposed and then withdrawn. The discussion on implementation is set to close today anyways. Besides, my initial proposal was a compromise, and it didn't go over as well as opening it up to all autoconfirmed users did. Sven Manguard Wha? 20:24, 4 March 2011 (UTC)

Closing summary

There's essentially a unanimous agreement to extend the ability to move files to more people than just administrators. The bigger question is whether we should grant it to all autoconfirmed users or create a separate usergroup. There seems to be no solid consensus on the former, so I think it is appropriate to choose the more conservative of the two—creating a new usergroup for this. Perhaps in some months, we can reconsider Ruslik0's proposal. But for now, someone who knows how should file the appropriate bugzilla request to create a new usergroup with the ability to move files, similar to how Commons does it. NW (Talk) 04:12, 8 March 2011 (UTC)

How to Attract Thousands of New Editors

Why don't visitors edit? Figure that out, and our cup will runneth over.

My friends all think:

• 1. "Because it's edited by anybody, it's mostly just made up."
• 2. "Some mysterious body within Wikipedia vets edits."
• 3. "It's a profit organization."

Survey visitors about Wikipedia with open questions, and I think they will all say exactly that: It's not credible. How it works is unknown. It's a company that is out to make money.

My suggestion:

• Enlighted them, and sneak in a step-by-step of how to make an edit.

• Get the visitor to make a single edit, THEN, help that editor improve.

• Do that by thinking like an advertising agency: Sell it! Make it ADD-friendly, just like this proposal.

• Put a banner at the top of every page:

WHAT YOU DIDN'T KNOW ABOUT WIKIPEDIA

Link it to a page that is "for dummies" - short and sweet, easy read:

WHAT YOU DIDN'T KNOW ABOUT WIKIPEDIA When somebody adds something, other editors check to see if it's true. If not, it is deleted. There is no committee that checks contributions. Wikipedia is just a bunch of editors. Wikipedia is nonprofit. How to add something made easy: 1. Take the info from a good site: "Apples grow on trees." from www.apples.com/apple-trees.html 2. Rephrase it: "Apples come from apple trees." 3. Click "edit this page" at the apple article. 4. Paste in "Apples come from apple trees." 5. At the end of the sentence paste in: <ref>www.apples.com/apple-trees.html</ref> 6. Click save. 7. You are now a Wikipedian.

Anna Frodesiak (talk) 14:02, 23 February 2011 (UTC)

Re: "1. "Because it's edited by anybody, it's mostly just made up."" - I've seen a lot of that in various forums I frequent. A lot of people only accept knowledge from "authority", and they assume that because Wikipedia can be written by just anybody, it can't be trustworthy. -- Boing! said Zebedee (talk) 14:07, 23 February 2011 (UTC)

Right! So educate them without a wall of text. It's still the MTV generation. Lots of enthusiasm, but zero attention span. They don't read lectures on the truth of Wikipedia. But they will read slogans.

Yep, short and snappy messages get the eyeballs where long-winded essays don't. -- Boing! said Zebedee (talk) 14:27, 23 February 2011 (UTC)

Do you really think people with an attention-span of zero can be constructive and useful here? Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 14:36, 23 February 2011 (UTC)

Comment: Wikipedia doesn't advertise, except for itself to raise money to survive. But what we need is an army of new editors. Where is the advertising for that? So many visit yet relatively few editors join. Harness that immense visitorship. Draw them in with a snappy banner. They just need very simple instructions to make their first edit. Then they will make a second, etc... Anna Frodesiak (talk) 14:19, 23 February 2011 (UTC)

The people who still believe 2. and 3. are the people who believe Obama is a Muslim and the earth is flat. Neither slogans nor dissertations will change that. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 14:31, 23 February 2011 (UTC)

I'm not sure about whatever that thing is above, but I really like the idea of conducting a general survey to visitors, and using the data to work out a way to attract people to edit Wikipedia and correct some of the misconceptions of Wikipedia that are out there. We make so many assumptions; let's see what the masses really think. I think devising a suitable survey would indeed be the best place to start. --Dorsal Axe 15:18, 23 February 2011 (UTC)

I like it. My friends and family all have similar misconceptions. As for the counter-suggestion I'm not a big fan of surveys. Wikipedia's generally been most successful when it didn't conduct itself as a corporate mass. Let's just act on what we all know to be true already rather than conducting market research. IMHO. Equazcion ^(talk) 15:22, 23 Feb 2011 (UTC)

(edit conflict) Why not notify the people at Wikipedia:OUTREACH? Also, I suggest we make the advert a bit less flashy and obtrusive. ManishEarth^{Talk • Stalk} 15:29, 23 February 2011 (UTC)

I'm against putting that banner on Wikipedia pages. Yes we have attraction problems, but numerous editors I've talked to, among them members of WP:CONTRIB and a smattering of arbs, all say that the biggest issue we have with attracting editors is that we treat them so poorly. We need not just to get out the word about what Wikipedia really is, but make it easier for new editors to feel like they fit in and be less hostile towards each other as a whole. Since civility blocks are looked down upon, we need some other option, or a combination of other options. I've heard quite a few and some of the better ones include being much stricter on 3RR, pushing mediation heavily, and putting tighter controls over the IRC wikipedia-en-help channel, which often does more to scare off users than it does to help them. Just some thoughts. Sven Manguard Wha? 15:49, 23 February 2011 (UTC)

If you're acknowledging the attraction problem I'm not sure why you'd be against remedying it, despite there being another more prominent problem at hand in your eyes. Just cause we're out to fix one thing with this particular suggestion doesn't mean we'd be abandoning others. You haven't really given any reason that you're actually against a banner like this. Equazcion ^(talk) 16:02, 23 Feb 2011 (UTC)

Because you are solving problems out of order. Opening a big, welcoming door for a bunch of potential new users does no good if that door is placed on the edge of a cliff. As far as a survey banner goes, I've no opposition to one, but man, something less gaudy than that, please! Resolute 17:00, 23 February 2011 (UTC)

We're too far from solving the civility issue to allow it to hold up expanding the project in general, if that issue can even be said to be solvable at all. So we attract a thousand new editors and a certain percentage end up staying after seeing the community's flaws. Still means we end up with more editors. We can work on becoming a perfect society at the same time too. Equazcion ^(talk) 00:16, 24 Feb 2011 (UTC)

The banner is only one line, but it certainly is RED, isn't it? Maybe tone down the color? But, heck, it is only ONE LINE. Under my proposal (below) it wouldn't have to run on all pages anyway. Sincerely, GeorgeLouis (talk) 19:39, 23 February 2011 (UTC)

• Agree. Add the above banner to randomly selected pages for a time, then do an automated survey to see how many people click on its links. It might be possible to also see how many of those IPs log in again and edit a page and follow to see how many convert to named editorships. Do several versions of the banner to see which one works best. I agree that short, snappy marketing sells. Look at the ads on Facebook for confirmation. User:Anna Frodesiak gets a barnstar from me. A friend to all, GeorgeLouis (talk) 16:31, 23 February 2011 (UTC)

  See also {{Invitation to edit}}, being trialled on medical pages. Fences&Windows 01:35, 24 February 2011 (UTC)

  Would be nice in a custom welcome template for some users Ottawa4ever (talk) 14:37, 24 February 2011 (UTC)

Really wanted?

• OK, I'll be the bad guy here: Do we want an influx of new editors? Now, OK, granted, we certainly don't want to turn people away. Every time that I see someone talking about how the sky is falling because our registration numbers are decreasing, I can't help but wonder... do we really want the "AOL crowd" to come rushing in? Now, before anyone goes ballistic on me, I want to say up front that I believe that I'm more accepting of new editors then most. Call me egotistical if you'd like, but I've seen the "massive influx of new users" several times in the past, and 9 times out of 10 it's a net negative.

What's the answer then? I'd add my voice to those above in saying that the problem is simply how we deal with new users. We collectively need to institute an attitude of acceptance among ourselves, somehow. Slow, steady growth is what we need. However, slow steady growth in registrations is the wrong metric to be seeking. We need slow steady grown in the number of en.wikipedia "heavy editors" (defined as those who make... I think that it's 100 edits/month, now?).
— V = IR (Talk • Contribs) 23:25, 24 February 2011 (UTC)

Are there any concrete stats about the historical effects of a user influx? I know there's the perceived negative aspect, but it might be the case that more users simply means more idiots as well, and thus it seems like a failure, when it might actually be that the benefits outweigh the downfalls, but they are just not as visible.

In any case, I think that teaching readers about how editing is easy is a generally good thing. A good tie in with this program would be to make a thank you message for anon users after they edit, as well as a link to register an account. It could very well do this now, I don't know, but it seems like everyone likes to be thanked, even by a machine, and registered users are probably way more likely to recontribute. Once they make an account, then they're hooked, we give them a welcome message from the good will committee, and then shebango, we turned a reader into an editor.

It sounds simple, but I think the basic concept is there. Entice them with how easy it is to edit, thank them and ask them to register an account, and then welcome them to the wiki with some basic instructions on how to get involved in specific areas. --NickPenguin_(contribs) 06:23, 26 February 2011 (UTC)

I gathered some stats last year about new user retention. See User:Mr.Z-man/newusers. The majority of new accounts never make a single edit. And of the ones who do, only a few percent actually stay around and become regular editors. Mr.Z-man 16:21, 26 February 2011 (UTC)

If anyone wants concrete stats on new user activity, then this might help (It's not entirely relevant, but it gives you a rough idea). I help out at WP:ACC. Out of the 50-odd accounts I've created , one reverted one instance of vandalism , another wanted help with the API, and a third actually got around to create an article which got AfD'd. If you want better data, check out January's account creation log for blue "contribs" links. ManishEarth^{Talk • Stalk} 13:07, 26 February 2011 (UTC)

Well, it looks like from those stats, roughly 2% of editors stick around once they've registered an account, regardless of wither their first edit is kept or not. That's a pretty small number. So roughly for every 10,000 registered users, we get maybe 200 from the bunch that stick around to become semi-regulars, and an unknown number of those ones become heavy users.

If my rough evaluation is correct, then if we can raise our retention level by a percent or two, then we can gain a couple hundred users each go. So in order to increase regular users, we would have to: increase the sheer number of registered users and/or figure out how to entice people who register an account to stay. The first bit can be done with a message like Anna Frodesiak suggests, the second bit, we might need to have some discussion on.

I think if new users immediately saw the wiki as a community as opposed to a bunch of people working independently at their computers, they would be more inclined to stay. I myself made an account in 2005, but I didn't start editing regularly till two years later when I saw that template:trivia was nominated for deletion, and I got involved with the discussion. Then I saw that it wasn't a bunch of articles, it was a bunch of people, and it became fun, like a game. --NickPenguin_(contribs) 17:10, 26 February 2011 (UTC)

Note that that's 2% of users who stick around after making at least one edit. If you include the users who never made an edit, it's 0.68%. Mr.Z-man 17:31, 26 February 2011 (UTC)

The "community" aspect is something that I think we should highlight more often. The best part about doing so is that it really doesn't require much in the way of changes. Some technical changes (the first thing to come to mind would be Liquid Threads) would assist us handily in being more "social". Unfortunately, there's a rather ingrained field of thought here; including a rather extensive "institutional memory", if you will; against such sociability. The most common refrain can be paraphrased with something like: "If it doesn't directly affect the mainspace, then it's a waste of time and resources." So, historically, social networks revolving around Wikipeida has largely been pushed off-site. Even more unfortunately, it seems as though the more... shall we say, "hostile elements" to the goals of Wikipedia are the social groups which seem to prosper in such a manner. It's a shame really.
— V = IR (Talk • Contribs) 02:19, 27 February 2011 (UTC)

With that in mind, what is really going on with the welcoming committee? The members list seem more than a little outdated, and the welcome page and the committee page have basically remained completely unchanged for several years. This makes me wonder if we are really doing a sufficient job in this area. It seems the nature of the wiki is doing a fine job bringing both readers and editors, but how do you think we can show people enough reason to stay? --NickPenguin_(contribs) 04:27, 27 February 2011 (UTC)

I have a life

I'd like to add my self to the discussion here, but I warn you, I am going to come off like a total bad guy here. Please read objectively though. I'm someone who has been editing since 2006, but I hardly edit at all. I have had peaks in where I edit some articles, mostly based upon some interests like movie awards or wrestling, but I don't think I've ever done "heavy editing" as described above. The main reason is because I have a life. After studying business, I'm currently in my 3rd year of a Biology B.S. and I also have a part-time job, a girlfriend, etc. I have hobbies, I play tennis, I take part in Tae Kwon Do training and I like having time to read books, watch movies, go to the beach and go to my fraternity's awesome parties. My point is that the people who visit Wikipedia aren't editing because they're afraid, they aren't editing because THEY DO NOT WANT TO SPEND THEIR TIME EDITING AN ENCYCLOPEDIA. Yeah, there are some of you out there who have dedicated a grand part of your lives to this website. Some of you go as far as to join the ArbCom and some have north of 100k edits. That's cool for you, but that is not "normal" to everyone else. No one wants to do this. The only people that actually want to do this might chime in now and then because they find Wikipedia interesting (like me), but no one wants to stay editing an encyclopedia. A lot of the editors here think this is the most important thing in the world. They write a lot of articles, get some FAs, run for adminship, fight about wether an article uses to much weasel words, etc. Most of you who comment here, in the Village Pump, you're probably in this category. I'm not knocking you, I like this place and maybe in a few years, I would be interested in adminship, but in no way will I ever live this like a lot of editors do. Sure, I take part in AFDs, I've read most of the guidelines, I consider myself a constructive editor, I like debating article content and I take my time to write a long paragraph in the Village Pump, but I won't ever dedicate whole hours to editing articles like people do here. Even Jimbo only has 1200 article edits. Wikipedia is just a website. Press X and see what happens. Feedback ^☎ 05:09, 27 February 2011 (UTC)

Looking at your contributions, you have over 500 edits since September. If the working definition of a 'heavy user' is more than 30 edits a month, then you're it. And the beauty of it is that you can lead a perfectly functional life, just like the rest of us, and still have a meaningful part in developing the wiki. Now, how do you feel the community would be able to attract more like minded individuals? --NickPenguin_(contribs) 05:33, 27 February 2011 (UTC)

You could say the same thing about lots of things, yet they still manage to attract people. People spend hours and sometimes even actual money playing games like Farmville and Frontierville on Facebook - things that only their friends will see and that have absolutely no consequence anywhere. World of Warcraft has more than 12 million subscribers. The goal is not to get everyone to spend hours each day on Wikipedia (though that would be nice), but to get them to do something. Right now, for every 10,000 accounts created, maybe 70 will still be editing, even sporadically (>1 edit per month), 6 months after they create their account. Mr.Z-man 06:20, 27 February 2011 (UTC)

That's true; but I think the idea behind this comment is more to dispel the equivalent of the Anglo-American notion that every person on earth would gladly and jubilantly assimilate to the Anglo way of life, and most of them just don't know it yet. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 06:57, 27 February 2011 (UTC)

Thread-killer. ;)
— V = IR (Talk • Contribs) 19:52, 1 March 2011 (UTC)

Google

Unless I missed it, one point has not been made here which surely should be made here - Wikipedia frequently has a high Google search. Since Google is probably the only search engine most people use nowadays, surely this in itelf is going to help to attract new editors to the Wikipedia project. ACEOREVIVED (talk) 00:10, 4 March 2011 (UTC)

Why I don't contribute

Hello, I'll add my $0.02 to this, and why I am incredibly reluctant to contribute anything to Wikipedia until some problems are resolved. Please have a look at my user page. People, eg new editors, or existing editors are very much off put by having their stuff deleted. Granted there needs to be guidelines to have good articles, but good articles have to start somewhere, and if Wikipedia's first response is to just delete them, then why even bother? I get that the stuff that I have written may be not worthy about being included in Wikipedia, but there has got to be a better solution than to just delete it; it needs to be mentored by the community. I will further add that my father who is a world renowned Adam Smith scholar made some edits to the Adam Smith article a few years ago that where reverted. Compound this with the nonsense surrounding the Old Man Murry debate. Stuff like that does not advertise well for new editors. This 'deletionist' movement has to be curtailed.

I regularly use Wikipedia to look up various computer and programming information, and while the articles are very much useful to me, they are not always referenced well. Many have signs on them that they could be improved. Could some of the people who are taking the time to put those signs up, take the time to improve the articles? Yet some people edit articles to the detriment of the article _why. _why has significance to the Ruby community, that most newcomers have trouble grasping at first, but notable none-the-less. In short, Wikipedia comes across to new and novice editors as being smug, elitist, cliquey, bureaucratic and generally unwelcoming: "How dare I put an article that doesn't meet all notability and significance requirements." I have also run into problems where I was told because I worked for an organization, I could not edit it. I have a fair few friends who are Veterinary Medical students, who are told flat out by their professors that Wikipedia is a waste of time. Furthermore, when a site like Old Man Murry is deleted, there are a group of Editors/Admins that refer to 'new' people as Sockpuppets or Meatpuppets.

These are real problems that I have witnessed, or experienced myself. I think there needs to a better moderation system for articles, a way to mentor new articles, Wikipedia needs to find a way to be more inclusive, and offer positive feedback to authors. Should new articles be sandboxed somehow until they are of sufficient quality? Recently, I wanted to add an article about Cardinal, a implementation of the Ruby Programming Language on the Parrot Virtual Machine. It was a start of an article, but I don't have a day to sit down, plan and write it out, so I just started it, but my start did not meet the minimum threshold for an article, so it was rejected. Are there some good examples of articles from which to model an initial attempt? I couldn't find any.

It takes work, and it takes time to develop a high quality article. Wiki's fosters collaboration, so promote that, and understand that improving articles is an incremental process that takes time. Perhaps what I had written really belonged in the Ruby_programming_language article? I don't know, it was just declined. My experience so far with Wikipedia has been, on balance, negative. While Wikipedia claims to be an encyclopedia that 'anyone can edit' that has not been my experience, and many others, and this is something that needs to be fixed. Hackbinary (talk) 12:11, 4 March 2011 (UTC)

That's part of the problem, but "don't do that" isn't really a solution. There are hundreds, if not thousands of new pages created every day, but the majority of the reviewing work is done by a small group, probably fewer than 20 people. Though you did identify what I've thought to be one of the key problems – we basically encourage new users to write new articles, which is a difficult task, then chide them when they (almost inevitably) screw it up. Rather than continuing to encourage people to write articles, I think a better solution would be to get people to contribute to existing ones. From my experience, collaboration really doesn't happen that often. It tends to occur more for well developed articles. For example, in the last 9 days of February, 190,000 users edited 428,000 articles. Of those articles, only 3,400 (0.8%) averaged more than one user per day editing it and only 118,000 (27%) had more than one user in the entire 9-day period. Having more articles is almost counterproductive in terms of fostering collaboration. We have so many more articles than we do active users, it's much easier to work alone than to find someone else to work with. Mr.Z-man 17:29, 4 March 2011 (UTC)

So therein lies the main problem. Wikipedia has the feel of being a bunch of individual editors working mostly independently from the rest. And appears that way because that's exactly how it is. It seems like part of the way to encourage more editors is to encourage more collaboration.

Along those lines, are wikiprojects an effective way to get users to collaborate? From my perspective it seems like most wiki projects start out with a big push, and then 6 to 8 months later they remain relatively inactive as the members move onto other tasks. Or, the project page stays up and a slow trickle of users "join", but with no centralized leadership, just a broadly stated mandate and perhaps a list of short term goals. --NickPenguin_(contribs) 20:43, 4 March 2011 (UTC)

I'd like to highlight Mr.Z-man above: "we basically encourage new users to write new articles, which is a difficult task, then chide them when they (almost inevitably) screw it up." He's exactly correct, of course. More importantly though, this is a symptom of the larger "disease" which we are collectively suffering from. My question is: why in the world do we countenance any user "chiding" any other user, for anything? We're all going to screw something up here, eventually. It's a wiki though, so once the mistake(s) are identified, just fix the dang problem and move on! Quit trying to be "cool", and try actually accomplishing something.

Wikipedia certainly is made up of a bunch of individual editors working individually (except for the occasional, transitory, collaborations on popular/notorious articles). I'm often poking aroudn the Village Pump advocating for the development or improvement of our social resources, and this is the reason why. Wikipedia certainly doesn't need to turn into Facebook, or the like, but the attitude that "anything that makes us more like Facebook is bad for the Encyclopedia" is just as damaging, if not more so at this point, then the "turning Wikipedia into Social Media" bugaboo is.
— V = IR (Talk • Contribs) 03:15, 6 March 2011 (UTC)

So if there was somehow an integrate of the social web into the wiki, in what ways do you think would be most helpful? I mean, taking into account the problems we have now (civility, quality standards and such) and what would most help the wiki in the long run, how could the social web improve the quality of both existing articles and all the new articles being created? Maybe we do need a facebook app, I think one of the main drawbacks of editing the wiki is that it's really a thankless job, there's no better way to get street cred among your peers than showing the quality of the work you do, and the improvements you make. Maybe attaching wiki usernames to social profiles will discourage stupid edits and encourage more positive contributions. It might even encourage competition among peers, or at least bring more awareness to what people do here. When I mention to people I edit wikipedia, some of them are shocked to actually meet someone who contributes regularly. --NickPenguin_(contribs) 03:24, 6 March 2011 (UTC)

I can tell that you're already grasping what I'm trying to say. The only thing that I would adjust is that I don't think that we should directly connect to Facebook, or any other external site for that matter. Within Wikipedia, however, the social aspects could certainly be improved. Talk pages in general desperately need to be updated. I mean really, MediaWiki's default talk page system is straight out of the mid-90's! However, there's already a solution in the works for that issue: Liquid Threads. The only problem there is that, unless forced on us by the Foundation (which I'd be supportive of, but it ain't gonna happen...), the conservative bent of many Wikipedia editors means that Liquid Threads is likely to never be turned on, here. That's sort of a separate issue, though. Really, aside from the technical aspect, the largest issue I see is the disjointed, fragmented nature of discussions on Wikipedia. Granted, I'm used to webforums and message boards (I've been using them since the late 80's, during the dial-up BBS era... [remember Prodigy, or CompuServe? hehe]), so I'm partial to that sort of setup, but something should be done to reduce the "one talk page per regular page" syndrome. The system software itself works to create the "individual editors working mostly independently from the rest" feel.
— V = IR (Talk • Contribs) 03:50, 6 March 2011 (UTC)

I see how liquidthreads will be a dramatic shift in how discussion occurs, it will be simpler to add to a discussion, and it won't be like editing a text file anymore. As far as ending discussion fragmentation I'm not seeing that bit. The nature of the wiki seems to resist centralized discussion, but as such it seems a variety of venues have sprung up (WP:CENT, the village pump to a lesser extent). It used to be that the only way to get attention on an issue was to make a big fuss at AfD. I'm not sure if liquid threads alone would cause a mindshift in how we discuss large issues.

Aside from that, don't discredit facebook integration out of the gate, it still might be useful, but we should focus on thing inside the house before we work on the rest of the neighborhood. --NickPenguin_(contribs) 04:11, 6 March 2011 (UTC)

I have two suggestions that may help: 1. Articles should be rated/ranked, and the higher their score, the more they adhere to being a good quality article, eg NPOV, references, notability.

2.) New articles, stub articles would sit in a incubator, until they had reached sufficient quality to be put into Wikipedia. Articles could just sit in the incubator, and evolve into quality articles, or perish from inactivity. If an article hasn't been visited in a 2 to 3 years, it could be purged. Articles in the incubator may or may not be indexed by search engines. This would also allow (new) articles, writers and editors to be mentored, and facilitate incremental improvement directly. Hackbinary (talk) 14:24, 7 March 2011 (UTC)

Far afield

This discussion has gone rather far afield. Nevertheless, there turned out to be one good link above — the one to http://en.wikipedia.org/wiki/Wikipedia:Invitation_to_edit . It seems the project there is a positive, forward-looking endeavor, and I am inclined to take part in it as a fine response to the original poster in this thread — user:Anna Frodesiak, the editor with the spiffy new barnstar. Your sincerely, and moving on — GeorgeLouis (talk) 21:12, 4 March 2011 (UTC)

Pay users to edit and you'll get millions more. Feedback ^☎ 05:43, 5 March 2011 (UTC)

And article quality goes waaaay down (Aside from the budget problem). People edit for fun and satisfaction. Paying them makes it into work. Nobody outperforms at work (unless you want a promotion)

“ Work consists of whatever a body is obliged to do, and, play consists of whatever a body is not obliged to do ” — Mark Twain, Tom Sawyer

ManishEarth^{Talk • Stalk} 08:39, 6 March 2011 (UTC)

Template

One thing I think would help improve the ol' Wikipedia is to have a little template appearing at the top of the page saying you have new messages on your talk page whenever you do have new messages. Of course, it would have to be done so that it doesn't appear on every single page to everyone, just to those who have new messages on their talk pages. Maybe have it say something like this:

You have new messages

Just have it be as simple as possible, and have "new messages" link to whichever user's talk page. Besides, just about every other Wiki I've been to has this feature, why not Wikipedia? --Codyrox (talk) 01:24, 25 February 2011 (UTC)

• Isn't that what the orange "You have new messages" band is for? – Peacock.Lane 01:51, 25 February 2011 (UTC)

• This is, in fact, the way it works already! The reason you're not seeing it is that you're editing as Thebigfan2 (talk · contribs), with your user talk page redirected to User talk:Thebigfan. As a result, anyone looking to leave you a message will end up doing so on the talkpage associated with Thebigfan (talk · contribs), and triggering the message alert for that (now dormant) account; the message alert would only get triggered for you were a message to be left on User talk:Thebigfan2. Shimgray | talk | 03:04, 25 February 2011 (UTC)

Well, I would edit as "Thebigfan" but I seem to have forgotten what my password was to get on it. --Codyrox (talk) 18:35, 25 February 2011 (UTC)

Can't you just request the password be sent to your email address? Otherwise, redirect User:Thebigfan to User:Thebigfan2, and get on with editing, problem solved. You already use the totally unrelated "Codyrox" in your sig so there's no reason to be wedded to the Thebigfan account. Fences&Windows 23:58, 28 February 2011 (UTC)

Like Button

I propose a Like button/link on every page. This information would be persisted for every user. This information could be used to provide personalized page suggestions on the home page, based on that particular user's interests.

• Sorry, but I disagree. Wikipedia is a completely different thing than Facebook. See [[WP:NOT]. – Peacock.Lane 01:49, 25 February 2011 (UTC)
• I also think that's not a good idea. Besides, if you really want to share a Wikipedia page, just cut and paste the URL of that page into your post on the social networking site. It's much easier than the prevalence of buttons on other sites would indicate. Sven Manguard Wha? 03:53, 25 February 2011 (UTC)

I don't think that's what the OP meant. The "personalised page suggestions" would suggest an entirely on-wiki thing, but we don't really have a way to achieve this. - Jarry1250 ^{[Who? Discuss.]} 20:44, 25 February 2011 (UTC)

This is actually in the works via the article feedback pilot; see Category:Article Feedback Pilot. ---— Gadget850 (Ed) ^talk 20:54, 25 February 2011 (UTC)

I looked at the feedback form, it asks for too much, there should be a short form, ie the Like button, and a long form which people can optionally fill in.Hackbinary (talk) 12:19, 4 March 2011 (UTC)

Strong Support A simple like and dislike buttons, keep it simple. Hackbinary (talk) 12:19, 4 March 2011 (UTC)

This has been proposed and rejected a month ago, see Wikipedia:Village pump (proposals)/Archive 68#"Like" or "dislike"" button MBelgrano (talk) 17:23, 26 February 2011 (UTC)

Anyone wanting personal suggestions might be interested in User:SuggestBot, "a program that attempts to help Wikipedia users find pages to edit based on their past contributions". Fences&Windows 19:14, 26 February 2011 (UTC)

Tag team

A large number of WP articles now have maintenance tags, many of which are years old. In some cases the issues have been fixed, in others not. In some cases the person adding the tag acted in good faith with rationale on the Talk page, in others it's a drive-by or agenda account whose sole problem is that the article reflects WP:NPOV instead of WP:TRUTH.

Proposals:

1. That tags over 1 year old be removed by a bot.
2. That tags over 1 month old and with no active discussion be targeted for manual removal.

It is clear to me that newbies do not feel they have the right to remove tags. Issues not actively being fixed, and where the editor identifying the issue cannot be arsed to make a case, should simply be closed - as is the case with any trouble ticket system. I think that's the way to view tags: as trouble tickets. In every system I've encountered, "no response from originator" is solid grounds for closing.

I'd exempt WP:BLP articles; tags on these over a month old should result in listing at WP:BLPN and loud klaxons and flashing lights.

Lets pick up after ourselves. Guy (Help!) 01:22, 26 February 2011 (UTC)

• Strong Oppose - Ignoring the problem doesn't make it go away. These tags for the most part represent things which ahve problems. An example of backlogs being worked on would be the Unreferenced BLP Rescue wikiproject has done a great job at cutting down the backlog on unreferenced BLPs, there are now fewer than 11,000 compared to the 50,000+ that we had 2 years ago. The {{fact}} category is down to ~267k from ~312k. So clearly things are eventually being fixed. Having a bot remove tags simply because we aren't keeping up fast enough doesn't fix the problem, they ARE useful for at least tracking what needs to be done. --nn123645 (talk) 02:59, 26 February 2011 (UTC)

• Comment in Guy's original form I must strongly oppose the proposal, but I think there is a germ of a good idea here. The problem of old tags is certainly real; the trouble is that "old" is not very adequately measured by the passage of time, and "activity" is too hard to quantify for the wide range of high and low activity pages on Wikipedia. We could certainly try and find ways to prod editors to ensure that there is a current rationale for tags, and a bot would figure in that somewhere, but doing this in a way that doesn't clear out tags that shouldn't be is not going to be easy. Rd232 ^talk 17:36, 26 February 2011 (UTC)

• Strong Oppose as nn123645 said, "Ignoring the problem doesn't make it go away." Many of these tags are for serious issues, such as articles not having sources. There are people that work on these things, however they only work so quickly. Also, if a problem persists the tag should not be removed no matter what, period. Whether it's by bots, newbies, or experienced users, removing a tag without fixing the problem is not acceptable, period. Sven Manguard Wha? 21:15, 26 February 2011 (UTC)

• Oppose per nn123645. Even if people aren't actually fixing some of the problems, these provide useful statistics and many tags warn readers about potential reliability issues. Why should people be required to start a discussion for things that are often blindingly obvious? If an article has no sources, that's not something that needs explanation. I agree with Rd232 though, there are probably a lot of articles that are mistagged due to the problem being fixed. A bot could, for example, find all pages with citation templates or multiple external links that are tagged as having no sources, but a human would still need to do the final check. Mr.Z-man 22:57, 26 February 2011 (UTC)

• Strong Support. Maintenance tags are, as currently implemented, a blight on Wikiepdia. JzG spells out several of the problems perfectly. To be clear though, what I support here is the removal, or change in practice, in the use of Category:Cleanup templates (for the most part). I think that inline templates are very useful, it's the more general "cleanup this article" template that is problematic.
  Realistically though, we're not going to get rid of them. My idea for quite some time now has been to move these templates onto the article talk pages. That would get the "nastygram" aspect of the message box out of the reader's faces (especially since these tings are normally the very first thing someone sees when they go to an article). Putting them on talk pages would allow for the continued categorization and tracking of pages, as well. More importantly though, it seems obvious to me that if the message is left on the talk page then that would encourage those adding the tags to say something in order to describe the problem.
  — V = IR (Talk • Contribs) 23:38, 27 February 2011 (UTC)
• Oppose. First, with reference to Ohms law's comment, see WP:Perennial proposals#Move maintenance tags to talk pages. The point is that we actually want them to be "in the face" of the readers. One, we want to warn them if what they're seeing may have problems (so that they may be more wary about relying on it), and, second, we want to encourage them to try to help fixing it. The only way to fix these tags is for a human to go through and actually fix the problems, or, at least, identify that there is no actual problem. That's actually the goal of things like the current Great Backlog Drive or similar drives run by other wikiprojects. I can tell you, just because a tag isn't old doesn't mean it's valid. I'm working in a category with tags from 2007, one which requires a substantial amount of effort to fix, but I can tell you that in every case except for 2 or 3, the tags were fully valid and substantially problematic. Qwyrxian (talk) 07:19, 28 February 2011 (UTC)

  You want them to be "in the readers face". Myself and others certainly don't (admittedly, this seems to be a minority point of view). There's no "we" here; people with your viewpoint 'win' on this issue more because of inertia then any real consensus.
  — V = IR (Talk • Contribs) 20:00, 1 March 2011 (UTC)

• Oppose both, but especially #1, per everyone above. Removing a legitimately placed tag is like taping over a "check engine" light on your car instead of getting the engine checked. Wrongly placed tags can and should be removed, but a bot isn't going to know the difference. 28bytes (talk) 17:53, 28 February 2011 (UTC)
• Oppose. As nn123645 said, "Ignoring the problem doesn't make it go away." This would be defeating the purpose of tags, wouldn't it? Guoguo12--Talk--  21:35, 1 March 2011 (UTC)
• Strong oppose The goal of maintenance templates is to identify the problems. Removing these templates without addressing the problem is counter-productive. Armbrust ^{WrestleMania XXVII} _{Undertaker 19–0} 19:17, 5 March 2011 (UTC)
• Oppose - though I hate to see articles plastered with tags they are important pointers to problems that have been identified that need to be investigated further and fixed before removal. Unfortunately I cannot see how a BOT can check out if the problem has been fixed or not, apart from possibly dead-links. May be we could encourage WikiProjects to use the clean-up listings more and continue have specific tag drives to clear out the older tags. Keith D (talk) 19:54, 5 March 2011 (UTC)

Debundling of sysop tools (commonshelper right)

I'd like to propose a debundling of a new right, commonshelper, to allow non-admin users experienced in image work (transferring appropriately licensed enwiki images to commons, reviewing transferred images) to be able to delete in the File: and File talk: namespaces. They'd use this right to help clear backlogs, (Category:Copy to Wikimedia Commons Category:Wikipedia files with the same name on Wikimedia Commons Category:Wikipedia files with a different name on Wikimedia Commons), as not many current administrators are very willing to do it. I've listed more details here. --Addihockey10 ^e-mail 03:18, 26 February 2011 (UTC)

Would/should/could this be bundled with the filemover tool proposal? Thoughts? --Addihockey10 ^e-mail 03:22, 26 February 2011 (UTC)

Note that consensus may soon allow all autoconfirmed users to move files. Guoguo12--Talk--  20:51, 26 February 2011 (UTC)

Note that the above statement is patently false and that the consensus supports unbundling of filemover but rather strongly opposes giving it to every autoconfirmed user at this time. FWIW the proposal also opposes bundling it with accountcreator, so I'd avoid that idea here. Sven Manguard Wha? 23:49, 27 February 2011 (UTC)

Note that the statement directly above may not be true. How can you say consensus strongly opposes it at this time? You strongly oppose it, but the opposition is not unanimous, nor is consensus very clear. However, for obvious reasons, let's not discuss this here. Guoguo12--Talk--  01:12, 28 February 2011 (UTC)

• Support FWIW.
  — V = IR (Talk • Contribs) 23:39, 27 February 2011 (UTC)
• Oppose allowing non-admins to delete anything, for any reason, at this time. I would however be in favor of creating a bot to assist in the work. Consider the following:
• Wikipedia already has the capability of noticing that someone is trying to upload an image that is pixel for pixel identical to an existing file.
• Most of copying to commons involves copying images pixel to pixel.
• A bot, theoretically, could scan two addresses, the enwiki one and the commons one, to determine if the two images are pixel for pixel matches.
• One idea would be to allow users access to a wikipedia to commons move script without the ability to delete the wikipedia image, which would automatically feed information to a bot that would scan to ensure that the image was pixel for pixel identical, the file names were identical, and that license information was transferred over successfully. If that were the case, the bot would delete the enwiki version. Any edits that need doing to the image itself, such as cropping or renaming, could be done on commons.
• This proposal ensures that only files that were copied to commons are deleted, as opposed to allowing anything in the file namespace at all to be deleted. Sven Manguard Wha? 00:06, 28 February 2011 (UTC)

  That would hit a couple snags though. If people uploaded blatant copyrighted images, such as a cover of an album etc., the bot wouldn't be able to tell it is copyrighted. So the inexperienced editor adds {{CC-BY-SA 3.0}} to the image description - the bot finds the image and copies it to commons. I also find that when knowledgeable humans review it - it's far less likely to be a copyrighted image. --Addihockey10 ^e-mail 12:57, 28 February 2011 (UTC)

Support - I generally support the idea but I also recommend that users with the above right also has the ability, via a script or whatever, to be able to rename images on Wikipedia. This currently requires administrator access and would be very beneficial. --Kumioko (talk) 01:41, 28 February 2011 (UTC)

• Unfortunate Oppose - after thinking about this, I've come to the conclusion that there are very few users that would be suitable for deleting images moved to commons but not suitable for other admin tasks. Now to toot my own horn a bit and show my credentials in the area: I have spent literally hundreds of man-hours moving images to commons and I'm largely responsible for the clearing of 2/3 of the backlog at Category:Wikipedia files with a different name on Wikimedia Commons. I can testify right now that many non-admins are better at recognizing which images should be moved over and which shouldn't. But the users I'd trust to recognize which images should be moved over, I'd mostly also trust to be admins. Thus I see three problems:
  1. If any admin could bestow this ability upon a non-admin, then there would be countless bad moves, if only because most admins don't really know what they're doing in the area. This isn't like rollback or autopatrol; hitting the delete button can't be undone easily. And if an admin sees exemplary behavior from a user in all areas and much good work with images, this admin is liable to say "I would trust this user with images" without going through the vetting process of making sure that user is familiar with the subtleties of image moves (e.g., COM:DW, COM:FOP, COM:DM, COM:COA, Wikipedia:Non-U.S. copyrights (a woefully out of date document), WP:PERMISSION, {{PD-US-not renewed}} - and how to search for it [2], work-for-hire laws, {{Not-PD-US-URAA}}, the interaction of {{PD-URAA}} with {{PD-Russia}} and {{PD-Russia-2008}}, etc.).
  2. If, on the other hand, we require a vetting process to gain the bit, it would become sort of a pseudo-RfA. All of which would be fine with me (no really), except that the community has repeatedly rejected the idea of giving admin bits in increments.
  3. The third objection isn't really mine, and it might prove to be immaterial: this is a fairly difficult thing for the devs to write into the software. They would have to give the ability to certain users to delete only certain files, and only allow the users to choose one option from the pull-down list. The devs might reject this as not worth their time. Magog the Ogre (talk) 18:29, 28 February 2011 (UTC)

  I'm not one to ask, but I don't think it'll be THAT hard to make a new usergroup that can delete pages in the File: and File talk: namespaces. Also it's not just for users just focused on enwiki>commons work. It's for users who are fully capable of reviewing enwiki->commons images but would not pass a regular RfA for various reasons (not any experience in certain areas such as WP:AIV WP:RFPP WP:UAA etc. etc. --Addihockey10 ^e-mail 22:35, 28 February 2011 (UTC)

Support - this should help with the backlogs.   — Jeff G.  ツ 01:50, 3 March 2011 (UTC)

• Oppose This is an example for creating too many user groups for too few users. I suspect that only a few users would end up helping with the backlogs; we have over a thousand admins and look where we are. /ƒETCHCOMMS/ 04:40, 4 March 2011 (UTC)

I'm not sure how to take the "we have a thousand admins and look where we are" comment. We have a 2-3 year admin backlog that few people want to deal with? A handful of those few people being non-admins? I kinda picture this to be similar to the abusefilter right. Not TOO many people have it, but it's enough to significantly clear the current (2-3 year) backlog that we have. --Addihockey10 ^e-mail 15:08, 5 March 2011 (UTC)

Support Deletions in the File/File Talk namespaces are often uncontroversial. And virtually all deletions that have to do with images moved to Commons are uncontroversial. There's a need for competent people working in this area and it's a good idea to try and make it happen. I see a couple of problems with Addihockey10's objections above. First it's quite likely that some very competent candidates for this userright would fail RfA because of unfamiliarity with other areas that are considered more important at RfA. Second, it's true that most admins would be incompetent at this task but this is precisely why it makes sense to selectively target competent people for this task. Unbundling will increase the number of competent people in this area without creating any sort of drama. Pichpich (talk) 19:46, 5 March 2011 (UTC)

Share button

Not sure if this has been already proposed, but can't we have a "Share" button to directly share a page on Social networks like Facebook/Orkut? Knowledge is power but the power increases exponentially when it's shared !! — Preceding unsigned comment added by Arnabcse28 (talk • contribs) 12:00, 26 February 2011 (UTC)

It's been proposed quite a few times, declined thru WP:NOTMYSPACE. But, you may use this userscript if you want to enable it for yourself. ManishEarth^{Talk • Stalk} 12:51, 26 February 2011 (UTC)

I think we prefer to limit the sharing of knowledge to those competant enough to copy and paste a URL.©Geni 14:04, 26 February 2011 (UTC)

Wikipedia is a social network wether you like it or not. Its a network and it promotes social interaction between its users. The focus is on the encyclopedia, but that doesn't change anything. Flixster's focus is on movies, Fickr's is on photos, Digg's on news, YouTube's on videos and Wikipedia's on encyclopedia articles. No one refutes YouTube's status as social network just because its primary goal and function is to collect and provide video content. Wikipedis IS a social network and the encyclopedia isn't damaged because of it. Wikipedia has taken steps towards the future like Barnstars, Userboxes, guest books, humor pages and and other things that have nothing to do with the encyclopedia. Does it hurt it? No, it just let's people have some fun and interact in ways the encyclopedia doesn't let them. These people contribute, but they also love interacting and chatting. Just like YouTube's users subscribing to each other's pages and chatting up the comment boards doesn't change the fact that a lot of them upload videos regularly. The day Wikipedia embraces the social network revolution is the day it truly reaches its full potential. Feedback ^☎ 05:21, 27 February 2011 (UTC)

Personally I think we should enable a share button, but it would be in the preferences if a user would want to disable it. --Addihockey10 ^e-mail 05:27, 27 February 2011 (UTC)

Hell No! The separation of WMF project and social network site must be absolute at the development level, or Wikipedia loses essentially overnight the credibility and academic standing it has spent ten years trying to gain. I don't see how this is so freaking hard for people to understand that Wikipedia is not a social networking site. Most Wikipedians are quite happy with the fact that there is no share or like or friend or whatever other buttons on Wikipedia, and that there are no corporate relationships between the WMF and these sites. Wikipedia is an encyclopedia, it shares the knowledge of the world. It can be social in so much as that people work together to improve the project. Facebook is not academic, most of the time it is not even substantive, and it's primary functions are in no way comparable with Wikipedia. If you want a social experiance related to Wikipedia, hop onto the IRC, which at least attempts to be Wikipedia focused some of the time. Sven Manguard Wha? 20:27, 27 February 2011 (UTC) Amazingly, one post works in both sections.

One post in two sections, but I really don't think it's terribly relevant to this section. A Share button would be less about building a social environment around Wikipedia and more about sharing our content with people in increasingly easy ways. What use is compiling the sum of all human knowledge if nobody reads it? (of course, I'm not suggesting that nobody reads Wikipedia, but still) EVula // talk // ☯ // 16:40, 28 February 2011 (UTC)

You'll not meet many people with lower opinions of social networking sites than I have. I would hope that if this passes, it would be very, very low key, and give logged in users the ability to hide it entirely through their preferences. Sven Manguard Wha? 06:15, 6 March 2011 (UTC)

Sharebox is a script that reorders your toolbox. It adds new buttons that make it easier to mail, print or share an article on Facebook or another linksharing service. See User:TheDJ/Sharebox. ---— Gadget850 (Ed) ^talk 20:55, 27 February 2011 (UTC)

• This purism about not including share buttons is weird. Scholarly journals do include them, see the right-hand bars on OUP's Bioinformatics and BMC Bioinformatics for just two examples. Being 'scholarly' is not the same as being snobbish stick-in-the-muds like Wikipedians are over this. It'd not harm our credibility one jot to have share buttons for Twitter or Facebook. Fences&Windows 23:53, 28 February 2011 (UTC)

• Support. The share button is just a button to share our content to other sites, and that's it, just a link. It doesn't make Wikipedia any more or less like a social network. I'd strongly support this feature, it would make spreading the name of Wikipedia much easier... Rehman 11:27, 1 March 2011 (UTC)

• Oppose Facebook already includes the chance to "share" a link with a friend (to any web site). This generates a link with the page name over it, a small preview of the content, and one of the images included at the site (which the user may select before sharing the link). The result is more or less like this. This requires no work or Facebook-association from the source site, in this case, us. So why bother? MBelgrano (talk) 11:43, 1 March 2011 (UTC)

Mmm, yes, you have that option too... But I still think a link from the source site is a bit easier. And because of that "bit easier", I am changing my vote to neutral... Changed back to Support, per my comment below. Rehman 12:46, 1 March 2011 (UTC)

Have a look at the toolbox of the Hebrew Wikipedia, they have "Share on Facebook", "Share on Twitter", and "Email This". This hints that there is no real problem in having them here too... Rehman 05:37, 6 March 2011 (UTC)

• Oppose. URLs and Facebook's link-posting function works fine, if you ask me. Guoguo12--Talk--  21:39, 1 March 2011 (UTC)
• Support - Facebook is already on many other sites, and it's a great way to spread the message. So what if it's a commercial site and it's social networking? Great way to share. That said, I have opted out of this feature myself on Facebook due to privacy concerns (enforced via NoScript on my browser!) Magog the Ogre (talk) 06:53, 4 March 2011 (UTC)
• Oppose There are tons of sharing utilities, bars, social sites, etc.. To add functionality for one or for all would be to extensive, and the "flavor of the month" always changes. If you like something, just use whichever tool you have to share with friends. Who (talk) 13:19, 4 March 2011 (UTC)
• Support - I tend to agree with Fences & Windows. Being scholarly is not the same as being old-fashioned. There are even services now like CiteULike specifically for sharing scholarly publications. Nature and journals published by Springer also include some variant of "share" links. The links don't have to be extremely visible, just present. I don't think it's in our best long-term interest to continue to isolate ourselves from the rest of the internet. Mr.Z-man 17:28, 4 March 2011 (UTC)
• Support While it wouldn't turn Wikipedia into a social networking site, it would only serve to increase visibility of articles, encouraging contribution. I don't think WP:NOTMYSPACE applies here, the ability to share articles on social networking sites doesn't make Wikipedia a social networking site itself. Swarm ^X 17:39, 4 March 2011 (UTC)
• Support Wikipedia is not myspace, but to deny the existence of the social web is to miss out on a whole venue of site promotion. Being able to share articles only attracts more readers, and probably over time, more editors too. I don't see a negative. --NickPenguin_(contribs) 05:59, 6 March 2011 (UTC)
• Oppose A special plea to those obsessed with Facebook: Keep it as a separate part of your lives. I use Facebook a little, but there is no way I want to see any connection between it and Wikipedia. Wikipedia is already very well known. A link via a url makes a perfect connect if one is required. HiLo48 (talk) 06:16, 6 March 2011 (UTC)

Mix Wikipedia and Twitter

Wikipedia offers the "immutable" knowledge of the world. Twitter offers the "mutable" experience of the world changing in front of our eyes. Wouldn't it be interesting to being able to take a look to both at the same time? --Maalvarez (talk) 09:56, 27 February 2011 (UTC)

So go design that. I'm not sure exactly what you're envisioning, but if you have something in mind, web hosting is cheap (and often free) while you're just in development. Why does everyone want to throw something out there, and then have someone else go code it? Seraphimblade ^{Talk to me} 10:11, 27 February 2011 (UTC)

For what purpose? There's no reason to read a Twitter feed and an encyclopedia article side-by-side (and I say this as an avid Twitter user with close to 13k tweets). Plus, your use of "immutable" and "mutable" here is incorrect: Wikipedia is an excellent example of "liable to change". EVula // talk // ☯ // 15:51, 27 February 2011 (UTC)

Here's an easy way to do this. Go to Wikipedia. Resize your browser screen to half of your monitor. Open another browser window. Go to Twitter in the other browser window. Also resize this to half of your monitor. Place them side by side. Presto! Done. Cheers! bd2412 T 16:27, 27 February 2011 (UTC)

But that's hard to do if you don't have Windows 7… :( --Izno (talk) 16:46, 27 February 2011 (UTC)

Hell No! The separation of WMF project and social network site must be absolute at the development level, or Wikipedia loses essentially overnight the credibility and academic standing it has spent ten years trying to gain. I don't see how this is so freaking hard for people to understand that Wikipedia is not a social networking site. Most Wikipedians are quite happy with the fact that there is no share or like or friend or whatever other buttons on Wikipedia, and that there are no corporate relationships between the WMF and these sites. Wikipedia is an encyclopedia, it shares the knowledge of the world. It can be social in so much as that people work together to improve the project. Twitter is not academic, most of the time it is not even substantive, and it's primary functions are in no way comparable with Wikipedia. If you want a social experiance related to Wikipedia, hop onto the IRC, which at least attempts to be Wikipedia focused some of the time. Sven Manguard Wha? 20:25, 27 February 2011 (UTC):

I agree, hell I don't really consider Wikipedia to have much credibility, though I do think its articles are reliable 99.95% of the time. I would never use it in an academic setting, but I think it has been improving and maybe a few people are starting to respect it a bit more. Plus I am editting it in a serious manner rather than just vandalising, so I guess that says something. If you integrate the ability for Twitts to do this and that so that it becomes a social networking site where people talk about and share the most boring details of their lives, I think Wiki will lose any and all respect that, as Sven has said, it has spent all these years trying to get. So in closing, **** No! TheArchaeologist Say Herro 20:44, 27 February 2011 (UTC)

Sharebox is a script that reorders your toolbox. It adds new buttons that make it easier to mail, print or share an article on Facebook or another linksharing service. See User:TheDJ/Sharebox. ---— Gadget850 (Ed) ^talk 20:56, 27 February 2011 (UTC)

That's a useful script. I didn't know that AddThis could be used in wiki scripts. Goodvac (talk) 08:37, 3 March 2011 (UTC)

Please read Wikipedia: What Wikipedia is not. I think it is the section under sub-heading 2.5 that clarifies that Wikipedia is NOT a social networking site, so it must be kept separate from websites such as Facebook, Bebo, My Space or Twitter. ACEOREVIVED (talk) 22:27, 1 March 2011 (UTC)

Testing new account creation processes

During the next couple of weeks, there will be some testing on the account creation process. I and the others who are working on this of course aim to disturb the normal routines as little as possible, but as we have seen (see WP:AN for more details), there can be some unforseen side effects. If that is the case in the future, you are welcome to help out. I have created this workspace, so that everything is transparent. If you have any questions about this, feel free to contact me through my talk page (but remember that I am on GMT+1 time), or through email (which you can find on my user page). I apologize in advance for any problems this may cause and hope that many people jump and create their own versions so that we have many new alternatives to test.

Oh, and by the way, I intend to start testing version nr 3 in about 10 hours. You may edit that page up until that moment. Thanks for your patience.//SvHannibal (talk) 00:15, 28 February 2011 (UTC)

In my opinion this is a great idea. I think that it would also be a good idea to provide this information to those whose accounts were made at the ACC interface.. perhaps a little blurb on the response email for requested closed as created? Ajraddatz (Talk) 03:16, 28 February 2011 (UTC)

Well, when ACC-created users login for the first time, they see the shiny "New messages" bar and they read the normal welcome template. The welcoming bot was down for some time last year, so the messages didn;t get out, but I;m quite sure they do now. *checks . Yep. They do. Oh, and the idea is wonderful!. I might try to create my own version... ManishEarth^{Talk • Stalk} 12:05, 28 February 2011 (UTC)

• FYI: Now test nr 3 is up and running. Let me know if there are any problems.//SvHannibal (talk) 12:54, 28 February 2011 (UTC)
• And now test nr 4 is going on.//SvHannibal (talk) 23:31, 2 March 2011 (UTC)

Collab with Citizendium

As I am sure everyone here knows, Wikipedia is the largest source of free online information available. Thanks to the ever vigilant team of admins and editors(yes I’m talking to you) this website continues to become increasingly accurate and neutral. The talk:Reliablilty of Wikipedia does an excellent job of allowing us editors to help the way by which this online resource covers itself, showing that neutrality is ultimately the websites main goal. However this produces a paradox of sorts, Wikipedia cannot self-define with absolutely neutrality. This brings me to my main point; a collaboration with Citizendium. When Wikipedia’s founder left the team shortly after its creation, he started a second project which attempted to remove the lack of credibility that is inherent within Wikipedia(sorry guys). I propose, and I assume I am not the first, that these two projects are combined. The pure size of Wikipedia is something that Citizendium could never match, and the accuracy and neutrality that Citizendium has is exactly what is holding Wikipedia back. Citizendium only has 155 pages with have been edited and confirmed by multiple experts of that topic, but these pages are said to be entirely error free. Adding this level of accuracy to Wikipedia articles, even if just 155 out of the 3-million plus articles would be an incredibly beneficial step forward for the site that would only increase with time.” --Droberts4080 (talk) 09:24, 28 February 2011 (UTC)

I've never been overly impressed with the scope or writing on Citizendium; of the pages they have that are workable the content is about on a par with what Wikipedia has on the same topic, usually using the same sources. The caveat to that is that certain contentious pages are much better on Citizendium through virtue of being restricted editorship - but practically speaking those pages are crappy (example compare Islam to Islam) because they are contentious. The lead to our Islam article is horrible; but how is Citizendium collaboration going to fix that problem :) --Errant ^(chat!) 09:52, 28 February 2011 (UTC)

WikiProject Citizendium Porting exists already as a way for Wikipedia to benefit from Citizendium's work. You might want to look at what they're doing. Including, by the way, assessments of which pages aren't up to Wikipedia standards. — Gavia immer (talk) 09:55, 28 February 2011 (UTC)

Citizendium is hardly error-free, nor are they particularly neutral. Their alternative medicine articles have largely been taken over by proponents, and many of their approved articles are terribly written and/or inaccurate, for example, Biology is a confused mess, and Scientific method has a section advocating for Intelligent design, which is pretty horrifying to anyone who knows biology.

Frankly, there's serious quality and accuracy gaps in a lot of Citizendium articles, and we'd be well advised to be very careful in use of them, while, of course, benefiting from the occasional very good articles to come out of the process. Adam Cuerden ^(talk) 10:07, 28 February 2011 (UTC)

There isn't a "section" on ID, just part of a paragraph, which clearly states that very few biologists accept it. Peter jackson (talk) 11:38, 28 February 2011 (UTC)

It looks to me as if there are three whole paragraphs (and some other verbiage elsewhere) dedicated to introducing the proposition that the theory of evolution by natural selection is possibly not scientific. Since the article is not about evolution (and says it is not), the amount of verbiage attached to this proposition is pretty troubling. — Gavia immer (talk) 12:05, 28 February 2011 (UTC)

Having taken the time to flick through a few more articles there, Citizendium suffers a lot for requiring "expert" editors on topics & most of the articles suffer from a lack of focus, poor writing, neutrality issues and often too narrow a scope. It's a shame, the idea IIRC was to fix those very problems, I guess that is an approach that doesn't work. --Errant ^(chat!) 12:18, 28 February 2011 (UTC)

I've seen no evidence that Citizendium is overall more neutral or accurate. Many of their articles are in fact old forks of Wikipedia articles that have since been cleaned up on Wikipedia, but not on Citizendium. 28bytes (talk) 16:26, 28 February 2011 (UTC)

Quite. "Citizendium only has 155 pages with have been edited and confirmed by multiple experts of that topic, but these pages are said to be entirely error free." Said by whom, the experts? Citizendium has terrible problems with fringe science, even more than we do, and that's caused by their "experts" (just look at their Homeopathy article). Moreover, the restrictions on editing and the general culture there led to stagnation (example: the discussion email list got busy just as it was launching, so Larry Sanger responded by essentially shutting it down[3]; another example of Sanger's "golden touch":[4]). An alternative approach is to overlay 'expert review' on top of Wikipedia, see meta:Expert review. Fences&Windows 23:43, 28 February 2011 (UTC)

An alternative to this may be to create a system similar to the GA nominations, where the articles would be reviewed by an expert in such topic. Of course, "an expert" would not be some random user with delusions of grandeur, but someone previously approved for such a task, perhaps detailing his real name and degrees by OTRS. And of course, the topics that this expert can manage as an expert. This system would not replace FAC or GAN, but be a new one. It may not replace FAC, accuracy is an important thing for FA status but not the only one, and an expert-approved article may still need to adress other issues. We shouldn't expect real-world experts to be aware of internal Wikipedia nuisances, such as how to use templates, not linking to disambiguations, no overcategorization, image licences, what to keep at an article and what to move to a fork article, etc; and the expert may overlook them. And, although it would have a higher prestige than GAN, it will certainly be a very, very, very slow process, with backlogs that may last for many months, as very few people would be managing them, and without help from other users. MBelgrano (talk) 17:41, 1 March 2011 (UTC)

[Edit conflict] The major problem is that credentials can be somewhat dangerous when you're dependant on one person: For example (and using only really obvious cases to avoid BLP issues) Michael Behe is a professor of biochemistry, but one would not want him as the judge for our biology articles, given his promotion of the unscientific intelligent design form of creationism, and denial of evolution. Andrew Wakefield was a medical researcher at a respected hospital, but would've been a disaster if he were our judge for immunology, given, you know, that he was found guilty of committing fraudulent and unethical research in order to promote a crank immunological theory.

Instead, may I point to the vastly respected WP:MILHIST and their multi-person expert A-level review. On a WikiProject level, with multiple experts fully integrated into Wikipedia, expert review can work wonderfully. Adam Cuerden ^(talk) 18:07, 1 March 2011 (UTC)

Isn't Citizendium basically dead? Only 155 articles in how many years? I just looked at the recent edits there which are 500 article edits since 26 februari, not terribly active. Garion96 (talk) 17:56, 1 March 2011 (UTC)

There are more than 155, the 155 are the approved articles. Still not that much though. Garion96 (talk) 18:00, 1 March 2011 (UTC)

I have very rarely looked at Citizendium, but on the rare occasions I have looked at it, I can only say that it appears to be an online encyclopaedia that is lower-quality product than Wikipedia. It lacks Wikipedia's range of articles and comprehensiveness, for a start. ACEOREVIVED (talk) 19:41, 2 March 2011 (UTC)

Let me be a little more specific. When I looked at Citizendium, I noticed that it did not even have an article on Paul Tillich - a leading theologian of the twentieth century without an article! Citizendium may be against anonymous editing, but that has not made it a better encyclopaedia than Wikipedia. ACEOREVIVED (talk) 00:22, 3 March 2011 (UTC)

I looked at Citizendium from the computer I use at work on the morning of March 3 2011,and again, I was anything but impressed with it. I noticed that it did not even have a separate article on ascetism - an article which has long existed in the paper version of Encyclopaedia Brittanica. So please let us keep us what is definitely the better online encyclopaedia (Wikipedia} separate. ACEOREVIVED (talk) 22:28, 3 March 2011 (UTC)

May I also add that Citizendium rarely has the high Google search that Wikipedia has. ACEOREVIVED (talk) 00:07, 4 March 2011 (UTC)

Feel free to write such articles yourself. Citizendium can't be expected to have lots of articles until it has lots of people. Peter jackson (talk) 09:39, 4 March 2011 (UTC)

MB, Veropedia already runs such a system for WP articles. Also, the new site known (last I looked) as Knowino has such a system internally. Peter jackson (talk) 09:42, 4 March 2011 (UTC)

Gavia, the article is on scientific method. It's proper for it to cover philosophy of science, in which Karl Popper is a major figure. In relation to his ideas it's quite appropriate to discuss whether evolution is a scientific theory. Peter jackson (talk) 09:44, 4 March 2011 (UTC)

It is not, however, reasonable to then go on to claim that Intelligent design - an idea, not a theory, the premises of which are either untestable or disproven, is on equal footing. That's directly contrary to Popper.

Indeed, anti-science is core citizendium policy:

“ [http://forum.citizendium.org/index.php/topic,1029.0.html The Guardian piece belies any sophisticated understanding of the neutrality policy.

Have any of you actually carefully read the policy?

There are hints going on all over the place here, and no one ever comes out and says what he means: that he really is opposed to neutrality, when it comes to certain issues, like global warming. In other words, we really should simply state that certain views are incorrect, period. This is the only way to achieve "credibility," especially on issues that are merely "manifestations of ideological and social currents" as Greg nicely puts it. But it is precisely because they are such manifestations that our readers deserve a neutral presentation of them. It would be false, misleading, and ultimately a great disservice both to our readers and ourselves to pretend that controversies don't exist, when they most certainly do exist--even if they are, as you say, merely religious or political.

Let me be quite clear. No, we will not ever simply state that certain views in some currency (however ridiculously false) are simply false. This is what our Statement of Fundamental Policies says, and it is going to be written clearly into the Citizendium Charter. We will always make room only for views outside the mainstream, and allow people to make up their minds for themselves. Note, this does not mean we will simply state what all of us probably regard as pseudoscience uncritically. We will simply give it a fair hearing, and we will not state or imply that it is false; we will carefully word our articles so that the reader is apprised of the relevant facts, including the facts about what different people say (and how they reply to each other), and then the reader can decide for him/herself.

If for instance you feel that the "intelligent design" article should simply say, or take the clear stance, that intelligent design entirely lacks credibility, period, that is tantamout to rejecting the neutrality policy. As a Citizen, however, you are committed to this policy. Please, please do not harbor plans to change the policy, because this will only end in grief for everyone. Neutrality is part of the social contract that defines CZ, which I have been quite clear about since Day 1.]

--Larry Sanger

”

In short, Larry Sanger is an idiot, and Citizendium is awful by design. We're not going to salvage this by bringing a horribly broken system over into Wikipedia, which violates our basic WP:NPOV policy (ironically, written by Sanger orginally, before he decided he knew better than those damn scientists). Adam Cuerden ^(talk) 07:17, 6 March 2011 (UTC)

Adam Cuerden ^(talk) 07:13, 6 March 2011 (UTC)

• Oppose Let Citizendium rot. Last time I saw a thread here regarding Citizendium, it was because they didn't have enough money to keep the doors open and someone suggested a WMF loan. I have issues with both the quality of Citizendium's content and its philosophy. My opinion on Larry Sanger isn't so hot either, but that's a different matter entirely. The point is that it's really not something worth our time. For the sake of discussion, Wikipedia:WikiProject Citizendium Porting does exist. My understanding is that it's not very successful. Sven Manguard Wha? 06:21, 6 March 2011 (UTC)
  • We're 40% done with the porting, and several articles we lacked have been imported wholesale. I call that success. But yes, there have been a surprising number of articles copied from WP w/o significant improvements, and there are a few unusably tainted articles. --Cybercobra (talk) 08:02, 6 March 2011 (UTC)
    • There's certainly things to gain from using the compatible licenses, and the Porting WikiProject should not be disparaged: it has improved a few dozen articles. But adopting Citizendium's methods, or giving Citizendium power here, as the proposal suggests, is an AWFUL idea. I'm of the impression that the successful articles are despite the setup they have, not because of it. Adam Cuerden ^(talk) 02:27, 7 March 2011 (UTC)

My impression of Citizendium is that it's basically failed - I don't know why, perhaps just because it never achieved that critical mass of publicity to match that of Wikipedia, or perhaps because it turns out that their editing model isn't tenable for a voluntary project, whereas Wikipedia's (in spite of all we dislike about it) is. That isn't to say we can't learn things from Citizendium - if there are some articles that they have better than ours, then I'm all in favour of porting them in, licencing permitting (and glad to hear that that's happening). Otherwise, the best way to "cooperate" with Citizendium is to persuade the kind of specialist editors who write there to come and write for us instead/as well - ours (fortunately or otherwise) is the encyclopedia that the world reads. And we could certainly benefit from hearing first hand about any features of the setup over there (including the software) that might be usefully introduced over here.--Kotniski (talk) 08:46, 6 March 2011 (UTC)

Adam, the article doesn't put ID on an equal footing. And Citizendium's neutrality policy is much the same as Wikipedia's. Peter jackson (talk) 11:07, 7 March 2011 (UTC)

Kotniski, many of the specialist editors on Citizendium do edit here as well. For the rest, it's hardly going to be the case that they're unaware of Wikipedia, is it? So those who don't edit here must have some reason for not doing so. That must be that they got fed up with having to fight endless wars with propagandists and/or idiots and/or trolls. Until Wikipedia develops an effective means of resolving disputes those sorts aren't going to come back. Peter jackson (talk) 11:12, 7 March 2011 (UTC)

Yes, that's kind of what I meant. Make the atmosphere and culture here more amenable to serious and knowledgeable editors.--Kotniski (talk) 12:44, 7 March 2011 (UTC)

Purge dropdown change to purge tab

I would like the purge dropdown to change to a tab, as it's easier. --Highspeedrailguy (talk) 16:22, 28 February 2011 (UTC)

Alternatively, we could change the personal toolbar purge clock in preference → gadgets tab → User interface gadgets, into a default and have its removal available through preferences.--Fuhghettaboutit (talk) 16:30, 28 February 2011 (UTC)

Please don't. Anomie⚔ 22:42, 28 February 2011 (UTC)

Purging is a fairly rare need. I'm sure someone could write a gadget to add a tab for it though. --Cybercobra (talk) 02:28, 1 March 2011 (UTC)

See User:Svick/DropDownToTabs.js. — Edokter (talk) — 18:03, 1 March 2011 (UTC)

Use bots to maintain census figures

Bots can be used to maintain census figures.

Editors may construct initial text templates which would be locked. These would be incorporated into the text of the place article. Editors would present the template for incorporation into the list of templates a bot would maintain. A separate "acceptance" bot would be needed to accept and file the template.

When the bot was run, and found material that needed to be updated, it would unlock the template, make changes in some pre-specified manner, and relock the template.

No one else would make any census changes in the US. There would be a separate country-bot (and acceptance bot!) for each country since they each present material differently. But they would probably resemble the US one in construction and updating. — Preceding unsigned comment added by Student7 (talk • contribs) 17:54, 28 February 2011 (UTC)

I'm not sure what this means. I do know, however, that the boilerplate used for census figures in the U.S. articles is simply appalling. Sincerely, your friend, GeorgeLouis (talk) 20:25, 28 February 2011 (UTC)

While the editors of the article would still construct the text (template presentation; layout) for the article, I would guess that the templates would become more standardized. But yes, the words "spread out" for age groups, particularly appalled me. But these would be decided in advance (as the 2000 census were, only by a much smaller group, and for everyplace in the US) and would usually not be as clunky, having had the input of several people for each article. Student7 (talk) 13:04, 1 March 2011 (UTC)

I'm with GeorgeLouis. The text in thousands of US-related articles from the last (2000) census are pretty appalling. Moreover, the information being claimed to be so in those thousands of articles was nearly always without any sort of an inline citation that would have made the claim be easily verifiable to the casual reader of Wikipedia. In my view, Wikipedia can do better, and we should. N2e (talk) 13:40, 1 March 2011 (UTC)

I'm in full agreement about the need for a change in the boilerplate. Even after reading and editing scores of articles on US communities, that phrase "the population was spread out" always makes me think of population density. The organization of the age-distribution paragraph could also be improved: I think that it ought to begin with the single summarizing statistic, viz., the median age; after that, we can elaborate on the distribution. --Ammodramus (talk) 23:23, 1 March 2011 (UTC)

The boilerplate could be addressed with this change. The bot (and bot handlers) would have the responsibility of ensuring the material was properly footnoted. This would most likely be in the boilerplate template - the same place for everybody. I am assuming a centralized census bureau, as in the US, and, in fact, aiming this at the US which would most likely be first to be implemented.

So, step one, could be the construction of a recommended text template. There is no reason we could not start work on one now. On the other hand, there is no reason why anyone must use this exact boilerplate, but we might build into the "acceptance bot" criteria for a basic template. That is, the US template must contain age distribution, economic data, the valid footnote, etc. No point in using the bot without census-relevant data. Student7 (talk) 13:53, 2 March 2011 (UTC)

I concur; the work on the boilerplate could start anytime. And if we could build consensus about that boilerplate text, including the specific {{full}} citation(s) (linkable to the particular place in the Census Bureau online data repository that supports the specific claim for any particular Wikipedia page, along with the date of the data and the date that the bot accessed the database) that would support the quantitative assertions, then the bot gurus could later use it and turn a bot loose on adding the text to applicable pages based on the data in the Census report. If anyone starts this, feel free to drop me a line and I'll try to join the effort. Cheers. N2e (talk) 19:20, 2 March 2011 (UTC)

For the record, a current (or near-future) boilerplate, might have "...White = 44.6%..." as a part of its text. The distant future template, might have, for the same information, "((uscensus|white=}}" and be absolutely riddled with this type of template invocation.

My idea of boilerplate is dry facts, no embellishment. Just looked up Demographics of New York City. Quite embellished. Editors would still be free to have any template they wanted, including embellishments. But the one we come up with would be dry as toast, right? Student7 (talk) 18:35, 3 March 2011 (UTC)

I support the idea of using a bot to update the numbers but...good luck. I don't have much faith in the bot group these days and from what I have seen if you submit the bot task today it will be summertime before it gets approved and by then we could have fixed the majority of them manually. I would recommend working with the US WikiProjects in a Census drive to fix the problems. You will probably have better results. --Kumioko (talk) 19:06, 3 March 2011 (UTC)

I was rather hoping for census data to be maintained centrally. Right now we get annual updates (if we are lucky) or monthly or more frequent ones with someone "finding" another guesstimate on their local population increase. Always increase, of course. The idea here is to control format, then release figure updates to the bot. The bot unlocks the template for updating once a year with the official census guesstimates, then locks them again. No changes unless approved.

Our problem in the past has been to figure out when someone is legitimately updating and when some newbie IP is simply vandalizing by altering a few numbers at random. Usually they get reverted (with no edit summary)! But it is a nuisance to have to even worry about it. And unnecessary IMO. Student7 (talk) 13:29, 4 March 2011 (UTC)

I support the idea of a managed bot, opened only occasionally (annually?) to put in basic non-embellished "dry facts" from the census data, with simple boilerplate of the type suggested by Student7. I would just like to ensure that whatever comes out of this effort does not do it (as was done after the 2000 census) with unsourced bot entries. There ought to be a (hopefully, bot-generated) citation to a specific online-available part of the census database that would reliably source the claims made. In the case you mentioned, it might be "...White = 44.6%...<ref name=uscb20yymmdd> {{cite web |title=Census 2010 Database |url=http://www.LinkGoesHereForCensusDB.gov |work=United States 2010 decenial census |publisher=US Census Bureau |accessdate=20yy-mm-dd<!-- date the bot consulted the database to obtain the data -->}}</ref>" as a part of its text, but with a citation. We should not turn a bot loose that adds a lot of text to articles that is difficult to verify, as was done after the 2000 census. Cheers. N2e (talk) 14:22, 4 March 2011 (UTC)

Agree.

Having said that, I've put a possible boilerplate for census data on Wikipedia_talk:WikiProject_United_States/proposed census boilerplate. Not sure there were citations there when I copied it!

Note that we will change and discuss changes on the same page.

Feel free to notify other interested editors/Projects. I've put a notice on the US Project discussion page. Student7 (talk) 19:25, 5 March 2011 (UTC)

WP:Notability (video games)

Posting here as there it seems we have a final draft before this gets promoted. This is based on the GNG, WP:VG/GL and common practices, If anyone has any comments please feel free to discuss them there.陣内_Jinnai 22:40, 28 February 2011 (UTC)

Allowing more users to use huggle

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

No consensus. Mono (talk) 01:34, 7 March 2011 (UTC)

---

Huggle is an antivandalism utility which is used also on english wp, as I couldn't find any policy which says that rollback is the requirement for usage of the tool I think it would be great to allow less strict requirements, it's easy to disallow a person from being able to use it and I see no particular reason for requiring a rollback, so I think it would be good to change the requirements to autoconfirmed + other requirement, edit count and so, what do you think? :) I think easiest way would be some sort of poll whether allow people or not, so if you want you can support or oppose this idea with comment why or how would you change it. Petrb (talk) 19:48, 1 March 2011 (UTC)

Agree (support)

1. yes 250 edits and account age 10 days, Petrb (talk) 19:48, 1 March 2011 (UTC)

Disagree

1. no, most users need more than 10 days to figure out the difference between vandalism and content disputes. --SarekOfVulcan (talk) 20:40, 1 March 2011 (UTC)
2. Strongly oppose If somebody is not yet capable enough to handle rollback they should definitely not be allowed to handle Huggle. I would in fact support a proposition to raise Twinkle to the same bar. Yoenit (talk) 20:43, 1 March 2011 (UTC)
3. No Huggle induce false positives and induce "stress" as user start to compete with one another to revert the vandalism. This induce more errors. --Tyw7  (☎ Contact me! • Contributions)   Changing the world one edit at a time! 21:31, 1 March 2011 (UTC)
4. Oppose, to me there is a significant difference between rollback and autoconfirmed. Rollback is granted by a human being, and that ensures that at least some check is done on the potential rollbacker/huggler. In the case of autoconfirmed, no one can be sure the candidate for huggle has been noticed before and that he is trustworthy. [[CharlieEchoTango]] 21:33, 1 March 2011 (UTC)
5. Oppose. Users granted rollback most likely know what they're doing when it comes to anti-vandalism. New users might not. Guoguo12--Talk--  21:44, 1 March 2011 (UTC)
6. Oppose. Just because Huggle doesn't require rollback rights doesn't mean that there isn't a reason behind that restriction for using it. Not all autoconfirmed users can be trusted with this tool, and having rollback shows that the user is capable of using Huggle properly. Logan _Talk ^{Contributions} 23:09, 1 March 2011 (UTC)
7. Oppose. Far to easy to revert in Huggle, for someone who might not understand exactly what we call vandalism. A reasonable bit of anti-vandalism with Twinkle will show that the user is competent to have the right, it not that there's a huge waiting list of rollback applicants.  Ronhjones  ^(Talk) 23:22, 1 March 2011 (UTC)
8. Oppose - I have seen editors who were rollbackers and still had problems using Huggle responsibly. The minimum requirements for Huggle should be rollbacker. ~~ GB fan ~~ 23:50, 1 March 2011 (UTC)
9. Oppose in agreement with Yoenit and GB fan. I have both rollback and reviewer and I don't think I should be using Huggle. – Allen4names 03:36, 2 March 2011 (UTC)
10. Strong oppose There are indeed many rollbackers who use huggle incorrectly, let alone those who aren't proven vandal fighters. Huggle essentially performs the same task as rollbacking, so opening it up would render the entire rollbacker user group obsolete, in favor of a much more dangerous tool. No way. Swarm ^X 03:40, 2 March 2011 (UTC)
11. Strong oppose - I'd support the complete removal of huggle. In my opinion, countervandalism should be done in the traditional environment - examining diffs. As it is, countervandalism has turned into some sort of a game, and allowing more users to play is not a good thing. Ajraddatz (Talk) 04:47, 2 March 2011 (UTC)
12. Oppose Huggle can be quite dangerous if used inappropriately. Rollbackers have been checked (a tiny bit, but still) by a human. We already have problems with users reverting wrongly. Countervandalism has become a game (This is not completely bad), and it'll be dangerous if newbies decide to join. ManishEarth^{Talk • Stalk} 12:00, 2 March 2011 (UTC)
13. Oppose there's a lot of abuse of rollbacker-only tools; NO WAY! --Posted on 17:34 on 2 March in 2011 (UTC) by Highspeedrailguy 17:34, 2 March 2011 (UTC)
14. Oppose per my statements in the comments section.--Cube lurker (talk) 17:44, 2 March 2011 (UTC)
15. Oppose There is way too much roboticization on Wikipedia. The usertalk templates are worst, but these scripts are a bad problem too. I'll stop short of wanting to eliminate them completely, but they should have fewer users, not more. 71.141.88.54 (talk) 01:22, 3 March 2011 (UTC)
16. Oppose Huggle should be at the same level of trust as AWB, a high level that is proportional to the high level of damage that is possible to inflict if the tool is improperly used. Sven Manguard Wha? 07:06, 3 March 2011 (UTC)
17. We have too many incompetent people reverting good edits already. /ƒETCHCOMMS/ 15:49, 4 March 2011 (UTC)

Discussion

• Though I'm not entirely sure on this, I think having rollback is also a technical requirement, as huggle uses the rollback facility when reverting. –xeno^talk 20:04, 1 March 2011 (UTC)

No it isn't. Petrb (talk) 20:06, 1 March 2011 (UTC)

Yes, I edit conflicted with you trying to remove my comment. –xeno^talk 20:23, 1 March 2011 (UTC)

So what is the technical requirement? If there aren't any, then what are we even discussing?--Kotniski (talk) 07:15, 2 March 2011 (UTC)

Huggle uses the API's rollback feature. It could just as well use "undo", but there's no undo feature in the API. To undo, Huggle would have to fetch the previous revision's revid, then the wikitext of that revision, and finally reupload the whole wikitext to the page. This makes it a bit slower, and less efficient. ManishEarth^{Talk • Stalk} 11:48, 2 March 2011 (UTC)

So in fact you do have to have rollback enabled in order to use Huggle?--Kotniski (talk) 17:57, 2 March 2011 (UTC)

Yup. Though theoretically, Huggle can go without it, but it'd require a small change by the devs. ManishEarth^{Talk • Stalk} 08:46, 3 March 2011 (UTC)

So (moot as the question is, since it seems to have been soundly rejected), the proposal would actually simply mean giving the rollback privilege to a greater number of users?--Kotniski (talk) 16:58, 4 March 2011 (UTC)

• Why should we feel confident that a new user with that little experience will be able to tell the difference between vandalism and good faith unproductive edits?--Cube lurker (talk) 20:27, 1 March 2011 (UTC)

Indeed somehow I agree with you, perhaps inceasing the requirements a bit? There are many users who use twinkle and are not rollbackers and many others who can constructively help with vandalism anyway huggle is a tool only people familiar with that know. Petrb (talk) 20:40, 1 March 2011 (UTC)

Have you read the signpost from today? Wikipedia:Wikipedia_Signpost/2011-02-28/News_and_notes. Yoenit (talk) 20:44, 1 March 2011 (UTC)

The only way to 'learn' Huggle is to use it, and it's the responsibility of any editor who sees someone using it incorrectly to correct them. I've done it several times and the users have been apologetic and eager to fix and learn from their mistakes. It's all part of learning. Swarm ^X 03:47, 2 March 2011 (UTC)

Actually I strongly disagree with this. There is a serious foundation of policy knowledge that's required (or damn well should be) before you even touch huggle. It comes from manually reverting vandalism. Manually choosing and applying proper templates. Learning to take a look at the edit and ask yourself, is it vandalism? a new user who doesn't understand policy? a good faith edit that accidentaly broke formatting? or any of the other types of edits that all need to be handled differently.--Cube lurker (talk) 17:43, 2 March 2011 (UTC)

Considering I'm in complete agreement with that statement, I have a hard time seeing where the "strongly disagree with this" comes in. Swarm ^X 23:39, 2 March 2011 (UTC)

I'm most likely misreading your comment. I was reading The only way to 'learn' Huggle is to use it as dive in with huggle and learn policy as you go, where I was focusing on getting a foundation in policy then move to huggle. Appologies for misunderstanding.--Cube lurker (talk) 15:59, 4 March 2011 (UTC)

Oh, no problem. Let me try to clarify. I was replying to Petrb, who suggested increasing the requirements to use huggle because getting the rollback right doesn't automatically make you competent to use Huggle. My point was that if you've been granted rollback, you've presumably shown that you can responsibly identify and revert vandalism, and you should be trusted to use Huggle. At that point, the only way you can learn it is to use it; further increasing the requirements won't help anything. So yeah, I was only talking in the context of rollbackers; I didn't mean to imply that anyone should be able to use Huggle to learn by experience. Hope that cleared up my comment. Swarm ^X 16:55, 4 March 2011 (UTC)

Got it. That sounds reasonable. Think we're both ont he same page.--Cube lurker (talk) 16:59, 4 March 2011 (UTC)

• Comment I stopped by this page because I just noticed I no longer have "undo" buttons, and am wondering what happened. Maybe I'll find some discussion someplace, but it doesn't seem like a useful removal. 71.141.88.54 (talk) 01:23, 3 March 2011 (UTC)
  • Wikipedia is changing over it's code base from whatever it was before to the mw:API, which is HTML5 compatible. I read above that there is no undo feature in the API, which explains why the undo button is gone. Personally I didn't notice that, but if you say it's gone, it might be. Someone with actual technical knowledge could/should probably give you a better answer. Sven Manguard Wha? 01:53, 3 March 2011 (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.

Template:Worldcat

I wish to add more functionality to the current Template:Worldcat. I have created a proposed version as well as described the new usage on the talk page. Basically the proposed idea is to add a new parameter OCLC for entries that do not have an Identity ID; as well as adding an accessdate parameter to be shown when it was retrieved. The new code will check if you are using either the ID or OCLC parameters and provide a warning otherwise. The current usage would be unaffected for any article already using the ID param, new usage below:

{{Worldcat|name=Test|oclc=222395773|accessdate=March 2011}} would produce:
Test in libraries (WorldCat catalog). Retrieved on March 2011.

similarly:

* {{Worldcat|name=Test|id=lccn-n50-34079|accessdate=March 2011}} would produce:
Test in libraries (WorldCat catalog). Retrieved on March 2011.

Please feel free to view and edit my proposed version to better refine it, or offer any suggestions. Thank you. Who (talk) 23:08, 1 March 2011 (UTC)

Qualification for being a reviewer

My proposal is that no editor ought to be allowed to review an article at a level that they themselves haven't reached. In other words, if you haven't written a good article or a featured article then you have no demonstrated expertise to review someone else's GAN or FAC. Malleus Fatuorum 03:08, 3 March 2011 (UTC)

Is there an actual problem this solution is designed to resolve? Lack of reviewers is a problem that has plagued Wikipedia for years. Creating artificial barriers to willing volunteers will simply exasperate the existing lack of supply. Additionally, FAC has a reputation for being rather cliquish in nature. Implementing a restriction that only existing members of the FA club are able to comment on the worthiness of others efforts will simply compound this widely held perception and breed animosity to the FA process. --Allen3 ^talk 03:42, 3 March 2011 (UTC)

No, of course there's no problem, everything's just hunky-dory, my mistake. Malleus Fatuorum 03:46, 3 March 2011 (UTC)

I personally would oppose this, but only because I can't write a good article to save my life. It doesn't mean that I don't have a literary skill set, I'm just better at reviewing than writing. Seriously read one of my books and you would agree. That said, I agree with Allen3 on many points. Any input is better than no input, IMHO. Who 05:12, 3 March 2011 (UTC) sorry my sig got scrubbed. Who (talk) 05:15, 3 March 2011 (UTC)

I oppose this, not because I don't think there's a problem, but because I think your solution needs adjustment. Not everyone is an excellent writer, but that does not mean that they don't know what to look for in conducting reviews. Instead of mandating that everyone produce content in order to review content at that level, why not mandate that new reviewers get mentored into full reviewer status. Case in point: In my first and only GA review, I asked an experienced reviewer to check my work. I got some things right, but I also missed a bunch. In the end, it went rather well, everything got caught and fixed, and I learned a lot about what to look for. If I decided to continue to do reviews, I would have continued to ask for guidance until I performed a review where the second reviewer did not see anything that I missed. It might have taken three or four or five tries, but in the end there would be two competent reviewers instead of one. Perhaps training is a better option, as it both includes those that make for good reviewers but bad writers and excludes those that make good writers but bad reviewers. Thoughts? Sven Manguard Wha? 07:04, 3 March 2011 (UTC)

Indeed, people may know how something should be done without being able to do it themselves. Otherwise, we wouldn't have, well, critics in general. ♫ Melodia Chaconne ♫ (talk) 07:07, 3 March 2011 (UTC)

you can't vote for president until you've been one ;) Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 08:12, 3 March 2011 (UTC)

This would discourage/forbid editors who may be experts or have access to good sources who don't happen to have got an article to GA/FA from commenting at all - surely this would make for a poorer quality review and poorer articles.Nigel Ish (talk) 22:12, 3 March 2011 (UTC)

• Comment I've done quite a few FA reviews including at least one to an article that Malleus submitted, and don't even have a Good Article to my name, so I suppose I'm a fairly extreme example of the sort of reviewer that this proposal seeks to weed out. As you'd expect I think this sort of rule is unnecessary and unhelpful, but I suppose I would say that wouldn't I. I'm especially not convinced that FAC reviewing should only be done by FA writers, as this is a collaborative process with multiple reviewers and FA delegates who can judge the reviews and ignore unhelpful ones. I accept that GA is somewhat different because one reviewer can pass or fail an article. But if it helps keep the peace, I will avoid reviewing further articles by Malleus Fatuorum, ϢereSpielChequers 00:27, 4 March 2011 (UTC)
• I have a hard time believing that doing this would be anything less than detrimental to the GA/FA review process. Second, I don't see how writing a GA/FA makes you more competent to review GANs/FACs. Who would say when "you've written a GA"? Nominating a good looking article and fixing minor mistakes brought up doesn't automatically make you competent to review GAs, and never doing this doesn't mean you're incompetent. Third, the "you can't comment on it unless you've been there" sentiment simply valid. Fourth, I don't see a problem that needs fixing. Swarm ^X 17:15, 4 March 2011 (UTC)
  • second point is a good one. it's not always clear who gets how much credit for writing an article. Rd232 ^talk 18:08, 4 March 2011 (UTC)

Improving review processes

Moving beyond the original proposal, which hasn't had any support, there is a real issue motivating that proposal. Now I would have thought more emphasis on collaboration would be the way to go, to ensure that (for GA) reviews don't rest solely on the shoulders of a single editor who might not be qualified enough. Get a minimum of 2 or 3, and on average it should be OK. Alternatively, and more in line with the original proposal, get the relevant community (FA/GA) to approve reviewers, based on some defined standard in which contributing FAs/GAs would feature as providing lots of credit, but not be required (necessary credit for approval can be reached without that). We could also consider ways to make reviewers more accountable, with a clear list of review contributions. Rd232 ^talk 08:11, 3 March 2011 (UTC)

I think there is a case for doing something close to this at GA where currently a sole review by any editor other than the article creator can include promoting the article to GA status. At FA we have FA delegates who close FAC discussions, perhaps GA needs a similar role but with the added responsibility that they can promote as GA an article that they have reviewed, and even where they are the sole reviewer. This would mean that any editor could still review at either GA or FAC, but only someone who has been trusted to do so by the community could close a discussion and decide whether or not to promote an article. So a single review could still lead to a GA being promoted or not, but only if a "GA delegate" did the review or made the call based on another editors review. As an aside, I'm not convinced that either reviewer or delegate is the best title for this. WP:Reviewer is already in use and I think delegate is a title that we have given a very different wiki meaning to its real world meaning. ϢereSpielChequers 15:32, 4 March 2011 (UTC)

GA nominations can sit for months awaiting a review from a single editor. How long would they sit waiting for a second or third editor to review them? Or, in the case of the alternative option, how much longer would they sit waiting for a "GA delegate" to promote them? The great thing about the current system is that GAs can either be reassessed by the community or by a single editor and delisted at any time. GA reviewing is a much more massive operation than FA reviewing, hence it naturally needs to be quicker, more flexible, etc. While a good idea in theory, I don't see how it could work practically. Swarm ^X 17:06, 4 March 2011 (UTC)

"How long would they sit waiting for a second or third editor to review them?" - depends. Additional reviewers would be able to draw on the work of the first, and contributing to an existing review discussion is less daunting than taking lead (and often sole) responsibility. So paradoxically, you might get more people move into reviewing, if you can create a clear path for reviewing baby steps through contributing to reviews led by an experienced reviewer. Besides which, waiting months for a competent reviewer isn't a problem per se (WP:DEADLINE); far better than having people pitch in who aren't really interested and risk the review being too superficial. Rd232 ^talk 18:06, 4 March 2011 (UTC)

Would this slow the process down? Well that depends on the proportion of the current GA reviews that are done by people who would merit "GA delegate" status. If the bulk of the GA reviews are already done by people who are already at the standard to do a GA review on their own, then my proposal should not greatly impact waiting time, and as RD232 pointed out it might even speed it up, both for the reason RD232 gave and also as it could encourage reviews from people like myself who check some but not all aspects of articles. But also there is no deadline, better to get something like this right than have them done to a schedule. Though it would be important to appoint all the suitably active and accurate reviewers as GA delegates. ϢereSpielChequers 19:17, 4 March 2011 (UTC)

Well, that pretty much answered my concerns. At the same time, while we have no deadline, backlogs are bad. Excessive waiting is bad. I wouldn't like see the GAN backlog get any more overblown due to waiting time when most reviewers are perfectly competent already. If process wouldn't be affected too much, it's definitely something I'd support. Swarm ^X 01:08, 5 March 2011 (UTC)

The other direction

Personally, I'm all for going in the complete opposite direction, here. We should just mark the whole GA/FA process historical and forget about it. Regardless of original intents (which, I believe, were good), the reality of the current GA/FA ecosystem is that it consists of an insular group of people who seek to provide ego boosts to themselves and others associated with the group. I, for one, will not be a part of it.
I don't expect that my opinion here will be popular, of course. As a matter of fact, I expect it to be largely ignored. There's nothing wrong with that, but I think that it's still important to state. People such as myself generally avoid those of you involved with GA/FA due to your collectively prickly nature (in the area concerned with the GA/FA process, at least). I have done some MOS work, and may contribute to parts of the MOS again, at some point in the future. Unfortunately though, the FA/GA process has become a rather exclusive and, as I said above, insular group (dare I say elitist?). I simply feel that it is the antithesis of what Wikipedia should aspire to, so I have no real motivation to enable it. I know that I'm not alone in basically ignoring the whole system (which, interestingly, is easy to do. Happily.). Regards
— V = IR (Talk • Contribs) 02:33, 6 March 2011 (UTC)

You're not alone, although I would go further and include at least some of the most vocal the MOS regulars in that assessment. Many MOS-related discussions are simply impossible to contribute to due to a certain group of users, and enough MOS "guidelines" seem to be decided on and then enforced as if policy by small insular groups that when I hear about a new MOS prescription decided on without any community discussion I just chalk it up as par for the course. I too just try to ignore them whenever possible. Anomie⚔ 15:15, 6 March 2011 (UTC)

I think it helps the articles to have people concentrate on individual ones to try and bring them up to a good standard. I definitely would not discourage that. And as to stopping people doing a review who hadn't themselves done work to that level, hasn't anyone heard of film critics? Do you really want to get rid of such opinions? Do you expect artists for instance to work in a vacuum with no feedback? Dmcq (talk) 15:41, 6 March 2011 (UTC)

Whether V = IR is being cynical or serious, they make a very, very good point. A large number of people who "write GAs" tend to view themselves as vested contributors who increase in value with each icon they add to the top of their userpage. They then presume to look down on people who haven't done GAs. This commonly manifests itself as an oppose in an RfA or the like. It's really quite nauseating. While doing away with GAs entirely is...one option... a more practical option perhaps would be to do away with "keeping score" when it comes to GAs. This probably wouldn't be a successful community proposal either, but people who track GAs as if it were a game certainly tend to be a problem. Swarm ^X 01:22, 7 March 2011 (UTC)

Automatically welcoming new users

The Welcoming committee has a huge task, to try and introduce new editors to the basic aspects of the wiki once they make a contribution.

My proposal would be to use bots to automatically leave a message with registered users once they make their first edit into the project namespace. Regardless of wither this is a positive or negative edit, I think a simple message could be generated to neutrally present the five pillars, some basic links to editing, and a handful of other useful links. This would in turn automatically show users the broader aspects of the community and perhaps lead them to make more constructive and focused edits. More specific welcoming messages could be used if the first edit is to a user page, a talk page, and so forth.

This would not negate the use of the Welcoming Committee, they could still provide a more specific and human welcome. But for the most part, their basic duty could just as easily and more accurately be performed by automation. Thoughts? --NickPenguin_(contribs) 06:13, 6 March 2011 (UTC)

This is a Perennial proposal ;) -- œ^™ 08:48, 6 March 2011 (UTC)

See also User talk:Hannibal/Welcomecreation#Use the user's talk page for confirmation (a proposal intended as an alternative to the confirmation page for newly registering accounts) prompted by the hubbub caused by outreach experiments adding a preloaded inputbox "Create your user page" on experimental versions of the confirmation page.  --Lambiam 15:37, 6 March 2011 (UTC)

Ah bummer, sometimes a good idea is just the same old unpopular idea. --NickPenguin_(contribs) 16:54, 6 March 2011 (UTC)

One unusual aspect of this perennial is that some of our sister projects have successfully implemented it, Commons has been doing it for years. What we don't know is whether the advantage of welcoming those newbies who currently get ignored offsets the disadvantage of giving an impersonal welcome to those newbies who would otherwise have received a personal one. I did make a proposal some time ago to try and achieve the best of both worlds by using a bot to welcome all the newbies who were still unwelcomed a week after their first edit - strategy:Proposal:Welcome all useful new users, if necessary by a bot. Perhaps now would be a good time to refloat that idea? ϢereSpielChequers 01:15, 7 March 2011 (UTC)

I think that sounds like a great idea. I'll definitely expand on my thoughts if there's another proposal. Seems like a bot welcome is better than no welcome any day of the week. At least a welcome template tells newbies where to get help and answers to their questions- whereas an "unwelcomed" newbie will have no clue where to go for this. Swarm ^X 02:27, 7 March 2011 (UTC)

Maybe welcoming the people who fall through the cracks might be a good idea, after a week they're probably not goingto get noticed by anyone. More generally tho, how personal are the welcomes from the Welcoming Committee? Is pasting a template on a talk page really a personal welcome? Certainly humans can give more appropriate welcoming messages, like if the user makes an nonconstructive edit, but for general editing advice and policies, I think a bot would do just as good or better. --NickPenguin_(contribs) 04:37, 7 March 2011 (UTC)

Exactly what I was thinking. How impersonal is a bot compared to a human when all it does is paste the exact same welcoming template a human would? Another point to consider is that if an account creator has the option enabled a welcome template is automatically placed on any account they is create. This is on Wikipedia. Swarm ^X 05:46, 7 March 2011 (UTC)

Just for the record: it's much more important to have a welcome template on commons to inform the user how to proceed within the context of the many different languages. This is not an issue here. Magog the Ogre (talk) 05:53, 7 March 2011 (UTC)

I welcome a lot of newbies, but I almost always use one of four options on friendly: The plate of cookies, welcome your first article didn't meet guidelines, welcome IP vandal and welcome vandal. Two of those are tailored level 1 warnings and a third is almost a warning - so I fit the usual pattern of personalised relevant info for problem users but an impersonal welcome for our best newbies. Occasionally I will tailor it by adding a relevant wikiproject to the message. Maybe we need an easier way to do that? Or maybe we could get the bot make their message personal by mentioning some wikiprojects that are relevant to the articles they edit? If we want to reverse the trend of fewer editors joining us, then personalising the welcome message would be sensible. Better still we need an analysis done of the hundreds of thousands of users welcomed and the welcomes they've been given so that we can identify which welcome messages work best and encourage their use. ϢereSpielChequers 10:32, 7 March 2011 (UTC)

I did some counting.

Of the last 1000 user creations of February, 461 had one or more contributions. Of those 461, 278 (60%) had no talk page yet.

Of the last 1000 of January, 356 had at least one contribution. Of those, 166 (47%) had no talk page.

I think that means that half the users who did more than only register received no welcoming message.

Here is a simple experiment. For a couple of days, we send randomly about half the new users an automated welcome message. For the other half, business as usual – maybe someone welcomes them personally, maybe no one does. (Whether someone does or does not gets an automated message should not be really random but be decided in a way that can easily be repeated afterwards, such as whether the user name has an even or odd length.) Then we check say two months later if there is a difference in activity between the two groups.  --Lambiam 18:10, 7 March 2011 (UTC)

I think that's a great idea. If we determine which method best increases the number of return users then it would help us move forward. --NickPenguin_(contribs) 01:27, 8 March 2011 (UTC)

Reducing boilerplate below edit box

Between the edit box and the box below it (the one that allows you to enter wiki markup and such stuff as Greek and Hebrew letters by clicking) there are several lines of boilerplate text:

Content that violates any copyrights will be deleted. Encyclopedic content must be verifiable. You irrevocably agree to release your contributions under the CC-BY-SA 3.0 License and the GFDL. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license. See the Terms of Use for details.

and:

If you do not want your writing to be edited, used, and redistributed at will, then do not submit it here. All text that you did not write yourself, except brief excerpts, must be available under terms consistent with Wikipedia's Terms of Use before you submit it.

(These texts can also be found at the interface pages MediaWiki:Wikimedia-copyrightwarning and MediaWiki:Wikimedia-editpage-tos-summary.)

By now, after some 30,000 edits, I just ignore them. So why do they bother me? Because this boilerplate stuff takes up real estate at an inconvenient place: I regularly find that I need to scroll the window down and up, again and again, to switch between the place in the editing window where I'm entering text and the Non-Latin-letters-etcetera box below it, since I want to have immediate feedback, but they don't fit together in the browser window. It is annoying to do this scroll down, click, scroll up for every single letter you enter. (I could opt to have fewer "rows" in the editing window, but then it becomes a peephole through which it is harder to keep an eye on the context.)

The proposal is:

Add an option (disabled by default) to the list of options at Special:Preferences/Editing to "Show Wikimedia copyright warning and terms-of-use summary before preview and edit box".

 --Lambiam 15:04, 6 March 2011 (UTC)

I doubt any developer would get around to adding such an option, and disabling it by default would never fly; we want IP users and newbies to see that text. To disable it hide that text for yourself, add this to your skin.css:

span.editHelp { display:none; }
#editpage-copywarn { display:none; }
div.mw-tos-summary { display:none; }
#editpage-copywarn2 { display:none; }
span#minoredit_helplink { display:none; }

This could probably be turned into a Gadget if there were sufficient demand. Anomie⚔ 15:20, 6 March 2011 (UTC)

I think you have misunderstood. The default (disabled) would let the page be exactly as before: with the boilerplate between the edit box and the goodies box. Enabling the option will move the boilerplate up to before the edit box, where it will still be quite visible, just as the anon edit warning "You are not currently logged in. ..." before the edit box is quite visible. But the CSS stuff does the trick for me; thanks.  --Lambiam 15:58, 6 March 2011 (UTC)

Yeah, I misunderstood. Sorry. Anomie⚔ 00:01, 7 March 2011 (UTC)

Well, it stopped working; an admin deleted my skin.css page, stating: creates copyright headaches. :(  --Lambiam 00:22, 8 March 2011 (UTC)

Proposed layout change for "Deletion sorting" notes in XfDs

The current layout renders {{Deletion sorting}} notes on XfD pages similarly to the !votes cast. This makes XfD pages harder to understand. I propose changing the layout so that notes are more clearly separated from !votes, using a colon to generate an indented list item without a bullet, and eliminating the bold formatting of the word "Note". A mock-up is shown below. - Pointillist (talk) 12:56, 7 March 2011 (UTC)

Note: This debate has not been included in any list. Can you believe that?

• Support – looks like an improvement to me. Also makes the delsort messages actually easier to spot, for the same reason – now they look too similar to the !votes.  --Lambiam 18:19, 7 March 2011 (UTC)

Non-admins moving pages with no Talk redirect

Pretty-much in the title: what would you think if non-admins could move pages without leaving a talk page redirect? Maybe the software could check for inbound links to the talk page and not present that option if they exist. The vast majority of talk pages have no incoming links, and the ones that do probably shouldn't be moved. The article/page would still leave a redirect, so no harm done. ▫ JohnnyMrNinja 19:34, 7 March 2011 (UTC)

A place for more proposals

Hey, everyone. This isn't a proposal itself per se, but I wanted to drop a note here to point out a new place where fully-formed proposals that have some community support can be taken if they need help from the Wikimedia Foundation. Some of you know that the WMF started a fellowship program for Wikipedians, academics, and others to come join the organization for a limited time to work on a specific project or projects (that's my job). Well, now there's an open proposals process for new fellowships on Meta, so please consider it when you're thinking about the future of Wikimedia and moving your proposals for improving English Wikipedia forward. Thanks! Steven Walling at work 23:51, 7 March 2011 (UTC)