Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

The proposals section of the village pump is used to discuss new ideas and proposals that are not policy-related (see Wikipedia:Village pump (policy) for that).

Recurring policy proposals are listed at Wikipedia:Perennial proposals. If you have a proposal for something that sounds overwhelmingly obvious and are amazed that Wikipedia doesn't have it, please check there first before posting it, as someone else might have found it obvious, too.

Before posting your proposal:

• Read this FAQ page for a list of frequent proposals and the responses to them.
• If the proposal is a change to the software, file a bug at Bugzilla instead. Your proposal is unlikely to be noticed by a developer unless it is placed there.
• If the proposal is a change in policy, be sure to also post the proposal to, say, Wikipedia:Manual of style, and ask people to discuss it there.
• If the proposal is for a new wiki-style project outside of Wikipedia, please go to m:Proposals for new projects and follow the guidelines there. Please do not post it here. These are different from WikiProjects.

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

"Safe Search" or "Adult Filter" function proposal

Many search engines and websites have something called a "Safe Search" or "Adult Filter" function. Wikipedia does not have such a thing. This causes many parental controls and corporate content filters to block Wikipedia. That sucks. Is there any way we could create such a feature so that Wikipedia would not get blocked? GO-PCHS-NJROTC (talk) 02:11, 16 April 2008 (UTC)

Wikipedia is not censored. People who are searching for things like that are going to get what they want. We don't cater to any specific group or party in this regard; we portray these things in an objective, neutral manner that demands no censorship. Sephiroth BCR ^(Converse) 02:26, 16 April 2008 (UTC)

How do you define "adult content"? --Carnildo (talk) 04:32, 16 April 2008 (UTC)

While Wikipedia is not censored, there isn't anything stopping people from installing filtering software which should block most "undesirable" content, although I must stress the word most. But I don't think anything can be done at the Wikipedia level. x42bn6 Talk Mess 18:43, 16 April 2008 (UTC)

But the problem occurs when the filtering software ends up designed to block Wikipedia as a whole. I'm not saying we need to ban unsafe material, I'm just saying it might be a great idea to have some kind of special system to make it possible to have a "block adult content" feature which could be enabled by the viewers which could be done not only be registered users, but annon IPs as well. The idea would be to have a system similar to the one at http://www.aboutus.org. Another possible idea would be to have a system where Wikipedians could report pages as "adult content" and the word "explicit" would appear in the URL so that the designers of filtering software would block only those articles instead of Wikipedia as a whole. We could also make a policy where all articles containing mature material would have to have "(mature content)" in the title (so basically, if someone searched for "Naked woman" for instance, it would redirect that person to "Naked woman (mature content)"). I don't really see how mandating that all of such content have the text "(mature content)" in the title would be censoring Wikipedia, since the content would still be there and there would be little effect on anyone trying to post such content; the only people this would effect would be those on filtered computers. GO-PCHS-NJROTC (talk) 01:27, 20 April 2008 (UTC)

Who gets to decide what is "safe" and what isn't? Admins? Consensus? The Wikimedia Foundation? Oppinions as to what is appropriate for minors differ vastly accross cultures and nations. For example, I know a lot of people who would have no problem whatsoever if their 5-year old child saw a (non-pornographic) image of a naked person. But I also know people who would have a huge problem with that. And they don't even belong to different ethnic groups. So which group do we cater for? How to we find a compromise that pleases both groups? We can't really. All we could do is cater for every conceivable group, and soon a large number of Wikipedia articles would be tagged as "unsafe". A much better idea is to let each cultural group censor itself. This is already possible, so why bother with a universal "unsafe" template that can be added and removed by any self-declared moral crusader, and that will achieve nothing but endless edit warring? Cambrasa 23:44, 17 April 2008 (UTC)

There are no known cases of Wikipedia being completely blocked by parental or corporate content filters. If you know otherwise, speak up, otherwise I don't think you have much of a point. Kaldari (talk) 00:02, 19 April 2008 (UTC)

Charlotte County Public Schools blocks Wikipedia for this reason; the only way a student or teacher can access this site from one of Charlotte County's schools is to sneak on through the secured site, which only a few dedicated editors (constructive and destructive) even know exists. As evidence, read this email I received when I emailed CCPS IT requesting that Wikipedia be unblocked:

"(removed for security) <(removed for security)@embarqmail.com> writes: >Why exactly is Wikipedia blocked anyway? > (removed for security),

I take it that you are a student? I could not find a teacher with that name.

The short story is that I have to follow district policy. wikipedia is a very interesting and sometimes useful site. I won't argue about whether or not its all guaranteed to be factual since it is created "by the people for the people". As with anything, consider the source.

You may have noticed that most of the search engines like Yahoo! and Google are forced to use "safe search" settings. wikipedia has no such functionality. It wants to be uncensored. That is all well and good, but because of this, the site includes a porn star database, "recipies" for doing bad or dangerous things (I'm intentionally being vague on that one), etc.

Wikipedia is like the Internet in it's own little world, it has a bit of everything. Because of the "bad stuff" one can find on wikipedia, it is blocked.

I hope that explanation helps. A school district is required by law to provide safeguards and you won't get the freedom you'd expect at home here."

See, there are content filters blocking Wikipedia. If you'd like, you can contact CCPS at web_security AT ccps DOT k12 DOT fl DOT us (but please don't say anything about the secured site, you'd make lunch time awfully boring as I go to the media center to fight vandals during lunch). GO-PCHS-NJROTC (talk) 00:52, 20 April 2008 (UTC)

Looks like this problem has more to do with backward US laws. I'm sure that Pakistani Madrassas censor wikipedia for similar reasons. Perhaps we can deal with this by categorizing wiki articles in such a way to take cultural sensitivities into account. Perhaps this might even allow the Taliban to be able to safely access wikipedia if we can categorize articles such that their browsers will be able to block pages depicting women who do not wear a burqa. :) Count Iblis (talk) 17:11, 22 April 2008 (UTC)

This kind of categorisation already exists, plus the tools to block categories. See Category:Bad images. Only problem is that some schools seem to stupid or lazy to make use of these tools. This isn't really our fault. All we can to is try to educate more. But we don't need universal censorship.Cambrasa confab 02:24, 26 April 2008 (UTC)

Thank's, I wasn't even aware of that. However, I think it would be great if we could create a similar catagory for Bad miscellany (this would include articles) or maybe just Bad articles. Also, must a person be logged in to block catagories? GO-PCHS-NJROTC (talk) 23:44, 27 April 2008 (UTC)

A school blocking all of Wikipedia because a few pages have "inappropriate content" is just stupid and a very poor reason to make the significant changes this will require. Either the school is too cheap or paranoid to use filtering software that can block based on page content, or they're just too lazy to configure their filter properly. Mr.Z-man 23:55, 23 April 2008 (UTC)

We're not talking about the school itself, we're talking about the district. The reason it's blocked is 'cause some idiot over at Charlotte High School in Punta Gorda, Florida got the urge to go on here and look up porn stars. If you want, you can email them, but I doubt much is going to change as long as we have one high school in the area (or possibly one more, Lemon Bay) that has malicious students, not much is going to be done to get the site unblocked unless something is changed on the Wikipedia side. Hey, it's not my schools fault that some SOBs from the other schools decided to act like a bunch of jack asses. GO-PCHS-NJROTC (talk) 18:39, 24 April 2008 (UTC)

It's probably not the only issue, but I can pretty much come up with a more reasonable solution for the other issues. By the way, I'm using the secured URL right now, which allows me on here from school for now, but I don't know how long that's gonna last. You might bring your opinion up with web_security AT ccps DOT k12 DOT fl DOT us, but if you say anything nasty, don't point the finger at me, I just think it sucks that at any moment I could get kicked off of this site by filters. GO-PCHS-NJROTC (talk) 18:43, 24 April 2008 (UTC)

There is no reasonable solution to an unreasonably draconian school district. Dude, schools are always going to have students who look up porn. The best idea is probably just to circumvent the school's computers altogether and edit Wikipedia through a mobile broadband modem attached to your laptop. --Cambrasa confab 02:39, 26 April 2008 (UTC)

I might as well try and use a secured proxy as to try that. I don't access Wikipedia from a laptop unless I'm at home; I edit from desktop PCs when I'm at school. The district does not allow any electronic devices on campus. It's not that it's as big of a deal for me as it is for other people who would like to use this site on projects and stuff (hey, I fall in that catagory too). Besides, I don't have a cellular internet service, and I hear all of the wireless access points around the school require WEP codes. Also, I wonder how many other districts block access to Wikipedia. I'm sure we aren't the only one. GO-PCHS-NJROTC (talk) 18:55, 26 April 2008 (UTC)

Anyone who says that "Wikipedia is not censored" is actually a liar, if it weren't censored, vandalism would never be reverted, the notability policy would not exist, WP:NPOV would be unknown to all, WP:UAA would be tagged as humorous, open proxies would be free to edit, spam would be welcome, attack pages would exist indef, WP:CIVIL would be an essay rather than a policy, page protection would be considered a joke... A more appropriate statement would be "Wikipedia is censored," other sites don't have near as many policies and endless cernsorship as we do. GO-PCHS-NJROTC (talk) 19:39, 26 April 2008 (UTC)

You are confusing censorship with moderation. Vandalism, spam, and uncivil comments are moderated because they are are a detriment toward our goal. We have NPOV to ensure balanced coverage. Censoring based on explicit content anymore than the law requires us to would be harmful to the project. Removing spam and vandalism is not harmful and straw man arguments do not help your proposal. Mr.Z-man 23:50, 27 April 2008 (UTC)

Okay, so that might have sounded a little extreme, but still, saying that "Wikipedia is not censored" implies that anyone may come on here and create articles about themselves, their friends, their run-of-the-mill elementary or middle school, the run-of-the-mill mom and pop convenience store on down the road, their best friend's wedding, the day their cows got out and shit on a political sign, yesterday's newspaper, and all kinds of other nonsense that will in reality be deleted under the notablility policy. The statement also implies that people can create usernames such as "I f***ed your mom," "Always shop at Kmart," "I am an administrator," "I am an unlicensed bot," and other nonsense usernames banned by the username policy (not that I'm saying that I disagree with the policy or anything). Hey, I ought to propose that "Wikipedia is not censored" be replaced with "Wikipedia has rules," right? GO-PCHS-NJROTC (talk) 00:48, 28 April 2008 (UTC)

You don't seem to understand what censorship is. Censorship is not the removal of inaccurate, unverifiable, and unhelpful content. Censorship is the removal of verifiable and pertinent content because some groups find it objectionable. Or at least this is what we mean by censorship. If you have a problem with that (widely accepted) definition of censorship, I suggest you discuss it on the page Wikipedia talk:What Wikipedia is not. Cambrasa confab 17:11, 28 April 2008 (UTC)

What you are not understanding is this, Wikipedia does have rules, particulary dealing with user conduct, as well as quality standards. However we don't censure things that can be considered "pornographic" or "gruesome" if they are represented accurately since that wouldn't conflict with our quality guidelines, there is also the fact that "acceptable" and "non-acceptable" are a matter of opinion, thus they are in direct conflict with WP:NPOV. - Caribbean~H.Q. 17:19, 28 April 2008 (UTC)

Sure. I kinda disagree, but I'm not going to enflame an argument here; arguments = destruction. GO-PCHS-NJROTC (talk) 19:42, 28 April 2008 (UTC)

I don't think anyone is advocating censoring Wikipedia. What was suggested is a "hook" or an optional feature that would enable people, households or corporations to censor, at their own discretion, a particular brand of content that is often found undesirable. This would enable such individuals to use Wikipedia at their own comfort level. --Eliyak T·C 00:21, 5 May 2008 (UTC)

I don't really see what kind of benefit this would add to Wikipedia. Personally, I don't find much use in a bastardized, half-assed version of something. It would seem that the only argument in favor of implementing such a system would be to help try and convince draconian public schools to unblock the project and allow access. However, at that point, it's essentially up to them to dictate what constitutes a bad article or a bad image rather than by operating by consensus on what constitutes such things, which is a terrible idea. I think it best to err on the side of staying with the goals of the project and providing information to everyone. Celarnor ^{Talk to me} 11:07, 5 May 2008 (UTC)

I seriously suggest that you start a petition. In this regard, you might like to read Wikipedia:Researching with Wikipedia and Wikipedia:School and university projects. Anyone who thinks that it would be feasible to implement a system where pages could be flagged on the grounds of their content should take a look at the debates over at AFD. We shouldn't add another layer of administration, policies and rules just because some narrow-minded school districts can't figure out how to configure their net-nanny filters. Wikipedia has information about a wide range of sexual activity, and even some information out how to make certain kinds of infernal machines, but a student who cannot figure out how to build an Improvised explosive device, and can't manage to get internet access through a mobile phone, will probably not get far just by reading Wikipedia. Back in the days before the evils of the internet and The Anarchist Cookbook, my friends at school were successfully building chlorine bombs and match-head bombs. If students are looking at nekkid pictures on Wikipedia when they should be working, or where other students can see and be offended, those students should be disciplined. Honi soit qui mal y pense. --Slashme (talk) 13:54, 5 May 2008 (UTC)

I agree, the student(s) need to be punished individually. I do believe that it was CHS students, so there's not as much chance that their school would do anything as some of the other schools would; their teachers tend to let them get by with things they shouldn't. On the other hand, I think it was probably more of a teacher there too lazy to do his/her job than anything else; most websites that are blocked by the filters are 1: blocked because a teacher or staff member requests it, or 2: the website is a popular website and is a blatant violation of district policy (examples: myspace.com, torproject.org, hotmail.com). I don't see that Wikipedia is a blatant violation, so I'm guessing some idiot teacher complained, and there's a good possibility that the reason this site is blocked entirely is because the teacher or staff member wouldn't settle for just blocking particular articles or catagories. GO-PCHS-NJROTC (talk) 01:49, 9 May 2008 (UTC)

Wikipedia is not censored, period. Who makes the decision about what is "family friendly?" Google image searches are one thing, but I'm strongly opposed to having a filter capability on the encyclopedia, there's just too much potential for bureaucracy. What's the next step, requiring age verification with a credit card to perform an uncensored search? No way! If parents, schools, or libraries want to filter out objectionable content on the encyclopedia, they can do that on their end easily enough without blocking the whole site. Mister Senseless™ (Speak - Contributions) 15:29, 7 May 2008 (UTC)

Renaming the "move" tab to "rename"

I've never really understood why "move" was called "move." In reality, you're not moving anything, you're just changing the title of the page. None of the logs move, none of the deleted revisions move, nada, zilch, squat-diddily. The history moves over, but that's sort of an expected result of renaming something. In short, there is, so far as I can tell, no point whatsoever in calling that a "move." Because that's exactly what it isn't. I'm not the only one confused by this, either - the help desk gets asked on a regular basis "How do I edit the title?", "How do I rename this page?", or my personal favorite, the all-caps "WRONG TITLE". Here's one today, from Apr. 14, from Apr. 9, just after that last one, and so on. Mind, we do get a LOT of repeat questions, but renaming this tab would be really helpful in reducing those numbers, as well as reducing the number of confused newbies who don't bother asking. Of course, the log will still appear as a "Move log", but those who need to check those logs will probably know what it's referring to. For reference, the appropriate MediaWiki page is MediaWiki:Move. Hersfold ^(t/a/c) 23:37, 16 April 2008 (UTC)

Support the change (in fact, I've been thinking about it for a while). Soxred93 | talk bot 23:38, 16 April 2008 (UTC)

For what it's worth, "move" makes perfect sense to me, as you're moving the entire article (with history) to a new name. *shrug* EVula // talk // ☯ // 23:50, 16 April 2008 (UTC)

I support this. It makes a lot of sense. Majorly (talk) 23:51, 16 April 2008 (UTC)

I think [move] suffices just fine, honestly. seresin ( ¡? ) 23:56, 16 April 2008 (UTC)

@ EVula and Seresin: I will admit it does sort of make some sense, but look at it from the eyes of a newbie. If you're looking to change the title, would you click on "move", or would you be confused when there wasn't a "rename" tab? Hersfold ^(t/a/c) 00:24, 17 April 2008 (UTC)

I think rename makes more sense semantically, but I think it might cause more confusion to newbies due to the tree structure of pages. If someone wants to move a top-level page to a subpage, it's not as intuitive to call that a "rename". People might not understand that they are both the same function, and that in order to move a page within the "tree", you need only "rename" it. People here are used to computer file systems, where changing something so that it's in a "sub-folder" requires a "move", which is a separate function from "rename". In reality, you're not actually "moving" anything within a file system either, you're merely changing its name. But the illusion is important to the intuitiveness of the system. Equazcion •✗/C • 00:32, 17 Apr 2008 (UTC)

I'm probably a bad person to ask, because when I was a newbie, I put that together quite readily. But I'm also the sort of person that pokes at every little button up there to find out what they do... EVula // talk // ☯ // 00:34, 17 April 2008 (UTC)

This has come up here before. While move doesn't really fit, rename just invites newbies to vandalize with it or test it even more than just move does. Reywas92^Talk 01:28, 17 April 2008 (UTC)

That was before only autoconfirmed users could move pages, though. Soxred93 | talk bot 01:53, 17 April 2008 (UTC)

"Rename" sounds better, for newbies, in theory, so I support it in principle. My personal preference for "move" can be easily achieved with some JavaScript; I already have "edit this page" fixed to "edit" and a few other changes. Nihiltres^{t.l} 02:50, 17 April 2008 (UTC)

I wasn't confused by the word "move", but I admit that "rename" is clearer, so I'll support. I don't think we would have a problem with people testing it any more than we do now; and any small increase in vandalism can be delt with by stern warnings and blocks. --Arctic Gnome (talk • contribs) 03:04, 17 April 2008 (UTC)

• Yes, I'd support changing the "move" button to the "rename" button: many times I have encountered users who don't know how to rename a page because they can't find the "rename" button, and instead, they perform cut-and-paste renames, which are disruptive. Changing "move" to "rename" will be a very good idea. Acalamari 16:13, 17 April 2008 (UTC)

• I did this before and it got reverted...up for it again though. Voice-of-All 16:57, 17 April 2008 (UTC)
• In my opinion, "rename" makes the action sound less computationally intensive than it actually is, in terms of the number of pages that need to be reparsed as a result. Unlike simply renaming a directory name in a file system (the tree structure Equazcion mentioned), or changing a file name in Windows (where all shortcuts to the file are changed to reflect the rename), moves can corrupt link structure. If one doesn't know what "move" means, how might one know what a "double redirect" is, and all of the problems that are caused by it? e.g. "I wonder what happens if I rename 'Kitten' to 'Kittie cat'. I'll just rename it back when I'm done". Users making constructive page moves when they need to is a great thing, but imho, calling a page move a rename simplifies what the action does and does not do. The term is more clear in terms of what the MediaWiki actually does with the database (see Title.php, "public function moveTo"), but not in terms of what the consequences of the action are. Gracenotes^T § 19:16, 17 April 2008 (UTC)
  • But how can moving renaming pages screw up links when the original page is always automatically redirected to the new page? GO-PCHS-NJROTC (talk) 19:22, 26 April 2008 (UTC)

  I agree. "Move" is clearer. It gives the connotation that more is happening than the name of a page is being changed. If it was possible to edit the title of a page, then I could understand "rename", but that's not what happens, and we do a disservice to newbies by making it appear otherwise. - jc37 00:56, 18 April 2008 (UTC)

  I also prefer "move" for the same reason. —Remember the dot ^(talk) 00:38, 19 April 2008 (UTC)

  Likewise. Allow me to give you a metaphor... Titles are like lockers, ready to accept labelled containers (boxes etc.) of various types of content (representing information). An index also exists (representing the network of links and categories here), tracking all the containers and noting which lockers they are in. Moving pages is like moving the contents to different lockers inside their containers, orderly and with their names on top; the index is updated. Cutting and pasting is like emptying the containers and clumsily moving the contents by hand, unlabelled. On one hand, the index to the lockers will refer to the empty containers, so tracking the contents will be difficult. On the other hand, the contents will be outside any indexed and labelled containers, and thus unidentifiable (no history). As one can plainly see, there is a problem at both ends of the equation... And all this cannot be represented by Rename, which would imply a simple re-numbering of the lockers. Waltham, The Duke of 17:19, 19 April 2008 (UTC)

Given the hierarchical way in which subpages work, "move" seems to a better descriptor than "rename". If something goes from User:Until(1 == 2)/Foobar draft to foobar, then that has been moved, not just renamed. _(1 == 2)^Until 17:40, 19 April 2008 (UTC)

I don't see the point. Move and rename are synonyms computer-wise - I don't think one is any clearer than the other -Halo (talk) 17:49, 19 April 2008 (UTC)

Move requires users have a mental conceptual model that equates physical locations with different articles or web pages. I bet for novices that's more complex than the conceptual model that they can rename the article on a web page. They don't need to then understand how the hierarchy / name space works to make sense of the tab. - Owlmonkey (talk) 18:56, 23 April 2008 (UTC)

Exactly; novices should have a complex image of the moving process because it is a complex process, or at least it is much more complex than a simple Rename implies. Look at my metaphor above; it is essential that all editors should learn early on exactly what a move entails, and the suggested modification, if implemented, would create a false image of non-existent simplicity. Waltham, The Duke of 01:13, 27 April 2008 (UTC)

• Support. Simpler conceptual model for users to learn = easier to use UI. - Owlmonkey (talk) 18:56, 23 April 2008 (UTC)

• Strong Support; the name "move" could be confused with page merging. "Rename" would be a much more appropriate term. The only problem I can think of is that there are many essays and policies that will have to be modified after the change, but that aside, this is a terrific idea. GO-PCHS-NJROTC (talk) 19:13, 26 April 2008 (UTC)
  • What you are essentially saying is that there are newbies who do not know what moving is but are familiar with the concept of page merging. I have trouble believing that. Waltham, The Duke of 01:13, 27 April 2008 (UTC)
    • It depends on what we're talking about when we say "newbie", and it depends on what part of Wikipedia a person has been working with. Someone who has only been here a few days would probably usually not even know how to properly cite his/her sources, much less know anything about Wikipedia terminology. However, someone who has been here a few weeks may know a little bit about moving and merging, but may not understand them thoroughly. A person may not know what page moving is until he/she's either played around with it him/herself, or he/she has asked someone what it is. I remember this from when I first came here. Oh well, so much for my opinion. GO-PCHS-NJROTC (talk) 00:01, 28 April 2008 (UTC)
      • Actually, editors are supposed to read the relevant documentation before trying out anything new, but it looks as if this is not the cool way to do things on Wikipedia. (rolls eyes) In any event, if an editor has picked something up about page merging, which means that they will have probably heard people talking about it, it is also likely that they have heard about its being restricted to administrators. Moves are discussed much more, and clicking on Move tells one what it is anyway: "Using the form below will rename a page, moving all of its history to the new name. The old title will become a redirect page to the new title. Links to the old page title will not be changed; be sure to check for double redirects (using 'What links here') after the move. You are responsible for making sure that links continue to point where they are supposed to go." There is nothing about merging here. Waltham, The Duke of 13:42, 30 April 2008 (UTC)

• Strong oppose – per my various arguments above (I do not like repeating myself). Also, a point which has just occurred to me: by moving a page one can (and usually does) also move its corresponding talk page; it is much easier to say that the talk page is moved along the main page than to say that it was renamed in the same way as the main page... More intuitive as well. Waltham, The Duke of 01:13, 27 April 2008 (UTC)
• Support - I agree that from a user perspective, the "move" functionality is identical to "renaming the article" Bluap (talk) 04:30, 28 April 2008 (UTC)
  • If the user botches it up, then they will realise that this is not true the hard way. Even if they do it correctly, they will still have to fix double redirects (I know that a bot does it as well, but it is better if the users do that themselves); rename implies that changing the name of the page will also automatically update all incoming links. This is misleading. Waltham, The Duke of 13:42, 30 April 2008 (UTC)
• Oppose - "Rename" isn't descriptive of moving pages to or from sub-pages, and is confusing in that regard, especially to newbies. Equazcion •✗/C • 04:46, 28 Apr 2008 (UTC)

PS. This section should've been called "Moving the 'move' tab to 'rename'"! Hyuk hyuk. Equazcion •✗/C • 04:52, 28 Apr 2008 (UTC)

• Support - to me, "rename" is the clearest word to describe what happens from the user's point of view, which frankly is all that should matter. I like owlmonkey's argument. I don't like these "psychology" arguments about using "move" (perhaps I'm exaggerating a little here) because it confuses potential vandals or induces new users to read about what the word means. Dwr12 (talk) 20:26, 5 May 2008 (UTC)
• Oppose, when I first got the idea of changing the name of a page, the Move thing was a bit concerning, and I think that's the way it should be; thought-provoking. If it is called rename, many childish acts of vandalism will result. Phlegm Rooster (talk) 06:45, 6 May 2008 (UTC)
  • Don't you have to be a registered user to move articles though? Dwr12 (talk) 18:20, 7 May 2008 (UTC)
    • You really think there are no childish acts of vandalism from registered users? SamBC(talk) 18:31, 7 May 2008 (UTC)
      • If they do, it's easy to fix right? If we are really concerned about registered users vandalizing the encyclopedia then the solution is (not that I'm advocating this ) to make renaming available only to administrators rather than an ambiguously-worded button. Dwr12 (talk) 23:51, 8 May 2008 (UTC)
        • "Easy" is a relative concept; the page will have to be moved back. If the initial page has been edited in the meantime, things are even more complicated, because only an administrator will then be able to move the page back. And it's not just vandalism; we should be more worried about honest mistakes caused by a lacking understanding of the moving procedure. Things can go wrong along the way. Waltham, The Duke of 00:47, 9 May 2008 (UTC)
• Oppose, by the way, lots of good arguments on both sides, but creating a false feeling of simplicity is just going to cause more confusion. SamBC(talk) 18:31, 7 May 2008 (UTC)
• Support if autoconfirm is strengthened. Otherwise, we're just inviting move (ahem ... rename) vandalism. (See Wikipedia:Autoconfirmed Proposal/Poll.) -- John Broughton (♫♫) 23:59, 8 May 2008 (UTC)
  • With all due respect, sir, adding ten or twenty edits to the auto-confirmation threshold will not make editors experts in moving pages, with move-vandals or without. Waltham, The Duke of 00:47, 9 May 2008 (UTC)
• Support this. While I figured out what "move" did without too much trouble, "rename" seems like it would be a lot clearer from the newbie perspective. Lankiveil ^{(speak to me)} 12:10, 12 May 2008 (UTC).
• Support -- "rename" is easier for newbies to understand than "move" and the overall effect is basically the same. One thing that I thought of is having a setting in preferences so that registered users can choose between "move" and "rename" -- unregistered users, who are generally (but not always) newbies, would see "rename". -- Imperator3733 (talk) 20:23, 12 May 2008 (UTC)
• Resounding oppose - "move" is clear, accurate and succinct... thus has all the makings of a good title. It also has a root in our 'history', such as it is. —TreasuryTag—t—c 18:51, 13 May 2008 (UTC)
• Oppose - prefer move, and less likely (I feel) to be abused as much, maybe. FT2 ^{(Talk | email)} 16:25, 15 May 2008 (UTC)

Being able to edit your edit summaries

Ok, I've done this way too often. I make an edit, write the edit summary, and click "Save page", only to notice that I completely misspelled a word. At this point, there is nothing I can do about it other than hope nobody looks at my contributions. My proposal is being able to edit your own edit summaries. I brought up this discussion on one of the Wikipedia IRC channels, and there were plenty of ideas. The first is only letting admins edit summaries, and letting people make requests for them, because there is fear that other users would abbuse it, and possibly fabricate them. The other is only being able to make minor edits to fix typos, and prohibit completely rewriting the edit summary. I know this sounds odd, but some people (myself included) think this would be something that would make editing a little easier. Juliancolton ^{Tropical Cyclone} 17:06, 23 April 2008 (UTC)

I really don't see the need for this, nor a big problem that this would solve. If anything, a user script can be created that would require some sort of confirmation of your edit summary before saving it. - Rjd0060 (talk) 17:36, 23 April 2008 (UTC)

I think such a feature would be useful, as long as only admins could change them, and a history of the changes was logged. It should only be done for typos and minor mistakes. Fabrications of edit summaries would obviously not be allowed. Majorly (talk) 18:17, 23 April 2008 (UTC)

I would say have it so you could only change it if it was the most recent edit to that article (and it was your edit, ofcourse). This would do away with the need for a history of changes, admin-only restriction, etc., while allowing for fixing of one's edit summary in the vast majority of cases where it would be useful and appropriate. Kevin Baas^talk 18:21, 23 April 2008 (UTC)

This would require a fundamental change to how Wikipedia's database is structured. _(1 == 2)^Until 18:40, 23 April 2008 (UTC)

How so? You wouldn't need to change any table names or column structures. As far as the database is concerned, it would just be one additional "update" query. Something like "update [table] set summary=? where article=? and revision=? and editor=? and revision=(select max(revision) from [table] where article=?)". That's not what i'd call a "fundamental change [in the] database [structure]". Kevin Baas^talk

I'd much rather be able to change my log summaries (blocking, protecting, etc) which can sometimes look odd with typos. MBisanz ^talk 18:43, 23 April 2008 (UTC)

I would support that if it's possible. I would add though, that a message (like "This edit summary was added at ") was added at the end of the summary and then let admins view all versions of the edit summary. -- Imperator3733 (talk) 20:29, 12 May 2008 (UTC)

Why waste time fixing a typo in an edit summary? Edit summaries are not part of article content, and so it doesn't matter that they have perfect grammar. If you really need to amend or retract an edit summary, then make a dummy edit or use the talk page. –Pomte 20:12, 23 April 2008 (UTC)

Because that would be an even greater waste of time to leave a message on the talk page. And it wouldn't take that long. It could be like Rollback. You have to be granted the ability to edit your edit summaries, and then you just have to press a button or something. And really, how much time is it going to waste? Also, an edit summary is supposed to give an overview of what you've changed in the article. If you misspelled something or gave the wrong information, people might mistake what you've done. Juliancolton ^{Tropical Cyclone} 20:27, 23 April 2008 (UTC)

And it can get worse. I have sometimes pressed the wrong key while writing the edit summary (I still don't know exactly what I did) and that resulted in the edit being saved with just half the summary. This is obviously unhelpful. Waltham, The Duke of 21:02, 23 April 2008 (UTC)

That happens to me all of the time. You pressed Enter. hmwithτ 18:26, 15 May 2008 (UTC)

I would go with Kevin Baas on this one. One's most recent summary should be editable to fix typo. Any more than that, I and see RfA candidates going back to give themselves a leg up. —Preceding unsigned comment added by Paragon12321 (talk • contribs) 22:29, 23 April 2008 (UTC)

There is a simpler solution. Cultivate the habit of proofreading the edit summary as well as the actual edit when you show a preview. If you make a small error, it is really not a problem. If you really screw it up, make another edit to carry a correction.

Letting people alter either edit summaries or the substance of edits is allowing the rewriting of edit histories. It undermines the integrity of edit histories. The benefits are not anywhere close to being worth the cost. IMO. Wanderer57 (talk) 02:25, 24 April 2008 (UTC)

Not if you only let them change their edit summary if it was the most recent edit to that article - as soon as another edit is made you can no longer change the edit summary, so a historical record is kept (and shown) that can't be rewritten. Kevin Baas^talk 15:36, 24 April 2008 (UTC)

You may be right. I think people are underestimating the technical difficulties involved in allowing people to edit their edit summaries, and overestimating the benefits of doing so. Wanderer57 (talk) 06:01, 25 April 2008 (UTC)

This is a great idea! I suggest limiting it to the latest edit during a 1 - 12 h period. Coding-wise it is an absolute no-brainer and will be very easy to implement (contrary to the above comments). Full support - Сасусlе 00:15, 26 April 2008 (UTC)

This is also good if you accidentally forgot to add a summary or put in the wrong one (happens if you have many tabs open). This would cut down on pseudoedits just to give or correct a summary. Сасусlе 20:49, 26 April 2008 (UTC)

Straw poll

I think it is too early to start a straw poll, please let us discuss details and implications a but further. Сасусlе 20:49, 26 April 2008 (UTC)

See also: bugzilla:10105. --MZMcBride (talk) 20:55, 26 April 2008 (UTC)

Support

1. This is an excellent idea. At present, vandals can put offensive comments in an edit summary and nothing can be done about it other than attempt to get the edit deleted from history. GO-PCHS-NJROTC (talk) 20:29, 26 April 2008 (UTC)

   I am pretty sure that there is a wide consensus that admins should NOT be able to edit summaries of other users. We are talking so far about changing your own summary during a limited time period for every user. Сасусlе 20:49, 26 April 2008 (UTC)

   That sucks; I think admins should be able to edit the edit summaries; I have seen WAY too many vandals using abusive edit summaries. But I still support, there's been plenty of times when I've screwed up with edit summaries and wished I could go back in and fix the problem. GO-PCHS-NJROTC (talk) 00:20, 28 April 2008 (UTC)

   If an edit summary in a vandalism edit is that offensive, the revision can be deleted by an admin -- no editing necessary. Equazcion •✗/C • 09:34, 4 May 2008 (UTC)

2. I have often wished I could edit my summary - sometimes I noticed my error just as I clicked the Save button. Allowing users to edit their own summaries immediately after saving and before any other edits to the page seems very reasonable. Sbowers3 (talk) 00:02, 28 April 2008 (UTC)
3. have it so you could only change it if it was the most recent edit to that article (and it was your edit, ofcourse). Kevin Baas^talk 14:19, 3 May 2008 (UTC)
4. This idea would be wonderful if it can ever be implemented. Users should only be able to edit their own summaries, except admins can edit other users summaries to remove stupid comments ect. .:Alex:. 19:25, 3 May 2008 (UTC)
5. Excellent idea; more people see edit comments that the actual text, and how many times have we all see boo-boos after pressing the button? TONY (talk) 14:00, 5 May 2008 (UTC)
6. A fine idea - a few times I've hit "Save Page" and at the last moment realised that I've omitted something from the edit summary that perhaps should have been there. I see no real drawbacks (apart from the drain on the programmer's time) to this proposal. Lankiveil ^{(speak to me)} 12:12, 12 May 2008 (UTC).
7. Support - users should be able to edit their last edit, as long as it is the last edit to a page and it has been no more than a couple hours. -- Imperator3733 (talk) 20:35, 12 May 2008 (UTC)

Conditional Support

• On one hand there should be a mechanism for removing disrputive, offesnsive, promotional, or dangerous edit summaries without going through oversight. On the other hand, I'm opposed to allowing any user to change any edit summary. It has a huge potential for abuse or misuse and I'm not sure why the average contributor would need that capability anyway, except maybe to correct a typo on their last edit. My vote would be to definately give sysops the capability to modify or remove offensive or disruptive edit summaries, and to allow other users to edit their own most recent summary under some type of time limitation. Mister Senseless™ (Speak - Contributions) 18:39, 1 May 2008 (UTC)
• Yes – I have made typos in edit summaries, and also sometimes wished that I had written one (instead of using the default). This is a neat idea. However, I am not sure if there are any legal issues (therefore, I'm putting my support as "conditional.") 69.140.152.55 (talk) 14:10, 12 May 2008 (UTC)
• Weak support leaning towards "not really important", there's been a few instances where I wished I could fix my edit summary, but again it's no big deal (forgive the cliche). If it's not a huge technical hurdle, I'd support editing the last edit summary only, during a 5 minute window following the edit. xenocidic ( talk ¿ review ) 16:40, 15 May 2008 (UTC)

Oppose

1. Not worth fussing over. Live with your embarrassing mistakes, or make a non-edit follow-up to correctly describe your mis-typed previous edit. Too many issues about the reliability and fixed-ness of the edit history database arise in ths proposal. -- Yellowdesk (talk) 20:04, 3 May 2008 (UTC)
2. Language in an edit summary is often quoted in disputes, often very quickly after the edit. Fixing the imo trivial problem of typos in summaries would seriously jeopardise the ability to verify these claims if an editor can go back and modify their summary based on future events. Frankly, well meaning intentions aside, this is a no-brainer, or should be to anyone who has followed a few disputes before. A far worse problem that needs addressing is allowing no summary. MickMacNee (talk) 18:16, 13 May 2008 (UTC)

   But under this proposal, the edit summary could only be changed if it was the last edit made. It seems to me that most of the time what you are saying would not happen. Plus, I think someone proposed that admins would be able to view the previous edit summaries. -- Imperator3733 (talk) 14:42, 14 May 2008 (UTC)

3. Resounding oppose - toooooooo much potential, hardly any benefit, causes some damage (yeah, I know...), if people want to retract an edit they can always do a null edit afterwards. —TreasuryTag—t—c 18:56, 13 May 2008 (UTC)
4. This seems to offer little actual improvement to the editing experience to offset the major disruptions it could cause to the process of dispute resolution, vandalism fighting, etc. --Gwguffey (talk) 19:46, 13 May 2008 (UTC)
5. Strong Oppose. We have enough problems with vandalism without creating a route for "edit summary vandalism". – ukexpat (talk) 15:22, 14 May 2008 (UTC)

   If the editing is limited to the last edit during a relatively short timespan I do not see the potential for vandalism or disruption as any subsequent edit (e.g. fixing vandalism) makes a summary permanent. Cacycle (talk) 03:57, 15 May 2008 (UTC)

6. Highly doubt this would ever actually happen, but here's my two cents anyway. I agree it's annoying when you accidentally make a stupid grammar or spelling error in an edit summary, yeah it can be embarrassing etc, but guess what, it happens to all of us and it isn't important, so just deal with it. Also, as someone points out above, summaries are used as evidence in disputes -- so the ability to edit them would add a certain kind of recursive complication. Similar to the fact that edit summaries are required when editing a page, edit summaries would probably be needed when editing edit summaries as well -- it is, after all, the ability to change evidence, so an explanation for the edit would be needed, not to mention a history of previous versions.... seems to be getting silly then, right? You bet. This would only cause problems and, trust me on this one -- it's just not happening. No developer in their right mind would ever add this kind of superfluous functionality. Equazcion •✗/C • 04:16, 15 May 2008 (UTC)
7. Per above. ES are have document character here. If we make then editable we need a history/permalik feature for them as well. This will not happen. Don't waste your time fussing about it. The benefits are marginal. Everyone makes typos sometime, just suck it up. --Dschwen 17:09, 15 May 2008 (UTC)

Neutral

• As a number of people mentioned above, this could be difficult in implementation and perhaps more importantly could have wider implications. My suggestion would be a special kind of 'change edit summary' edit. This would function much like the above (only possible with most recent edit by the person who made the edit and perhaps some sort of time limit as well) except instead of actually changing the edit summary, it simply makes an automatically completely null edit with summary and marks the previous edit summary as 'obsoleted' or something of that sort (similar to minor edits and bot edits). By default, these obsoleted edit summaries will be hidden but editors can obviously chose to view them if they so desire. My suggestion would be to extend this to edits as well. (It will always be completely optional.) This way, editors who e.g. don't preview or otherwise make several edits in quick succession can choose to hide the intervening edits if they desire to make it easier for other editors to browse the edit history (but as I mentioned other editors can still view the intervening edits if they want). A time limit will probably be important in this case to avoid editors who think they're funny and vandalise or cause other problems and then hide it a few hours later to try and obscure what they're doing, and also to avoid encouraging editors to edit when they are in a foul mood thinking they can hide anything bad they did later. Potentially this should be added as an autoconfirmed option or even a rollback option to discourage misuse further. Nil Einne (talk) 06:50, 1 May 2008 (UTC)

  Under the restrictions we are currently talking about (last plus own edit for a short time) I do not see the potential for abuse (after all, any following edit to the page makes the previous summary permanent). Therefore, I do not think that we need a history for this. A simple link on the history page that lets you change the summary entry of that edit would do it. We probably want to restrict this to registered users, but I do not think that we would need further restrictions. Сасусlе 21:46, 1 May 2008 (UTC)

• While I'm still roughly neutral on whether an editor should be able to edit their own edit summaries (I can see both points of view, but haven't personally decided yet), I don't think admins should be able to edit "anyone's". Yes, talk page comments may be edited, but only under certain situations. (And I've seen enough successive revertings by admins of such edits, to be concerned.) And we really don't need to see the creation of reversion histories of edit summaries. So opening this door would seem to be a bad idea. And there's no real "need", since admins can always delete the revision in question. (And which can also be undeleted. And already has a set of logs.) If it's deemed truly necessary, just add this ability to the oversight "package". - jc37 20:17, 6 May 2008 (UTC)

Please participate in the discussion of the "official feature request" for this under https://bugzilla.wikimedia.org/show_bug.cgi?id=13937. Cacycle 19:16, 3 May 2008 (UTC)

Page move speed restriction

I believe there has been an increase in page move vandalism recently by sockpuppets (it could also be my imagination) and I remember a user (one account) who moved in excess of 40 pages before being blocked. This was mainly due to the speed that they are able to move pages and the fact that it requires an admin to properly clean-up afterwards means the damage can be significant. I therefore propose that there be a restriction on page move speed (e.g. no more than 10 in 5 minutes). I understand that this would inconvenience some users who wish to move lots of similarly badly-titled articles etc. but the benefits outweigh the inconveniences in my opinion. GDonato (talk) 18:34, 29 April 2008 (UTC)

Good idea if the software can be modified to accomplish this, though I'd suggest a limit of one move per minute. Obviously admins should not be subject to this limit. -- John Broughton (♫♫) 19:09, 29 April 2008 (UTC)

I would support this as well (though it would have to be 2/min, article & talk). Mr.Z-man 19:13, 29 April 2008 (UTC)

Bad idea. Some (maybe even most) valid page moves require multiple moves in order to be complete. The original page, the talk page, archives, perhaps some redirects -- A single move can mean multiple actual pages need to be moved, and the next time I have to do that, I don't want to have to do part of them and then remember to come back ten minutes later to do the next part. What we need here is a better way for editors to revert bad moves, rather than more restrictions. Equazcion •✗/C • 19:16, 29 Apr 2008 (UTC)

Or that, but I can't see how it is possible. GDonato (talk) 21:06, 29 April 2008 (UTC)

The 10 moves in 5 minutes idea sounds good. That should be enough to do most moves without having to wait. Of course, admins should not be subject to this. -- Imperator3733 (talk) 20:42, 12 May 2008 (UTC)

Straw poll

Just to get an idea of whether anybody actually wants any changes and, if so, what they should be. Please feel free to sign under the heading which you believe would be the best solution to the page move vandalism "problem". GDonato (talk) 20:35, 5 May 2008 (UTC)

Increase autoconfirm

Please see Wikipedia:Autoconfirmed Proposal/Poll.

A class

Isn't it about time that we have a process to find, review and select A-class articles much in the line of WP:FAC and WP:GAN? Aditya^{(talk • contribs)} 04:23, 1 May 2008 (UTC)

Not really, no. And not just to stop the assessment creep either. A-class is part of a separate, wikiproject-specific assessment process, and has mostly been superceded by the GA process. If anything, A-class should be deprecated, since the only practical difference between GA and A is that A-class articles are reviewed by someone from the project rather than someone from GAN, and usually if your article is under the scope of one of the larger projects, the guy who's doing your GA reviews is a project member anyway. --erachima talk 07:07, 1 May 2008 (UTC)

Don't you find it funny that FA grade articles have guidelines and a dedicated process and so does GAs, but A class articles don't have any? Wikipedia:Version 1.0 Editorial Team/Index shows that A-class articles come between FAs and GAs on the quality scale. If it stands that way, omitting A-class articles from the system is not resisting that "creep", rather its more like just that, an omission. But, if the quality scale is revised and nothing comes between the FAs and GAs, then the problem is solved, and only the top two grades will go through processes. Otherwise, it isn't working. We have a total of 3840 GAs and 2292 FAs, but only 961 A-class articles. Many articles lie only in the periphery of WikiProjects, many WikiPorjects have no A-class review process, and many other WikiProjects don't have enough participants to do such review. A simple dismissal like the above is not helping the situation. Aditya^{(talk • contribs)} 10:36, 1 May 2008 (UTC)

Creating an A-Class assessment process would create more problems than it would solve (seeing as it would solve 0 problems):

• If people take part in it, it will add to the red tape required for an article to reach FA.
• If people don't take part in it because they want to save time reaching FA, it is a waste of space, time and effort.
• Your comparison of article counts from different classes show that this process would not be following user consensus.

The better solution is to remove A-class or place it below GA-class. That's what we did at Wikipedia:WikiProject Chemistry, and we're all happy clams. --Cryptic C62 · Talk 10:49, 1 May 2008 (UTC)

I agree; placing A-class below GA-class would remove a lot of confusion; and as it's mainly just a marker used by Wikiprojects it seems like that would make sense. Adding an A-class review, however, is just creep. Nihiltres^{t.l} 15:32, 1 May 2008 (UTC)

It would, indeed, be WP:CREEPy to have assessment and process for A-class; however, I can see value in A being between BA and FA; B-class is "working towards GA", and A-class is "working from GA towards FA", in each case the project suggesting that it's made distinct progress on that goal. SamBC(talk) 15:46, 1 May 2008 (UTC)

That would create an unnecessary (though solvable) technical problem, since most banners don't allow multiple article classes and A-class pages would then be both GAs and As. A simpler way of looking at the issue might be to consider GA and FA to be two levels of A-class. --erachima talk 00:33, 2 May 2008 (UTC)

When FA status is reached, the GA status is removed. I am not sure if declaring an article as FA (yes, without a process, one may just go on and declare it an A) would require a removal of the GA status. If it does, pity that a careful review and response may have been replaced with just a conviction. It is only logical to have articles go through stricter quality measures as it goes higher up on the ladder. Thus, a B-grade is assessed by any assessor within a project, an A-grade assessed by more people within the project (provided that there is system for that within the project, otherwise it's much like B, only higher in grade), a GA-grade is assessed by a dedicated process which mostly depend on a single reviewer, and, finally, an FA-grade that requires community participation and scrutiny. Having A-grades between GAs and FAs look much like a relapse in the ladder of incremental progress in quality assurance. That may be a bigger problem than creep, as already the lack of creep is producing a much lesser number of A-grad assessments. Aditya^{(talk • contribs)} 08:20, 2 May 2008 (UTC)

I have spent a lot of time assessing articles and what I feel is - A class is probably not necessary, GA and FA can very well be the top 2 classes. A GA article is already a good candidate for going into an FA drive, a separate article class is seldom necessary. However, what is really needed is: 2 classes between GA and start (currently there is only one class: B). If we accept that anything slightly more than a stub is a start class article, then there is really a long way to go from that point to GA. So, my recommendation is, either downgrade A class below GA or romove A class altogether and add a new class between B and GA. I agree with Aditya, as it is now the A-class is not making much sense. Arman ^(Talk) 08:32, 2 May 2008 (UTC)

The current system has much in its favour. Military History WikiProject is a good example of a strong wikiproject managing the assessments well across the ratings. GA is awarded through the process you mention. An A Class Military History review is managed in a similar way to a Peer Review: it is listed and comments from other editors welcomed. Consensus awards the A class (or not): basically saying "yes, this is better than GA, but not quite an FA". The comments, advice and suggestions offered in the process are invaluable pointers for anyone then working towards FA. I agree that it works well in a WikiProject setting; by using WikiProject members, an editor can tap into the specific expertise and experience relating to an article. It is not a "relapse in the ladder", but a slightly different approach (and not really "creep" but "review"). An article I am working on has recently had an A-Class review, which I considered a useful and encouraging step on my way to FAC. But I consider it a bonus gained from working within a field of a strong Project; it is certainly not a formal necessity. In other words, Wikipedia itself has formal GA and FA ratings. WikiProjects offer stub, start, B, A grades as part of their own management, review and encouragement processes. Secondly, we need not be concerned about the comparative rarity of A Class articles: it is likely that many editors considered it a stepping stone to FA. You might say that, having brought an article so far, and been recognised and encouraged for it, editors are motivated to take it all the way. Gwinva (talk) 08:57, 2 May 2008 (UTC)

Yes, I have come into contact with the Military History project, and it's brilliant. I have also come in contact with the Aviation project where Biman Bangladesh Airlines waited an eternity for an A-review, and that not happening it was submitted to FA and it breezed through. This happens even to a strong project like that. With plenty Wikiprojects that are not as strong the process works even less, and many doesn't even have the process at all. For the Militray History project, it may not be a relapse, but for most other projects it indeed is. A quality assessment higher than can not be laid at the mercy of the strength of WikiProjects, which is, in a larger context, fickle at the best. I have this Sitakunda Upazila, a GA, waiting for a go at FAC, and I have absolutely no way of getting an A-review. I propose a quick visit through the projects before deciding if there is enough juice in the projects to have an A-grade assessed higher than a GA. Otherwise the proposition is extremely discriminatory. Some articles will have the good fortune to have the support of a strong WikiProject, and hence an A-review, and other articles that are less fortunate will never have the support. Why do you think the number of A-grades are significantly lower than either FAs or GAs? Aditya^{(talk • contribs)} 11:11, 2 May 2008 (UTC)

Beginning fresh

In light of this discussion looking at the possibility of putting GA icons on top of articles like the FA icon, I have come to believe that it is even more important to address the issue of the barely functional A-grading of articles. Let me restate the proposal.

Problems first

• A-grading is a prerogative of WikiProjects, but many of these projects don't have a A-review process in place, while many others don't have enough active and experienced editors to keep the process running.
• Without a process A-grading wither becomes arbitrary, or there in no A-grading at all. Naturally, we have a total of 3840 GAs and 2292 FAs, but only 961 A-class articles (three-day old stats here, but much hasn't changed since).
• There are community-wide processes for GAs (including WP:GAN, WP:GAR, WP:GACR, WP:GAPQ and WP:WPGA) and FAs (including WP:FAC, WP:FAR, WP:FARC, WP:FACR and FA directors), but no such thing for A-grading.
• As the quality ladder takes articles through stricter quality measures as they go higher — stubs and starts often graded by creators of the articles, starts and B-grades mostly graded by experienced assessors within WikiProjects, GA assessed by a set of predetermined and elaborate quality guidelines and dedicated reviewers who are open to dispute through a proper process, and FAs measured by community consensus as well as community collaboration.
• On this quality ladder A-grading is much like a relapse in strictness of measurement, as the article falls back from wider community processes to smaller project community process, if there's one, or nothing at all.
• The current system is also discriminatory to articles that are not a part of a strong WikiProjects and, therefore, to editors who have worked on those articles. Quality in no way can have membership of a strong WikiProject as a prerequisite.

Observations next

• There may be a chance that B-grades are seen as a stepping stone to GA and A-grades as a stepping stone from GA to FA. In this case B-grades are the top articles short of processed measurement, but A-grades become kind of ephemeral beings.
• There may be a chance that a lot many people don't believe in the A-grade or take is a waste of time. Therefore, they go directly from GA to FAC. This would be natural, because A-grades don't have as much a semblance of proper review as a GA or an FA.
• There may also be a chance that installing a process for A-grading would be an show of "process creep" and, therefore, would not be very acceptable. But, if we are exchanging a desire for quality with a fear of process then I guess much is lost.

Finally propositions

• Reduce A-grading down, so A-articles are assessed as lower grade than GAs. That way the scale would be B (single assessor) > A (WikiProject community assessment, if any) > GA (elaborate process assessment) > FA (community consensus).
• Install a proper process for A-grading that is acceptable as a step between a GA and an FA. So that, if it comes to that, A-icons can be shown on top of articles as well as FA-icons or GA-icons.There's no need to keep this alternative around anymore. Aditya^{(talk • contribs)} 15:36, 4 May 2008 (UTC)

I am personally in favor of the former proposition, as it also addresses the fear of the creep. Please, comment. Aditya^{(talk • contribs)} 03:45, 4 May 2008 (UTC)

I agree very much with the idea of moving A below GA and FA; your analysis of the move from low-level involvement relations to wide community scrutiny makes a lot of sense. I still don't see, however, why we should institute some special review process - what does it add besides creep? Within a WikiProject, it makes sense to have a rating system that the WikiProject's focused group can use, but outside of that it seems like wasted effort. There isn't much use in flagging articles as "pretty good" except to focus work on them, and so I don't see the point of an in-between universal process. GA was originally conceived as a lighter-weight rating for decent, usable articles that weren't yet FAs. Do we really need another such duplicate system with yet lower ratings? (By the way, some of this isn't just my opinion, it's also to test the proposal via devil's advocate). Nihiltres^{t.l} 04:22, 4 May 2008 (UTC)

See oppose#54 from the GA poll, where John Carter says "There is currently a proposal to revise the article assessment structure at Wikipedia talk:Version 1.0 Editorial Team/Assessment#Overhaul and rewrite of the assessment scheme ..." and more. (just above this section: Wikipedia talk:Good articles#Neutral) -- Quiddity (talk) 06:07, 4 May 2008 (UTC)

Thanks, especially for the links provided, though cherry picking one opposition out of the whole discussion or emphasizing the neutral views over support or oppose views. I wouldn't also emphasize too much on the necessity of a new process for A-grading, at least as long as it is possible to evaluate A-grades as lower than GAs (one WikiProject already does that). I also see that a lot of problems identified here would match with the questions raised at the assessment overhaul discussion. As I understand, there has been a tremendous improvement in quality measurements around Wikipedia since the old assessment scheme was devised. A lot of recent GAs may be much higher in quality than a lot of older FAs, and the A-grading has fallen much out of use. By the way, just to clarify, I am not planning to propose any discussion on what else could be put on top of articles beside the FA-icon. All I see is the current awkwardness in the position, use and quality measurement of A-grading, and not necessarily in that order (this WikiProject dependent process doesn't even feature in the system of many WikiProjects). We don't need to support creep, but we don't have to continue a scheme that isn't helping. Aditya^{(talk • contribs)} 15:32, 4 May 2008 (UTC)

I only just noticed this discussion (thanks Arman!), as I've been pretty busy recently. Some good points raised here. I personally don't mind if A is ranked as equal to or even below GA. For the article selection bot, we rank A and GA as worth the same. The original discussion is here, but at that time GA was very new and the quality was very variable, plus there was an emphasis on "short but good" articles.

This issue is not as simple as suggested above, though. Please read my earlier post on this issue. This is why the debate of "above or below GA" isn't so important to me. I accept the criticism that peer review for A-Class doesn't work well at most WikiProjects; perhaps we should recommend that such projects either not use A-Class, or they only promote an article after at least two project members agree on the A (perhaps via a regular talk page)?

We are about to start rewriting the entire assessment descriptions, and hopefully to supply the more detailed guidelines Aditya has asked for! If you'd like to help, please sign up here. Thanks, Walkerma (talk) 02:41, 8 May 2008 (UTC)

The discussion there looks to be much more elaborate and, yes, the problem does not have as simple a solution I imagined. But, it's not too complicated either, and given a little effort things could improve much beyond the current hotchpotch. Aditya^{(talk • contribs)} 14:04, 8 May 2008 (UTC)

The problem in my view is that GA and A both are steps in evolving from B towards FA. They are different, parallel paths. Where GA takes the article from the project and subjects it to a Wikipedia broad assessment, A class subjects the article to a detailed, within project, mulitple editor review process. In the light of the path to FA I would rather remove A-class and replace it with a mandatory peer-review prior to submitting to FAC. Placing A between B and GA will definitely lower the standards for A as I have seen many GA's which would not pass A pocedure (and vice versa); which in turn will likely lower B-class standards. As there are many 100's of article assessors out there, for the sake of consistency and maintainability of the system I would prefer fewer, rather than more levels. Arnoutf (talk) 17:21, 10 May 2008 (UTC)

Two parallel system of assessment? That would be really tough, confusing, and incoherent to some extent. It is always a lot simpler to have one straight path to the top. On top of that, I believe, WikiProjects are here to help the broader community, not the other way round, at least not explicitly. WikiProject assessments should not, ideally, supersede or transcend a community-wide system like Wikipedia:Version 1.0 Editorial Team/Assessment or something. My, this assessment thingy is tricky. Aditya^{(talk • contribs)} 18:10, 10 May 2008 (UTC)

• Lots of comments here:
  • First, you are right-on when you say that A-Class articles are essentially ephemeral. They were, indeed, initially advertised as "articles that are ready for FAC, but need to be nominated or checked just a little bit", if I recall correctly. So, indeed, these ratings don't stay long, because when an editor has taken the time to get an article to A-Class, chances are it will get FA status sooner or later.
  • The A-Class rating is indeed skipped several times on the path to FA, just like GA is. That's really an editor preference.
  • There are several projects with active A-Class assessment projects, so shifting the ranking to be under GA would severely disrupt the assessment operations of those projects.
  • The SSBA scale, unlike GA and FA, were not meant to be public grades of the article's quality. Instead, they're more akin to checklists of the quality of articles. GA and FA are there only to provide general anchor points to the WP:1.0-scale.
• In brief, the three points you present are not really bugs, they're features. A-Class was meant to be a lightweight checkmark. You are also right that there is an increasing demand on the scale to have a rating between Start-Class and GA. I've heard suggestions to move the A-Class rating, but I'm strongly opposed to that, as it would disrupt the operations of the larger projects, and also would remove the "almost ready for FA" bucket that the A-Class rating was originally meant to accomplish. So, what would be better is to introduce a new class between GA and Start.
• One more thing: We're having this discussion in like three different places. Can we try to contain the ForestFire and continue in just one place? Titoxd^{(?!? - cool stuff)} 06:26, 11 May 2008 (UTC)

Moving the Main Page

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.

---

• Since this seems to have little or no support, I'm closing this in the interest of eventually getting it off this page. Equazcion •✗/C • 20:15, 13 May 2008 (UTC)

I realize this has been discussed about 30 times before, but it's been a while, and there's no real reason to not discuss it again.

Proposed: We move the Main Page to Portal:Main Page.

It is one of the few pages that is still in the article namespace that is clearly not an article. Obviously Main Page would remain a redirect to Portal:Main Page. And the sidebar and logo could be easily updated to link to the correct location.

Thoughts? --MZMcBride (talk) 01:28, 3 May 2008 (UTC)

No.--Urban Rose 02:42, 3 May 2008 (UTC)

Yes. MBisanz ^talk

The main reason is that thousands of sites link to http://en.wikipedia.org/wiki/Main_Page so unless someone wants to create a page called "Main Page" it wouldn't be best to move the main page and delete the redirect (I'm assuming the redirect would be deleted, as redirects to project pages in the article namespace generally aren't allowed). When someone actually has reason to create "Main Page", we'll worry about it then. If it really bothers you, then you could start a band named Main Page and become famous.--Urban Rose 03:35, 3 May 2008 (UTC)

Or, there's always Main Page (movie). *Dan T.* (talk) 14:08, 3 May 2008 (UTC)

I would argue that the Main Page is grandfathered with regards to title; if it's an issue with it appearing as part of the main namespace, perhaps a technical change can be made to fix that – indeed, already there are technical differences: the tab reads "main page" instead of "article". "Portal:Main Page" just sounds awkward. Nihiltres^{t.l} 15:11, 3 May 2008 (UTC)

Edit: After checking, no, that tab text is changed by JavaScript. As an additional argument, I should point out that "Portal:Main_Page" is worded redundantly. Nihiltres^{t.l} 16:12, 3 May 2008 (UTC)

No. There is no reason to perform this move. Nakon 15:47, 3 May 2008 (UTC)

I don't think this is likely to improve the usefulness of Wikipedia to its consumers. Christopher Parham (talk) 20:43, 3 May 2008 (UTC)

I would prefer Wikipedia:Front Page. Aside from the more friendly name, this would be good for three reasons:

1. No JavaScript required to fix the "article" tab to read "main page". The tab would simply read "project page".
2. It would be easier for downstream users to separate article content from project content.
3. If we ever needed to make an article at Main Page in the future, the backwards compatibility impact would not be so great because we would already have made the change a long time ago.

We would of course keep a redirect at Main Page unless we needed that space for an article. —Remember the dot ^(talk) 23:50, 3 May 2008 (UTC)

I appreciate the rationale behind the proposal, but I don't find it sufficiently convincing for such a change. Sorry. - Neparis (talk) 01:07, 4 May 2008 (UTC)

Prescriptivist reasoning with no pragmatic basis. Has multiple problems which have much more serious implications, both pragmatic and on-principle. — Werdna talk 13:05, 5 May 2008 (UTC)

I don't think this is worth doing, considering the drama and waste of time that would come as a result of it. dihydrogen monoxide (H₂O) 10:19, 6 May 2008 (UTC)

To restate what's already been said above repeatedly in different words, the only reason to worry about this is some abstract semantic inconsistency. There's no practical benefit. The resulting title would actually be less user-friendly. Newbies and casual surfers who don't know about namespace differences wouldn't care or appreciate the change, at best. At worst, it would confuse people. Equazcion •✗/C • 10:25, 6 May 2008 (UTC)

Although I have to say I like Remember the dot's suggestion. "Wikipedia:Front Page" seems just as intuitive as "Main Page" while also being more technically accurate. It also seems somehow more pleasing to the eye than the current name. It seems to exude more competence, if that makes any sense. Equazcion •✗/C • 10:33, 6 May 2008 (UTC)

The one reason why we would want to do this is consistency with other portals, which is a tiny advantage, and as pointed out it could cause many problems. Not worth it. Hut 8.5 18:47, 7 May 2008 (UTC)

• Resounding oppose - historical; everyone will understand the discrepancy. —TreasuryTag—t—c 18:59, 13 May 2008 (UTC)

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

Shadowing Template

I've been experimenting with a shadowing template I created and decided to test it in my Main Page sandbox. Please check it out and give me feedback. ~RayLast ^«Talk!» 02:42, 4 May 2008 (UTC)

Looks neat, but I think the multiple shades look odd. I think just the last, lightest box alone would give a more believable drop-shadow effect. Drop-shadow filters in image editing programs, for example, generally just add the one layer alone. Equazcion •✗/C • 07:06, 4 May 2008 (UTC)

Looks neat, trying to figure out how I'd use it, but yea it is a cool thing. MBisanz ^talk 11:26, 4 May 2008 (UTC)

I agree with Equazcion that the multiple shades look wrong. It is simpler to use one single shade. If you are going to use several shades you should not stack them diagonally like you did, instead you should stack smaller and smaller variants over the same centre to achieve a real looking shadow with toned borders.

--David Göthberg (talk) 13:10, 4 May 2008 (UTC)

I know what you mean. The template has the capability to be used for lighter shadow as well as diminishing the shadow spread which would minimize the effect you mention. With your suggestions I'm planning to add another variable like "simple = true" or something that would only display one shade instead of multiple. As per your comment David, I completely agree with you, but I'm still on the concept side of the development of the template. To create a more realistic effect I would use the same diagonal technique I used but with a lot more shades allowing for a lot less positioning shift from the previous shade since I like drop shadows and not perspective ones. Doing it over the same centre would create kind of a perspective shadow. ~RayLast ^«Talk!» 17:00, 4 May 2008 (UTC)

OK I just added the single shade option using the "simple=true" parameter. Is this what you meant? ~RayLast ^«Talk!» 17:53, 10 May 2008 (UTC)

Possible "Did you mean " feature

Hello, When you type something into wikipedia and mispell it slighty the relavent page does not come up. But if you do the same on google it says " Did you mean.....". I was wondering how hard it would be to integrate a similar feature onto wikipedia. Could you plesae reply on my talk page or notify me on my talk page if you have replied. Thanks Bit Lordy (talk) 21:04, 4 May 2008 (UTC)

This has been proposed before (by me, among other people), and the response is usually that such a feature would be too much of a performance burden. I've disagreed with that response repeatedly, and wish we could try out something like this. Wikipedia is way behind in the site searching technology department. Nearly every other prominent site that features a site search function is light-years ahead of us. Equazcion •✗/C • 21:39, 4 May 2008 (UTC)

Can't we introduce this on a small trial basis on Wikitionary or something? Can we put this to a vote? If theres enough Consensus then they will find it hard to turn down. What do you think? Bit Lordy (talk) 21:43, 4 May 2008 (UTC)

I don't think we can decide things regarding Wiktionary from here. And I don't think a vote would be beneficial here. This should be a discussion by people who know about the technology and can offer educated guesses as to how it would work and what the performance cost would be. I do think a new discussion on this would be a good idea though. Welcoming any comments. Equazcion •✗/C • 21:58, 4 May 2008 (UTC)

It's not just a performance burden, it's also a difficult thing to do if you want it to give decent suggestions. --Carnildo (talk) 02:28, 5 May 2008 (UTC)

I think redirects and disambiguation pages work just fine for this purpose. If a redirect doesn't exist for a specific phrase, make one. If a redirect doesn't exist for a typo, learn how to type. --Cryptic C62 · Talk 00:21, 5 May 2008 (UTC)

Funny how for some reason all those other sites don't tell their users to "learn how to type". We must know something they all don't. Or maybe we're just better than them, or expect more from our users. Perhaps we're just very choosy about just who we want to accommodate here -- we wouldn't want just any idiot to be able to use the site. People who don't know how to spell something should really go and check the proper spelling using some other tool prior to searching here. Who needs user-friendliness? That's not our responsibility. Users should just get smarter. This is all sarcasm of course, cause "learn to type" was a ridiculous response. Again, other sites have this feature for a reason. It makes the site easier to use. That's reason enough to want it for ourselves. And if it isn't purely the performance issue that's keeping us from doing it, but rather that the feature is a challenge to construct, then let's roll up our sleeves and rise to it. Equazcion •✗/C • 03:50, 5 May 2008 (UTC)

Users should get smarter. That is the purpose of Wikipedia (or of any encyclopedia), right? Let's take our bold goal of free education a step further: let's couple the vast amount of information available on Wikipedia with some classical conditioning. When you type poorly, you don't get what you want. When you type well, you do get what you want. This forces the user to get better at typing. Sounds like a nice educational program to me. That's not to say we would expect users to already know how to spell everything. That's what redirects are for. User-friendliness is only valuable up to a point. Pass that point, and you're training people to be stupid. I think user-friendliness is at a good level right now. --Cryptic C62 · Talk 20:24, 8 May 2008 (UTC)

You are more than welcome to submit a patch for this feature. It will be reviewed for its performance impact on the site, code quality, and so on. See How to become a MediaWiki hacker for details. — Werdna talk 13:01, 5 May 2008 (UTC)

Thanks, but this is a proposed change to the site for discussion. Even if I were a developer capable of creating this feature on my own, I wouldn't even start putting in the effort until the proposal gained consensus here. And, we have developers for that sort of thing, so if consensus here is that it would be a benefit to the site, they could take over from there and implement it, as is usually the case for such proposed features. Equazcion •✗/C • 16:58, 5 May 2008 (UTC)

The vast majority of technical changes are implemented without any sort of community consensus or announcement. If you plan on waiting for the few paid developers we have to do this because people ask for it (most of the developers are volunteers, who work on whatever they feel like) you may be waiting for a while. Mr.Z-man 17:23, 5 May 2008 (UTC)

I'm aware of SUL. I created persistent proposals because of it. That's neither here nor there. As with any proposal, we should first decide whether or not it should be done, then worry about actually doing it. That's what this page is for -- proposing and discussing changes. We don't tell people who post here "Well go and make it yourself, then get back to us", so I'm not sure where the sudden attitude problem is coming from. Let's have an actual discussion, thanks much. Equazcion •✗/C • 17:42, 5 May 2008 (UTC)

I guess what I was trying to say was, I really don't see this as a controversial change in any way. If someone can code something that won't have a significant impact on performance, I don't see it as being the type of thing that the sysadmins would require a community consensus on every project to turn on, like the AJAX based search suggestions that were just added recently. Mr.Z-man 17:48, 5 May 2008 (UTC)

When it's been brought up before it was controversial. Also, the point of this page is also to demonstrate interest in a proposed feature. If there is enough demonstrated interest, that would serve as motivation for people (designated developers and others alike) to try and create the feature. A discussion of the feature, its possible benefits, and a simple demonstrated interest by as many people as possible is instrumental in getting a change implemented. At least three people here have so far expressed the feeling that this would be a beneficial addition to the site. Great. Keep them coming. If I could write something myself and bring it to the table I would, but I just don't have the programming ability. Hopefully with enough demonstrated interest, someone who does will take notice.

In other words, you seem to be saying this is a non-controversial change. If it's just a matter of getting someone to create it, then let's do whatever we can towards that end. Equazcion •✗/C • 17:57, 5 May 2008 (UTC)

I think this is a great idea. Can someone please implement this???? It would save so much time correcting little typos.Numpty454 (talk) 18:48, 5 May 2008 (UTC)

I'm all for anything that will improve Wikipedia's terrible search function. I too have mispelled things by one letter or something and it comes up with some other results at the bottom which are completely unrelated, but it doesn't come up with the thing I might have mispelled. In fact, sometimes you can have better luck looking up Wikipedia pages on Google than on Wikipedia itself! Please, please, PLEASE do something to drastically improve Wikipedia's search tool. .:Alex:. 18:54, 5 May 2008 (UTC)

See WP:PEREN. This feature exists but is disabled on English Wikipedia for performance reasons - it's not that this would be fundamentally impractical, but that the current implementation does not scale to a wiki this large. Dcoetzee 21:19, 5 May 2008 (UTC)

That's all very well but can't we find a solution to implement it to a large Wiki? I mean if Google the largest serach engine in the world can do it surely the largest Wiki can too :) Bit Lordy (talk) 21:33, 5 May 2008 (UTC)

Exactly. I'm not sure why this should be given up on just because the existing feature wasn't made for a site this large. If IMDb and especially Google can do it, I think we should be able to find a way, and what's more I think it should be a priority. Equazcion •✗/C • 21:36, 5 May 2008 (UTC)

I agree - it's a matter of finding someone who knows Mediawiki and the approximate query research to do an implementation. I could do this myself, actually, but need to find a bit of time first. Dcoetzee 06:36, 6 May 2008 (UTC)

I think one of the biggest flaws in wikipedia is it has articles on pretty much every subject but it doesn't take into account human error. For example if you spell a word incorrectly it doesnt recognise it as a mistake and come up with a "did you mean"? message like google does; the best you can hope for is a re-direct which in 9 out of 10 cases don't come up. I propose we implement a did you mean thing when displaying search results with obvious spelling errors --Hadseys 12:46, 8 May 2008 (UTC)

Support this change - it is becoming more and more common on other sites, and is very useful to users. I have repeatedly noticed its absence (due to my own poor typing!) Dhollm (talk) 22:13, 12 May 2008 (UTC)

Automatic linking whenever possible

I just did my first Deletion review, and as I noted there apparently the Deletion review doesn't drop automatically drop a note on the relevant AfD. That would be convenient for people looking at the AfD later, but even more convenient is that it would let people who are still watching the AfD know about the Deletion review. I think that, whenever possible, we should automatically link relevant things together. Previous AfDs should be automatically linked to later AfDs, previous RfAs should be linked to subsequent RfAs, ect. ImperfectlyInformed | {talk - contribs} 03:07, 6 May 2008 (UTC)

^Agree completely. The fact that people watching the deletion discussion aren't notified that it ended up at DRV is a problem. A link should be automatically generated and placed in the XfD. Equazcion •✗/C • 03:12, 6 May 2008 (UTC)

"Imperfectly informed"... Tell me about it. :-)

I also agree; there is a need for good information flow. There should be a certain degree of standardisation, I suppose... A dedicated section in each page, perhaps, to be added only in the event of further action on a deletion. I don't know the deletion pages that well, but I've seen templates used in some cases; however, template proliferation should be avoided. Any ideas? Waltham, The Duke of 22:26, 6 May 2008 (UTC)

There's a template to link to previous deletion discussions. I don't think I've ever seen one linking to deletion reviews once a deletion ends up there. Perhaps we just need to create a template, then people would use it. Equazcion •✗/C • 00:19, 7 May 2008 (UTC)

See Wikipedia_talk:Deletion_review#Change_to_DRV_instructions. Equazcion •✗/C • 07:09, 7 May 2008 (UTC)

When there's a renewed deletion attempt of something that previously survived XfD, the new XfD should include a link to the old one(s) (though this isn't always done); but, to spread the notice more widely, the old, archived XfD should be edited to include a link to the new one. In fact, I'm inclined to say that anyone reopening a previous discussion, whether through a new XfD or a DRV, should be required to drop a note on the talk page of every editor who expressed a contrary opinion in the earlier discussion. A prior decision shouldn't be overturned just because the people whose views prevailed then didn't happen to know about the new discussion. JamesMLane t c 15:08, 8 May 2008 (UTC)

I agree with that. Magioladitis put something on my talk page about Wikipedia:Articles for deletion/Emily Sullivan, which otherwise I would most likely not have known about. Thanks Magioladitis! That should be a required step for new XfDs -- Imperator3733 (talk) 14:51, 14 May 2008 (UTC)

Downloadable spreadsheets on Wikipedia

It would be extremely nice if a lot of the data presented on Wikipedia was downloadable. Specifically, every table in Wikipedia should be downloadable (perhaps csv format). I don't know if this is possible right now, but if it is, it's not quite as simple as I think it should be. It should be a click of a button in a the corner of the table. ImperfectlyInformed | {talk - contribs} 04:22, 6 May 2008 (UTC)

You could convert wikitables to CSVs pretty easily. Just do a text replace, replacing "|" with "," and "|-" with line break. For tables with style formatting there'll be a bit more to remove. It shouldn't be difficult to whip up a script for this though, for someone who's good with scripts (not me unfortunately). Equazcion •✗/C • 05:10, 6 May 2008 (UTC)

... and non-nested tables can be simply copy-pasted into your favorite spreadsheet app. -- Fullstop (talk) 06:02, 6 May 2008 (UTC)

What do you mean by non-nested? When is HTML not nested? I've been using computers intensively for 8 years or so and I still don't know what you're talking about. Clearly this isn't user-friendly. I haven't encountered a table yet that I can copy/paste. The point is that it should be simple enough for your average WP user, and they shouldn't have to do a time-consuming text-replace. There's lots of publicly available data that we could host, which would be extremely handy for students and researchers. I don't understand the resistance something so simple and obviously helpful. ImperfectlyInformed | {talk - contribs} 06:33, 6 May 2008 (UTC)

I think what Fullstop means by non-nested is that Wikitables have the ability to have tables-within-tables, and that's not something that spreadsheet programs are capable of producing. This isn't exactly resistance you're experiencing; you might see such a feature as obviously useful but I'm not sure how many people agree with you. If this discussion attracts more comments by users who agree with you then then I'm sure it will be given its due attention. Just be patient. Equazcion •✗/C • 06:49, 6 May 2008 (UTC)

yep. "non-nested tables" means tables that don't have yet other tables inside them. Not only can't these be copy-pasted, such tables also cannot be represented in CSV, and as Equazcion notes, spreadsheet apps can't deal with them either. Ditto tables that use colspan= or rowspan=. -- Fullstop (talk) 02:18, 7 May 2008 (UTC)

header 1	header 2	header 3
row 1, cell 1	row 1, cell 2	row 1, cell 3
row 2, cell 1	row 2, cell 2	row 2, cell 3

copy-pastes fine into excel for me - You have to start the mouse-drag outside the table for it to paste properly though. --Random832 (contribs) 17:36, 6 May 2008 (UTC)

Still doesn't paste into Excel for me. Strange. Using Firefox. And I did try to start the mouse-drag outside the table. ImperfectlyInformed | {talk - contribs} 07:06, 8 May 2008 (UTC)

I want korean language warning templates!

I am a korean wikipedian. I use en-2.

In ko: wiki, I edit 10,000s and I use ko: wiki for 3 years. I edit en: wiki "sometimes" :)

User talk:WonRyong/Archive1#Replaceable fair use Image:Park_Geun-hye.jpg

In my talk page, above template warnig is there. many.

but, I don't know what means.

because, when I read english, I translate and understand. but that warning is too long. I can't understand what mean it.

so, I sugesst korean translate warnig templates!

Example: http://commons.wikimedia.org/wiki/Template:PD-old

I click "한국어(korean)", and I can easily understand what mean.

PLEASE!!! MAKE IT!!! :( -- WonRyong (talk) 12:02, 6 May 2008 (UTC)

Please keep in mind that I'm active on many, many foreign language wikis. However, to put it bluntly, this is the English Wikipedia, not the Korean. The only projects that I'd expect to have multi-language versions would be Commons, Meta, and Wikispecies, as they are language-independent projects. We have enough trouble getting people to translate everything for those projects; to expect each template to be translated for every other language is a bit optimistic. EVula // talk // ☯ // 14:27, 6 May 2008 (UTC)

I think what WonRyong is suggesting is that boilerplate warnings link to the Template in question, i.e. where the interwiki links would/could/should appear. At least, that is what I think he/she is suggesting. -- Fullstop (talk) 02:27, 7 May 2008 (UTC)

I considered that, but the various Wikipedias have very different policies, making such interwiki linking largely useless from the user's perspective. For example, while we have fairly strict rules about Fair Use images, we at least allow them here. On the Spanish Wikipedia, there are no images; it has to come from Commons or there's nothing, so a Spanish speaker receiving a warning here would be totally lost if looking on their home project for the equivalent (and it's ridiculous to expect all the projects to document every other project's policies not to mention the nightmare of keeping them all in sync). If a user was given an image warning here, the target language that they speak may not have anything for them, or might give them totally contrary advice. Not only that, but internal links wouldn't work; even in cases of similar policies between projects, the instructions would still likely be somewhat different, and again becomes a sprawling amount of effort for everyone to document everyone else.

Trust me, my attitude about using only English on this Wikipedia is not an opinion I generated lightly or off the cuff. I've gone on record as saying that, if a user can't actually contribute in a language, they shouldn't make the attempt. This is not because I'm a jerk (not saying that I'm not one) but because of the logistical nightmare of every project trying to support every language. Each language should support its own language and nothing else. EVula // talk // ☯ // 14:37, 7 May 2008 (UTC)

I think the original matter here has been more or less agreed upon (interwikis/foreign language texts in messages are not appropriate), but the fact that this person who appears to have a decent grasp of English can't understand the message in question would seem to indicate that it's badly written and difficult to understand. Is there any scope for making the boilerplate "Replaceable fair use" talk page message simpler and easier to understand? Lankiveil ^{(speak to me)} 12:43, 12 May 2008 (UTC).

English wikipedia is not for only native english people.

English wikipedia is not for only en-3 or en-4 people.

So many en-1, en-2 people use English wikipedia. Becuase many information is here.

I suggest...hmmm...

For en-1, en-2 users, make other languages' warning templates, please.

English wikipedia is not meta. English wikipedia is not commons.

But, in some respects, English wikipedia is meta. English wikipedia is commons. -- WonRyong (talk) 12:55, 12 May 2008 (UTC)

Method to protect your user and talk page from "quicky" vandals

About three years ago I recall asking if there was anyway to block a vandal or persistent stalker from posting to your user or user talk page. However, by accident I have recently discovered a way to do just that - at least in terms of a "quicky" vandal who is unwilling or unable to go to the extra trouble it takes to find your user or user talk page and cause trouble. The method is simply to use a different name (such as your real first name) in your raw signature line. The solution is that simple. Thanks. --Taxa 13:48, 6 May 2008 (UTC)

And what about editors that have a legitimate need to contact you? EVula // talk // ☯ // 14:15, 6 May 2008 (UTC)

It can still be done but not as quickly. --Taxa 17:04, 6 May 2008 (UTC) —Preceding unsigned comment added by Taxa (talk • contribs)

This post resulted from me asking Taxa to include a link to their user or user talk page in their sig, per WP:SIG. I agree with EVula; we shouldn't put obstacles like this in the way of legitimate editors in order to make things harder for a few vandals. — Matt Eason ^{(Talk &#149; Contribs)} 14:47, 6 May 2008 (UTC)

Its not a major obstacle and besides the sinebot usually corrects the missing link in a relatively short amount of time. No one should be so disparate to contact you that they can not wait for the sinebot to appear. --Taxa 17:06, 6 May 2008 (UTC) —Preceding unsigned comment added by Taxa (talk • contribs)

SineBot is not a replacement for normal user signature, it was designed for those who do not know how or forgot to sign. Besides, you admit yourself that SineBot makes your "method" ineffective anyway. Please fix your signature. —AlexSm 17:31, 6 May 2008 (UTC)

This method is also unlikely to have much effect: I find that vandals usually find my userpage (which is semi-and-move-protected) and my talk page (which is move-protected) through my contributions which are reversions of their vandalism. As one's signature does not appear on the contributions page, but instead links to one's userpage, this anti-vandal method is not very effective, either. If you're worried about vandalism to your userpage, request that it be semi-protected at WP:RPP. Nihiltres^{t.l} 15:15, 6 May 2008 (UTC)

In addition to what EVula and Matt said, not linking to either your user or talk page is a clear violation of WP:SIG, which states "at least one of those two pages must be linked from your signature." --Kralizec! (talk) 17:18, 6 May 2008 (UTC)

I concur, there must be some link to your user-space in your signature and you must use your signature regularly when editing. MBisanz ^talk 19:26, 6 May 2008 (UTC)

Apart from all these, I should like to draw attention to the lightness of Taxa's signature; many editors will have a hard time reading it, and the lack of a link does not help things in the least. Waltham, The Duke of 19:49, 6 May 2008 (UTC)

• I propose that it is a requirement of WP:SIG that every user signature must contain a link to one's userspace; it must be a clear link and not concealed in any way. —TreasuryTag—t—c 18:47, 13 May 2008 (UTC)
• See also Wikipedia talk:Signatures#Proposed new section from March (and Wikipedia talk:Signatures/Archive 6#What to do if someone doesn't seem to want a signature? and Wikipedia talk:Signatures/Archive 6#No links in a signature). At least we don't have a problem with images anymore! -- Quiddity (talk) 01:58, 15 May 2008 (UTC)

wrong interwiki link is not red

Hi,

I made a kind of silly typo, in other language wiki. It looks something like ('(' and ')' are used instead of '[' and ']' to prevent link here)

((:en:exiting page)) instead of ((:en"existing page))

However, on preview, the interwiki link (on left side, which reads "English" was not red, so I did not notice. (so it went out. and when clicked new page for edit pops out)

Is it possible to make it red?

Thank you very much. AIEA (talk) 16:30, 7 May 2008 (UTC)

This totally makes sense. Red interwiki links would help to identify typos and when articles are deleted in other languages. Interwikis can be accurate without having to rely entirely upon bots. --Cryptic C62 · Talk 19:33, 7 May 2008 (UTC)

While red links for bad interwiki links would be useful, it's probably not trivial to implement. When Wikipedia software builds a page for display, it checks (internal) wikilinks in order to mark them for the browser to display. What is being suggested here is that the software needs to go outside of en.wikipedia.org in order to determine validity. Yes, all Wikipedias run on the same set of servers - but each uses a different instance of the software, including a different database. So now information is going to have to be fetched via an API or other database call - en.wikipedia.org needs to ask (say) fr.wikipedia.org if a given page exists or not. -- John Broughton (♫♫) 21:33, 7 May 2008 (UTC)

How would that be any more difficult than simply checking if the page's edit box has any text in it? Or checking the revision history to see if there are any entries? I'm not much of a programmer, but I can't imagine it would be that difficult to implement. And if it were, so what? John F. Kennedy would want to try it. :) --Cryptic C62 · Talk 21:38, 7 May 2008 (UTC)

I can see how – if not implemented very carefully and thoughtfully – such checks could be quite (computationally) costly. Articles on major topics can have more than a hundred outgoing interlanguage links (see, for example, the city of London). Checking all of those outgoing links every time the article is edited, previewed, or read could cause some very serious issues. As John notes, en.wikipedia would have to send queries to dozens of other wikipedia instances and wait for replies from all of them.

It would be a nice feature to have. Getting it to work in a test instance would be pretty easy. Implementing it in a way that doesn't hammer the servers is hard. TenOfAllTrades(talk) 19:41, 14 May 2008 (UTC)

I also found that broken interwikilink is not red either. ie not red is not red, and if you click this link, the page you get is what red link would show in Italian one. It may not be easy for programmers to fix, but it is not straightforward to users to follow link either.AIEA (talk) 15:14, 8 May 2008 (UTC)

Support, though it's not the highest priority. --Amir E. Aharoni (talk) 18:31, 14 May 2008 (UTC)

Promote WP:WWII to its own Wikiproject

Many of you might know about the articles relating to World War II, their importance and varied quality. In fact, the main article on World War II, the beginning of the modern era, is only a B class article despite the slew of excellent sources out there to use. Presently, the only project working on these articles is a task force with enough members for its own Wikiproject. A topic of such importance deserves more attention, don't you think?  Marlith (Talk)  03:23, 8 May 2008 (UTC)

Try Wikipedia:WikiProject Council/Proposals. Equazcion •✗/C • 07:20, 8 May 2008 (UTC)

Actually, all the sub-areas of military history were converted to task forces in order to minimize the administrative overhead of maintaining fifty different projects, enabling their members to concentrate more attention on article work. I don't think splitting things back out will be beneficial to anyone; certainly, it won't help the WWII article directly, since there will be fewer people available to look at it, not more. Kirill ^(prof) 13:03, 8 May 2008 (UTC)

Two thoughts. First, articles like World War II will always have quality problems because they are plagued by ad-hoc drive-by contributions of little or no value. The higher the profile and the greater the scope of an article the greater the diificulties in getting consensus and so forth. Second, I agree entirely with Kirill: wikiprojects need a good critical mass to handle the wikignoming required for tracking article progress, assessment, updating templates, etc and the bigger the umbrella structure the better, with task forces operating within it with a great degree of autonomy. --ROGER DAVIES ^talk 14:15, 8 May 2008 (UTC)

Maybe it's just me, but I fail to see why, if a "task force with enough members for its own WikiProject" isn't making enough progress on what needs to be done, that simply retitling it is going to make that much difference. It certainly would require more administrative effort, that's clear. -- John Broughton (♫♫) 15:40, 8 May 2008 (UTC)

Apologies, my mistake.  Marlith (Talk)  00:01, 9 May 2008 (UTC)

We should rename Verifiability to Credibility

The much-cited "verifiability" policy is a misnomer. What's important is not so much that the citations are verifiable (especially immediately -- we use print sources) but rather that they are credible. If we keep using verifiable in a way that it doesn't mean, we'll keep having confusion. Ultimately we may even distort the meaning of the word itself. I've raised the issue at the Verifiability talk page. ImperfectlyInformed | {talk - contribs} 07:10, 8 May 2008 (UTC)

Verifiability doesn't refer to the sources but to the information in our articles. That information needs to be verifiable, via sources. You could create a "credible sources" redirect to WP:Reliable sources, as that is a synonym in that case. Equazcion •✗/C • 07:19, 8 May 2008 (UTC)

You're missing the point. If you have a non-fictitious source, that source is automatically verifiable. There's no need to emphasize that point, and indeed the page does not emphasize verifiability. It says nothing about verifiability (the ability to check up on a source). And, in fact, we allow sources which are rather difficult to verify, such as past print newspaper articles. ImperfectlyInformed | {talk - contribs} 15:54, 8 May 2008 (UTC)

And again, you're missing the point. "verifiable" doesn't describe the source, but the content of the Wikipedia article. If an article says "The sky is blue", that information needs to be verifiable. Verifiable means the fact can be found in an outside source. The sources themselves, though, are not what we're describing via verifiability. We don't make our editors verify what's said in reliable sources. We pretty much assume it's the truth. Equazcion •✗/C • 16:01, 8 May 2008 (UTC)

Why should we even emphasize verifiability? Why don't we just say that the content should be sourced? Verifiability introduces confusion; its repetitive and unnecessary. ImperfectlyInformed | {talk - contribs} 08:10, 11 May 2008 (UTC)

It's not repetitive. Verifiable is just our way of saying sourced. They're one in the same, for our purposes. Equazcion •✗/C • 13:28, 11 May 2008 (UTC)

Did you mean?

I think in case of spelling errors and such wikipedia should have a search system like googles which provides a did you mean to write this word instead. At the moment wikipedia's searching procedures arent very good at taking spelling mistakes into account --Hadseys 12:57, 8 May 2008 (UTC)

See Wikipedia:Perennial proposals#Search should detect spelling errors. And please note that it's good to check the editor's index before making a proposal - sometimes it has relevant information. -- John Broughton (♫♫) 15:46, 8 May 2008 (UTC)

And see the very same proposal further up on this page. Equazcion •✗/C • 16:04, 8 May 2008 (UTC)

Requiring some time before uploading ability

I would like to suggest that, like the move feature, we require some time before people are allowed to upload images. I find it quite common to see people who are simply using Wikipedia as their personal image storage place. Besides, there is no reason for someone's first edit to be an image upload. -- Ricky81682 (talk) 00:16, 9 May 2008 (UTC)

This would also greatly reduce the number of problematic images uploaded. The statistics I've seen are a year or so out of date, but something like 50% of all deleted images were uploaded by people who aren't autoconfirmed. --Carnildo (talk) 00:34, 9 May 2008 (UTC)

Don't I know it. Sometimes it's simply a technical issue. -- Ricky81682 (talk) 00:39, 9 May 2008 (UTC)

Support, this would make it much more difficult for fools to upload vandalistic images and copyright violations. GO-PCHS-NJROTC (talk) 01:56, 9 May 2008 (UTC)

Perhaps something has changed, or there is incorrect information at Wikipedia:User access levels, or I'm misreading it, because it seems to say that an editor must be autoconfirmed in order to upload an image. Your statistics may not reflect that.

That doesn't mean (at the moment) that an editor's first action can't be to upload - it just means that the account needs to be at least four days old, so that it becomes autoconfirmed; then the editor can start uploading. And if that seems like a good argument for adding an edit requirement in order to become autoconfirmed, and/or lengthening the amount of time until autoconfirmation, then you might want to express your opinion at Wikipedia:Autoconfirmed Proposal/Poll‎. -- John Broughton (♫♫) 02:03, 9 May 2008 (UTC)

I'd support adding an edit requirement for autoconfirmation. I'm thinking something in the low double-digit range, like 10-15 edits, although that might be a bit low. -- Imperator3733 (talk) 17:21, 12 May 2008 (UTC)

Wikipedia:Noindexing Talk Spaces

This is a proposal by WilyD, which I think has a lot of merit, in terms of not putting things on Google that really don't belong there. Please comment at Wikipedia talk:Noindexing Talk Spaces. Thanks.--Pharos (talk) 00:39, 9 May 2008 (UTC)

Advanced search function

Most websites with a search feature have an advanced search, where it is possible to very easily narrow down a search. Why not create such a function on Wikipedia? GO-PCHS-NJROTC (talk) 01:53, 9 May 2008 (UTC)

Could you be more specific as to what you mean by "narrow down" a search. At the moment, for example, it's possible to narrow a search by namespace. Is there something more that you're looking for? (Again, please be specific.) -- John Broughton (♫♫) 01:59, 9 May 2008 (UTC)

I agree, our search page is a bit low on advanced features. I think that's the first shortcoming to Wikipedia that I ever noticed. Just take a look at basically any advanced search page on any other prominent site, a search engine site, even a forum site. We could have an advanced search page with word include and exclude fields, category options, etc, not to mention a better format for our field of namespace options. As I've said before, we're way behind in the search technology field. Equazcion •✗/C • 13:38, 11 May 2008 (UTC)

Add contributions total number

If I click my contributions:

http://en.wikipedia.org/wiki/Special:Contributions/WonRyong

I see at the top of the article:

User contributions

From Wikipedia, the free encyclopedia

For WonRyong (Talk | Block log | Logs)

I suggest some more.

User contributions

From Wikipedia, the free encyclopedia

For WonRyong (Talk | Block log | Logs)

This account is created 2005-12-11 22:25

First edit 2005-12-11 23:27:17

This user's total edits: 798

How about this idea? -- WonRyong (talk) 14:29, 9 May 2008 (UTC)

You can see your total edits by going to Special:Preferences. The date your email was confirmed also appears on this page, but no one can see the page but you. You can see when your account was created by clicking on "logs" on your contributions screen, selecting "User creation log" from the pulldown, and pressing "Go" (acounts created more than a few years ago are older than the log, so they won't appear). You can see your first edit by pressing "Earliest" in your contributions page, and scrolling to the bottom of the screen. I think it would be a good idea to add these last two pieces of information to the Preferences page, but they aren't necessary directly on the Contributions page. — Preceding unsigned comment added by Gadfium (talk • contribs) 20:21, May 9, 2008 (UTC)

I bet that all of that information (excepting account creation date, for example my account was created before that log existed) could be retrieved using the API and some creative JavaScript. Just a random thought. Nihiltres^{t.l} 01:43, 10 May 2008 (UTC)

Account creation date is public too. :) -- Fullstop (talk) 23:54, 10 May 2008 (UTC)

Editcounters like wannabekate and the like do exactly what you are describing. Anyone can look up this information using offsite tools like that. --Jayron32.talk.contribs 23:59, 10 May 2008 (UTC)

Except that we don't want spread that serious disease. -- Fullstop (talk) 00:07, 11 May 2008 (UTC)

Making an Ambox like thing for the Wikipedia namespace

Well, I see that *box fever has swept the Wikipedia nation over the past few months, the easier and more efficient way to make nice message boxes. But, the Wikipedia namespace doesn't use something like that. I think we should just kinda make a metatemplate for the Wikipedia namespace that uses Ambox, but DOES NOT take on the usual appearance of an Ambox at the same time. Like, it could be made to emulate the usual message box styles used for that namespace, but at the same time, be on a more powerful and consistant platform.

So, anyone thing we should have Wmbox or Wpbox or something like that? ViperSnake151 22:39, 9 May 2008 (UTC)

While I agree that in the long run it would be nice to have a "{{wmbox}}", for now let's focus on {{imbox}} and {{cmbox}}. Once those are in active use, we can move on to other namespaces. Nihiltres^{t.l} 01:30, 10 May 2008 (UTC)

Actually, we are running out of namespaces... Portals and MediaWiki pages don't have message boxes, and Help pages have very few, if any. Apart from Project, that leaves us with... (counts in fingers) ...Template and User. Not much work to do there, am I right? Waltham, The Duke of 05:50, 10 May 2008 (UTC)

Hmmm, standardized user boxes would be nice. Maybe {{usbox}}? I think {{tempbox}} would just be ridiculous. Paragon12321 (talk) 16:05, 10 May 2008 (UTC)

That would be {{userbox}} and {{Userbox-2}}. --— Gadget850 (Ed) ^talk - 17:40, 10 May 2008 (UTC)

Make traffic numbers public

We should be able to see the traffic to each page. Further, there should be some articles devoted to categorizing and listing the pages with the most traffic. If you can suggest a personal hack to do this, cool, but that doesn't distract from the point: I want this built into WP in a simple, obvious manner. This would be useful because some of us don't want people to be misinformed. Thus the pages which have a lot of traffic could be monitored more closely. ImperfectlyInformed | {talk - contribs} 21:23, 10 May 2008 (UTC)

Please see Wikipedia article traffic statistics. -- Wavelength (talk) 21:36, 10 May 2008 (UTC)

Ah, cool. Still would be nice to see these integrated into WP itself. ImperfectlyInformed | {talk - contribs} 22:43, 10 May 2008 (UTC)

It's a common suggestion. Unfortunately, having pageview statistics on the pages themselves would interfere with how Wikipedia survives the load of two billion pageviews a day. --Carnildo (talk) 22:54, 10 May 2008 (UTC)

I'm an old-timer. If I recall correctly, I think we had this functionality back in 2003 or 2002. It was disabled due to the heavy traffic noted by Carnildo. So, the solution is "donate"! -- Taku (talk) 23:02, 10 May 2008 (UTC)

Nice sentiment, but donations unfortunately won't cut it either. What Carnildo was presumably referring to is the fact that the caches can't cache if the page changes with every page view (or would be terribly inefficient even if they just synchronized page-hit-count). -- Fullstop (talk) 00:00, 11 May 2008 (UTC)

As long as the numbers aren't on the pages themselves, but on a separate statistics page, the cache issues wouldn't be a problem. --Tango (talk) 00:09, 11 May 2008 (UTC)

the separate statistics page is here (updated daily). -- Fullstop (talk) 05:12, 11 May 2008 (UTC)

FOR INTERWIKI BOT

I have a interwiki bot.

Wikipedia:...

Thease article's interwiki is too difficult.

Many errors! :(

So, I do not interwiki those.

I suggest.

Make Template:..., Wikipedia:... edit rules for interwiki bots.

Make worldwide rules.

For example,

http://en.wikipedia.org/wiki/Wikipedia:Changing_username

Where is interwiki?

Bot's task is error.

Make worldwide rules for interwiki bots!! -- WonRyong (talk) 00:21, 11 May 2008 (UTC)

Is the redirect retard really necessary?

To the best of my limited knowledge, Wikipedia doesn't include redirects for derogatory terms that are linked to the subjects they are describing, and creating such redirects seems to be interpreted is the equivalent of attacking said subjects. There was a user who redirected the page Turd burglar (UK slang for a gay person I believe) to gay and they were severly reprimanded for this, so I'm not sure it the redirect I pointed out should stay. I propose deleting it.--Urban Rose 02:33, 11 May 2008 (UTC)

Well... why would it be deleted, aside from the fact that it's potentially offensive? "Retard", regardless of whether anyone liked it or not, is a term for the mentally retarded, and redirects such as that are there to help people find what it means. See also Wikipedia:Redirects for discussion/Log/2007 December 17#Retard, Retards, Retarded, Mental retard, Mentally Retard, Half-wit, Half-Wit, 'tard, Tard, Tardster, Imbecile, Imbecility, Imbeciles → Mental retardation, though you are certainly welcome to submit another request for deletion. EVula // talk // ☯ // 02:53, 11 May 2008 (UTC)

Though before you do submit another request for deletion, you may want to read arguments to avoid in deletion discussions, which includes arguments based on the existence/deletion of similar pages. Mr.Z-man 05:12, 11 May 2008 (UTC)

New Project

I know you guys probrably get loads of requests for projects, but shouldn't we have a welcome team? For example, wikiHow do, Wikipedia FR have a few users who welcome you and give some good links to start you off. Thanks -- ♦ { Crimson } ♦ Talk • Contributions 16:03, 11 May 2008 (UTC)

We already have the Welcoming Committee, if that's the sort of thing you're thinking of? RichardΩ612 Ɣ |ɸ 16:29, May 11, 2008 (UTC)

Thanks ♦ { Crimson } ♦ Talk • Contributions 16:44, 11 May 2008 (UTC)

Wikipedia logo improvement

Why does the German Wikipedia logo look so much better than ours? Can we do whatever they did? Notice their smooth anti-aliasing and lack of any white edge around the globe, despite the transparency. Any thoughts?

Equazcion •✗/C • 17:39, 11 May 2008 (UTC)

Even better, would be to fix the errors in the logo.

The last mention was Brion's message in June 2007: http://lists.wikimedia.org/pipermail/foundation-l/2007-June/030972.html

The listings at these 2 pages, Wikipedia:Wikipedia logos#The current logo and meta:Logo#Current logos, claim we're using different (fixed) logos, Image:Wikipedia-logo-en-big.png and Image:Wikipedia-logo.png, from the one we actually are using.

From a glance at commons:Category:Wikipedia logos, about 1/5 of the Wikipedias are using an updated/fixed logo:

Everything else I could find (back in Jan 2007) is listed at: User talk:Ambuj.Saxena/Wikipedia-logo#All the related discussion links

I emailed all this to Brion about 3 weeks ago, but he didn't respond. I was going to wait another week, before emailing someone else, but since you've brought it up... :)

Anyone know what's going on, or where/who to ask? -- Quiddity (talk) 18:30, 11 May 2008 (UTC)

Well I doubt there is any one person in control of the logo, I'd imagine any admin can change it. I defiantly agree with its replacement, I say just use the exact image that our German counterpart is using, bar the German tag line of course... ☯Ferdia O'Brien ^(T)/_(C) 19:07, 11 May 2008 (UTC)

On some wikis the logo can be changed by admins at Image:Wiki.png, but that isn't enabled here. A request on Bugzilla could get it changed. Mr.Z-man 22:35, 11 May 2008 (UTC)

This has long been suggested but there's been no activity and has turned largely into a farce. Someone needs to take the initiative and get the mistakes in the logo fixed and the ugly transparency problems and get them included. -Halo (talk) 18:22, 12 May 2008 (UTC)

I support switching to the improved logo along with fixing all the logo errors. -- penubag  (talk) 01:31, 13 May 2008 (UTC)

Yes, the German style is better. Hut 8.5 19:24, 14 May 2008 (UTC)

Much better, in my opinion. Waltham, The Duke of 03:06, 15 May 2008 (UTC)

• See bugzilla:14137. If someone knows the exact locations of the logos in use at both English and German Wikipedias, I can composite the image myself and upload it. Equazcion •✗/C • 14:08, 15 May 2008 (UTC)

  http://en.wikipedia.org/images/wiki-en.png and http://upload.wikimedia.org/wikipedia/de/b/bc/Wiki.png Dragons flight (talk) 14:22, 15 May 2008 (UTC)

  Thanks, I'll post again when it's uploaded. Equazcion •✗/C • 14:24, 15 May 2008 (UTC)

  Oops, please note I corrected the DE link above. Apparently dewiki is configured to draw their logo from a location other than the default. Dragons flight (talk) 14:27, 15 May 2008 (UTC)

  Thanks again. One more question: Anyone have any idea which fonts were used for the banner? I can fix the globe easily by copying the German one, but the English text has aliasing problems and I obviously can't copy the German text. Equazcion •✗/C • 14:46, 15 May 2008 (UTC)

  PS I just need to know which one was used for "The Free Encyclopedia". "WikipediA" itself can be copied from the German logo as well. Equazcion •✗/C • 14:47, 15 May 2008 (UTC)

  Nevermind, found it. Equazcion •✗/C • 14:54, 15 May 2008 (UTC)

New logo

Let me know what you think. This is Image:WikiNewSample.png, a sample showing the new image, Image:WikiNew.png, against our background. See Image:WikiNew.png for the actual new logo with transparent background. According to the Bugzilla response, when we're ready, the image needs to be uploaded to Image:Wiki.png, then full protect the image description page again, then re-open the bugzilla ticket. Equazcion •✗/C • 15:49, 15 May 2008 (UTC)

• Looks much better. Go for it. Can't be letting the Germans out-do us! xenocidic ( talk ¿ review ) 16:20, 15 May 2008 (UTC)
• This is so obviously an improvement I see no particular point in waiting. Dragons flight (talk) 16:30, 15 May 2008 (UTC)
• Support changing the logo. Obvious improvement due to the removal of the rather unprofessional white lip. J Milburn (talk) 16:51, 15 May 2008 (UTC)
• Definitely support I don't even know if this is controversial. I mean, it's not like we're changing the logo, it's just a higher quality version than we had before. J.delanoy^gabs_adds 16:58, 15 May 2008 (UTC)

• I honestly can't see the difference. And does it make a difference? Who stares at the logo for hours deciding how transparent the barely visible back layer of colouring is? NIN (talk) 17:58, 15 May 2008 (UTC)

• So...weak support? The difference is pretty apparent to me, now that it's been pointed out. xenocidic ( talk ¿ review ) 18:01, 15 May 2008 (UTC)

• The difference is subtle, but on a site as prominent as ours, subtle imperfections come across as unprofessional. This would also vastly improve the appearance of user pages that have custom background image placed under the logo, such as User talk:LaraLove. I know that's not the most important thing to consider, but it is an added benefit. Equazcion •✗/C • 18:06, 15 May 2008 (UTC)

• i like the crisper look of the old logo. The new one looks too soft. Maybe something inbetween? --Dschwen 18:15, 15 May 2008 (UTC)

• The new logo is a vast improvement. I definitely support this change. hmwithτ 18:24, 15 May 2008 (UTC)
• We need approval to fix ugly graphics errors? Just do it. Lawrence Cohen § t/e 18:28, 15 May 2008 (UTC)

Wikipedia Toolbar

As some might already be aware, I suggested this a while ago, and when no one was interested I made it myself.

Now, keep in mind as you read this, that presently, this toolbar, well, sort of sucks. It's the first Firefox extension I've ever attempted to write, and I didn't have the inclination to really delve deep into the various possibilities. So while I think it's pretty useful, it's really still quite basic, no-frills, and essentially it boils down to some shortcuts that I sought to make for my own use.

Nevertheless, less than 4 months later, the download count reads 600, and that's just at the extension's Mozilla page.

To give you an idea of the significance of that number:

• If you'll read WP:WPTB, the Mozilla page is actually considered a secondary download site. People who find the toolbar via its Wikepedia page are strongly advised to download from a different external site, the downloads from which I have no way of keep count of. So the 600 count likely doesn't include those who found the extension here.

• Also, the extension is currently not in Mozilla's main public listing. Right now, it's in what they call the "sandbox", where just about anyone can upload just about any extension, and most of them don't get much attention. As far as I can see, the number of downloads this is getting is astronomical in comparison to other non-public extensions.

In the past, I think the mention of a Wikipedia toolbar made people cringe, because they think of crappy ad-campaign toolbars like Google and Yahoo. Had I heard the suggestion I might've thought the same myself. However I'd attest now that a toolbar doesn't need to be something that takes over the user's computer. It can instead be a real asset, especially to WP junkies who spend entirely too much time here (such as myself). My goal here is now to get some more interest going in development of this, perhaps even by Wikipedia's developers. There's only so much I can do here myself, and I think it's a shame that a tool with so much interest and potential has to be so limited.

The fact that this toolbar, in its admittedly very basic form, currently averages over 60 downloads a week, just at the secondary site (and that's a number that's been climbing steadily for as long as I can remember) should surely tell us that this is something worth serious consideration. I'm reasonably certain that a well-written tool could help get more people involved in the project, get more of the casual users to be more involved, and not to mention, make work easier for our current regulars. Equazcion •✗/C • 12:10, 12 May 2008 (UTC)

Excellent idea.! Fully supported :) FT2 ^{(Talk | email)} 16:23, 15 May 2008 (UTC)

raw signature example

I propose that an example of the raw signature such as: <small>--<font face="rage italic" size="4.5" color="LightSteelBlue"> [[User:taxa|Taxa]]</font> ([[User talk:taxa|talk]])</small> be included on the my preferences page. -- Taxa (talk) 15:16, 12 May 2008 (UTC)

Oppose. We should not encourage obnoxious signatures, especially ones using the deprecated font-tags. --Dschwen 16:41, 12 May 2008 (UTC)

Oppose per Dschwen. Signatures such as those suggested above are extremely ugly, non-standards compliant and should be discouraged rather than encouraged. -Halo (talk) 18:20, 12 May 2008 (UTC)

Oppose - Agreed, those signatures truly do suck :) Equazcion •✗/C • 18:23, 12 May 2008 (UTC)

Seriously though, I do oppose encouraging newbies to experiment with funky signatures. That would get annoying very quickly. I'd rather they wait and discover that ability on their own, when they'll likely have a better feel for what's acceptable on talk pages. Equazcion •✗/C • 18:23, 12 May 2008 (UTC)

Oppose I wouldn't be opposed to a better explanation of what a raw signature is, but that example is... no, not good. EVula // talk // ☯ // 18:34, 12 May 2008 (UTC)

Oppose. There are better places to experiment with HTML tags. Elaborate, complex signatures are usually harmful to Wikipedia — they make it more difficult to contribute to discussions, especially threaded discussions, because of the markup clutter they introduce. An editor in this discussion will notice that Equazcion's signature above is larger (266 characters!) than either of his comments. While it is by no means the only criterion by which I judge, I do take large, elaborate signatures as one sign that the editors in question care more about their own preening than about the convenience of their fellow editors. TenOfAllTrades(talk) 03:49, 15 May 2008 (UTC)

I don't care so much about my own preening as I do about showing everyone how much better I am than they are. Equazcion •✗/C • 03:53, 15 May 2008 (UTC)

Twinkle

I really think we need to remove twinkle from gadgets. When it was in monobooks of users, we were able to remove it when problems arose. Now, we're stuck with the only option of blocking a user when it is misused. I have heard that protecting the monobook works to remove twinkle from the gadgets, but I'm not completely sure on this.

I don't think every user here can be trusted to use twinkle constructively, and as it's easy to install in your monobook, being able to remove the tool from a users monobook is one last safety net. Ryan Postlethwaite 17:47, 12 May 2008 (UTC)

When specifically would taking away Twinkle from someone be warranted while blocking wasn't? It seems to me that inappropriate or disruptive edits made using Twinkle can be handled the same way any other type of inappropriate edit would be; Warn a few times then block if necessary. Equazcion •✗/C • 17:52, 12 May 2008 (UTC)

Blocks should be preventative rather than punative. We had the perfect protective measure before, which was being able to remove it rather than block. Having to block an otherwise good faith contributor is silly when we have better options. Ryan Postlethwaite 17:58, 12 May 2008 (UTC)

If the editor is good-faith, then you must mean they're misusing Twinkle inadvertently. Couldn't they just be told, then, how to properly use it, or barring that, to lay off its features or even disable it in their preferences temporarily? Equazcion •✗/C • 18:01, 12 May 2008 (UTC)

Some people just don't learn, but a block is too harsh, especially, as I've already stated, when we have much better methods. I don't know who thought up the idea of putting it in gadgets, but they didn't really consider much when they did. Ryan Postlethwaite 18:04, 12 May 2008 (UTC)

And if/when they don't... then we're forced to block them? That's a less-than-elegant solution. EVula // talk // ☯ // 18:06, 12 May 2008 (UTC)

I will always support removing Twinkle from the Gadgets. The last thing we need is to allow newbies to make mistakes faster, easier, and more efficiently. EVula // talk // ☯ // 18:06, 12 May 2008 (UTC)

← (ec) Perhaps, but I'm sure we could conceive of a way to disable it per-user even though it's not in monobook.js. I see how you may have experienced trouble due to it, but looking at the larger picture, my concern is that it probably does much more good than harm having it more widely available. Equazcion •✗/C • 18:08, 12 May 2008 (UTC)

See Wikipedia:Administrators' noticeboard/Archive142#Vandal_making_use_of_Twinkle. --— Gadget850 (Ed) ^talk - 18:10, 12 May 2008 (UTC)

I don't want to see the ability to arbitrarily change someone's preferences; that's a somewhat scary thought. What I'd much rather see, however, is for Gadgets not to be implemented without substantial discussion. Call me crazy, but that strikes me as a better (and easier) solution. EVula // talk // ☯ // 18:32, 12 May 2008 (UTC)

Mmmm... I wasn't suggesting anyone be able to change just any preference, just gadgets. If an admin can change your monobook.js, is that all that different? I'm not sure why one is scary and the other isn't. For the future, public discussion regarding new gadgets is certainly required, but removing Twinkle now would mean disabling it for everyone who had it enabled, so I think that makes this a special situation. Equazcion •✗/C • 18:37, 12 May 2008 (UTC)

Well, aside from the fact that the ability to change someone else's gadgets (you are correct on the distinction, my bad; that is where a lot of my knee-jerk reaction came from) would require a substantial amount of technical mucking, there's still something a bit unsettling about it. Can't quite put my finger on it, but I still consider it totally different from editing a monobook.js file. EVula // talk // ☯ // 18:45, 12 May 2008 (UTC)

Please bear in mind that Twinkle only works for autoconfirmed users. I'll have to look into additional restrictions when I have time. —Remember the dot ^(talk) 18:41, 12 May 2008 (UTC)

Not to sound too draconian, but a user blacklist that automatically disabled Twinkle for anyone listed, regardless of their installation method, would satisfy my concern most of my concerns about a Gadget-installed Twinkle (I still have concerns about someone who doesn't know what they're doing installing the tool and going hog wild, whereas the manual installation adds a step to at least protect us from random "oh, what does this do?"; this would still be an acceptable mid-way point between the arguments). EVula // talk // ☯ // 18:51, 12 May 2008 (UTC)

That sounds like a good solution to me. Perhaps AzaToth might be willing to add that. Equazcion •✗/C • 18:48, 12 May 2008 (UTC)

Maybe another option that avoids keeping a central list of users with Twinkle disabled would be to allow setting a variable in monobook.js and have Twinkle refuse to run if that variable has been set. Tra (Talk) 19:24, 12 May 2008 (UTC)

That would require an admin to change the editor's monobook.js file and protect it. I like the central list idea better; in addition to the overall easiness, it centralizes all admin activity in regards to Twinkle abuse, which is a lot more transparent than having to modify every user's monobooj.js file. EVula // talk // ☯ // 19:34, 12 May 2008 (UTC)

A central list would be possible, but not scalable, and might make the devs cry, better then to hack gadgets instead. _→AzaToth 19:46, 12 May 2008 (UTC)

Not to mention slow most of the Twinkle functions down by loading the page every time you use it. Mr.Z-man 19:56, 12 May 2008 (UTC)

It would be possible to have Twinkle turn off if the user's monobook.js is protected, but we'd have to set up a fairly complex cookie system to prevent a significant performance burden. We could also restrict the Twinkle gadget to rollbackers. Or we could remove it entirely and go back to users having to manually add it. You decide. —Remember the dot ^(talk) 00:38, 13 May 2008 (UTC)

restricting twinkle to rollbackers would be a reasonable compromise and have the smallest impact on current users. Gnangarra 01:02, 13 May 2008 (UTC)

Autoconfirmed would be a better alternative -- penubag  (talk) 01:28, 13 May 2008 (UTC)

It's already restricted to autoconfirmed users. Equazcion •✗/C • 02:40, 13 May 2008 (UTC)

And it all comes back to raising the auto-confirmation threshold... :-D (See, Equazcion? It's not just moving...) Waltham, The Duke of 06:10, 13 May 2008 (UTC)

Yes, it's not just moving. That's the problem. As Penubag already suggested at the poll, an added confirmation level could apply to moves and things like Twinkle, while still allowing for a lesser requirement for semi-protected edits. But let's not fragment that discussion. Keep it at the subpage. Equazcion •✗/C • 08:56, 13 May 2008 (UTC)

• I don't get it. We didn't have a shortage of Twinkle users when it wasn't a gadget, and if making it a gadget causes problems, why do we keep it as a gadget? Titoxd^{(?!? - cool stuff)} 09:00, 13 May 2008 (UTC)
  • I'm not sure how you're assessing a "shortage" or lack thereof... Equazcion •✗/C • 09:02, 13 May 2008 (UTC)
    • Twinkle was widely available well before gadgets even existed, and it was well advertised in pages such as the WP:CUV portal and RC patrol. There were few reports, if any, of users having problems installing the script. Titoxd^{(?!? - cool stuff)} 09:05, 13 May 2008 (UTC)
      • Having it as a gadget makes it available to people who weren't necessarily aware of its existence. I know I hadn't even heard of it until well into my experience at Wikipedia -- surely well after I reached the point where I could've used it constructively. This makes it more widely available, and I think, helps people deal with vandalism etc. Again I know it's caused problems but I think the benefits outweigh the harm -- the harm being all we would really be made aware of. Equazcion •✗/C • 09:11, 13 May 2008 (UTC)
        • I guess I don't agree with that conclusion, as Twinkle was already widely available, without gadgets. But can't there be just installation instructions in Special:Preferences, instead of installing the script outright? That way, we get the best of both worlds. Titoxd^{(?!? - cool stuff)} 09:18, 13 May 2008 (UTC)
          • hehe, funny joke :) _→AzaToth 11:15, 13 May 2008 (UTC)

I for one support Twinkle being limited to rollbackers. That way, a user's rollback can be removed if an admin wishes to disable Twinkle, even if it's in use as a gadget. dihydrogen monoxide (H₂O) 11:22, 13 May 2008 (UTC)

Can you give multiple examples of misuses of Twinkle that justifies changing the requirements? -62.172.143.205 (talk) 13:51, 13 May 2008 (UTC)

Corey Worthington Article

Greetings, There is a BIG backstory behind this article. So have a read of this before commenting - please. The two basic reason behind the repeated deletions of the Corey Worthington article have been WP:ONEEVENT and (my personal opinion) the other main reason has been because of WP:IDONTLIKEIT. With his continued coverage in the media over the last few months not relating to the initial event that made him notable, I now believe that ONEEVENT has been well and truly satisfied. To this end, I have been working on the article in userspace but I would now like to promote it to mainspace to allow a broader editorbase to edit it. I have created two subheading below to attempt to contain different disputes about this topic as I am sure it will get into another heated debate - please try to place your comments in the correct one (I reserve the right to move them to the correct heading if they are misfiled) Fosnez (talk) 07:17, 14 May 2008 (UTC)

This is already been discussed at deletion review here which is where this should probably be discussed. Davewild (talk) 07:30, 14 May 2008 (UTC)

Ops... thanks for that. Fosnez (talk) 09:42, 14 May 2008 (UTC)

Is howto needed if there is guideline and help?

Let's look at the page WP:MOSLINK#Context. This is a guideline, it provides some rules. Now there is Help:Piped link which is a Wikipedia-specific version of m:Help:Piped link. These are Help pages, they explain technical details. Having these pages (guide + help) I'm starting to wonder... What is the possible reason to maintain yet another howto page at Wikipedia:Piped link? This is an instruction creep, pure and simple! Should be split and redirected. And this is just an example, there are some more Wikipedia:xxx pages that unnecessarily replicate Help:xxx pages (instead of redirecting to them). --Kubanczyk (talk) 13:32, 14 May 2008 (UTC)

For a respected editor, when seeing an off-topic discussion, he/she could probably post a link to an appropriate website to carry on the discussion -- once in a while. But a designated area for links like that is just asking for advertisements/spam, so it's not a good idea. Equazcion •✗/C • 15:01, 14 May 2008 (UTC)

Hmmm? What designated area? --Kubanczyk (talk) 16:57, 14 May 2008 (UTC)

guh...? Either I'm senile at 26 or I inadvertently replied to a thread that was removed from the page just before I clicked edit. In answer to your proposal, I think you're right -- experienced Wikipedians tend not to respect the help pages' value. Those pages in the Wikipedia: space that are more or less identical to a help page should probably be redirected, as long as they're instructions and not guidelines. Guidelines (even rules that haven't been tagged as guidelines or policies) should stay in Wikipedia: space, though. Equazcion •✗/C • 19:32, 14 May 2008 (UTC)

I think you were replying to #"Discussion Links", way up top. Algebraist 01:04, 15 May 2008 (UTC)

which had no business being there anyway. Rectified. Algebraist 01:07, 15 May 2008 (UTC)

Semantic categories

(moved to Wikipedia talk:Categorization. --Amir E. Aharoni (talk) 19:42, 14 May 2008 (UTC))

Lt. Micheal Moulton

I beleive that entry is needed for Lt. Micheal Moulton. He was a Revolutionary Soldier and Moulton, Alabama is named after him. He accompananied Gen. Andrew Jackson at the Battle of Horseshoe Bend. thank you. —Preceding unsigned comment added by 70.222.105.224 (talk) 00:54, 15 May 2008 (UTC)

Please make your suggestion at WP:RA. This isn't the right place. -- Kesh (talk)

"Discussion Links"

I've noticed that many users will use the discussion page of an article to debate the topic of the article, not the article itself. Instead of simply telling them not to discuss these things, give them a space on the page to put links to other website or chatrooms where they can discuss them. 168.216.176.35 (talk) 14:55, 14 May 2008 (UTC)

For a respected editor, when seeing an off-topic discussion, he/she could probably post a link to an appropriate website to carry on the discussion -- once in a while. But a designated area for links like that is just asking for advertisements/spam, so it's not a good idea. Equazcion •✗/C • 15:01, 14 May 2008 (UTC)

An idea for FC recognition

(Duped from here) So we've got stars at the top-right of individual FC items, but there's usually no way to tell if (say) an article's featured unless you go there. What if FC links appeared as a different color than blue, say, green? Since FC articles inevitably touch upon more than just their own subjects, greenlinks could help browsing by steering people to the best prospects for research. It'd also provide an additional reward for FC stuff in terms of added visibility. Thoughts? Cheers, Mdiamante (talk) 13:05, 15 May 2008 (UTC)

Non-admin rollbackers

The following discussion was moved from Wikipedia:Village pump (technical)#Non-admin rollbackers

I don't know if this has been/is being discussed somewhere else, or even if this is the correct place to post this, but I think that non-admin rollbackers should be allowed to make more than 5 rollbacks in a minute before being throttled. I think that they (OK, we) should be able to make at least 10 rollbacks (15 would be better) before being throttled.

Considering that rollback rights are not automatically assigned (as autoconfirmed rights are), I do not see any reason that we should be restricted so much. I use Huggle rather vigorously, and I would be able to be much more effective in my vandal-fighting (especially during high-volume times) if I was not slowed down by having to force Huggle to mimic the rollback feature for ⁵/₆ of the time after I use up my 5 rollbacks in 10 seconds. (which I do fairly frequently when vandalism is at its peak)

Also, I sometimes encounter someone who adds external links (pointing to pages in the same website) to many articles (think 15-25) before I realize what he/she is doing. I review their contribs in Huggle to ensure that they are all spam, and if they have not been warned previously, I usually give them either a level 2 or a level 3 warning, open their contribs, and click on the rollback links. It is incredibly annoying to only be able to do 5 rollbacks, and then having to click "undo" for the rest. J.delanoy^gabs_adds 02:04, 11 May 2008 (UTC)

I have to agree. I had the same problem when reverting someone who had spammed about 120 articles today. Even though I took a second or two to double check every single diff using popups, I still bumped on the limit several times. Rather frustrating and time consuming. —Ashanda (talk) 02:36, 11 May 2008 (UTC)

I haven't personally hit the limit but I agree that since there's approval to receive rollback it could probably be increased a bit. xenocidic (talk) 02:38, 11 May 2008 (UTC)

The throttle is set in the site configuration, but it is easy to change. You just need to point the developers the presence of the mythical beast of consensus. Titoxd^{(?!? - cool stuff)} 03:19, 11 May 2008 (UTC)

That's what I am hoping to get here... J.delanoy^gabs_adds 13:29, 11 May 2008 (UTC)

Doesn't seem like it should be much of a risk to increase the limit to, say, 25 or even 50 rollbacks per minute. Actually, I'm not sure it even really needs a limit at all; after all, the worst you could do with unlimited rollback would be to run a bot to rollback every page and every new edit as soon as it's made — and that would just get you blocked quickly and the rollbacks reverted. Yes, that would be a nuisance, but hardly a serious one. Probably about equal in overall annoyance level to a 5-minute database lock or thereabouts. —Ilmari Karonen (talk) 14:05, 11 May 2008 (UTC)

It sounds like double or tripling the limit would help editors, while posing minimal risk. Unless a case is made for a higher limit, I don't think we should go there; there is a clear downside, and - absent a demonstrated need - why go there? (So count this as a vote for doubling or tripling the current limit.) -- John Broughton (♫♫) 01:52, 13 May 2008 (UTC)

So, would 15 rollbacks per minute enjoy consensus? —Ilmari Karonen (talk) 19:15, 13 May 2008 (UTC)

I'd say so; the benefit is real, and the opposition is not. :) EVula // talk // ☯ // 20:02, 13 May 2008 (UTC)

Why on Earth do we even need a limit? We can just revoke it from someone who abuses it. _{1 != 2} 20:10, 13 May 2008 (UTC)

I agree that we don't need a limit on the number of reverts a minute: I don't see why it was necessary to include a limit in the first place. Rollback is very easy to remove if it's abused, and changing non-admin rollback from five reverts a minute to unlimited will be a major positive, in my opinion. Acalamari 20:32, 13 May 2008 (UTC)

I think the limit was placed when non-admin rollback was first introduced, as part of a compromise to those that were opposed to it. I'd be fine with the restriction's removal, now that we've established that granting rollback isn't the encyclopedia-destroying concept some may have been concerned it would be. As has been pointed out, abuse can easily be dealt with by any admin. EVula // talk // ☯ // 20:55, 13 May 2008 (UTC)

←OK, it looks like several people think it's a good idea, so, how do we move forward from here? Should I create a poll somewhere to try to get more community input? If so where should I create it? As a subpage of WP:ROLLBACK? J.delanoy^gabs_adds 21:11, 13 May 2008 (UTC)

The feature request is bug 12760. I support this measure and would prefer no restriction, the current limit makes rollback useless at nuking spam. MER-C 06:50, 14 May 2008 (UTC)

I put a limit on it because I thought we were going to be sensible and give rollback to all users, and I had the limit set accordingly. I'm not attached to it, and it was pretty much plucked from thin air, so there's no big deal in upping it two or three-fold. FWIW, I've hit this limit too, and it's a bit of a pain. — Werdna talk 09:16, 14 May 2008 (UTC)

As the person who filed bug 12760 back when rollback was first made available, this obviously has my full support. I can confirm that the limit is easily reached during busy periods when only a handful of people are patrolling recent changes. While I have addressed this to some extent in Huggle by falling back to normal reversion rather than just displaying an "Action throttled" error message, the difference in speed can be significant Gurchzilla (talk) 12:10, 14 May 2008 (UTC)
OK, it looks like we have quite a bit of support for this. I'm going to move it to WP:VPP and open a straw poll. J.delanoy^gabs_adds 15:18, 15 May 2008 (UTC)

Previous discussion from Wikipedia:Village pump (technical)#Non-admin rollbackers. Please add any new discussion in the section below.

Discussion

It seems that most of the people above supported removing the limit entirely. When I originally made the post, I did not want to sound too radical. (for lack of a better term) Many of the users who supported removing the limit entirely on VP:technical are administrators, which is why I worded the straw poll the way I did. J.delanoy^gabs_adds 15:33, 15 May 2008 (UTC)

Straw Poll

At present, non-admin rollbackers are able to make 5 rollbacks per minute.

Considering that mass rollback vandalism would be fairly easy to revert, and that any admin can remove rollback rights from any non-admin rollbacker, I beg the question:

Should non-admin rollbackers be able to make unlimited rollbacks without being throttled?

(After your signature on your !vote, please include the user group which shows up under Special:ListUsers/ when you type your name in. I do not mean for this to be demeaning to uninvolved parties, it is merely to aid in determining the natural bias of votes, as present rollbackers (e.g. me) would obviously be very likely to support this measure. Thanks.)

Support for rollback throttle removal

1. Reasons already stated above. J.delanoy^gabs_adds 15:33, 15 May 2008 (UTC) (rollbacker)
2. Support, either the removal of the limit, but at very least it should be increased to say, 20 per minute (that's 3 seconds per rollback which is a enough time to verify the edit qualifies for rollback). xenocidic ( talk ¿ review ) 16:31, 15 May 2008 (UTC)
3. Support removing the limit. Imposing something like Xenocidic suggested might not be a bad idea, and wouldn't hinder people's use of RB too much, while still stopping revert-sprees or edit-warring [hopefully!]. RichardΩ612 Ɣ |ɸ 16:35, May 15, 2008 (UTC)(Account creator, rollback)
4. I followed the original discussion on VPT, and J.delanoy makes an excellent case. Removal of rollback from abusers is easy. --barneca (talk) 16:59, 15 May 2008 (UTC)
5. Support total removal of the throttle, per my rationale below. Equazcion •✗/C • 17:02, 15 May 2008 (UTC)
6. per "dictator" Equazcion ( ;) ) and J.delanoy's rational. Thingg^⊕⊗ 17:05, 15 May 2008 (UTC)
7. Given the overall responsible way admins have been handling rollback permissions, among other things mentioned above, removing (or raising substantially) the limit should be fine. Gracenotes^T § 17:08, 15 May 2008 (UTC)
8. I can't see any need for a throttle. Editors who abuse the tool can be blocked or have the permission removed. Hut 8.5 17:57, 15 May 2008 (UTC)

Origin of the throttle

I was rather active in the original proposal to implement a non-administrative rollback feature, and I don't recall any mention of a "throttle" or similar limit. Can someone post a link to the discussion that led to the setting of such a limit? Equazcion •✗/C • 16:42, 15 May 2008 (UTC)

I looked over Wikipedia:Non-administrator rollback, but I didn't see any discussions about throttling. I have no idea where throttling came from. Sorry. J.delanoy^gabs_adds 16:56, 15 May 2008 (UTC)

At the risk of being judged a unilateral dictator, I think the throttle should be removed now with no further discussion required. There was a massive discussion regarding the adding of an administrative rollback feature in which very wide consensus was established to implement it, and no discussion whatsoever, as far as we can find, regarding the setting of any throttle. It should never have been implemented in the first place and as such it should be removed. That's my two cents. Equazcion •✗/C • 17:01, 15 May 2008 (UTC)

Unless a Dev provides a technical reason for it (server load, or some such), then I would concur. UltraExactZZ ^Claims ~ Evidence 18:02, 15 May 2008 (UTC)