Misplaced Pages

Revision as of 03:51, 1 March 2011

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

• WP:VPR
• WP:VP/PR
• WP:PROPS

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 Misplaced Pages:Village pump (idea lab).
• Proposed software changes that have gained consensus should be filed at Bugzilla.
• Proposed policy changes belong at Misplaced Pages:Village pump (policy).
• Proposed WikiProjects or task forces may be submitted at Misplaced Pages:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.

Centralized discussion Village pumps policy tech proposals idea lab WMF misc Voluntary RfAs after resignation Allowing page movers to enable two-factor authentication Rewriting the guideline Misplaced Pages:Please do not bite the newcomers Should comments made using LLMs or chatbots be discounted or even removed? For a listing of ongoing discussions, see the dashboard. view edit history watch archive talk purge

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 Misplaced Pages, 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 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 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 19:36, 21 February 2011 (UTC)

• Support. davidwr/(talk)/(contribs)/(e-mail) 16:37, 21 February 2011 (UTC)
• Support. Der Wohltemperierte Fuchs 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 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 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. Misplaced Pages 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 _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 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 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 ☯ 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 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 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 ☯ 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 Misplaced Pages 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)

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 Misplaced Pages: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 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 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 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 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 19:46, 26 February 2011 (UTC)

My only concern is in regards to a point Joe raised on my talk page, that Commons and Misplaced Pages 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 Misplaced Pages as well. If you created a page with the same name on English Misplaced Pages, it would overlay the content on the Misplaced Pages (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 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 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 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)

• 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)
• Weak Support per the test of Mr.Z-man - giving this right here is safer to English Misplaced Pages 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 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 due to the potential damage this can cause. A little too much power just to be handed out to everyone. It's not exactly difficult to become autoconfirmed; potential of vandalism etc. Swarm 03:51, 1 March 2011 (UTC)

Implementation Proposal: Enable for all rollbackers

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)

Broadcast content transcription and verification program

A situation has come up in regards to a TV broadcast and WP:V. The discussion can be found here, but the crux of the problem is how WP:V applies to broadcast content once it is no longer available. In this particular instance, while the BBC archive all their broadcasts, the vast amount of the archives are only available to people involved in the production of the programme (outside of those programmes that are commercially available). The interpretation of the WP:V which we have is that just existing in an archive isn't completely consistent with WP:V, and such archives need some form of public access so that editors can verify content. This is causing a problem for a particular editor who wants to include quotes from a current affairs show that can no longer be accessed by the public.

Since TV/radio broadcasts seem to be the main medium especially for current affairs interviews, it would be a shame if we couldn't use this material, and a policy which is supposed to enhance Misplaced Pages starts to become a hindrance. I was wondering if initiating a "transcription verification" service might be a way to incorporate the material without compromising WP:V to an unacceptable level. Maybe some form of this already exists? The basic idea would be in a typical interview/debate, a quote (along with the context i.e. such as a question) is fully transcribed for use on a particular article, and two independent editors who haven't edited the article could verify that the transcript is an accurate rendition of the quoted material. In the example of the BBC and this particular problem, the shows are available on iplayer for a week after broadcast, which would allow enough time for the transcription and the verification.

If this idea is a complete no-go I understand, but we have an editor at the discussion who is willing to trial the system if we can try it. Betty Logan (talk) 03:52, 21 February 2011 (UTC)

I took a look at that link, but it's just the one comment. What I'm wondering is who is interpreting WP:V to mean that we can't use TV shows as sources, even when those shows aren't archived? WP:V says, "The principle of verifiability implies nothing about ease of access to sources." Now, I would be comfortable excluding such sources for information about living people under the more stringent sourcing requirements laid out by WP:V. Similarly, if someone is trying to include an incredulous claim based upon "I saw it on BBC News yesterday", WP:REDFLAG ("Exceptional claims require exceptional sources") could also be invoked. And, of course, it would be better to have a print source if one were available. But, all of that being said, I don't believe WP:V can be read to generally state that un-archived television programs cannot be used as sources. Is this being discussed somewhere else? Qwyrxian (talk) 00:40, 23 February 2011 (UTC)

Misplaced Pages's Most Wanted (Pages)

I think Misplaced Pages has progressed far enough that it's faults are becoming more apparent. It seems that recently (the last two years or so), community work has been focused on the nuances of existing policy, rather than the less functional aspects of the wiki model. Basically, given enough time, wikipedia will eventually have generated articles on all subjects. However, this model suffers from the fact that people find some stuff more interesting than other stuff, and the extremely popular subjects are basically exhausted in terms of new articles. This leads me to think that for the wiki to become more well rounded, the areas of missing content should be addressed.

It seems that about a year ago, the process that generated pages on Special:WantedPages was sabotoged by a new mode of editing, where redlinks get added to templates. Because of this, links to missing pages got disproportionately measured, since any article added to a popular template would make it seem highly requested, while articles only redlinked in mainspace text would be easily missed. There is also Misplaced Pages:Most wanted articles, which was created using a database dump in 2007. This page only includes links from mainspace articles, not templates. This circumvents the problem generated by Special:WantedPages, but there is no automated updates or removals to this process.

There are two other processes worth mentioning: Misplaced Pages:WikiProject Missing encyclopedic articles, which is a project geared to create articles that have been identified as missing through a variety of other sources. There is also Misplaced Pages:Requested articles where users can add red links to the subject-based lists.

Basically I am looking for ideas. I guess there's two issues, methods of discovering missing articles and methods of creating missing articles. I think this is the sort of problem that would be served well by applying the original goals and ideals the wiki, since when it started out there was a great deal of interest and momentum in article creation. As things are right now, there are huge gaps in certain areas, and this is a community issue. What are your thoughts? --NickPenguin_(contribs) 00:54, 22 February 2011 (UTC)

Not really an answer to your questions but: aren't red links still strongly discouraged in templates? That's what Misplaced Pages:Red link says. Pichpich (talk) 01:16, 22 February 2011 (UTC)

Not always - "The exception is redlinks in navboxes where the articles are part of a series or a whole set ..." - which fits most of the large templates which have been the issue here. Shimgray | talk | 03:07, 25 February 2011 (UTC)

Proposal to Acquire a Professional Musopen Account for Misplaced Pages

Discussion at Portal talk:Featured sounds/Musopen. Sven Manguard Wha? 08:02, 22 February 2011 (UTC)

A-class

How about a top icon for A-class articles? I made a template already. It's at Template:Class A article.

~~Awsome EBE123~~(talk | Contribs) 12:51, 22 February 2011 (UTC)

GA and FA are wikipedia-wide standards while A-class is wikiproject specific. Not all wikiprojects use A-class and if one wikiproject makes an article A-class that does not mean it is an A-class for another wikiproject. For example Thinis is assesed as A-class for Misplaced Pages:WikiProject Ancient Egypt, while Misplaced Pages:WikiProject Former countries considers it only B-class. Yoenit (talk) 13:17, 22 February 2011 (UTC)

I'm not a big fan of the idea. Actually, I'm not a big fan of the GA top icon either. For the casual Misplaced Pages reader, I think the multiple icons are confusing because their meaning is not that obvious. In particular, the fact that a good article is "not as good" as an A-class article but "better" than a B-class article is somewhat counter-intuitive. Furthermore, the process that identifies A-class articles is not transparent. For the avid Misplaced Pages reader/editor, there's always the possibility to set the preferences to include the user interface gadget that automatically displays the assessment. I highly recommend it if you're not already using it. Pichpich (talk) 13:21, 22 February 2011 (UTC)

This whole classification reeks of subjectivity. I suggest the "EmmanuelM index" for article greatness, which is the ratio of total visits / number of edits, both over the last 30 days. In other words, a great article is an article that many people read but few find something that needs to be corrected. Emmanuelm (talk) 20:02, 22 February 2011 (UTC)

Speaking from WP:PRIMATES, some of the articles in our top 25 for hits get very few edits, but are in really crappy condition. Monkey and Slow loris quickly come to mind (although we have a collaboration slowly working on the latter at the moment). – VisionHolder « talk » 21:25, 22 February 2011 (UTC)

I was going to propose this and I think it's personally an awesome idea, but we need to standardize this site-wide first before we can really make progress with this proposal. Kevin Rutherford (talk) 06:19, 24 February 2011 (UTC)

Archive Protection

I got an idea of having an new type of protection on archived pages that is not supposed to be edited like RfA. The protection makes no one can edit it. Maybe that when bureaucrats approve or rejects the request, it automatically protects the page.

~~Awsome EBE123~~(talk | Contribs) 12:58, 22 February 2011 (UTC)

Is there currently a problem with vandalism on the RfA archive pages? If not, then what is the point of protecting them. Yoenit (talk) 13:21, 22 February 2011 (UTC)

Although probably unnecessary, and technically not worth the trouble of implementing, It's still not a bad idea: There's no reason anyone should be editing those pages anyway, and in the off-chance that they do get vandalized, and I can see that happening as someone wanting 'revenge' on an admin for some past block, it's possible that the vandalism can go uncaught for a long time, especially if the admin is inactive, as presumably noone other than the admin would have that page on their watchlist. -- œ 18:42, 22 February 2011 (UTC)

As there is always the possibility of unforeseen future reasons to edit closed RfAs, I don't think it's necessary to preemptively protect them. –xeno 18:49, 22 February 2011 (UTC)

Allow users to suppress the external links icons in their preferences

Basically wrapping everything (articles, watchlists, special pages, etc... in <div class="plainlinks">. This icons can be annoying to those of us who are fine with the difference in tone as the only way to tell internal apart external links. Headbomb {talk / contribs / physics / books} 00:18, 23 February 2011 (UTC)

Try adding this to your skin.css:

a.external {
    background:none !important;
    padding:0 !important;
}

That could probably be turned into a gadget, if there were sufficient demand. Anomie⚔ 01:59, 23 February 2011 (UTC)

I'm not sure what the proposer means. Are there external links icons? Where? GeorgeLouis (talk) 03:44, 23 February 2011 (UTC)

the arrow in the box to the right of this text is what he's talking about. Sven Manguard Wha? 04:22, 23 February 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 Misplaced Pages vets edits."
• 3. "It's a profit organization."

Survey visitors about Misplaced Pages 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:

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

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 Misplaced Pages 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 Misplaced Pages. 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 14:36, 23 February 2011 (UTC)

Comment: Misplaced Pages 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 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 Misplaced Pages and correct some of the misconceptions of Misplaced Pages 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. Misplaced Pages'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 15:22, 23 Feb 2011 (UTC)

(edit conflict) Why not notify the people at Misplaced Pages:OUTREACH? Also, I suggest we make the advert a bit less flashy and obtrusive. ManishEarth 15:29, 23 February 2011 (UTC)

I'm against putting that banner on Misplaced Pages 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 Misplaced Pages 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 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 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)

• 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 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 Misplaced Pages 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'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 Misplaced Pages 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 Misplaced Pages 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. Misplaced Pages is just a website. Press X and see what happens. Feedback 05:09, 27 February 2011 (UTC)

• Misplaced Pages noticeboards
• Misplaced Pages proposals
• Pages automatically checked for accidental language links