Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Mr.Z-man (talk | contribs) at 18:08, 31 May 2008 (→FRUSTRATED: Wikipedia REPUTATION is dirt, sneer, disrespect, skoff, ignored, contempt, unreliable: comment). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
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.

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)[reply]

Support the change (in fact, I've been thinking about it for a while). Soxred93 | talk bot 23:38, 16 April 2008 (UTC)[reply]
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)[reply]
I support this. It makes a lot of sense. Majorly (talk) 23:51, 16 April 2008 (UTC)[reply]
I think [move] suffices just fine, honestly. seresin ( ¡? ) 23:56, 16 April 2008 (UTC)[reply]
@ 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)[reply]
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)[reply]

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. Reywas92Talk 01:28, 17 April 2008 (UTC)[reply]

That was before only autoconfirmed users could move pages, though. Soxred93 | talk bot 01:53, 17 April 2008 (UTC)[reply]
"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)[reply]
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)[reply]
  • 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)[reply]
  • I did this before and it got reverted...up for it again though. Voice-of-All 16:57, 17 April 2008 (UTC)[reply]
  • 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. GracenotesT § 19:16, 17 April 2008 (UTC)[reply]
    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)[reply]
    I also prefer "move" for the same reason. —Remember the dot (talk) 00:38, 19 April 2008 (UTC)[reply]
    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)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]
  • 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)[reply]
    • 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)[reply]
      • 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)[reply]
        • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    • Don't you have to be a registered user to move articles though? Dwr12 (talk) 18:20, 7 May 2008 (UTC)[reply]
      • You really think there are no childish acts of vandalism from registered users? SamBC(talk) 18:31, 7 May 2008 (UTC)[reply]
        • 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)[reply]
          • "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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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).[reply]
  • 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)[reply]
  • 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)[reply]
  • Oppose - prefer move, and less likely (I feel) to be abused as much, maybe. FT2 (Talk | email) 16:25, 15 May 2008 (UTC)[reply]
  • Support. FWIW, on fr: the tab has been named "renommer" (= rename) for years. _R_ (talk) 18:02, 16 May 2008 (UTC)[reply]
  • Support change to rename for the sake of clarity, "Move" has always seemed unintuitive to me. If we want to keep newbies away from renaming articles we should rename it "Virtual relocation" or something (<-- joke). :) Pax:Vobiscum (talk) 23:13, 17 May 2008 (UTC)[reply]
  • oppose - renaming is only a part of the functionality "move" is used for, i.e. "rename" is when moving a page to another page in the same namespace, and the same level, and with the intention to rename, and not for example histmerge etc... Could support it if it was only changed for newbies, but then it would require some advanced AI to be able to raise an newbie flag, and adapt the UI accordingly. →AzaToth 23:24, 17 May 2008 (UTC)[reply]
  • Comment What about putting both on the tab? "Rename / move" is clear and accurate. --ais523 23:32, 17 May 2008 (UTC)
  • Oppose You are moving a page... --Willypx2 (talk) 19:28, 20 May 2008 (UTC)[reply]
  • note I checked, and what is happens technically is a rename - the title of the page row is changed and a new page for the redirect is created at the old title (as opposed to a new page being created at the new title and all revisions being moved to it). The pageid goes to the new title. Whether this is relevant is of course a different question. --Random832 (contribs) 19:34, 21 May 2008 (UTC)[reply]
  • Strong Oppose proposed name does not make sense in the context of a cross-namespace move. The existing name works in all contexts and is certainly not confusing. Jerry talk ¤ count/logs 15:35, 26 May 2008 (UTC)[reply]

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)[reply]

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)[reply]
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)[reply]
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 Baastalk 18:21, 23 April 2008 (UTC)[reply]
This would require a fundamental change to how Wikipedia's database is structured. (1 == 2)Until 18:40, 23 April 2008 (UTC)[reply]
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 Baastalk
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
That happens to me all of the time. You pressed Enter. hmwithτ 18:26, 15 May 2008 (UTC)[reply]
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)[reply]
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)[reply]
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 Baastalk 15:36, 24 April 2008 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]
See also: bugzilla:10105. --MZMcBride (talk) 20:55, 26 April 2008 (UTC)[reply]

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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  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)[reply]
  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 Baastalk 14:19, 3 May 2008 (UTC)[reply]
  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)[reply]
  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)[reply]
  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).[reply]
  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)[reply]
  8. Support - It would stop embarassing things like this, where I had the fingers of my right hand one key over from where they were supposed to be and didn't notice until I'd hit "Save page". ~ ONUnicorn(Talk|Contribs)problem solving 00:02, 17 May 2008 (UTC)[reply]
  9. Support, On the grounds that the user can only edit their own summaries. Also, admin should be given the right to edit anyones summaries. Rgoodermote  19:46, 20 May 2008 (UTC)[reply]
  10. Support for own edit summaries only, but with admins able to edit offensive edit summaries by anyone. DuncanHill (talk) 11:05, 21 May 2008 (UTC)[reply]
  11. Support for last edit only, by same person/IP only. --207.176.159.90 (talk) 23:58, 21 May 2008 (UTC)[reply]
    Comment:No offense but I myself do not like the idea of an IP being able to edit their own edit summaries. I know you are an IP. But I would like to suggest that IPs be given a limit. Rgoodermote  18:11, 22 May 2008 (UTC)[reply]
  12. Support - offensive summaries or summaries that reveal personal data are a big problem, but right now there is no way of editing them except for deleting the edit completely... which is not a solution most of the time. Figure out a way to prevent abuses, but it should be implemented. Renata (talk) 21:51, 24 May 2008 (UTC)[reply]

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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Strong support as long as we are talking about an editor being able to change the summary of an edit if, and only if, it is their own edit, it is the most recent edit on the page, and no more than, say 12 or 24 hours have passed; this should apply equally to all registered users, including sysops. There is no potential for abuse there (nobody would "re-write article history"), and all sorts of problems with erroneous or incomplete summaries would be solved without complicating the history by leaving confusing or misleading summaries or making otherwise useless edits. Waltham, The Duke of 09:39, 18 May 2008 (UTC)[reply]

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)[reply]
  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)[reply]
    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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
    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)[reply]
  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)[reply]
  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)[reply]
  8. Strong Oppose: They are often used in RFArb cases, so no hiding embarrassing edits. --Dragon695 (talk) 00:50, 23 May 2008 (UTC)[reply]
  9. I have made spelling mistakes in my edit summaries an embarrassing number of times but I don't really see having the option to edit them improving the encyclopaedia. Spelling mistakes - not really a big deal, being able to easily hide past negative behaviour is potentially a big deal. If edit summaries were editable would they have histories, are are these histories going to have edit summaries, will those be editable? Guest9999 (talk) 02:50, 23 May 2008 (UTC)[reply]
  10. Strong Oppose - Negligible benefit, strong likelihood for misuse/abuse. /Blaxthos ( t / c ) 12:11, 24 May 2008 (UTC)[reply]
    • I am referring here to all the opposing parties using this as an argument: How could the feature possibly be abused if the summary could only be changed within a few hours and as long as the edit is the top one? Or do people expect cases to open on the same day as the edit summaries are given? Honestly, I do not understand this. Waltham, The Duke of 23:29, 26 May 2008 (UTC)[reply]
  11. Oppose. The benefits are negligible while the potential for abuse is substantial. Nsk92 (talk) 19:08, 24 May 2008 (UTC)[reply]
  12. Oppose One of the points of edit summaries is to keep a record. Are we to also have edit summary histories? Do you make an edit summary to explain the change to you edit summary? Can you change those edit summaries too? This is a waste of the developers time too, as the current software cannot do this. 1 != 2 19:14, 24 May 2008 (UTC)[reply]
  13. Oppose I do not see the problem for which this proposal advances a solution. I can imagine new problems and new rules about who is allowed to edit what in which summaries, and how to deal with those who abuse the feature, people suspected of abusing the feature, or people not using the feature being told they should. in lieu of null edits, etc. Why create a new layer of crap when the status quo is actually just fine? Jerry talk ¤ count/logs 17:34, 26 May 2008 (UTC)[reply]
  14. Oppose if this were implemented, modifications would have to be logged for transparency. And of course, we'd have to have a field in which users could provide an explanation as to why they edited the summary. And then... oh... :D Happy‑melon 16:42, 27 May 2008 (UTC)[reply]
  15. Oppose. Too little benefit would cost too much in time and effort. WODUP 20:36, 27 May 2008 (UTC)[reply]
Short break:

It was really not a good idea to start a poll without talking about the same thing.

The current proposal and bugzilla discussion can be found here. It asks for a mechanism to correct edit summaries (1) if it is your own edit (2) and if it is the last edit (3) during a short time span. This exact same mechanism is implemented in most online forum systems and has proven its efficacy and safety. Under these restrictions (own, last, recent), there is absolutely no potential for abuse (e.g. any following edit would make the previous summary permanent). At the same time you keep the benefits such as fixing accidentally empty summaries, switched summaries (when you have many tabs open), and half-completed raw summaries.

I am sure that many of the opposing users (as well as some supporting users which were obviously voting for a different mechanism) would actually support such an implementation under these restrictions. Again, this is not about allowing administrators to change summaries, not about allowing admin candidates to white-wash their editing history, and not about giving vandals any type of new toy. It would just be a nice feature to make editing Wikipedia easier - nothing more and nothing less. Cacycle (talk) 03:28, 28 May 2008 (UTC)[reply]

I completely agree. With all due respect to the editors who have voted above, and to their arguments, a poll as badly organised as this one can yield little useful information on the consensus for the specific proposal made here. Waltham, The Duke of 15:22, 30 May 2008 (UTC)[reply]

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)[reply]
    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)[reply]
  • 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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]

Is there any real reason not to set a throttle?, as evidenced here [1], unlimited page moves once autoconfirmed is a lot more useful for vandals, there can't be many legitimate reasons for a mass of page moves in a short space of time, and in those cases, it wouldn't be difficult to get admin help, obviously they'd be exempt--Jac16888 (talk) 16:41, 27 May 2008 (UTC)[reply]

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)[reply]

Increase autoconfirm

Please see Wikipedia:Autoconfirmed Proposal/Poll.

Page move speed restriction

Easier to undo page moves

Don't change anything

Comments/other

  1. Tight page move limit for accounts that have no edits between now-24 hours and now-720 hours, perhaps 0 page moves/minute. This will stop most socks.
    • Page move limit around 5/minute for accounts not falling into #1. Moving a page and the automatic move of the talk page counts as one move.
    • "Mover" attribute conceptually similar to "rollbacker" that effectively removes the move rate limitation. Attribute automatically (or manually) given to admins, and may be given by admins to others. Loren.wilton (talk) 12:12, 23 May 2008 (UTC)[reply]

There is already a page move speed restriction, didn't you know?

  1. Gurchzilla (talk) 16:05, 16 May 2008 (UTC)[reply]

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)[reply]

Oppose. We should not encourage obnoxious signatures, especially ones using the deprecated font-tags. --Dschwen 16:41, 12 May 2008 (UTC)[reply]
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)[reply]
Oppose - Agreed, those signatures truly do suck :) Equazcion •✗/C • 18:23, 12 May 2008 (UTC)[reply]
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)[reply]
Some never do... (evil grin) Waltham, The Duke of 01:20, 17 May 2008 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
Oppose more useless sigcruft, especially when it's using bad HTML too. Stifle (talk) 09:28, 16 May 2008 (UTC)[reply]
Oppose – I understand that many editors like to be able to find their comments easily in a discussion, but I doubt that newbies feel this urge so intensely. And it doesn't necessarily take an elaborate signature; you'll be surprised at how easily I find my comments. (Although, for all its simplicity, my signature does comprise 102 characters.) Waltham, The Duke of 01:20, 17 May 2008 (UTC)[reply]
Oppose. They look ugly most of the time, and they advocate a sort of 'l33t' atmosphere, which scares newbies away. How terrifying is it when you're just little newbie, and you find some fault in an article that you feel you might be able to rectify, but on the talk page everyone's signature has some crazy fonts and stuff going on. Suddenly you feel insufficient and you don't want to help anymore. It's not cool. If you want to play around with HTML, go to myspace or neopets. Agelseb (talk) 18:48, 18 May 2008 (UTC)[reply]
Oppose. Also disallow anything but wikicode for the signatures. (You may think I'm joking, but I'm dead-serious here. All of those stylish signatures are just annoying, and add no value to Wikipedia whatsoever. They're just annoying.) Jon Harald Søby (talk) 18:42, 19 May 2008 (UTC)[reply]
Oppose with some caveats: Don't show that, show something more like [[User:Example|Example]]~''[[User talk:Example|talk]]'' which would be better, more because it doesn't have those ridiculous font tags in it... ~user:orngjce223 how am I typing? 21:00, 26 May 2008 (UTC)[reply]

Non-admin rollbackers

Transcluded from Wikipedia:Rollback feature/throttle removal


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.

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 5/6 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.delanoygabsadds 02:04, 11 May 2008 (UTC)[reply]

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)[reply]
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)[reply]
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)[reply]
That's what I am hoping to get here... J.delanoygabsadds 13:29, 11 May 2008 (UTC)[reply]

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)[reply]

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)[reply]
So, would 15 rollbacks per minute enjoy consensus? —Ilmari Karonen (talk) 19:15, 13 May 2008 (UTC)[reply]
I'd say so; the benefit is real, and the opposition is not. :) EVula // talk // ☯ // 20:02, 13 May 2008 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]

←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.delanoygabsadds 21:11, 13 May 2008 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]
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.delanoygabsadds 15:18, 15 May 2008 (UTC)[reply]

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.delanoygabsadds 15:33, 15 May 2008 (UTC)[reply]

I count over 30 users in support of either raising the limit or removing it altogether, with no opposition. Enough for now? I'm not too optimistic about the change actually being implemented since I requested it four months ago, but it might be helpful to be able to say "there is consensus for this" -- Gurchzilla (talk) 16:53, 19 May 2008 (UTC)[reply]

I was going to wait a week, but I was unprepared for the amount of support this got. Where do I go from here? Do I contact a developer directly? J.delanoygabsadds 17:01, 19 May 2008 (UTC)[reply]
Good question. I'd say take it to Bugzilla, but no one seems to care about those. If I were you I'd leave this discussion here and wait until someone with significant influence sees it and decides it's time to make the change happen. Equazcion •✗/C • 17:05, 19 May 2008 (UTC)[reply]
Hmmm. I guess I'll spammessage a couple of devs and ask what the proper procedure for this is. J.delanoygabsadds 17:14, 19 May 2008 (UTC)[reply]
Or a dev.... [2] J.delanoygabsadds 17:42, 19 May 2008 (UTC)[reply]

Straw Poll c

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.delanoygabsadds 15:33, 15 May 2008 (UTC) (rollbacker)[reply]
  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) (rollbacker)[reply]
  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) (Administrator)[reply]
  5. Support total removal of the throttle, per my rationale below. Equazcion •✗/C • 17:02, 15 May 2008 (UTC) (rollbacker)[reply]
  6. per "dictator" Equazcion ( ;) ) and J.delanoy's rational. Thingg⊕⊗ 17:05, 15 May 2008 (UTC) (rollbacker)[reply]
  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. GracenotesT § 17:08, 15 May 2008 (UTC) (rollbacker)[reply]
  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) (Administrator)[reply]
  9. There's no need for the throttle: anyone who abuses unlimited rollback can have the right removed from them. Removing the throttle will increase our vandal-fighting capabilities greatly. Acalamari 19:21, 15 May 2008 (UTC) (Administrator)[reply]
  10. We can always take away rollback permission for anyone who abuses it. There's no reason to make life hard for the many who use it properly. Aleta Sing 19:38, 15 May 2008 (UTC) (Adminstrator)[reply]
  11. I haven't seen any problems that would make it necessary that there is a limit to rollbacks per minute. Captain panda 21:03, 15 May 2008 (UTC) (rollbacker)[reply]
  12. As mentioned by others, the benefits are great, and if someone abuses it, they will lose permission. -- Imperator3733 (talk) 04:16, 16 May 2008 (UTC) (no group memberships)[reply]
  13. Originally I was all about proceeding with caution with rollback, but things are going very smoothly with the process, and I personally feel it would be safe to remove the throttle. I actually wasn't even aware there was one, but even so, it doesn't seem necessary to me. -- Ned Scott 04:38, 16 May 2008 (UTC) (normal user)[reply]
  14. For the record. MER-C 12:03, 16 May 2008 (UTC) (rollbacker)[reply]
  15. It would be a benefit to the project in increasing vandal fighter effectiveness. Easy enough to remove from any abuser. --Gwguffey (talk) 15:23, 16 May 2008 (UTC) (rollbacker)[reply]
  16. Abusers can easily be removed. BigDuncTalk 15:39, 16 May 2008 (UTC) (rollbacker)[reply]
  17. A measure like this should only have been introduced if it had turned out that the rollback permission gave rase to substantial abuse. Oliphaunt (talk) 15:46, 16 May 2008 (UTC) (rollbacker)[reply]
  18. I do not see any major objections (technical or otherwise), so therefore I believe it can be removed. A throttle can always be replaced if abuse gets out of hand. Mahalo. --Ali'i 15:48, 16 May 2008 (UTC) (regular old boring editor)[reply]
  19. Its easy enough to remove. MBisanz talk 15:50, 16 May 2008 (UTC) (admin)[reply]
  20. Per all the reasons stated above. Juliancolton Tropical Cyclone 15:54, 16 May 2008 (UTC) (Rollbacker)[reply]
  21. Support as perfectly reasonable suggestion. —TreasuryTag—t—c 16:20, 16 May 2008 (UTC) (rollbacker, innit)[reply]
  22. CWii(Talk|Contribs) 22:33, 16 May 2008 (UTC) (rollbacker, account creator)[reply]
  23. Unnecessary support in an unnecessary poll[why] for an unnecessary throttle. It would be better applied to page moves. :) Nihiltres{t.l} 23:53, 16 May 2008 (UTC) (Administrator)[reply]
  24. Support - Rollback can be taken away even easier than Twinkle can (in the event of abuse of rollback priviledges), now that Twinkle is a gadget. —  scetoaux (T|C) 01:49, 17 May 2008 (UTC) (Rollbacker)[reply]
  25. Support - The rate of rollback is not much of a concern to me; page moves are a more serious matter. I'd suggest also that rollbackers have unlimited page moves but non-rollback editors be limited to a certain number of moves per hour (Administrator). EdJohnston (talk) 02:20, 17 May 2008 (UTC)[reply]
  26. Support Any increase at which the vandals would be able to use this if they every got a hold of it is offset by the increased speed at which their work could be undone. - Icewedge (talk) 08:25, 17 May 2008 (UTC) (Rollbacker)[reply]
  27. Support. *Dan T.* (talk) 11:50, 17 May 2008 (UTC) (Rollbacker)[reply]
  28. Support. Would help us faster for vandal reversing... --Creamy!Talk 13:13, 17 May 2008 (UTC) (rollbacker)[reply]
  29. Support Would be helpful to vandal fighters. FunPika 20:55, 17 May 2008 (UTC) (rollbacker, account creator) [reply]
  30. Support, with no reservations. The reasons behind the throttle are no longer valid. Titoxd(?!? - cool stuff) 06:00, 19 May 2008 (UTC) (administrator)[reply]
  31. Support, Per above users. Also EdJohnston like the page move idea. Rgoodermote  19:38, 20 May 2008 (UTC) (Rollbacker)[reply]
  32. Support per above. I also agree with EdJohnston regarding page moves, though I suspect that's a separate kettle of fish. Matt Deres (talk) 19:44, 21 May 2008 (UTC) (rollbacker)[reply]

Oppose rollback throttle removal

Neutral

Straw polls are stupid, and I already made my position clear in non-poll form above

  1. Gurchzilla (talk) 16:04, 16 May 2008 (UTC)[reply]

Adding straw poll options to facetiously declare how stupid straw polls are has been overdone

  1. Equazcion •✗/C • 19:57, 16 May 2008 (UTC)[reply]
  2. J.delanoygabsadds 00:15, 17 May 2008 (UTC)[reply]
  3. Waltham, The Duke of 01:13, 17 May 2008 (UTC)[reply]
  4. "Are has been overdone"? MER-C 10:54, 17 May 2008 (UTC)[reply]
    All ur base r belong 2 us :P J.delanoygabsadds 14:02, 18 May 2008 (UTC)[reply]
  5. Love the sense of irony. (I couldn't care less about rollback.) -- Taku (talk) 11:28, 17 May 2008 (UTC)[reply]
    Actually, most of us who voted here already voted above. I don't think this was actually intended to be a real option in the straw poll. J.delanoygabsadds 13:47, 17 May 2008 (UTC)[reply]
  6. Agree 107.232005281% with this. —TreasuryTag—t—c 17:00, 18 May 2008 (UTC)[reply]

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)[reply]

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.delanoygabsadds 16:56, 15 May 2008 (UTC)[reply]
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)[reply]
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)[reply]
Read Werdna's post above from yesterday. GRBerry 23:02, 15 May 2008 (UTC)[reply]
Basically the developer who implemented it did so on the assumption that it would be given to all registered user accounts, and that it would be necessary to do this to guard against abuse. Widespread objection to this led to it being limited to individual users at the discretion of administrators; since this provides much more stringent protection against abuse, the original reason for the limit no longer applies -- Gurchzilla (talk) 16:03, 16 May 2008 (UTC)[reply]
Sounds like it was a reasonable suggestion. It should've been discussed rather than decided on by one person. I suppose that's moot though, since it seems that it'll be removed now. Equazcion •✗/C • 17:47, 16 May 2008 (UTC)[reply]
  • Can't we just raise the throttle to a higher number, say 20rpm? — xaosflux Talk 16:35, 17 May 2008 (UTC)[reply]
    We could, and indeed that was the original suggestion. Arguing over whether to raise the limit or remove it seems a little pointless, though, and many people seem to prefer removing it. Since the only purpose the limit serves is to reduce the potential for abuse -- something that can be handled far more conclusively by removing the user from the rollback group and/or blocking them -- and was only added in the first place because the developers anticipated rollback being given to all autoconfirmed users, I believe the argument is that there is really no point to a limit at all, as the current one sometimes hinders genuine use of rollback while doing nothing to prevent abuse (since possession of rollback is regulated by administrators) and a higher limit would be similarly pointless -- Gurchzilla (talk) 16:51, 17 May 2008 (UTC)[reply]

Update

The rollback rate limit has been raised to 100 / minute on all WMF wikis. --MZMcBride (talk) 02:24, 21 May 2008 (UTC)[reply]

10/minute, actually -- Gurchzilla (talk) 17:37, 28 May 2008 (UTC)[reply]
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.

Common Sense Noticeboard?

Has a Common Sense Noticeboard ever been considered? By that I mean a noticeboard where disputes involving claims of common sense could be linked to, which could also potentially serve as examples of how policies and guidelines may need to be reworded. I originally posted this suggestion on the WP:COMMON discussion page, but that appears to get very little attention, so I thought this was probably a better place to suggest it. PSWG1920 (talk) 22:47, 15 May 2008 (UTC)[reply]

I think one side of an argument making an "official report" that the other side is lacking in common sense would probably make the dispute worse rather than better. Mr.Z-man 23:04, 15 May 2008 (UTC)[reply]
Probably not much more so than with other noticeboards. It could be the opposite as well. Someone could report that common sense is perhaps being wrongly invoked. And would it not be helpful to have a centralized location with potential examples of how policies and guidelines might need to be tweaked? PSWG1920 (talk) 01:10, 16 May 2008 (UTC)[reply]
Hmm. There's always Special:WhatLinksHere/Wikipedia:Use_common_sense. Dcoetzee 02:55, 16 May 2008 (UTC)[reply]
That list is too long to really be meaningful, although I suppose such a noticeboard might become the same way. PSWG1920 (talk) 03:01, 16 May 2008 (UTC)[reply]
"Common sense is the best distributed thing in the world, for we all think we possess a good share of it."
René Descartes, Discours de la Méthode (1637)
In other words, I don't think anyone could ever agree on what was a violation of "common sense" long enough to make it anything worth reporting. -- Kesh (talk)

OK, I see that a "common sense noticeboard" per se might not be such a good idea, but what about a centralized location with links to discussions on article talk pages which potentially serve as examples of how policies and guidelines might need to be reworded? PSWG1920 (talk) 22:40, 21 May 2008 (UTC)[reply]

It would wind up linking to practically every policy page, though. Policies & guidelines are constantly reworded, challenged and otherwise debated. — The Hand That Feeds You:Bite 22:57, 27 May 2008 (UTC)[reply]

Site-wide spelling choice tabs

Hi, I don't know if this has been proposed before, because I haven't read the archives. On the Chinese Wikipedia they have tabs at the top of the page where a user can choose to display all WP pages in the writing style of their choice. The options are: no conversion, Simplified characters, Traditional characters, Mainland simplified, Taiwan variant, Singapore variant, and Hong Kong/Macau variant. The entire page is instantly changed to the style of choice, for example 國 is detected and changed to 国.

Couldn't something like this be implemented on the English Wikipedia, so the user can select their preferred writing style? I'm unaware of differences between the countries of Commonwealth English, so the three tabs would be "no conversion", "Commonwealth English" and "American English". The term "color" would be detected and converted into "colour" at the click of a tab. The tab could be auto-selected based on a user's IP, and a change stored in cookies.

Of course this could bring up server load issues, but I don't know if there are more Chinese character variants than English word variants, or vice versa, so the usage would either be greater or less. Also, there would need to be exceptions, like proper nouns such as Medal of Honor, possibly within article titles or a template that hides the term from detection in article content, along the lines of {{noconvert|Medal of Honor}}.

I wasn't sure if this should be at Bugzilla, but I figured that if it's already done on the Chinese WP, it's already part of the software. --Joowwww (talk) 19:44, 16 May 2008 (UTC)[reply]

I think it's feasible, but not necessary or worth the effort it would take to develop. After all, just because something can be done doesn't mean there a reason to do it. In the case of English, the spelling differences between the two dialects are pretty slim. Aside from the occasional added "u" and "z" becoming "s", that's pretty much where the spelling issues end, and I doubt this causes any problems for readers. The more substantial differences between the two are in phrasing, and that's probably not something that could reliably be changed on-the-fly anyway, even if we did see a potential benefit in doing it. Equazcion •✗/C • 19:50, 16 May 2008 (UTC)[reply]
I move that this proposal be tabled. --Carnildo (talk) 20:25, 16 May 2008 (UTC)[reply]
This has been discussed in the past. It was decided that it wasn't worth the effort or arguments it would create. BrokenSegue 21:34, 16 May 2008 (UTC)[reply]
I think this is a bad idea simply because the differences between the different versions of English are so slight that they can be understood by any dialect. The added problems and work this would require is massively outweighed by the advantages. -Halo (talk) 22:06, 16 May 2008 (UTC)[reply]
I would second the motion if we worked that way. I do agree— of all the things to fix, this is way at the bottom of the list. --— Gadget850 (Ed)talk 15:51, 17 May 2008 (UTC)[reply]
You hit the nail on the head yourself, Joowwww: "there would need to be exceptions". The question is, how many, where, and who's going to exempt them? We have two and a half million articles now, and eleven million pages overall. The number of exceptions which would have to be coded for a proposal like this to be implemented is just mind-boggling. And the worst part is, just like spelling-bots, we wouldn't be able to automate it: it would have to be done by hand. Far too much work for an utterly trivial gain, and it still wouldn't solve the Georgia debate :D Happy‑melon 15:55, 17 May 2008 (UTC)[reply]
What's the "Georgia debate"? -- Imperator3733 (talk) 15:18, 23 May 2008 (UTC)[reply]
Look at the history - for a while last year there was a running move-war between about ten editors over whether Georgia should redirect to (or contain the contents of) Georgia (US State), Georgia (country), both, or neither. Similar arguments have cropped up over Petrol / Gasoline, Liancourt Rocks and a variety of other names, and a number of other pathetic cultural rivalries. Check out Wikipedia:Lamest edit wars - the majority of them are over dialect-related hiccups. Happy‑melon 16:58, 27 May 2008 (UTC)[reply]
Was Carnildo's comment a subtle joke? To a Brit "this prpoposal should be tabled" means "we should put this on the agenda and act on it" but to an American it means "we should ignore this". Really translating between dialects is almost impossible. Dingo1729 (talk) 04:26, 19 May 2008 (UTC)[reply]
Exactly. There's no context, so an automated system wouldn't be able to tell what I meant. --Carnildo (talk) 06:53, 19 May 2008 (UTC)[reply]
Switching Chinese writing styles is just a font change AFAIK. This proposal would be far more involved since it needs to change the content of the page rather than just the presentation. The effort-to-benefit ratio of this proposal I think falls squarely on the side of not implementing it. --Selket Talk 18:00, 21 May 2008 (UTC)[reply]
I have no problem with the idea of this (i.e. I wouldn't object if it was implemented), but it just seems to complicated to implement. English speakers can understand either spelling. -- Imperator3733 (talk) 15:20, 23 May 2008 (UTC)[reply]
It's not "complicated", it's "impossible". Read my earlier comments, then look up the meaning of the word "table" in the context of parlimentary procedure. --Carnildo (talk) 04:47, 24 May 2008 (UTC)[reply]
It's no more impossible than the corresponding system at the Chinese Wikipedia (which does involve phrase and idiom changes in addition to simple character remapping). It would, however, require writers to pay attention to it and regularly add manual exception for phrases that cannot or should not be automatically translated (like your "tabled" example). As pointed out above, this would be way too much work for way too little gain here. For details, see meta:Automatic conversion between simplified and traditional Chinese. —Ilmari Karonen (talk) 19:31, 27 May 2008 (UTC)[reply]

Favicon improvement

As requested by User:Alex.muller, I created a new version of our favicon. The idea was simply to remove the big (ugly) white box and instead make the background transparent. See the screenshot above, which compares the new favicon (FaviconNew.png, left) to the current one (right). Welcoming any comments. Equazcion •✗/C • 15:22, 17 May 2008 (UTC)[reply]

  • Great work! looks much better, this is a no-brainer for me. The sooner its up the better (Nice job on the logo too btw, hope the devs take care of it) Acer (talk) 15:49, 17 May 2008 (UTC)[reply]
  • Agreed. This looks good. Since this is based on Image:Favicon.png, it should inherit the description and license information and be moved to Commons. --— Gadget850 (Ed)talk 15:57, 17 May 2008 (UTC)[reply]
    • I'm not that knowledgeable with licensing, but just FYI, Favicon.png is a screenshot, not the actual favicon, so I'm not sure about that. Also, I couldn't actually use any of the old images to make this, it's made from scratch, so I don't know how much of that licensing info should be transferred over. In other words it's not actually "based" on anything, if that matters.Equazcion •✗/C • 16:11, 17 May 2008 (UTC)[reply]

As regards licensing: {{PD-font}} (it's just a "W" for goodness sakes) + {{trademark}}. Dragons flight (talk) 18:57, 17 May 2008 (UTC)[reply]

    • Since nobody spoke against this, and its just a graphical improvement that I don't think will be controversial maybe a bugzilla report can be made? Is anybody opposed to going ahead with it? Acer (talk) 23:35, 20 May 2008 (UTC)[reply]

I think this is a great improvement! It's been bugging me for a while now as well. But I had a different design in mind, if no one don't objects, and since Wiktionary has the same 'W' as us. How does this look?

Besides, this is more descriptive than just a W; much more symbolic and recognizable. -- penubag  (talk) 01:56, 21 May 2008 (UTC)[reply]

<-- Live preview, using Image:Wiki letter w.svg. Looks a bit messy and indistinguishable at favicon resolution, especially against a grey background. MER-C 06:49, 21 May 2008 (UTC)[reply]
Yes, the svg version above does look messy, which is why I created a different version, which can be seen in the screen shot. -- penubag  (talk) 16:31, 21 May 2008 (UTC)[reply]
Yes I was also thinking of using a "puzzle pice", looks good on the screenshot, and it solves the problem I mentioned above.
— Apis (talk) 14:53, 21 May 2008 (UTC)[reply]
Yep, I like the puzzle on the screenshot too. Looks nice Acer (talk) 19:12, 21 May 2008 (UTC)[reply]
  • Well, is the silence an expression of utter indifference or something else? Maybe we could get a bugzilla report for this change, unless someone is against? It solves any problem I can think of at least, and goes well with the main puzzle globe logo.
    — Apis (talk) 00:40, 26 May 2008 (UTC)    [reply]

No, I don't like the puzzle piece. I prefer just the W. Reywas92Talk 16:22, 26 May 2008 (UTC)[reply]

Standard location for admin instructions

When I became an admin I spent a lot of time just finding the templates to use when closing xfd:s, and I kept forgetting where the instructions were. To make it easier for new admins to get the hang of things (and for old admins to get involved in new areas) I suggest that we work out some sort of standard location to keep admin instructions, so when you come to a page like AfD or rfpp the "technical" instructions would always be in the same location. I've created a suggestion of how it could look like, if a link in the top right corner was used. I think a standard location of admin instructions would have several benefits:

  1. Quick and easy access to the right information for new admins (and oldies!)
  2. We could remove any admin instructions from main process page, making it less cluttered for non-admins
  3. We could break up huge instruction pages like Wikipedia:Deletion process, sending each section to the appropriate process page, thus making it easier for the people active in each process to update and monitor the instructions (and only having the appropriate section on your screen certainly makes navigation easier).

I guess my most important point is that I really think a standard location for admin instructions would make life easier for everyone. The exact implementation could be something totally different from what I suggested. The instruction pages should not contain any actual policies or policy interpreting stuff, just describe the process, present all the templates that an admin would need and links to the appropriate policies. Pax:Vobiscum (talk) 00:32, 18 May 2008 (UTC)[reply]

It would probably also be a good idea to standardize some of these things. Is it really necessary to have different templates and techniques for each type of XFD debate closing? Some go above the section header, some below. Some include the result as a template parameter, some put it after the template. Its unnecessarily confusing. Mr.Z-man 01:13, 18 May 2008 (UTC)[reply]
The Editors' Index to Wikipedia covers some of what you want.-gadfium 04:18, 18 May 2008 (UTC)[reply]
Yes, it's a nifty page, but hard to navigate and incomplete (as far as information for new admins goes). Even if it was greatly improved I still think having separate instruction pages for each process (and always having the links to the instruction pages in the same place) would be a much more efficient and user-friendly solution. I guess my proposal consists of two things: 1. Making sure that the links to the admin instructions are always in the same place and 2. Gathering all necessary admin info on separate instructions pages to ease maintenance and navigation. For most of the xfd:s it would just be a question of moving the right section of Wikipedia:Deletion process to its own page and creating a link in a standardized location (my suggestion would be in the top right corner). Pax:Vobiscum (talk) 20:09, 18 May 2008 (UTC)[reply]

Since this seems to be an uncontroversial suggestion I've gone ahead and implemented it at WP:RFPP and I've also made an AfD example page. More opinions would be appreciated. Pax:Vobiscum (talk) 16:04, 23 May 2008 (UTC)[reply]

Yes please, implement this across the board now... I remember not knowing where to start, and part of the problem stopping me from dipping my toes in the water at MfD is that the instructions are in 16 different places. And then, once they're all in the same place across the board, we can start standardising - keeping headers in the same place, as Z-man said. Go for it, quick! I can't see the downside. Alex Muller 19:02, 25 May 2008 (UTC)[reply]
Oh, by the way - I don't know whether there'd be much call for something like this because it's probably not necessary to move between those pages, but an index of all of them might not go amiss... Alex Muller 19:14, 25 May 2008 (UTC)[reply]

Threats/suicide admin. notice board

I’d like to suggest that an administrator noticeboard be set up handle threats of violence or suicide made anywhere on Wikipedia. The standard response to this is usually to contact the local authorities with any information available I believe. (I’m not sure if we have a formal policy on that though.) I suggest this be called Wikipedia:Administrators' noticeboard/threats or something similer.

I’m suggesting this as a follow up to this thread on WP:AN/I. (For further discussion of these issues please also see discussion here.) --S.dedalus (talk) 00:29, 21 May 2008 (UTC)[reply]

After that little fiasco a system should be setup to deal with these quickly. A couple of yanks with an inability to call internationaly is not good. Basically. Instead of a Notice Board why not first responders...or a list of admin/trusted users from various countries who are available near round the clock. Rgoodermote  00:49, 21 May 2008 (UTC)[reply]
This would in effect function like that since most administrators have all the admin noticeboards on their watchlists. --S.dedalus (talk) 01:01, 21 May 2008 (UTC)[reply]
Sounds like a good idea to me, and there should be guidelines posted there about how to deal with such threats. However, I'd name it "threats of violence", rather than just "threats", or we might get people posting threats to delete other's comments, etc., which isn't what this board would be for. StuRat (talk) 01:26, 21 May 2008 (UTC)[reply]
True, and I guess suicide can be looked at as self directed violence. --S.dedalus (talk) 01:29, 21 May 2008 (UTC)[reply]
This seems like a pretty terrible idea to me. We're here to write a free online encyclopedia, let's focus on that. A board like this would only serve as a troll / vandal / drama magnet. --MZMcBride (talk) 01:36, 21 May 2008 (UTC)[reply]
Indeed we are a free online encyclopedia, however we have notice boards like Wikipedia:Requests for oversight to insure that editing here is safe. A violent threat response protocol is no different from our protocol for responding to personal information. It is meant to protect editors from harassment or violence. I fail to see how anyone could object to administrators calling the police in an editors vicinity if that editor threatens to stage a Virginia Tech style massacre for instance. If it’s a troll, that troll gets a couple of policeman at their door and there’s no harm done, if it’s NOT a troll our action could prevent a tragedy. --S.dedalus (talk) 01:52, 21 May 2008 (UTC)[reply]
As I may have mentioned elsewhere, I prefer the simple "contact the Foundation and let the Foundation handle it" approach. However, I might also mention that a post saying that one wishes to hurt one's self is not a "threat," and the Foundation should handle it more respectfully than an actual threat. (The end point, contacting the authorities, may be the same, but how it's done or who's contacted might be different.)
If you do the noticeboard approach, then please make it a private noticeboard, accessible only to trusted users. (Otherwise it could be patrolled by trolls.) 69.140.152.55 (talk) 02:56, 21 May 2008 (UTC)[reply]
Requests for oversight is not a noticeboard, it is a closed mailing list. If we're going to do something like this, it should be a private thing, like the oversight mailing list, open to admins and trusted people who want to help. If we make a huge deal over every little thing that could be considered a threat, and the trolls are going to have another attack vector; we're calling the FBI over every "OSAMA WILL ATTACK AT NOON" I'm surprised they haven't caught on already. Since very little of a threat requires on-wiki action, there's no reason to have something like this on-wiki. Mr.Z-man 03:20, 21 May 2008 (UTC)[reply]
I'm not very sure what should be done.
On one hand, even though Wikipedia is an encyclopedia, it is also a community and as such, I think it should try to take care of its members. It would be tragic if someone were to post threats of suicide or harm to others, and have those threats come true out of inaction on our part.
On the other hand, there are very real concerns about being trolled, and questions of privacy and legal responsibility.
Under the current system, it seems to me that either individual administrators take the initiative to contact the authorities by themselves, or the Foundation is notified (or both). Perhaps what could be done is establish a private noticeboard and/or mailing list for discussion of incidents, and whenever a threat of violence is posted to WP:AN, WP:ANI, etc., the revision can be hidden from public view so as to reduce the amount of on-wiki drama. I understand that this would reduce the amount of transparency in these cases, but I also think that these have to be handled with sensitivity. --Kyoko 05:25, 21 May 2008 (UTC)[reply]
Of course, unless the police also have an admin on their staff, deleting the revisions right away makes it somewhat difficult for them to see the threat. Mr.Z-man 06:00, 21 May 2008 (UTC)[reply]
Indeed, I don’t think we need to delete these kinds of messages from the page history, most vandals and trolls don’t even know the page history exists, but I think an oversight mailing list might be the right direction to go. --S.dedalus (talk) 06:07, 21 May 2008 (UTC)[reply]
I'm happy with the current "report to WP:ANI and follow WP:TOV"; I'd rather not prefer a noticeboard which will turn into a troll magnet. x42bn6 Talk Mess 17:26, 21 May 2008 (UTC)[reply]
We are now considering some sort of a closed mailing list I believe; something which would be inaccessible to trolls. WP:ANI has time and again been proven to be slow and inept at handling delicate maters like this. TOV is great, but most users don’t know or follow that procedure. --S.dedalus (talk) 22:28, 21 May 2008 (UTC)[reply]
Now that is a better idea. I support the idea of a closed mailing list. But I also highly suggest still going to WP:ANI before using that mailing list. As it is highly likely that the mailing list could be bombarded with reports that are not even remotely close to threats of violence. Rgoodermote  22:47, 21 May 2008 (UTC)[reply]
We could just put a BIG sign at the top of the page instructing people on what belongs in the mailing list and what doesn’t. I suspect if there is another step involved it will just slow down what should be a fast response. Either way though, we can work that out if/and when this is set up. --S.dedalus (talk) 23:09, 21 May 2008 (UTC)[reply]
The problem with those billboards is that sure they attract the right crowd. But with that we get the wrong crowd. The poor email would be getting bombarded with emails from would be pranksters. I was thinking why not just put a link in WP:TOV, make it obvious...but yet hidden. Because I do not know how you would be able to make it for established users only. If you can then I am for the billboard. I am still for the mailing idea. Rgoodermote  01:55, 22 May 2008 (UTC)[reply]
We have several mailing lists on Wikipedia. Sure they get trolled sometimes, but we’ve been dealing with that for years. Users who miss-use Wikipedia get blocked. The mailing list will only include members who are interested in helping and willing to deal with an occasional troll when it rears it’s ugly head so I don’t think it will be a problem. Actually I’m virtually certain that trolls will ignore it completely if it’s in the form of a mailing list. Trolls do what they do in order to get a reaction. The only reaction they would get if they misused the mailing list would be a stern note on their talk page. Per Wikipedia precedent we can’t really have a “hidden” link. We also can’t add the link to WP:TOV since that is a rejected policy and, as far as I know, you’re not supposed to edit those. --S.dedalus (talk) 03:21, 22 May 2008 (UTC)[reply]
If we tell people to report it to ANI at the same time as the list, it defeats the purpose of the list, which is to handle such matters discretely and if the ANI comment just serves as a note, it is sort of a misuse of ANI, which is to attract a lot of people to an incident. If we have the list, we can't stop people from posting to ANI instead, but we shouldn't encourage it. Mr.Z-man 02:05, 22 May 2008 (UTC)[reply]
I actually thought that through later and decided it a bad idea. The only problems I can see now is. A. Getting people to use that instead. B. Notification of the list C. Implementation of the list D. Who will run it? Rgoodermote  02:20, 22 May 2008 (UTC)[reply]
I don't think this will work out. So long as the WMF tells users and admins to use their best judgment and lets them call authorities when they think appropriate, they are not themselves responsible or liable. But the more systematically they intervene the more they can be accused of making the wrong decision. For example, suppose someone posts a note that they are going to shoot up Bogus High School at 2 p.m., and an admin diligently deletes the note and calls the cops. But he contacts a dispatcher in the wrong jurisdication or doesn't make the point well or has a language barrier... and the alert doesn't get implemented quickly. Then after a shooting happens some mother turns up saying that her son's class was all working on the high school's Wikipedia article and if WP hadn't decided to delete it one of them would have seen the message and raised the alarm... now the lawyers will have their proboscides so deep into WMF funds you might as well start making your edits on a mirror site. Wnt (talk) 15:20, 22 May 2008 (UTC)[reply]
That's why I support the idea of submitting tips to http://tips.fbi.gov in that kind of case; they have juristiction over the whole United States. They have agents working around the clock who will route any tips to the appropriate FBI office (or in some cases, foreign agencies) so they can handle that kind of case. Of course, it's probably not a good idea to "cry wolf" to them since they would cease to take reports seriously if we did. Trying to locate the correct local sheriff and police departments can be difficult, and in my experience, they won't take reports of such threats over the phone or internet, so we'd need a Wikipedian in every town and city around the globe to volunteer. I also think it'd be a good idea to notify the freaks' ISPs; many ISPs would gladly notify the editor's local law enforcement of the problem, especially if we're talking about a school or place of work. GO-PCHS-NJROTC (Messages) 23:02, 29 May 2008 (UTC)[reply]
See Good Samaritan law. Except in a very few countries a bystander can never be held accountable for not taking action or taking the wrong action in an emergency. This mailing list is intended to protect people, that’s all. Legal issues are for the foundation to handle. --S.dedalus (talk) 04:23, 23 May 2008 (UTC)[reply]
I looked at that article, but it matches my preconception that such laws are narrowly cast to protect first aid responders. It is true that the legal issues can be left to the foundation, but that would seem to imply adhering to (current) policy. If you start setting up large private mailing lists and arranging to censor Wikipedia so that a group of people with no special credentials can "handle" serious threats (not yet emergencies), I think you're going to deviate from the status quo in a negative way. Also note that in the example I give above, the censorship might actually contribute to a lethal event - while no one can give you a firm prediction of numbers as to how many times deleting a post will push an event one way or the other, it is my general belief that openness is a more healthy practice. Another factor to consider is that an elaborate formal mandatory procedure handled by highest level admins and WMF people would serve as a soft juicy target for any vandal on Wikipedia. Wnt (talk) 16:56, 23 May 2008 (UTC)[reply]
There is no aspect of this which includes censorship, unless you believe that policy as currently implemented is censorship. If someone makes a threat of violence on Wikipedia the material already is removed and the authorities are called. All that is being proposed here is that we have a more streamlined system for handling the existing policy. Note too, that there are already many mailing lists for handling sensitive Wikipedia issues. These include I believe networks for handling stalking, real world abuse, personal information, vandalism and many other things. --S.dedalus (talk) 00:32, 24 May 2008 (UTC)[reply]
I think some of us are taking this whole "Wikipedia is not censored" thing way too seriously; if we keep goin' at this rate, we're liable to have all of the drug dealers, hookers, and fraudsters in this world using Wikipedia as a medium in their crimes. I don't support total censorship, but we can't go letting people use Wikipedia for purposes it was not intended for. Wikipedia is a free encyclopedia; it is not Myspace, it is not Ebay, it is not an advertising service, it is not the Better Business Bureau, it is not a place to vandalize, it is not a form of communication (although communication relating to the improvment, use, etc of the encyclopedia is permitted), and it is not a place to place threatening or harassing comments, and as long as we allow people to make Wikipedia into something it is not, people will continue to abuse it. We are an uncensored encyclopedia, not an uncensored anarchy. GO-PCHS-NJROTC (Messages) 23:15, 29 May 2008 (UTC)[reply]
I think this is a fairly good example of why encouraging the reporting of all such threats on-wiki may not be a good idea. Mr.Z-man 23:15, 29 May 2008 (UTC)[reply]
You're right. After thinking about it, if some nutcase posted a bonafide threat and was reported on-wiki, wouldn't (s)he just remove the report from the list and mark it as vandalism to the list or something? GO-PCHS-NJROTC (Messages) 23:40, 29 May 2008 (UTC)[reply]

Move the search box directly beneath the puzzle globe

This is a follow-up to Wikipedia:Village pump (technical)#change the SEARCH field input box, please (permanent link).

Currently the search box, the first thing that our users want to use, is about 3/4 of the way down the screen, after the lists of "navigation" and "interaction" links. This can make it hard to find for new and elderly users.

I propose that we move the search box directly beneath the puzzle globe, like so:


You can try this out in your own browser by adding 

addOnloadHook(function() {
    document.getElementById("column-one").insertBefore(document.getElementById("p-search"), document.getElementById("p-cactions"))
})

to your monobook.js. You can also type 

javascript:void(document.getElementById("column-one").insertBefore(document.getElementById("p-search"), document.getElementById("p-cactions")))

into your browser's URL bar and press "Go" to see how just one page would look with the new layout.

If there is consensus to make this change, then I'm sure the developers can just tweak the search box's location by default, eliminating the need for JavaScript.

So, what do you think? —Remember the dot (talk) 03:28, 21 May 2008 (UTC)[reply]

  • I like the idea of having the search box higher up the page, but this version seems to almost blend into the logo to me. Perhaps if a thicker line separates the globe from the search box? Johntex\talk 04:01, 21 May 2008 (UTC)[reply]
  • It could easily be added as a Gadget if people want it, I mean it's hardly a lot of code to implement. Oh, and yes, I like the idea. RichardΩ612 Ɣ ɸ 06:02, May 21, 2008 (UTC)
  • Support new visitors to the Wikipedia are likely to be here to find things out. Having the search box as proposed makes this easier for them so to do. DuncanHill (talk) 09:28, 21 May 2008 (UTC)[reply]
  • Oppose - I think it looks nicer the way it is; it's still not hard, and Google will direct most people to the right page anyway! —TreasuryTag—t—c 09:38, 21 May 2008 (UTC)[reply]
  • support. It should be made more obvious than in the sample; ease of use is more important than aesthetics (ask Jakob Nielsen, he knows). While most people enter Wikipedia via search engines (including me!) and most find related articles via wikilinks, we should be encouraging visitors to search for other info that's of interest to them - either unconnected or connected in ways that were not foreseen by editors. Philcha (talk) 10:08, 21 May 2008 (UTC)[reply]
    • The point is to combine aesthetics and usability, not to go too far towards one thing on the expense of the other. And for people who do not enter through search engines, we should have a truly prominent search box on the Main Page. From that point on, it won't be hard for them to find their way around. Waltham, The Duke of 01:37, 25 May 2008 (UTC)[reply]
  • Comment what about putting it between the "navigation" links and the "interaction" links? I do think it needs to be higher (people shouldn't have to scroll for it) but it does look a bit wierd right underneath the globe. What's the javascript for that? And there's no need to bug the devs for a change like this - if we gain consensus, just add the relevant code to Mediawiki:Common.js. Happy‑melon 11:04, 21 May 2008 (UTC)[reply]
    • Comment - I've corrected the proposal to make clear that developers don't need to be involved in making this change. —Preceding unsigned comment added by John Broughton (talk • contribs) 11:56, 21 May 2008 (UTC)[reply]
    • Comment. I like Happy-melon's suggestion of moving it between "navigation" and "interaction" - that would fix my issue whereby I have very small screen (I've already pointed this out posting from a different IP) because it would then be visible without scrolling. But thinking further about this, why are links like "Featured content", "Current events" and "Random article" so high up? I don't believe these are central to most consumers of this encyclopaedia who generally are looking for information on something specific.--82.148.54.183 (talk) 18:05, 26 May 2008 (UTC)[reply]
  • Support. The location of the search box should be optimized for readers; there are more than a thousand page views (by readers) for every edit that is done. The location may not be that important if a reader comes to a specific article via (say) Google, but it's hugely important when reader starts at the main page - and millions do so every day. Take a look at how Encyclopedia Britanica does it - search box right at the top. I don't think editors will have any problems adjusting - there was a major reorganization a couple of years ago without many complaints, I think. But for experiencd editors who like the old location, just create a gadget so that they can put the search box back where they prefer it. -- John Broughton (♫♫) 11:56, 21 May 2008 (UTC)[reply]
    • The analogy is an unfortunate one, I am afraid. Even if we do move the search box to the top, it will hardly be any more visible than it is now, given that we do not drastically change its formatting. Britannica's search box is incorporated in the masthead, or whatever it is called, which is always at the top—we have a sidebar, which occupies the left edge of the screen. Completely different vehicles for the display of important links. Furthermore, it is white on a blue background; our colours are much more subdued. In other words, it is clearly more conspicuous than our search box will ever be. And it probably needs to be, because there are visibly fewer ways to browse Britannica than Wikipedia. In any event, these are two very different examples. Adopting anything similar to Britannica's format would entail a radical change of Wikipedia's layout. And the current one works much better for the requirements it needs to meet. Waltham, The Duke of 23:02, 22 May 2008 (UTC)[reply]
  • Oppose I think the search provided by Wikipedia is kinda useless. I don't use the search box. -- Taku (talk) 12:09, 21 May 2008 (UTC)[reply]
  • Support The search box is THE most important thing of the sidebar and it makes every sense in the world (to me) to have it on the very top. John Broughton's arguments are spot on. Pax:Vobiscum (talk) 12:56, 21 May 2008 (UTC)[reply]
  • Support I definitely like it better up there, and John's suggestion is a good one. J.delanoygabsadds 13:27, 21 May 2008 (UTC)[reply]
  • Support I like it better up there because it makes it easier to navigate by lists and headings with screen readers. To get to the categories of a page, I can just hit up arrow twice from the search heading and to get to the Article/Discussion/Edit tabs, I can just hit "l" to navigate to the next list from the search heading. With the old positioning, I sometimes had trouble finding my way around. I know about the hidden "Views" heading, but that doesn't work in my version of JAWS. Graham87 14:11, 21 May 2008 (UTC)[reply]
    • One-size-fits-all solutions always have problems, especially with the modern variety in monitor sizes. Some people say the search box is too low now; taking it to the top will have other problems, however, especially for people with bigger screens. Surely there isn't the ability to adapt the main page to various gadgets? The demands of different users often seem irreconcilable. Waltham, The Duke of 01:37, 25 May 2008 (UTC)[reply]
  • Hmmm... I think I'm with User:Happy-melon. What about between the "navigation" and "interaction" boxes? Or altering the color of the box from white to a slight padtel or something to make it stand out more where it is? Mahalo. --Ali'i 14:29, 21 May 2008 (UTC)[reply]
  • Oppose Too much white space clumped together. It looks better the way it is now. 1 != 2 14:34, 21 May 2008 (UTC)[reply]
  • Oppose as a site-wide JavaScript hack. If you want it changed, please change it in MediaWiki. GracenotesT § 14:57, 21 May 2008 (UTC)[reply]
I thought that's what the proposal is for. To tweek MediaWiki so that the javascript workaround can be avoided. Missing something am I? --Ali'i 15:01, 21 May 2008 (UTC)[reply]
Ah, must have missed that paragraph (doesn't look like you missed anything, no); struck. No opinion on the GUI change, but implemented as a change in the monobook skin, there shouldn't a problem. GracenotesT § 15:18, 21 May 2008 (UTC)[reply]
Well, I wasn't 100% sure myself, so I figured I could have been totally wrong. :-) Mahalo. --Ali'i 15:26, 21 May 2008 (UTC)[reply]

 
    • Comment - This is a proposal to move the search box up to the top of the left margin on every page - the example above is simply an example. Moving the search box to where it is more visible doesn't change the nature of the Main Page; it's not a search page. The search box has to go somewhere - this question is simply about WHERE that somewhere is. -- John Broughton (♫♫) 16:36, 21 May 2008 (UTC)[reply]
      • I believe that Wikipedians could find a way to integrate a search box in the Main Page's top, where it would be most useful, without compromising aesthetics; it is certainly better than changing the appearance of a few million pages. Waltham, The Duke of 01:37, 25 May 2008 (UTC)[reply]
  • Comment and background. See Wikipedia:Village pump (proposals)/Sidebar redesign for the previously proposed idea, of having the search box between the "navigation" and "interaction" boxes (which we all liked, but it appeared to be technically difficult to accomplish). I'd support that as the ideal, if it's possible.
    Otherwise, I'd support Oppose this proposal to move it to the top of the stack, per Waltham and Evula, plus our search results are still quite abysmal. -- Quiddity (talk) 18:13, 21 May 2008 (UTC)[reply]
  • Support. I like it better this way, myself. It makes more sense, considering that Wikipedia is a searchable encyclopedia above everything else. Celarnor Talk to me 22:21, 21 May 2008 (UTC)[reply]
  • Support. And in addition, perhaps make the word "Search" bigger and bolder. --207.176.159.90 (talk) 23:54, 21 May 2008 (UTC)[reply]
  • Totally support this, to make it easier for new users to find their way around Alex Muller 06:00, 22 May 2008 (UTC)[reply]
  • Oppose on the following grounds:
    • It would be rather distracting, being placed exactly next to the beginning of text in articles (I don't think the screenshot above is so representative, if this change is to take place in all pages). Its current position, on the other hand, is well into the body of articles, and therefore more distinct than the non-sidebar part of the page.
    • I consider the proposed place of the search box too high, forcing my eyes go almost to the top of the page for every single search. Furthermore, it does not give me the ability to change that, in contrast to the current position, which is easily adjustable in most pages by scrolling. I'd also like to note that, although the current position rarely ever requires scrolling to reach the box from the page's top, it requires less scrolling from the bottom than the proposed position.
    • The search bar is rather distinguishing as it is; while the rest of the sidebar is a long bulleted list, the search box has a long box and two large buttons below it. I believe it strikes a perfect balance between being visible and not distracting a viewer's attention. The sidebar should be discreet; if one needs it, one can look at it then.
    • The search box's being above the sidebar's first two boxes would make it look as if it is more important than the links in these boxes, which is not necessarily true. The first box contains standard ways of browsing, important to, and useful for, a great part of our readership. The second one includes pages of extreme importance, including the "About", contact, and donation pages and the Community Portal; the first two are of particular significance to non-editors.
    • The current location of the search box divides the sidebar into two parts, of arguably different importance and usage. The first two boxes are important to all Wikipedia users; the toolbox is only used by editors, and the languages box is a varying factor.
    • Finally, per 1 != 2. I don't like the aesthetic side of the proposal. (And don't you dare focus on this argument... :-D) Waltham, The Duke of 06:24, 22 May 2008 (UTC)[reply]
  • Support. A very sensible idea, in line with navigation principles used on other web sites. And, replying to Nihiltres, if the main page isn't a "search" page as well as a "content" page, I wonder what is a search page? That's a rather overwrought statement—it's obviously both. –Outriggr § 10:33, 22 May 2008 (UTC)[reply]
    I would suggest Special:Search and Google as good examples. Nihiltres{t.l} 14:29, 22 May 2008 (UTC)[reply]
  • Support. As I suspect that it will make life easier for readers who are not used to the site. CambridgeBayWeather Have a gorilla 14:25, 22 May 2008 (UTC)[reply]
  • Oppose Its current location is just fine; if a user is so easily confused that they can't figure it out, moving the box up won't help (and it's already above the threshold, so even on a small screen, it's visible). Moving it clumps all the other sections (Navigation, Interaction, Toolbox, Languages) together; having the search box in the middle helps to make the sidebar more visually distinctive. I think it would be perfect for a gadget, though. EVula // talk // ☯ // 14:42, 22 May 2008 (UTC)[reply]
  • Oppose. I'm going to have go with the opposers on this; they've convinced me. Navigation and Interaction are just as important as the search bar, and its current location is, I think, more noticeable and distinctive than it would be up by the logo. To me, it's part of what makes the default Wikipedia skin look like Wikipedia. Powers T 18:27, 22 May 2008 (UTC)[reply]
  • Expand the discussion
Personally I prefer the current position because it's near the photo of the Feature Article, but try the other if you like. The real problem is that the Main Page is too long and needs to be edited down. This is a very tricky operation because everyone will have their favorite links! But the way it is I don't even remember to look at the Featured Picture most of the time, for example. There are three sections for other languages - the "Local embassy" link, the list of numbers of articles in other languages at bottom, and the sidebar with other languages. (By the way, I think that we should find a way to trim crazy languages like Volapuk from the main list; I know it has 100,000+ articles listed, but there should be some way to trim the list based on the number of articles and the number of actual readers; also Chinese should be at the top of the list rather than the bottom)
The problem is, we need a way to begin meaningful editing. There has to be some way for alternate Main Page versions to compete against one another in a very widespread test of approval. For example, if people could set a "Wikipedia home page" in their preferences, then different people, once logged in, could see different Main Pages, sometimes using portals or Wikiprojects, sometimes using an alternate development version of the main page. The statistics would start to prefer specific development versions that could be subjected to a Wiki-wide vote of approval or a test for a day. Wnt (talk) 15:51, 22 May 2008 (UTC)[reply]
This thread is about the Sidebar, not the Main Page. However, See Wikipedia:Main Page alternatives for Main Page variants, and the js code to make them your default. -- Quiddity (talk) 18:26, 22 May 2008 (UTC)[reply]
Thanks for pointing these out. Still, I think most users will bail out the moment they see ".js", without further consideration. Also, is there any way to gather statistics about how many use each version? Wnt (talk) 16:44, 23 May 2008 (UTC)[reply]
See http://stats.grok.se/ eg [3]. -- Quiddity (talk) 17:52, 23 May 2008 (UTC)[reply]
Hey, that's a handy tool - thanks! I guess no special method of collecting stats is needed then, though differences in the number of reloads between users could skew the results somewhat. Wnt (talk) 14:09, 26 May 2008 (UTC)[reply]
  • Oppose—Silliest idea in a long time. Its current position allow you to access it both initially and having scrolled down further.TONY (talk) 02:18, 23 May 2008 (UTC)[reply]
    • I dunno...most of the time when I'm reading along in an article, I have to scroll up to get back to the search box anyway.
    • We could also make the search box more prominent by adding it to the main page like the Commons does (although they hide the "Go" button and just leave the "Search" button). Would that be better? —Remember the dot (talk) 03:20, 23 May 2008 (UTC)[reply]
  • Support, as we have actually gotten complaints about it's current position (see the link at the top of the thread). You really have to look at the sidebar as a casual visitor does and realize that they're blind to it and many of its links because it looks similar to and is positioned similarly to contextual ads on other sites. I do recall seeing studies where people were asked to find something on a government website and almost everyone completely ignored a link to exactly what they were told to look for because it looked like an ad- logic doesn't even enter into it, there aren't ads on government sites. Putting it directly under the puzzle globe will make it much easier to find for new visitors- people look at logos because they're usually navigational aids. I'd also advise bolding the word "search" above the box to make it a tad more prominent. I don't like the way the searchbox on Common's main page is set up- it looks just horrible to me. That's my two pennies anyway. —Ashanda (talk) 01:04, 24 May 2008 (UTC)[reply]
    • Bolding search would not help because the Wikipedia logo has large, bold lettering anyway. Basically, all it takes for a user to know where the search box is is to find it once; and if there is a prominent box on the Main Page then they will know that there is searching capability, so that they will look for it on other pages even if they cannot find it straight away. And where will they look but in the sidebar? As long as they think to look at the sidebar, they will see it right away—within the sidebar the search box is rather distinctive. I agree that the Commons solution is rather ugly, but we don't have to do it this way. I am thinking of a page-wide narrow bar below the top box, which would be useful without disrupting the page's layout or ruining its appearance. Waltham, The Duke of 01:37, 25 May 2008 (UTC)[reply]
  • Support - The first thing most people want to do when they visit is search, so it makes sense to have the search box closer to the top. – FISDOF9 04:40, 24 May 2008 (UTC)[reply]
  • Comment (I actually support this, but don't want make it appear I'm voting as I don't my opinion to get rejected as I'm an anon.) An important point is that an increasing number of users like me use small-sized screens (800x480 on my Asus Eee PC) and cannot currently see the search box without scrolling.--82.148.54.195 (talk) 12:43, 24 May 2008 (UTC)[reply]
  • Support anything that helps searching. I would die to see the search box in the header next to "Welcome to Wikipedia" in place of the portals (like Portal:Art, Biography, etc...) Renata (talk) 21:44, 24 May 2008 (UTC)[reply]
    • That I would support (seeing Renata dead would not be bad, either). However, I do not want to see the portals replaced, but the inclusion of the search bar would certainly help; a long, narrow bar with bold wording below the top box would not affect the Main Page's layout and formatting much. See comment a few bullets below. Waltham, The Duke of 01:37, 25 May 2008 (UTC)[reply]
  • Support - The two main activities on Wikipedia are "searching and browsing". It makes sense that those should go at the top where they are most noticable. Searching followed by navigating (browsing) is fine. The Transhumanist    22:37, 24 May 2008 (UTC)[reply]
    • As I say below and have said again, the top of the sidebar is not that much different than any other place in the sidebar, and moving the search box has more consequences than a simple re-arrangement; it changes its entire appearance and the way people look at it. The top of the Main Page, however, is much more prominent, and really is the first place one will look at on that page—which is dubious for the sidebar. Waltham, The Duke of 01:37, 25 May 2008 (UTC)[reply]
    • I disagree that the search box is more noticeable below the logo. I would (and did) in fact argue that it's more noticeable where it is now, than up by the logo. As it is now, the user's casual glance sees "round thing, block of text, interruption to the block of text, block of text" along the left sidebar. I fear that with the edit box moved up, it would blend in to the logo on a casual glance or in peripheral vision. Having it interrupt the "block of text" makes it stand out more. Powers T 13:49, 25 May 2008 (UTC)[reply]
      • In practice, however, new users don't even actually "perceive" the side bar's table of links because to them it looks like a series of contextual ads (white boxes with text in them) and is ignored because of banner blindness. I've had n00bs email me to ask how to do something linked to from the sidebar, and I've had to give them specific directions, including landmarks and how many links to count down to find what they're looking for. Putting the search box between the "white boxes" and the logo will definitely make it more visible to newcomers. —Ashanda (talk) 14:20, 25 May 2008 (UTC)[reply]
        • I don't know about "definitely" -- I understand the banner blindness, but I think it's precisely the current position of the search bar that serves to break that up. Moving it could exacerbate the problem rather than alleviate it. Powers T 14:50, 25 May 2008 (UTC)[reply]
        • Indeed; it is not at all assured that it will draw more attention to the sidebar. Nor is it assured that people read web pages like book pages in a very rational sequence from the top to the bottom. They focus on images, large headings, and otherwise distinctive features, like those breaking patterns (and that includes the search box). The logo is right in the corner; even if people look at it, they might as well ignore the search box even if it is right below, as it will be lost next to the big, bold Wikipedia. And then the sidebar will not be in the least noticeable, because it will just be a long and largely featureless column of links. Waltham, The Duke of 02:11, 26 May 2008 (UTC)[reply]
  • Support This will more closely match user expectations. Essentially every site on earth does it at the top, though the top right corner is perhaps the most usual. In fact I think doing it up there, right above the page tabs might be the very best. DGG (talk) 00:22, 25 May 2008 (UTC)[reply]
  • Comment – If it is so important so help people find how to search in Wikipedia, then why not just have a search box on the Main Page—the main portal of entrance to Wikipedia—much more prominent than it would be anywhere in the sidebar, including the top? Renata's idea is splendid, and is in line with the otherwise completely irrelevant references to the layout of the Commons main page. For all other pages it does not matter so much, as people either know how to search in order to have found these pages, or have gone there from Google or other search engines. Personally, I prefer the status quo, but if there really is a problem, then this is the way to go, without ruining the grouping of the sidebar boxes or the balance of the search box's neither too high nor too low. Waltham, The Duke of 01:37, 25 May 2008 (UTC)[reply]
    • So, where on the main page would you put the search box? —Remember the dot (talk) 01:57, 25 May 2008 (UTC)[reply]
      • I am thinking of a one-line page-wide box just below the top box ("Welcome to Wikipedia", portal links, etc.). Too narrow to affect the page much, but it would still be noticed due to its prominent position, and perhaps slightly different colouring. (I have yet to decide if the box would be better above or below the "Overview", "Contents" and other links, but I think below would be better.) It would say "Search Wikipedia" on the left, with bold letters of medium size, and a long search box would be on that phrase's right; on the far right there would be the "Go" and "Search" buttons, or some differences might exist there. The details are open to discussion, but this is the general idea. A prominent box on the most important page, without adversely affecting either that page or the sidebar. Waltham, The Duke of 03:33, 25 May 2008 (UTC)[reply]
        • Well, one of the reasons why I'm hesitant to add a search box to the main page is because that would mean there would be two search boxes on the main page, a prominent one on the top and the regular one in the sidebar. It seems rather unprofessional...wouldn't it be more consistent and easier to find if the search box was in an easy-to-find place on every page? —Remember the dot (talk) 03:38, 25 May 2008 (UTC)[reply]
          • There would be two search boxes; although I do not generally like redundancy, I do not find this much of a problem—especially if we incorporate some sort of extra feature into the top search box which would make it more "special". The main points are two: one, I seriously doubt that a top position in the sidebar would make the search box much more visible (if one looks at the sidebar, one can easily locate the search box—this really is a matter of drawing more attention to the sidebar), and two, in the current position the search box acts like an anchor for the sidebar, splitting it into two well-defined parts, of which the first is always identical while the second is subject to changes. If we were to move the box to the top, we'd have all the other components of the sidebar lumped together, a grey mass with no distinguishing features; the whole thing would look like a long, fading line, instead of the current solid format. And, of course, there are the other arguments I have put forth in my main oppose (scrolling, semantics, etc.). Waltham, The Duke of 05:15, 25 May 2008 (UTC)[reply]
          • Update – There is redundancy elsewhere in the Main Page: out of the eight links below the top box, mostly linking to general information and browsing methods, four are already in the sidebar. I don't think redundancy should be considered so seriously for the main page.
            • What I don't like about this idea is that it may very well end up hindering navigation by new readers because they'll never notice the search box on every single page and will think they have to return to the main page every time they want to search. Besides, even the smallest changes to the main page seem to involve a lot of drama even after it seemed consensus had been reached. —Ashanda (talk) 14:20, 25 May 2008 (UTC)[reply]
              • That is exactly the reason we didn't implement this suggestion during the Main Page redesign. See specifically Wikipedia talk:WikiProject Usability/Main Page/Draft/Search box poll, plus many discussion threads.
                However, If you'd like to experiment with a new example, try fixing up Wikipedia:Main Page alternative (Search Box) (perhaps using elements from Wikipedia:WikiProject Usability/Main Page/Draft extra search box2). Hope that helps. -- Quiddity (talk) 20:42, 25 May 2008 (UTC)[reply]
                • Ashanda, we could give a link to the help page about searching in that bar, explaining the whole process. Many readers seem to be at a loss regarding how searching works in Wikipedia, even if they have located the box. Which, by the way, you make it sound quite difficult. The sidebar is one of the very few things that don't change from page to page; people are bound to notice that at some point. About the drama... If the arguments are compelling enough, they should prevail. Why should the Main Page be so much harder to change than an element appearing in every single page? Anyway, I now look at the poll, and see that the main arguments are:
                  1. "It distracts from the sidebar box" (which would indicate that people notice it).
                  2. "it makes searching look too important" (these could be used against any attempt to make the search box more conspicuous).
                  3. "It disturbs the layout of the main page" (that only relates to the specific proposal).
                  4. "Redundant", "it will make people think there is something special about one box over the other"
                  5. "It confuses readers because it disappears on the next page"
                • The two last bullets contain the most compelling arguments, I believe. However, it must be noted that from the 116 supports for the extra box, only one mentioned moving the sidebar one up, and from the 131 opposes, again there was only one such suggestion. Apart from that, the comments seem directed towards making the box more prominent. That I am willing to support (depending, of course, on the means), but moving the box up would simply ruin the sidebar. Waltham, The Duke of 02:11, 26 May 2008 (UTC)[reply]
  • Support, the most important navigation element (or should I say browsing element...) should be where new users actually find it (currently, it is easy to miss it in that jungle of small links). I further suggest to remove the 'search' heading above the search form, it is redundant to the 'search' button and it looks much, much better without. Cacycle (talk) 01:06, 26 May 2008 (UTC)[reply]
The search box is completely different from the "small links" (for one thing, it is sidebar-wide and has no blue at all), and a distinctive break in the sidebar's pattern; how can it be missed? And what makes the proposed spot "where new users actually find it"? In all honesty, I'd like to know where that comes from. In any case, the "search" heading, apart from ensuring consistency, actually helps setting the search box better apart, giving it more space. I am not so sure about its not being useful at the top, either; a box with no heading at all and just two buttons below would look downright strange, even below the logo. Waltham, The Duke of 02:11, 26 May 2008 (UTC)[reply]
Exactly because the "search box is completely different from the "small links"" the box should not be intermingled with those (for a new user more or less irrelevant) links. And for me it seems quite obvious from what I have read about usability that the place under the logo is the most prominent place to get the user's attention while any element hidden in small text and link lists at a visually non-prominent place will almost certainly be missed by a new visitor. Cacycle (talk) 03:14, 27 May 2008 (UTC)[reply]
How could you call it "intermingled" when the links are organised in boxes and separated from each other? And even if you don't believe that a box breaking a repeating pattern is more eye-catching than another lost in the shadow of the logo, do you really believe that the search box's move would not have detrimental effects on the appearance of the rest of the sidebar by accentuating this repetition and making the sidebar draw even less attention? I maintain that the move, although perhaps producing a small gain for the search box, would negatively affect the entire sidebar's layout and through it that of every single page in Wikipedia. Is it really worth it? And that small gain could be made much more painlessly by colouring the search box, as suggested by Quiddity below. Not anything loud... Just enough to be noticed, better guaranteed than dubiously beneficial moves. Waltham, The Duke of 19:37, 27 May 2008 (UTC)[reply]
Not true :-) Cacycle (talk) 03:14, 27 May 2008 (UTC)[reply]
I think the main point is less about how any of us likes it better, it is about how we can make life easier for new visitors. Cacycle (talk) 03:14, 27 May 2008 (UTC)[reply]
  • Neutral I'm happy with the search box where it is, but I don't really care. I do care that the location of the search box be consistent on all Wikimedia wikis because I am active elsewhere and I depend on a comfort level with the interface in foreign languages. I don't think it's worthwhile to change the interface on a thousand different wikis, so my suggestion is: don't bother changing anything. Shalom (Hello • Peace) 03:41, 27 May 2008 (UTC)[reply]
  • Weak Oppose - I'd normally strongly support this, as it conforms better to general web interaction conventions (familiarity being a large part of usability) and because it's very helpful for a user seeking info on a specific topic. On the other hand, the current search is fairly useless unless you know exactly the right term to search for; and worse, can be very confusing to people who use "go" instead of "search".
  • Support Sounds good to me. Why anyone would oppose such a minor and trivial change is beyond me,... Dr. Cash (talk) 00:17, 28 May 2008 (UTC)[reply]
    • The upper left part of the screen, from the logo to the "toolbox" label, is (perhaps along with the "book" background) the only part of the interface that does not change in the slightest degree in any of Wikipedia's several million pages. It is the one constant element that acts as a connecting thread between the most diverse of pages, and which everybody recognises and often uses. Even the slightest change to that part would, and should, be subject to discussion. That said, this is certainly not a trivial change, considering that it would affect (very negatively, in my opinion) the appearance of the entire sidebar, as well as the searching experience of readers and editors alike. A move would entail consequences which would not be trivial. Waltham, The Duke of 20:27, 28 May 2008 (UTC)[reply]
  • Support - would make life much easier for visitors and editors alike, and it's easy to implement. I don't think "I'm used to where it is" is a good reason to oppose - we'd soon all get used to the new position. Waggers (talk) 09:55, 29 May 2008 (UTC)[reply]
  • Support. It's an excellent idea: the whole layout feels more consistent, and the search box is easier to access. -- The Anome (talk) 23:58, 29 May 2008 (UTC)[reply]
  • Comment – Does any one know why when I hit Save without having previewed first I am taken to a search page? (For the record, I use wikEd's previewing tool.) It only happens in this thread. Waltham, The Duke of 15:41, 30 May 2008 (UTC)[reply]
  • Support. As an ordinary user and only occasional contributor, I've been annoyed by the current placement for a very long time. As the proposer says, it's the first thing people want to use but is currently hidden away and a real nuisance if you're accessing wikipedia from a mobile device. Saluton (talk) 21:15, 30 May 2008 (UTC)[reply]

Two alternatives

Feel free to refactor/move these 2 comments into new threads/pages etc. I won't have much time this week, and just wanted to get them mentioned. -- Quiddity (talk) 21:25, 25 May 2008 (UTC)[reply]

search
  • Change the search box button text - Proposed as part of the sidebar redesign, but postponed to avoid overloading the redesign with too many changes at once. (It should be re-raised sometime, and now seems appropriate.) The most favored option was changing "Go" to "Titles", and changing "Search" to "All text" - this is both more accurate and more informative than the current labels. Example above. (The "Titles" button should/will be bolded when in actual use (just like "Go" is), but cannot be shown in bold in the example due to technical restrictions with css-id usage). -- Quiddity (talk) 21:05, 25 May 2008 (UTC)[reply]
    • Comment – I am not sure that the new titles are any more clearer, and they might even be misleading—the Go button is more complex than that, and in fact leads to a search page if it finds no results in page titles. I should instead suggest adding a help link somewhere in the box, explaining how searching works on Wikipedia. Much more useful, don't you think? Waltham, The Duke of 02:11, 26 May 2008 (UTC)[reply]
    • Oppose I know what thewy mean and I still find "Titles" and "All text" confusing. Most websites use search, and there's no reason why that should be changed. Reywas92Talk 16:33, 26 May 2008 (UTC)[reply]
    • Strong support- I've seen many people go to Wikipedia and try to use it as a search engine (Typing 'Honda pictures red') and turning up no results. If the go button were renamed to 'Title search' this really should clear the confusion a bit. -- penubag  (talk) 06:55, 30 May 2008 (UTC)[reply]
      • I do not understand. The search page appears when there are no title results; wouldn't that page yield the same results if Search were to be hit directly? What difference does it make? Waltham, The Duke of 15:41, 30 May 2008 (UTC)[reply]
Search box with highlighted yellow background, 1 of 3 example colors
  • Highlight the search box, with color - A proposal that came out the Main Page Redesign discussion years ago, was that we Highlight the search box with colour (either border or background, see example images). It kind of fizzled out through lack of participation/consensus, but is still an option, both for individuals via css, or to implement sitewide. -- Quiddity (talk) 21:05, 25 May 2008 (UTC)[reply]
    • Comment – Highlighting could work; not only does it draw more attention to the larger box, but the long, white box where the letters go is also more prominent through contrast. If that is not accepted, I have another idea: colour the box for the letters yellow, until someone clicks in it the first time (or, even better, until someone searches for the first time). I don't know to what extent that would be technically feasible, but it would attract attention only until noticed. But I think Quiddity's proposal is better (old picture, eh?). Waltham, The Duke of 02:19, 26 May 2008 (UTC)[reply]
    • Oppose, I like it just fine as it is now. GO-PCHS-NJROTC (Messages) 23:42, 29 May 2008 (UTC)[reply]

Non-Wiki Talk Pages

I was wondering why exactly the discussion pages are wiki-pages (i.e. editable). Why wouldn't we just use a standardized approach (I'm thinking forum-alike)? I know this would of course a big overhaul, and that it causes problems with respect to the talk-pages already in place. I only would like to know if people agree, aside from the issues above, this would be a better system. Advantages:

  • Clear separation of posts and topics.
  • Quick and easy identification of users.
  • Easier replying.
  • Automatic signing.

Disadvantages (apart from the two posted above):

  • Where to put top-page templates? (This would be solvable though)

84.87.183.181 (talk) 12:21, 22 May 2008 (UTC)[reply]

To incorporate a totally different style of discussion would involve a massive amount of work, for very little gain, as the way those two "types" of software handle their data are totally different. If you're a web developer and wish to try your hand at integrating a board system into the MediaWiki software, by all means, prove me wrong. :) EVula // talk // ☯ // 14:46, 22 May 2008 (UTC)[reply]
Wiki talk pages mean that users can commute techniques learned between article editing and discussions. Why make users learn one syntax for articles and a different syntax for talk pages, when wiki markup works well for both? It also facilitates linking to articles and other talk pages (allowing both to be done the same way), and it makes quoting articles on talk pages much easier. Powers T 18:13, 22 May 2008 (UTC)[reply]
See mw:Extension:LiquidThreads. Coming soon, maybe. -- Quiddity (talk) 18:33, 22 May 2008 (UTC)[reply]
I'm not sure what the development status of LiquidThreads is, but I agree strongly with you that there ought to be forums on talk pages. See User:Dcoetzee/Why wikithreads are bad for my argument why. I already address all of LtPowers' objections, which aren't new. Dcoetzee 19:57, 22 May 2008 (UTC)[reply]
I can't agree with you more, Dcoetzee. Why do we still have to archive discussion threads manually? That's so primitive (and error-prone). (Or remember to put "Taku (talk) 08:43, 23 May 2008 (UTC)") Wikipedia is great, but the software system on which it operators isn't quite so, unfortunately. -- Taku (talk) 08:43, 23 May 2008 (UTC)[reply]
I think LiquidThreads looks good but too complicated to implement. —TreasuryTag—t—c 13:09, 23 May 2008 (UTC)[reply]
This sounds like a lot of work with very little benefit. GO-PCHS-NJROTC (Messages) 23:49, 29 May 2008 (UTC)[reply]

Language clean-up category splitting by language?

The categories which I try to do some work in, as a German-English bilingual, such as Category:Rough translations and Category:Wikipedia articles needing cleanup after translation, are generated by templates which have a parameter for sources language - so would it be possible to split the cleanup categories by language? It's really annoying to have to click through almost every article trying to find the ones that are from German - and having a distinct category for, say, Japanese, might make it easier to recruit Japanese-English bilingual help. Cricketgirl (talk) 08:05, 23 May 2008 (UTC)[reply]

Not a bad idea, that; and I doubt very controversial. You might want to ask over at WP:VPT to get a template coder to modify the templates and maybe a bot to sort the articles. —Ashanda (talk) 12:33, 24 May 2008 (UTC)[reply]

New section for Number articles: Age at time of death

A friend of mine had a birthday this week and I thought it would be fun if I could link to a page that shows historical figures that she is now older than. It would cross reference to a sentence on biographies that says [person] was ## years old when they died. —Preceding unsigned comment added by Vtricia (talk • contribs) 18:03, 23 May 2008 (UTC)[reply]

Wikipedia has about a quarter-million biographies of dead people. Is it really useful to have pages with lists of 10,000 or so names? --Carnildo (talk) 19:11, 23 May 2008 (UTC)[reply]
I don't think that's practical. How about Category:People that died in their 60's? --Tango (talk) 20:04, 23 May 2008 (UTC)[reply]
A category with maybe 100,000 entries is practical?? --207.176.159.90 (talk) 22:21, 23 May 2008 (UTC)[reply]
More so than a list with 10,000 entries, anyway. It could be split more. It's probably not worth it, though. Perhaps in the future we'll have the ability to semantically tag things in articles, then you could just run a query "list where type=person, deathdate-birthdate>X" (there is an extension, Semantic MediaWiki, that allows that kind of thing - it might be implemented on Wikipedia at some point in the future). --Tango (talk) 23:33, 23 May 2008 (UTC)[reply]

Welcoming Committee

I believe the WWC is need of help badly. With the large amounts of new users, the user creation log is full of red links. Therefore, I am asking anyone who wants to sign up please do so.--LAAFan 18:54, 23 May 2008 (UTC)[reply]

I certainly hope we're not trying to welcome every new user in the list, given that about 50% of accounts never edit, that's just a waste of effort. Only accounts that actually make a constructive edit should be welcomed. Mr.Z-man 19:16, 23 May 2008 (UTC)[reply]
I agree. Use newbie contribs, not the user creation log. The last thing you want to do is welcome a vandal. Paragon12321 (talk) 21:16, 23 May 2008 (UTC)[reply]
I agree, it is pointless to welcome accounts that never make an edit. However, welcoming productive users is important, and I do agree in part that the WC has fallen somewhat inactive. RichardΩ612 Ɣ ɸ 22:08, May 23, 2008 (UTC)
Here's what I do: When a change appears on my watchlist from a new user, and it's a meaningful contribution, I welcome the user myself. I think that's more meaningful than a committee dedicated to welcoming because it means that I actually saw their work and appreciated it. —Remember the dot (talk) 04:49, 24 May 2008 (UTC)[reply]
That's not to say that welcoming users based on Special:Contributions/newbies isn't meaningful. It is, but don't think we would have a problem at all if people took to welcoming new users that showed up on their watchlists. —Remember the dot (talk) 04:51, 24 May 2008 (UTC)[reply]
I agree with Remember the dot. I don't use my watchlist, but when I see a good edit by a user who doesn't yet have messages, I welcome that user. Note that welcome messages per se are unnecessary for users who don't edit because there's already a "welcome" message that you get when you create an account. It's only after you start editing that you might be helped by a welcome message from one of us. Shalom (Hello • Peace) 03:49, 27 May 2008 (UTC)[reply]
Why not create a robot to welcome new users? It's cool for the newbies to have a real Wikipedian welcome them and all, but I think a bot would be much more efficient. Many websites run by large corporations (such as Ebay, Myspace, Hotmail, Embarqmail, AOL, Amazon.com, etc) already have bots that send welcome messages to new users via email, so why shouldn't Wikipedia have a bot to post welcome messages on people's talk pages? GO-PCHS-NJROTC (Messages) 23:57, 29 May 2008 (UTC)[reply]
Because that would defeat the purpose of what we're trying to accomplish by welcoming them - extending a helping human hand and offering assistance if required. P.S. This is a perennial proposal that's been declined many times. xenocidic (talk) 00:03, 30 May 2008 (UTC)[reply]

Go back to the old current event icon

Someone has been going around changing all of the current event templates to use instead of . Frankly, the one we were using before looks much better. I propose that we go back to the old icon on all the current event template messages. —Remember the dot (talk) 05:48, 24 May 2008 (UTC)[reply]

FYI, I think that this is the discussion that led to the change. Kelly hi! 06:02, 24 May 2008 (UTC)[reply]
I agree with Remember the dot! Totally unnecessary, and as you say the “new” one is not very appealing. It doesn’t look like consensus was actually reached to make the switch in the first place anyway. The changes should be reverted pending a better discussion. --S.dedalus (talk) 06:06, 24 May 2008 (UTC)[reply]
I agree that the old icon is nicer than the new icon. However, I feel that looks better than either of those two. —David Levy 09:00, 24 May 2008 (UTC)[reply]
I agree, the one David has put forward seems more professional looking somehow, I say replace the old and new one with that. ☯Ferdia O'Brien (T)/(C) 09:10, 24 May 2008 (UTC)[reply]
I also agree with Remember the dot. We should by now have a significant enough number of users to demonstrate that the change did not have consensus. Harryboyles 13:43, 24 May 2008 (UTC)[reply]

Rating Images?

I was thinking about a rating system for images similar to WP:ASSESS. Any ideas? RedThunder 14:49, 24 May 2008 (UTC)[reply]

The idea is interesting, but I'm not sure I get the purpose. One major difference between images and articles is that the former tends to be static, especially when it comes to photographs. It may be possible to bring stub to a featured article, but not to bring a 800x600 overexposed photograph to featured picture status. Assessment may determine important articles that are of good quality, but ultimately images are useful only to the extent that they help illustrate an article. One thing that's useful is to determine if pictures can be somehow improved—e.g., if svg diagrams have incorrect information, or if a picture has a watermark, or if a photo is too dark and needs to be made lighter—and this Wikipedia and Commons already do have systems for that. GracenotesT § 15:20, 24 May 2008 (UTC)[reply]

Change "navigation" on sidebar to "browse"

The two main activities on Wikipedia are "searching and browsing" - they go together like bread and butter. They are referred to by these names on most of the relevant help pages, and on Wikipedia's main table of contents page.

Currently, on the sidebar, browsing is referred to as "navigation". This proposal is to change it to the word "browse". With the search section likely to be moved to the top of the sidebar (right below the Wikipedia logo - see that proposal above), having the "browse" section right below the "search" section would be the perfect companion. In any case, "browse" is the term in more common use on Wikipedia, and should replace "navigation". The Transhumanist    22:52, 24 May 2008 (UTC)[reply]

  • Support - as proposer. The Transhumanist    22:52, 24 May 2008 (UTC)[reply]
  • Question Could you remind us why it didn't get changed to that during the WP:VPR/Sidebar redesign? Thanks. -- Quiddity (talk) 00:10, 25 May 2008 (UTC)[reply]
    • I remember that it was part of the proposal (I might have voted in the poll), but that the specific term did not appear in the end. I did not look into it then, but was glad for the preservation of the word navigation, which is more general and sounds clearer to a non-technophile. Waltham, The Duke of 01:51, 25 May 2008 (UTC)[reply]
  • Comment – Even if browse is used more in Wikipedia, isn't the box in question mostly for plain readers? These are more often than not completely unfamiliar with any Wikipedia terminology, so what we should be doing is examine what is more well understood outside Wikipedia, not amongst editors. Besides, one should be making a decision on its own merits, not as a response to a change that has yet to happen (and one, in my opinion, which would completely ruin the layout of the sidebar). Waltham, The Duke of 01:51, 25 May 2008 (UTC)[reply]
  • Support It's a matter of semantics; apples and oranges, basically. Seriously, for such minor little changes, if the wikimedia foundation chooses to make a minor wording change, fine. Do we really need to vote? Dr. Cash (talk) 00:13, 28 May 2008 (UTC)[reply]

Requesting more details

I generally love Wikipedia and use it almost daily, but from time to time there are particular details on topics that I'd like to see expanded. I have a very slow internet connection, so there may already be a way to do this that I haven't found, but could there be a mechanism to request expansion on topics, maybe by flagging the article? I think something like this could help Wikipedia grow by providing authors with a means of feedback so they know what readers want to know more about. This may not be practical and I doen't expect any kind of personalized service, but it could result in a one stop place where someone who wanted to contribute could see what topics have a demand for more details. —Preceding unsigned comment added by 132.236.155.76 (talk) 21:28, 25 May 2008 (UTC)[reply]

Normaly adding some kind of stub template or {{Expand}} but there are so many articles that need expansion that taging is unlikely to help much.Geni 23:26, 25 May 2008 (UTC)[reply]
My best advice is: leave a note on the talk page giving specific requests for the information that you believe is missing. A general {{expand}} tag says almost nothing - a specific request evokes a response, either in the form of actual article expansion, "that sounds like a good idea but I don't know that info," or "that info doesn't really belong in this article, but maybe we should link X." Dcoetzee 05:53, 26 May 2008 (UTC)[reply]
Absolutely - click the "discussion" tab, then "new section", then leave a comment saying something like "I expected to find information about thing1, thing2, thing3 ..., but didn't. Would someone please add that to the article?" (As for "expand" templates, I dislike those - virtually everything but Feature Articles and Good Articles need expanding, so what exactly is the point?) -- John Broughton (♫♫) 16:17, 27 May 2008 (UTC)[reply]

Video requests

There are a lot of articles that could be vastly improved by the inclusion of videos of sufficient quality and length which are not difficult to obtain. Liquid crystal thermometer, for example, is hard to understand without a non-static visual reference. Since the Template:Reqvideo is seldom used and the Template:Reqphoto is way overused, how about a central video request page, where articles in need of videos could be listed, and people could contribute their own videos to it? Dr. eXtreme 23:09, 25 May 2008 (UTC)[reply]

since we have a fairly small number of people who knwo there way around the technical side of sorting out videos would probably have to make it clear that suggestions may be removed if unliekly to be fulfilled.Geni 23:31, 25 May 2008 (UTC)[reply]

Theres "Audio and Visual requests" on Commons http://commons.wikimedia.org/wiki/Commons:Audio_and_video_requests -- Coasttocoast (talk) 00:46, 27 May 2008 (UTC)[reply]

That's a neat idea, but it seems to me that using too many videos in articles could cause complications (examples: people using cell phones or dial up ISPs may find it more difficult to use Wikipedia). GO-PCHS-NJROTC (Messages) 00:04, 30 May 2008 (UTC)[reply]

Shortcut template changes

Today a fairly big change of the functionality of links in the {{shortcut}} templates was suggested. (The links will no longer take you back to the page the box is on, but instead to the shortcut redirect page.) The change seems like a useful improvement so I am thinking of adding it. Since this affects lots of project pages (like this page) and I know many of you reading this page uses such shortcuts I thought it best to announce it here too. Take a look at the discussion and examples at Template talk:Shortcut#Shortcut links.

And while I am at it: We added a feature to the shortcut templates some week ago: They now automatically add section anchors to the pages they are used on. See documentation of the anchor functionality at {{shortcut}}.

--David Göthberg (talk) 02:23, 26 May 2008 (UTC)[reply]

If I understand this correctly, implementing the proposal will make things a bit more difficult and confusing for non-editor WP users who click shortcuts in order to provide an occasional slight convenience for WP editors who are into the nut & bolt workings of wikinavigation. If I've got that right, the priorities seem reversed. -- Boracay Bill (talk) 03:19, 26 May 2008 (UTC)[reply]
Shortcuts
The links on the {{shortcut}} template are shortcuts for the page you are currently on, so the link will just take you back to the current page. For example, see the shortcut box for this page. Mr.Z-man 03:55, 26 May 2008 (UTC)[reply]
Please guys, discuss this at that template's talk page: Template talk:Shortcut#Shortcut links. Since then the conclusions of the discussion are left at the right place for future editors to read, instead of deep inside the Village pump archives. I announced the changes here just to draw attention to them and so people won't come later and ask: "Why didn't you announce the changes before you did them?"
Boracay Bill: I responded to your comment at that template's talk page.
--David Göthberg (talk) 04:04, 26 May 2008 (UTC)[reply]

New user group for prolific article creators

It would be beneficial to users patrolling Special:Newpages if users who create lots of quality articles were excluded from their articles needing review. The 'autopatrol' right is already given to admins and bots - any new pages they create are automatically marked as patrolled. However, many of these users don't want or need the rest of admin tools. This could be given out by admins, similar to rollback and accountcreator, to users with a history of creating good articles (lots of good creations, no problems with articles being deleted). So what do people think? Mr.Z-man 05:41, 26 May 2008 (UTC)[reply]

I like the either, only question is if the account should be separate from the main account (a modified bot account) or if the flag should be given to the main account. MBisanz talk 05:44, 26 May 2008 (UTC)[reply]
Since we only use the patrolled edits feature for newpages (and we really only patrol new articles AFAIK), there's not much of an issue with giving it to the main account; its basically just regular article work. Mr.Z-man 05:48, 26 May 2008 (UTC)[reply]
Ok, but from a technical point of view, all pages, regardless of namespace are listed for patrol. We've just decided the default view should only be the article space. MBisanz talk 05:52, 26 May 2008 (UTC)[reply]
Is there any worry that users who create quality articles are going to create inappropriate pages in other namespaces that people don't patrol anyway? I understand that all the namespaces are included in the patrolled edits feature, I just don't see why its an issue. Mr.Z-man 05:59, 26 May 2008 (UTC)[reply]
No, no real risk issue. Also, I'd be against Admins giving it out. I'd prefer crats give it out. MBisanz talk 06:03, 26 May 2008 (UTC)[reply]

I think it's un-necessary, and low-risk, if it has to happen then admins giving it out seems fine. —TreasuryTag—t | c 07:06, 26 May 2008 (UTC)[reply]

Let's have it be a minimum of 100 good articles first (not Good Articles, just good, valid articles). Sound good? DS (talk) 12:10, 26 May 2008 (UTC)[reply]
I think that this is a good idea; anything that helps content-creators can't be that bad, after all, content is what WP is all about. I think that admins should give it out (it's hardly high-risk and can easily be revoked). What about giving it to content-creation bots such as User:FritzpollBot? If such bots are creating 1000s of basically identical articles, it would be tedious to patrol them all manually, not to mention unnecessary to check them. RichardΩ612 Ɣ ɸ 12:31, May 26, 2008 (UTC)
I like this idea. Would each admin have the ability to approve someone or would there be a more formal approval system for this? Captain panda 12:37, 26 May 2008 (UTC)[reply]
Bots already have the flag, so that won't be necessary. As for approval, a page like WP:RFR could be set up, or it could be like the accountcreator group, given out by admins involved to non-admins involved, as this is less of an "everyone can use it" thing like rollback and more of a "only a few people need it" thing like accountcreator. Mr.Z-man 20:21, 26 May 2008 (UTC)[reply]

(Unindent) This sounds like fun. I'd like this kind of access for myself, but I suppose if I really wanted it that badly I could do an RFA. I put "construction" templates to keep the speedy deletion tags off my pages, and I'd prefer not to have to do that, but I've gotten used to it by now. Of course, we must also consider the consequences of creating endless new user access levels for no particularly compelling reason. :) Shalom (Hello • Peace) 03:47, 27 May 2008 (UTC)[reply]

This sounds like it might be useful to admins, but it's not really the user's problem. I mean, I never really thought about people patrolling the new articles I started - whoever they are they are apparently a lot more laid-back than the deletionists I often run up against when I start a new paragraph! So there's no reason I can see to make any special action to apply for this, except as a status symbol. I think the admins should just keep a list of who they trust on this point, which wouldn't even necessarily have to be public since it doesn't actually confer any special privilege beyond a chance of getting away with something until it's spotted. Wnt (talk) 00:07, 28 May 2008 (UTC)[reply]
Err, you may not have seen WT:CSD then. Overzealous patrollers is a problem frequently raised by content creators. With something like this, all patrollers could know to ignore certain users (and patrolling isn't limited to only admins either). We don't even have to make it a thing to apply for. The users with the flag won't notice anything (except their articles won't be plastered with cleanup tags an inappropriate speedy tags 2 minutes after creation). Mr.Z-man 02:29, 30 May 2008 (UTC)[reply]
Seems sensible to me. There few things seem more pointless than going through the patrol log ticking off yet another bunch of Blofeld's French geostubs. Angus McLellan (Talk) 15:12, 30 May 2008 (UTC)[reply]
I have to agree with Angus here. This would benefit both the article creators by allowing them to work in peace without having to deal with overzealous NP patrollers (like my self ¬_¬ ;) ), but would also aid the said NP patrollers by not requiring them to scroll through endless lists of legit new articles (we're averaging what? 18-20k+ legit new articles/day?) to find the "Tommy is the coolest guy in the world" articles. I can't think of any downside to implementing something like this. Thingg⊕⊗ 15:19, 30 May 2008 (UTC)[reply]

Send to a friend

It would be helpful if pages had a link or button so they could be emailed (either the whole text or a link). Job listing example —Preceding unsigned comment added by Wiki11790 (talk • contribs) 02:29, 27 May 2008 (UTC)[reply]

I think most web browsers have a "send a link" feature built in. Mr.Z-man 03:19, 27 May 2008 (UTC)[reply]
I'm using Mozilla Firefox and Internet Explorer and I don't believe they have that feature.-- Wiki11790  talk  06:47, 27 May 2008 (UTC)[reply]
In Firefox: File->Send Link. In IE7: Page->Send link by email. Mr.Z-man 06:52, 27 May 2008 (UTC)[reply]
True! We don't need a Wiki-feature for that. ╟─TreasuryTag (talk ╬ contribs)─╢ 07:05, 27 May 2008 (UTC)[reply]
Both of those seem to require that you have an email account set up with the web browsers. I'm suggesting a feature that would allow you to type in your email address and a friend's email address to send it to.-- Wiki11790  talk  15:49, 27 May 2008 (UTC)[reply]
If that were to be implemented, it would probably last about 3 minutes before being disabled after spambots started auto-vandalizing pages with ads and then sending that version to their 10,000 "friends"... Anomie⚔ 01:38, 28 May 2008 (UTC)[reply]
That's entirely possible, but why not assume good faith? The technology exists, articles could have been auto-vandalized up until now and web browsers used to send that to "friends". I feel as though this would be convenient and practical for wikipedia users.-- Wiki11790  talk  05:48, 28 May 2008 (UTC)[reply]
There is a big difference between using the web browser's "email this page" feature and having such a feature built into Wikipedia. In the former, the message is sent from the email account of the person sending, using that person's and their ISP's resources and reputation, and making that person answerable to their ISP's AUP. In the latter, the message is sent from Wikipedia's servers using Wikipedia's resources and reputation, and all we could do is block various IP addresses from using the misfeature. As for AGF, Wikipedia's legitimate users might use it in good faith, but the spammers and their zombies would abuse it horribly. Anomie⚔ 13:24, 28 May 2008 (UTC)[reply]

Wikipedia already has this feature. See: Template:Email -- penubag  (talk) 06:11, 28 May 2008 (UTC)[reply]

I think this is a really good idea, and that the spambots can be overcome. If all major news websites can do it, why can't wikipedia? Saluton (talk) 21:20, 30 May 2008 (UTC)[reply]

muchasref

I think we should try this w:es:Plantilla:Muchasref. It's a very useful tool to make smaller the references section. Srmagnetismo (talk) 02:38, 27 May 2008 (UTC)[reply]

Do you mean the fixed-height scrollable box for containing references such as on this Spanish article? I'm sure I saw one in a featured article on the English Wikipedia maybe a month or two ago. I do agree that this sort of thing should be used more extensivley as sometimes the refs section can get extremely long. Does anyone know what the English Wikipedia equivalent template is?--85.158.139.99 (talk) 11:10, 27 May 2008 (UTC)[reply]

This? I think it's a good idea, as some references sections are ridiculously long and there is a group of editors who oppose all such methods to remedy this problem citing that the templates are "not standard" which is not a valid reason. 

<div style="height: 220px; overflow: auto; padding: 3px; border:1px solid #AAAAAA; reflist4" >

--.:Alex:. 11:59, 27 May 2008 (UTC)[reply]

I'm a proponent too, but other editors cite screen-reader compatibility as an issue. User:Krator (t c) 15:13, 27 May 2008 (UTC)[reply]
Well that makes sense, it's a better argument than "it's not standard so we won't/can't use it". Could you elaborate on these compatibility issues? It's at least worth trying to rectify them and seeing what we can come up with. .:Alex:. 15:38, 27 May 2008 (UTC)[reply]
There's also this template as well:
<div class="references-small">{{reflist}}</div>

It makes the text in the references section smaller, which is a good alternative to using the scrollable box if it's causing problems (and may not suit the article). .:Alex:. 15:44, 27 May 2008 (UTC)[reply]

See Wikipedia:Citing sources#Scrolling lists. I'm guessing this has come up before. --—— Gadget850 (Ed) talk - 20:42, 27 May 2008 (UTC)[reply]
Would anyone be opposed to using the second template I posted, the one that makes the text smaller? Here's an example. .:Alex:. 17:25, 28 May 2008 (UTC)[reply]
{{reflist}} already makes the font smaller. No further reduction is needed. As for scrollbars, they have been utterly rejected due to a number of accessibility problems and problems printing out articles. Also keep in mind that the entire point of Wikipedia is to provide a starting point for further research, which isn't helped by trying to hide references in any and every way possible. --- RockMFR 01:11, 29 May 2008 (UTC)[reply]

Why is news being posted on the Main Page?

Why is news shown on Wikipedia's main page? That is what Wikinews is for. Wikipedia is supposed to be an encyclopedia, not a newspaper. In real life, would you open up the encyclopedia volume to find the latest news? Certainly not. Likewise, would you open up the newspaper to find general news? Again, no.

Wikinews should be dedicated to news, and likewise Wikipedia to knowledge and learning. On Wikipedia's main page, they could continue to provide a news section, but it should only be a link to Wikinews.

I often wonder why Wikipedia is the only project of the Wikimedia Foundation that has truly taken off. Perhaps it was the first and the oldest and the other projects will follow. Please discuss anything further either at the Village Pump or elsewhere, but please keep me informed as this goes on. Thank you!

Agomulka (talk) 13:15, 29 May 2008 (UTC)[reply]

I would gather it's there to point people to the respective articles related to ongoing current events such that they may be updated as required. I would support renaming it from "In the news" to "Current events" to more accurately reflect this. xenocidic (talk) 13:20, 29 May 2008 (UTC)[reply]
I agree, as really it just covers current events rather than going into huge detail and covering different news stories. I'd support such a change. --.:Alex:. 13:55, 29 May 2008 (UTC)[reply]
I concur with the original poster's point. We are not a news service, we are a reference work. I'd love to see a conscious effort to de-emphasize the "current events" aspect of things in all our public faces, as a first step towards actually addressing our hideous plague of blatant recentism. --Orange Mike | Talk 14:09, 29 May 2008 (UTC)[reply]
Or "Updates". Phlegm Rooster (talk) 19:15, 29 May 2008 (UTC)[reply]
I disagree. Statistics have shown that have readers have an overwhelming interest in articles related to current events - even if those articles already existed before the media brought attention to the topic. The "in the news" box is really about listing a few topics that the reader is likely to be interested in, because they're relevant to current events. They're not news articles, as they discuss the topic in its entirety, frequently with only a section dedicated to the current event. Dcoetzee 20:38, 29 May 2008 (UTC)[reply]
Traditional encyclopedias do publish news annually in yearbooks, according to Encyclopedia Yearbook Reference Guides. To do so daily would be difficult. -- Wavelength (talk) 03:01, 30 May 2008 (UTC)[reply]

Unified login

Unified login is now available. We should have a message to users to Special:MergeAccounts like on other wikis. Reywas92Talk 22:20, 29 May 2008 (UTC)[reply]

Message box standardisation, all namespaces

Last summer the style for message boxes in articles were standardised and the meta-template {{ambox}} was implemented to allow easy creation of such boxes. Some weeks ago we deployed {{imbox}} and {{cmbox}} for image page and category page message boxes. (But we are still discussing one extra feature for imbox.)

Now we have coded up the {{tmbox}} for talk pages, the {{ombox}} for all other types of pages such as "Wikipedia:" pages, and the {{mbox}} namespace-detecting style-shifting message box to rule them all. This means all the namespaces are covered. Everyone is invited to take a look at the new boxes and have a say at their talk pages.

Please discuss at their talk pages and not here. This is just an announcement.

--David Göthberg (talk) 12:26, 30 May 2008 (UTC)[reply]

One template to rule them all, one template to find them, one template to bring them all and in the darkness bind them? Hope it's protected... :) -- Gurchzilla (talk) 14:01, 30 May 2008 (UTC)[reply]
Haha, oh yes they are protected by a whole army of WikiElfs backed up by hordes of WikiGnomes and WikiFairies. There might even be some WikiDragons and WikiKnights among our ranks.
And don't worry, the other boxes don't build on {{mbox}}, instead mbox uses the others. And mbox is meant to be the least used since it should only be used for message boxes that need to be used on several different types of pages, which is not that common.
--David Göthberg (talk) 14:30, 30 May 2008 (UTC)[reply]

Slideshows

Wouldn't it be nice if an automatic slideshow of the pictures of an article could be created and accesible at a single click? —Preceding unsigned comment added by Simon.bastien (talk • contribs) 02:17, 31 May 2008 (UTC)[reply]

Pronunciation explanations

I think articles like this one look bad with too much explanations about the pronunciation, that's not so important for using the whole first line. It could be put bellow, or inside anoyher section --Moraleh (talk) 02:52, 31 May 2008 (UTC)[reply]

Confusing note on Wikipedia:Sandbox

For more experienced users (and probably most newbies), this usually wouldn't be very confusing since we already know what the sandbox is and what's permitted there, but I can't help but to wonder how many newbies have been confused when they've proceeded to edit the sandbox and read the text "For testing, please use the sandbox instead" on the sandbox. Should we delete "instead" from that sentence that appears whenever someone attempts to edit any page? GO-PCHS-NJROTC (Messages) 16:29, 31 May 2008 (UTC)[reply]

The relevant text is at MediaWiki:Edittools. It would be even better if this message and MediaWiki:Anoneditwarning didn't show the sandbox bit at all when editing WP:Sandbox. Is this possible? Algebraist 16:42, 31 May 2008 (UTC)[reply]

FRUSTRATED: Wikipedia REPUTATION is dirt, sneer, disrespect, skoff, ignored, contempt, unreliable

When I mention Wikipedia to most people older than 30, I get the same reaction:

"Waste of time. Terrible, unreliable info"

  • (Personally, I find the Wikipedia concept is fantastic!)

When I probe a bit, I find the source of their disrespect, scorn, sneers, and contempt:

FIRST IMPRESSION - they see the EDIT button, they see that anyone can edit, and immediately write off the project as unreliable information. (They don't understand peer review on wikipedia.)

I know I know... it's a foundation issue and has been discussed thousands of times. All I'm saying is that this is the reaction from most people I meet in person. Wikipedia has a lousy reputation and it's because of the Edit button.

Even a simple change like "Submit" (instead of Edit) could make a huge difference. —Preceding unsigned comment added by VgerNeedsTheInfo (talk • contribs) 17:36, 31 May 2008 (UTC)[reply]

If you think the button names or user interface could be changed for better presentation, that's a reasonable suggestion. There have been proposals to simplify or rearrange the buttons for users who have not logged in, on theory that the majority are not interested in all of the features. However, I don't share your perception about Wikipedia's reputation. That's simply a byproduct of biased and shallow coverage in the press, which is more interested in scare stories and amusing anecdotes than substance when it covers things on the Internet. Anyone who has that opinion has not given it much thought, and is not really the kind of user Wikipeida needs to reach. The Foundation lacks the multimillion dollar PR and marketing budget that commercial operations and even schools and charities use to counter bad press, so we might just have to live with it. 17:43, 31 May 2008 (UTC)
And yet we are one of the most popular web sites on the internet. We are a work in progress. 1 != 2 17:49, 31 May 2008 (UTC)[reply]
Of course, you could just rename the "Edit" button to "Contribute", but only to users who have not registered. It's something to consider nonetheless. --.:Alex:. 17:51, 31 May 2008 (UTC)[reply]
And my reply to anyone who thinks the edit button makes the information unreliable is to point out just how wonderfully satisfying it is to be able to actually correct errors rather than have to put up with them or consult lengthy errata sheets like you have to do with textbooks and other publications. The proverb, "Don't believe everything you read" long predates Wikipedia... —Ashanda (talk) 18:04, 31 May 2008 (UTC)[reply]
Wikipedia is not so universally denounced by non-young people. There are plenty of active contributors who are older. I've met multiple college professors who like the idea of Wikipedia - I've even seen a textbook that referred students to Wikipedia for information on topics that were too specific to be covered in the book. While Wikipedia isn't universally liked either, I don't think changing the wording of the edit tab is really going to change any minds. Mr.Z-man 18:08, 31 May 2008 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=216227034"