Jump to content

Wikipedia:Village pump (proposals)/Archive AK

Add links
From Wikipedia, the free encyclopedia
Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Clarifying binary prefixes in MediaWiki templates

Would anyone object if I edited the MediaWiki templates MediaWiki:searchsize, MediaWiki:size-gigabytes, MediaWiki:size-kilobytes, MediaWiki:size-megabytes, and MediaWiki:longpageerror to use the binary prefixes KiB, MiB, etc. as per Wikipedia:Manual of Style (dates and numbers)#Binary prefixes? These messages are used to refer to the amount of storage used by articles, and disk storage is an area where these prefixes cause the most confusion. Krimpet (talk) 18:17, 4 May 2007 (UTC)

Since no objections have been raised, I've gone ahead and made the change. Krimpet (talk) 04:31, 7 May 2007 (UTC)
T'was reverted, and for the record I agree with the reversion. Carcharoth 23:28, 9 May 2007 (UTC)
I think the templates should use whichever abbreviation is accurate. I also think the templates should use binary amounts. — The Storm Surfer 01:25, 14 May 2007 (UTC)
Kilobytes, Megabytes, etc. is accurate, standard, and does refer to binary amounts, as it always has. —Centrx→talk • 21:03, 16 May 2007 (UTC)
It is not true. Kilobytes, megabytes etc are ambiguous and inaccurate when used to express binary capacities because the standards define them as decimal. They did not always refer to binary amounts. Binary prefixes are appropriate here, except if you prefer common usage rather than unambiguity (this is a valid argument but I don't think that reflecting "common usage" is more important than unambiguity in an encyclopedia). The same discussion is taking place there WT:MOSNUM. Of course I don't agree with the reversion. Sarenne 22:01, 16 May 2007 (UTC)
No, kilobytes, megabytes, etc. mean 1024 everywhere except in specific situations where hardware sellers are trying to make money by misleading people. "Bytes" is not an SI unit. There is nothing unambiguous about "kibibytes" to the vast majority of readers; it is instead more confusing or considered a typo. —Centrx→talk • 03:27, 17 May 2007 (UTC)

I think binary prefixes are appropriate here. In case people do not know what they are, wikilink them to the appropriate explanatory article. We should strive to be as accurate as possible, and saying KiB is a lot more accurate than KB, because KiB unambiguously means 2^10 whereas KB could mean either 2^10 or 10^3, which are not the same number at all. --Cyde Weys 01:36, 14 May 2007 (UTC)

If a word is so novel that even technical people would need to look it up to understand that it was not a typo, then the word is not appropriate. Wikipedia is not the place for neologisms, and Wikipedia is not the place to promulgate invented standards. —Centrx→talk • 21:03, 16 May 2007 (UTC)
"Invented"? It's IEEE 1541 for God's sake. Should we not use the metric system either because it's just "invented"? Or more relevant, what about ISO 8601, which we do commonly use on Wikipedia? Standards exist for a reason. --Cyde Weys 21:40, 16 May 2007 (UTC)
The metric system was invented more than two hundred years ago and is in overwhelmingly common use today. If this were 1800, then no we should not have used the metric system. Even today, Wikipedia does not exclusively require the "standard" metric system in articles. Regarding ISO 8601, it looks to me like the default dating everywhere on Wikipedia is Time, Day Month Year not Year-Month-Day-Time and in fact the use of ISO 8601 is specifically discouraged in articles in the Manual of Style because it disrupts the prose for the vast majority of readers, who being anonymous do not have date preferences set. Regarding standards in general, Wikipedia is not a vehicle for promulgating new standards, especially ones that are not even accepted by specialists in the field for which they were created. It is not the business of Wikipedia to be the sole publisher to require these terms; it is not the business of Wikipedia to use terms so unfamiliar to its readers, not even used by specialists, that every use must necessarily include a clarification for what is ultimately a very basic term; it is not the business of Wikipedia to be the vanguard of a standard long before others, even industry magazines and academic journals in the field. —Centrx→talk • 03:27, 17 May 2007 (UTC)
The key problem here, though, is that using the SI prefixes in a binary sense is ambiguous. A better comparison to circa 1800 would be if we were to simply use the term "inch"; back then, there were English inches, French inches, etc. all in common use. Simply the term "inch" for all of them would be ambiguous, especially if we used different inches in different articles; to be accurate and unambiguous we'd explicitly state which unit we're talking about. Krimpet (talk) 04:24, 17 May 2007 (UTC)
If you care to look at WP:MOSNUM it does say "editors should refrain from changing prefixes from one style to the other" and if you look at WT:MOSNUM you'll see the consensus was reached to write KB which is in line with the common majority accepted use of that term. Also if you look at the IEEE Computer Society Style Guide it also says to use KB. Fnagaton 22:05, 18 May 2007 (UTC)
There is no such consensus.
Which units to use in Mediawiki templates should follow the decision that is made on the MoS. Don't re-debate everything here. It's already been debated and re-debated a few hundred million bazillion times on WT:MOSNUM. Whatever decision we make for articles will apply to Mediawiki messages, too.
The consensus has been demonstrated by the results of the poll in WT:MOSNUM and the subsequent changes made to WP:MOSNUM, to deny that there is consensus for that is silly. Fnagaton 10:55, 19 May 2007 (UTC)
And anyone who cares about the use of such prefixes on Wikipedia might want to express their interest in mediation, though there are so many people with opinions I don't know how a simple mediation is going to solve this. — Omegatron 00:20, 19 May 2007 (UTC)
No, the manual of style is not some iron-clad rule, and the other parts of the manual of style about not rampantly changing styles is more applicable and has much wider consensus than your binary prefix experiment. —Centrx→talk • 04:48, 19 May 2007 (UTC)
Wikipedia should find more places to use kibibytes until it gets reported on The Colbert Report just like Truthiness -- SWTPC6800 03:33, 19 May 2007 (UTC)

Merging New contributors' help page and Editor assistance into Help desk

I propose to merge Wikipedia:New contributors' help page and Wikipedia:Editor assistance into Wikipedia:Help desk. The reason for this is due the more or less similar activities:

  • All three have a help desk with possibility for users to leave a question on how to use the wiki, although the Help desk is the most established.
  • All three deals with "how-to" type questions; anyone asking for factual stuff is directed towards the reference desk
  • In addition, the new contributor's page and the help desk also mentions/links to the {{helpme}} and the IRC client.

There's really not a point in having three similar pages dealing with (as far as I can see) support mainly targeted at new users, and it would probably be better for Wikipedia if we were to have one single page instead of three. Could also be better for those interested in contributing through helping other users.

Also, this would mean the creation of #wikipedia-help and #wikipedia-en-help channels instead of using the current #wikipedia-bootcamp on IRC, as has already been suggested by some of the users on #wikipedia-bootcamp. The current bootcamp channel will be forwarded to one of the new channels. Bjelleklang - talk Bug Me 00:30, 4 May 2007 (UTC)

  • Addition as of May 19: Over the past weeks there has been quite a lot of arguments both for and against this proposed merger, and as it currently stands I've been convinced that there's absolutely no consensus to merge any of them, and as a result I've decided to withdraw the this proposal. Bjelleklang - talk Bug Me 16:57, 19 May 2007 (UTC)
  • I disagree with the merger. Strongly. I think differentiating the pages (by linking them on the main help page as different links, as I have done), is necessary. New users: (1) may be intimidated by the technological jargon of the original Help Desk, (2) receive answers that may be hard to grasp given the extreme use of acronyms and abbreviations for answers, and (3) few users (especially new ones) read the backlog of questions as most present singularly unique questions. I look at having two different pages the way a school teacher looks at differentiated instruction. Teaching everyone with the same resource might be practical and more clear cut, but students have divergent needs and skills sets so instruction needs to be different. If there's a problem here, it seems to me that the two pages need to be further differentiated so they better address the divergent needs of different users. SkipperClipper 02:59, 4 May 2007 (UTC)
  • Merging WP:NCH was already discussed, but I don't see how Wikipedia:Editor assistance is mergeable. It has more in common with the Adopt-a-User program than with the help desk, so if it has to be merged, I'd suggest it's merged with the adoption program instead. - 87.209.70.231 04:46, 4 May 2007 (UTC)
  • Disagree. As SkipperClipper mentioned above, the three pages are like two teachers teaching the same idea with different resources. Moreover there are several major differences among the projects:
    1. HD deals with questions in a single-thread Q-A manner. Old discussions are archived automatically after 5 days. A second follow-up action or response is unlikely. On the other hand, both NUH and EA works in the form of a personal follow-up.
    2. EA and HD is for everyone, while NUH is specialized for newcomers.
    3. Processes in HD and NUH are more well-defined, while EA is comparatively casual.
    Owing to these differences in working principles and style, I believe the three projects should survive individually. --Deryck C. 04:56, 4 May 2007 (UTC)
  • Comment: As far as I can see, WP:EA does nothing different from the other two pages mentioned; on the requests page people leave their questions, while other users reply, also keeping follow-ups in the same page. That's more or less exactly the same as HD or NUH. As for the level of expertise on the users seeking help I can't really see a that big difference with EA compared to HD! Both pages have questions ranging from brand new and inexperienced users to those with more experience and more advanced questions.
If the original intention of EA was more coaching-thing than traditional Q&A, this should be empathized much more instead of focusing on the Q&A. As an alternative to the Q&A, both NUH and HD links to an online IRC client as well as the {{helpme}} template; the latter primarily for users to put on their userpages in order to get help from a more experienced editor directly. EA has no such alternatives, and only focus on Q&A. I also don't understand the problem of mixing questions from inexperienced users with other questions from somewhat more experienced users; this has been done on all three pages, although there is generally a lower level of expertise required to answer questions on NUH. If it turns out that the differences are really small, why not expand one of the projects instead of having three different? Bjelleklang - talk Bug Me 10:24, 4 May 2007 (UTC)
Reply: if a Wikipedia project page can solve a problem, why bring it offsite to IRC, complicating things? Moreover, EA is not just Q&A; it also lets people discuss stuff. See some more complicated cases out there. It's just the simple cases that look like Q&As. --Deryck C. 14:40, 4 May 2007 (UTC)
  • Disagree, and would note that a failed (and I mean failed, only one person supporting) merger proposal happened around a month ago. EA's been working just fine as a separate project, let's leave it alone. Seraphimblade Talk to me 11:46, 4 May 2007 (UTC)
  • I'm not convinced there's enough of a difference between WP:NCH and WP:HD to keep them separate, but the arguments I've heard to prevent the merge seem reasonable. The problem is that WP:NCH is not that well-known; new users often find the Help Desk instead, and NCH doesn't have as many users answering. So maybe better advertisement, rather than merging, is the solution. --ais523 12:53, 4 May 2007 (UTC)
  • Disagree. ASSIST is working nicely as it is, and is performing an additional role in getting newbies' heads around policy, so that they actually do what they're meant to, rather than get the AMA to wikilawyer for them. Moreschi Talk 14:20, 4 May 2007 (UTC)
  • Disagree with the merge, but perhaps some sort of restructuring of the New contributors' help page, I keep both watchlisted, but the problem with the NCHP seems to be that it's not very well publicized, maybe it would help to add a few more links to it in the various banners and page headers designed for new users--VectorPotentialTalk 14:25, 4 May 2007 (UTC)
  • Agree in part - I concur with ais523's comment about the need to promote the WP:NCH page properly; but it suffers from alarge degree of redundancy, so it should be merged. I have only recently begun to monitor it because I didn't even know about its existence, but it suffers from very low traffic. I and at least one other editor raised the same point in the previous merger discussion. WP:EA, however, should not be merged, but its intended use needs to be emphasised and/or repositioned to reflect the differing nature of the assistance on offer. I often work one-to-one with new editors about specific queries/issues and WP:EA is the ideal forum for their requests. As such, it needs to be promoted properly, described clearly, and easy to locate. Adrian M. H. 16:13, 4 May 2007 (UTC)
  • Comment - I would also like to point out that too much merging may result in excess strain being placed on the Help Desk during busy periods, and if that happens, some questions will slip by unanswered and questioners will only find it that bit harder to find their questions. Adrian M. H. 16:17, 4 May 2007 (UTC)
  • Agree in part - I think that WP:HD and WP:NUH should be merged while WP:EA should remain. WP:HD and WP:NUH are the same set-up and used for the same purpose. I think having these two is redundant. If someone is at the mall and needs help they go to the help kiosk; the system we have now sends the new shoppers one place and the established shoppers somewhere else. I don't think that WP:EA should be included in the merge simply becuase it does more than answer questions. WP:EA is used for resolving disputes and is a more personal aid. In summary, I strongy agree that WP:HD and WP:NUH are merged to one page (after all new users come to the help page all the time), and I feel that WP:EA remain as its own page. Scottydude talk 17:07, 4 May 2007 (UTC)
  • Agree in part - WP:HD and WP:NUH should be merged while WP:EA should remain per above. Agree that WP:NUH has low traffic and so could be merged to streamline our procedures, while WP:EA is working ok and merging could over-load WP:HD. Addhoc 23:18, 4 May 2007 (UTC)
  • I definitely support the merger of NUH and HD, EA is an essentially an unnecessary fork of the Adopt a user program (or perhaps just the same thing with less "cute" title). Maybe they should be merged. —The preceding unsigned comment was added by John Reaves (talk • contribs) 23:24, 4 May 2007 (UTC).
The less confusing conflicting help channels for newbies (and oldbies), the better. 86.31.103.208 13:02, 6 May 2007 (UTC)
Extra comment: One current advantage of EA over HD is that the traffic in EA is not too high so discussions are relatively coherent and easy to follow. Promoting on Help:Contents is good, but beware that excessive advertising could lead to overcrowding of EA, which is not good for this lightweight ask-and-help project. --Deryck C. 15:30, 7 May 2007 (UTC)
  • Disagree - I am a rather new contributer, and I read everything on the NCHP, sometimes learning new things about Wikipedia in small steps. I tried to read HD also, but most of the questions were too difficult. It's nice for a new wikipedian to have a safe place where you don't have to be afraid that your question is too stupid.
    Just read the way NCHP starts: "A place to get help with editing and finding your way around Wikipedia", compared to HD: "Read this first!...Please check the Very Frequently Asked Questions Page before asking a question here!" You notice the difference in tone?
    No please, keep NCHP for us newcomers! Lova Falk 13:49, 8 May 2007 (UTC)
As demonstrated, newcomers do not expect as complicated and serious a thing as help desk. Something extra should be designed for them. --Deryck C. 07:17, 9 May 2007 (UTC)
  • Disagree. If I were to say to merge one of them somewhere else, it would be WP:EA, but even that carries considerable overhead for no real benefit, so meh. The Help desk and the New contributors' help desk have different methodology objectives, so they should remain separate entities. Titoxd(?!? - cool stuff) 00:01, 12 May 2007 (UTC)
  • Agree in part. This is the matter of difference in names. The Help desk and the New contributors' help page serve just the same purpose in practice. Given that more than half of the questions at the Help Desk come from the newbies, I believe this page is not too complicated. So WP:HD and WP:NUH should be merged while WP:EA should remain. PeaceNT 12:24, 13 May 2007 (UTC)
  • Merge, same thing. Same difference. "Dare to diff", they did... but now they should "face the diff." --CyclePat2 01:23, 17 May 2007 (UTC)
  • Comment/disagree – Since my earlier comment and !vote, I have found myself contributing regularly to NCH and much less often to the Help Desk; this is partly due to limited wiki-time to be shared around, but also because the NCH has shown itself to be a good place to go into more detail with more time to do so. The questioners typically get more attention and I and other respondents often follow up requests with one-to-one help if they need it, which they quite often do. The NCH seems to be a place where newbies can answer their questions and get their answers in a more relaxed and less hurried way than the often-busy Help Desk, where questions are usually (with the honourable exception of Teratornis) dealt with more contritely. What may be seen as the NCH's weakness is actually its strength. I am increasingly against the idea of a merger. Adrian M. H. 21:22, 17 May 2007 (UTC)
  • STRONG DISAGREE: the NCH is for - let me empesize it - NEW wikipiedians. The Help Desk is for the more advanced wikipiedians. And I have to agree with Adrian M. H. about the difrences between the two. A merger would only make things worse, therefore I do not want the NCH to be merged. End of. --Adam Hillman 06:14, 19 May 2007 (UTC)
  • Disagree Both HD and NCH are sprawling by their very nature; EA is relatively manageable. If I had to wade through all the correspondence that is present in the others, my participation would be scaled back dramatically. --Aarktica 16:34, 19 May 2007 (UTC)
  • This proposal has now been withdrawn, as further discussion isn't going to get us anywhere. Thanks to everyone who has participated, I hope that the arguments presented here has helped those (inluding me) that didn't really see any issues as to why they shouldn't merge. Bjelleklang - talk Bug Me 17:12, 19 May 2007 (UTC)

Proposed change to "Template:Unreferenced"

{{Unreferenced}} is a high-profile template that is currently used on thousands of different articles. I tried to start a discussion on the talk page to make an edit that I think might actively prompt people to go hunting for sources. However, due to concerns that it might constitute advertising and due to the high-visibility of the edit, it was suggested to bring the discussion here.

Here is my original proposal:

I was wondering if the template could include links to the three big search engines (Yahoo, MSN and Google) to prompt people to start searching for sources. I chose those three search engines, because those are the search engines that Wikipedia already chooses to use as part of its searching system: see http://en.wikipedia.org/wiki/Special:Search?search=googleblat
I've created a proposal so that people can see what I mean before implementing anything: Template:Unreferenced/Proposal
The template essentially plugs the article name into the search engine as a search term. Could lead to useful results, or at least represent a good starting point to refine the search terms used...

I suggest keeping the discussion here rather than putting it on the template talk page. Looking forward to comments.GDallimore (Talk) 13:07, 2 May 2007 (UTC)

If worded carefully, this might be a useful change. It would have to be very carefully worded to avoid advertising though. What sort of language were you thinking of? ~ ONUnicorn(Talk|Contribs)problem solving 18:00, 2 May 2007 (UTC)
Oh, I see the link to your proposed wording. I don't care for that language - it does sound advertisy and makes it look like only internet sources are required. How about something more along the lines of "You can help! Google, Yahoo and MSN might be good places to start." Though I still think that's a little ady. ~ ONUnicorn(Talk|Contribs)problem solving 18:03, 2 May 2007 (UTC)
I don't like it. It sends the wrong message - Internet sources should not be used exclusively, and are indeed generally somewhat unreliable. Nihiltres(t.c.s) 18:22, 2 May 2007 (UTC)
Maybe a template can be created to search http://www.worldcat.org/ and then be added to Template:Unreferenced alongside the Internet search engines. --Iamunknown 18:29, 2 May 2007 (UTC)
Most readers know how to use general search engines so linking to them isn't very helpful. More specific ones that they may not be familiar with, such as Google News and Google Scholar, should be much more useful for finding reliable sources. The template currently links Wikipedia:WikiProject Fact and Reference Check. Instead of linking one specific WikiProject, there should be a central page on referencing with convenient links to other pages like Wikipedia:Newspapers and magazines request service and Wikipedia:WikiProject Resource Exchange. –Pomte 19:53, 2 May 2007 (UTC)
I actually don't find Google Scholar to be all that helpful as I usually only get abstracts rather than full text of the papers. But I like the idea of pointing to resources that can be used to find potential sources, and maybe pointing to resources that can help them figure out the how of citing ones sources in Wikipedia (something like Wikipedia:Citation templates). We don't want the template to get too crowded though. Maybe we should put together a page of links that are helpful for finding sources and link to that page. It could link to the "big three" search engines, Google Scholar, and more specific things like Chronicling America, and internal links like to the citation templates. However, that would eliminate the usefulness of the posters original idea, which was to format the links in such a way that clicking automatically takes you to relevant search results. ~ ONUnicorn(Talk|Contribs)problem solving 20:10, 2 May 2007 (UTC)
I've made a couple of changes to the wording of the template. This isn't intended as final, but is just a first stab at softening the wording. Maybe a fourth link could be added to the list of other resources that are being suggested.GDallimore (Talk) 21:47, 2 May 2007 (UTC)
Had a thought and made a couple more edits to {{Unreferenced/Proposal}}. It now uses exactly the same wording as the Wikipedia search screen and includes a possible way to link to an article that suggest other resources. That article should include at the top "your local library" or something. :) GDallimore (Talk) 21:59, 2 May 2007 (UTC)
To me Search for "article title" on Google, MSN or Yahoo!, implies the search will result in finding Reliable sources which is far from the case. If an editor knows what a reliable source is they will know where to find it. If they don't know there is no reason to point them towards a million unreliable sources. Jeepday (talk) 02:54, 3 May 2007 (UTC)
The template already includes a link to explain what reliable sources are. If people find unreliable sources, they'll be removed, that's the way Wikipedia works, but at least it will prompt people to start looking. GDallimore (Talk) 08:57, 3 May 2007 (UTC)
Take a look at today's featured article, William Monahan. Almost every reference in it is an Internet reference, with online articles by the Boston Globe and other reliable sources. The Internet is invaluable for articles about relatively recent things, people and events so it's hardly a useless thing to do to include links to search engines to be able to find whether it was the Boston Globe or the New York Times that printed an article about Mrs Jane Untermyer and her unusually large cat. GDallimore (Talk) 09:59, 3 May 2007 (UTC)
not wise. Internet sources are notoriously unreliable. Further, this sends the message that online sources are more important than offline sources (the reverse is usually true), and that just using the internet to source your article is sufficient. 86.31.103.208 12:59, 6 May 2007 (UTC)
Somewhat disagree with the last comment. Internet transcriptions of reputable sources (newspaper articles, scholarly documents) should always be online if at all possible. Its all very nice to put a book as a reference, but 99.9% of all Wikipedians (and even 99% of all Wikipdians watchlisting the article) are unlikely to posess said book. Online sources are a good way to add to the hard-to-check other references.
As regarding the original proposal, may opinion is: do NOT provide direct links, but the idea of linking to a main search help page on Wikipedia is a good one. Just don't clutter up the template too much. MadMaxDog 10:14, 7 May 2007 (UTC)
I think this would most result in people adding bad sources (especially Wikipedia mirrors!) to articles that have no sources, and then the unreferenced template will be taken out, and there'll be no way to identify the articles. — 128.119.127.137 21:17, 11 May 2007 (UTC)

Terrible idea. We don't need to tell people how to search for sources. If anyone looks at one of the search engine links and thinks "OH WOW! I never thought to do this before!", they aren't the type of person I would want editing Wikipedia. --- RockMFR 19:18, 13 May 2007 (UTC)

There are {{find}} and {{search}} templates, however I would suggest they are better placed on talk pages. Addhoc 12:21, 19 May 2007 (UTC)

Biography Barnstar award

It seems odd to me that maybe one of (if not the) biggest projects out there, WikiProject Biography, doesn't yet have a Project-specific barnstar. If nothing else, the amount of work required in keeping such a project running seems to me to merit at least the potential of such an award. Unfortunately, I, who have trouble hitting the right key let alone making images, am probably not the best person to try to create it. But, taking the obvious approach here, maybe the File:Crystal personal.png could be superimposed over the center of a barnstar? John Carter 18:25, 19 May 2007 (UTC)

How does Image:Biographystar.png look? Mr.Z-mantalk¢ 18:48, 19 May 2007 (UTC)
Twenty-three minutes from proposal to existence?!? I am stunned and very grateful for the speed of the response, and I think it looks wonderful. Does anyone know of what further steps (if any) have to be undertaken for this to be approved? John Carter 18:57, 19 May 2007 (UTC)
(I had nothing better to do) I'm dropping a message now on the Project talk page about it. The old barnstar approvals page was marked as histroic recently, so now the project just has to decide what to do with the image. Most are put into templates so they can easily be subst'd on user talk pages. Mr.Z-mantalk¢ 19:04, 19 May 2007 (UTC)

Individual Comic Book Pages

I do not know if pages that discuss individual issues of comic books are wanted. For my own personal reference, I have made summaries of many comic books, and was considering posting them. Pages for comic series, i.e. Detective Comics, exist, but individual issue pages, i.e. Detective Comics #27, do not. Are these wanted, or not? --TheCoolestDude 16:11, 7 May 2007 (UTC)

Most likely non-non-notable. Maybe ask Wikipedia:WikiProject Comics about what has happened before with any such articles, an example of which is Dragon Ball Z: Volume 1. It should be better to combine individual summaries into the main article, as long as it doesn't get too long. –Pomte 21:54, 11 May 2007 (UTC)
I am dubious about articles for individual TV episodes, or fictional characters, see WP:FICT, which i generally support; and this seem less desirable than those. i would think this would be a bad idea except in some extraordinary circumstances (if a particular issue is very famous, perhaps because it sold for a very high sum, or was very different from other issues and had significant mainstream media coverage). But normally i don't see why mentions in an article about the series isn't sufficient. There are other wikis where more detailed coverage might be plausible. DES (talk) 22:02, 11 May 2007 (UTC)
I think starting a page on Detective Comics 27 with a summary and prices it's sold for would be a valuable addition to Wikipedia, but I think the vast majority of comic-books are not individually notable and as such probably shouldn't be added. -Halo 19:52, 13 May 2007 (UTC)

As far as doing page on individual books, i say go for it! I would suggest making a "Notable Issues" Section or something similar on the series page, and have links to those issues where a summary would be desirable... Just my two-cents, but I hope it's worth something! Tylerofmaine 17:55, 17 May 2007 (UTC)

IIRC, according to Wikipedia's notability policy, if a publication has over a certain number of copies published, then it is notable. So, if there are more than 5,000 copies of a comic book distributed, then it is notable. And if it's notable, it has a place on Wikipedia. The Transhumanist    20:18, 19 May 2007 (UTC)

Unsupported Characters

Hey, new user here.

Numerals and letters of alphabets, Latin or otherwise, are included in the database. For example, there is a search result for the keyword (perhaps it could be called a key-letter!) 'D', whereas characters such as ':' and ';' are unsupported and have not any results. Why not change that? There are links to pages started with that particular prefix, but what if someone actually wants information on the character ':' used for punctuation?

If one Googles ':', there is no result, which somewhat surprised me, but when one Googles 'punctuation symbols', there are 967,000 hits (the first one, of course, is the Wikipedia article).

Discuss. Any suggestions or comments? — Preceding unsigned comment added by Obssessedlinkfan (talk • contribs) 18:13, 20 May 2007

It's not necessarily that easy to change. Allowing colons in the search box would require a major technical change to how linking is done, which will cause a lot more trouble than being unable to search for ':' ever will. -Amarkov moo! 18:20, 20 May 2007 (UTC)

Cascading Protection on copyvio

Should {{copyvio}} be put on a cascading protected page so that all pages that have copyvio template on it can only be edited by admins, since the template says not to edit it until an admin fixes the problem? --R ParlateContribs@ (Let's go Yankees!) 21:30, 20 May 2007 (UTC)

That wouldn't work, since cascading protection works the other way - if the template was cascade-protected then only the pages that were transcluded onto the template page itself would be protected.
Also, even if this was possible, it still shouldn't be implemented because it would mean that anyone could go around protecting whatever pages they felt like just by putting {{copyvio}} at the top of them. Tra (Talk) 21:40, 20 May 2007 (UTC)
I know protecting the template wouldn't do anything. I said put the template on a cascading protected page. --R ParlateContribs@ (Let's go Yankees!) 00:03, 21 May 2007 (UTC)
Sorry, I must have misunderstood you. Putting the template on a cascading-protected page would have the same effect on the template as cascade-protecting the template itself. The template would be locked from editing but other pages that transclude it would be unaffected.
Unless you're suggesting that the pages with the copyright problems themselves are cascade-protected individually in addition to the template being added. If that is the case then there probably wouldn't be any need for the protection to be cascading - just normal protection should be enough. Tra (Talk) 00:22, 21 May 2007 (UTC)

To clear this up: if template A is transcluded on page B, cascade-protecting page B will protect template A, but cascade-protecting template A does nothing to the protection status of page B. (In other words: what Tra said.) --ais523 10:05, 21 May 2007 (UTC)

Vandalism warnings template syntax

As I've increased the number of pages on my watchlist, I've been seeing and reverting vandalism more often, and thus using the warning templates more often. However, I occasionally forget to add my signature to the warnings, making it look rather odd if HagermanBot doesn't come around. I'd like to know: would it work to add a ~~~~ to the coding for the warning templates? Nyttend 15:45, 17 May 2007 (UTC)

It could be made to work, but then there'd be loads of instances of double-sigging warnings. Also bear in mind that some users don't sign with the four-tilde abbreviation, but instead use a script, or copy-and-paste it in, or even type it out manually. --ais523 15:50, 17 May 2007 (UTC)
Apparently a bunch of users were adamntly against having the signature included inside the template. Ask at Wikipedia talk:WikiProject user warnings for specific past discussions. –Pomte 03:58, 21 May 2007 (UTC)

Merger proposal regarding pokemon articles

As the existence of things like WP:Pokémon test and Wikipedia:Poképrosal can attest, there has been some resistance to the fact the all 493 individual pokemon have their own articles, even though many of them will never garner much more information than they have now. After several months of discussion, many members of the related project (WP:POKE) have agreed upon a way to merge many of the articles. To prevent split discussions, all wikipedians are invited to review and comment on the guidlines proposed at WP:POKE/Layout. -ΖαππερΝαππερ BabelAlexandria 17:49, 21 May 2007 (UTC)

Index to important talk page discussions proposal

Has it ever happened to you that you had some idea about a guideline, policy, or wikipedia process only to later discover that three years ago 500 people already thoroughly discussed the issue? Have you ever been frustrated at the annoying tediousness of digging through archives in search of a debate you remember happened there?

Well, my solution is simple. Let's create a Wikipedia:Index to important historical debates (or whatever name is better). It would be an alphabetical list organized by topic and description. An example entry would be:

  • Main page - non-free images on, [links go here]; layout [more links]; selection of content on, [yet more links] etc.

The index would be very incomplete at first, but in typical wikipedia fashion, I expect it to grow and become very useful, especially as Wikipedia continues to develop and people start forgetting older discussions. It would also solve the problem (with which we are all familiar) that there is no set talk page for discussions of any number of issues, and debates have sprawled throughout the wikipedia namespace. What do people think of this? Any other suggestions? nadav 11:14, 18 May 2007 (UTC)

that sounds like a good idea, but I think it might be better implemented on the project talk page instead. If I'm looking for historical AfD discussions, I'll probably be looking at WT:AFD first. howcheng {chat} 20:51, 18 May 2007 (UTC)
Yes we can do that instead. In any case, this will take a lot of work. It might be best to create a formal wikiproject for this, so we can have templates and everything, say WikiProject Discussion Indices.

As further proof that this index is needed, I have just discovered that Radiant, in her infinite wisdom, has already thought of this a long time ago and created Wikipedia:Centralized_discussion/Conclusions. See, now I wish I had access to the index earlier so I could've checked discussion of this issue and not reinvented the wheel! nadav 11:25, 19 May 2007 (UTC)

  • Why thank you! I think what you're looking for is really CAT:G. Many important discussions are preserved as guidelines (if they had a practical outcome, at least). >Radiant< 13:42, 21 May 2007 (UTC)

AIC Hazzard 2; Request

AIC is meant for users to go to to post a new article so other wikipedian's can help in the making of the article. I have some requests for the article.

1- A protective covering for the articles posted on the AIC. the articles are supposed to be incomplete or have nothing more then just a structure for others to follow, or else it doesn't really need other's help, but this can cause delection tags to appear. So a protective cover against delection might be needed.

2- multiple links so people can find out about AIC. AIC needs people to post new articles on it, and AIC MUST have wikipedians to help the new articles.

3- AIC can be found only by typing it's name in {Article in Construction} but other names for people to find it by would be very helpful, names including AIC, AC, what ever comes to mind.

These requests are very important to the future of this article. — Preceding unsigned comment added by Nikro (talk • contribs) May 22, 2007

Perhaps navigation to AIC should be offered as an option on the No page with that title exists page. -- Boracay Bill 01:27, 22 May 2007 (UTC)

Internal article references

Hello.

I notice that your articles can make reference to other articles. However, the other articles make no reference to the referencing articles.

For example. The article on Strategic lawsuit against public participation (SLAPP) (http://en.wikipedia.org/wiki/SLAPP) makes reference to the Oprah Winfrey page (http://en.wikipedia.org/wiki/Oprah_Winfrey), but the Oprah Winfrey page provides no indication that it is being referenced from the SLAPP article.

I have written applications that make such two way linking the norm. Yet Wikipedia seems not to support it.

Just a suggestion.

Kurt Christensen

Kurt... if you click on "What links here" in the toolbox panel, it will show all the articles that reference the one you are in. Blueboar 19:35, 21 May 2007 (UTC)

Start informal campaign to purge Wikipedia of bad grammar/spelling

It might be a good idea to get people to volunteer to occasionally scrub Wikipedia of some common grammar and spelling mistakes. For instance, I just fixed several pages of "protray" spelling mistakes when "portray" was meant (still several pages to go). I picture a place where people can sign-up to monitor some common grammar/misspelling problems. If two or three people each volunteer to monitor each proposed mistake (it would only take a couple minutes every month or so per person), Wikipedia's quality might improve dramatically. I've noticed that people or bots must already fix many common errors but finding typos that have apparently never been searched for isn't very difficult. Userboxes could be made to identify volunteers and to locate others of the same task. They might say "This user makes sure 'portray' is spelled correctly." etc. I've been a grammar/spelling gnome for a while now and I've noticed that many of the pages I correct are low visitation pages that go months between edits. The higher visitation pages get people frequently checking of their spelling. Global spelling fixes tend to fix typos that would otherwise linger for a long time. I'm aware of the problems of blindly fixing "typos", which is why I think a person should monitor each spelling/grammar fix. My idea is an organized version of that. Probably would let somebody else implement. Jason Quinn 03:02, 15 May 2007 (UTC)

The AutoWikiBrowser can help you with this. –Pomte 03:08, 15 May 2007 (UTC)
Thanks. (that was quick!) I was wondering if something similar in function to my idea already existed. Jason Quinn 03:11, 15 May 2007 (UTC)
Coincidentally the other day I typed "occurence" in the search box, and Wikipedia reports an astonishing 122,808 hits. That's a huge amount of work. I wondered if there was any automated way all these could be fixed. The problem is that there may be a very few cases when "occurence" is correct (e.g. in a literal quote, probably with "sic", or when the misspelling is being discussed). The program would have to be clever enough to identify these. Matt 11:15, 15 May 2007 (UTC).
Actually, on further investigation it seems that this figure is incorrect. I think that Wikipedia search is for some reason also picking up instances of "occurs" and other legitimate variants. Matt 11:33, 15 May 2007 (UTC)
It's also because our search box sucks. ^demon[omg plz] 03:39, 22 May 2007 (UTC)
Automatic spelling-correction programs aren't permitted because there would be too high a risk of false positives. Manually-assisted spelling correction problems (i.e. where it asks a human whether to correct on each 'occurence') are permitted, and I think several of them are being used. --ais523 11:28, 15 May 2007 (UTC)
You might also be interested in Wikipedia:Typo, a department that acts rather like what you've suggested. --ais523 17:11, 15 May 2007 (UTC)
One reason why full automation would be wrong is that the incorrect information may be a quote. It would be absolutely wrong to correct spelling or grammar in a quote (unless the quote is inaccurate, something requiring detailed reading of sources). (But adding [sic] can be a good thing). In talk pages and user pages it would be just wrong. 08:35, 16 May 2007 (UTC)

Deleted

My two articles, AIC and Scientific Beliefs were delected without my knowing of it. AIC was treatened once, but the poposal to delete the article failed, AIC had nothing in it that gone against the policys, and there wasn't a project/article similar to it. AIC's threat was stop, so they place a speedy deletion on it. and Scientific Beliefs was on AIC, meaning it was incomplete, still being worked on and they placed a speedy deletion on it before it could be completed. Please do something about this, and if possible, bring back my articles, mainly AIC, it was not disobeying the policies in any way! — Preceding unsigned comment added by Nikro (talk • contribs)

Scientific Beliefs was redirected to Science. Looking at the article that you created - [1] - this article doesn't exactly appear to have been ready for prime time. Anything in article space needs to be such that if a reader looked at it, they would see it as something of encyclopedic quality, not just as an outline of an article. Also, please see our policy on original research. Wikipedia is not the place for your own views or interpretations - ideas in articles need to be attributed to a reliable source. As for AIC, it seems to have been discussed above. Self-referential topics or "meta" topics are kept out of article space. Instructions on writing articles or project coordination topics all go in Wikipedia: space. --BigDT 13:31, 22 May 2007 (UTC)
It looks as if the editor actually wanted to start a list such as List of scientific theories. Although there was a lot of WP:OWN in the original article ("don't change structure unless you absolutely have to") it could be an interesting project that wouldn't have been WP:OR. I personally would view it as completely impossible task to create such a list but if someone else wants to give it a go, I think it could make an encyclopedic article. GDallimore (Talk) 13:40, 22 May 2007 (UTC)
Nikro... I mentioned this above, but will do so again here. If you have an idea for an article, and want it "protected" from deletion while it is "incomplete" (ie you are still working on it), create a sub-page attached to your user page, and work on it there. You can transfer it to the main article space once you think it is complete. Also, please note that once an article is placed in mainspace, it is inappropriate to call it "my" article... it belongs to all of us. Blueboar 14:45, 22 May 2007 (UTC)

Video on Wikipedia

Hi all. Someone has proberly come up with this before but how about wikipedia has short videos on educational subjects like an egg hatching or the different earthquake types. If we did this it would be comparable to microsoft encarta. Of course there would be problems like people uploading irrellevent stuff or working out who should have the powers to upload the correct videos but if we got past that it would be an even better encyclopedia with people seeing how it really happens and for those people who learn from watching rather than just reading!Wiki.user 19:47, 21 May 2007 (UTC)

You may be interested in the Video policy on Meta-wiki. Nihiltres(t.c.s) 20:42, 21 May 2007 (UTC)
Uploading of videos is allowed and encouraged. You have to use Ogg Theora, though. Night Gyr (talk/Oy) 23:30, 22 May 2007 (UTC)

Wiki-automation. Update facts from their source pages automatically on other pages using author-defined variables.

This was an e-mail sent to Wikipedia by me. I do not know how Wikipedia works in terms of code, but I had this idea that could help:

"While reading the Oprah Winfrey wiki, I read "Although blacks are 12% of the U.S. population, Winfrey has remained the only black person wealthy enough to rank among America's 400 richest people nearly every year since 1995."

I immediately questioned the statistic, and had the idea that perhaps that "12%" should be automatically updated by the US census wiki.

Such as, on the US census wiki, variables could be defined by the authors and then used by other wikis. So, say that on the US census wiki you have a variable for total US citizens, and total black US citizens. The Oprah Winfrey wiki authors could use those variables in their wiki to come up to the percentage automatically. That way, when the US census wiki is updated, the Oprah Winfrey is automatically updated as well.

This may be a poor example, but the idea would save a lot of time and bring accuracy to more wikis.

Sincerely, Daniel Matthews"

My concern is that massive transclusion of data would greatly facilitate vandalism - change one variable and you would vandalize many pages simultaneously. The solution for many critical templates on Wikipedia has been to protect them - see for example {{!}}, a prominent metatemplate. Protecting such numbers in any similar system would undermine the openess of the wiki, which is a major problem - free editing is one of the five pillars. Nihiltres(t.c.s) 03:42, 21 May 2007 (UTC)
However, this sort of transclusion is occasionally done anyway. --ais523 10:08, 21 May 2007 (UTC)
If your writing includes a statistic that can date easily in many places, you're doing it wrong. That would be better phrased with a specific point in time attached to both her wealth and the black population number. Night Gyr (talk/Oy) 14:53, 21 May 2007 (UTC)
that is true, but says nothing of articles that are discusing present conditions. -ΖαππερΝαππερ BabelAlexandria 18:08, 21 May 2007 (UTC)
When discussing present conditions, you still give a date. Like today's date. Then it can be updated as needed. Carcharoth 01:54, 23 May 2007 (UTC)

A new Term to Coin

I wish to establish a new term in the tradition of terms that have entered the world vocabulary such as "politically correct" and "environmentally correct". The term is "carbon correct" to be used to suggest that efforts and disourse to reduce or offset carbon emissions is often a complex problem with many competing variables. Or the term could be used sarcastically to disparage the claims of those who say they can drive their SUVs without guilt because they have purchased carbon offsets without knowing whether such offsets are effective or efficient or preferable to alternative means to reduce carbon release.

submitted by scarman50

This page is for proposals related to Wikipedia, not general proposals about life. However, I think that we generally refer to things like you are talking about as "green" or "Environmentally friendly". —METS501 (talk) 00:34, 22 May 2007 (UTC)
Wikipedia is not the place to establish new terms or usages for terms. Even if lots of us liked your term "carbon correct", it would be a neologism... a new coinage of a word or term... and we aren't supposed to use neologisms in Wikipedia. Before we can use it here, you would need to demonstrate that it has been widely used in the world beyond Wikipedia. Blueboar 14:33, 22 May 2007 (UTC)
I don't believe this is the right place for you to try and coin a new term in language. Jmlk17 20:22, 23 May 2007 (UTC)

American, British, etc. idiom template

There appears to have been many debates over British v. American, etc. spelling. The proposal to minimize this debate is:

  1. Create a template such as {{idioms | American=color British=colour}}
  2. Allow users to control which version they see based on their Monobook.js file
  3. When a new account is created, set the default using one of the following systems
    1. The country the IP block resolves to
    2. Set American English as the default since it is probably more common among 'pedia users
  4. Example 1, one current solution: Color (or colour, see spelling differences) is the visual perceptual property corresponding in humans to the categories called red, yellow, white, etc.
  5. Usage would then be: {{idioms | American=Color British=Colour}} is the visual perceptual property ...
    1. British English speakers would see "Colour is the visual perceptual property..."
    2. American English speakers would see "Color is the visual perceputal property..."
    3. Other variants could be added. The list of allowed idioms would probably need to be controlled through the template page to avoid vandals adding 'humorous' idioms.

Antonrojo 12:51, 17 May 2007 (UTC)

There's a good reason not to do this in the example you give - it can be useful to know the different spellings that are used (without having to edit the page to see the template).
Could the servers handle the huge number of template calls that this would require for a Wikpedia wide roll-out? Dunno the answer to this.
What might be an idea is to use a template along those lines for the first example of a particular word in an article and the template works so that, if a person then rolls their mouse over the word, the other spellings could pop-up. That might solve both my issues with the idea. Don't know if there are others, though. GDallimore (Talk) 15:08, 17 May 2007 (UTC)
I had not considered either of those issues. A 'no idiom' setting that displays all idioms could be an option though I do not know what this would look like. Regarding the server load, the fact the template simple substitutes text rather than generating graphics, tables, etc. might avoid that problem.
Also, a user over at Talk:Yoghurt just informed me of a similar template {{sp}}. Antonrojo 15:56, 17 May 2007 (UTC)
I don't think this is necessary. Spelling differences are minor and not confusing to anyone. If people are that offended by seeing a different spelling than their own then they should just get over it. As for words with different meanings/not used in on version of English, then a synonym can be used instead. Koweja 15:59, 17 May 2007 (UTC)
{{ADCE|year}} (which appears as {{ADCE|year}} to you; if you haven't customized your monobook.css, it displays both) never really caught on (only one transclusion, and it's in userspace). I don't expect this would either. --ais523 16:00, 17 May 2007 (UTC)
I personally do not think that it is necessary. The {{sp}} template does not seem to be in popular use (I haven't encountered it before), so I somehow doubt that this would be used either. Besides, spelling like this is but a trifle. -- Cielomobile talk / contribs 23:40, 17 May 2007 (UTC)

A possible solution would be the previously suggested rollover idea. If users are really that concerned with the spelling, they could roll over the disputed word, click on it, choose their spelling preference, and all subsequesntly accessed wiki pages could use that spelling, unless the integrity or accuracy of the article is reliant on the local spelling of the word. For instance, if the term 'autumn' was used in an article, the alternative 'fall' could be presented. Unless a song lyric, quote, or other literary work or such like was being quoted, then of course, the original word would stay, without alternative language preferences being offered.

If you were to create a template that didn't alter the appearance of the words unless the user set up their monobook preferences, this could be ok. I would drop any suggestion that US spelling should be the default though. Addhoc 12:25, 19 May 2007 (UTC)
I'm an American, and I don't believe the colour, nor the centre of anything really matters. We speak the same language, so it's all good in the end. :) Jmlk17 20:15, 23 May 2007 (UTC)

Links currently can be of two forms:-

  • [[xxxx]] = link to page xxxx, display xxxx
  • [[xxxx|yyyy]] = link to page xxxx, display yyyy.

But sometimes a link format [[xxxx|yyyy|zzzz]] = "link to page xxxxyyyy, display xxxxzzzz" would be useful, e.g. [[incinerat|ion|ed]] would link to incineration and display incinerated without having to repeat the whole of a page name which may be long. Anthony Appleyard 20:19, 14 May 2007 (UTC)

Not a bad idea, but also why not just make a redirect from incinerated to incineration (which is apparently currently the case)?↔NMajdan•talk 20:24, 14 May 2007 (UTC)
Some editors seem to take a dislike to links that make use of a redirect and change them as they would a link to a disambiguation page. I don't mind them at all (notwithstanding any possible increase in server load, which I'll leave to experts to comment on). Adrian M. H. 20:41, 14 May 2007 (UTC)
I think that although this proposal may have some merit, it's not a very intuitive system - I don't think it would help much in practice. Oh, and there's another link format: [[zzzz:xxxx (yyyy)|]] = link to page zzzz:xxxx (yyyy), display xxxx, if "zzzz:" is a namespace. Works without either of "(yyyy)" or "zzzz:" too. Nihiltres(t.c.s) 01:57, 15 May 2007 (UTC)
Support - It's not intuitive, but it's not difficult to use either. If it is documented well people will catch onto it and use it. There is a need for it. --EMS | Talk 02:58, 15 May 2007 (UTC)
Oppose; I think we should reserve this syntax for something more useful. I actually had a really good idea as to what that would be, but it's slipped my mind. — The Storm Surfer 04:38, 15 May 2007 (UTC)
Oppose; covered already by redirects and the [[xxxx|yyyy]] notation. Nihiltres(t.c.s) 20:44, 15 May 2007 (UTC)
Oppose; no point. HighInBC(Need help? Ask me) 22:43, 15 May 2007 (UTC)
Oppose; same as The Storm Surfer, even though it's neat. Sorry. ~EdBoy[c] 02:01, 16 May 2007 (UTC)
Oppose; this saves a handful of keystrokes, and in the process provides still anothing thing for new editors to learn how to understand when they come upon it. The benefit to a few doesn't seem to be worth that cost. (In general, the issue of added complexity is not considered nearly enough). Notinasnaid 08:39, 16 May 2007 (UTC)
Oppose; I don't even like links like [[thi]]s or [[even (this)|]]. I'd trade a few keystrokes and a little visual clutter for a consistent and easy-to-learn one-rule syntax any day. Dcoetzee 13:33, 18 May 2007 (UTC)
Strong Oppose; It would take me a bit of time to get used to and I'm sure others would not appreciate changing it when it really doesn't do much. Jmlk17 20:13, 23 May 2007 (UTC)

Naming conventions (Indic)

Wikipedia:Naming conventions (Indic) should not be tagged as "inactive". It is being actively linked to as guideline. It was tagged as "historical" because there was no "active debate". I find this strange, because the absense of debate does not necessarily mean the page is obsolete. It may also mean, incredibly, that there is consensus and the page is stable. dab (𒁳) 07:01, 25 May 2007 (UTC)

You appear to be correct. Be bold and remove the inactive tag! YechielMan 13:50, 25 May 2007 (UTC)
Good advice Yechiel...only by being bold can this project keep growing and changing as much as it has the potential to. Jmlk17 20:49, 25 May 2007 (UTC)

Bring back the Horror collaboration of the month?

Wikipedia:Horror_collaboration_of_the_month was a valuable page that helped improve several articles greatly, and bring about some featured articles. I'm not sure how I can see why it was made historical - the horror wiki project still lists it as active on its main page. Could some other Wikipedeans chime in and say whether it could be brought back or not? Thanks Desdinova 23:34, 17 May 2007 (UTC)

If you can find other people who are interested in collaborating for horror articles, by all means get together and improve an article. That page was marked historical, I believe, because interest in the collaboration abated acutely. It seems as though modeling the page after WP:ACID may have caused its decline, since the ACID model is based on a significant amount of traffic. I have no problem with resurrecting the collaboration, so long as people are interested in working on the articles. GracenotesT § 03:38, 18 May 2007 (UTC)
Thank you! I'll see what I can drum up! Desdinova 10:35, 18 May 2007 (UTC)
Good luck! Jmlk17 02:51, 25 May 2007 (UTC)

Unclear status of Wikipedia:Reliable sources/examples

This useful page seems partially forgotten, and has no clear status, I have labelled it with 'proposed'. See also my comments at relevant discussion page about how it ties to aspects of WP:ATT/FAQ.-- Piotr Konieczny aka Prokonsul Piotrus | talk  17:32, 25 May 2007 (UTC)

Reliability noticeboard proposed

See Wikipedia_talk:Reliable_sources#Reliability_noticeboard for a proposal about a new noticeboard, a kind of RfC for discussion of reliability of specific sources.-- Piotr Konieczny aka Prokonsul Piotrus | talk  17:24, 25 May 2007 (UTC)

Ability to gauge quality of information

A simple way to gauge the quality of the information in an article, or more accurately the extent to which the information is accepted, would be to measure the number of edits in proportion to the number of visitors. The theory is that the greater the number of people viewing the article the more opportunity there is to make corrections. Therefore, an article that is viewed by many but edited by few contains widely accepted information. However, an article that contains many edits in proportion to the number of viewers contains more dynamic and less accepted information. A more static article is expected to be more accurate.

These measures would need to be constrained to a period of time. For instance, the number of viewers and editors could be from the past day, week or month. An analysis of the frequency of edits of existing articles would likely reveal an optimal period of time based on the article total lifespan. For example, the quality of information in an article that is only a month old may be measured by activity in the past two weeks, whereas an article that is a year old is measured based on activity in the past month. There are lots of options for determining the time frame.

The resulting metric could be represented as a rating (low, med, high; 1-5; etc) near the title of each article to indicate to users the reliability of the information they are reading. Metrics could also be produced for each independent block of an article to give a more granular measurement since the blocks are edited independently of one another.

Unfortunately, due to server resources, we don't track the number of visitors to each page. —METS501 (talk) 00:35, 22 May 2007 (UTC)
The server logs should contain the number or requests for each page. If Wikipedia has customized those log files it wouldn't require a great deal of resources to track this info - 65.196.71.3 14:57, 25 May 2007 (UTC)

Watchlist Categories

I currently have 115 items on my Watchlist. What I think would be useful would be a way to group items into categories such as Radio, TV, Wikipedia (pages like this for example), Education, Computing etc.

The you could select the category and see if any changes have been made to set pages rather than having a long list of changes. pjb007 14:27, 20 May 2007 (UTC)

Here's a "low-tech" way to do it. Create alternate accounts, such as User:Pjb007a, User:Pjb007b, and so forth, and put on the user page a link to your main account. (This is permitted per WP:SOCK.) Then create a separate watchlist for each user account. YechielMan 16:16, 20 May 2007 (UTC)
Only 115 items? This survey might interest you then. Adrian M. H. 17:17, 20 May 2007 (UTC)
That sounds like an interesting userscript project. I guess it would be a major PITA to design a even marginally efficient way to store and retrieve dataset<->location pairings though (especially with bigger watchlists where this would be most useful). -- Seed 2.0 19:58, 20 May 2007 (UTC)
Use related changes to achieve a similar effect to what you're saying. Place links to all the articles that you would want in one group on a user subpage, and when you're viewing that page and click "related changes" in the toolbox, you'll see a watchlist-type pages as if only those pages were on the watchlist. —METS501 (talk) 21:47, 20 May 2007 (UTC)
It seems like a good idea, if it was in a user script, and not something that is default in your watchlist. I would prefer categorising by namespace but even then it would only be useful if you have a high amount of articles in your watchlist. –Sebi ~ 10:09, 25 May 2007 (UTC)

Hiding Footnotes/References/Notes

As you all know, most articles have references, notes or footnotes at the end of the article. But some articles have a massive list such as Spider-Man 3 and Virginia Tech massacre. They take up a lot of room, so perhaps, could we start using the hide tag: 

{{hidden begin|header=header}}

{{hidden end}}

to hide it, to save space? Just a thought. — « hippi ippi » 05:27, 20 May 2007 (UTC)

I don't think you'd get any benefit, they're tucked away at the end after all the content anyway. As for spider-man 3, that article has too many references, many of them are used only once to cite little things that are probably covered in any of the other reasonably complete references. I'd like to see some consolidation and pruning going on to make it less crowded. Night Gyr (talk/Oy) 05:40, 20 May 2007 (UTC)
This has been tried in the past, and as I recall if they are hidden by default it breaks the footnotes -- i.e. when you click on a footnote you are not taken to the reference. Christopher Parham (talk) 20:56, 20 May 2007 (UTC)
Oh... okay. There goes my (unoriginal) idea. Ok then, I'll live. — « hippi ippi » 10:58, 21 May 2007 (UTC)
I agree with Night's comments. To be honest, I'd rather see a huge list of references then see an article with a huge amount of whitespace. As Night said they are tucked away at the bottom, so I don't see any good reason why they should be hidden. –Sebi ~ 09:53, 25 May 2007 (UTC)

Sandbox name?

What would everyone think of changing the name of the sandbox? Right now, Sandbox gets nothing but vandalism. There are plenty of warnings that this article is not the place to play around, but people do so anyway. No article exists by the name of Edit test area, so if we renamed the sandbox to Wikipedia:Edit test area and made Edit test area a protected redirect, that might cut down on the mainspace test edits. --BigDT 22:58, 25 May 2007 (UTC)

I don't agree personally. I think Sandbox is a cool name, and it is meant to be a test area anyway, so why does it matter if someone adds some junk to it? It is reverted almost immediately anyway. Jmlk17 23:21, 25 May 2007 (UTC)
You misunderstand. The article Sandbox gets vandalism because people go there looking for Wikipedia:Sandbox. The problem isn't people vandalizing the page in Wikipedia: space - the problem is people vandalizing the article. --BigDT 23:25, 25 May 2007 (UTC)
It doesn't seem like that much vandalism. If it gets higher, just semi-protect. As people usually using it have just created an account, semi-protection will work, since editors must be autoconfirmed to edit semi-protected pages, and if I remember right, auto-confirmation takes 4 days. Any other people doing editing tests probably know they're at the wrong page. --R ParlateContribs@ (Let's Go Yankees!) 23:56, 25 May 2007 (UTC)
We could introduce some sort of message that appears when you are editing the article stating "If you are making a test edit, please use Wikipedia:Sandbox" or similar. –Sebi ~ 00:05, 26 May 2007 (UTC)
Also, we can't keep reverting test edits on the article without letting the test editors be notified that they are at the wrong page. The small italic note at the top of the article doesn't seem to suffice. –Sebi ~ 00:10, 26 May 2007 (UTC)

New template for global perspectives task force

I am posting here to let the community know about the creation of a new template that is being used by the Global perspectives task force of the Project on countering systemic bias. This template will be placed on talk pages to let editors know that the task force is actively working to improve the global perspective of an article. In that sense, the template will work in concert with the existing cleanup templates, which are typically put on article pages. I am not 100 percent sure this is the right place to announce this new template, so I welcome suggestions of other places I should post this information. I also welcome any questions or comments about the template or the global perspectives task force. Thanks! --Mackabean 20:21, 25 May 2007 (UTC)

Multiple tags

I've seen a few articles lately that have multiple cleanup tags, and clog up the page alot. Could we possibly discuss a new template that could have multiple cleanup tags all merged into one cleanup tag. I am not proposing that we create a combination template for all possibilities of combinations of cleanup tags (e.g. {{unreferenced-or}}, {{unreferenced-npov}}, etc) but like This article does not {{{1}}} and is not {{{2}}}. or similar. Please discuss pros and cons of this idea. –Sebi ~ 10:01, 25 May 2007 (UTC)

I'm not in favor. I think it's helpful to list each problem separately because it makes it easier to read through them, and it's simple to remove one tag while keeping the others, or to add a new one. If you are concerned about visual clutter - and that is a valid concern - I wonder if there's a way to shrink some of the templates, as was done with Template:Uncategorized. YechielMan 13:48, 25 May 2007 (UTC)
I'm opposed as well. Not all articles need to have multiple tags. Some just need a slight wikify, while not needing to be references. It's a big step to make a page sport many different tags, and it should be a complete mess in order to do so. Jmlk17 20:51, 25 May 2007 (UTC)
See {{Articleissues}}, which was kept at TfD. –Pomte 21:13, 25 May 2007 (UTC)

Naming conventions (Indic)

Wikipedia:Naming conventions (Indic) should not be tagged as "inactive". It is being actively linked to as guideline. It was tagged as "historical" because there was no "active debate". I find this strange, because the absense of debate does not necessarily mean the page is obsolete. It may also mean, incredibly, that there is consensus and the page is stable. dab (𒁳) 07:01, 25 May 2007 (UTC)

You appear to be correct. Be bold and remove the inactive tag! YechielMan 13:50, 25 May 2007 (UTC)
Good advice Yechiel...only by being bold can this project keep growing and changing as much as it has the potential to. Jmlk17 20:49, 25 May 2007 (UTC)

More convenient way to discuss recent edits with other users

Currently it is not very convenient for users to identify and discuss recent edits in an article. I have a few proposals to make the "peer review" process easier, so that more readers will read and comment on recent contributions:

  • To find recent edits, you currently need to go to the history page and do a comparison with a previous version. This could be facilitated by having a direct link to show changes made in the "Last 7 days" and "Last 30 days". Some edits would need to be flagged as vandalism, to prevent them showing up again 7 days later in the comparison.
  • After discovering an edit that requires discussion, you currently have to start a section on the talk page, and explain which edit you're talking about. It would be much easier to have a link from the History page, allowing you to create a discussion automatically (or to take you to a pre-existing discussion). Readers of the discussion could then click a standardized link to see a "before/after" comparison for the corresponding edit, so everyone knows exactly which content they are discussing.
  • When submitting an edit for an article, a user should have the option of creating a corresponding discussion thread. This would be helpful if the user feels that some improvement could be made to the new content, or if it is likely to prove controversial. It would also be courteous to give other users the opportunity to comment after removing unwanted material from the article.
  • Comments posted in a discussion should drawn automatically to the attention of the user who made the corresponding edit.

Mtford 02:00, 27 May 2007 (UTC)

Images

Would someone please be kind as to find some good images for an article I made and an article I Wikified. The article are:

My created article- Gold Coast Art Centre.

The edited article- Gold Coast City Art Gallery.

Please find very suitable, good images for both this articles. Please contact me at my Talk page if you've replied to this request.

§→Nikro 15:29, 26 May 2007 (UTC)

Place {{reqphoto}} on each talk page and/or add a request for each article at Wikipedia:Requested pictures. Adrian M. H. 19:49, 26 May 2007 (UTC)
Good luck...also, this probably wasn't the right area to go looking for image requests, as Adrian was kind enough to give you a template and links. Jmlk17 21:31, 26 May 2007 (UTC)

Image sizing

There's been considerable discussion at Wikipedia talk:Manual of Style#Images regarding bot removals of thumbnail size tags from articles. There appear to be three broad schools of opinion at present:

  1. Thumbnail sizes are inherently evil because they override user preferences - including those of people with accessibility issues e.g. visual impairment. People who want to change from the default 180px should get an account and set their preferences accordingly.
  2. Removing thumbnail sizes is evil. Very few readers even consider getting an account (remembering that only a very small percentage of readers become editors, and relatively few editors become account holders). We should size images so that they're easily legible to the vast majority of visitors. That often means that they need to be bigger than 180px.
  3. Thumbnail sizes are a necessary evil at present because the MediaWiki 180px default size is too small for the average display. On a 1024x768+ screen (most modern PCs), 180px images are little better than postage stamps and are overwhelmed by the text. The minority of users who require small (or very large) images might be easily encouraged to register an account; we shouldn't handicap the encyclopaedia just to cater to the visually-impaired, etc., many of whom are probably already familiar with making accessibility adjustments during their internet usage. The default thumbnail size should be increased to, say, 220px, to reflect the larger average display size of modern computers.

I'm pretty much in agreement with #3. It strikes me that, ideally, two changes would please most people here:

  1. Increase the default image size somewhat.
  2. Allow thumbnail sizing for odd-aspect-ratio images and change the software so that user preferences override article image sizes, rather than vice-versa (is there already a setting for this somewhere?).

Opinions from a broader audience would be welcomed. Cheers, --YFB ¿ 23:25, 22 May 2007 (UTC)

  • My opinion is that there should be a software solution. Editors should have the ability to make some thumbs larger (maps, paintings with small details) and some smaller (simple diagrams, etc.). Users should have an ability to set preference to see thumbs larger (if they have good monitors and Internet connections) or smaller. I would suggest syntax like [[image:..|thumb|150%|...]where the size is set as a percentage to the default image size set in user preferences. If user set default to 300px, the image would be shown as 450px, If user set the default to 100px, the image would be shown as 150px, etc. For now, I would recommend to use fixed sizes then it matter: the image clearly should be shown in the size above 180px or clearly in the size bellow 180px. Otherwise we should use defaults sizes Alex Bakharev 07:07, 23 May 2007 (UTC)

It seems to me that rather than setting pixels, the best solution would be to allow editors to set the proportion of the width of the article space that an image would take up (say 5% 10% 20% and so on) which would be uniform regardless of the monitor size. That would allow editors to set a page layout that would be constant regardless of the viewing device. Although I am not a technical person and so have no idea whether this is feesible or not. G-Man * 19:21, 23 May 2007 (UTC)

Yes, it is possible with CSS. Dynamic page layouts, by the way, can never be truly consistent. Adrian M. H. 20:52, 23 May 2007 (UTC)Just to clarify: it would take a change in the wiki image syntax to accept anything other than pixels. It fails to respect the surrounding div with any other measurement.
I like the idea of percentages. I wonder how hard it would really be to change it. ~ ONUnicorn(Talk|Contribs)problem solving 20:20, 25 May 2007 (UTC)

I think it's worth mentioning a function similar to Alex Bakharev's idea has been implemented already (just a few days ago): [[Image:...|thumb|upright|...]] will display the thumb at 75% of the thumb width; this is supposed to be used for unusually high images. This factor can be changed, e.g. [[Image:...|thumb|upright=0.6|...]] uses 60% and widths are rounded to the nearest multiple of 10. (I'm not sure whether this is documented anywhere on en.WP yet--I couldn't find it.) --Dapeteばか 22:33, 26 May 2007 (UTC)

Intersecting Categories

Does anyone know of an easy way to cross-reference two categories? As in, I'm looking for all articles related to biochemistry that need cleanup, or the like. Besides, of course, skimming through the actual categories. Someguy1221 00:15, 22 May 2007 (UTC)

Yes, this feature is available as "List comparer" in AutoWikiBrowser. —METS501 (talk) 00:31, 22 May 2007 (UTC)
Category intersection is a perennial feature request that may actually get implemented if someone can figure out how to manage the server load it will create. -- ☑ SamuelWantman 23:08, 26 May 2007 (UTC)

Hit counter for every article in Wiki.

I feel a hit counter has many advantages:

1. May serve as a measure of 'popularity' for an article.
2. It motivates contributors to do more on the article if they know that it is popular.
3. May serve as a measure of 'reliable content' if it is accessed by many people.
4. Acts as a reward to the author because so many people read his/her article.
5. And many more that I can't think of right now in this quick post.

I don't know wheter it is appropriate for Wiki but for example 'planetMath' do have it.
Also, a hit counter wouldn't be appropriate for the 'Main Page' as the articles differ frequently.
Just to add another, a hit counter for each article may be used one for each year in order to assess its time evolution. Edyirdaw 14:20, 17 May 2007 (UTC).

This is not feasible on Wikipedia because of the server load it can incur. You may be interested in some aspects of Special:Statistics. -- nae'blis 14:27, 17 May 2007 (UTC)
We do have this though.↔NMajdan•talk 14:28, 17 May 2007 (UTC)
And what is more, if that was visible on every article, it would make it easier for vandals to target either the very popular pages for maximum exposure, or the least viewed pages for the best chance of going unnoticed. Bad idea. But to answer your points:
  1. It is not a contest.
  2. I have no desire to concentrate on mainstream and/or popular articles. Quite the opposite.
  3. I doubt if very many of "my" creations are high-traffic (often quite obscure) but they are still reliable. 100% I hope.
  4. Same answer as 1 and 2. I'm not in it for the glory.
Adrian M. H. 21:04, 17 May 2007 (UTC)
I think it would just end up becoming a popularity contest or a vanity issue for far too many users. Jmlk17 20:14, 23 May 2007 (UTC)
Don't the server logs already have the necessary data? If not, tracking this data wouldn't demand a lot of resources and it would address the primary criticism of Wikipedia
And measuring updates as a proportion of hits(views) would avoid a popularity contest while providing a measurement of reliability. See post below about measuring the reliability of an article
I Agree With You,The Wiki Should Must Accept This Proposal.Good Idea

SunnyIndia 09:35, 26 May 2007 (UTC)

Strong oppose. Because of quite a few reasons:
  1. Wikipedia is an encyclopedia, and encyclopedic content can't or shouldn't be judged by popularity
  2. It is only natural that Linda Lovelace will always have more hits than The Old Man and the Sea (check here to see that latest films and human organs have way more hits than almost any of the featured content
  3. There is no reason that accuracy or authenticity will draw more hits than human vanity and well circulated behavior patterns
  4. This would actually promote Wikipedia:WikiProject Pornography over Wikipedia:WikiProject Countering systemic bias very strongly (it roughly translates into a typical Big Mac becoming more imprortant than 1 billion Chinese people, just because the Chinese visit the English much less than the average American)
  5. In a world where MySpace is way more popular than BBC how can we suppose that "popularity" is a measure of "reliability"? (Hitler was very popular when he won the election, but was he reliable?)
  6. Instead of addressing the primary criticism aganist Wikipedia it will aggravate the criticism deeply, with a possibility of turning an encyclpedia into a farce of popularity parade
  7. And, of course, for all of the reasons already stated above

Very, very bad idea. Aditya Kabir 20:18, 26 May 2007 (UTC)

British/English

In my opinion British and English are 2 different things depending on the subject matter. English LAW and English LANGUAGE are two seperate and easily distinguished matters. I refer to, as one of possibly many Wikipedia examples, the subpoena article, extract pasted here in parenthesis (The subpoena has its source in English common law and it is now used almost with universal application throughout the Anglo-American common law world. However, for Civil proceedings in England and Wales, the term has been replaced by witness summons, as part of reforms to replace Latin terms with easier to understand English terms.) The link in question in in bold. To the uninitiated or layman, this could be confusing. I therefore propose that all links featuring the word 'English' with a reference to England as a country (law, culture etc but NOT language obviously) could have a (GB) suffix attached, so the previously highlighted link would read 'English(GB) common law', so to distinguish that 'English' means 'originated in England ' rather than be possibly confused with the English language, that is obviously used worldwide.

The alternate proposal is that 'American English' should be described by the term 'American', while 'British English' should be described by the term 'English'. Neither proposal is realistic. Addhoc 12:28, 19 May 2007 (UTC)
Also, hasn't this been as issue around here for quite some time? Even down to spelling (colour vs. color, centre vs. center, etc). I think that if it is readable and grammatically correct, it doesn't matter which version the article is in. Jmlk17 20:05, 23 May 2007 (UTC)
How could English common law possibly be confused with the English language? Incidentally, of course British and English are two different things - one refers to Britain and one to England! -- Necrothesp 14:10, 27 May 2007 (UTC)

Edit summaries

Currently, the limit for edit summaries is 200 words. Perhaps that can be extended to 300 (or 400, for that matter) words. The reason is that sometimes, people want to provide more detailed summaries; they have to use abbreviations because of the short limit. Universe=atom•Talk•Contributions• 18:28, 25 May 2007 (UTC)

I dont't know, bu I believe that is characters, not words. Reywas92TalkHow's my editing? 19:24, 25 May 2007 (UTC)

I think perhaps an expansion to 250 might be in order. But 400 words in quite a lot of writing for an edit summary in my opinion. Jmlk17 20:52, 25 May 2007 (UTC)
Actually, 250 is the maximum edit summary length that MediaWiki accepts. For some reason, the edit form's textbox has its maximum length set to only 200. The number can easily be altered with JavaScript, or even better, in the software itself. GracenotesT § 03:07, 26 May 2007 (UTC)
Actually the current maximum is 200 characters, not words. There is no minimum. I was only thinking of having the max extended. Universe=atom•Talk•Contributions• 17:55, 26 May 2007 (UTC)
I would like a maximum higher than what it is at the moment, if technically feasible (250 is just below 255, so there may be reasons why it was chosen). Increasing the edit-summary-box maximum would be helpful; I'm fed up of having to edit my edit summaries just to make them shorter.
Oops, I meant "characters" as well. Eh, the following js code might be useful.
addOnloadHook(function() {
    var sumBox;
    if (sumBox = document.getElementById('wpSummary'))
        sumBox.setAttribute("maxlength", "250");
});

GracenotesT § 13:03, 28 May 2007 (UTC)

Wikipedia:Reliable sources/Noticeboard

The page has been created per discussion at Wikipedia_talk:Reliable_sources#Reliability_noticeboard.-- Piotr Konieczny aka Prokonsul Piotrus | talk  18:21, 29 May 2007 (UTC)

Template for byte quantities

The current WP:MOSNUM, regarding binary prefix, recommend to "stay with established usage, and follow the lead of the first major contributor to the article." and also suggest that "The use of parentheses for binary prefixes "Example: 256 KB (KiB)". As WP:MOSNUM state , "There is currently no consensus as to whether common binary prefixes or the IEC-recommended prefixes should be used in Wikipedia articles.". That lead to chronic edit war and lengthy arguments. The acceptance of the IEC notation has been slow, both in the industry and in the public at large, and it is reasonable to think that is will still take significant time, years in not decades, before the usage is settled.

This proposal attempt to eliminate few of the most commons objections raised during the debates on this topic. These are, in no particular order

  • Wikipedia is an encyclopedia and therefore exactitude and precise standard conformance are paramount
  • Wikipedia is the reflect of the world as it is not as it 'should' be.
  • Legacy hardware have all their reference materials written using usual notation therefore IEC notation are confusing
  • Non-specialist user is confused when seeing S.I prefix used with a different value than their expected meaning

and of course, at the end of the day, a lot of the arguing is motivated by a very strong force : personal taste.

The following templates Template:KiB Template:MiB Template:GiB Template:TiB are proposed. They take 2 positional parameters. The first one is the size itself, a number. the second is an optional unit.

For example: If an editor has no preference he would defer to the template, which should reflect the then current consensus. In this current version of the tempalte version that would give: {{KiB|16}} -> 16 KB (KiB)

If an editor whish to use the traditional notation, he would use {{KiB|16|KB}} -> 16 KB

A benefit of the few extra characters is that it make apparent to any other editors that the editor knew that KB was a binary prefix in this context, and that he belive that it still should be represented as traditional notation.

But the main feature of these templates is that they are wirtten in such a way that a user can customized his environment in order to see these units in his favorite representation.. Indeed, thanks the good work of User:Mike Dillon, a small piece of javascript can be used by any user who want to see only his favorite notation.

for example: 

var byteSuffixes = {
    "kib": "KiB",
    "mib": "MiB",
    "gib": "GiB",
    "tib": "TiB"
};
importScript('User:Mike Dillon/Scripts/byteQuantities.js');

to have only IEC unit displayed or 

var byteSuffixes = {
    "kib": "KB",
    "mib": "MB",
    "gib": "GB",
    "tib": "TB"
};
importScript('User:Mike Dillon/Scripts/byteQuantities.js');

to have only traditional unit display.

Note that it will not impact the place where the unit HAS to be one way or the other for the article to make sens, like for instance in binary prefix, since only the text using the template will be impacted.

The proposal is as follows:

  • That these template be mentionned in WP:MOSNUM
  • That on pages relating to legacy hardware/software, the main editors be encouraged to use them in order to indicate the consensus on the page and to clarify to other editor that the choice of unit is purposeful and not an oversight.
  • That editors in general do not fight the usage of such template, so long as their introduction do not change the normal appearance of the page (that is without any javascript helpers)
  • That the existence of the technique based on javascript be mentioned so that user that have a strong opinion on the matter can satisfy their preference.

The current form of the Template is not necessarely part of this proposal. The only characteristic of the template that are part of the proposal is the use of the class attribute in order to make the javascript substitution technique works cleanly. -- Shmget 03:52, 26 May 2007 (UTC)

Avoid movement in pages

Yesterday's Picture of the day, Image:Translational motion.gif, was extremely distracting; it may well have caused problems for users with cognitive disabilities. It appears to breach WAI-WCAG Web Content Accessibility Guideline number 7.3: "Until user agents allow users to freeze moving content, avoid movement in pages". I suggest a policy that all such images should use a still image, or text, to link to the animated version, with a prior warning. (prior discussion: Wikipedia talk:Picture of the day#Animation, Wikipedia talk:Accessibility#Animated Picture of the Day) Andy Mabbett 21:34, 15 May 2007 (UTC)

I agree with this. I don't like animation on pages unless I specifically want it. This allows people who want to see the animations see it and those who don't can see a static page. Perhaps we could have a user setting to have the animated or still version of images load by default on the article pages. Koweja 21:42, 15 May 2007 (UTC)
I'm with you 100%. But, as I often find in the course of my work, it can be hard to convince people of the importance of accessible web standards. Adrian M. H. 21:43, 15 May 2007 (UTC)
I agree on general principle, but sometimes an animation is essential. For articles on horse gaits for instance, a series of still images just doesn't do the subject justice. A looped vid or animation is the most powerful informative tool on the page in a case like that. If you require a link, I guarantee it will get missed. So I agree with making it policy, but it needs to be clear that it's avoid movement, not a across-the-board ban on animation. VanTucky 22:22, 15 May 2007 (UTC)
Of course an outright ban would be bad, I would just like a choice in when we see the animation. You can even make it default to showing animations and users have to check something in their settings to see stills w/ a link to the animation. That'll help prevent people from missing it if we made no-animations the default settings. Maybe even a bar on top of the page if there are animations and the user has animations disabled. Koweja 22:35, 15 May 2007 (UTC)
Sounds good. VanTucky 22:37, 15 May 2007 (UTC)
Warn people about the moving picture but keep it because some people enjoy them and the people who do get seizures from movement dont have to look because they know that the moving picture will be there.adambear8888 19:13, 24 May 2007 (UTC)
I think that some applications may warrant moving images. This should be left to editorial control. HighInBC(Need help? Ask me) 22:42, 15 May 2007 (UTC)
Can you give an example of a page where it's more important to show (rather than link to) a moving image, than to respect the meeds of users with disabilities? Andy Mabbett 11:58, 16 May 2007 (UTC)

Can't we just create a JS/CSS system where 2 images are preloaded, and then you need to click like a "play" image before the animated image is shown? I think it's possible we just need to find the right place to place the .js Sounds simple and doable. It should still be used with the greatest reserve and stuff, just like any other animated gif we have now, but it would address some of the concerns mentioned above I think. --TheDJ (talk • contribs) 12:59, 16 May 2007 (UTC)

That would involve always sending both images and using up bandwidth. As you're using JS anyway, maybe replacing the image using DOM manipulation would make more sense? --ais523 13:03, 16 May 2007 (UTC)
I just did some testing. we only need a special version of the table collapse scripting. My tests show that hidden elements are loaded when needed, not upon page load in Safari and Firefox. I think it would be relatively easy to change the table collapse code in some code that will switch between a "play" image or the "animated" image. --TheDJ (talk • contribs) 13:53, 16 May 2007 (UTC)
I cordially invite you to run a test on the GIF page, which has two three useful but potentially distracting animations. Being able to see the effects would enable people to gauge whether it would be a good idea to implement this feature and doing so on a page heavily devoted to GIF animation might bring some more knowledgeable people into the discussion. GDallimore (Talk) 14:07, 16 May 2007 (UTC)
(edit conflict) The other problem with using display:none-like code is that it breaks an accessibility guideline itself; see Wikipedia:hiddenStructure. With DOM manipulation code, it'd be possible to degrade in a more graceful manner for ancient browsers (e.g. have the 'play' link take the user to the image description page for the animated version). --ais523 14:09, 16 May 2007 (UTC)
Click the image to see the animation. The only drawback seems to be I can't get the image to resize, but maybe I just haven't figured out how to do that yet.
As I outlined on Wikipedia talk:Picture of the day, this capability already exists on MediaWiki with the following syntax: [[Image:Animated.gif|thumb=Still frame.png]]. howcheng {chat} 21:08, 18 May 2007 (UTC)
3 comments copied from Wikipedia talk:Accessibility#Animated Picture of the Day
Could you perhaps clarify the problem with an example or two? What kind of disabilities are affected by animated images? Do the images at Earth#Orbit and rotation and Engine#Modern need to be removed/made-static and have a warning added? Every other animated image on the site?
The only example I can think of that makes obvious sense to make static/warn about, is Strobe light, which is of course linked to from Photosensitive epilepsy. Though possibly its small size makes even that ignorable.
We simply need more to go on, than "is extremely distracting" and "may well cause problems".
Finally, it's the Picture of the Day, it's meant to be distracting! --Quiddity 23:22, 15 May 2007 (UTC)
"We simply need more to go on, than "is extremely distracting" and "may well cause problems". " Indeed, which is why I cited WCAG.
"Do the images at Earth#Orbit and rotation and Engine#Modern need to be removed/made-static and have a warning added?" - Yes. Andy Mabbett 12:04, 16 May 2007 (UTC)
They make JAWS behave more sluggishly (with all modern versions of JAWS I have including the latest one). This is because when the JAWS rendering engine sees a change in a page, it thinks it is a new page and tries to redraw it. This tech support bulletin is slightly relevant, though things have improved since it was written. For what it's worth, I just turned off animations in Internet Explorer - it can be done easily through the tools menu - and sluggishness at the article Earth disappeared. I had never thought of that before I read this conversation and I haven't found anything in the JAWS documentation about non-flash animations. I like the way the picture of the day section works on the main page and I have no objections to animated images being featured as long as they are not directly displayed there. However, in actual articles, I think only static images should be displayed directly. Graham87 12:43, 16 May 2007 (UTC)
end of copy

The WCAG 1.0 Guidelines you cited are from 1999, and the draft for 2.0 appears to have removed that particular element of advice on general animated images. Possibly because it is indeed now possible to disable them within all major browsers (firefox, IE, opera).

The Strobe issue is addressed by WCAG 2.0 Guidelines #2.3 - Seizure (Working Draft). It should indeed be made-static.

Apart from that, I'm still unsure who exactly is being affected by this? Who are we going to be helping by removing what is, to most, useful content? --Quiddity 18:04, 16 May 2007 (UTC)

The WCAG guidelines v1.0 are still current; version 2.0 is being re-drafted because they were not accepted by the wider community. Andy Mabbett 21:56, 16 May 2007 (UTC)
But the 1.0 guidelines were developed during the heyday of blinking-rotating-animated interfaces, the monstrosities of geocities and flashturbation. The spirit of the intent was not aimed at removing single useful animations from an encyclopedic page.
You keep arguing the abstract point and tangential concerns, and I keep asking for concrete examples. Who are we going to be helping by removing what is, to most, useful content? Is there a single disability that is seriously affected by the image at Horse gait#Gallop? --Quiddity 01:25, 17 May 2007 (UTC)
"But the 1.0 guidelines were developed during the heyday of blinking-rotating-animated interfaces, the monstrosities of geocities and flashturbation. The spirit of the intent was not aimed at removing single useful animations from an encyclopedic page." - can you cite some evidence to support that claim, or are you just expressing a personal opinion? Andy Mabbett
Call it common sense, call it personal opinion. The web has changed just a little bit in the last 8 years; to ignore that, and the original context, would be foolish. --Quiddity 19:00, 22 May 2007 (UTC)
Common sense as a method of argument is a logical fallacy. The kinds of disability affected by movement or flashing have not changed in that period. Andy Mabbett 12:15, 23 May 2007 (UTC)
"Who are we going to be helping by removing what is, to most, useful content?" - Straw man. No-one is asking to remove useful content; I'm suggesting that where that content is animated, and this breaches WCAG 1.90 guidelines, it's preceded by a simple but clear warning; to help anyone and everyone who is distarcted or made ill by such images, such as people with cognitive disabilities, attention issues or types of dyslexia. I'm not an expert on those issues, but the people who drafted WCAG 1.0 were. Are you? Andy Mabbett 22:21, 21 May 2007 (UTC)
Well, attention issues makes sense. But reducing the utility of the 'pedia for everyone else requires overwhelming need, and frankly I'd like to see an actual complaint from someone suffering a problem first. Similar to the spoiler tag controversy - supposedly noone has been able to find a valid complaint about a lack of spoiler tags yet.
The likelihood that a reader will not click through to an animated image is quite high. Conversely, I find the animated images useful because they capture my attention when I'm scrolling down a page - an animated image will often be the item that makes me curious enough to read that section.
My only suggestion would be for you to draft what you envision as an appropriate policy/instruction-set for animated images, so we can have an example of what you want. Apart from that, I think howcheng's answer above covers the problem adequately.
The last line at Wikipedia:Image use policy#Displayed image size already suggests that "Inline animations should be used sparingly". That's where any changes would go, and a note should be left on its talkpage pointing to this discussion (or move it all to there). --Quiddity 19:00, 22 May 2007 (UTC)
That guideline is being ignored, or circumvented; presumably because "sparingly" is a weasel-word. Andy Mabbett 12:15, 23 May 2007 (UTC)

Image:Roodlicht.gif I support this proposal. Image:Dainsyng.gif Krimpet (talk) 01:56, 17 May 2007 (UTC) Image:Roodlicht (reversed timing).gif

There should be a ban on enforced viewing of moving images. They are distracting. Distraction was also mentioned for removal of movement at Pan Am Flight 103. Non-stop images are the worst. Distracting work colleagues or calling attention to the use of Wikipedia at work can also be a bad thing. Currently, the only options to avoid unrequested moving images are to scroll away or close the page. Neither option is good. I see no reason for a total ban on moving images (the horse gait example is great) just on unrequested image movement. Thanks for bringing this up. Editore99 12:44, 17 May 2007 (UTC)
Users who should not be loading Wikipedia from work are not our concern. Unrequested moving images are no greater a concern than sexually explicit images, and we already know how that discussion goes... without concrete descriptions of the harm to be incurred, this needs to be a page-by-page consensus on whether animation is warranted. At most, a guideline for some of those reasonings so they can be more globally applied (though I suspect we already have one, somewhere). -- nae'blis 14:33, 17 May 2007 (UTC)
"Unrequested moving images are no greater a concern than sexually explicit images" - I've heard of sexually explicit images inducing moral outrage, but never epilepsy. Andy Mabbett 09:52, 18 May 2007 (UTC)
You need to show the evidence that all moving images trigger epilepsy, or concede that not all moving images are bad. -- nae'blis 14:41, 18 May 2007 (UTC)
Given that I've never claimed that "all moving images trigger epilepsy"; no, I do not. Andy Mabbett 14:52, 18 May 2007 (UTC)
Given that you think Earth#Orbit and rotation and Engine#Modern need to be made static, I think we need a more clear view of your criteria then. -- nae'blis 15:00, 18 May 2007 (UTC)
My "criteria" is adherence to WAI-WCAG Web Content Accessibility Guideline number 7.3: "Until user agents allow users to freeze moving content, avoid movement in pages". Andy Mabbett 15:15, 18 May 2007 (UTC)
Do you have any answers for my questions/statements 8 comments up (Beginning: "But the 1.0 guidelines were...")? --Quiddity 16:57, 18 May 2007 (UTC)
"Users who should not be loading Wikipedia from work are not our concern." You do not speak on behalf of me so the word our is not appropriate. Editore99 12:04, 18 May 2007 (UTC)
Let me rephrase that, then: "There has never been a consensus that Wikipedia should be edited with an eye toward the concern of users who should not be loading the encyclopedia from work." Whether or not you personally have a concern about such, it's not a goal or policy of the encyclopedia. -- nae'blis 14:41, 18 May 2007 (UTC)
Thank you for rephrasing it. I understand your point and agree that the issue has not arisen before. Editore99 18:20, 18 May 2007 (UTC)

I strongly object to this proposal. One of the most powerful features of Wikipedia is the ability to insert moving pictures into the articles. Such moving pictures often make for a far easier-to-understand exposition of a principle than would 1000 words.

Can it be misused? Of course. And I'm sure we'll see that. But properly used, it greatly improves the accessibility of information in our encyclopedia. I look forward to the day when, for example, our tiger article shows video of tigers in motion and not just a few static images.

Atlant 17:11, 21 May 2007 (UTC)

I look forward to the day we have a video of a tiger on Wikipedia, too. But I want it to star playing when *I* say so, not the page's authors. This concurs with the findings of every usability study worth its salt. Andy Mabbett 22:23, 21 May 2007 (UTC)

Above there was an inquiry as to whether moving or blinking images cause actual problems for soemone. i have been presnet when blinking computer images caused a serious epileptic seziure in another person -- and let me tell you significant harm was done. I'll go into detail if anyone wants. Now most moving images are not in the least likely to cause seizures, any policy about those must rest on other grounds. but images with significant area blinking or changing color on a regular basis such as Image:status.gif can indeed cause a problem. DES (talk) 21:16, 22 May 2007 (UTC)

I don't really want to sound insensitive here, but what do we imagine coming next? A ban on police and ambulance lights? You can never be politically right enough, right? Motion sickness is a more regular phenomenon than epileptic fits, but that shouldn't get us to want a ban on passenger airplane flights. I personally have a problem with cathode ray tubes, which makes my eyes hurt bad after every Wikipedia session. I am sure there are millions of other people who has a similar problem. So what do we ban - cathode ray tubes or the Wikipedia or both? Please, banning something is a serious measure, think long and hard before you propose it. It's easy to start banning things, for one reason or another, all with a good intention - smoking, abortion, slash-and-burn agriculture, euthanasia, polygamy, inter-religion marriage - whatever. But, when we start stretching things, where do we stop? Before we all go and ban something as little as a blinking image, we might end up becoming either a bureaucracy or an authoritative regime - both highly against our fundamental principles. Please, think again. I don't think this discussion should be about seizures, value of moving images or bandwidth. It should rather be more about principles and ideologies. Aditya Kabir 16:13, 23 May 2007 (UTC)
Please avoid slippery slope as a method of debate. Andy Mabbett 14:46, 24 May 2007 (UTC)
But that's an integral part of the argument that you are relying upon. It's a rare image that would trigger an epileptic seizure, yet we're supposed to ban all motion (in large part) because of that. Clearly, objectionable images can be dealt with on an individual basis.
Atlant 16:39, 29 May 2007 (UTC)
There is a difference between a government banning soemthing in real life, and a website adopting a policy of what images it will and won't use -- anyone who doesn't like wikipedia's policies is free to find a wiki with different ones. There is also a significant difference between the harm done by a seizure and by motion sickness, and there is also a difference in the oppertunity of a potential victim to anticipate and avoid the problem -- people generally know when they are about to get on a vehicle that may cause motion sickness. In many jurisdictions the design of flashing lights for emergency vehicles has been altered to reduce the chance of seizures -- and the positive benefit provided by such lights is IMO rather higher than that provided by flashing images on wikipedia not behind a link. DES (talk) 17:10, 24 May 2007 (UTC)
Please, avoid an intention to stop a method of argument that is quite popular in areas as diverse as macro-economics, criminal law, mechanics, and public health. And, please, if you really want to advise someone to leave Wikipedia if the policies is not suitable, then stop discussing them and start hurling people out of the community. We discuss policies that we like or don't like, and try to build a consensus (that includes non-existent policies that have a potential to become). If you don't like the way Wikipedia operates, I guess, you can leave it and start one Wiki on your own, with complete liberty to drive people out. Now for the slippery slope, I'd like to ask a simple question - do we go out banning stuff left and right and act like a stiff bureaucracy? Or do we depend on the editors to work towards a great encyclopedia, and try out a system that politely asks people to make careful use of blinking images? I stand for the second route (I have already removed one blinking image I was using, and that didn't need a banning policy). Cheers. Aditya Kabir 17:19, 25 May 2007 (UTC)

Evidence

  • More. To support the above on Photosensitive epilepsy, I am adding the following research findings (Harding, Graham; Photosensitivity: a vestigial echo?, The first Grey Walter lecture; International Journal of Psychophysiology, 1994, volume 16, pages 273-279.):
  • About one in 4000 individuals has photosensitive epilepsy. Repetitive flashing lights may induce seizures in these individuals. The flash frequency of concern is from 5 Hz to 70 Hz, with most individuals only susceptible in the range of 15 Hz to 20 Hz.
  • A flashing strobe (or a close combination of multiple strobes sequenced together) must not be programmed to flash in the 5 Hz to 70 Hz frequency range.
  • Slower flash rates, and randomly flashing lights are not known to be a cause of photosensitive epilepsy.
  • Point sources of light are much less likely to induce seizures than a diffuse source of light which covers a large part of a person's field of vision.
  • To induce a seizure the light must be present in the center of the field of vision as opposed to the periphery.
  • Reducing brightness or increasing distance between a photosensitive viewer and the light source is effective for preventing photosensitive epileptic seizures.
  • Lights flashing in the distance, even in the frequency range of concern, are not known to cause seizures when in the presence of other lights of a more natural or chaotic nature.
  • The probability of inducing a seizure is greatly increased (by up to a factor of ten) if the light source is arranged in a regular pattern, such as a raster scan image. (This would be far more difficult to accomplish with the DMX Multi-Strobe Brik than with say, a television image.) Stated another way, avoid adding spatial contrast (pattern) to temporal contrast (flickering).
It is also widely known that seizures in photosensitive individuals may be triggered by events like:
  • Flickering or rolling television images
  • Certain video games
  • Computer monitors
  • Alternating patterns of different colors
The Web Content Accessibility Guidelines 1.0 proposes the following remedies to the threat:
  • Allow users to control flickering, avoid causing the screen to flicker
  • Allow users to control blinking, avoid causing content to blink
  • Allow users to freeze moving content, avoid movement in pages
  • Provide the ability to stop the refresh, do not create periodically auto-refreshing pages
  • Provide the ability to stop auto-redirect, do not use markup to redirect pages automatically. Instead, configure the server to perform redirects.
There also have been evidence that Epileptic Seizures can be self-induced, like looking at the sun and blinking rapidly. May be it naturally follows that an outright ban would be a too simple minded solution. I propose that we develop a start button for moving/flashing/blinking images, and incorporate that into the coding for such images. May be a bot can help. There is no evidence to tell us that people who may be able to provide with such images of great educational value are also adept enough in writing codes that incorporate a "start" button. Aditya Kabir 04:34, 26 May 2007 (UTC)
  • Post Script As for seemingly cute but actually quite silly images like Image:Status.gif (not that I mind the silly, I used the image myself), which has no educational value whatsoever - they can always go. There already is a deletion debate going on, and it doesn't warrant a high-handed policy/guideline at that.

Absolutely agree that images should not animate until being told to animate. The proposed inline Flash video player could handle this, no? — Omegatron 17:29, 29 May 2007 (UTC)

Weighted Random Article Link

I enjoy the "Random article" link on the left navigation menu, but it takes some clicking before it conjures up an article of interest. Mostly, it seems to pull up small stubs. I'd like to see a "weighted random" link that pulls up a random page selected by popularity - i.e. any page that has 100 times more visits will be 100 times as likely to be chosen as one that has only ever been viewed by its creator.

I have to imagine the wiki software has a page hit counter somewhere.

It does, but is disabled for performance reasons. x42bn6 Talk Mess 22:24, 27 May 2007 (UTC)
That doesn't really make it random, now does it? Besides, stubs are meant to be expanded, and if we have a weighted system, it'll just start brining up the same pages over and over again eventually. Jmlk17 23:04, 27 May 2007 (UTC)
I believe the true essence of the "Random article" button is that it is "Random". I would not be oppposed to having a most viewed pages button on the menu. My signature is not WP:COI. :) --Random Say it here! 03:36, 28 May 2007 (UTC)
I think there's an off-wiki page somewhere that has the top 100 pages. And yes, random article is designed to show shorter pages. --R ParlateContribs@ (Let's Go Yankees!) 03:39, 28 May 2007 (UTC)
The location is here. However, don't you think it would be kind of cool to have it more accessible. --Random Say it here! 03:43, 28 May 2007 (UTC)
If you take a look at top 100 most popular pages, which cover very a large proportionof our hits, you'll see most of them either involve something linked from the Main Page, something linked from a popular web site, or something involving sex. I think a random article that returned one of these most of the time wouldn't be all that useful. Dcoetzee 05:05, 28 May 2007 (UTC)
Also whatever the popular movie of the month is, and numerous pages about Naruto. --tjstrf talk 18:45, 29 May 2007 (UTC)

Proposed change in the WP:NOT#DIR rule

Moved to Wikipedia:Village_pump_(policy)#Proposed_change_in_the_WP:NOT.23DIR_rule, as it's a proposed change in policy. Firsfron of Ronchester 07:14, 7 June 2007 (UTC)

Wikidata

Does anyone know where m:Wikidata is being discussed currently? All those links appear to be untouched since June 2006, and the wikidata-l mailing list is utterly silent. Omegawiki is not an official Wikimedia project (? so why does OmegaWiki list all our sister projects at the bottom of its mainpage?), but Wikidata isn't even mentioned at the foundation site... --Quiddity 19:52, 4 June 2007 (UTC)

Propose Ending the Rules against Puppets

Based on the logic in my essay on sockpuppets (User:Cool3/Puppets), I propose ending the ban on sockpuppets in favor of a policy to "judge each account on its own contributions". I welcome your input. Cool3 22:12, 1 June 2007 (UTC)

Sockpuppets are permitted, but discouraged. See Wikipedia:Sock puppetry for further information. Clearly, if you cause no harm, then no harm should come to you or your friendly little puppets of sock. --Bossi (talk • gallery • contrib) 22:21, 1 June 2007 (UTC)
In many of the cases you propose, it can already de facto happen. If Willy on Wheels is around somewhere making good, constructive edits, no one will ever even think to question whether the account is his. However, sockpuppets do have a lot of harmful and abusive uses, such as falsifying consensus (and the number of editors supporting a position is a factor in determining consensus, even if it's not the only factor), and revert warring. It also is possible to find sock accounts. Checkuser isn't magic, but it certainly can find supporting evidence. (Also, note that a husband/wife team would probably be considered meatpuppets, and they're pretty much treated the same.) I have a sockpuppet myself, you can find it here, but it's clearly marked as mine and used for a legitimate purpose (preventing compromise of my admin account while editing on a public terminal). But we certainly shouldn't say "use socks for whatever you like." And if we just allowed people to circumvent a ban by creating a new account, bans would be meaningless. A ban means that the person is forbidden to edit, not that their account is. If they want the ban lifted, they can wait a suitable amount of time, come back around, apologize for what they did, and ask if we're willing to give them another chance. Seraphimblade Talk to me 22:41, 1 June 2007 (UTC)
I am perfectly aware of the circumstances under which sockpuppets are permitted, I'm saying that they should be permitted all of the time. As for the husband/wife team, if both are editors in their own right and perhaps without even each other's knowledge, the term meatpuppet hardly applies. I understand that we ban people not accounts, and that is essentially what I want to change. As for consensus, I would direct you to the section entitled "People Judge Accounts on their Contributions" in my essay. Cool3 00:07, 2 June 2007 (UTC)
Sometimes, people use sock puppets as a malicious means to socially engineer debates. Even if the logic of arguments is more important than the number of people saying it, Wikipedia can be based on "consensus" more than "logic". Intentions (in some cases, ignoring social contracts to get what you want) and consequences (in some cases, disruption) can be important in analyzing if a certain editor is overall good or overall bad for both the community and the encyclopedia. Your idea is not a bad one, but even Wikipedia has not a social structure so Utopian. GracenotesT § 01:17, 2 June 2007 (UTC)
Ooo boy. I think that this would spiral out of control in the end, resulting in quite a bit of bad sockpuppetry, and I don't personally agree with that. Jmlk17 07:04, 2 June 2007 (UTC)
  • Whether it should or not, Wikipedia uses a protocol of “consensus”. Allowing unlimited sock-puppetry would produce an equilibrium in which the most aggressive group of puppeteers got their way. In many cases, single individuals would dominate areas simply by virtue of having the free time and will to engage in puppetry.
  • Allowing unlimited sock-puppetry would mean that it were impossible to block editors whose actions were plainly and overwhelmingly destructive.
  • There should be greater modesty about Checkuser. Specifically, editors should not treat confirmation as definitive proof, and denunciations should generally be avoided.
  • The rules against “meat-puppets” represent an attempt to have the cake and eat it too. There was an especially ugly transition period as meat-puppetry went from been encouraged (albeit not under that name) to being outlawed.
—SlamDiego←T 10:06, 2 June 2007 (UTC)

Add search engine

For JavaScript-enabled browsers, there is a drop-down box on Special:Search so that a search engine can be selected. Someone has suggested to me that Exalead should be added to it; as the author of the script, I’d be fine to write the code if the community agrees on it. (See the request at User talk:Gracenotes#Add a search engine). GracenotesT § 17:04, 1 June 2007 (UTC)

I don't know the right place to bring this up, but Firefox earns $50 million dollars a year from its drop down search bar. How should we choose our search websites?--Commander Keane 09:28, 2 June 2007 (UTC)
By the amount of money they donate to us, then! Er, in our case, probably how effective it is at searching. See the note on my talk page; David.Monniaux (talk · contribs) can probably provide details. GracenotesT § 17:03, 2 June 2007 (UTC)

Wikipedia:Flagged revisions

Just started this proposed policy page a while ago. Voice-of-All 23:32, 31 May 2007 (UTC)

Article Duplication option

When creating multiple, similar articles, it would be useful to be able to duplicate the article and the Talk page after finalizing the format of the initial article including wikiProjects on the Talk page. This could just be another tab next to Move and could even have check boxes for what the editor wants duplicated:

□ Article
□ Talk
□ [something else I haven't considered]

It could also have a field for the new article name or simply alert the editor upon saving to choose a new title. Grika Ⓣ 21:17, 31 May 2007 (UTC)

You can do this - add "&preload=Article" to the end of the url to edit your new page, and it will copy all wikitext from the original (Article) to the edit window of the new one. You have to do talk pages separately, but it's very convenient. Nihiltres(t.c.s) 23:14, 31 May 2007 (UTC)
I would say it is somewhat convenient. It is very interesting and I am sure to use it, but I still would want a solution that does both the article and the talk page at once. Grika Ⓣ 05:56, 1 June 2007 (UTC)

Retired Wikipedians Memorial

I was thinking yesterday. "Wouldn't it be a good way to appreciate wikipedians who have moved on by creating a memorial?" I don't know what other peoples ideas on the matter are, but I thought it was a good idea. So I'm bringing it up. --Tλε Rαnδоm Eδιτоr 19:50, 31 May 2007 (UTC)

  • Start in userspace, and if it catches on, move it to WP-space. It looks like a good idea, but there would need to be parameters so that RickK and Elaragirl are in, but Robdurbar and Essjay are out. Also, it may be odd if a memorialized Wikipedian decides to rise from the dead. YechielMan 20:06, 31 May 2007 (UTC)

Linking to other Online Free Encyclopedia

Wikipedia should link to other online encyclopedias like Conservapedia as it links to other Wiki projects like Wikibooks or Wikiquote. This way Wikipedia can show and guarantee neutrality and the diversity of opinions. --draq

No, we should write neutral and diverse articles here. We only link to other wikis where they provide a service we do not. --tjstrf talk 19:32, 31 May 2007 (UTC)
I have to agree with tjstrf. The Wikimedia network, is the "Wiki" network. There is no real reason to link to outside encyclopedias. --Tλε Rαnδоm Eδιτоr 19:41, 31 May 2007 (UTC)
Though there are some subject-specific wikis that can warrant linking to because they offer more depth of coverage than us. --tjstrf talk 20:00, 31 May 2007 (UTC)
You can certainly add a link in an article to whatever site you want and leave it up to the community to decide its relevance. Grika Ⓣ 20:56, 31 May 2007 (UTC)
Agreed, If another free encylopedia has better coverage than us, then we should link to it. --Tλε Rαnδоm Eδιτоr 01:04, 1 June 2007 (UTC)
No, no, no. Wikis are all unreliable. Corvus cornix 03:14, 1 June 2007 (UTC)
Which is why we don't reference them. They can still make good external links in cases where they provide some sort of functionality we don't. You're not going to find a better resource for scanlation techniques than the Wikilation wiki, for instance, and it makes an excellent external link on the relevant page because it provides instructions, which we do and will not include on Wikipedia. --tjstrf talk 03:20, 1 June 2007 (UTC)

New forum-based format for talk pages

This proposal is related to my previous one about discussion of edits.

Wikipedia currently uses the same type of interface for editing both articles and talk pages. This seems illogical, as talk pages are not encyclopedia articles - they are forums. Most other forums on the web (e.g. Google Groups) use a thread-based format, in which contributions are automatically signed and users can only edit their own posts. In Wikipedia talk pages, it is often difficult to see where one user's comments end and another user's begin. Any indentation or insertion of comments between previous posts must be done manually, and there is no standard style for this; often in a complex multi-user discussion it is hard to tell which comment a user is responding to. Why not implement something similar to Google Groups?

Mtford 02:29, 27 May 2007 (UTC)

I think every agrees this is a good idea, and development is underway (m:LiquidThreads). It might take a while to be implemented.--Commander Keane 08:51, 27 May 2007 (UTC)
I may be alone here, but I actually believe the current talk page system is ideal. Since it is identical to the article system, working off of the blank slate of "anyone can edit" rather than delineated "threads", talk pages are able to function as the article's workshop, not only for discussion of how to improve the page but for actually hammering out the details right there as well.
I cannot see how a switch to a forum-like system could be implemented without either losing a lot of our ability to work on talk pages (rather than chat on them), or creating yet another meta-article namespace for banners, drafts, article status information, and everything else talk pages currently do. I additionally expect that the not-so-sparse layout of a forum system would annoy me to no end anyway, and believe that it would serve only to turn Wikipedia talk pages into forums, places for random chatter about a subject, rather than workspaces. In short, oppose. --tjstrf talk 09:10, 27 May 2007 (UTC)
Who is everyone? Some self-appointed group of guardians? I agree with tjstrf - this is completely unnecessary and a perfect example of change for change's sake. The talk pages are not for chat, as are fora, but for discussion about the articles. Wikipedia should not morph into yet another chatroom. There are quite enough of those on the web already. -- Necrothesp 13:54, 27 May 2007 (UTC)
Two very sensible editors, there. I strongly oppose this silly idea. What we have now is very clutter-free, very flexible, and easy to use (most fora are not particularly user-friendly). Adrian M. H. 16:57, 27 May 2007 (UTC)
See my essay User:Dcoetzee/Why wikithreads are bad for a host of reasons why we don't want to use wiki for talk pages. To answer the practical question of how to hammer out details, that can either be done on a temporary page or the individual posts could be written using wiki syntax. There's no reason to go to the unmerciful trouble of formatting our threads using wiki formatting rather than just embedding wiki formatting inside them. Dcoetzee 17:09, 27 May 2007 (UTC)
WP:OR specifically applies to articles, not talk pages. The primary purpose of a talk page is to discuss the article, but it still takes the format of a discussion, having threads of conversation, and is distinctly different in its appearance and evolution from an article. Saying something is a "forum" doesn't say anything about the topic of conversation - it's not like people would start posting social things there just because of a change in format. The purpose and content would be identical, only the software support would be different. Dcoetzee 05:02, 28 May 2007 (UTC)
  • Strong oppose - I really do hope this becomes yet another perennial proposal. I completely agree with the above comments; wiki should not turn into a forum or its talk pages spammed with content about the article topic itself. –Sebi ~ 08:30, 28 May 2007 (UTC)
I'm still failing to see how simply presenting exactly the same discussion regarding article development in a different way that better supports discussion will magically make everybody start discussing off-topic things. Is there a psychological study explaining this that I've overlooked? Or are people just overgeneralising their prior experiences with other forums? Dcoetzee 08:35, 28 May 2007 (UTC)
Same here. Having something better for our talk pages will greatly improve our efficiency in collaboration. If anything, removing and preventing off-topic chatter would be easier. -- Ned Scott 08:57, 28 May 2007 (UTC)

I agree with the above comments that a talk page should be a place to work on the article, and not to chat about it. As such, it is vital that the talk page should use wiki syntax, and that all contributors should be able to read (but not necessarily edit) the raw content of other posts. However, I don't see why this is inconsistent with a more forum-like style of presentation. My two biggest objections to the current format are:

  1. You cannot easily find the most recently-updated threads. I frequently find myself wanting to say something on a matter that was discussed several months ago. However, unless I start a new discussion, or move the old one manually to the bottom of the page, nobody will find my comments.
  2. Take a look at the formatting of this thread: it starts out with a sequence of indents, then somebody stopped indenting and used a single bullet point, then there are more indents, a single indented bullet, and finally a boxed comment from the original author with numbered indents inside. Could you see at a glance where my current comment begins and ends if I had not put a box round it? Surely this would be easier if the software enforced some basic formatting standard.

I don't see any problem with preventing users from editing other users' comments; if two people really want to work together on editing some text before it goes online, they can use User pages.

Thank you dcoetzee for posting this: User:Dcoetzee/Why wikithreads are bad. I entirely agree.

I will now demonstrate how a discussion should operate, by moving this thread to the bottom of the page. NB if moving threads down the page is bad practice, why did you give me such an excessively flexible interface? And if it's good practice, why doesn't it happen automatically?

Mtford 07:05, 31 May 2007 (UTC)

Well said. Much time is wasted each day just finding which threads have been updated with additional comments, and all too often we've all missed discussions and posts in the shuffle. -- Ned Scott 07:15, 31 May 2007 (UTC)
A forum based format works for quick comments... but not for working on snippets of articles (which is one of the primary reasons for a talk page). I prefer things as they are. Blueboar 18:29, 31 May 2007 (UTC)
Once again, snippets can be edited within individual posts (which can still be written in wiki syntax) or in temporary articles. Dcoetzee 19:36, 31 May 2007 (UTC)
Lots of people are saying that forums are unsuitable for working on snippets of articles; however, I do not see many examples of such "work" in the current talk pages. I certainly haven't noticed any cases where the work relies on a free-style talk page, or where the combination of forums (with wiki syntax) and user sandboxes would be less convenient. Perhaps somebody could move this discussion forward by finding an example of such work in the history of a talk page. Then we can discuss in concrete terms how the same work would look in a forum, instead of just idealizing about why "Wikipedia does things its own way." Mtford 20:12, 31 May 2007 (UTC)

GA icon on top of page?

Just wondered, since the FA's are on the top right, why can't we list the GA icon there too? :-) ♥♥ ΜÏΠЄSΓRΘΠ€ ♥♥ slurp me! 19:31, 30 May 2007 (UTC)

GA is not supposed to be a FA replacement, and it's already too similar to FA. It's supposed to be for articles that are ... pretty good. CMummert · talk 19:38, 30 May 2007 (UTC)
There has been discussion over this in the past, and the main objection to not having the icon in the corner is that articles are only reviewed by one editor who can pass or fail a GA. FAs, on the other hand, go through a stricter and more developed review process that involves multiple editors. This allows FAs to have the designation of being in the top right corner for the amount of people who are looking over the article to ensure its quality. --Nehrams2020 19:38, 30 May 2007 (UTC)
(edit conflict) This idea has been suggested and rejected in the past. See the "what links here" for {{good article}} for various related discussion. This might also be of interest. Christopher Parham (talk) 19:43, 30 May 2007 (UTC)
I think it should stay where it is. To gain the status of FA on an article is an achievement, and, while GA is a great achievement, FA is a class higher...of course. Jmlk17 21:20, 30 May 2007 (UTC)
I have to agree. The FA icon is a symbol of excellence, that has been found by the community. Whereas a GA is a one person review. When you see the FA symbol, you know you are reading a top notch article in the communities opinion.
--Tλε Rαnδоm Eδιτоr 19:45, 31 May 2007 (UTC)

New posts on top of List

  • Why not have the new posts on the top of the list, instead of at the bottom. This way then the older it gets, therefore most people have said what they want or lost interest, the further down the list it is. This way then one does not have to go all the way to the bottom for the most currest posts; it is automatically near the top of the list. The oldest ones will just fall off the list automatically then due to Old age.
  • Can one put a Watch just on the posts one made. Then a peroson would only check back if there is a response to one's post. Otherwise now one has to check back even though there has not been a response yet (possibly a waste of time). If not, can software be designed to make these features happen?--Doug talk 13:35, 30 May 2007 (UTC)
Sounds like you want a messageboard format. That's not how a Wiki works. Anyway, in direct response to your questions:
  • First suggestions sounds like a bad idea. You read from top to bottom, so following a discussion top to bottom is far better and easier. In any event, a long talk page will have a list of contents so you can jump to the relevant section quite easily.
  • Second suggestion is already catered for in a sense. If you create a topic with a heading, additions under that heading will have the heading title as part of the edit summary, assuming the editor edited just that section or didn't delete the edit summary. In the history tab, you can then see what was added to each section. GDallimore (Talk) 14:39, 30 May 2007 (UTC)
I still prefer it the way we've always had it. Scrolling down only takes a second, but it keeps it much more organized. Jmlk17 21:19, 30 May 2007 (UTC)
  • First suggestion: What I am suggesting here is for example on the Humanities reference desk that May 30 (most recent date) be at the top and May 27 be at the bottom. May 27th subjects have been answered and no longer have any interest to most. May 30 material are still being answered. Within each of these days the most recent contents of that day at the top and the oldest for that day at the bottom. I understand you read from top to bottom, so within each "Content" that discussion reads from the top to the bottom (same as it is now). The only thing I am suggesting is the most recent "Content" be at the top and the most recent day at the top. Otherwise it would read from the top to the bottom, within each Content. The way the "My Watch List" is set up is in this fashion I am speaking of, with the most current and newest on the list at the top. Oldest eventually drops off the list; a much more logical approach. The way this is set up is that May 30 is at the top with the most current Watch on top. May 23 is at the bottom and will fall off by tomorrow and May 24 will be at the bottom. May 31 will be at the top tomorrow morning and any new changes to any pages I am Watching. Except I can not put a "Content" of a Reference Desk on My Watch List.
  • Second suggestion: However you can not put a "Watch" on this as you do for an article as it is on your Watch List. I don't want it that anytime someone puts anything on the Humanities Reference Desk it shows up on my Watch List, however ONLY when the "Content" I started (i.e. "When was Petrarch born") is answered will it show up on my Watch List - otherwise I can just ignore checking back ever-so-often to see if there is an answer. Sorry I didn't make it more clear the first time.--Doug talk 21:50, 30 May 2007 (UTC)

Templates for common topics

I noticed that many items from within a certain topic are very inconsistent. For example if i look up two different movies some of the most common and important information (Date released, Actors, directors, ect...) can range from being very easy to find to very difficult depending on who wrote the article. If we create common topic templates that convey the most common and important information first then any additional information afterwards this would give wikipedia more consistent feel, easier to use and more useful. Topic templates can range any where from pharmacuticals, animal classification, plant classification, movies, people, to musical albums.

I agree, it can't harm anything, in fact, it can only be good from my point of view. §→Nikro 12:00, 30 May 2007 (UTC)

Infobox templates allow you to easily spot the essential info. Article text does not need to be strictly standardized, I think. If info is hard to find, try organizing the sections in a better way for that particular article. There are general guidelines like Wikipedia:WikiProject Films/Style guidelines. –Pomte 09:03, 31 May 2007 (UTC)

Top bar with more options

Currently, the top bar (don't know if it has a name) includes the user page, talk page, preferences, the watchlist, contributions, and the log out option. I was wondering if it was possible for there to be an option in preferences that would allow users to add other pages to this top bar. It appears that there is room for at least four or five more pages/options that could be added. Users could choose to add subpages they have (for image galleries they have, sandboxes, userboxes, templates they always use, etc.), specific articles they are working on at the moment that they may not want to type in all the time, or other user's pages or talk pages. Is this feasible? If it is, by allowing it in preferences, users could modify it how they wanted or if they choose, not modify it at all. --Nehrams2020 06:33, 30 May 2007 (UTC)

I was wondering about this recently, although it would probably be through users' CSS files if it can be done at all. Adrian M. H. 14:57, 30 May 2007 (UTC)
Not quite the same thing, but I just found Wikipedia:Tools/Navigation shortcuts, which can add stuff to the links pane. Adrian M. H. 18:20, 30 May 2007 (UTC)
Neat! Thanks. I was wondering the same thing earlier this week actually. Jmlk17 21:17, 30 May 2007 (UTC)
That's a cool link, thanks. Is this the only location where this can be proposed or is there another place where someone else would know? --Nehrams2020 00:14, 2 June 2007 (UTC)

Snakes on a wikipedia

An article named State Snakes {or whatever you want, I don't care}, should be made, listing all 50 states, which are redirects or links to a list of snakes {including a clear, very visible picture for each snake, and a good discription of the snake, and a picture or map showing where they live} in that state (Example: Click on Missouri and it takes you to a list of all the snakes in missouri.) and if i'm correct, i didn't find any article like these, so all these articles might need to be created. This would help people check to see what snakes are in a state, and what they look like, in case they're planning to move and want to be prepared, or if there's a snake and their garden or their yard, and they need to see what it is, and a picture will be very helpful, so a picture for every snake and a map of picture of were they live for every snake listed could be very helpful. So this could all be a good idea. after all, Wikipedia is supposed to be so people can find the imformation they need. §→Nikro 20:46, 29 May 2007 (UTC)

Not sure, but wouldn't that article and the accompanying articles be quite long? I mean, how many species of snakes are there in each state? It must be a large number. Just a thought and comment. Jmlk17 04:17, 30 May 2007 (UTC)
List or category? (SEWilco 01:13, 31 May 2007 (UTC))

Ya, but think of the good it can do, I mean, there's a copperhead in my garden and i'd like this idea, incase any other snakes are spotted. And if I want to move out of state, this would be helpful, and if an unknown snake is seen, this could identify it. This would be very useful and quite helpful. §→Nikro 11:57, 30 May 2007 (UTC)

Oh believe me, I think it could potentially be quite useful. But is there a source online (or off) that actually has listings of snakes of each state? Jmlk17 21:15, 30 May 2007 (UTC)

Ya... Um... Hello, ain't there sources online {and off} that you can find out stuff and learn more, so why need Wikipedia, besides, wikipedia is almost the first place some people looks to find stuff, and wikipedia to meant to help people find imformation, {That can be found on and off line}. Imformation that this proposal can provide if accepted. §→Nikro 23:12, 30 May 2007 (UTC)

Of course, no one is stopping you from creating such a list for your (or any other) state. I myself created List of Minnesota reptiles which the community expectedly expanded. Grika Ⓣ 20:53, 31 May 2007 (UTC)

I'd say something like List of reptiles in the United States. bibliomaniac15 An age old question... 01:49, 2 June 2007 (UTC)

"TEAT" - An historical novel about Isaiah Dorman, the only African American to fight with the Seventh Cavalry at "Custer' Last Stand."

To Whom It May concer:

I spent many years in research and five years writing it. I had a Literary Agent and dear friend who was to submit the story to Publishers specializing in this subject matter. I believe my agent, Mark Bredt, died last month. All communication has ceased. I discovered your wonderful web-site when I thought about contacting the publisher of "Son of the Morning Star," which, as you know was the last mega-hit on the "Battle" and the persons and events that led up to it.

The manuscript is 268 pages long. I've been told it's a "real page turner!" At the end of the novel the reader discovers what Heaven tuly is. I went on the Custer web-site. As you know, there must be over one hundred historical books about him, but not one novel! History books tell you what happened, my historical novel tells you how it felt. I believe it is a first and, like Son of the Morning Star, would not only be the next "Super Hit'" but an epic motion picture like "Dances With Wolves and, unlike "Wolves," it would also make a terrific televison series.

I look forward to hearing from you at your earliest convenience.

Respectfully yours,

O.C. Jenkins, Jr.

Sir, I am not sure that this is the correct website for you to be promoting your book. It does not interesting, but I recommend you keep trying else. Also, I am not exactly sure what you are hoping to get a reply towards. Good luck however, and best wishes. Jmlk17 20:51, 28 May 2007 (UTC)
However, there is a wikipedia page on Isaiah Dorman which looks like it could use expansion, improvement, and supporting cites. -- Boracay Bill 23:01, 28 May 2007 (UTC)
Excellent suggestion! The article could benefit greatly from your knowledge. Jmlk17 05:23, 29 May 2007 (UTC)
In case you're still confused, I should point out that this website is a general-interest encyclopedia, and is not affiliated with the book-publishing industry in any way.--Pharos 05:33, 29 May 2007 (UTC)
Your novel is certainly not the first one about Custer and the Battle of the Little Bighorn. See Little Big Man, a novel and motion picture in which Custer's Last Stand is the high point and focus. Edison 15:11, 30 May 2007 (UTC)

Force Abolishing Of Anon Edits

Currently, all those who oppose anonymous editing are forced to continue with the status quo, in order to prevent their hard work from slowly deteriorating. Much work that is not closely watched over does deteriorate. Having read the perennial proposals page, I believe that we constitute a significant fraction, if not the majority. If properly organised, we and all sympathisers of this hitherto-ignored population of Wikipedians could force the powers that be to take us seriously and stop frittering our time and effort. If a date was set and widely advertised inside and outside Wikipedia, everyone who supported this stance could boycott Wikipedia for one week and leave the rest to deal with the vandalism. If we took it further, we could log out and vandalise pages ourselves (don't get mad, keep reading), the idea being that the Wikipedia bigwigs couldn't ignore us any more and realise that without us, the editors that they continue to abuse, Wikipedia is nothing. We'd force them to respect our time, and prevent anonymous editors from occupying so much of it. After the week, the most sensible thing to do would be to revert all articles to their status one week previous. Of course, if the necessary change was implimented before the boycott, it would not need to happen. Wikipedia is bigger than the people who created it.

Would anyone be interested in helping to organise such a thing? I'm fully aware how radical this sounds but I'm only trying to help Wikipedia and its editors in the long-term. --Seans Potato Business 16:12, 12 May 2007 (UTC)

This is a perennial proposal, and has good reasons for rejection. Nihiltres(t.c.s) 16:41, 12 May 2007 (UTC)
Read m:Foundation issues, the ability of anyone to edit articles without registering is not up for debate, it is mandated by the foundation. I agree with this mandate too. HighInBC(Need help? Ask me) 16:46, 12 May 2007 (UTC)
If we were to do anything to reduce crap, I'd tend to instead set mainspace page creation to only autoconfirmed users. A lot of anonymous edits are poor or vandalism, but I've seen a lot that are good and helpful too, especially in aggregate. I entirely support continuing to allow anonymous editing. Seraphimblade Talk to me 16:50, 12 May 2007 (UTC)
I just looked at the latest 500 contributions of all three of you, and notice that the majority of these edits are in templates, talk space and userpages. I don't think that it's fair for you to condemn those who want to work on ARTICLES to an eternal struggle with vandals, when you yourselves don't suffer the ill effects. --Seans Potato Business 17:22, 12 May 2007 (UTC)
If you really looked at my latest contribs, you should probably also see a lot of edits in user talk with summaries such as "nn-warn" - newly created users creating articles inappropriate for various reasons. I'm fighting vandalism too, just the majority of the article space edits you were talking about are from tagging inappropriate articles that have been deleted - those deleted contributions don't show up. It further emphasizes the point that abolishing anon editing would destroy more than it would achieve - destroying all positive anon contribs while at the same time allowing vandals to simply use hundreds of throwaway accounts. I'm sorry if my rebuke seems harsh, but I do a lot of work in the article namespace to tag inappropriate articles, and your accusation feels particularly insulting to me. Nihiltres(t.c.s) 17:31, 12 May 2007 (UTC)
I just looked at the top 20 anon edits in recent changes. I hit rollback on 5 of them; the other 15 looked fine, and most were actually constructive. If you block all anons, the vandals are likely to continue by registering usernames (making them even harder to stop), and the constructive edits are more likely to stop. (For reference: [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21]). --ais523 17:38, 12 May 2007 (UTC)
By comparison, only about half of the top 20 edits by non-anons in Recentchanges were to article-space, and were about as useful as the anons' by comparison (it was the same sort of changes), although only one was the addition of a spamlink. In the meantime, an anon reverted vandalism to my user talk page. I suspect that if all anons were banned, we wouldn't have much of an encyclopedia by now. (By the way, you might want to compare Citizendium, another wiki encyclopedia that does ban anon edits, to Wikipedia.) --ais523 17:45, 12 May 2007 (UTC)
Problems with Citizendium: 1) They want to start from scratch - Six years back in time 2) Wikipedia already has nearly 100% "market-share" 3) They appear to have questionable ideas regarding how to copyright their content. What I want is 2007 Wikipedia minus the vandalism (registration with confirmed email address) and everything that goes with it (a lot more than meets the eye). I don't see the point in discussing this, since according to m:Foundation issues, this policy is beyond debate. My call for editors in agreement stands - we'll use a way that doesn't involve debate. --Seans Potato Business 18:05, 12 May 2007 (UTC)
Then fork Wikipedia, which you're perfectly entitled to and the project provides database dumps to allow you to do so. -Halo 01:47, 23 May 2007 (UTC)
Our core aim is to be a free encyclopedia that anyone can edit. What you mean is, basically, force semiprotection to every single article, a fact that prevents "anyone" from editing. Our strength is that anyone, anywhere, can fix a typo or correct a fact in a couple of seconds. It is up to everyone to prevent that fact from being our weakness as well.
Since you talk about organizing, create a Wikipedia:Obligatory registration or similar essay, and link to it from as many pages as you can find (besides village pump, noticeboards, help desks, Wikiprojects, etc), and see if the community agrees or not. Since I am against the idea of restricting edition (which has brought me problems for always giving second opportunities to even vandals), if I were to create such essay, it would be considered a point. However, if you believe that is the solution to many of our problems, don't let us stop you from starting that discussion. -- ReyBrujo 18:00, 12 May 2007 (UTC)
Seans Potato Business, if you look a little closer at my contribs you will see that I am directly effected by the vandal problem. I have also done plenty of work in the article space, and even if I did not my opinions are just as valid. HighInBC(Need help? Ask me) 17:59, 12 May 2007 (UTC)
In addition to anonymous editing being the foundation of all Wikimedia projects, also consider a more practical matter: if registration were required, all vandals would just start registering accounts to vandalize. Krimpet (talk) 18:10, 12 May 2007 (UTC)
I am also against abolishing anon edits. As an article writer I see first hand the benefit of anon edits in correcting typos and copy edits. Of course I also see the spam ELs and vandalism but admittedly they are easier to pick out and revert when they come from an IP. In my watchlist, IP contributions stick out and I make it a point to look over them. If everyone had to register it would be harder to isolate these potential vandalism edits for closer scrutiny. AgneCheese/Wine 18:14, 12 May 2007 (UTC)

Anons are the largest group of wikipedia editors, and IIRC produce most wikipedia content. If forced to choose, I would ban all registered users first. ;-) --Kim Bruning 18:25, 12 May 2007 (UTC) (Anons also produce most wikipedia mess, but that's what you get for being the largest group of editors ;-))

Gather supporters and spur on more debate: sure, go ahead. Log out and intentionally cause vandalism to articles to prove a point: I will pursue you just as I pursue every other vandal: be they IP or registered; regardless of a user's past beneficial contributions. Good editors know how to go about raising their concerns, and intentional vandalism is not the way. --Bossi (talk ;; contribs) 19:26, 12 May 2007 (UTC)
This discussion has been going on for a long time. However, we have another option against vandalism : semi-protection. If we loosen the guidelines on semi-protection a little bit, it would certainly stop a lot of vandalism. Certainly all those articles that are as good as finished, could be semi-protected. Practically all changes on those articles just consist of vandalism. I’ve tried this out on a few articles (such as Apple, Rose, Leaning Tower of Pisa) that were vandalised one or more times on a daily basis and it helps a lot. JoJan 08:36, 13 May 2007 (UTC)
There are plenty of good-faith edits (though not necessarily the greatest quality of edits) by anons and I think content is very hard to come by, so any sort of good-faith edit can be worked upon and should be welcomed. x42bn6 Talk Mess 17:57, 13 May 2007 (UTC)

The reason for vandalism is simple: Anyone can edit and can see their change go live immmediately. Nothing can be more attractive to someone who wants to see that they can have an impact on the world, even if only temporarily. "Anyone can edit" is a "office policy", meaning that Jimbo Wales would need to change his mind on this one. I really don't see that happenning anytime soon.

The other option is not to have the edits "go live" immediately. One possibility is this business of "approved versions" that is being tried out in the German Wikipedia, but I am not sure of the status of that. It would show an "approved version" by default, but an editor could still go into the article and edit the current version at will. I am not sure if this works much to discourage the vandals or not, as the vandals edit does "make it in" to Wikipedia. I have also called for review of edits by anons and new users to no avail. Another idea is to require an e-mail exchange to verify an edit. This would force a vandal to "sign" their edit, but once again people have expresed concerns about inconveniencing the anons. Personally I feel that an anon doing a legitimate edit will be happy to put up with review or confirmation as long as they told up front what is going on and why. The process cannot be too onerous, but some bar is needed so that a vandal just does not find Wikipedia worth the bother.

BTW - I do have another suggestion: Immediately ban ANY editor engaging in blatant vandalism for at least two weeks. If it is so blatant that a bot can detect it, then you are probably catching the vandal when they are active. --EMS | Talk 01:56, 14 May 2007 (UTC)

I strongly disagree with any suggestion which prevents IP addresses from editing Wikipedia. Why? Well:

  • The vast majority of people wanting to ban anons are people who do vandal fighting or regularly check watchlists, and are generally the people who see the worst side of IP contributions. They're inherently biased.
  • The vast majority of edits by IPs are genuine, and much of the genuine content from Wikipedia was by people editing using IP addresses.
  • It's inherently unwiki-like, and creates artificial restrictions on who can edit.
  • It's easier to "see" the fruits of vandalism rather than genuine content, making the problem seem worse than it is.

I also disagree with anyone who inherently talks about "increasing punishment". This doesn't work:

  • Many genuine editors will get hit in the cross-fire
  • Promoting and extending already overly harsh bans isn't a good idea
  • It doesn't work in real life with the "death penalty", why the assumption it will work on Wikipedia? -Halo 02:02, 23 May 2007 (UTC)
Also, part of the appeal and initial draw of Wikipedia is the fact that anyone can edit. I remember reading through the project about 4 years ago, long before I registered an account, and fiddling around with copyediting and such. Just because SOME anonymous IPs vandalize doesn't mean all do. There are plenty of usernames on this site that vandalize as well. Jmlk17 20:08, 23 May 2007 (UTC)

Lower the tolerance on vandalism by anons

The problem about stopping anons from editing articles is that the majority of anon edits are constructive. So it will not be fair for the well behaving majority. So, another idea will be to lower the tolerance for anonymous IPs. Make it so that they can be blocked after just 1 warning, rather than the final warning. If the IP address is shared, urge any innocents to create an account. On the other hand, allow the admins to actively track the IP address of any users with fewer than 50 edits. Then it can be immediately known whether it's someone who creates an account just to cause trouble after his IP's been blocked.--Kylohk 19:40, 14 May 2007 (UTC)

  • Strong support - Lowering the tolerance is very much needed. I gets to be much less fun if you are stopped almost as soon as you get started. I have also called for a vandalism-revert flag to be added edit page so that people can point out vandalism to the admins. The two combined would no doubt curtail vandalism quite a ways. --EMS | Talk 20:11, 14 May 2007 (UTC)
  • Support – With a caveat. Certainly, that would make it easier to limit their activities and halt the bored children and casual mischief makers. I have a slight concern that this might result in more blocks being carried out, which would add to the admins' workload. That is in addition to the possible increase in malicious accounts and Agne's point about spotting IPs in one's watchlist. Adrian M. H. 20:33, 14 May 2007 (UTC)
  • Support I also agree. Four warnings and often more gives the vandal too much lenience. A quicker block will better stop the fun and multiple IP users may quicker as well. I don't think that extremly blatant vandals will ever become useful and must be stopped much sooner. Testers should perhaps recieve more warnings. Reywas92Talk 20:30, 14 May 2007 (UTC)
    • Comment I'm not sure that I care to distinguish between testers and vandals all that much other than to perhaps give the non-malicious testers a shorter block. In both cases people are looking to see what they can do, and the quicker you lower the boom the better. (However some cases, such as when the tester quickly reverts their own edit, can and should be excused with little more than a warning.) As for Adrian's concerns about workload: I suspect that this will decrease workload by stymying vandals before they get a sense of power and start treating the vandalizing of Wikipedia as a game. --EMS | Talk 02:55, 15 May 2007 (UTC)
Comment Looks like we are getting close to a consensus. If it is reached, I guess we can place it in the talk page of WP:VANDAL.--Kylohk 18:16, 15 May 2007 (UTC)
Done. See Wikipedia_talk:Vandalism#Lessening_the_tolerance_for_vandalism. --EMS | Talk 02:37, 16 May 2007 (UTC)
  • Strong oppose - seems like a slippery slope and prone to abuse, and lots of people genuinely trying to submit genuine will get hit in the crossfire, particularly people who "mean well". I also dislike the implication that people who make anonymous genuine edits will not do it from the same IP that would commit vandalism. Whatsmore, it may encourage the continuing practise of heavy-handed anon-IP blocks of "indefinite" over minor vandalism rather than the 24-hours deserved -Halo 01:44, 23 May 2007 (UTC)

Immediate blocks won't do much. Most vandalizing IPs only do it once or twice, and by the time you block them they'll be done. Night Gyr (talk/Oy) 05:39, 23 May 2007 (UTC)

This policy would never work in my opinion. There are far too many anonymous IPs that have multiple users. I recall how 300,000+ users from Singapore were blocked because someone didn't notice how they shared the same IP, and someone was using it to vandalize. Jmlk17 20:10, 23 May 2007 (UTC)
Support As a frequent vandal patroller, I have noticed that an IP will become very active in vandalism for a short period of time. I believe this could be due to the location the IP comes from, ie) a middle school. Now, this is a hypothetical situation, but if a group of students were on computers researching something in an english class, say Shakespeare, frequently, the WP page is the first one to hit in google. So, now you have a group of students, all accessing the same page and topic, and one student realizes you can edit the page, so they blank the page and add Janie loves Bobby to the page. Now, every student sees this in the class and they are editing like crazy and hence, a vandal attack is inadvertantly initiated. In this case, if the IP was monitored, and accessing the same article and causing vandalism, the IP could be blocked quickly and vandalism would be ended. This also leads to another question, should a short, ie 1hr block be standard for an IP that is identified with a school or similar institution, barring further vandalsim after the 1hr block is up? Plm209 (talk • contribs • count) 19:04, 30 May 2007 (UTC)

Friends List Or Activity Group

One User Should Be given the freedom to have friends of the same interests,that will ultimately result in the broadness of wiki as more and more information is gathered.

A friends list seems like it could be helpful when sharing information on articles/topics that a group of users are colaborating on. My big concern with starting a friend's section is that users will begin to use Wikipedia as a social networking site like Myspace or Facebook rather than a site dedicated to gathering information about a myriad of topics. Good idea in theory but seems like it would be bad in practice. Plm209 (talk • contribs • count) 18:53, 30 May 2007 (UTC)
Try a Wikiproject. KillerChihuahua?!? 11:08, 31 May 2007 (UTC)
maybe another tab entitled subject talk. You could then have general dicussions about the articles subject rather than just article accuracy or neutrality. Wardhog 22:51, 6 June 2007 (UTC)

Image zoom

I have two issues with the image pages - no caption, and checkerboard backgrounds. An attempt has been made to provide an image description but it does not serve the end user well - it's usually buried in the maintenance material - not good.

The checkerboard is displayed as if the image page were an image editor. Editors show checkerboard to indicate a transparent background. The end user does not want an editor's view of the image.

People need to zoom on images, especially the plots with small text labels. That's a weakness of html, and one reason why technical content tends to be published in pdf. Let's overcome this limit of html and provide the end-user a high quality image zoom facility, with caption, ane without the maintenance content, up to par with the general high quality of wikipedia. Rtdrury 19:42, 2 June 2007 (UTC)

Web policy

Did I miss the posting to editors that what they write in "user talk" appears on the web? I was very surprised to find my comments posted there.Alethe 02:12, 3 June 2007 (UTC)

umm... Wikipedia is on the web, everything you write here is on line, probably forever, even if you delete it. Jeepday (talk) 02:35, 3 June 2007 (UTC)

Merge of Template:Backlog, Template:Adminbacklog, and Template:Noadminbacklog

I am proposing a merge of the Template:Backlog, Template:Adminbacklog, Template:Noadminbacklog. Template:Backlog would be revised to use parser functions to have the abilities of the above 3 templates combined into 1 template. It would also be possible to switch "experienced editors" in Template:Backlog to something else. A draft of this can be found at User:Funpika/Drafts/Backlog. Funpika 17:47, 2 June 2007 (UTC)

I am taking the silence as acceptance of this proposal. I will begin the merge now. Funpika 21:07, 3 June 2007 (UTC)

Establish a convention for barring an editor from a page.

There are a lot of policies and procedures for dealing with problem editors, but each one has the drawback that it is somewhat time-consuming. Currently, those of us on the general relativity article are dealing with a very POV and disruptive editor. This editor feels the GR is "rubbish" and that the article should reflect that "fact". Currently, he is on a path to being blocked for disruption, but it occurs to me that it would be nice if a motion against the person could be brought on the talk page of the article.

I'm not sure what to call it, maybe a "motion to exclude" or a "reguest to deny editorship", but the idea would be that the editors of an article could request that a particularly bad editor be kept from editing the article. If established, it should be something that

  • Requires an administrator to sign off on.
  • Requires strong consensus of the article's editors to invoke (such as 75% or 80% of the established editors who work on and/or watch the article.), and
  • Has a quorum requirement (such as at least 10 or more editors expressing an opinion on the motion).

If the motion/request is approved, then any further edits by the editor would result in an immediate block, and being excluded from two or more articles could constitue grounds for a RfAr.

The purpose of the requirements I listed is to make it difficult for a cliche to control an article through this mechanism. A broad consensus of a large number of editors should be hard to come by unless there is an obvious cause for the action IMO, but the admin approval is an additional sanity check on such an action. That is not to say that other checks and balances (such as a review procedure) cannot also be established. --EMS | Talk 02:35, 4 June 2007 (UTC)

This is called an article ban, and it is already instituted in some cases. However, the decision to hand out article bans should not rest with those who edit the relevant article. It would be hard for a clique to control an article through this, yes. But if most editors of an article have some view X, it would be easy to imagine a case in which an editor who complains that the article is biased against another view Y would be banned from the article for no good reason. Also, article bans should be a last resort, occuring after blocks have shown to be ineffective. -Amarkov moo! 02:56, 4 June 2007 (UTC)
Community article bans seems like a sensible idea in some cases cases (General relativity makes a very good example). Why not propose to have the editor in question article-banned at the community noticeboard? —Ruud 07:45, 4 June 2007 (UTC)
Concur with Amarkov - this is already an option, with the emphasis on uninvolved editors deciding. However, I am not aware of any case where this sanction (whether endorsed on the community or admin noticeboards) has been implemented without the editor in question leaving the project. Addhoc 10:41, 4 June 2007 (UTC)

Page history – "previous" and "next"

The links for paging forward and backward in page history are confusingly backwards: previous for newer edits, and next for older edits. Is there any reason not to change these to either later and earlier, or Newer and Older (as in User contributions)? --Fyrlander 16:51, 4 June 2007 (UTC)

I strongly agree, though I'm not the one who can really help with this. Reywas92TalkReview me 20:21, 4 June 2007 (UTC)

see MediaWiki talk:Nextn, they cover this exact issue. Night Gyr (talk/Oy) 20:29, 4 June 2007 (UTC)

and it's covered by bug 4777 Night Gyr (talk/Oy) 20:30, 4 June 2007 (UTC)

Problem: Section renaming breaks links --- Workaround ??

Just a thought.... WP:GTL says, in pary, "Changing section names breaks links (hence the utility of permalinks), so it is best not to change already-established article section names." However, cases do exist where an article contains badly-named sections. How about a workaround for this problem something like {{alternative name|Old_name}}, which might be coded something like <p><a name="{{{1|}}}" id="{{{1}}}"></a></p> or {{#if:{{{1|)))|<p><a name="{{{1|}}}" id="{{{1}}}"></a></p>|}}? (here, I used the HTML anchor coding which I observe being generated in wikipedia article pages) -- Boracay Bill 03:58, 4 June 2007 (UTC)

If a section is poorly named, the incoming links should be updated accordingly. Unfortunately, it takes time to find all those links that specifically lead to one section. Editors are supposedly encouraged to use HTML comments to record the incoming links, but I've never seen that done. We probably shouldn't be using templates in article sections though. What happens when the section gets renamed again? –Pomte 23:27, 4 June 2007 (UTC)
1. it sounds as if you are disputing the guidance I quoted above from WP:GTL. 2. If a section is renamed seven more times, seven more instances of "{{alternative name|Old_name}}" could be added -- or not added -- editor's choice. 3. I don't follow the logic behind: "We probably shouldn't be using templates in article sections." -- Boracay Bill 23:40, 4 June 2007 (UTC)

Wikidata

Does anyone know where m:Wikidata is being discussed currently? All those links appear to be untouched since June 2006, and the wikidata-l mailing list is utterly silent. Omegawiki is not an official Wikimedia project (? so why does OmegaWiki list all our sister projects at the bottom of its mainpage?), but Wikidata isn't even mentioned at the foundation site... --Quiddity 19:52, 4 June 2007 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_AK&oldid=1249259695"