Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

New ideas and proposals are discussed here. Before submitting:

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

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

Transferring over "filemover" tool

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)

 Done here. Ruslik_Zero 09:17, 8 March 2011 (UTC)

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(edit conflict)

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

Implementation Proposal: Three month trial as userright

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

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

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

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

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

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

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

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

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

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

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

Implementation Proposal: Enable for all autoconfirmed users

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Implementation Proposal: Enable for all rollbackers

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

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

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

Compromise

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

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

---

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

Add redirectsuppress to the File mover right

I propose that we add redirectsuppress to the file mover right so we could instead of leaving the File:ThisGuyIsAJackass.jpg redirect for an admin to come by and delete the thing. I figure if we're trusted to move images, we should be able to suppress useless redirects. Thoughts? Also, consider bundling this with ALL namespaces? It'll be useful for us non-admins to undo pagemove vandalism, clean up after ourselves and will reduce the burden on current admins. --Addihockey10 ^e-mail 14:29, 13 March 2011 (UTC)

On the one hand that would be an excellent tool for me to have, these DSC##### image names just need to disappear forever. On the other hand, it's very much a matter of trust, and right now, without naming names, I don't particularly trust some of the 100 or so people that have the right. This is not because they're bad people or because they've done anything specific wrong, but because some of the people with the user right now have almost no experience in working with the file namespace at all. The potential for vandalism, as well as for chaos caused by good faith mistakes, increases if we do this, but the utility of the tool increases as well. I'd be interested in hearing what the community thinks of this tradeoff. Sven Manguard Wha? 05:31, 14 March 2011 (UTC)

Might make more sense to create a new userright "page mover" or something that includes movefile, suppressredirect, and move-subpages, (and maybe tboverride, for good measure) and then develop stricter criteria for granting it. –xeno^talk 20:18, 15 March 2011 (UTC)

• Support   — Jeff G.  ツ 00:16, 16 March 2011 (UTC)

How to Attract Thousands of New Editors

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

My friends all think:

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

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

My suggestion:

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

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

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

• Put a banner at the top of every page:

WHAT YOU DIDN'T KNOW ABOUT WIKIPEDIA

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Really wanted?

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

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

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

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

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

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

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

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

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

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

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

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

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

I have a life

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

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

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

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

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

Google

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

Why I don't contribute

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Far afield

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

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

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

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

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

Editing paid and sponsored, say, by academic institutions would be a net plus. The problem of paid editing is COI editing for private companies or self-promotion, but fostering professional paid Wikipedians to take care of specific subject areas just like institutions pay librarians or curators would be a definite improvement. I would personally love to do that as a job. --Cyclopia^talk 12:43, 8 March 2011 (UTC)

Article complexity level

In the strategy - March 2011 update it's concluded that the number of editors that stay around longer than a year is on the decline. One reason for this may be that the complexity of the articles is on the increase, such that the level of knowledge required in order to make a useful contribution is also on the increase. I also agree that the "deletism" is too often a shoot at sight, rather than a wait-and-see. Electron9 (talk) 04:18, 14 March 2011 (UTC)

Tag team

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

Proposals:

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

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

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

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

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

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

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

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

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

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

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

• Oppose What if there is still the problem? ~~Awsome EBE123~~(talk | Contribs) 23:42, 9 March 2011 (UTC)
• Oppose tags tell us what is wrong with an article. --Guerillero | My Talk 17:24, 16 March 2011 (UTC)
• Strong oppose - the proposal defeats the entire purpose of having a tagging system - unless instead of removing the tags we delete the articles...

Share button

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Oppose. URLs and Facebook's link-posting function works fine, if you ask me. Guoguo12--Talk--  21:39, 1 March 2011 (UTC)
• Support - Facebook is already on many other sites, and it's a great way to spread the message. So what if it's a commercial site and it's social networking? Great way to share. That said, I have opted out of this feature myself on Facebook due to privacy concerns (enforced via NoScript on my browser!) Magog the Ogre (talk) 06:53, 4 March 2011 (UTC)
• Oppose There are tons of sharing utilities, bars, social sites, etc.. To add functionality for one or for all would be to extensive, and the "flavor of the month" always changes. If you like something, just use whichever tool you have to share with friends. Who (talk) 13:19, 4 March 2011 (UTC)
• Support - I tend to agree with Fences & Windows. Being scholarly is not the same as being old-fashioned. There are even services now like CiteULike specifically for sharing scholarly publications. Nature and journals published by Springer also include some variant of "share" links. The links don't have to be extremely visible, just present. I don't think it's in our best long-term interest to continue to isolate ourselves from the rest of the internet. Mr.Z-man 17:28, 4 March 2011 (UTC)
• Support While it wouldn't turn Wikipedia into a social networking site, it would only serve to increase visibility of articles, encouraging contribution. I don't think WP:NOTMYSPACE applies here, the ability to share articles on social networking sites doesn't make Wikipedia a social networking site itself. Swarm ^X 17:39, 4 March 2011 (UTC)
• Support Wikipedia is not myspace, but to deny the existence of the social web is to miss out on a whole venue of site promotion. Being able to share articles only attracts more readers, and probably over time, more editors too. I don't see a negative. --NickPenguin_(contribs) 05:59, 6 March 2011 (UTC)
• Oppose A special plea to those obsessed with Facebook: Keep it as a separate part of your lives. I use Facebook a little, but there is no way I want to see any connection between it and Wikipedia. Wikipedia is already very well known. A link via a url makes a perfect connect if one is required. HiLo48 (talk) 06:16, 6 March 2011 (UTC)
• Oppose We really need a button to do this? All you are doing is ctrl+l, ctrl+c, go to facebook (as in type it in to the address bar, not search for it), ctrl+v. The only advantage of doing this via button is to collect statistics on our users as to who is sharing what where. Buttons are in my opinion more work than just copying and pasting, because as of yet there is no standardized way of doing this and you end up having to log in anyways. As such it usually takes me longer to post about something on facebook with a share button than it does to do it manually. --nn123645 (talk) 18:59, 9 March 2011 (UTC)
  • There most certainly is a standardized way. Mr.Z-man 22:23, 13 March 2011 (UTC)
    • Popular share buttons include share this, add to any, add this, custom share buttons, and the buttons from the third party sites (such as facebook). I would hardly call this standardized. --nn123645 (talk) 00:15, 16 March 2011 (UTC)
• Oppose It's just like the like/dislike buttons above. ~~Awsome EBE123~~(talk | Contribs) 20:36, 13 March 2011 (UTC)
  • No it isn't. The only thing that they have in common is that they're both buttons. The "like button" proposal above is for something that would be completely based on Wikipedia. Mr.Z-man 22:23, 13 March 2011 (UTC)

Mix Wikipedia and Twitter

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

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

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

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

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

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

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

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

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

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

• No It has the same principals like facebook. ~~Awsome EBE123~~(talk | Contribs) 21:21, 13 March 2011 (UTC)

Testing new account creation processes

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

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

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

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

• FYI: Now test nr 3 is up and running. Let me know if there are any problems.//SvHannibal (talk) 12:54, 28 February 2011 (UTC)
• And now test nr 4 is going on.//SvHannibal (talk) 23:31, 2 March 2011 (UTC)
• I just started test nr 5.//Hannibal (talk) 16:01, 8 March 2011 (UTC) PS. If you are curious about the results, you can have a sneak peak here.
• I just started test version nr 6. //Hannibal (talk) 12:52, 11 March 2011 (UTC)
• Me again. Test version nr 7 is on now.//Hannibal (talk) 16:56, 14 March 2011 (UTC)

Qualification for being a reviewer

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

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

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

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

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

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

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

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

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

Support. Of course. We don't need more unqualified reviewers. We need more qualified ones. It's hard enough dealing with qualified ones, but throwing poor quality into the process reduces efficiency, not increases it.

Doing a good review in some ways requires even MORE perspective than doing a good article. Ideally we'd have some superstud New Yorker editor figure. But failing that, an article writer is much better than someone who can't or won't write articles. If someone doesn't have the capability (or desire) to write an article, I don't want the review.

I've been unimpressed by the reviews from people who haven't done an article. They don't have an overall vision, they don't spell out their crits, they don't have any sympathy or understanding of the author. They seem to play the RFA power game of playing with the support/oppose to drive personal views on style choices, rather than making reccs on things where a choice is allowed. I've actually twice (in a short go) seen very malicious behavior from reviewers who had not done an article.

Only other thing is would add that we should do quid pro quo (require reviews) as DYK does. I'd MUCH rather have an enforced review from someone who writes featured content (he's going to give a good review, he's already shown that by writing articles that he can compose his thoughts) than have a review from someone who is intimidated by actually...well writing an article (which after all is the unit of work product from the reader [customer] point of view). And I'd be more likely to do the reviews and be more interested in the process, if it was a part of the civic duty, than if it's some ad hoc thing with Sandy whining about how no one does reviews or isn't nice enough to reviewers.

And I actually agree that the places (well FA really) are kind of clubby. But I don't think inviting Randy from Boise is the answer. The answer is getting ALL of the populaton of FA writers to do reviews, not just a small number.

TCO (talk) 14:33, 13 March 2011 (UTC)

Improving review processes

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

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

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

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

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

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

The other direction

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

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

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

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

• While I tend to agree about what the processes have turned into (not to mention the constantly tightening standards, especially with FA), I see them as more of a necessary evil. Being able to put a little icon on your userpage or seeing your work on the main page for a day provides a little more incentive for people to improve our existing articles, which we desperately need. They may be insular groups, but they're insular groups going around and improving articles; I can't really complain that much about it. Mr.Z-man 19:41, 8 March 2011 (UTC)

• Hear, hear!!! the reality of the current GA/FA ecosystem is that it consists of an insular group of people who seek to provide ego boosts to themselves and others associated with the group. I, for one, will not be a part of it. Articles should just be rated A - B - C - start - stub, with clearly-defined criteria for each, and any established editor should have the freedom to assign a grade. I have no interest whatsoever in any of the FA/GA nonsense, which seems to me to be related to the Cult of Administratorship, in which I also refuse to participate. Carrite (talk) 01:45, 14 March 2011 (UTC)

• I've heard a few iffy things about GA, and worse things about FA, however the criticism I hear the most is that there exists a group of reviewers who will fail the reviewed item because there are problems in it, fixable problems, and yet even though it would be easy for those problems to be fixed by the reviewer, the reviewer does not 'see it as their problem' to do so. In the worst cases, reviewers will say 'you failed criteria X' and not even make themselves available for clarification, let alone assistance. I saw this recently in a Featured Sounds review, and the reviewer actually said as much, that reviewers review and that it should have been right before being put up for review (Mind you mentioning FS is a tad off topic, but still illustrates the point which I've seen in GA and heard about in FA). Now I agree with the second part, to a point, things should be in as good a shape as possible before being reviewed, but at the same time, there needs to be a recognition that things won't be perfect going in, and more importantly than that, there needs to be an attitude shift. I would go as far as to say that any reviewer that is unwilling to help fix the problems he spots should be barred from reviewing. I'm not saying that reviewers need to help rewrite articles or fix up articles that were clearly not ready to be submitted, but the fail and run attitude I've seen at GA and heard about at FA needs to end, and it needs to end now. More than a textbook sized MOS or the learning curve required to write top quality material, the biggest, most discouraging factor hampering these processes is getting a drive by panning. If a user's first GA review ends up like that, I doubt that user will be back for seconds. Sven Manguard Wha? 19:53, 15 March 2011 (UTC)

Online testing of FA/GA reviewers

I have another proposal for improving FA/GA reviews - subjecting reviewers to a short 10 question open-book online quiz to make sure they have read the criteria. Anyone who passes the quiz would have a bit set in their signon record and they would be eligible to review FA and GA candidate articles. We are facing a large problem with criteria creep. Some people who are reviewing DYK-suggested articles treat the process as if it were a GA review of the article. Other reviewers give GA nominated articles an FA level review, etc. The plan could be implemented by designing a panel of 25 multiple choice questions that would be selected at random and presented to the test-taker one at a time with an explanation of why each answer selected was right or wrong. The test-taker would only advance to the next question if he answered the prior one correctly, and the bit would be awarded after 10 correct answers in a row.

At present, there is no guarantee that the reviewers understand their role or the criteria. This proposal would give FA/GA reviewers a sense of being "certified" and would lead to better reviews. Racepacket (talk) 15:45, 10 March 2011 (UTC)

Automatically welcoming new users

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

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

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

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

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

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

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

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

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

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

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

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

I did some counting.

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

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

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

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

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

From a pragmatic point of view, I would oppose this. Redlinked talk pages can be a good cue for vandal fighting and sock-hunting. Seeing redlinked talk pages for people with precocious knowledge of Wikipedia is a very useful cue to investigate further. If we bluelinked every talk page as soon as someone edited, it would make it somewhat harder to track these sorts of issues. --Jayron32 04:46, 8 March 2011 (UTC)

Special:Log/newusers shows both links to talk and contribs. Checking for vandalism involves actually looking at user contributions, and the only useful information you can glean from redlinked talk pages is that no one has chastised them yet. If this proposal were put into place, it might take an extra click (or mouse hover depending on your setup), but I think the potential of increased return users would far outweigh this small negative. --NickPenguin_(contribs) 06:00, 8 March 2011 (UTC)

Oh, it was a small (but very real) concern. I am quite experienced enough to know how to root out problematic users. I was just noting the lamentation of the loss of one small tool that does help find socks rather easily, should this proposal be accepted. In other words, yes, I know quite well the limitations of relying on the redlinked talk page as the sole method of finding socks. Still, its a handy tool at times, and I would miss it if we bluelinked every talk page the second an account went active. --Jayron32 06:13, 8 March 2011 (UTC)

I understand your perspective, and it is a legitimate concern. --NickPenguin_(contribs) 07:13, 8 March 2011 (UTC)

This is a perennial issue which really arises because of the flaw in MediaWiki:Welcomecreation: it disappears and can't easily be found again. The solution was proposed as Template:Bugzilla: essentially, turn it into a dismissable message shown on new users' talk pages, which isn't an actual talk page posting and doesn't turn the redlink blue. Rd232 ^talk 14:34, 9 March 2011 (UTC)

• I hadn't been aware of the sock spotting advantage to redlinked talkpages. However that would not be affected if we set the bot to welcome people who still had redlinked talkpages one week after their first edit. ϢereSpielChequers 18:19, 11 March 2011 (UTC)
• I oppose welcoming users on their first edit with a boilerplate message. First off, personally I don't think that boilerplate welcome messages help with anything at all. People recognise it instantly as an automated message. I for one wouldn't care for an automated message on my talkpage. Ideally I'd say leave a personal message on a talkpage after about 5 edits, to show the newcomers that they are free to experiment and make mistakes, and people aren't watching on their fingers with every step and mistake. Then, if they still haven't been welcomed after about 20 edits, leave a boilerplate message (and hang our collective heads in shame). I know this is a lot more labour intensive than templating. Still, I believe that welcoming one newbie properly should be chosen over welcoming 20 with a template. Martijn Hoekstra (talk) 21:55, 17 March 2011 (UTC)

• By the way, I would very much welcome metrics of newbie retention on editors templated newbies verses non-templated numbers. I can have all the ideas I want on the effectiveness of template/boilerplate messages, but without any numbers it's anyones guess really. Martijn Hoekstra (talk) 22:00, 17 March 2011 (UTC)

Proposal to run a test session

I think the test method outlined by Lambiam would give us the most neutral way of determining which method of welcoming functions better. Taking a test group of new editors and automatically welcoming them when they make their first edit, and then a control group where regular methods of welcoming occur. Using a few thousand accounts for each group would reduce the chance of number skewing.

The bot welcoming message would be simple, it would only include neutral information about content policy, MOS, how to interact with users/talk pages and how to get involved with the community. Just short and simple. Then after several months, we analyze the results. Thoughts? --NickPenguin_(contribs) 15:59, 11 March 2011 (UTC)

I'd support a test, though it needs to be 7 days after their first edit not immediately, and in that case the control group should be unwelcomed users not manually welcomed ones. We also need to test the efficacy of various welcome messages. ϢereSpielChequers 18:23, 11 March 2011 (UTC)

Things I, as a newbie, would have liked to have seen when I was "welcomed"

This is my first visit to the village pump. After a year or more of considering the possibility, I did my first edit on 23 February and since then have been enjoying populating a very small corner of the Wikipedia world (Jewish musicians, poets, actors, etc involved in cabaret in Warsaw between the World Wars) using a few Yiddish reference books I've been reading and some amazing Polish savants who post inter-war tangos on Youtube!

Feedback for the old-timers: I found the Wikipedia interface incredibly intimidating. It's austere and verrrry nerdy and obscure. It took me a while to even SEE the "edit this page" tab - at first I thought I could only edit the reference list, not the article itself. Also, I couldn't figure out for a couple days HOW to make my references show up in a reference list.

I needed (still do need) a list of formatting rules close at hand - I still look some of them up by GOOGLING wikipedia to see, for instance, how to format a "redirect." I know there is a cheat sheet but I can't remember how to find it. I am overwhelmed by all the acronyms. I stuck it out because I was curious, but it wasn't easy. I'm surprised and pleased to see so many people here caring about there being new editors - and I did receive a "welcome" note - but really what you need is to see this interface through my eyes (or any other newbies). It doesn't work like any forum or other user-content-generated site I've ever been involved with. And now I will remember to add my four tildes. Jane Peppler (talk) 03:37, 15 March 2011 (UTC)

Truly this is a testament of great courage and tenacity. Hearing your comment about learning how to make a ref show up is a very common problem I see new users having when I—very rarely— patrol new pages. Perhaps more effort should be made to direct new users towards the help button on the left hand side of Wikipedia, or to use the "first article" creator, or to look at the tutorial.AerobicFox (talk) 04:42, 15 March 2011 (UTC)

One of the biggest problems with referencing is that there is no standard. We have our citation templates, but not only do some people (including veteran editors) not use them, but there are different ways of using them, such as list defined references vs. ordinary inline references. Some use {{Sfn}}, others use {{Harvnb}}, and many simply create footnotes manually. Some "References" sections have "Literature cited" subsections and use footnotes, others don't. And if you try to discuss standardizing it across all Wikiprojects, expect to see people charge at you with pitchforks and torches... or just ignore you completely. Personally, I hope the new editing interface is released relatively soon, and I especially hope it handles references for us in a clean, efficient manner. But one of the biggest things I think we need for new users is a better interface to policies, like WP:MOS, WP:V, WP:NPOV, etc., as well as other things like WP:ASSESS. It needs to be super simple, easy to find, easy to read, but providing links to more detailed explanations for when the general overview is insufficient. As it stands, these important pages are long and difficult to read, and I doubt few editors have read them completely. – VisionHolder « talk » 05:22, 15 March 2011 (UTC)

Re refs: There should be a "cheat sheet" which includes the suggestion that new users (or anyone, really) is welcome to insert a reference by simply entering the plain text in brackets. A wikignome will format it in due course. What is needed is a simple suggestion about what information should be entered, and the order, with a couple of examples.

Re new editing interface: The rich text editor at wikia.com is ghastly. Management and newbies love the idea of it ("look, there's a bold button just like on my word processor"), but the only things the clever editor can do are the dead easy things (bold, italics, and perhaps one or two other things since the last time I tried, months ago). The stuff which is tricky in wikitext is ghastly or impossible in a clever editor. Johnuniq (talk) 06:27, 15 March 2011 (UTC)

Dear Visionholder: I visited those acronym links of yours (WP:MOS etc) and nearly fainted. Though I am a cum laude graduate of Yale University and read very long books quite happily, I find the formatting and tone (if not the content) of those pages so dense that they immediately fall into the life is too short category. You would have to hold a flame to my foot to make me read them. Jane Peppler (talk) 12:00, 15 March 2011 (UTC)

Hi, Jane Peppler. I can remember being intimated by the interface, the tools and the WP:bureaucratese of the policies and guidelines. I've attempted an advice page at User:Philcha/Essays/Advice for new Wikipedia editors, which tries to write in simple English, to concentrate on useful tools and techniques, and to summarise the main policies and guidelines and link to pages where editor can get advice on the main policies and guidelines. But I'm aware that I'm very probably assuming too much - apart from WP, I've been using Windows since 1992. If anyone can identify problems or omissions, or suggest improvements, please comment at User talk:Philcha/Essays/Advice for new Wikipedia editors. --Philcha (talk) 12:29, 15 March 2011 (UTC)

Reducing boilerplate below edit box

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

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

and:

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

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

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

The proposal is:

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

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

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

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

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

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

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

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

Someone who has been here for 5 years with over 30000 edits should be well aware of the copyright issues by now, without needing interface clutter to remind them. Try asking the admin in question what they're playing at, and if they won't undelete take it to WP:DRV. Anomie⚔ 05:01, 8 March 2011 (UTC)

Another admin already restored it, stating: don't be silly – always good advice to everyone except clowns and comedians. I hope I did not unwittingly instigate a wheel war.  --Lambiam 13:22, 8 March 2011 (UTC)

Unfortunately being aware of the copyright issues means aproximately very little from a legal perspective. We need a release and by removing the we lose that release. Effectively your position is equiverlent to arguing that experence users don't need to add license templates to their images.©Geni 18:34, 8 March 2011 (UTC)

It is a totally different position that does not bear even the remotest resemblance to the strawman you're putting up.  --Lambiam 00:13, 9 March 2011 (UTC)

Interesting argument. Do you really think one can prevent their contributions being so licensed simply by hiding the relevant text? If so, what is to stop them from hiding it with browser css (or a post-it note, for that matter)? –xeno^talk 18:56, 8 March 2011 (UTC)

Because that's browserside. They got a bunch of stuff sent to them that has the intention of showing that notice. With the CSS changes no attempt is made to show the notice. The whole area is very messy and best avoided for precisiely that reason.©Geni 19:11, 8 March 2011 (UTC)

So you are hypothesizing some future situation where someone would sue the Wikimedia Foundation for copyright infringement, after hiding the release via css? And you think that, after it is demonstrated that they had intentionally and willfully hidden the release, they are going to have legitimate grounds for such a suit? –xeno^talk 19:19, 8 March 2011 (UTC)

they argue that their action was the equiverlent of opting out. The court might accept that. The court might not but argue that any future use of material derived from that work would then constitute a copyvio. As I said messy. The copyright situation on wikipedia is complex enough as it is and making it messier is at best missguided.©Geni 19:24, 8 March 2011 (UTC)

I think that's a bit of a stretch - but would you be satisfied if a user who, having hid the release via CSS, made a blanket general release somewhere on their userpage? –xeno^talk 19:26, 8 March 2011 (UTC)

(e/c)CSS is browser-side whether its delivered by the server or not. The text of the copyright notice is still there in the HTML source, its just hidden by the browser. The terms of use don't stop applying just because you don't read them. Mr.Z-man 19:30, 8 March 2011 (UTC)

Also, the terms of use is still linked on every page, and clearly states how everything is licensed. I too find this scenario quite a stretch. henrik•talk 19:33, 8 March 2011 (UTC)

if you remove editpage-copywarn and editpage-copywarn2 (which appears to be what is being attempted in this case) then there is no link to the terms of use on the edit page.©Geni 19:41, 8 March 2011 (UTC)

No but in this case we need an active agreement which is a bit of a problem if the editor has turned off the mechanism by which we get that.©Geni 19:37, 8 March 2011 (UTC)

This is rediculous. Any editor may choose what to hide for him/herself, even if it is a copyright warning. One's personal CSS file only affects visibility to the eidtor itself, unlike licence templates, which are visible to anyone. Please don't remove those lines from personal CSS files. — Edokter (talk) — 19:13, 8 March 2011 (UTC)

The license templates are the release in the case of images. The release in the case of text is clicking save page on a page with the text of editpage-copywarn next to it. Other people being able to view it or not is of no actual significance.©Geni 19:20, 8 March 2011 (UTC)

By hiding a message, the editor is asumed to have read and agreed to any message previously displayed. Hiding it does not in any way deminish our policies. If it were really this important, the message would be unhidable. — Edokter (talk) — 19:27, 8 March 2011 (UTC)

!)I don't think it occured to anyone that someone would try and do this and 2) how would you even go about making it unhidable.

You could remove the class ID, I suppose. In any case, as Z-man notes about, even when hidden with user or browser CSS, it is still present in the HTML source. –xeno^talk 19:34, 8 March 2011 (UTC)

Unless you are going try and argue that the courts would look kindly on a release in the HTML that was commented out I don't think "it's still there in the HTML" is an argument that gets us very far.©Geni 19:39, 8 March 2011 (UTC)

I feel silly arguing about this in the first place, but I suppose frivolous lawsuits are a lot more common south of the border. –xeno^talk 19:44, 8 March 2011 (UTC)

There are 352 users who are hiding copywarn2, including me for close to two years now. IANAL and find the idea that hiding the notice can be argued as an opt-out absurd, but I try not to underestimate the absurdness of copyright law, so I wouldn't want to rule it out either. Cat's out of the bag however. If anyone is seriously worried about this having the potential to create problems, ask WMF legal council, and have them worry about it. Amalthea 21:29, 8 March 2011 (UTC)

The long term ones create another headache because of course the copyright warning has changed from pure GFDL to GFDL+CC-BY-SA.©Geni 23:58, 8 March 2011 (UTC)

And even 726 users are hiding copywarn. The way I see it, we all agreed at some point to uphold policy; we really don't need to do that with every edit. — Edokter (talk) — 00:35, 9 March 2011 (UTC)

I'm in a weird position here in that I agree that it's probably not necessary, if we require affirmation of understanding of policy before the notice is disabled, but still kind of thinking that displaying it universally is a good idea. :) The only potential for legal problems I can see out of allowing opt-out would be if somebody argued that they had usurped an active account and so did not themselves agree to the opt out or know about the copyright policy, or if terms significantly changed (as with our great license shift). For all I know, it's plausible to unilaterally override everybody's opt out in the latter case, and the former could be taken care of by adding to that opt out requiring an affirmation of understanding that accounts are not transferable. But, again, I think it's a good idea to have it at the bottom of every edit screen because it may potentially provide an additional layer of protection for WMF, demonstrating a strong good faith effort to prevent misuse of the project. --Moonriddengirl ^(talk) 13:53, 9 March 2011 (UTC)

Going back to the original proposal, if you add the release to the login page and repeat it as part of the setting on the preferences page, surely that is sufficient if the user has opted out of the warning next to the edit box? - Pointillist (talk) 18:48, 8 March 2011 (UTC)

I'm not sure adding text to the login page for everyone is a great idea.©Geni 19:20, 8 March 2011 (UTC)

Why not? - Pointillist (talk) 21:33, 8 March 2011 (UTC)

Because we try and keep it as sort as possible in the vauge hope that new users will read it.©Geni 00:00, 9 March 2011 (UTC)

Is that an established view? I would have thought that the project would benefit from new users being told that "Encyclopedic content must be verifiable. Content that violates any copyrights will be deleted. You irrevocably agree to release your contributions under the CC-BY-SA 3.0 License and the GFDL." BTW, why do you prefix your username with ©? - Pointillist (talk) 00:21, 9 March 2011 (UTC)

Well the whole registration system is meant to be undergoing a complete overhal so I suppose historical might be a better description. The © is playing with a bug in CC-BY-SA 3.0©Geni 00:28, 9 March 2011 (UTC)

Side question—appropriate use of admin powers?

Is it really an appropriate use of admin powers for an admin to go around editing other users' personal css files after it has become clear that there is not consensus for his/her position? Anomie⚔ 23:05, 8 March 2011 (UTC)

A strict reading of policy would call for warning followed by indefinet block however I would regard that as somewhat excessive.©Geni 23:59, 8 March 2011 (UTC)

Revert, desysop, block, then ban. What fun. Mono (talk) 00:04, 9 March 2011 (UTC)

I would say not. An editor's personal CSS is not subject to any content or copyright policy. An admin making such edits should revert his/her edits and apologize to the editor. — Edokter (talk) — 00:32, 9 March 2011 (UTC)

Everything (with the possible exception of the logo) on this wiki is subject to the copyright policy. Quite a few of the CSD criteria could also apply. In fact since it is possible to drop comments into your monobook.css page there are quite a selection of content policies that apply.©Geni 00:37, 9 March 2011 (UTC)

Right, there are cases where a users js or css file could be deleted. This isn't one - hiding a page element doesn't make it not there, any more than covering a contract with a piece of paper voids it. But I think we've come to that conclusion already anyway. Prodego ^talk 02:28, 9 March 2011 (UTC)

Redesign

How about combining the two into a simple notice, like

Mono (talk) 00:04, 9 March 2011 (UTC)

Isn't that considerably larger than what we currently have?©Geni 00:19, 9 March 2011 (UTC)

It is somewhat consolidated. But in my view, it should be shrunk to one clear line with a link to the Terms of Use page. — Edokter (talk) — 00:28, 9 March 2011 (UTC)

Tried that. Actualy back in the GFDL days we got pretty close (although we used footnotes rather than link out). Current text is foundation mandated and objections about length got kinda brushed asside. Feel free to file a fresh protest though.©Geni 00:31, 9 March 2011 (UTC)

Perhaps the second? Mono (talk) 01:19, 9 March 2011 (UTC)

The second notice is not consistent with Terms of Use, in that hyperlinks and URLs are not the same thing. For instance, we use hyperlinks when copying within Wikipedia, not URLs. (Also, it's not necessarily to the page you're contributing to, as it could be a stable version stored elsewhere.) Both of them exclude reference to "except brief excerpts". I think we need to retain that. :) We don't want to eliminate quoting here. I'm not sure that either of these are an improvement over what we have, though. (Though it, like these, omits the other possibility of attribution--a list of authors.) --Moonriddengirl ^(talk) 13:30, 9 March 2011 (UTC)

Adblock Plus

File:Screenshot-Adblock Plus Preferences.png

Personally, I found Adblock Plus an efficient tool to ged rid of those annoying messages. —Ruud 01:06, 9 March 2011 (UTC)

Why have the boilerplate disclaimers?

Sometimes, I wonder why we have them there in the first place. I highly doubt most people, including newcomers, "casual editors", and veteran users alike, don't care to heed them. If they're going to add unverifiable or copyright-violating stuff, they are going to anyways. I feel that they are more in the way aesthetically than whatever benefits they have in informing users. –MuZemike 20:35, 10 March 2011 (UTC)

It is, as we lawyers say, to cover your ass... in case of a lawsuit. Without notice of disclaimers etc it is hard to rely on them in court. With them you at least have an argument. Isn't this an issue that the Foundation's General Counsel should be opining upon, rather than the user base? – ukexpat (talk) 20:45, 10 March 2011 (UTC)

An alternative for the legal issue

All this started because there is people who do not like a mass of well known links in the space between the edit box and the summary and save sections; but now it may seem that it may be legally needed to include the copyright release in the save box. Both things are not mutually exclusive: if it turns out that the copyright links must be included, wy not include them somewhere else? The "important" area in edit mode, where editors use things and need to see them or scroll to them,, is between the tools and the save button. Above and below it's unused space (for editing purposes) and any boring mandatory messages may be included in there. MBelgrano (talk) 21:59, 10 March 2011 (UTC)

Which was the very proposal with which this started, or, at least, to make that a user-preference option.  --Lambiam 00:51, 11 March 2011 (UTC)

Non-admins moving pages with no Talk redirect

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

I think that's a dreadful idea. Only admins should be allowed to do anything. Malleus Fatuorum 06:14, 8 March 2011 (UTC)

"move pages without leaving a talk page redirect"... how often is that a good idea? And WP:CSD#G8 makes cleanup of the occasional case easy. Changing the software is always hassle, you need to make a pretty good case to stand a chance of it happening. Rd232 ^talk 00:54, 9 March 2011 (UTC)

Interesting idea Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 08:26, 8 March 2011 (UTC)

Merits aside, I think this is technically problematic as "not leaving a redirect behind" is currently achieved using the delete tool, which would have to be split or otherwise tinkered with a lot to isolate this particular implementation from the ability to delete other pages. Skomorokh 18:36, 15 March 2011 (UTC)

No, "not leaving a redirect behind" is achieved by unchecking the "Leave a redirect behind" checkbox on the move form or using the noredirect parameter in an API action=move query. This is available to users with the suppressredirect right (currently bots and admins). Anomie⚔ 21:59, 15 March 2011 (UTC)

Force edit summary usage for new users until they're autoconfirmed

I don't expect to get much support for this one. But I want to propose it anyway. I often see new accounts make big bold edits without leaving edit summaries, and I assume good faith of course, but I still don't know why they boldly removed that certain paragraph or sentence, or changed that date or statistic, or whatever. I don't know how many times I've had to leave an extended message on new users' talk pages explaining why they need to use edit summaries. Better to get them in the habit early, then once they get autoconfirmed they can have the option to turn it off. -- œ^™ 09:29, 11 March 2011 (UTC)

I like it, can we set a trial to test this out? I think use of edit summaries would reduce the number of good faith edits reverted as vandalism. Yoenit (talk) 09:40, 11 March 2011 (UTC)

Agreed. I've often reverted silent deletions due to lack of an edit summary (they're indistinguishable from vandalism or POV-zealotry). Occasionally I've inferred "lack of references" as the reason and not reverted, but requiring an edit summary would significantly help in distinguishing nonconstructive deletions from good-faith ones. --Cybercobra (talk) 09:59, 11 March 2011 (UTC)

WP:PEREN#Automatically prompt for missing edit summary. (But I'm not sure I agree with the “[r]easons for previous rejection”: after all even most e-mail clients warn you if you're trying to sent a message with an empty subject line.) --A. di M. (talk) 11:35, 11 March 2011 (UTC)

Do we have evidence that this is even a true perennial proposal? It seems to have been added back in 2006 [2], but has it ever been the subject of discussions? Yoenit (talk) 12:07, 11 March 2011 (UTC)

What about turning on the prompt gadget by default? Kayau Voting IS evil 12:44, 11 March 2011 (UTC)

Right. The gadget is already there, but only registered users can turn it on in their preferences setting. If turned on, an attempted save of a summary-less edit does initially not succeed but instead displays a conspicuous warning banner: "Reminder: You have not provided an edit summary. If you click Save again, your edit will be saved without one." (See it at MediaWiki:Missingsummary.) Unregistered users and most new users don't get to see this, as it is turned off by default. Although enabling this by default is not exactly forcing unconfirmed users to use edit summaries, it most definitely will help encourage them to do so.  --Lambiam 14:02, 11 March 2011 (UTC)

Could we change the text to something like "Reminder: You have not provided an edit summary. Edit summaries help other users understand the intention of your edits. Please enter one before click Save again, or your edit will be saved without one."? I am afraid the default text is not really helpfull to a newbie and is more seen as annoying. Yoenit (talk) 14:27, 11 March 2011 (UTC)

I've put this proposal up at Wikipedia:MediaWiki messages#Proposed change for MediaWiki:Missingsummary. Please discuss it there.  --Lambiam 23:22, 11 March 2011 (UTC)

I'm definitely all for trying to get people to put in edit summaries and I haven't the foggiest why ips aren't prompted to do so. It should be like that by default. Dmcq (talk) 16:13, 11 March 2011 (UTC)

I really dislike this proposal. What are the new users supposed to do say they are for instance, just trying to get a piece of wiki code to work, or making minor edits. Forcing them to write a summary of everything they do seems like a hassle for new users.AerobicFox (talk) 17:27, 11 March 2011 (UTC)

I would weakly support a dismissible reminder for anons and new users (weakly because of AerobicFox's concerns), but I would oppose forcing users to provide one. Mr.Z-man 17:38, 11 March 2011 (UTC)

I've had other users ask me how to leave an edit summary before, so I do suspect that many just can't see the bar right above the "save page" button. How about we just move the edit summary above the edit box, make it some obnoxious color, and render "Edit summary (Briefly describe the changes you have made)" as "Edit summary (Briefly describe the changes you have made)" and/or (along Mr. Z-man's suggestion) if they try to save a page without putting an edit summary, a prompt comes up saying "are you sure you don't want other editors to understand what you're doing?" Ian.thomson (talk) 17:50, 11 March 2011 (UTC)

If you use an obnoxious colour then the message could use the same colour so they can easily spot where the place to insert a summary. Dmcq (talk) 13:13, 15 March 2011 (UTC)

I would oppose compulsary edit summaries. The last thing we need is another hoop for new users to jump through before they can edit. Support a reminder, which would leave it firmly in their hands while still encouraging them to use the tool and educating them about its use. Interesting to note that of the eleven of us involved in this discussion, only four used edit summaries on the first edit, and none on all of the first ten ([3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13]). Would it be right for us to force new users to do something that we failed to? Alzarian16 (talk) 13:27, 15 March 2011 (UTC)

Support the default reminder in article space for non auto-confirmed users. It's no great imposition and should reduce misunderstandings and possible summary reverts due to misjudging new editor's intentions, particularly if edit is not well formulated. It should also serve to highlight intentional disruption. RashersTierney (talk) 13:45, 15 March 2011 (UTC)

Oppose. As Alzarian helpfully pointed out this is not something we should hassle newbies about. I would be more tolerant of something along the lines of "congratulations on your 100th edit, may we now introduce you to the idea of the edit summary", but as for newbies I'm much more concerned about getting them to tell us their source. DE wiki has a referencing prompt and I would like that to be trialled here. ϢereSpielChequers 14:00, 15 March 2011 (UTC)

The last thing we need are more barriers, especially those requiring a degree of technical aptitude, to new editors contributing. Would not object to a dismissible prompt after 20 or so edits though along the lines of the comments by MuZemike and WSC above. Skomorokh 18:33, 15 March 2011 (UTC)

Allow Wikimedia-wide searches from within Wikipedia search screen

There used to be a box at the right of the search results page that showed the most relevant results from sister projects (see Help:Searching#Search results page which btw desperately needs updating) This is no longer the case and hopefully someone can tell me why because I thought that was very a very useful feature. And I DO have "Enable enhanced search suggestions (Vector skin only)" checked in My Preferences, and this tool doesn't really do what I'm wanting to do. What I propose is to be able to search ALL Wikimedia projects, including ALL languages, all at the same time, and to be able to do this from the regular Wikipedia search results screen (perhaps by selecting it from the drop-down box that lets you select external search engines?) Is this feasible? -- œ^™ 09:53, 11 March 2011 (UTC)

Yes, wiki-wide searches is a problem. If I search for 'Mikołaj Dowgielewicz' I get nothing - except on the wikipedia.pl because he is polish. In this case I took the picture, so I know he is polish, but next time maybe all I have is a name, and no nationality. Really I could use a system-wide search, for any language, and also for picture/media as well. It would be useful if the search result told me how many bytes (so I can look at the longest result first). As it is now, it is entirely a one-language closed box. If anyone knows how to do system-wide searches, then tell me, as I apparently do not know how to do that. --Janwikifoto (talk) 15:36, 12 March 2011 (UTC)

Warning sign on Mediawiki:Signupend

Hello,

I just wrote a proposal about removing some of the more off-putting things on one page in the account creation. The discussion can use your input. Best wishes//Hannibal (talk) 14:26, 11 March 2011 (UTC)

After receiving only positive feedback on my proposal, I edited Mediawiki:Signupend to create a shorter second page in the account creation process, which I hope seem a little bit friendlier now. All the relevant information is just one click away. Assuming that newcomers like the shorter version, this may actually increase the number of new accounts slightly. We will have some results on that shortly on this page. (If you have an account on the Toolserver, please help out with that.)

Best wishes//Hannibal (talk) 22:46, 15 March 2011 (UTC)

Revolutionizing Peer review and the accademic Process through wiki: Involving the Professors and digitizing academia

I propose we, wikipedia, begin to create appeal for PhD.

I propose the following

Wiki registration divide members up according to discipline of major and level of education (Elementary, Middle, Highschool,Undergrad Freshman+Sophmore, Undergrad Junior and senior, master candidate, master, PhD. Candidate, TA,)then...

Instructor 2 Board Eligible 50-75 hours of teaching per year

Assistant Clinical Professor 8 High degree of clinical competence, 50-75 hours of teaching per year

Associate Clinical Professor 6

Clinical Professor - - Evaluations - Excellent teaching, 50-75 hours of teaching per year

Emeritus - - Reserved for highest rank - distinguished record of UCSF teaching and clinical competence.

I proposed based on academic rank no level can edit the information placed by a supperior accademic title, and can only be altered by one of a higher or equal rank,

However, the issue is when a piece of information becomes out dated event though a professor said it is true and no one can change it. I would propose that any Graduate can question the point made by a professor and opon reaching a certain boundary it should be checked by a staff of PhD.'s hired or open sourced through wikipedia.

Also I propose anyone can hypothesize, while also a process of philosophical building can occur in the mind and words of anyone, as such anyone can propose theory (Following this same rank system mentioned above), however I propose only a graduate can choose to breath life into the idea and perform appropriate scientific experiments that will move the idea from philosophy to theory.

I believe this would revolutionize accademia giving professors access to a vast sea of ideas while establishing an interactive process of peer review which is constantly being refined by the masses. I believe this would increase education, reseach, wealth, knowledge and the condition of man.

Finally I propose we establish a section for every discipline with a subsection for every theory and its associated subsets until the fact level. I believe that this would enable man to revolutionize the peer review process making responces between professors instant and furthermore breaking peer review down from massive 30 page essays of 6 months of independent thought to thought by thought constant refinement.

Tell me what you think and please add and edit as you see fit! You can reach me at <redacted> — Preceding unsigned comment added by Mcl10002 (talk • contribs) 10:08, 12 March 2011 (UTC)

Anyone signing up can claim to be a Nobel Prize winner, but how do you propose to verify the claims provided by a registrant? Your ideas may have some merit for an academic Wikidea (see also http://academia.wikia.com/), but not for an encyclopedia. I don't know if you are familiar with academia, but it is a battleground of ideas, and you don't want this battle to be fought out on the pages of an encyclopedia. And trust me, there are plenty of professors who are also kooks. If a professor replaces verifiable information by unverifiable self-glorifying content, anyone should be able to revert that. Academic qualifications are not required, or even particularly helpful, for being able to contribute to a good article on a topic like, say, The Legend of Zelda: Majora's Mask. Finally, the title Emeritus doesn't mean more than that some geezer managed to get old without being kicked out of academia.  --Lambiam —Preceding undated comment added 12:36, 12 March 2011 (UTC).

You may also want to review Essjay controversy; the failed proposal Wikipedia:Credentials (proposal) and its talk page; competing essays Wikipedia:Credentials are irrelevant, Wikipedia:Ignore all credentials, and Wikipedia:Credentials matter; Wikipedia:Expert editors; and Wikipedia:Expert retention. Anomie⚔ 13:47, 12 March 2011 (UTC)

I've known brilliant physics professors who couldn't program the time on their VCR. Having a degree in one field does not mean you know anything about unrelated fields. And, as Anomie points out, every field has its quacks. Simply put, what you're proposing won't work for Wikipedia. It might work as its own service, but I doubt it. — The Hand That Feeds You:^Bite 19:13, 14 March 2011 (UTC)

In addition to all of the above concerns, which are correct, proposals that restrict editing in some hierarchical way are incompatible with meta:Founding principles and therefore will not be realized.  Sandstein  20:33, 16 March 2011 (UTC)

Citizendium works on similar principles. Peter jackson (talk) 18:06, 17 March 2011 (UTC)

Automating submissions for Autopatrol right

In an effort to reduce the burden at WP:NPP, several people have undertaken a large project to review and grant autopatrol rights to users that qualify for them. Over the last 2 months, about 2,500 users have been reviewed and about 1,000 users have been granted the right so far. The task has been laborious and I would like to get one or more bots to help with the effort. Before making a bot request, I want to get input from the community to see if we want to do this. Do we want to do this?

If we decide to do this, I think much of the effort could be automated. We already have a script/bot that is generating reports of possible qualified users. This is the general idea — only users that would easily qualify for the autopatrol right would be automatically submitted for review.

1. The existing script/bot would be left "as is" to generate reports
2. One or more bots would remove users from the list using defined criteria
3. Users that remained on the list would be submitted to Wikipedia:Requests for permissions/Autopatrolled by a bot over a series of days rather than having seperate lists as we have now.

The bots could remove users from the list using several defined criteria;

• Users that have been declined recently
• Users that have copyright violations in their recent talk page history (certain messages from CorenSearchBot}
• Users that have created unreferenced BLPs in their recent talk page history (certain messages from DASHBot}
• Users that are currently blocked

Note that this is completely different than users requesting the right. This would be specifically defined to find users that would easily qualify for the right. Any input is greatly appreciated. - Hydroxonium (talk) 13:04, 12 March 2011 (UTC)

As one of the people who has been appointing Autopatrollers, I would add that the most important filter that the current bot reports lack is that the editors need to have created articles recently. The current bot just identifies people who have created sufficient articles to qualify, but many have been inactive for years. It is only worth assessing candidates who still create articles. ϢereSpielChequers 13:19, 12 March 2011 (UTC)

If the bot is just weeding out candidates who qualify on numbers but not on other things, leaving those who are eligible for review by admins, I think this would be helpful. I would suggest that it only remove indefinitely blocked users and it would be good if it could remove anyone who hasn't created a new article in, say, two months. HJ Mitchell | Penny for your thoughts? 14:08, 12 March 2011 (UTC)

I think that's all good. No copyvios, no unreferenced BLPs, no indefinitely blocked users, no users recently declined. Indefinite is the requirement here in that if someone happens to be on a 1-hour block while the bot goes round, they'd be excluded under your criteria. Ironholds (talk) 14:26, 12 March 2011 (UTC)

If the bot was running a weekly report then you could keep it simple by excluding blocked users. If they happened to miss one week's report because of a 24 hour block the next week would include them. It would also be sensible to exclude those currently displaying a retired template on their userpage. ϢereSpielChequers 15:01, 12 March 2011 (UTC)

And the {{Not here}} template. -- œ^™ 15:10, 12 March 2011 (UTC)

If we can exclude authors who haven't recently created articles then all the {{Not here}} ones will be excluded. If we can't do that then the report will be almost unusable as we have already picked off most of the active ones in the recent trawl. So unless we can screen out those who haven't created an article in the last couple of months then I doubt if there will be any value in running the report till nearly Xmas. ϢereSpielChequers 16:56, 12 March 2011 (UTC)

Would it make sense to check for deleted article creations? For example, if the editor has created a couple hundred stubs, but half of them have been quickly A7'ed, that might suggest that having NPPs continue to patrol their creations would be a good idea. 28bytes (talk) 17:26, 12 March 2011 (UTC)

Minor remark. The generated list is based on the count of created articles that are not redirects, but this also includes articles in the count that were created as a redirect, but were later changed (usually not by the creator) to a normal article. I assume that that is not intentional. In practice this may not be a big deal.  --Lambiam 21:08, 12 March 2011 (UTC)

I would also suggest looking at the List of Wikipedians by number of edits here for those that may qualify. I would also recommend excluding from the list anyone with Admin Rights (the permission would be inherent in their admin powers) and anyone with a Retired template. --Kumioko (talk) 17:14, 14 March 2011 (UTC)

The current prospect list excludes admins and Autopatrollers and yes any new list needs to continue to do that. I'm not convinced it is worth assessing editors who have high edit counts but don't create articles, the reason why we flag users as Autopatrolled is as a white list for newpage patrol. If someone has done fifty thousand useful edits but never created a new article then they would get Autopatrolled flag as part of the admin package if they passed RFA. But there is no reason to spend time checking their contributions otherwise - and no history of creating articles would mean it was more difficult to predict whether any future articles they created might merit deletion. ϢereSpielChequers 13:53, 15 March 2011 (UTC)

Sorry, latecomer to this discussion. Per 28Bytes, and there are editors who mass create stubs - some of them are socks (or reformed socks and still creating stubs). What experience has been gained on this by the admins who have been according the right?--Kudpung (talk) 10:33, 18 March 2011 (UTC)

Need help with time frames

Thanks for all the great input everybody. This is what the search currently does.

• Finds users on en.wiki who have created 50+ non-redirect articles
• Remove users that are Admins, Autopatrolled or Bots
• Remove users that are less than 6 months old
• Remove users whose last edit was more than 30 days ago

These are new suggestions

• Remove users who are indef blocked (or any block, they'll get picked up on the next run)
• Remove users that are {{retired}} or {{not here}}

These suggestions need timeframes

• Remove users that have been declined in the last (30? 60?) days
• Remove users whose last new article was more than (30? 60? 90?) days ago
• Remove users that have copyright violations on their talk page within the last (??) days
• Remove users that have unreferenced BLPs on their talk page within the last (??) days
• Remove users that have deleted articles in the last (??) days

Any help for suggested lengths of time is greatly appreciated. Thanks very much. - Hydroxonium (T•C•V) 08:25, 18 March 2011 (UTC)

Deny automated recognition

You may be interested in my user essay User:Yaris678/Deny automated recognition. It recommends a tweak to how the various automated and semi-automated anti-vandal tools should work. Yaris678 (talk) 15:50, 12 March 2011 (UTC)

I've seen some vandals that were obviously trying to earn warnings, but I usually start at uw2 and will skip right to a uw4 if it looks like it's gonna be a vandalism only account. However, most of the IP vandals I see are people just testing the waters, and they get scared when "some admin" (apparently only admins can give warnings?) "threatens to ban them" with the standard warning templates. Though I do agree that it is a problem that if I give a uw4 at the end of the month, ClueBot starts off with a uw1 in just a few hours, but I also see that behavior in human editors. Ian.thomson (talk) 21:29, 16 March 2011 (UTC)

Add of access

Ok, so I think that SPI Clerks should have access to all relating to sockpuppets. It's strange that they do not have all sockpuppet things access. ~~Awsome EBE123~~(talk | Contribs) 19:07, 13 March 2011 (UTC)

What are you even talking about? Kevin Rutherford (talk) 02:06, 14 March 2011 (UTC)

I'm talking about that SPI Clerks gets to go block confirmed sockpuppet accounts and all of SPI. ~~Awsome EBE123~~(talk | Contribs) 19:02, 14 March 2011 (UTC)

Clerks are not necessarily Admins. That's why they don't get to block. — The Hand That Feeds You:^Bite 19:16, 14 March 2011 (UTC)

Classification, Quality and Authorship

Let me start by saying how amazing the Wikipedia is. Given the disparity of views and how difficult human nature is it is amazing that the Wikipedia works at all.

I wonder if it would have been better to have different classes of pages within the one wikipedia.

Quality

• Draft.
• Mad ramblings of uniformed amateur. ;)
• Original work (new ideas etc).
• Expert.
• Reviewed for accuracy.
• Reviewed for unbiased and referenced.
• Reviewed for readability.
• Core document.

Classification

• Encyclopedia entry (a page describing a comprehensive list of final results and facts relating to a subject).
• Encyclopedia summary entry (a page describing a summary of key results and facts, to allow quick understanding of a subject).
• Derivation (a page showing how results are derived).
• Rigorous proof (a page showing a rigorous proof. Bias is towards accuracy, not readability).
• Teaching Page (a page showing a lesson or lessons to allowing the understanding of an area. An ordered series of lessons designed to allow understanding of a subject).
• Research Paper (allow actual research papers to be published on the wiki).

Authorship

• Designated author (or co-authors)
• Expert authorship only (authors must have established expertise in field)
• General authorship

I think this could open the Wikipedia up and allow a broader range of content. Thepigdog (talk) 02:54, 14 March 2011 (UTC)

Please see WP:PILLARS and WP:ENC ♫ Melodia Chaconne ♫ (talk) 04:12, 14 March 2011 (UTC)

"Allow actual research papers to be published on the wiki" -- Never going to happen. This is a proposal which would fundamentally alter the structure of Wikipedia, as such such a system would probably need to be implmented as a new project. --nn123645 (talk) 14:48, 14 March 2011 (UTC)

Also, WP:OWN. Kayau Voting IS evil 15:00, 14 March 2011 (UTC)

Yes, "original works" and "experts only" will not happen because of WP:5P. There are already a number of systems that classify articles by quality or deficiencies, too.  Sandstein  20:30, 16 March 2011 (UTC)

Most of the above types of material can be posted on Wikinfo, while Citizendium has an expert approval system. Peter jackson (talk) 18:08, 17 March 2011 (UTC)

Automatically redirect CamcelCase

I usually have this issue when it comes to WikiProject redirects, but have had it elsewhere. It becomes really annoying when I am confused for a while as to why my link is redlinked. I usually try several other things before it dawns on me it was an issue of CamelCase formatting. I realize that this could cause issues when 2 items conflict and one is spelled with CamcelCase and the other isn't, but I think we already do something similar with plurals.陣内_Jinnai 23:28, 14 March 2011 (UTC)

If capitalization differences are autoredirected, then it becomes impossible to create distinct articles should one be evenetually needed under two capitalization schemes. For example, sat is a redirect page to a disambiguation page, while SAT is the college admissions test. If the redirecting was handled automatically, it would be impossible to distinguish between these two usages. There are likely many more examples. Instead, what you should do is create redirectes manually as needed. --Jayron32 05:45, 15 March 2011 (UTC)

I would think the software should be able to be updated to check for the lack of an existing article under the exact name if typed in and only then redirect.陣内_Jinnai 22:32, 15 March 2011 (UTC)

Since it already does this with first letters of the title, I would think it'd be possible as well. ♫ Melodia Chaconne ♫ (talk) 00:10, 16 March 2011 (UTC)

I could imagine a search function similar to Google's that asks, when you are searching for 'dinasore', say, responds with "Did you mean 'dinosaur'?" That should also resolve 'New York times' and 'CamcelCase'.  --Lambiam 22:11, 16 March 2011 (UTC)

That would be useful, although I think it should auto redirect and ask the question then because I'd think most of the time the answer would be yes and it involves less clicking for the user.陣内_Jinnai 20:50, 17 March 2011 (UTC)

Bot to reduce duplicate references

I have made a request to allow a bot to reduce duplicate references in articles, and I'm posting here to see if there is any opposition to the idea, or any requests to modify the way the bot would work. The bot request is here. In short, the bot will comb through this list of articles and search for duplicate references in each article. If it finds duplicate references, it will combine them using named references. In other words, if the bot finds multiple instances of this in the same article:

<ref>foobar.com</ref>

it will replace the first instance with:

<ref name=duplicateref1>foobar.com</ref>

and it will replace all subsequent instances with:

<ref name=duplicateref1 />

Please note that this bot will only affect references that are exact matches. If there is even one character that is different in two refs, it will leave them alone (unless the difference is only whitespace characters). I've made a table below to summarize the different cases that the bot will encounter, and whether or not it will take action on each case:

First ref	Second ref	Bot Action?	Comments
<ref>http://www.google.com</ref>	<ref>http://www.google.com</ref>	Yes	Exact duplication
<ref>http://www.google.com</ref>	<ref>http://www.google.com/stuff</ref>	No	Same site, different page. Not an exact match, so the bot will not touch it.
<ref>{{cite book|title=Foo|author=Bar}}</ref>	<ref>{{cite book|title=Foo|author=Bar}}</ref>	Yes	Exact duplication
<ref>{{cite book|title=Foo|author=Bar}}</ref>	<ref>{{cite book|author=Bar|title=Foo}}</ref>	No	This is technically an exact duplication, but arguments are out of order so the bot will be cautious and leave it alone.
<ref>{{cite book|title=Foo|author=Bar}}</ref>	<ref>{{cite book|title=Foo|author=Bar|page=47}}</ref>	No	Same source, but one references a page number. Not an exact match, so the bot will not touch it.
<ref>[http://www.disney.com Mickey Mouse]</ref>	<ref>[http://www.disney.com Mickey   Mouse ]</ref>	Yes	Only difference is white space, the bot will filter this out.
<ref>{{cite book |title=Foo |author=Bar }}</ref>	<ref>{{cite book|title=Foo|author=Bar}}</ref>	Yes	Only difference is newlines, the bot will filter this out.

Hopefully the table above demonstrates that the bot will only be fixing duplicate references which were created either by mistake or created by editors who don't know about named references, and it will not touch any references that were purposely not grouped together. There are currently over 5,000 articles that have duplicate references. Let me know if you see any potential problems with this proposal. Thanks. —SW— ^spout 16:55, 15 March 2011 (UTC)

• Sounds good to me, I don't know what we didn't already have this. I'm no programmer, though. Ian.thomson (talk) 17:09, 15 March 2011 (UTC)
• As described here, it sounds great in principle. Would want careful testing before implementation though. Skomorokh 18:30, 15 March 2011 (UTC)
• Support Nifty! Sounds potentially really helpful, with the appropriate care in rollout of course. I'd almost suggest that worrying about the cite template argument order is too conservative, but I'm guessing that if anything it's easier to code (and easier to code correctly) the current way, and it probably wouldn't pick up that many more duplicate refs. I wouldn't mind a version I could run on my own, either. --joe decker^{talk to me} 18:38, 15 March 2011 (UTC)

Reflinks will do this manually. ---— Gadget850 (Ed) ^talk 18:42, 15 March 2011 (UTC)

Awesome, I make a lot of use of RefTools but haven't played with Reflinks at all. Thanks! --joe decker^{talk to me} 18:46, 15 March 2011 (UTC)

The main Reflinks has a bookmarklet that you can drag to your browser bookmark bar. Clicking on it will open the current page in Reflinks. ---— Gadget850 (Ed) ^talk 04:20, 16 March 2011 (UTC)

You're right, it's much easier to program the bot if it doesn't have to worry about identical template arguments that are out of order. And, I agree that it would probably only find very few (if any) additional duplicate references if it was programmed to look for that case. Not worth the effort, and not worth the risk of introducing bugs due to increased algorithm complexity. —SW— ^{spill the beans} 20:57, 15 March 2011 (UTC)

• Applauds* your good engineering sense.  :) (And thanks to other folks for pointing me at Reflinks, which I'm also using now to good effect in a couple places.) --joe decker^{talk to me} 19:04, 16 March 2011 (UTC)

• I'm surprised this doesn't exist already. I guess existing instances I've seen are using reflinks and possibly AWB? Rd232 ^talk 00:43, 16 March 2011 (UTC)

I was also surprised that this doesn't exist. I think the fact that there are currently over 5,000 articles that have duplicate references is proof that either no such bot exists, or that it's not doing a very good job. —SW— ^soliloquize 15:45, 16 March 2011 (UTC)

• Oppose. Whether we should have named references or not (and correspondingly, whether we should have multiple footnotes at a single point) are matters of editorial judgment; an article repeating one reference exactly is not a problem. Septentrionalis PMAnderson 17:18, 16 March 2011 (UTC)

As Pmanderson says, using named references is optional. Bots should not add "named" references to articles where human editors have avoided using them; see WP:CITEVAR. — Carl (CBM · talk) 17:21, 16 March 2011 (UTC)

To be clear, the bot is specifically designed to not add named references to articles where human editors have avoided using them. It is specifically designed to find articles where duplicate references have been inadvertently introduced. Can you describe a situation where it is necessary to have multiple references in a single article which are 100% identical? —SW— ^chatter 17:38, 16 March 2011 (UTC)

• I don't see the objection. This does not seem to be the kind of variation in style that WP:CITEVAR is concerned with. It is the difference between:

John agreed,^[23] and the flight was uneventful.^[24] But on arrival in Chicago, the police was waiting for the duo.^[25] Martin had snitched on them.^[26]

---

References

23. ^ John Doe (1999). My Crook Years: an Autobiography. Hothouse Press.

24. ^ "An uneventful flight". The Chicago Flyer. 2009.

25. ^ John Doe (1999). My Crook Years: an Autobiography. Hothouse Press.

26. ^ John Doe (1999). My Crook Years: an Autobiography. Hothouse Press.

and

John agreed,^[23] and the flight was uneventful.^[24] But on arrival in Chicago, the police was waiting for the duo.^[23]. Martin had snitched on them.^[23]

---

References

23. ^ ^{a b c} John Doe (1999). My Crook Years: an Autobiography. Hothouse Press.

24. ^ "An uneventful flight". The Chicago Flyer. 2009.

What is the value of having repeated identical entries in the References section?  --Lambiam 17:58, 16 March 2011 (UTC)

Exactly, there is no value to having repeated identical references, and WP:CITEVAR is not a relevant guideline with respect to this topic. If sentence #1 cites reference #1, and sentence #2 cites reference #2, but reference #1 and reference #2 are 100% identical, then there is no difference for both sentences #1 and #2 to cite reference #1. The only difference is that it is more efficient, saves space, improves readability, and generally makes logical sense. —SW— ^chat 18:54, 16 March 2011 (UTC)

It sounds like you are arguing that using named references is required by WP:CITE, but it isn't. Articles are not required to use named references even if they have "100% duplicate" citations, which is why a bot can't just go through changing the duplicates to named references. — Carl (CBM · talk) 19:01, 16 March 2011 (UTC)

Bots are not limited to perform only tasks that are explicitly "required" by some guideline or policy. The reason that grouping identical references is not required is because Wikipedia is not a bureaucracy, and not every common sense rule has to be spelled out. There is no logical reason why having duplicative, identical references is preferable to grouping them. Unless you can provide some kind of example situation (preferably with respect to an actual, real, existing article) where grouping 100% identical references will result in an actual problem, or an example situation where duplicative references are actually preferred, then the basis for your opposition is unfounded. —SW— ^communicate 20:12, 16 March 2011 (UTC)

Our guiding principle is that, in optional matters, the established citation style in each article should be preserved, and new references should be added that match it. The style should not be converted from one optional style to another based solely on personal preference. This includes, among other things, the choice whether to use named references in an article. Neither using them nor not using them is objectively better; it's just a matter of preference. — Carl (CBM · talk) 20:32, 16 March 2011 (UTC)

The issue of named references is a red herring. It's not like the bot is going around naming every reference it can find. The primary purpose of the bot is to group identical references, and it just so happens that it accomplishes this by naming them. Having identical references is not a personal preference, nor is it a style preference. It is illogical and inefficient. Again, you have not presented any logical reason why identical references would be preferred in any real situation, or why grouping identical references would be problematic in any real situation. We're looking for logical reasons to not perform this task, not reasons based on an emotional response to automated edits. —SW— ^confabulate 20:48, 16 March 2011 (UTC)

The choice of style is always a little illogical. But since there's no lack of vertical space in articles here, there's also no need to be efficient with it. There is a long history of disagreements over citation styles where everyone feels their preference is the only logical choice; but in reality the choices are all more or less equivalent. That's why we have a presumption to keep the original style. — Carl (CBM · talk) 21:13, 16 March 2011 (UTC)

I agree with most of what you're saying. The only thing I disagree with is that this particular issue is a style issue. The use of duplicate references is, in my opinion, a mistake on the part of the editor, not a conscious stylistic choice. If this were a style issue, then there would be at least two valid ways of dealing with identical references. You would be able to say "In situation A, it's better to do it this way, and in situation B, it's better to do it a different way." That is a style issue. In this case, there is only one valid way to deal with identical references, and that is to group them. If you disagree with that statement, then please provide an example of a real-life situation where not grouping identical references is clearly preferable to grouping them. We don't force editors to group references because it is not technically possible. However, it is beyond clear that it is considered preferable to group them, as evidenced by the fact that no one can provide an example case where it is not preferable. —SW— ^speak 23:41, 16 March 2011 (UTC)

Some find sequential references are simpler to follow in a text, and some style guides support that. In the Wiki implementation, if you have three refs reused a dozen times each, then grouping with named refs makes some sense, but grouping a handful of refs that are repeated once or twice each impedes sequential referencing for no substantial benefit. So there are some situations where is is preferable not to group refs. However, if you say it is "beyond clear that is it considered preferable to group them", what is the huge over-riding benefit that trumps any other consideration? Gimmetoo (talk) 20:42, 17 March 2011 (UTC)

• Comment Don't most people use ibid when referring to the same thing? I like the lettering thing. Sir William Matthew Flinders Petrie Say Shalom! 18:06, 16 March 2011 (UTC)

See WP:IBID, which specifically instructs us to not use ibid. —SW— ^express 18:28, 16 March 2011 (UTC)

• Sounds like a very sensible bot proposal. As said above, there is no value to having repeated identical references, and no style variant that I know of calls for repeated identical references.  Sandstein  20:27, 16 March 2011 (UTC)

Many style guides for endnotes say they should be numbered consecutively [14], which means that the same number cannot be used in two different places for the same reference. Do you know of any style guide for endnotes that allows the same endnote number to be repeated after larger numbers have been used? The same question applies for footnotes, but I doubt any guide allows using a footnote number for a footnote that appears on a previous page. — Carl (CBM · talk) 20:40, 16 March 2011 (UTC)

You can't be serious. Random external style guides don't trump the MOS. If sequential footnotes were required, then the mechanism for grouping footnotes wouldn't have been made available to us. Can you tell us the real reason that you are so vehemently opposed to this proposal that you would go to such lengths to discredit it? —SW— ^comment 20:52, 16 March 2011 (UTC)

There's nothing in the MOS that requires named references – that's my point. You're arguing as if they were required somehow. OTOH Sandstein said he had never heard of a style guide that would require repeating a reference, so I pointed out that some do, by requiring endnotes to be sequentially ordered. — Carl (CBM · talk) 21:13, 16 March 2011 (UTC)

Ok, let me clarify my position as much as possible, as it seems you're not understanding the point. It's true that the MOS doesn't require identical references to be grouped. On the other hand, the MOS doesn't prohibit identical reference from being grouped either. In fact, the Mediawiki interface specifically provides a mechanism to group identical references, suggesting that this is a desired feature. Furthermore, bots have never been restricted from performing tasks that weren't "required" by some guideline or policy, so your argument that it is not required by MOS is irrelevant. Also, while the MOS does pull some of its style guidelines from other organizations' style guidelines, that doesn't mean that we are bound to any style guideline you can find on google, so that argument is also irrelevant. Besides, I think Sandstein was saying that he's not aware of any Wikipedia style variant, not that he was not aware of any style variant that has ever existed in the history of mankind. Here is my main point, which you or no one else has yet responded to satisfactorily: Under what circumstances would it be beneficial/desired/valuable to adopt a personal preference or style preference whereby duplicate references are not grouped? When would it ever be better to leave identical references ungrouped? Until I get a satisfactory answer to those questions, then I can't help but to feel that you are arguing for the sake of arguing. —SW— ^communicate 22:40, 16 March 2011 (UTC)

I'm just pointing out that we have a longstanding principle not to do this sort of thing. WP:CITE allows article to use named refs, or not to use named refs, and the established style should be respected. — Carl (CBM · talk) 23:54, 16 March 2011 (UTC)

• I regularly coalesce identical refs, like here, and have not yet once run into an adverse reaction. My impression is that, apart from the cases that were introduced before we had ref naming, many editors don't know about the possibility or do not understand how to use it (and copy–paste is easy), while in other cases duplicate refs are inadvertently introduced by editors unaware of the fact that there is already an identical reference elsewhere. I've never had the impression such duplication was a conscious preference.  --Lambiam 22:26, 16 March 2011 (UTC)
• I could've sworn some of the cleanup bots already do this. I have yet to come across a single article where references are duplicated on purpose and named references are avoided on purpose, so some of the above arguments seem rather silly to me, to be honest. --Conti|✉ 22:41, 16 March 2011 (UTC)
• To combine a couple threads above, I'll respond here. If an editor writes an article in which he or she consciously chooses to keep the footnote numbers consecutive, by not using named references, that is certainly stylistic choice - what else is it? We have a longstanding practice of respecting such choices unless there is a consensus that something has to be done some other way. That's expressed both in WP:CITEVAR and WP:STABILITY in the MOS: when two different styles are both acceptable, the first style to be chosen should be left, not changed solely for the benefit of using a different optional style. This principle is motivated by the perennial difficulty of getting any agreement on these things; arguments that one style is better than another tend to be Qixotic. In the case at hand, the benefit of named references is marginal, because there is no space limitation on the references section of an article. On the other hand, the idea that footnotes should be numbered consecutively is quite common in real style guides and is certainly compatible with the MOS. — Carl (CBM · talk) 23:51, 16 March 2011 (UTC)

To my knowledge, keeping footnote numbers consecutive has never been important on Wikipedia, nor has it ever been spelled out as a priority, a requirement, or even a suggestion in the MOS (again, to my knowledge). —SW— ^chat 00:27, 17 March 2011 (UTC)

It doesn't matter whether I, or you, find it important. If the style in an article is established that way, in the absence of any requirement that named references have to be used, we need to respect the preferences of other editors. Everyone has their own taste and their own preferences, which may not make sense to others. We recognize that in our policies by saying not to change from one optional style to another. — Carl (CBM · talk) 00:36, 17 March 2011 (UTC)

Now you're assuming that editors are making conscious choices to preserve the consecutive numbering of citations. What evidence do you have that at least some of the duplicative references are a result of conscious style choices by editors, as opposed to inadvertent coincidences or blatant mistakes? —SW— ^express 00:55, 17 March 2011 (UTC)

Carl, do you have any examples of articles where editors specifically choose to use duplicated references? Because I'm getting the impression you're talking about a hypothetical problem here that doesn't actually exist anywhere on Wikipedia. --Conti|✉ 07:51, 17 March 2011 (UTC)

I thought this whole discussion began with a list of articles where there were duplicated references; aren't those examples? If we assume good faith, that means assuming that editors edited articles intentionally, and formatted the references the way they wanted to. It's not as if named references have ever been required, so not using them is not a mistake in any way; if an editor didn't use them, that's the prerogative of that editor, and perfectly acceptable according to the MOS and WP:CITE. — Carl (CBM · talk) 11:54, 17 March 2011 (UTC)

That's a rather odd way of defining "assuming good faith". Is it suddenly "assuming bad faith" when I assume that people might not even know of named references, and therefore don't use them? Or that the large majority of editors simply wouldn't care one way or the other? No one here talks about named references being required. It just simply makes sense to use them, and apart from "there might be somewhere someone that might not want to use them for no specific reason", there's no reason not to use them. --Conti|✉ 12:37, 17 March 2011 (UTC)

The existence of articles with duplicate references is not proof that they were created that way intentionally. AGF has nothing to do with determining whether someone did something as a conscious stylistic choice, or if they did it unintentionally or as a mistake. If I misspell a word in an article, I would hope that you wouldn't "AGF that I meant to do it" and not fix it. —SW— ^babble 14:19, 17 March 2011 (UTC)

A good example of that is this edit, which introduced duplicate refs in an inferior style (just the bare urls) in an article that at that moment had strictly coalesced refs, largely in standard style and at least giving the source titles. I see no reason not to assume good faith, but it is quite far-fetched to suggest that this referential duplication is the result of an intentional choice reflecting the editor's stylistic preference.  --Lambiam 22:15, 17 March 2011 (UTC)

Articles are not required to use duplicate citations and humans can change them to named references, which is why a bot can just go through changing the duplicates to named references. There also is no need to be inefficient with vertical space merely because there's no lack of vertical space in articles. If an editor disagrees with the change, they can just undo it. Change in an article always invites a potential for disagreement. However, until there is a disagreement or at least an objective/explicit preference for a particular style, there is no basis to preserve one style over another, particularly for stub and start articles. Consensus preference for removing duplicate references is set by Wikipedia:Featured article criteria - criteria to which all articles should aspire. -- Uzma Gamal (talk) 15:43, 17 March 2011 (UTC)

• Support A no-brainer, I think. Now if we can only reduce the "single word supported by 25 cites syndrome". Any bot available to find the worst offenders? Collect (talk) 14:24, 17 March 2011 (UTC)

I just saw one of those articles, but now forget where it is. Good idea for another bot - list of articles having more than three adjacent references sorted by max number of adjacent references. -- Uzma Gamal (talk) 16:03, 17 March 2011 (UTC)

There may already be a toolserver script out there that does this. —SW— ^prattle 16:31, 17 March 2011 (UTC)

• Support trial tests - In general, it is a good idea. As for an issue, not very often, I'll use duplicate references when I want to use two different URL links to two different pages in the same book posted at Google. If the bot were to remove one of my two URLs, that would be a mistake. I think the bot will have to have a lot of exceptions to its decision to remove duplicate references. I suggest finding the most clear cut case for removing duplicate references - the one where just about everyone will agree that it would be beneficial to remove the duplicate references -- and use that to implement the bot v1. Let everyone chew on that for a while then slowly add a second duplicate reference removal condition. I suggest starting with dublicate {{cite web}} references since newbies are more likely to cite to web pages and to not know about naming a citation. Also, perhaps you can limit the bot to operating on articles rated below a B class. Carl's point above about preferred styles likely is more true for B and higher class articles. -- Uzma Gamal (talk) 15:27, 17 March 2011 (UTC)

I would hope that no GA's or FA's would have duplicate references. That would almost certainly be something that gets addressed in GA/FA review. And, for the moment, the plan is to run the bot once, not let it run continually. If the backlog bloats up again in the future, I might run it again, but it would probably be several months down the line. —SW— ^yak 01:20, 18 March 2011 (UTC)

See the table at the top of this thread. If two references have slightly different URL's, the bot will not group them. It will only act on references that are 100% identical. —SW— ^prattle 16:31, 17 March 2011 (UTC)

OK, what about limit the bot to operating on articles rated below a B class. The bot won't be hitting uf FA or GA articles, right? Also, the bot should not return to any article it has worked on since (i) if the bot reference change is kept, then there is no reason to return and (ii) if the bot reference change is undone, then a human decided what they wanted and the bot should not re-undo that. -- Uzma Gamal (talk) 00:31, 18 March 2011 (UTC)

• Like CBM argues, articles have been written with all refs in sequence, consciously avoiding reused named refs. A bot really shouldn't change that. But, there is a fairly natural way to handle this - only automate work on articles that already have some minimum number of reused named references (say 5), and definitely avoid any article which does not have any reused named references already. That should avoid the bot working on any article written without reusing named refs. Gimmetoo (talk) 20:42, 17 March 2011 (UTC)

I'm not aware of any conscious movement to support the sequential numbering of references in articles. Is this just a feeling that you have, or do you have any evidence to support the fact that there is a conscious effort to keep references sequential, or any evidence of articles where the major editors of an article expressly agree that sequential references are important on that article for some particular reason? Also, the limitations you've proposed above would make the bot almost completely non-functional. The vast majority of articles with duplicate references don't already use named references, because if they did then they wouldn't have duplicate references. This is because duplicate references are not intentionally created, they are created either by mistake or by editors who are not aware that there is a mechanism available to group them. Take a look at the reference sections of these example articles and tell me you don't see a problem (the bold ones are especially terrible):

• 1984 Tampa Bay Buccaneers season
• 1985 Tampa Bay Buccaneers season
• 2011 Asian Winter Games opening ceremony
• 2011 Clube de Regatas do Flamengo season
• 2011 in hip hop music
• Abram Fitkin
• Amanda Knox: Murder on Trial in Italy
• Antonia Handler Chayes
• Arian controversy
• Australian Road Rules

And considering I only searched until the end of the A's, it's all but guaranteed that there are even worse examples out there. Only one of these articles would pass your criteria of already having 5 named references (Arian controversy). I don't see any evidence of a conscious effort here though. Take Australian Road Rules as an example. It's hard to argue that an editor consciously did that to keep references sequential, since the same reference is repeated a dozen times in a row with no other references in between. So, if they had grouped the references, it would not have broken the sequential numbering. You can also see from these examples that grouping references makes it much easier to determine how heavily an article relies on a particular source. If there are 400 references in an article, and one reference is repeated 50 times throughout the article, it would be difficult to determine that this is a reference on which the article relies heavily. If it was grouped, however, you'd be able to see it immediately. There is no benefit to sequential numbering, and that is why there is no reason to strive to keep reference numbers sequential. —SW— ^communicate 21:36, 17 March 2011 (UTC)

It's not a "feeling". If an article has 20 refs, two of which are used twice and all the others used once, I don't perceive any significant benefit from introducing little 'a' and 'b' marks on the two, and doing so would break sequence, which I perceive as a loss. Sequential refs are easier to follow for verification and in accord with some style guides. If you don't agree those are benefits, that's fine, but saying "there is no benefit" is not exactly correct. Your proposed bot would be useful for articles which have a lot of named, repeated references, but get sources re-added regularly by editors who are not aware of what sources are already cited. Gimmetoo (talk) 22:34, 17 March 2011 (UTC)

How do sequential refs make it easier to follow for verification? All you're doing is matching numbers. Actually, in most cases all you're doing is clicking the link and looking for the highlighted reference, so the sequential nature of the number makes no difference. Even if you were going through an entire article top to bottom to verify references, it would still be beneficial to have grouped references. That way, if reference #7 is used 5 times in one section, and you've already read through reference #7, then you can just skip over it. With sequential references, you would waste all kinds of time looking through the references just to find out that references 14, 19, 27, 53, and 66 are all the exact same source that you've already read. I can say that "there is no benefit to grouped references" because no one has produced one as of yet. So far, the reasons you have described include: "I don't perceive any significant benefit", "[it] would break sequence, which I perceive as a loss", "sequential refs are easier to follow for verification" (with no other reason to support why it is easier), and "[it is] in accord with some style guides" (style guides which have nothing to do with Wikipedia, and which do not include the MOS). None of these are valid reasons, in my opinion, and I believe I have refuted them all. You also mention that you believe that the bot would be useful only for articles which already have a lot of named, repeated references. What about the vast number of articles that have been recently created, which have been primarily edited by one editor, where that editor is not aware of named references? This case makes up the majority of the 5,750 articles that currently have duplicate references. Also, keep in mind that we are currently talking about 5,750 articles, which represents 0.16% of articles on the english WP. The fact that this problem affects such a relatively small number of articles implies that #1, duplicate references are not desired since 99.84% of articles already don't have duplicate references, and #2, that we probably shouldn't be making such a big deal over it. —SW— ^chat 23:05, 17 March 2011 (UTC)

• • • • None of these are valid reasons, in my opinion, and I believe I have refuted them all. Then you don't know what you are talking about. Absolutely and unconditionally oppose. Septentrionalis PMAnderson 02:26, 18 March 2011 (UTC)

See also Help:Footnotes#Multiple_citations_of_the_same_reference_or_footnote, which does not mention that this is optional or subject to stylistic interpretation in any way. Your "absolute oppose" is duly noted, but without a logical reason for your oppose, it carries little weight. —SW— ^express 03:51, 18 March 2011 (UTC)

Nor does it say named references are required. I have provided a case where it is not preferable to use repeated named references. You appear to disagree, and apparently think that "it is beyond clear that it is considered preferable to group them". Fine. Can you convince me that reusing named references in the case I describe is absolutely and completely beneficial so as to override any other consideration from any other editor? Gimmetoo (talk) 04:45, 18 March 2011 (UTC)

Note that Pmanderson was just blocked for 1 week for an unrelated incident, and therefore probably won't be able to respond. —SW— ^speak 04:15, 18 March 2011 (UTC)

Strong support, if only because I always group my references because I think it makes sense. However, having worked as a major contributor to pages (eg.Brontë, Malvern, and a few others) that have hundreds of footnotes, it makes even more sense. There is also the aspect from my experience at AfD of having to sift through refs on articles that 'claim' to be well referenced, that to a more casual reader, a long list that includes the same duplicated ref makes it look as if the article is well referenced, giving a false impression of notability. Kudpung (talk) 07:52, 18 March 2011 (UTC)

Wikibets

Anyone want to start a page where users place bets on things like sporting events, elections, or really anything. We would be betting work on Wikipedia. Example:

Superbowl:

Person A Offer: 20 new page patrols says the Greenbacks win next season

Person B: I accept

Music:

Person A Offer: Getting any article of the other person's choice to good article status. I'm betting that Justin Bieber's next single doesn't even break the top 40.

Person B: His next single will make it to the top 20, I'm accepting this bet. My article will cardiovascular system.

Person A:Damn, nobody wants to touch that article!

Some wikifun to pass the time and hopefully get some work done. Thoughts?AerobicFox (talk) 20:58, 15 March 2011 (UTC)

No, you are not going to be immortalised in WP:NOT with such a poor proposal. That page is only meant for things that might with some plausibility be expected to fit here, or that a lot of people think should be allowed. Try again. Hans Adler 21:43, 15 March 2011 (UTC)

I lol'd Sir William Matthew Flinders Petrie, AKA TheArchaeologist Say Herro 22:00, 15 March 2011 (UTC)

That is pretty harsh Adler considering the proposal could just be an add on to our current bounty boards.AerobicFox (talk) 22:25, 15 March 2011 (UTC)

I'll bet you 15 featured sounds that your wikibet proposal is not accepted. —SW— ^soliloquize 23:49, 15 March 2011 (UTC)

I like the enthusiasm! Unfortunately though I don't think it will be accepted :( , so I decline your bet. Maybe I will just make bets with random users...AerobicFox (talk) 06:00, 16 March 2011 (UTC)

SW, if you mean that you're going to upload FS quality sounds, I'll pay in barnstars. If you're the performer, I'll pay in custom made barnstars. How's that? Sven Manguard Wha? 06:21, 16 March 2011 (UTC)

Can I have a barnstar too? What's that worth in Jew gold? (Also, what is it? Seriously). Sir William Matthew Flinders Petrie, AKA TheArchaeologist Say Herro 06:30, 16 March 2011 (UTC)

Right... Jew gold. Go be racist somewhere else please, there's no place for that here. Sven Manguard Wha? 06:46, 16 March 2011 (UTC)

As a Jew I reserve the right to make self-depricating jokes as it is part of our contemporary culture, especially that memorable one from South Park. Please check my userpage where I put that bit of my heritage (Ashkenazi Jewish). Also relax mate, it's the net (though being the net I can see how you'd make that mistake what with the rampant anti-Semitism elsewhere on it). ;) Sir William Matthew Flinders Petrie, AKA TheArchaeologist Say Herro 06:56, 16 March 2011 (UTC)

Eh, your comment wasn't appropriate, but I suppose I overreacted. Sven Manguard Wha? 06:58, 16 March 2011 (UTC)

Nah, despite my reaction, it's good to see people stand up for us now and then. Jewish humor is rarely appropriate, mate. ;) (We came up with most of the holocaust jokes) Though I suppose if my username were more clickable then you could have just clicked there and seen my background etc. Another reason to change it. On the issue of race in Judaism btw, I recommend checking out Category:Jewish_ethnic_groups, we come in many different flavours, but are genetically related (except one group, which I forget). So what was a barnstar again? What do they do for you? Sir William Matthew Flinders Petrie Say Herro 07:11, 16 March 2011 (UTC)

You are mistaken, and Sven Manguard did not overreact. Wikipedia is connected to the Internet but different procedures apply here, and crass commentary is not permitted. It can take quite a long time and lot of argument, but eventually people who repeatedly make comments such as yours are persuaded to do it elsewhere. Johnuniq (talk) 09:48, 16 March 2011 (UTC)

::::Oh will you relax, lol, such outward hostility like that can dissuade one from editing all together as it makes them feel unwelcome. Are other groups not allowed to make self-depricating comments in talk pages as well or does it just apply to us? I am curious, how is it handled when it does come up (in practice, not in theory)? I will take the approach that as you feel offended by it, I will not make self-depricating jokes on the encyclopedia, but I do still consider it to be an important part of our culture, and so I feel nothing wrong whatsoever about it. Sir William Matthew Flinders Petrie Say Shalom! 17:06, 16 March 2011 (UTC) Edit: alright, now that I am a bit more chill about this, and can look at it without the distraction of being offended, let me analyse it as an anthropologist. I think this is an instance of common cultural and (in my case) professional practice coming up against Wikipedian cultural practice and rules. So as an anthropologist I must of course conclude that the best approach to take is to adapt to the cultural practice of the Wikipedians so as not to cause further offence to them (and I know you're probably thinking I am talking about you guys like natives, etc, but the same applies if you're in France or elsewhere). So that is what I will do. Though might I suggest in the future this sort of thing be approached with a gentler hand? What starts and argument is two or more people approaching something in an angry manner rather than one person being calm, polite and friendly and dealing with it in that manner. Remember the old saying "you win more flies with honey than you do with vinegar." You do that until friendliness no longer works and then simply bring the banhammer. No one can blame you if you failed, but odds are that being friendly diffuses the situation. Anyway, about this bet thing, I oppose.

• Oppose I just don't like the idea of turning Wikipedia into an e-Casino, even if there is no actual money involved. Sir William Matthew Flinders Petrie Say Shalom! 17:26, 16 March 2011 (UTC)
• There's Wikipedia:Last topic pool -- Uzma Gamal (talk) 00:24, 18 March 2011 (UTC)

This might be a fun thing to have on a completely separate website..... Wabbott9 (talk) 01:35, 18 March 2011 (UTC)

Fair use upload bot

Please see commons:Commons:Village_pump#Proposal:_Fair_use_upload_bot for my proposal for a bot that would re-upload images that are deleted on Commons but in use on En to En as candidates for fair use. Please comment there. Dcoetzee 12:11, 16 March 2011 (UTC)

Time limits on adminship

I propose that adminship be granted for a period of three years only. An editor must also wait three years between adminships. All existing admins that have been admins for longer than three years lose that status (but may reapply for adminship in three years). I think this proposal is a good idea because:

1. It reduces admin burnout
2. It reduces factions of admins persisting for any length of time
3. It reduces the special status of adminship - admins really are just the same as other editors, they only temporarily serve in a higher capacity
4. It ensures a renewal process in the admin pool
5. It helps prevent WP rules and policies from becoming too byzantine. Very long term admins will know all the existing WP rules inside and out and naturally attempt to extend them to cover every eventuality. Short term admins will seek a smaller ruleset.

--Surturz (talk) 12:47, 16 March 2011 (UTC)

I think limiting terms is a good idea, but I think there will be a lot of resistance from long time admins, especially those who use a lot of admin specific tools to do their day to day work here. --NickPenguin_(contribs) 13:12, 16 March 2011 (UTC)

In that case, the newest admins should sign up for the policy. It will increase their influence, and improve their ability to implement new ideas. I suspect that people being people, some of the long-time admins have become warlords of a sort with entrenched factions? I pulled the "three year" period off the top of my head. Is there a way to work out a time limit that would eliminate the oldest (say) 40% of admins? --Surturz (talk) 13:19, 16 March 2011 (UTC)

• I think a set time limit is a very good idea, I would even advocate reducing it to 2 years. However, I'm not sure about a long gap in between though, perhaps they could re-appply immediatly for a vote of confidence. More importantly still, I would like to see editors having to show a 2 year commitment to the project before being able to become admins in the first place - I think this would reduce a great many of the problems which are caused by Admims being unaware of policy and common sense. Giacomo Returned 13:21, 16 March 2011 (UTC)

This proposal isn't practical. WP:RFA created 117 new admins in 2009 and 75 in 2010. If we carry on promoting people at the same rate as last year then by the end of 2011 this proposal would mean that we would have about 270 admins. Since we currently have 1,780 (780 of them active) this would probably result in huge backlogs in admin-related tasks. Hut 8.5 13:23, 16 March 2011 (UTC)

In order to assess partiality. It would e a good idea if those commenting on this stated if they were themselves admins. I am not. Giacomo Returned 13:26, 16 March 2011 (UTC)

I'm an admin, and I think some time limit on adminship would be a good idea. 3 years sounds fine, although it would be good to know how many reconfirmation RfA's we'd have in that case (how many users that were made an admin three years ago are still active as an admin today?). A mandatory pause of three years sounds problematic for the reasons Hut 8.5 outlined above. --Conti|✉ 13:29, 16 March 2011 (UTC)

Well, I'm still as active as an admin as I was three years ago; even more, since the number of admins working copyright cleanup queues has declined. --Moonriddengirl ^(talk) 13:33, 16 March 2011 (UTC)

(edit conflict)As an admin, I'm tentatively in favor of time limits, but opposed to a 3-year break in service. A month without the tools would be sufficient to see if you think you still need them enough to jump back in the meat grinder... --SarekOfVulcan (talk) 13:37, 16 March 2011 (UTC)

(edit conflict)x2 Assuming we maintain a pool of around 1000 active admins we would have one reconfirmations/RFAs per day on average with a 3 year time period, which is less than RFA handled in 2007. Should be doable. Yoenit (talk) 13:38, 16 March 2011 (UTC)

I would suggest a large cohort of existing admins would mean that less and less people get granted adminship as time goes on. Newer admins will encourage newer users. With a time limit, we do not need to vet admin candidates as much, since there is a built-in limit to their power.

This link shows the 1780 admins, 40% of 1780 = 712, and admin # 712 was created Nov 2004. So we could set the time limit at SIX years and still retire the 40% longest serving admins.

Reconfirmation isn't required, I think the link I provided can be used to work out which admins are auto-retired. --Surturz (talk) 13:34, 16 March 2011 (UTC)

Your link gives the date that the username was created. It doesn't tell you anything about when adminship was achieved, other than that it has to be more recently than that. Dragons flight (talk) 13:41, 16 March 2011 (UTC)

60% of 1780 is 1068. 818 people were promoted to administrator in 2007 or later, and there were 353 promotions in 2006, so if you wanted to retain 60% of the admin corps the time would have to be at least four-five years. Of course not all these people are still administrators so the limit might have to be set back even further. At this stage the proposal isn't going to be very good at tackling burnout, because if you're going to experience burnout it's probably going to happen less than five years after becoming an administrator. Hut 8.5 14:02, 16 March 2011 (UTC)

Two of the above reasons have nothing to do with being an admins: factions of users, and byzantine rulesets. Both happen with experienced users, and admins that are abusing their rights to enforce these when it is counter to consensus is not appropriate. Admin burnout can be dealt with on a voluntary basis, though I could support periods where as less-strict remedies for burnout is to deny an admin their admin status for a month or so.

To me, it is the lack of admins in various areas that need regular admining that put the task to only one or two dedicated volunteers that is an issue; that persists today. Any process along the lines of the above will cause these processes to break (we can't force admins to work on specific tasks so we can't necessarily replace the dedicated volunteers). --MASEM (t) 13:50, 16 March 2011 (UTC)

With the health of our community being as fragile as it is right now, I think that experienced admins are a resource that we won't be able to replace if we desysop all of them. If people want to serve the community long term as an admin, why not let them? Arbcom, though imperfect, can remove serious problem admins. (I am an admin myself, though I rarely use the tools)--Danaman5 (talk) 13:59, 16 March 2011 (UTC)

With a regular reconfirmation of adminship, say, every 3-5 years, admins could serve as long as they (and the community) want to. --Conti|✉ 14:03, 16 March 2011 (UTC)

Reconfirmation is possible, but this proposal specifically is talking about a forced break between terms. And to extend what the original idea is, reconfirmation likely would not fix any of the mentioned problems with an "old boys" network (as they pile on their "support retention" to a reconfirmation) --MASEM (t) 14:09, 16 March 2011 (UTC)

This process will just create a lot of unneeded bucrocreacy. In most cases the reconfirmation of good admins will have a huge supporting result, making it unneeded to go through it in the first place. It may be better to leave reconfirmation processes for cases when there's really a strong and specific reason to propose it. MBelgrano (talk) 14:21, 16 March 2011 (UTC)

The issue is that, of the 700+ admins which are "active", all but maybe a few dozen never show up as being "problematic". In other words, this is a case of taking 95% of the admins and making them jump through some silly burocratic hoop merely to catch the 5% that cause problems. Why not just come up with a better procedure of addressing the 5% of the problems directly, and let the other 95% do their job... For the record, I am an admin, have been for many years, and if anyone wants me to give up my tools for any specific action I have taken, feel free to raise the issue specifically about me. However, there is no need to tar the entire corps of administrators because I screw up. Deal with the individual on the individual basis, not on the group. --Jayron32 15:18, 16 March 2011 (UTC)

• I'm an admin, and this idea has a lot of problems. It fails to consider that what is controversial and damning at RfA is not necessarily what is inappropriate. If, for example, I close a difficult AfD, I will undoubtedly piss off one side whatever happens. This is inevitable. The impact of turning adminship into an eternal popularity contest is that "difficult" decisions, those requiring judgment calls, will be avoided. However, I like the theoretical basis for it, and personally I'm not going to stop closing things just because I have the chance of being shouted at for it. As such, I hereby announce that I will stand for adminship again, precisely two years after my successful RfA. If it goes well, it'll reassure those people worried (me included) that such a system would have a chilling effect on our admins. If it doesn't, the fireworks display will be damned fantastic :P. Ironholds (talk) 16:15, 16 March 2011 (UTC)
• I'm not sure that time limitations solve anything. There needs to be an efficient recall mechanism whereby serious errors of judgment or abusive behavior can be reviewed, defenses mounted, and votes of confidence taken. Carrite (talk) 17:23, 16 March 2011 (UTC)

Oppose: Personally, I think that mandatory reconfirmation after 3 years is a bit too short. It'll cause unnecessary trouble for our existing admins. Concerning admin burnout, this would not solve the problem. As Wikipedia isn't a bureaucracy, this would be against the goals of the project.Jasper Deng (talk) 17:35, 16 March 2011 (UTC)

• Most of our admins were appointed more than three years ago, so to desysop them and put them on a three year break from adminship would be an irresponsible action that would mean attack pages sat around for longer and vandals could do more vandalism before they were blocked. I'm one of the 346 admins appointed in the three years up to the beginning of this month, but don't imagine this would leave you with 346 admins, as many of those 346 have already gone. On current trends we won't appoint half as many admins this March as the 22 who were appointed in March 2008 and who on this proposal would be about to stand down for three years, so the number of active admins would not only be slashed but would quickly slide further under this proposal. If you want to introduce term limits first fix the problems at RFA and start appointing more admins than we lose. We currently have only 12 admins who started editing in the last 24 months, the challenge at RFA is how do we persuade those who joined us in 2008, 2009 and early 2010 to volunteer for adminship. Discussion of term limits is at best a distraction from that. ϢereSpielChequers 17:50, 16 March 2011 (UTC)
• I would agree with a 4 year term of adminship. I think that taking three years off could cause good editors to loose interest in the project. Maybe 8 months off. Inka⁸⁸⁸ 07:17, 17 March 2011 (UTC)

---

This is clearly listed at WP:PEREN#Reconfirm_administrators. Mono (talk) 17:35, 16 March 2011 (UTC)

• OpposeI'm an admin, and I think periodic reconfirmation would be a good idea, as would be some period between terms of adminship. "Elected for life" sounds like a tinpot dictator, although in a kinder light it might be viewed as being like a US federal judge, who can serve until he dies, resigns, or is impeached for bad behavior. I have seen many admins desysopped for bad behavior. The proposal is flawed: Three years off after three years service is too long, and would slash too severely the pool of hardworking volunteers which keep this project from turning into Uncyclopedia, full of vandalism, spam, and agenda editing. I could agree with a 4 or 5 year reconfirmation, or a 3 or 6 month timeout after 4 years with the option of reapplying. Then the folks at WP:RFA would not just be speculating about whether the applicant would properly wield the mop, and could look at performance versus promises about what admin activities would be done. Stepping away from the keyboard for a while and experiencing real life might be good for some admins (and other editors) who are glued to the keyboard 50 hours per week. Some of the anger aimed at admins in various forums is, in fact, from agenda editors who want to ignore the principles of Wikipedia and use it for their own purposes, without hindrance, don't want to be hindered in their flaming and personal attacks on other editors. (Speeders would prefer fewer traffic cops: after being a cop for three years, the cop should take 3 years off). Slashing the ranks of active admins, and making sure they are fairly inexperienced, would make it easier to make Wikipedia say what they want it to say, regardless of reliable sourcing, verifiability, neutral point of view, or undue weight. I expect that a variety of agenda editors would try to vote out any good faith admin who had thwarted their desires, even if it was done in full accord with policies and guidelines. More participation on WP:RFA from the general community would be needed to keep a cabal from voting out the good guys, broadly defined. The shiny buttons an admin gets do not confer any special privilege in regular editing that I have noted. After 3 years as an admin, I do not detect any special "power" when engaged in regular editing activities such as AFD debates, and regularly endure personal attacks from editors who have different views and who do not agree with Wikipedia:No personal attacks. Edison (talk) 18:05, 16 March 2011 (UTC)

I think comparison with a federal judgeship is probably taking our role a bit too seriously. Most jobs are pretty stable unless the company goes out of business or you screw up repeatedly and/or egregiously. (It's not like admins are paid; there's no incentive for Wikipedia to lay us off to reduce costs or bust our union.) Janitors, grocery store clerks, garbage collectors, bus drivers, mailmen, truckers, gardeners — they've all got a job for life, at least as long as the work needs to be done. TenOfAllTrades(talk) 18:30, 16 March 2011 (UTC)

There is such a thing as periodic corporate downsizing, where they lay off a fraction of the workers, chosen more or less randomly. A "job for life" might have been more typical in the 1950's than today. I see a great many people who lost their jobs in favor of a new hire who was younger, fresh of of school, and happy to work for lower pay. Granted volunteers here work for "no pay" but to make up for it they get unlimited abuse from agenda warriors. Edison (talk) 19:02, 16 March 2011 (UTC)

I see adminship as more akin to a driving licence. You can lose it if you break the rules, but otherwise you go on till you are old enough to start needing medicals (I gather that the US and some other countries charge annual renewal fees, but does any country make everyone resit their test?). Term limits are needed for politicians, trustees and in our case Arbcom members, basically anyone whose role is to make policy as opposed to implementing it. Term limits are inappropriate as long as admins are wielding the mop in accordance with policies that the whole community makes. If policy making or banning decisions became an admin only matter then there would be a case for term limits. Refresher courses or training modules for different parts of the mop are a different matter, they probably would be a useful innovation. ϢereSpielChequers 19:04, 16 March 2011 (UTC)

• Oppose (are we voting?) - I'm an admin with lots of outside interests. Health breaks are natural and needed, but an enforced 3-year break is unworkable, as per Hut 8.5 above, and will probably cause some of the best sysops to walk away. - Now, of course, if we could be sure that the vandals were taking a 3-year break too, then it might be worth a second thought... Ian Cairns (talk) 18:20, 16 March 2011 (UTC)
  • Comment Perhaps a "matching service," so that one agenda warrior or vandal takes a 3 year break along with an admin? Nah, the admins are outnumbered 100 to one, and the other side has a drawer full of socks Edison (talk) 19:04, 16 March 2011 (UTC)
• Oppose There is already an admin shortage, the last thing we need is an automatic, mindless process which further lowers the admin count by forcibly desysopping experienced admins who are perfectly willing and able to perform admin duties. —SW— ^squeal 18:32, 16 March 2011 (UTC)
• Comment. I'm not an admin, and I was heavily involved with Wikipedia:Community de-adminship/RfC, which (speaking of perennial proposals) please see, if you haven't before. I dislike the idea of a three year gap before reapplying, for the reasons given by others. I also dislike the idea of only applying it to new administrators, since (a few of the) older administrators are usually the ones for which this issue arises. I like the idea of making RfA more reversible than it currently is. I like that a lot. In fact, I think it's inevitable. But as noted above, making the many conscientious administrators jump through this hoop is an inefficient (at best) way to accomplish that, just to weed out a tiny subpopulation, and it has no chance of getting consensus anyway. I think we will need to find a way to more efficiently place administrators who lose the community's trust in front of ArbCom, without putting all administrators there. --Tryptofish (talk) 19:15, 16 March 2011 (UTC)
• Support One of the reasons RfA is such an ordeal is that adminship is a life appointment, so people are looking for the tiniest indication of unsuitability in candidates. I'll bet an adult beverage of your choice that a lot more candidates would be approved if we knew bad admins would naturally age out of the system. At present almost the only way to get rid of admins is if they firebomb the server farm and GOATSE the main page. Short Brigade Harvester Boris (talk) 20:17, 16 March 2011 (UTC)
• comment: Currently, surplus of administrators, or even surplus of "burned out" administrators (I am not sure how that category is defined), is not among wikipedias problems. Are admin cliques a problem? If they are I don't see this proposal helping that - three years is plenty of time to join or form a clique. As for complicated rules - admins don't make the rules, the community does. I don't see what process would lead to rules becoming simplified if this proposal was enacted. To me it looks like a bad solution looking for a problem. The real problem people are worried about is how to make admins more responsible and easier to remove - this is of course best adressed by enacting rules that serve that purpose, for example an easier process of desysopping (e.g. through rfC/U) - although even that might mean that less people would want to become admins.·Maunus·ƛ· 20:26, 16 March 2011 (UTC)
• Strong oppose per WP:BROKE. This proposal would turn our current admin shortage into a devastating drought, which the community will no doubt fail to compensate for by loosening RfA standards. Swarm ^X 20:31, 16 March 2011 (UTC)
• Oppose If someone is a good admin, why should they lose the ability to help others and have to wait another three years (remember, Wikipedia's only 10 years old, so that is a long time) to be able to assist again? Also, if you get rid of the required waiting period between RfAs, what is the point of a three-year term? One or two years might make slightly more sense, but three is seems weird. /ƒETCHCOMMS/ 22:51, 16 March 2011 (UTC)
• The 3-year forced non-adminship part of this proposal is ridiculous and counterproductive; it would significantly deplete the admin corps, which is absolutely what we don't need as the size of the project continues to increase. Periodic admin reconfirmation makes sense though. --Cybercobra (talk) 22:58, 16 March 2011 (UTC)
• As noted, this is a perrenial proposal, and as always, the question remains whether the consequences of such a plan outweigh the supposed benefits. The last proposal was built far more solidly than this, and it failed pretty easily. I don't expect this will work either. Truth is, if there was an expiry date on my adminship, I simply wouldn't waste the time looking for a reconfirmation. The tools, when I use them, are useful for page maintenence and quick blocking of vandals. If I gave up the bit, that is work that would fall to a smaller cadre of admins, who would likely face burn out at a much faster rate. So of the five arguments presented, I'd say 1 and 4 are patently false, and this proposal would actually make both problems worse. 5 I think is unproveable, 3 depends on the editor. I think most of the people constantly clamoring for term limits find the position far more glamourous than I do. 2 would happen, of course, but the question is whether that is actually a problem in need of repair. And if it is a problem, all it takes is one admin to make an action. non-admins can just as easily comment and help build consensus, even on AN/ANI, so nothing is solved this way. Resolute 23:11, 16 March 2011 (UTC)
• I agree with Resolute. Given the choice between going through RFA again or just not doing the few admin tasks that I do anymore, I'd choose the latter. Personally, I think this would make the "special status" issue much worse. If it's not a special status, why does it need additional rules about keeping it and why should people have to repeatedly go through a long, stressful process just to maintain the status quo? The real way to fix that issue is to make it easier to remove bad admins and lower the standards at RFA. Being an admin is not significantly more difficult or more dangerous than it was when I got the bit in 2007 (we can't even crash the site by deleting the sandbox anymore) but standards have continuously increased. Mr.Z-man 04:52, 17 March 2011 (UTC)
• Oppose. As noted above, the effect would be to make the good 95% of admins jump through hoops over the actions of the 5% (or less, IMHO)—and those are admins who should be addressed more frequently than at the end of their term.
  For disclosure's sake, yes, I'm an admin. No, I'm not listed as open to recall. However, I've taken a break or two in the past from admin tasks, and it's been in part because of concerns raised by fellow admins or veteran users about how I was using the tools. I stepped back, cleared my head, re-read the rules, and when I was ready eased back into the task.
  I'm a referee off-wiki, and there are procedures in place there to deal with errors made in games. It never happened to me, but I know crews who've had to go in and review game tapes sent in by coaches to the association and had to explain why a call was(n't) made, and I know crews who've gotten suspended over there errors. If we need to restructure the procedures with admins, that's the route to go: sit down the admins who are making the bad calls, but don't take the mop away from those using it well. —C.Fred (talk) 05:12, 17 March 2011 (UTC)
• Oppose. I'd oppose mandatory removal of the bit. Why should a good admin lose the bit just due to a time period running out? Even if I didn't have a problem with that, why on EARTH shouldn't they be allowed to re-apply immediately?! I've suggested a reconfirmation process below, which I'm expecting to get blown out of the water due to the perennial status of it. If burnout is an issue, perhaps there should be a system where X admins/editors can get to suggest a 1-month break for an admin, which then is enforced by the removal the bit for that period? I can think of a situation where that would have been useful in very recent history... Worm^TT · (talk) 09:09, 17 March 2011 (UTC)
• 250% opposed I can't see this working. RFA (you know what I mean) is a big page with just 3 requests, so if former admins and admin hopefuls are mixed together on the page, then I can see people with slow Internet/computers waiting to the end of time for the page to load. And if the page swells with this idea if it goes ahead, it may not load at all. There is no way to make RFA smaller, just get a faster Internet/computer. I also add Metropolitan90's and a litany of other users thoughts. Just chuck this idea in the bin. It must never be remembered, only mourned as this idea fails as consensus dwindles. --^{The Master} _{of Mayhem} 09:59, 17 March 2011 (UTC)
• Oppose. We have a declining number of admins - sending good experienced ones away for a forced break is one of the worst ideas I've heard in a long time. There might be some merit in some sort of review/reconfirmation in case they're doing a poor job, but most are doing just fine and forcing every one to go for a new RfA is not a good idea - we're trying to attract more admins here, not chase them away. And re: "In that case, the newest admins should sign up for the policy. It will increase their influence, and improve their ability to implement new ideas" - I'm a new admin, but I didn't do it for influence. And admin has got nothing to do with news ideas - anyone in the community can come up with new ideas any time they want. -- Boing! said Zebedee (talk) 10:09, 17 March 2011 (UTC)
• Strong oppose : We already have trouble with backlogs, and admins are needed pretty much everywhere. I'm not an admin myself (and don't want to be one in the near future), but I think that we should keep out admins. ManishEarth^{Talk • Stalk} 11:06, 17 March 2011 (UTC)
• I oppose this specific proposal with the mandatory three-year break, but support the general idea of admins needing to go through periodic re-election. Standards for admins now are so much more restrictive that those who passed the 2004-5 process can't be said to have gone through anything that we would now understand as an RFA.—S Marshall T/C 12:12, 17 March 2011 (UTC)
• Oppose As a non-admin, I have concerns about re-confirmations. Long-term admins are at least as much an advantage to the project (through consistency, institutional memory, and ability) as they can be a detriment. The problems come in our most difficult areas of adjudication. What admin is going to make difficult decisions in the face of aggravating their "constituency" to the point that they stand a very real chance of being denied another term? While I do believe that the loss of adminship is one of the least substantial actions the community can impose (considering interaction bans, blocks, site bans, etc. to be far worse restrictions) for actions that are non-constructive to the project, I have not yet seen a practical manner of implementing a reconfirmation process. Administrators in this project do not sit as a group and set policy, nor do they have much in the way of an authoritative role in process. They are not elected representatives in the democratic sense. As an example, a regular editor providing a third opinion tends to carry as much weight as an admin doing the same. Policies, guidelines, and consensus itself are created by editors who far outnumber admins. As such, I do not see that "re-election" really serves a substantial purpose. A community-based de-adminship process that does not require going to ArbCom would be far more effective in removing those few admins who have shown themselves to be problems in the general consensus of the community at large. The elimination of WP:NBD and the recognition that ALL actions by an admin, and not just those involving the use of admin tools, are "admin actions" would contribute greatly to the needs of the community in demonstrating a loss of support in a particular administrator. Reconfirmation would be a bureaucratic nightmare, and the limited number of members of the community who would bother to participate would probably make such an action a farce in terms of determining actual consensus for retaining admin rights. Jim Miller ^{See me | Touch me} 19:29, 17 March 2011 (UTC)

So if three years is crazy what would be a good number

I get the feeling there is some support to give admins a bit of a break, and clearly three years is too long. What about a much shorter period of perhaps three months? It is not overly long and would give admins a chance to reevaluate things from the outside once again. And what if this was a voluntary program to sign up for? Consider it a like a periodical sabbatical. --NickPenguin_(contribs) 04:34, 17 March 2011 (UTC)

I get much the opposite view. A few relatively new non-admins and one noted anti-establisment figure support this, the vast majority, now and historically, do not. There are things I support, such as making it easier to desysop admins who frequently break policy, (however the process would have to have safeguards against personal grudges and vendettas taking the form of desysops,) however I think that the idea of fixed time limits is an absurdly bad idea. If you want adminship and the RfA atmosphere to improve, you need to make adminship easier to gain, but also easier to lose. That will make it less of a zero-sum game. However the vast majority of admins do good work on a consistent basis, and imposing time limits on that work will hurt the project. Sven Manguard Wha? 04:54, 17 March 2011 (UTC)

Sven - easier to gain and easier to lose really is the best rubric, but unfortunately that's extremely unlikely. Rule #1 of power is that no one ever gives it up willingly once they have it (except for the few saints among us, and burnout cases), and unfortunately the project has been naive about the RfA and desysopping procedures, so that now becoming an admin is torturous and removing an admin is all but impossible.

If you wanted something interesting that might stand a ghost of a chance of success, suggest an admin lottery: one person a week (chosen at random from the group of editors who meet some minimum standards) is granted adminship no questions asked. they can refuse, in which case someone else is chosen, but otherwise they're in. That would add 52 new admins a year - enough constant fresh blood to shake up the establishment, but not so much that the newbies overwhelm the old guard. Very Roman republic, that... --Ludwigs2 06:07, 17 March 2011 (UTC)

Certainly a new idea, but I think it would end poorly. What happens when we give an admin that has issues with behaving civilly to others the mop? How do we decide if he should be excluded? Perhaps a better option is that we turn the system upside down: That every editor that hasn't been blocked in 18 months (ignoring blocks that were overturned as a bad block) becomes an admin unless the community decides that they don't deserve it. A reverse RfA if you will. That has it's risks too, but I think that it would be better than something random. Sven Manguard Wha? 06:21, 17 March 2011 (UTC)

18 months is too tiny for anyone to even consider this proposal, three-four years is better, though still I feel it isn't a good idea. Admins have quite a lot of power (and they carry around some respect, too... most people listen to admins). That's why we thoroughly vet them with RfAs. ManishEarth^{Talk • Stalk} 11:07, 17 March 2011 (UTC)

Eh, I think the 'who hasn't had a block' condition is just a wide invitation to gamesmanship. For instance, my block record sucks, but all except for one of my blocks were entirely undeserved (the result of science editors trying to game me because they think I'm a fringe editor - dorks!). But how am I supposed to argue that in any meaningful way?

The 'random admin' thing has two advantages:

1. it would insert people as admins who might be too shy or scared to run the AfD gauntlet but would otherwise make excellent admins.
2. it would give an incentive to improve the desysopping procedures (so long as adminship is seen as a powerful privilege admins will always fight against regularizing desysopping, but start throwing in wild cards and we'll start getting a few bad apples, and then we'll have to create a consistent process for desysopping just to get rid of them).

sometimes the only cure for systematic problems is to stir the pot - add random elements and force the system to adapt. --Ludwigs2 16:25, 17 March 2011 (UTC)

Don't we already have a voluntary process, Wikipedia:Administrators open to recall, which handles this more efficiently than a term limit does? —C.Fred (talk) 04:47, 17 March 2011 (UTC)

Admins that misuse their powers certainly wouldn't sign up to that voluntary process, wouldn't they? --Conti|✉ 08:04, 17 March 2011 (UTC)

It's not gonna happen, ever. I've read all this stuff many times before in different variations. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 04:58, 17 March 2011 (UTC)

• Oppose. I am an admin and have been one for over three years, and I agree with Jayron32's comments above. If an admin is doing a good job, there is no reason to take adminship away from them, particularly given that there is no maximum limit on the number of admins. --Metropolitan90 (talk) 07:42, 17 March 2011 (UTC)
• Completely opposed to this for a litany of reasons that have already been covered. Strikerforce (talk) 07:50, 17 March 2011 (UTC)
• 3 months of non-adminship sounds like a good idea to me. There'll still be enough admins to do what needs to be done, after all. The sad thing is that, thanks to Wikipedia's consensus system, even if just a third of our admins are power hungry and oppose any and all means to take away their toys, these proposals will never get anywhere. --Conti|✉ 08:04, 17 March 2011 (UTC)

• If we have so many admins to do what needs to be done, why can't I get people to help out in a sustained way with copyright cleanup even when I advertise? :( (1; 2, for example.) One or two people pitch in for a while, but then they fall away as real life interferes or the tedium of the job overwhelms them. Of the four "copyright admins" (that is, people dedicated to the work on a sustained basis) that I can think of promoted in the past three years, three of them have vastly declined their participation levels ([15]; [16]; [17]). People don't seem to be lining up to replace them. --Moonriddengirl ^(talk) 12:05, 17 March 2011 (UTC)

• A short break that admins can voluntarily sign up to? We already have that - they can just take a Wikibreak like everyone else. -- Boing! said Zebedee (talk) 10:09, 17 March 2011 (UTC)
• Non-admin comment. This proposal seems to once again highlight the perceived problems caused by rogue admins. I do not dispute that there are bad admins, but these are usually ones that have not signed up for recall, and usually use all means (such as bullying, lawyering) to hang on to their tools. So we must treat the underlying cause, and re-evaluate the mechanism for de-sysopping. I do not believe systematic retirement after three years is the answer, nor is the three-year fallow desirable for the smooth operation for our project because it will potentially cut our admin staff by half, with the most dramatic effect being in the first year of operation. This is the wrong medicine for the patient, and risks doing harm. An alternative could be to make the recall mandatory rather than voluntary. --Ohconfucius ^¡digame! 01:59, 18 March 2011 (UTC)

Annual/Biennial Re-confirmation

I was thinking about this on my way home from work yesterday, completely unrelated to this thread which I only saw this morning. I think one of the major reasons that RfA is "broken" is that there is a common belief that it is too hard to get administrators out. I was trying to work out if there was a way to re-confirm the administrators. What I propose is a process where "Once every *time period*, administrators would submit themselves for community review, where the community could offer feedback and most importantly !vote on whether they should retain the mop. The voters should be *editors in good standing*, and if the !vote is below *arbitrary limit*, then the administrator would lose the bit".

Now, I think the idea is good in principle, but the three items in question should be discussed. I was thinking a *time period* of 1 or 2 years (if we did 1 year, we'd have around 6 a day... that's possibly to much), *editors in good standing* should be editors with say over 100 edits (to prevent people registerring in order to get someone out), and the *arbitrary limit* I was thinking at around 50%. Definitely not as high as RfA, but if less than 50% of the community think you are doing a good job, I don't accept that "Someone has to make the tough decisions" is a good excuse. I wouldn't be averse to putting in a leeway of say, 20% for crat judgement either. Above 60% mostly retain the bit, below 40% mostly lose the bit. For the record, I am not an admin, but if I were I would be looking at something like this for my recall procedure. Worm^TT · (talk) 09:02, 17 March 2011 (UTC)

Periodic review (of active admins) may be helpful, in the sense of an Editor Review. Re-confirmation is too much work for too little benefit and too much risk of detriment to admins taking tough decisions. Admins are not elected representatives (in theory everyone could be an admin...), and they don't need to be re-elected; sufficient opportunity for desysopping when appropriate is quite enough. And to come back to the Review element: if there is no immediate risk of desysopping attached, it'll be reasonably open, honest and productive. If there is such a risk, it becomes a trial, with the admin being charged with Being A Bad Admin (chief witnesses: anyone they've ever acted against, fairly or not). Really, I think we should institute such a Review, because the demonstrated usefulness of that would reduce the frequency with which this perennial bad idea of Reconfirmation comes up. Rd232 ^talk 15:29, 17 March 2011 (UTC)

The last thing I'd want is a trial, and I was trying to avoid that by setting the bar to a point where it is more a review. But I also think this "job for life" thing is causing RfA to be regarded as a "gauntlet". Admins do drift off, burnout, exhaustion, whatever - leaving a much smaller admin corps. If there was a review process which could involve a de-sysop, I think that people would be less harsh at RfA. I could be wrong of course Worm^TT · (talk) 16:39, 17 March 2011 (UTC)

Setting the bar low wouldn't work, it would still be the same dynamics if immediate desysopping was on the table. Remember, a really bad review would be a wakeup call to the admin, and otherwise lay a basis for future desysopping if problematic behaviour continued. Besides, overall RFC/Us are more effective in this area than people credit, particularly as a wakeup call, which is part of what makes me think we should look at Reviews first. And apart from anything else, Reconfirmation is a perennial proposal which isn't going to get anywhere, so best not to waste energy on that anyway. Rd232 ^talk 18:18, 17 March 2011 (UTC)

I have in the past proposed incorporating Editor Review as a preliminary stage in RFA, so that candidates have a better idea of likely reception and what they can do to improve (if necessary) before getting to the more hardcore voting stage. Rd232 ^talk 18:09, 17 March 2011 (UTC)

How about this. We get a strong consensus from users here that we want an attitude change regarding desysoping. I would be behind a proposal that does not involve term limits or reconfirmation but would say "All admins, irregardless of their stated position on recall, are eligible for a desysoping procedure when a consensus of uninvolved users determines that they have made an egregious error or show a pattern of consistent error in admin related tasks." The proposal would have to put that bar in a high enough place that this doesn't become a tool for vendettas or content wars, but low enough that if an admin does screw up, there's a viable last resort system for correcting the issue that's more accessible and less extreme that ArbCom. Even if it never get's used, the mere presence of such a system would, I think, make RfA a bit less nasty and admins a bit more honest. Sven Manguard Wha? 17:12, 17 March 2011 (UTC)

I approve of that idea. Worm^TT · (talk) 17:52, 17 March 2011 (UTC)

The problem is that admins are expected to learn from their mistakes, with review via ANI and sometimes RFC/U. Anything more contentious needs the formality and neutrality of something like ArbCom - and we already have one of those. About the only thing I can see being useful is making it easier to refer admins to ArbCom for review, with possible outcomes including a reconfirmation RFA or even outright desysopping (also rejection of the request for review, and of course any censoring, sanctioning or advisory motions that might emerge from the review). Whatever the outcome, it would be properly justified after careful consideration by neutral parties. Rd232 ^talk 18:09, 17 March 2011 (UTC)

"Learn from their mistakes"'? I don't think that the way it is. In order to become an admin, one has to be perfect, after that, one can safely ignore any criticism short of murder in the real world. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 20:27, 17 March 2011 (UTC)

One can also claim to have "the trust of the community" while admitting that you would never get through another RfA because you've had to take "some hard decisions". Dishonest doesn't even get close. Malleus Fatuorum 20:32, 17 March 2011 (UTC)

My point exactly. I disagreed with a block that an admin made and left them a message on their talk page. 3 days later, the admin was still plodding along, the message was ignored (though is still there), the block had expired. I'm not one to take it to WP:ANI (one incident, and I disagreed with the length, not the block itself) so basically that is going to be totally ignored for all time. I've got the admin's talk page watchlisted, there has been no further incidents, so as far as I'm concerned he/she appears to be a good admin in general - but that doesn't mean that a feedback process wouldn't help them. Worm^TT · (talk) 20:36, 17 March 2011 (UTC)

• Oppose - I am open to six year terms or such, but we already have horrendous backlogs in many urgent areas of admin work - from WP:AfD to CAT:CSD - and this proposal will make it much worse. I have written many times that I am open to recall. Bearian (talk) 16:26, 17 March 2011 (UTC)

• It's obviously a good idea, just as the enforced break of three years suggested above is equally obviously too long. But even more obviously, none of these proposals have a snowball's chance in Hell of getting past the self-interested entrenched positions so evident here. Malleus Fatuorum 18:52, 17 March 2011 (UTC)

  "It's obviously a good idea" - it is? ErikHaugen (talk | contribs) 20:17, 17 March 2011 (UTC)

  I don't think it's obviously a bad one, as I wouldn't have suggested it. Malleus is right though, the people who actually discuss these ideas most fervently are generally the same people who have an interest in them not happening. Worm^TT · (talk) 20:25, 17 March 2011 (UTC)

• Oppose: I'd have to oppose this too, not so much that it's a bad idea (I think it has merit), but that it's addressing the wrong problem. The problem, I think, is that admins are insufficiently answerable to the content creators they serve. I think what we need is an easier, community-based, admin recall process - and ideas like this, while possibly good, detract distract us from that -- Boing! said Zebedee (talk) 19:09, 17 March 2011 (UTC)
• Oppose What we need is a way to remove the tools from admins that don't use them correctly, not a means of pestering admins that do their job correctly just to make them jump through some hoops. As I said above, the problem isn't the vast majority of admins who don't create problems. Its the small handful that do. I support efforts to remove the tools from admins that don't use them right. But I think that forcing all admins, including the hundreds that do nothing wrong ever, just to catch the 10 or 12 that may need to give up the tools, is wrong-headed. --Jayron32 19:50, 17 March 2011 (UTC)
  • Ten or twelve? I could name you at least 30 or 40, which is a substantial proportion of the active administrators as oppsed to the headline number. Malleus Fatuorum 19:56, 17 March 2011 (UTC)
    • Oh, we all understand your position, Malleus. We know that you believe that 100% of all admins are instantly corrupt and worthless the moment they accept a nomination for an RFA (and quite interestingly without any actual evidence on an individual level, person for person). It makes it quite easy to ignore your statements on these matters because they are so obviously without merit. Which is a shame really, because I think that in some cases you often have valid points. However, your presense in arguements which would otherwise help fix the situation with real problematic admins instantly ruins them, if only because of your position in opposition to a specific administrator in indistinguishable against your unfounded, baseless and nonspecific prejudice against the administrator corps in general. Again, what it really hurts is that, once you show up with the same tired arguements, it ruins any chance to remove actual problems because it poisons the well; people who would otherwise be able to rationally consider removing an administrator who needs to be removed will just stay away lest they be associated with you. Thanks a bunch. Keep it up, and we'll never ever get any real reform towards having a respectable administrator corps. After I finish typing this, I'm going to mail myself an email with your highly predictable response, before you even write it to me, so as to prove how predictable and tired your behavior in these matters is. --Jayron32 21:07, 17 March 2011 (UTC)
      • You very evidently don't understand, so I fail to see why you might want to pretend that you do. Malleus Fatuorum 21:20, 17 March 2011 (UTC)
      • Whether Malleus is right or wrong on the numbers, there should be a way for individuals to express such concerns and have them looked at by the community. (And I've never seen Malleus suggesting anything like the suggestion that "100% of all admins are instantly corrupt and worthless the moment they accept a nomination for an RFA", so you really should not malign him like that) -- Boing! said Zebedee (talk) 21:22, 17 March 2011 (UTC)
        • Indeed I've never said anything like that, no matter how many times Jayron32 tries to convince himself and others that I have. What I have said repeatedly is that the system is corrupt, a view that I find it difficult to believe that any rational person would disagree with. Malleus Fatuorum 21:26, 17 March 2011 (UTC)

• Oppose Let's focus on a recall process instead. If there's a problematic sysop why do we have to wait up to a year or whatever to deal with it? Why go through all the trouble of a "reconfirmation" RfA if nobody has any concerns about the admin? ErikHaugen (talk | contribs) 20:17, 17 March 2011 (UTC)

  I understand the general thinking and why the proposal has no chance of getting through - but my answer would be feedback and confirmation that you're doing a good job. The bar to desysop was intentionally set so low that there had to be a significant problem with the admin, but the feedback would be helpful. Worm^TT · (talk) 20:22, 17 March 2011 (UTC)

• I've got the same answer for just about everything that comes up at WT:RFA: I have no objection if people want to experiment. If someone wants me or any other admin to run for reconfirmation so we can see what that looks like, then fine. My guess, based on the recalls we've had so far, is that most people will be disappointed with the results, for a variety of reasons. But if a significant number of Wikipedians think it's worth trying, then let's have a look and see what happens. - Dank (push to talk) 20:46, 17 March 2011 (UTC)

• Oppose as per WereSpielChequers, Erik Haugen, and Sven. Most admins I know and who are active divide their time between admin tasks and content building/page repairing/policy making. Submitting their work to review after a fixed period would only invite opposes from people who have had their pages deleted or who have been blocked. Adding a time limit to tenure would also add to the reasons why so few good editors are coming forward to run for office. After my own recent RfA I would not expect to go through it again, and If I had thought for a moment that I would have to do it again or take a forced break, I wouldn't have bothered wanting the mop. 'Time' feels different for different people; I've been on Wikipedia for five years already, two very active, which demonstrates that I was in no hurry to get the bit. Now I've just got it, three years is is one heck of short time for people of my age. Let's not forget also that many of our admins are very capable young people who are still at school or college, and Real Life can get in the way for a few years. They may want to return to sysoping when the pressures of school or college life are over. I'm an admin open to recall, and I think we should be looking more into that direction than introducing proposals for probationary periods or reducing admin tenure. It can often take three years as an admin to gain the experience and the trust to become a bureaucrat. Kudpung (talk) 09:00, 18 March 2011 (UTC)

Time-based solutions don't work

If I'm hearing it right, the perceived problem is that "adminship is for life", and that it's too hard to get rid of those that are perceived as "bad admins". The proposals above focus on either forcibly desysopping admins after a certain period of time, or forcibly putting them through another mini-RfA every year, or something along those lines. None of these time-based solutions work. If an admin is doing a good job, and is willing to continue doing a good job for 20 years, then desysopping them for no other reason than "a certain amount of time has passed" is shooting us in the foot and throwing a good admin into the trash. Forcing a good admin to go through a mini-RfA every year is also an unnecessary burden on the admin and on the community. Getting through RfA once is stressful enough, having to go through that process again every year would be borderline unbearable. The problem is with "bad admins", not with "good admins", so any proposed solution should only affect the bad admins and leave the good admins alone. If the problem is that it's too hard to get rid of bad admins, then the proposal should focus on creating a mechanism for desysopping an admin when there is an overwhelming community consensus to do so. Or, the proposal should focus on making WP:AOR more enforceable. Any solution that involves mandatory events for all admins at specified time intervals is too cumbersome, bureaucratic, and places an unnecessary burden on admins who are busy enough doing a great job (i.e. the vast majority of them). I'd suggest this thread gets closed and you go back to the drawing board. —SW— ^gossip 20:47, 17 March 2011 (UTC)

I concur, but I'm wondering if something more simple might work. For example, we could say that that a new minted admin has a term of 3-4 years, and after that time, they stand at RFA again or the bit's removed, but only once (this to weed out admins who are gung ho, but lose steam, or who deviate from the path of truth and beauty sooner rather than later). And we work on a better recall system for the bad admins that have passed that bar. --Nuujinn (talk) 21:29, 17 March 2011 (UTC)

That's to ignore the possibility that a corrupt system (adminship for life) leads to corrupt and unaccountable behaviour, which in my view is where we find ourselves today. Malleus Fatuorum 21:32, 17 March 2011 (UTC)

It doesn't ignore that possibility, it just recognizes that a minority of admins will become corrupt as a result of the "adminship for life" system, and therefore the solution should only affect the minority that have become corrupt, not the ones who haven't done anything wrong. It's the whole hatchet vs. scalpel thing. —SW— ^speak 21:47, 17 March 2011 (UTC)

So your excuse for a corrupt system is that it hasn't yet corrupted everyone? Well-designed systems have checks and balances, not a "let's wait until someone goes crazy" mentality. Malleus Fatuorum 22:55, 17 March 2011 (UTC)

That's not even what it is; I'm all for "let's wait until someone screws up" — the current situation, however, is rather "let's find excuses for anyone who does screw up and sing kumbaya." Again, admins can practically do whatever they want, everyone knows it, and that's the problem. Once you're an admin, it is basically a courtesy of yours to give a damn. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 23:49, 17 March 2011 (UTC)

To trow any crazy idea in the fray, one of the main concerns about RFA is that it is currently very, very hard to pass which causes a massive reduction in the number of successful candidates (and I assume candidates in general). How about we do something like:

• 75-80+% support => full adminship
• 55-65+% support => temp adminship for 3 months
• less => fail.

A temp admin could do RFA again in three months and either get full adminship, get a second temp run or get demoted. The focus in the second RFA should be on his/her actions in those 3 months. I am pretty sure something like this has been suggested before, but I dunno what would be problems with it. Yoenit (talk) 23:09, 17 March 2011 (UTC)

It has been proposed, yeah. The problem I see with this is that those three months aren't very useful to judge a potential admin. The temp admin will know that he'll be scrutinized very closely, after all, so he'll be on his very best behaviour. Only once he gets full adminship he'd be himself, for better or worse. So you can just as well give him full adminship from the start. --Conti|✉ 23:15, 17 March 2011 (UTC)

"There is a problem, but this is not the ideal solution, so let's do nothing." That's the impression I get from a lot of the comments above. It's true, this isn't an ideal solution, but I sure as hell don't see a better one being proposed. As for the proposal, we could do it the other way around. Adminship will be automatically granted every year unless a significant number of users protest. That way, all the admins that do their work won't have to do anything at all to keep their adminship. --Conti|✉ 23:13, 17 March 2011 (UTC)

Not a particularly bad idea, but it has no more chance of success than any other idea that's been floated only to be shot down the entrenched admin corps. The only solution to this impasse is to unbundle the admin tools and to make it easier to add or remove those tools. This fiction that we have a trusted cadre of users just because they managed (once) to get through a popularity contest is simply that, a fiction. Malleus Fatuorum 23:16, 17 March 2011 (UTC)

I think this last notion is also an interesting option. I wonder if we could configure a set of "admin lite" tools, for lack of a better word, each with a particular orientation (vandal control, for example). But I have no conception of how difficult that would be in practice. --Nuujinn (talk) 00:53, 18 March 2011 (UTC)

I do: impossible in the current "admins have been through an RfA and are therefore trusted forever with everything, even those things that didn't exist when they were elected" environment. Malleus Fatuorum 01:04, 18 March 2011 (UTC)

Ha! I wasn't thinking of the political layer of the OSI model, but rather the technical aspects of breaking out what is often described as a bit into multiple bits. --Nuujinn (talk) 01:58, 18 March 2011 (UTC)

I'm sure it would be trivial. Just as I'm sure that it'll never happen while the admins rule the roost. Malleus Fatuorum 04:09, 18 March 2011 (UTC)

Unbundling is something I would support, and have done several times at WT:RfA, but it always gets shot down -- Boing! said Zebedee (talk) 09:08, 18 March 2011 (UTC)

In the name of Jimbo!

I just read through the entire text above. Consensus sits (fairly) squarely against it, for various reasons, not the least being that there is already a shortage of administrators. Now discussion is drifting back towards unbundling, and temporary adminship, which really doesn't seem to be directly related to the three years proposal. While I am against it for many of the reasons above, I think that this discussion either needs to truly redirect itself at some targeted proposals, or refocus on what was presented and what can be changed in the original proposal to make it viable. NativeForeigner ^Talk/_Contribs 03:58, 18 March 2011 (UTC)

What evidence do you have that there's a shortage of administrators? My experience has been that there's a damn sight too many. Malleus Fatuorum 04:11, 18 March 2011 (UTC)

None. Just parroting the feelings voiced above. NativeForeigner ^Talk/_Contribs 04:27, 18 March 2011 (UTC)

I seem to remember reading about the shortage in the Signpost. I think it was covering a potential or impending shortage, but I don't recall clearly. Swarm ^X 07:01, 18 March 2011 (UTC)

If we are to assume that a growing number of users and articles needs a growing number of active admins, then we definitely have an admin shortage. --Conti|✉ 07:35, 18 March 2011 (UTC)

Other Wikis

I understand from this discussion thread now ongoing as part of the March 2011 update on Strategic Planning at WikiMedia that the Swedish wikipedia currently has one year terms for admins, reportedly with successful results. Could we learn from what might work elsewhere and apply lessons learned here? Perhaps Lars Aronsson, who made the observation there would weigh in here? (I'll ask him) Geoff ^{Who, me?} 22:16, 17 March 2011 (UTC)

• Comment. I'm not an administrator anywhere and have no opinion in this matter. The Swedish Wikipedia in January-February 2006 introduced a one-year time limit on adminship. As far as I know, it has worked just fine for five full years now. The policy is now mentioned in sv:Wikipedia:Administratörer#Förordnandetid but was originally a page of its own where you can still trace the history and discussion (which, of course, are entirely in Swedish). --LA2 (talk) 22:56, 17 March 2011 (UTC)

Keep in mind that the Swedish Wikipedia also has half of the ratio of admins to articles that we do. They have 97 admins for 390,408 articles, a ratio of 1 admin for every 4025 articles. We have 1 admin for every 2014 articles. If we had the same ratio as them, we'd have about 891 admins instead of the 1,781 we have today. —SW— ^confer 23:59, 17 March 2011 (UTC)

The ratio of admins to articles is irrelevant, and simply demonstrates what an over-inflated view administrators have of their own importance. The overwhelming majority of vandalism is dealt with by the (untrusted) troops on the ground. Malleus Fatuorum 00:04, 18 March 2011 (UTC)

Um, that's because reverting vandals doesn't require admin tools. What's your point? —SW— ^confess 04:07, 18 March 2011 (UTC)

• Bad math. If en.wp had an annual renewal, it would lose some of those 1781 admins, who aren't active and wouldn't bother to be reelected, so the ratios would become more similar. The lower Swedish ratio is in part the result of having annual renominations for five years. --LA2 (talk) 00:23, 18 March 2011 (UTC)

• Quite possibly a significant number are dead, which puts the lie to the "admin for life" idea; it's actually "admin for all eternity". Malleus Fatuorum 00:32, 18 March 2011 (UTC)

• Ha, good point ... I feel enshrined. - Dank (push to talk) 03:49, 18 March 2011 (UTC)

"admin for all eternity" - that's actually what it says on the pyramid I built. You wondered what it was for? It is in fact a giant barnstar I gave myself, for being patient enough to wait thousands of years for Wikipedia to be invented. Well hey, when you've got eternity, you need to be patient. Rd232 ^talk 13:41, 18 March 2011 (UTC)

Proposer comment ("This is not a admin reconfirmation proposal")

• This is not a admin reconfirmation proposal. The crucial part is that admins are forced to take a break from being an admin for a period of time. I am happy to compromise on the timeframes, so that "Adminship be granted for a period of X years. An editor must also wait Y years between adminships". The value for X could be as high as 10, the value for Y could be as low as 1. I think the periods should be measured in years, not months, however.
• Just to cement my claim that this is not a reconfirmation proposal, I'm happy for admins to be automatically reinstated after Y years (though I'd prefer them to go through RfA again).
• While a lot of people are understandably focused on "rogue admins", this proposal is really about governance and renewal. This proposal suggests de-sysoping admins for a period of time even if they are doing a good job, for various reasons.
• Despite their self-image of some, admins are not simply normal editors with extra widgets. Because of the WP:RFA process, admins wield political power, and normal editors will usually call in an admin to personally mediate disputes in the first instance.
• Some admins have claimed that there are not enough admins. Patently untrue. The WP:RFA process is currently rejecting applicants at a rate of 50% or more. If WP were really desperate for admins, it would not have the luxury of rejecting so many applications, nor the time to be so exhaustive in vetting candidates.
• Given the tens of millions of people on the internet, the millions of wikipedia users, and the hundreds of thousands of active WP editors, it is not reasonable to assert that there are only 1800 or so suitable to be admins. The only reason that there are not enough admins is because the current system keeps people out of joining their ranks. This is not surprising, and not even a necessarily bad thing. As more people join the admin cohort, it is natural for the cohort to keep raising the barrier to entry (the counterintuitive aspect of this is that new admins are more likely much better admins than older ones!).
• The issue of governance is that the group of wikipedia leaders, who wield political power, should not be granted that political power indefinitely. Not because of "fairness" or "democracy", but out of the simple fact that if the group of admins is largely static, the website will inevitable end up tailored to the desires of that group, rather than appealing to the community at large.
• The issue of renewal is that with a largely static adminship, the website will be much less able to adapt and cope with changing circumstances in the future.
• We have an encyclopedia here where articles are changing every second, yet we grant adminship for eternity. It makes no sense whatever.

--Surturz (talk) 08:03, 18 March 2011 (UTC)

Apologies, the reconfirmation thing was my fault, an idea I put forward later on which I considered similar to your idea and worth mentioning. Worm^TT · (talk) 08:18, 18 March 2011 (UTC)

The root of your idea seems to be that admins get "political power" from being admins. But they don't (they're not elected representatives), they get "political power" (such as it is) from (a) being the sort of highly experienced and non-divisive[ish] editors able to get through RFA and (b) having (via RFA) the demonstrated trust of the community to wield powerful tools. As a result, taking an enforced break from adminship will have no effect, since the trust has not been withdrawn: only desysopping on grounds of untrustworthiness will have an effect. Besides which, admins have no more say in any of the "political" processes (of policy writing, enforcement and reform) than anyone else qua admin. The problem is rather one of numbers: the sort of people who get heavily involved in those over a longer period are very often the sort who will either become admins (becoming involved before RFA), or are admins already (becoming involved after). PS your remark of "a largely static adminship" is in any case highly debatable; especially on a 3-5 year time scale, there's actually a lot of churn in active admins. PPS given the perennial confusion between admins and elected representatives, I sometimes wonder if we shouldn't be done with it and have some, empowered to develop policy proposals with something like the deliberation process of ArbCom and put the proposals to the community. At least it would reduce the scale issues perennially experienced in developing big policy changes. Rd232 ^talk 09:28, 18 March 2011 (UTC)

But what actually is the point of a forced break? What actually is it supposed to achieve? It seems to me to me to be just trying to cosmetically address the "Admin is for life" issue but completely missing the reasons why that is considered a problem -- Boing! said Zebedee (talk) 12:05, 18 March 2011 (UTC)

• Your proposal works on the presumption that admins will actually remain active during the term you proscribe and will fill in the necessary tasks. I've put a lot of thought into this, because I am an admin of over three years standing, and I needed to ensure that I'm not protesting out of some self-interest. I don't think I am; I'm sure some others will disagree. :) That said: however many admins there may be, there are not enough admins working in the area I work (text based copyright cleanup); as I demonstrated above, of the four text-focused copyright admins that I know who were promoted within the last three years, three of them are either participating much less or virutally gone. Cut and paste repair, too, is a tedious and complicated task. User:Anthony Appleyard has been steadily working on this task for almost five years. He is one of very few admins who bother to do so. Anthony has been an administrator since December 2006. What benefit to the project could it possibly be to remove him from this task, which he attends to so well, for any length of time? I have myself long thought that there should be an easier process to review and remove admins who are unsuited to the tasks or who go off the rails. But universal forced breaks will only pull qualified people away from tasks which they are willing to undertake. The only way that I can imagine it would work is if we created some kind of draft system to require our new admin volunteers to take on the tasks that are then abandoned, rather than allowing them to work where they want to...and that seems like a whole separate recipe for disaster. --Moonriddengirl ^(talk) 12:26, 18 March 2011 (UTC)

• Those are great examples - forcing you and Anthony Appleyard out of the job for a while would be a disaster. The "admin for life" issue is only a problem for bad admins, not for good productive ones. You wouldn't, for example, force all doctors out of their jobs at regular intervals as a way to address medical malpractice - you'd have a process for addressing bad docs without harming the good ones. -- Boing! said Zebedee (talk) 13:22, 18 March 2011 (UTC)

• It goes a lot further than that Boing!, under this scheme, only 1 of the top 10 admins by administrator actions (who are not bots and are still admins) would be remain an admin. These administrators are doing lots of uncontroversial work, not causing any issues, not showing signs of burnout or political gain (to the best of my knowledge). Desysoping would clearly harm the encyclopedia and I'm unsure of the benefit? Worm^TT · (talk) 13:28, 18 March 2011 (UTC)

Undo button for text editing

Alright, maybe I'm missing something, but I am not sure why (to my knowledge) there is no undo button for those times when you accidentally hit Crtl+A while writing something. Just happened to me before. I see no option for undo, and it's not in the perennial proposals or in the old proposals afaik. So why don't we have an undo button exactly? Oh and redo too I suppose. If there are none without the toolbox thingees then I propose that an undo and redo button be added. Sir William Matthew Flinders Petrie Say Shalom! 17:39, 16 March 2011 (UTC)

What editor are you using, and what effect does Ctrl+A while editing have for you? I use the browser edit box, and there Ctrl+A has the effect of "Select All"; I also have Undo and Redo with their key shortcuts in the Edit menu.  --Lambiam 18:13, 16 March 2011 (UTC)

From a technical standpoint, I'm not sure how readily that functionality can be added to the interface; the edit window itself is just a text box in my browser, and I don't know if an external button can send it an 'undo'. For a user, undo should be available with the shortcut Ctrl-Z, and redo is Ctrl-Y. You can also right-click the text box and select 'Undo' or 'Redo' from the menu that appears. TenOfAllTrades(talk) 18:54, 16 March 2011 (UTC)

Did you intend to start this thread at WP:VPT instead of here? —SW— ^confabulate 23:49, 16 March 2011 (UTC)

Hmm, didn't see that section, so guess I did. I'm using the plain old vanilla editor. And now that I tried the buttons CTRL-Z and CTRL-Y, it did have the undo and redo effect even though I cannot see the buttons indicated. That'll do. =p Sir William Matthew Flinders Petrie Say Shalom! 18:57, 17 March 2011 (UTC)

Use of Abuse Filters for enforcement of bans (including ArbCom bans)

I emailed ArbCom about this (because I thought since it would be an ArbCom ban, it was ArbCom's decision) and they said that I should make the proposal to the community. Basically, the proposal is: I was thinking: people occasionally don't listen to ArbCom or community bans, and end up editing pages or topics they are banned from; sometimes with full knowledge, in which case they might create lots of drama and hinder editing, or a complete accident, where their claims sometimes can't be believed, even when they're true. Then I thought of a way to 'block' users from pages in certain categories or pages etc: the abuse filter. The abuse filter can be used (as said in an IRC discussion) to prevent users from editing certain pages by preventing the edit if a certain user tries to edit a certain page, and I believe this would be useful to prevent users from deliberately going past bans and causing disruption, or banned users accidentally editing pages they are banned from editing and being punished for their mistake. That's my proposal. --123Hedgehog456 : Create an account! 20:09, 16 March 2011 (UTC)

I suppose this could be useful for specific page bans, but in my experience topic ban violations are less often a matter of (to make up an example) "He was banned from Scientology articles and edited scientology!" than of "He was banned from Scientology articles and edited [article of someone marginally related to scientology which may or may not be covered by the ban and which needs ANI drama to determine if it is]." For that reason, having a software solution isn't going to help with most topic bans except in the most obvious of cases. Not necessarily a reason to not pursue it; just saying it may not be as useful as it sounds at first blush. A fluffernutter is a sandwich! (talk) 20:14, 16 March 2011 (UTC)

(ec) Agreed. Editing restrictions are normally so broad that they cannot be usefully implemented in software, see e.g. WP:TBAN.  Sandstein  20:23, 16 March 2011 (UTC)

Hmm, maybe there are areas where it would be impractical, or impossible to implement, but in areas where it is possible to implement, it may provide benefits. --123Hedgehog456 : Create an account! 20:31, 16 March 2011 (UTC)

I think you can ban users from editing articles that are in specific categories, and lots of categories carry the same topics as those that are commonly topic-banned (if you get what I mean). And in my opinion, this would be useful, as no-one wants to be blocked for an accident, or unnecessary drama created by a user editing a page they are banned from and causing problems. --123Hedgehog456 : Create an account! 20:21, 16 March 2011 (UTC)

The server cannot have too many filters and some useful filters were disabled in the past simply because they were not triggered often enough. So a filter for just one user is not going to be created. By the way, another possible solution is to remind users about topic bans through their own common.js. — AlexSm 20:47, 16 March 2011 (UTC)

This doesn't seem to be a good idea for a filter for the reason's given by Alex, but a bot would be easier (reports edits made in the topic). We can keep a section of monobook.js which gives them a nice "do not edit please please please" banner on the relevant pages, so that they don't accidentally edit.

Proposing a new "sister project"?

Is there a standard procedure for proposing a new "sister project" (Wiktionary, Wikiquote, WikiBooks, WikeSource, WikiNews, and a number of others are "sister projects" of Wikipedia, run by the Wikimedia Foundation)? I've created this proposal, but I don't know if that's the sort of proposal being sought there, and as far as I know, no one's noticed it. What would be the best way to inform online communities of the proposal and invite participation? (Besides maybe a brief notice on the talk pages of interested WikiProjects?)

Briefly the idea is this: Web sites like rate-my-prof (or whatever its called) are for soundbites only; they do not welcome serious substantive discussion. They have extremely small limits on lengths of comments and don't want to change that. I'd like to have a forum devoted to the same topic, differing from those in that it would allow and encourage serious discussion. Michael Hardy (talk) 23:34, 16 March 2011 (UTC)

I don't believe this is something that the Wikimedia Foundation would be interested in. All of the current projects revolve around making knowledge more accessible, an encyclopedia, a dictionary, a collection of primary source documents, a collection of multimedia files. Your idea seems more along the lines of a social network or a forum on living people. I would personally not support such an idea being created under the WMF banner. Sven Manguard Wha? 04:59, 17 March 2011 (UTC)

You may want to check out the Strategy wiki, it's a place where you can make these kinds of proposals. -- œ^™ 08:01, 17 March 2011 (UTC)

Without considering the merits of the proposal, Wikimedia does have a page for proposing new projects at meta:Proposals for new projects. Qwyrxian (talk) 08:04, 17 March 2011 (UTC)

Random Article

I have read through WP:PEREN and as far as I can tell this issue haunt been directly proposed yet. I have also searched through the archives of the pump and again as far as I can tell this issue has never been directly addressed.
I believe that there needs to be a way to tag something to not show up if you press the random article button on the side bar. I am saying this mostly for the point of censorship, I am not saying that the article be removed I am just saying make it so a 5 year old on Wikipedia can't hit the random article button and get something inappropriate for his age. I understand there are ways to go into setting to dis able pictures showing up but to do that you would have to know that the picture was on there in the first place. _{@ d \/\/ | | |}^Talk 11:42, 18 March 2011 (UTC)

WP:NOTCENSORED. I am also willing to bet my left kidney that 99.999% of all children visiting "inappropriate" pages on wikipedia do so because they actually searched for a specific term rather than with random article. Yoenit (talk) 12:14, 18 March 2011 (UTC)

Proposed liberty on essays

(NOTE: The following was moved from Wikipedia:Proposed liberty on essays. -- Uzma Gamal (talk) 14:10, 18 March 2011 (UTC)): The Proposed liberty on essays is a Wikipedia proposal that would let people have POV essays that don't have to do with Wikipedia. Well, we have userboxes that often have a POV and userboxes are often short. It would be healthier for the brain because then we can read more and thus our brains don't become mush. -- SomeDudeWithAUserName 21:22, 17 March 2011 (UTC)