Wikipedia talk:File mover/proposal

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

The contents of this page was moved from the Village Pump (permanent link) and bugzilla:27927 was filed by Sven Manguard to implement the new userright. :| TelCoNaSpVe :| 06:01, 8 March 2011 (UTC)