Wikipedia:Village pump (proposals)/Archive 45

Build in a list-comparer for categories.
Yes, I know I can just tee up AWB and use its list-comparer if I want to see what articles can be found in two categories, but I'm thinking of the masses who use Wikipedia on a purely piecemeal basis to research stuff. bd2412 T 04:32, 12 March 2009 (UTC)
 * This sounds like a job for toolserver. You might try bugging User:X! or User:Bjweeks who have a lot of tools on toolserver and might be able to make a client facing tool for people.  MBisanz  talk 08:22, 12 March 2009 (UTC)


 * The lack of Category intersection is a long standing complaint. There are technical issues that make a general solution difficult.  A partial solution now exists in search.  One can use multiple iteration of the search keyword incategory:, i.e. search for '+incategory:"Suspension bridges" +incategory:"Bridges in New York City"', etc. to find pages that are in multiple categories.  Dragons flight (talk) 17:07, 12 March 2009 (UTC)


 * Maybe it's my lack of technical savvy - I just don't see why it should be hard to do. The AWB listcomparer does it quite easily, why not just plug that exact code into a button on every category page? I realize that this is a tech issue, I hoped to gauge community support here before taking it up with the devs. Obviously, however, we've been down that road before. bd2412  T 17:58, 12 March 2009 (UTC)


 * Dude! Have you even looked at Category intersection. Why the hell do I bother writing an implementation?! --Dschwen 18:11, 12 March 2009 (UTC)


 * ✅ for the really lazy people: http://toolserver.org/~dschwen/intersection/ (so you don't have to read that page. --Dschwen 18:13, 12 March 2009 (UTC)
 * Don't get me wrong, I appreciate the tool, I'm just thinking of something for the masses - the people who don't edit Wikipedia, and only use it casually, who are unlikely to come across your excellent tool unless they happen upon a conversation like this one, or unless (and here's what I'm aiming for) it's built into the generic category page. bd2412  T 03:34, 14 March 2009 (UTC)


 * Yeah, that proposal comes up about every month (mostly on the mailing lists). The gist: with the current categorization scheme, which requires deep indexing (crawling of sub categories) this is a highly non-trivial problem (put lots of strain on the db). And I'd argue if people aren't really needing it, it should not be a high priority. My tool can be found through Category intersection, so I'd think if people need it they could find it, and yet its usage is disappointingly low. --Dschwen 15:35, 14 March 2009 (UTC)

RfC at WP:SPOILER
A RfC has been request to determine whether the Spoiler guideline (WP:SPOILER) should be changed to exclude plot details that some consider to be spoilers from the lead section of an article. --Farix (Talk) 14:05, 14 March 2009 (UTC)

RfC @ Notability (web)
Requesting comment on a policy decision with Notabiliy (web). -- Kraftlos  (Talk | Contrib) 03:02, 15 March 2009 (UTC)

Anti-blanking rule
I propose an anti-blanking rule so that any reduction of a large article to a few lines would be blocked. This blanking (diff) of the main page FA of today should not have had to be manually reverted. Smart people have probably already come up with logic to address the corner cases but if I had to spend 1 minute thinking about a rule, it would be that articles greater than ~10K in size can't be reduced to under ~1K; and such restrictions could be tightened up more for FA articles. Tempshill (talk) 23:16, 9 March 2009 (UTC)


 * It might not be a good idea. Imagine: one user adds lots of irrelevant text (or patent nonsense, or something like that) to a stub. Wouldn't such rule prevent another user from repairing the damage? --Martynas Patasius (talk) 23:57, 9 March 2009 (UTC)


 * No, this is a bad idea as it would impair subjects trying to removed BLP violations about themselves who do not know the editing rules, see and Requests_for_arbitration/Badlydrawnjeff.  MBisanz  talk 00:11, 10 March 2009 (UTC)


 * I think these three objections are pretty easy to fix. 1.  Lots of irrelevant text added to a stub would still be subject to "undo" and reverts.  2. and 3.  An attempt to (essentially) blank a page would be rejected with a rejection page stating, ''You've been prevented from removing a large amount of text from this article because experience has shown that such removal is usually vandalism.  If you are trying to remove information in an article about yourself, please contact our "Problem With Biography Of Living Persons" staff via e-mail.


 * Actually, there seem to be even more possible exceptions that cannot be worked around easily... For example, what if an article has to be redirected or merged into another one? And what if much of an article's text has to be split somewhere else? And would it apply to the talk pages or Wikipedia namespace (archiving does remove lots of text)? --Martynas Patasius (talk) 00:58, 13 March 2009 (UTC)


 * Good points. Redirects and merges would all get blocked.  Possible options would be to actually allow the blanking if it's replaced with a valid redirect - I assume that 99% of blanking vandals are unfamiliar wtih redirects - or implement a queue of "probable blanking edits" that an admin would have to approve before the edit is applied.  Removing a lot of text to go into a subarticle could use the queue also, though I think an effective blanking filter would target 90% text removal and I think splitting an article would not approach 90%.  Talk pages probably wouldn't apply.  Tempshill (talk) 17:35, 13 March 2009 (UTC)


 * Some version of this would seem extremely likely once the abuse filter is online. Dragons flight (talk) 19:07, 10 March 2009 (UTC)


 * The problem that led to this proposal is currently being handled quite efficiently. Usually, such massive blankings are reverted by bot. --  Blanchardb - Me•MyEars•MyMouth - timed 20:33, 10 March 2009 (UTC)


 * Yes, and that bot's logic can be placed in the abuse filter so the bad edits (that would be automatically removed anyway) aren't allowed to occur in the first place. I don't know exactly what criteria the bot is using, but it seems quite effective.  Dragons flight (talk) 22:27, 10 March 2009 (UTC)


 * Note that the Abuse filter isn't a complete replacement for antivandal bots. It can do math and some string operations. Its not a full programming language. Mr.Z-man 19:59, 11 March 2009 (UTC)


 * This is true, but I think the blanking logic (at least the examples I've seen) is simple enough to implement in the filter. (Unlike the page move logic BD2142 suggests above, which could only be partially accomplished with the current filter code.)  Dragons flight (talk) 21:00, 11 March 2009 (UTC)


 * We already have a policy against disruptive editing, I don't think we need a policy for each type. Blanking is easy to undo, we can use common sense when deciding how to deal with it. I don't think blocks for this should be automatic. Automatic reverting is just fine(as long at the automaton does not edit war). Chillum  15:11, 13 March 2009 (UTC)


 * Auto-reverting is certainly a perfectly fine solution as opposed to a pre-emptive block. Tempshill (talk) 17:35, 13 March 2009 (UTC)

For the record, a redirect requires an absolute minimum of fourteen characters: # r e d i r e c t [ [ x ] ]. Even the smallest possible template requires five characters: { { x } }. So far as I know, there are no single-character templates that could legitimately constitute the content of a mainspace page. We should at the very least prevent an edit that reduces a mainspace page to four characters or less, because there is simply no legitimate reason why any mainspace page would ever contain fewer than five (and, realistically, fewer than thirteen) characters. This will deter vandals whose mode is to click "select all" and then "delete" and "Save page". bd2412 T 22:20, 13 March 2009 (UTC)


 * This would stop page authors blanking their own new articles (typically leading the use of CSD-G7), which is a useful way of removing some of the less helpful new pages. Blank pages do not stay that way for long, as either Cluebot spots them or they head the list of short pages. --Rumping (talk) 12:03, 16 March 2009 (UTC)
 * Should be easy enough to implement the rule only where someone other than the person doing the blanking has edited the article. bd2412  T 12:10, 16 March 2009 (UTC)

SandBook?
This new book thing seems nice, but I'd quite like to have a play around with it without ruining anything already in place (e.g. accidentally deleting existing Wikipedia:Books/Foo pages or flooding Wikipedia:Books/ with new ones); hence, can a WP:SB-type page be created for assembling, saving and disassembling test books? Thanks! It Is Me Here  t / c 18:19, 14 March 2009 (UTC)


 * You could just as well use a user subpage. Right? §hep  Talk  19:08, 14 March 2009 (UTC)


 * A general sandbox would be better in the long run, though, so that more casual users might be able to take advantage of it too. It Is Me Here  t / c 18:17, 15 March 2009 (UTC)

New tag to indicate number of edits (and by whom)
This is NOT an idea I am suggesting for all the large number of articles in the English Wikipedia, just an idea which I am suggesting for a select number of articles which get edited frequently. Perhaps we could have a tag to say how often that article has been edited in the past four months or so. The same tag could also say whether these edits are by users who are anonymous editors or users who have confirmed uesrpage names, and how many of these edits are by the former, how many by the latter. There seems to be an unspoken assumption that edits are less likely to be works of Vandalism if they are done by users with usenames than they are done by those with mere IP addresses, so maybe this would help us to appreciate whether an article is likely to have had recent vandalism edits, or has been edited by reliable and trustworthy users. Certainly the assumption that users with userpages rather than users who just give IP addresses appears to be behind Protection policy. ACEOREVIVED (talk) 21:07, 12 March 2009 (UTC)


 * The thought behind (semi-protection policy is that newer users are more likely to be vandals; that's true of newly created user accounts as well as IP addresses (which don't necessarily have a single owner over time).


 * More to the point, if you click the "history" tab for a page, you'll find a link (at the top) for "Revision history statistics". That appears to be the sort of information you're suggesting would be useful.  I'm not at all convinced that it would be - knowing, for example, that 43% of the edits to an article were by IP editors implies what, exactly?  In any case, I don't think this information should be available directly on an article page; that would distract readers, most of whom wouldn't understand it (the number of readers of Wikipedia compared to the number of editors is roughly 1000 to 1). -- John Broughton  (♫♫) 16:57, 17 March 2009 (UTC)

Search tweak
Proposal for a search tweak. I was looking for the legal term "stay" and typed "stay (law)" in the search field and clicked Go. I was brought to the Search page where none of the 20 top search results was what I was looking for. I then went to the stay article, which is a disambig page that did indeed have a link to the article I was looking for: Stay of execution.

My proposal: If someone types "word1 (word2)" in the search field and clicks Go, and there is no "word1 (word2)" article, but there is a "word1" article, then the Search results' first result should be the word1 article. Leave all the other results in the list; just insert the "word1" article as result #1.

I acknowledge this search tweak only benefits users who are already familiar with the Wikipedia convention of using a parenthetical to distinguish topics. Tempshill (talk) 17:29, 13 March 2009 (UTC)


 * Comment I don't know what you mean. When I search "stay (law)" I get 1. Automatic stay 2. Stay of execution. I think the search engine searches the text and finds the most relevant with nearest occurrences between stay and law. Don't see the problem --Diaa abdelmoneim (talk) 16:04, 14 March 2009 (UTC)


 * I was referring to when the user clicks "Go", not "Search". Tempshill (talk) 17:11, 17 March 2009 (UTC)

Install DynamicPageList extension
After looking through WikiNews, I was impressed by the DynamicPageList extension, and it looks like it would be useful here. It is like a "smart" version of the
 * To your monobook.css. But I don't think the making-readers-and-editors-see-different-views-of-the-same-page route is a road we want to go down. Happy‑melon 17:11, 27 March 2009 (UTC)


 * Darned either way. Without the edit links, we will get queries about how to figure out the template to edit. --—— Gadget850 (Ed)  talk  -  17:16, 27 March 2009 (UTC)


 * The fact is that the vast majority of users of Wikipedia do not edit and users who are not logged in are unlikely to edit a template in any case because they are more likely to be new editors. If an unregistered user wanted those links displayed then they could change their preferences, I actually use the links quite a lot but I just think they are not relevant to most users. Darryl.matheson (talk) 17:26, 27 March 2009 (UTC)
 * The same could be said about much of the interface; even if it's going a bit far to say we should hide the edit tab, certainly most of the sidebar is useless to readers; should we hide that as well? Every reader who clicks on a link that takes them into the 'backstage' is a reader who could potentially be intrigued enough to become a fully-fledged editor, that's why we don't hide any of this stuff. It's not our place to decide what users do and do not want to see. Happy‑melon 17:38, 27 March 2009 (UTC)

These links should at least be marked as a blatant self-reference. We should not assume that every mirrored copy of an article which containing a navbox will be on an editable web-site, or that any separate page will exist for the template itself, etc. Thus in Template:Navbar class="noprint plainlinksneverexpand navbar" should be changed to class="noprint plainlinksneverexpand navbar selfreference" to help facilitate automatic removal of the "v•d•e" links on mirror sites, most of which will not want this. — CharlotteWebb 12:26, 29 March 2009 (UTC)

History with deleted versions
Hello. I think that pages that exist but was deleted in the past, should have deleted versions in the history tab. For example, the list could look like this:


 * (cur) (prev) 22:31, 2 November 2004 FrontFrog (talk | contribs) (undo)
 * Deletion log 13:17, 30 October 2004 Maxwell (talk | contribs) (Maxwell has restored article: Request of Lord Protector.)
 * Deletion log 22:40, 14 September 2004 SuperUser (talk | contribs) (SuperUser has deleted article: Somekind of nonsence.)
 * (cur) (prev) 22:31, 14 September 2004 Angela (talk | contribs) (undo)
 * (cur) (prev) 22:29, 14 September 2004 Grunt (talk | contribs)

--Janezdrilc (talk) 12:59, 29 March 2009 (UTC)
 * The deleted revisions are currently available to admins; this seems to work quite well as it prevents an BLP (etc) infringements, but allows for demands of information on request. - Jarry1250 (t, c) 14:58, 29 March 2009 (UTC)

watchlist for all versions of wikipedia
I contribute to several wikipedia language versions. It would be nice if I could have a common watchlist for all of them.Shep (talk) 14:03, 29 March 2009 (UTC)
 * See on a 'global watchlist'. Not currently available within the software. Cenarium (talk) 14:29, 29 March 2009 (UTC)

Date formatting and linking poll now open
The date linking and formatting poll is now open. All users are invited to participate.  Ryan Postlethwaite See the mess I've created or let's have banter 23:00, 29 March 2009 (UTC)
 * To all users, or just administrators only? ;) Someone forgot to unprotect it... Anomie⚔ 23:04, 29 March 2009 (UTC)
 * Doh!  Ryan Postlethwaite See the mess I've created or let's have banter 23:06, 29 March 2009 (UTC)

Add a tab to allow viewing the code without going into edit mode
This may well be a frequently-discussed proposal, but I can't think of a good way to search for it (as seen by my own clumsy title here). If it has been discussed before, I'd of course be grateful for a link that would let me see the facts and arguments on both sides.

What I'd often like as an editor is to see the (plain-language) code of a page without wanting to edit it or risking an accidental edit. Sometimes I want to copy a complete reference, the format of a table or the title of an image, or just to see how something was constructed, without having to risk changing the code accidentally or having to go through the steps of opening and closing an unnecessary edit process (perhaps causing a completely-needless edit conflict).

I can see a slight disadvantage in adding an extra "View" tab on page-tops that are already filling up with other tabs, but I think the advantages might be worth the cost. (I don't understand the technology behind Wikipedia, but perhaps it would also be easier on the system to have slightly-fewer prompts to be ready to upload new edits.)

—— Shakescene (talk) 05:15, 27 March 2009 (UTC)


 * Use Special:Export or just hit the back button on your browser once you've finished checking/copying the code. Graham 87 10:17, 27 March 2009 (UTC)


 * Actually, I just hit the "Article" tab. But I'd still prefer to be able to view how the article's written without even entering "Edit" mode when I don't want to and running the risk of changing the code (or creating an Edit conflict) by mistake. —— Shakescene (talk) 20:13, 27 March 2009 (UTC)


 * An edit conflict will not occur unless you have actually hit the "save page" button below the edit window. If you want to avoid accidentally saving a page, I suggest you go to Special:Preferences and look under "Editing" for the line marked Prompt me when entering a blank edit summary. This will make it practically impossible to save accidentally, as you will have to enter an edit summary to get the page to save. <font color="#CC7722" face="Papyrus">♪Tempo <font color="#00008B" face="Papyrus">di <font color="green" face="papyrus">Valse ♪  20:47, 27 March 2009 (UTC)


 * I do that, too (so I shouldn't have raised these secondary reasons in the first place); but I just don't like opening "edit" in the first place when it's unnecessary to do so and I just want to see the code. (And other editors won't know all these tricks.) —— Shakescene (talk) 21:08, 27 March 2009 (UTC)


 * Here's the problem: Every time we add another tab or other feature, the page looks even more challenging to new editors.  That you're uncomfortable doing something that has zero risk (because of how you have set your preferences) seems a very minor reason to add yet another feature.  Sure, inexperienced editors don't know the "trick" about an automated warning when there is a blank edit summary, but then, inexperienced editors typically don't want to see wikitext unless they are actually considering changing that text.


 * Besides which, if you or someone else do make a mistake and save a change that you do not want, it's pretty trivial to revert that change. -- John Broughton (♫♫) 01:01, 29 March 2009 (UTC)

For example, when an anon tries to edit a semi'd page or a non-admin tries to edit a fully-protected page, they get a screen like the OP wants. What would be nice is to be able to change the url of a page to "view" the code; something like this instead of like like that (note the ends of the URLs). I doubt the change would be difficult. There's probably something like that already, but that would have to be accessed through the API, if it even does exist. --Izno (talk) 04:12, 29 March 2009 (UTC)
 * It's also pretty trivial to not make the mistake in the first place if his suggestion is implemented. I don't think a tab-for-everybody would be a good thing, but throwing together tabs with javascript is simple, and other scripts already do that (such as Huggle). The problem is that the OP lacks a suitable way to hook into a "view" screen rather than an "edit" screen.

Thanks for the feedback; it allowed me to clarify the possible reasons better in my own head.

First (if I correctly understand an unspoken implication of at least part of Izno's posting), I think it would definitely be desirable — if such a tab were available (either by default or through User Preferences) — that it resemble the "Watch/Unwatch" tab in being only available to and us[e]able by Registered Users. Clutter and confusion to new readers and editors is certainly one of the possible drawbacks I could see in an extra tab.

Second, I can be a bit more articulate about why I think such a tab might be useful to me even after having done a couple of thousand edits. One reason is a bit abstract, and the other pretty specific.

(A) On the more general level, whenever I (or I presume most people) are on line, there's a certain level of attention and anxiety required to avoid sending or receiving something unintended, just as one is more relaxed composing a hand-written letter than in making a telephone call or sending an e-mail. There's far less chance of a sudden lapse or hasty misunderstanding if one has to go through the steps of writing, revising, folding, addressing, stamping and depositing a letter. Even though (for the technical reasons mentioned above) there's little chance of a serious or irreparable error in editing Wikipedia, every unnecessary doubt or hesitation in the back of one's mind that can be lessened is attention that can be brought to something more important.

(B) The practical situation that makes me wish for a "View" tab is this: When I'm copying a footnote, image, format, colo[u]r code, link or statistic from one article to another (e.g. an election return or the full bibliographic entry for The Encyclopedia of New York City between New York pages), I almost always have more than one browser tab or window open in "Edit" mode, even though (being at least partially sane) I usually want to edit only one of those pages at one time. This can be particularly tricky if (say) one footnote or link seems clearly better than the other, and I'm pasting over previous text. Although it's never got[ten] so far as to cause any noticeable damage, I've sometimes caught myself in the middle of pasting the "bad" footnote or link over the good one, i.e. the exact opposite of my intention. If, in the middle of constant jumping between windows, I could see all the code I need while only being able to edit one page, it would make the process far surer and easier for me. —— Shakescene (talk) 07:50, 29 March 2009 (UTC)

Eh just use <tt>&action=raw</tt>. — CharlotteWebb 12:07, 29 March 2009 (UTC)


 * OK, I'll bite; not being a techie, I have only the faintest, foggiest notion of what that might mean or how I could use it. —— Shakescene (talk) 18:01, 29 March 2009 (UTC)


 * What that means is if you click on the edit tab of a page then look at the URL in your address bar, you will find that it contains the text <tt>&action=edit</tt>. If you replace that with <tt>&action=raw</tt> and press enter, you will be prompted to download a file. If you download that file and open it with Notepad, you will see the wikitext of the page. Tra (Talk) 19:12, 29 March 2009 (UTC)

Here's some code that will give a view tab next to the edit tab. It uses the api so it does have the disadvantage of there being a lot of code you won't understand before and after the source code of the page.

To use this code, go to Special:MyPage/monobook.js, click the edit tab, copy and paste in the code and save the page. Then press Ctrl + F5 to clear your cache. Tra (Talk) 19:12, 29 March 2009 (UTC)


 * Or I could hit "Select All" (Control-A), "Copy" (Control-C), open Notepad (or, for longer articles, Wordpad) and paste the text onto that (which I've done in the past when I've wanted to use the Find & Replace function to change repeated wikilinks, formats or color codes). If this thoughtfully-provided code is something I'd have to paste onto each page each time after I've already opened it in Edit, I'm not quite sure of the advantage. Perhaps if could paste it onto the URL of the main Article (/Project Page/Template/...) View instead of pressing the "Edit" tab, it might work as a fix. —— Shakescene (talk) 20:52, 29 March 2009 (UTC)


 * I'm not sure you're completely understanding what you have to do to use this code. I'll try and explain it a bit clearer.
 * To install the code (this only needs to be done once), follow these steps:
 * Select the code I wrote above and press Ctrl + C.
 * Click on this link then click 'create this page'.
 * Click in the edit box and press Ctrl + V.
 * Click 'Save page'.
 * Press Ctrl + F5.
 * Once you have installed the code, you will see a 'view' tab on each page on Wikipedia. If you click on this tab, you will see the source of that page, along with some extra code which you won't understand.
 * If you're still not sure what this all means and you would rather I installed the code for you, please say so. Tra (Talk) 18:23, 30 March 2009 (UTC)

Wikipedia to have audio readout of whole article.
I was thinking if wikipedia had a complete audio read out of the article i would not have to read it. I know youtube has something similar and thougght it would give wikipedia more appeal.
 * Some articles already have this; see Spoken articles. However, the recordings are made manually so it's difficult to cover a lot of articles. Tra (Talk) 22:48, 30 March 2009 (UTC)

List of reliable/unreliable sources
I'd like to suggest having a noticeboard or a list of sources that can/cannot be used on Wikipedia. This seems urgent with the many sources that get contested on FACs and FLCs where reviewers ask about the reliability of the sources. If there was a list of sources that can be used on Wikipedia it would be easier to check a sources' reliability. This would also make a central hub for sources a user can research to improve his topic. I'd suggest a bot that adds all references an FA or FL has to this list. Users would also add websites they think are reliable, which if contested would go on reliability review. A user posting an FAC or FLC would have the option to check his sources before posting it. The list would of course have a subcategories with each topic like newspapers, magazines, blogs and websites (to be decided on). Official websites of companies don't have to be on these lists as they assert their own reliability. For example: someone doesn't know if www.techradar.com is reliable or not, he goes on the page of websites and finds it to be reliable or not. This would make checking reliability much easier and would have many future uses. I'm not suggesting VPR/Perennial but just a list of reliable, already on Reliable sources/Noticeboard discussed sources to make research and reliability easier.--Diaa abdelmoneim (talk) 08:49, 17 March 2009 (UTC)


 * A hole in the above would be if a normally unreliable source were to make an exception and write a few really great, well-researched pieces with references, good enough to be considered a reliable source. Conversely, a normally reliable source might have a blog-like column that's unreliable.  Both situations would have users on the wrong side of the argument using your noticeboard as ammunition for their arguments.  Tempshill (talk) 17:14, 17 March 2009 (UTC)


 * We don't judge reliability at the page level (whether something is well-research and well-cited); we judge based on whether the site does fact-checking, its overall reputation, use of expertise, etc.). In your first example, an editor should follow the references; in the second, it's an issue of dealing with incorrect information or information that contradicts other reliable sources.


 * I think this is worth further discussion, though I wonder whether it's really worth it, given the literally millions of websites out there, and the archives search function for the noticeboard. And if there were a list, I think a strong argument could be made to semi-protect it, so that any established editor who posts inappropriately there risks being called out for such an action.


 * Finally, you might want to post at Wikipedia talk:Reliable sources/Noticeboard; the editors who read that page regularly are probably the ones most capable of commenting on this proposal. -- John Broughton  (♫♫) 18:32, 17 March 2009 (UTC)

I think a list could be helpful, but I think we'd have POV pushers and spammers constantly screwing with the list. But then at least the battle over decidin such things would be limited to one plae instead of spread out over countless talk pages. Any bot trying to label reliable sources would be completely impractical and problematic, however. DreamGuy (talk) 13:56, 18 March 2009 (UTC)


 * There is really a spectrum of how reliable a source is - it is not always black and white. For example, I write articles about historical events.  A newspaper article may be a terrific source for modern reaction to those events.  The same newspaper (or same article) would not necessarily be appropriate for a description of the events themselves.  For the description, I should first consult books or papers written by historians who have actually researched the events.  It very much depends on the source and how it is used, and there is such a wide variety of sources that it is not really possible to categorize them all. Karanacs (talk) 14:50, 18 March 2009 (UTC)

Such a list could still be useful. I remember once almost using The Huffington Post as a source, because I thought it was the local newspaper in some town called Huffington. --Apoc2400 (talk) 18:42, 25 March 2009 (UTC)


 * It's going to be an awful battleground. You'll get cabals trying to get a general ban on sites that don't suit their point of view. Probably they'll succeed at least some of the time. I think the potential bad of this outweighs the potential good. I think it's probably better to keep these battles isolated and spread out. -- Ong saluri (talk) 19:30, 31 March 2009 (UTC)

Use the globe as a favicon
There have been several proposals to change the favicon in the past, with people seeming unhappy with this basic (and now very old) design. See /Archive_29 and /Archive_35, there are also some murmurings in relation the the Wiktionary logo discussion that it'd be nice to have a different favicon from Wikipedia. As the globe is used by most other Wikimedia projects when linking to Wikipedia (see b:Template:Wikipedia-inline), and it is the logo for the project, it seems silly not to use it as a favicon. Conrad.Irwin (on wikt) 15:47, 29 March 2009 (UTC)


 * The globe doesn't shrink to favicon sizes well. I greatly like the simplicity and clarity of the current favicon. If there were an icon to be tweaked, I'd suggest changing the icon used for the iPhone and iPod Touch slightly, but that's a different discussion. { { Nihiltres | talk | log } } 17:56, 29 March 2009 (UTC)


 * Wiki.png This is roughly what the globe would look like when shrunk to favicon size. It's far less identifiable than the current "W". --Carnildo (talk) 22:23, 29 March 2009 (UTC)
 * You should probably use one of the versions without words at the bottom for a fair comparison: Wikipedia-logo.png Wikipedia logo (svg).svg Wikipedia svg logo.svg Wikipedia-logo.svg Not that any of those are much better so small. Anomie⚔ 23:01, 29 March 2009 (UTC)


 * Too many other sites use globes. And their globes can use more color to be more distinctive.  -- SEWilco (talk) 23:08, 29 March 2009 (UTC)


 * I prefer the miniaturized globe. It would make it a lot easier to tell Wikipedia apart from other Wikimedia sites. The miniature globe doesn't have to look perfect; you just have to be able to tell what it's supposed to be. —Remember the dot (talk) 01:53, 31 March 2009 (UTC)


 * On my monitor the "miniaturized globe" is just another fuzzy gray sphere. --Carnildo (talk) 22:37, 31 March 2009 (UTC)

New featured content
I have put forward a proposal for Featured redirects. Any comments at the proposal's talk page would be welcome. —  Tivedshambo   (t/c) 05:09, 1 April 2009 (UTC)

MediaWiki:Revertpage
I have made a proposal at MediaWiki_talk:Revertpage. -- IRP ☎ 02:21, 1 April 2009 (UTC)

External links noticeboard
I deal oftentimes with the removal of external links that I don't see as meeting our external link guidelines and oftentimes these removals are contested. This oftentimes happens on smaller, out-of-the-spotlight pages in which it's hard to get an outside conversation going. The debate is oftentimes with newer users who don't understand the guidelines, and users with a conflict of interest who want the links up for promotional purposes. When discussions with these users come to a stand-still and edit-warring begins, I find it hard to bring the debate to a larger audience in an attempt to find a consensus. With spam there is WT:WPSPAM, with sources there is WP:RSN, with BLPs there is WP:BLPN, but there is no place for external links in themselves. WP:RFC can be about anything content related, and oftentimes RfCs are slow to develop, when a quick consensus about an application of the guidelines is all that external link problems need.

I'd like to start up an external links noticeboard, to create a forum for the discussions over individual external links on Wikipedia. This would be different than WT:EL, which is about the discussion of the guidelines proper. This would be a board in which editors would try to find consensus in disputes involving external links; what should be linked to, and what shouldn't be linked. I think this would be a quick and efficient way of handling many debates on the far-corners of Wikipedia, as the problems can be brought to a central noticeboard for uninvolved editors to look at. Themfromspace (talk) 14:12, 12 March 2009 (UTC)
 * I like the idea. Often times it's not really spam per se and it'd be worth linking to if WP *did* allow no real limit to ELs. So a place to say "hey would you come look and see if you think this is worthwhile" without having to goto the blacklist or spam board... ♫ Melodia Chaconne ♫ (talk) 14:46, 12 March 2009 (UTC)
 * Another advantage would be the specific examples/discussions editors could use when researching similar links. Flowanda | Talk 19:44, 12 March 2009 (UTC)
 * Seems like a good idea since it is divorced from the concept of only "spam", but rather all merit topics. I expect it would be a place with a lot of headaches, but still it makes sense to have a place to centralize headaches. 2005 (talk) 02:44, 13 March 2009 (UTC)

Yes, I can see the wisdom behind this - having a noticeboard to discuss the disputes about what should be in an external link. I have a question, though. Did you mean that this would be to discuss what should go on the page of external links guidelines, or to discuss the sub-heading under "What Wikipedia is not" which says "Wikipedia is not a repository of external links"? Or is there something on Wikipedia (which I have yet to see myself) to the effect of a category entitled "Pages with disputed utility to their external links"? ACEOREVIVED (talk) 22:24, 12 March 2009 (UTC)
 * Most of that is handled now at WT:EL. I don't think that the volume is high enough on that page to justify creating yet another bureaucratic forum.  Aceorevived, the category you're looking for is  Category:Wikipedia external links cleanup.  WhatamIdoing (talk) 00:12, 13 March 2009 (UTC)

Please be aware that any organized body of deletionists will require the organization of a body of contributors: This isn't the answer. Discussion is. I'm not sure how many groups of contributors Themfromspace is edit warring with today, so I'll just touch on the conflict that I'm involved with. Attempts at discussion are ongoing at three locations: Themfromspace's talk page, Roguebfl's talk page, and the  Reliable Sources Noticeboard. This would be number four. Roguebfl, A Quest For Knowledge, and I have open questions for Themfromspace. I think we deserve answers. BitterGrey (talk) 04:10, 13 March 2009 (UTC)

Reposting from the previous board where Themfromspace sought to recruit outside support, as opposed to discussing changes... BitterGrey (talk) 04:10, 13 March 2009 (UTC)
 * Themfromspace has concluded that the link to understanding.infantilism.org gives "undue weight to minority views". (Or, at least that is what he wrote before.) He has been asked repeatedly to be specific about what underrepresented majority he is concerned about.. If he's willing to be specific about what views he thinks are being left out, a compromise can probably be reached.BitterGrey (talk) 04:26, 12 March 2009 (UTC)


 * ...Themfromspace, the assertion about simply enforcing Wikipedia policies is discredited by the link you repeatedly left in place. Here you are trying to assert that understanding.infantilism.org might be a little biased.  The link you repeatedly left in place was clearly labeled as both an open wiki  (#12 on the list of links to be avoided) and  not in English.  (Windelwiki might be an excellent resource.  Since I can't read German, I don't know.)  Paraphilic infantilism is a medical condition (Diagnostic and Statistical Manual of Mental Disorders, Fourth Edition, Text-Revised. Washington, DC, American Psychiatric Association, 2000, pg 572-573) and those who have it have a right to exist and to be understood. I would imagine this viewpoint could seem off-center to one who openly frequents Encyclopedia Dramatica.  Now, are you going to let us in on the secret?  Who is this 'majority' that you are edit warring on behalf of? ...BitterGrey (talk) 04:26, 12 March 2009 (UTC)


 * BitterGrey, just to clarify, you're unhappy with Themfromspace for removing your pro-paraphilia website from the ==External links== section of Paraphilic infantilism, correct? WhatamIdoing (talk) 05:09, 13 March 2009 (UTC)
 * "pro-paraphilia?" Do you think Themfromspace's underrepresented majority view is some anti-paraphilia postion?  This is a discussion that Themfromspace should have at least tried to engage in before warring and recruiting.
 * I'm unhappy that he was edit warring with another editor and trying to recruit the help of others, as opposed being willing to discuss his actions. To avoid a conflict on interest, I have not joined in the edit war myself.  I have, however, joined in the discussion.  Please note that I have made multiple disclosures about being the maintainer of that website (specific to this conversation: ,) and have avoided making any changes to the external links list. BitterGrey (talk) 06:22, 13 March 2009 (UTC)
 * Thank you very much for hijacking this discussion that had nothing whatsoever to do with your particular link. I started it in part because I realised that there was no place to go to discuss links like yours.  The reliable sources board isn't appropriate, nor is the article's talk page as there aren't many people there familiar with the guildelines.  Please take this elsewhere as this board isn't the place to discuss your particular link.  If there was an external links board, on the other hand..... Themfromspace (talk) 11:24, 13 March 2009 (UTC)
 * Since he didn't mention a thing about all this in his initial post, you have no real bases for bringing all that up here. I don't see any reason you can accuse him of 'recruiting' in some negative sense. ♫ Melodia Chaconne ♫ (talk) 11:26, 13 March 2009 (UTC)
 * My apologies if I spent too much time detailing a specific example. The point is that in at least one case, Themfromspace sought support elsewhere instead of engaging in discussion.  The post here followed directly after his not getting support from the  Reliable Sources Noticeboard, and that discussion was specific to this example.  (By the way, there is one person from that board who asked a question and I think deserves an answer.)  Themfromspace didn't inform me about that discussion either.  I stumbled across it in a change log, and it was an unpleasant surprise.  I'll concede that it is possible that the discussion here was triggered by some other edit war that he is currently involved with, as opposed to the example.  Exactly how many edit wars is he currently involved with? And how many of those also could have been resolved by engaging in discussion there? BitterGrey (talk) 13:26, 13 March 2009 (UTC)
 * This isn't a referendum on my behaviour at all. Stop bringing me into this. This is discussion about the creation of a noticeboard.  I won't respond to any more posts from you on this board. Themfromspace (talk) 14:00, 13 March 2009 (UTC)
 * Actually I think it is extremely relent. Does you proposed noticeboard exist to discuss and resolved differences, or is it merely a flag for "watch these pages to remove stuff I disagree with" if it the former it a good idea, if the later it a bad idea that will only bring more damage to Wikipedia reputation Roguebfl (talk) 16:17, 13 March 2009 (UTC)
 * To bring this back to the requested discussion...I have a question based on WhatAmIDoing's comment about existing resources. I wonder if one reason for the low volume at the WP:EL talk page is because it's a talk page instead of a noticeboard. I've looked through the EL's talk page and archived discussions before, but I would never consider posting a request about a website or conflict because it's not clear to me that that's what the page is for. Flowanda | Talk 03:09, 14 March 2009 (UTC)
 * Exactly, WT:EL is the talk page for the guidelines themselves and the talks there are about the wording of the guidelines.  We have a noticeboard for BLPs, ethnic conflicts, fiction, fringe theories, original research, copyvio, and spam.  Why not one for external links?  Themfromspace (talk) 17:52, 14 March 2009 (UTC)

Support. WT:EL isn't at all intended for this. Let's set up a noticeboard and see what happens; if it turns out to be very problematical (can't see why) or redundant (ditto), then it's easy enough to shut it down. -- John Broughton (♫♫) 16:46, 17 March 2009 (UTC)
 * Oppose - I just think that we have too many noticeboards already. ╟─ Treasury Tag ► contribs ─╢ 16:47, 17 March 2009 (UTC)
 * Support. Go for it. Cla68 (talk) 02:48, 18 March 2009 (UTC)
 * Support--Legeres (talk) 20:29, 21 March 2009 (UTC)
 * Suppport I need it now! (really). Dougweller (talk) 16:22, 27 March 2009 (UTC)
 * Support seems like a decent idea. <font color="#CC7722" face="Papyrus">♪Tempo <font color="#00008B" face="Papyrus">di <font color="green" face="papyrus">Valse ♪  16:54, 27 March 2009 (UTC)
 * Strong Support Need a place to get impartial advice on links --DFS454 (talk) 18:33, 29 March 2009 (UTC)
 * Comment -- I'm a frequent Talk: Wikiproject Spam, Talk:Spam Whitelist and Talk:Spam Blacklist participant. I see pluses and minuses. On the plus side, we need a place to discuss the value of certain links without the perjorative implications of holding it on a noticeboard associated with spam problems. The spam boards are really about behaviour and we're talking here more about content value. On the minus side, it could become just one more noticeboard either underutilized or dominated by a handful of like-minded editors. It might also overlap with both the Reliable Sources Noticeboard and the spam talk pages, leading to confusion and possible forum-shopping. I suggest that perhaps the best solution might be to expand the the scope of the Reliable Sources Noticeboard to include the editorial merits of external links at the end of an article (leaving spam behaviour to the spam boards). --<font face="Futura">A. B. (talk • contribs) 13:28, 1 April 2009 (UTC)

'Common sense' has to be promoted more
Sometimes people become so fanatical into requiring sources to an article that it makes it look ugly and b) it makes you suspect we're talking about politics, people that's just don't like some common sense stuff and become entrenched into a 'sources hunt'. For example, in digg it is sourced that "there is suspicion that some people bury [vote down] articles they don't like politically". Come on, seriously, of course people downvote things they don't like politically, that's more common sense than gravity working on earth. --AaThinker (talk) 09:51, 24 March 2009 (UTC)
 * Your quote does not exist in the article. What is in the article says considerably more (it mentions a "Bury Brigade", implying that there is some organized clique of users who do this, and says that this is (according to one commentator) 'one of the site's major problems'), is not obvious, and needs sourcing. Algebraist 12:53, 24 March 2009 (UTC)

Please remember that, along with the principles of NPOV and no original research, WP: Verifiability is one of the fundamental principles of Wikipedia. This does not mean that everything on Wikipedia must be capable of being proven (after all, very few statements are); it means that claims should be backed by evidence through source citation, whether through citation of references in journal articles, in books or on the Web. I am not sure why you consider that having a long list of references at the end of an article would make the article "ugly"; after all, academic textbooks, journal articles, undergraduate and Master's level dissertations and indeed, Ph.D. theses would have lists of references appending them. Also, remember that what is common sense to one personl may not be "common sense" to another person - quite often, one might think that something is sense, but not COMMON sense (if by the term one means that the majority of the population will think that way). ACEOREVIVED (talk) 21:32, 29 March 2009 (UTC)
 * WP:V only requires that sources be provided for material that is potentially controversial or likely to be challenged. People seem to forget this. OrangeDog (talk • edits) 19:27, 1 April 2009 (UTC)

Minor edits
I hope this isn't a recurrent topic (I don't watch pump discussions that much anymore). In a current RfA, a candidate received criticism for his incorrect marking of edits as minor and I was wondering why we still keep that feature around. I think it's a remnant of the early days of the wiki but here are a few reasons why we should just disable the whole thing. Among the good reasons: Thoughts anyone? Pascal.Tesson (talk) 00:42, 25 March 2009 (UTC)
 * Most editors don't use it when editing. If an edit is marked as minor, chances are it's because the editor has "mark as minor by default" in his preferences.
 * Newbies don't know how to use it. Not because they're dumb but because it's not really something they worry about or even know about.
 * Few editors use it consistently and those who do provide good edit summaries. No real gain.
 * No one in their right mind would toggle minor edits off their watchlist. If you do that, then any vandal marking their edits as minor flies under the radar. Also, watchlists now provide the size of the diff which is often a better indicator when you know that the editor can be trusted.
 * Does anyone really see the bold m in the history? Frankly, I don't and it can only be useful if you trust that everyone uses that feature carefully and with consistency. And of course, that's not the case.
 * It's occasionally a source of strife. As in the RfA above or in other contexts where person X accuses person Y of marking an edit as minor although it isn't. This wouldn't really be a concern if the minor edit feature was of any actual use to anyone, but since it's not...


 * I'm inclined to agree with you that Wikipedia would be better off with the simplification of removing this functionality. It's a feature that depends on widespread knowledge and widespread compliance, and that simply isn't going to happen.   But: how much work would be for developers to remove minor edits not only from the edit screen but also as a filtering option on many special pages?  -- John Broughton  (♫♫) 01:05, 25 March 2009 (UTC)


 * Simply turning it off as an option when editing would be trivially simple. Removing it entirely from the software would be a bit more work; there's at least 14 files that contain "minoredit" not counting all the message files or any maintenance scripts. There's also columns in the revision, archive, and recentchanges tables to store minor edit information. <font face="Broadway">Mr.Z-man 01:41, 25 March 2009 (UTC)


 * I use it often; I don't have "mark [edits] minor by default" set in prefs.
 * Without intending to be facetious, newbies don't know to do a whole bunch of wiki-things, because they're new &amp; haven't learnt yet.
 * I see the bold m. :)
 * My only real point is that I use it often and find it useful. Useful to aid other editors who might have an article, on which I'm making a series of edits of varying degree, watchlisted; and, vice versa. –Whitehorse1 02:14, 25 March 2009 (UTC)
 * When I see an edit by an editor I know marked as minor (which is most editors I would trust to make good edits in the first place), I assume it's minor and don't bother with it. bd2412  T 03:29, 25 March 2009 (UTC)
 * If anything I'd prefer the feature expanded so it could be safe to hide minor edits. Specifically:


 * Allow the original editor to change the minor status of an edit. A number of feasible clarification criteria are possible here.


 * Allow the automated reverts and undos to make the revert and the original edits minor.


 * Allow anyone (or more likely logged in users) to remove the minor status of any edit (or just IP edits).


 * Mark Hurd (talk) 04:21, 25 March 2009 (UTC)

But that would be a complete bureaucratic nightmare, not to mention a big waste of time. I can just imagine the edit wars over the status of an edit! In any case, it only makes sense if everyone is on board which, obviously, will not happen. And that's my argument for removing the feature in the first place: if only a small minority of editors use it then it has no purpose. In my mind, the minor edit checkbox is just a distraction in what's already a fairly non-user-friendly interface. Pascal.Tesson (talk) 19:17, 25 March 2009 (UTC)


 * The feature can be trivially removed from use by removing the <tt>minoredit</tt> permission from the <tt>'user'</tt> usergroup; it simply won't be possible for anyone to mark edits as minor. There is a minor technical issue in that bots will need the ability to make minor edits in order for their edits to user talk page to not trigger the new messages banner, but that's easily remedied by granting them the permission explicitly.  I'm inclined to agree that the feature is largely useless and should probably be removed. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 20:29, 25 March 2009 (UTC)

If you go to "Minor edit", you can press on hypertext which says "What's this?" which should explain to any one what a "minor edit" is. Personally, I think the feature is quite useful myself. If one looks at the history of an article, it enables which of the edits are mere minor corrections, such as proof-reading corrections (for example, correcting a word that was formerly spelt wrongly), and which of them represent substantial changes to content. I expect that people are more likely to compare versions of past articles in cases where edits have not been marked as minor. ACEOREVIVED (talk) 19:57, 28 March 2009 (UTC)
 * I too find it incredibly useful when searching for content edits in page histories, as well as looking over my watchlist. I mark all my minor edits as minor to likewise help others. Why remove a feature that is both useful and does no harm? OrangeDog (talk • edits) 19:31, 1 April 2009 (UTC)

April 1st guidelines for 2009
This issue comes up anually and I would like to make it this year. This could have been posted on Talk:Main Page, WT:FAC, and WT:DYK, so this is a central discussion. I would like to propose the following: The following thing will be permitted that would normally be struck down as per WP:POINT or WP:DE: Like the idea?--Ipatrol (talk) 22:56, 25 March 2009 (UTC)
 * The main page FA must meet the FA criteria, same for the FP
 * The DYK must follow the criteria it follows all year, same for on this day and in the news.
 * All articles are to remain in tact
 * Humorous project pages may be created
 * Humorous RFAs, XFDs, PERMs, RFPPs, and VP proposals
 * Agree, there should be some April 1 spirit on the Main page. There is a discussion going on for a while already, check Wikipedia talk:April Fool's Main Page.--Tone 23:07, 25 March 2009 (UTC)
 * Yep, DYK made a decision long ago to still follow the regular DYK criteria. The only difference is that the April Fool's DYK hooks are allowed (and expected) to be misleading, which is discouraged in regular DYK hooks. <b class="Unicode">r ʨ anaɢ</b> talk/contribs 23:10, 25 March 2009 (UTC)


 * Isn't this... just what we do anyway? It seems a bit odd to go to the effort of producing guidelines to tell us to keep doing what we'd do regardless. Shimgray | talk | 23:23, 25 March 2009 (UTC)


 * Yarly. WT:AFMP has this covered already, including criteria for inclusion. Besides, they have developed better criteria than yours for eg DYK, and I don't see how creating frivolous project pages is a good thing. <b style="font-family:Times New Roman; color:maroon;">Modest Genius</b> talk 01:10, 26 March 2009 (UTC)
 * There is another exception: We normal use a 5-day period to evaluate the DYK articles. For April Fool's Day, we have always accepted nominations that were created or expanded 5x at any time during the prior year. We have dozens of DYK articles that were created in good faith in the past year using this assumption. DYK are expected to be misleading/misdirected. Featured Picture and Featured Article criteria say that it has to be featured through the normal process.  Royal broil  02:00, 26 March 2009 (UTC)

Agreed, lets keep April 1st special .... as usual. Breaking the rules is something that requires that extra effort on April 1st. Luckily we have responsible and fun loving editors. Not sure we need extra guidelines, but dusting them may advertise the event.Victuallers (talk) 17:26, 26 March 2009 (UTC)
 * This proposal has rather a lot of the "All festive frivolity must be strictly within authorised merriment guidelines!" over-regulation. Previous April Fools' pranks that went too far have been dealt with appropriately as they crop up - there is no need to proactively anticipate problems and come up with guidelines. ~ mazca  t 21:29, 27 March 2009 (UTC)

I think April Fools shenanigans are OK as long as it's kept to Wikipedia and User namespaces and it doesn't cause undo insanity. Also, in keeping with our tradition for the last few years, the FA was chosen and written up in such a way that everything in it is true, but hopefully people will write it off as an obvious hoax. Raul654 (talk) 21:35, 27 March 2009 (UTC)


 * If people are ever going to take us seriously then this is just an excuse not to, all my friends laugh at me because I frequently edit here, they see it as a joke, something to vandalise, and yet the edits here are just as disruptive and untruthful as anything they could do. An encyclopedia should be factual, and no matter how true the stories are, they deliberatly mislead, if a newspaper did that they'd get sued! <font face="Batik Regular">Highfields (talk, contribs, review) 18:21, 1 April 2009 (UTC)

You don't mind if WP:BAD is un-historicaled for April Fool's Day, do you?
....hmmm... 192.12.88.7 (talk) 05:33, 1 April 2009 (UTC)
 * I see a certain editor or two failed to notice this in the Village Pump. 192.12.88.7 (talk) 15:04, 1 April 2009 (UTC)

Featured Picture sizes and all other images
Download size options on featured pictures seem to be either small (the size it appears on the page) or whoppingly large (17MB on today's FP). It would be useful if one could choose from a range of download sizes after right-clicking. ciao Rotational (talk) 07:15, 1 April 2009 (UTC)
 * I agree that it would be handy if Wikipedia offered this on the image page, but regarding right-clicking, this is a browser function and Wikipedia could not control the options you get when you right-click. Just being pedantic, but wasn't sure if you were aware of that. Diliff  | (Talk)   (Contribs) 07:22, 1 April 2009 (UTC)
 * Thing is there are no standardly generated sizes, the smaller versions for thumbnails on pages are dynamically generated by the Mediawiki software when the pages are rendered. The only one that is vaguely consistent is the large thumbnail used on image pages. That's not to say that its not possible to have a page with for example 1024, 1600 and 1900 wide versions of the picture of the day for people to easily drag onto their desktop, just that no one has done it. Mfield (Oi!) 07:26, 1 April 2009 (UTC)
 * You could add Example.png to a random page, preview and download the resulting picture but that's rather awkward. MER-C 08:45, 1 April 2009 (UTC)
 * Something like the options given on the Hubble site  http://hubblesite.org/newscenter/archive/releases/2009/13/image/a/    Very user-friendly Rotational (talk) 09:58, 1 April 2009 (UTC)

New Footnote Tags
I propose that superscripted footnote-tags be created for each of the following six scientific classifications, all of them found in Wikipedia: in vitro, in vivo, in situ, ex vivo, in utero, and even in silico.

Need: to uniformly and concisely impart to the reader the specific nature of the experiment being referenced by footnote. Implementing this change would also effect a needed review of references.

Problem to solve: A footnoted statement of fact in an article may imply, for example, an in vivo context, yet the study referenced may actually be strictly an in vitro one. This proposed change would prevent that confusion by means of an identifier in the superscripted footnote itself. Eye.earth (talk) 13:53, 26 March 2009 (UTC)


 * If the article text and the information in the related footnote are not consistent, then the article text should be changed so the text and the information in the related footnote are consistent. Then there won't be any confusion at all.  -- John Broughton  (♫♫) 01:15, 29 March 2009 (UTC)

In theory. But consider a current problem, from the "Mode of Action" paragraph in the AZT article. At this writing a sentence is in dispute:

"However, AZT has a 100-fold greater affinity for the HIV reverse transcriptase than for the human DNA polymerase alpha, accounting for its selective antiviral activity."

That sentence currently has two supporting footnotes. Both refer to in vitro experiments only. However, only one experiment has in vitro in its title. To ensure that no one assumed an in vivo affinity I changed the sentence to:

"However, in vitro AZT has . . . "

That single 2-word phrase has led to an edit war. With standardized footnote-tags, this kind of dispute could be avoided, as casual readers would immediately see that both footnotes refer to in vitro experiments and could then draw their own conclusions. Basically this suggestion is an attempt to make inferences drawn from references editor-proof.


 * If there's an edit war over having this in the text, surely there'd be an edit war over using <ref name="foo" type="invitro"> for the reference tags? If it's just a matter of people not wanting to clutter the text, then there's no reason we can't note in the footnote that it's in vitro (or whatever) - "In vitro results; [citation]" - in much the same way as we add other explanatory notes to footnotes when something isn't clear. Shimgray | talk | 21:15, 2 April 2009 (UTC)

I think it would be much harder to edit-war over what is essentially a binary distinction: an experiment is likely to be either one classification or another. Experiments that encompassed multiple environments could be labeled with a hybrid tag. There would continue to be arguments over whether results could be assumed for another classification, but probably not over the experiment itself. (Odd thought: would future experimenters, if finding such tags inherently useful, incorporate them into the footnotes of their own references when their experiments are published?) Experiments that couldn't be classified with any of the tags would be conspicuous by the lack of a tag, and that might cause arguments in favor of creating tags for such situations. But that would be good, as it might bring to the fore aspects that if hidden could lead to wrong conclusions on the part of a casual reader. I agree that clutter shouldn't be a factor. What is informative in an efficient way can't be clutter. But clutter could result if the tags became too general. They should be specifically meaningful at a glance.


 * Just a bit of context: User:Eye.earth is seeking support for his or her attempts to insert information into Zidovudine implying that anti-HIV drugs for some reason do not work in vivo, a central belief of AIDS denialists that is not supported by reliable sources. How the above proposal would provide such support is unclear. In any case, the distinctions made by Eye are also unclear. For example, why in utero in addition to in vivo? Keepcalmandcarryon (talk) 23:20, 3 April 2009 (UTC)

Why in utero in addition to in vivo? Most studies would probably need only one as appropriate. But citing both classifications could be plausible for experiments of multiple parts with conclusions drawn separately therefrom, especially if those conclusions are referenced in text.

Readers interested in the dispute in question can see my Request for Comments at: http://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Maths,_science,_and_technology listed under Talk: Zidovudine. Eye.earth (talk) 02:48, 4 April 2009 (UTC)

Admin bit to set or clear article display in categories
I would like to suggest adding an extra bit to categories that admins can set to switch on or off the appearance of individual articles (rather than subcats). The category tree tends to get very messy as people often aren't sure which categories or subcats to put their articles in. If we had a bit that admins could set however, it should help the various wikiprojects to set which cats do or don't display articles, and by doing so bring a little more order into what is often a pretty chaotic part of the project. Gatoclass (talk) 05:55, 2 April 2009 (UTC)


 * I'm a little confused - is this set the category to not display articles for you-the-viewing-admin, so there's less clutter when you're working with them, or not display articles for anyone? The problem with this latter one would be that people probably won't notice they're miscategorised...
 * (In practice, this sounds relatively workable - something like the "don't display thumbnails" magicword - but I'm not sure of the practical benefits) Shimgray | talk | 21:00, 2 April 2009 (UTC)

Two letters code for musical instruments abbreviations
I have been discussing lately with some friends in a private form the need to indicate (and standardize) common abbreviations of popular musical instrument's names and we came at THIS research starting point. I am not a daily contributor of the wikipedia but I would appreciate your opinions on this matter. The idea is to add the gathered information to the basic info of each musical instrument. Do you find it appropriate?--Florenus (talk) 20:01, 2 April 2009 (UTC)

Is there a more specific discussion place inside the English wiki (for music matters I mean) for me to post and share opinions on this proposal? --Florenus (talk) 20:04, 2 April 2009 (UTC)


 * I applaud your work in this area, however Wikipedia is not a publisher of original thought: that is, we do not publish our own work, only the thoughts and opinions of other reliable sources. So while you have a good idea here to create a standard convention for instrument abreviations, it should come to wikipedia from an outside organisation such as the ISO, rather than the other way around.
 * You may find the people at WT:MUSIC or WT:MUSINST interested in the idea, however. My immediate reaction is to say that, while a very good idea, 676 unique codes is very unlikely to be enough to describe all the world's instruments; you probably need three letters if not four. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 20:19, 2 April 2009 (UTC)
 * As I am trying to explain this is not my own work. I report here a part of the discussion with User_talk:RHaworth: For us common abbreviations of musical instruments are part of the Wikipedia content. Language is not a personal opinion.--Florenus (talk) 19:29, 2 April 2009 (UTC)
 * Who are "us"? But the operative word is "common". Give me an example of a two-letter abbreviation which is in common use. &mdash; RHaworth (Talk | contribs) 19:34, 2 April 2009 (UTC)


 * The practice is quite typical in artists curriculums or concert programs. Just one: http://www.massimilianomotterle.com/repertoire.htm See "Chamber Music", (in Italian "cameristico", http://www.massimilianomotterle.com/repertorio1.htm): "L. Van Beethoven: Quintetto per pf., cl., fag., ob., cr. in Mi bemolle Maggiore op. 16".  But I can show you many. The abbreviations are common in this kind of language. It is right that the wikipedia shows the meaning of the word "op." : http://en.wikipedia.org/wiki/Abbreviation#Plural_forms so, as a reader, I would find logical also to find the meaning of the abbreviations pf., cl., ob., cr., etc..--Florenus (talk) 07:48, 3 April 2009 (UTC)

--Florenus (talk) 07:57, 3 April 2009 (UTC)
 * If there is some reliable source showing standard use of a particular two-letter abbreviation for an instrument, that should be mentioned in the article on that instrument, and on the disambig page for the two-letter combo. As far as defining these in individual entries, that belongs in Wiktionary. bd2412  T 18:13, 3 April 2009 (UTC)

Closure of English Wikipedia
Please post your thoughts here. Thanks,  Majorly  talk  14:09, 1 April 2009 (UTC) Are you serious, or this a belated April Fool's Day joke? I say belated, because I note that the time of this edit was 14: 09, which according to an old tradition, is too late to play April Fool's Day jokes. April Fool's Day only lasts until noon; otherwise, you will risk being greeted with these words:

April Fool's Day passed and gone

You're the fool, for carrying on.

By the way, if this was a serious proposal, and the English Wikipedia were to be closed, bear in mind that it would only get recycled on a website such as Includipedia or AntiWikipedia or at least somewhere on the web. ACEOREVIVED (talk) 19:32, 2 April 2009 (UTC) Well, I suggest that as from today, any one concerned about this should look at the tag which now heads the page! ACEOREVIVED (talk) 18:46, 5 April 2009 (UTC)

Reviewer usergroup
As we're progressing towards an implementation of flagged protection and patrolled revisions, it becomes necessary to decide the requirements for the reviewer usergroup, in particular for autopromotion, please discuss at Reviewers. Cenarium (talk) 14:55, 4 April 2009 (UTC)

A tag for signalling a weak citation
In the Monomyth article, its 5th citation link says only "Northup, p. 8", and in Comparative mythology the 8th citation is identical. So I researched online and didn't come up with anything, it seems original research being claimed as fact.

To quote from the Monomyth entry: Although well-known in popular culture, the monomyth has fallen out of favor in academia, which currently leans away from comparative mythology (comparativism) and toward particularism.

To quote from the Comparative mythology entry: However, modern-day scholars lean more toward particularism, feeling suspicious of broad statements about myths.

I'd like to highlight the linked citation as weak or too insufficient. "Northup, p. 8" doesn't really help to verify and further research the source. boozerker 18:59, 6 April 2009 (UTC)
 * What research did you do? Have you checked the given reference, "Northup, Lesley. "Myth-Placed Priorities: Religion and the Study of Myth". Religious Studies Review 32.1(2006): 5-10"? Algebraist 19:18, 6 April 2009 (UTC)


 * Ah, further down. But shouldn't the source be listed in the numbered citation? Also, we can still use a tag for really bad citations. boozerker 19:23, 6 April 2009 (UTC)
 * It's one of the standard ways of presenting references (see WP:Citing sources). Not sure abount the mix of styles in a single article, though. Algebraist 19:28, 6 April 2009 (UTC)


 * You probably want one of these templates:
 * Verify credibility, flag a source as possibly being unreliable and/or unverifiable
 * Verify source, request that someone verify the cited source backs up the material in the passage
 * Failed verification, source was checked, and did not contain the cited material
 * Request quotation, request a direct quote from an inaccessible source, for verification purposes
 * --—— Gadget850 (Ed)  <sup style="color:darkblue;">talk  -  19:32, 6 April 2009 (UTC)
 * Thank you. If encountering a bad cite, should I put the tag next to the cite # in the article paragraph, or down at the bottom of page in the reference list? boozerker 20:58, 6 April 2009 (UTC)
 * Inline after the <ref ></ref> in the body. --—— Gadget850 (Ed)  <sup style="color:darkblue;">talk  -  21:01, 6 April 2009 (UTC)

AES
A proposal has been made at MediaWiki_talk:Revertpage, however, additional discussion is needed. -- IRP ☎ 22:14, 6 April 2009 (UTC)

at time zone to time stamp at bottom of articles "This page was last modified on [dd month year, at xx:xx]"
time stamp at bottom of article fails to provide time zone (current: "This page was last modified on 2 April 2009, at 08:02."). thus, a printed version read by non-wikipedian (and probably many wikipedia users) are clueless that times on wikipedia are in "UTC" (i think it is UTC; somewhere that information is buried within wikipedia; sometimes i stumble upon a usage, but i always have trouble finding it when i want it and i'm sure i'm not the only one).

of course ideally, all time entries (history, discussion, etc.) would indicate which time zone is used.--71.183.238.134 (talk) 08:33, 2 April 2009 (UTC)
 * This can't be done easily. MediaWiki:Lastmodifiedat could be edited to indicate UTC, but then it would be wrong for anyone who's said their time preferences to anything other than UTC. This might be one to bug the devs with. Algebraist 11:53, 2 April 2009 (UTC)
 * If someone changes their Date/Time preference, the time at the bottom reflects that. -- lucasbfr  talk 15:04, 7 April 2009 (UTC)

Wikipedia and the Internet
I'm not a fan of exceptions, and I love rules. But far too many people on Wikipedia make it their mission to try to remove as many "deficient" articles rather than spend their time creating new ones. Far too many people feel some sort of thrill from having someone's hard work be deleted by slapping them with some rule or criteria. We have too many wiki-cops and too little wiki-artists.

We can say youtube is a site to post videos and Google is a search site. And we can say Wiki is an encyclopedia. But we all know these three are the big e-triumvirate that have grown far past what they were meant to be, to the point that google and wiki have become verbs (even youtube now, "go home and youtube it".

And as much as we have rules for notability, such as having more sources other than let's say Youtube itself. Wiki has to realize that Youtube is a category in itself. Having 17,000,000 views mean at least let's say 50,000 people a year at LEAST (or if you want to be conservative 5,000) will see some reference to Happyslip somewhere online/or hear about it(such as I did), and want to find out more about it. Knowing that even 1,000 people want a reference to it, should be enough. Youtube works more through word of mouth anyway, which is hard to document, who hasn't seen "Charlie Bit me"? I've been in drugstores and heard people talk about it, I've seen mothers put their finger in their children's and say, "ouch Tommy, Tommy bit me!". The beauty about Wiki is that it's not a cut and dry encyclopedia. It also documents e-life, e-phenomenons, and is basically an encyclopedia for us, the surfers. It's an edgier encyclopedia, and while we want to hone our accuracy and dependability, let's not forget that.

We also need to relax and realize that things can be notable now, or have BEEN notable. So for example, when a guy is lost at sea, and the media is buzzing about it. It's everywhere on the news for weeks, and someone adds it here. Three weeks later because the media died down about it does not make it less notable. What happens 5 years from now if the guy is found, and someone wants to see a reference to what they are talking about?

I realize this is not myspace, a forum, or a blog, but I believe there can be a peaceful coexistence between the serious academic and purely entertaining notability. When an article such as the "numa numa" guy faces problems it scares me! As long as an article is unbiased, neat, organized, and facts properly sourced, why work so hard towards deleting it?

I wonder if we could have some sort of view counter on pages, it would certainly help to see just how many people are accessing a page. (I'm hoping at least that would help show how notable something is)

This is just a friendly reminder for us to all take a big breath and care a little less about what grade an article would get. While an A article is beautiful, so is knowing you wrote down a little piece of history.

I sorely apologize if this sounds a bit like ranting. It's not, it's an honest effort to get people to stop a moment and readdress what we want to be, and how to get there. Wiki has matured into something more than just an encyclopedia, and that's a good thing. Pointing to a "WP:whatever" should not be the end of any discussion nor should it be unmalleable. I apologize in advance for my English and I appreciate any feedback. 75.69.233.90 (talk) 22:49, 3 April 2009 (UTC)


 * It is possible to see how often a page has been viewed, by going to the history tab then clicking 'Page view statistics', although it is a bit hidden away. However, it can be difficult to use the number of page views to judge a subject's notability. For example, this page shows the most viewed articles in August 2008. In position 6 is Wiki, which I'm sure you'll agree is not the sixth most notable subject in existence. Looking through the list, there are plenty of pages there because their subjects are well known, or in the news at the time. It's necessary to use other methods of determining a subject's notability, apart from its number of views. Tra (Talk) 09:08, 4 April 2009 (UTC)


 * Wikipedia's size also means its effect on the real world is increased. Creating articles about barely notable or non notable people is a recipe for disaster with regard to false statements and libel. <font face="Broadway">Mr.Z-man 18:11, 4 April 2009 (UTC)

I hope you are correct about Wikipedia being big on the Web (I look at it often, but hardly every look at You Tube myself). What you seem to be concerned about here is that Wikipedia has a number of users who identify themselves as "deletionists" and also that to judge a topic as "notable" is not an all-or-none matter. I agree with you that Wikipedia has now grown beyond something similar to a standard printed encyclopaedia - although we are not Wikinews, the coverage of up-to-date media topics does help it to bridge the gap between newspapers and encyclopaedias. To console you about deletionists, can I point out that there are Websites out there such as Includipedia or Antiwikipedia which seem to exist to recycle deleted Wikipedia articles. However, I am inclined to agree that one must use other methods to determine an article's notability than the number of times it has been viewed - a subject in the news might have had many hits, whereas some obscure topic which is known to be important to experts in the field might have few hits, but still be judged important by experts. Also, I already think Wikipedia has balanced the "seriously academic" and the "purely entertaining" well, as it is well-known that there are many articles on popular media culture in Wikipedia.

These are my own personal reactions to the above comment, and do not necessarily represent the views of the Wikipedia community as a whole. ACEOREVIVED (talk) 18:59, 5 April 2009 (UTC)


 * Three weeks later because the media died down about it does not make it less notable. What happens 5 years from now if the guy is found? Our approach to notability is that if a subject is notable now, it automatically stays notable in the future. Or, if you will, we don't delete articles because very few people are interested in a topic, or very few people are reading that particular article; we look at sources to determine whether the subject of the article ever was notable. So, in your hypothetical case, in five years the article will still be in Wikipedia.


 * Looking at the various links in Article Rescue Squadron should make it clear that the issue of excessive deletions have been discussed before. Do keep in mind that much, quite possibly the vast majority of articles that are deleted are pure drek (and are deleted via CSD); only a small fraction of articles are deleted via discussion (AfD). -- John Broughton  (♫♫) 01:39, 6 April 2009 (UTC)


 * Articles created by true 'wikiartists' as you call them, 75.69.233.90, are unlikely to be affected because those are rarely deficient in anything. The easiest way to solve this, is simply not to rush article creation. I've already had at least one great example in my own creation log. When I first wanted to create Louis Barnett (chocolatier), only a handful of references were available. By being patient and waiting for a couple of months I ensured that the resulting article I wrote was of sufficient quality. - Mgm|(talk) 08:26, 6 April 2009 (UTC)


 * Some experience patrolling new pages would likely change your point of view. You say "as long as an article is unbiased, neat, organized, and facts properly sourced, why work so hard towards deleting it?". We don't work so hard towards deleting those, we work so hard towards deleting all the other ones, those that do not, will not be unbiased, neat, organized and properly sourced often precisely because the notability of the subject is nil. Obscure bios or pages on high school bands or unknown rappers created out of vanity, hoaxes, nonsense, essays and original research on a variety of subjects, fancruft, POV forks, advertisement ... a ton of articles are created every day that do not and cannot meet the standards set by the community. The AfD process which I believe you are thinking of, is just the tree before the forest, most articles that are deleted do not reach AfD, they are quietly swept away by new page patrollers and admins, "speedy deleted" or more slowly (WP:PROD). Few reach AfD not because "wiki-cops" are nasty people hell bent on disposing of someone's work while nobody's looking, but because they are so below the standards set by the community that it would waste everyone's time and require more "wiki-cops" and "wiki-lawyers" if they did. Now some deletions are contentious, *some*, that's why the AfD process exists, that's were the community deals with borderline cases or at least disputed ones. We *need* standards, or Wikipedia wouldn't be anything like an encyclopedia, and we *need* what you call "wiki-cops" otherwise standards are of no use. There are standards you might not agree with, for instance you might think short lived internet buzz establishes notability, many however do feel that it's a playground for original research and unverifiable assertions. If it takes an AfD nomination to find out if a given article meets standards, then so be it, it's not a punishment, it's not a bad grade, it's just a useful process. Equendil Talk 12:42, 7 April 2009 (UTC)

changing text of edit summary field
Recently on wikien-l Erik Moeller mentioned that on de.wp they have changed the text of their edit summary field to read "Summary and Sources" instead of "edit summary." Apparently lots more new editors started including URLs etc. What do people think of trying this out on en:, as well? Could be an easy way to up sourcing. -- phoebe / (talk to me) 21:37, 4 April 2009 (UTC)


 * Support - David Gerard (talk) 21:41, 4 April 2009 (UTC)
 * Wouldn't this make people put their sources in the edit summary box instead of putting them in the article? It would be a bit confusing to tell editors that their sources should go in the edit summary box, when they really need to show up at the bottom of the article. Tra (Talk) 21:54, 4 April 2009 (UTC)
 * yes, it could lead to that, but I think the point is that it's easier for an experienced editor to pull a source from the edit summary and add it in the right place than it is to find a new source from scratch. Also, it reminds new editors that they have to have sources. Footnote syntax and refsections are confusing enough that people often skip it altogether. There might be better phrasing than "summary and sources" possible. -- phoebe / (talk to me) 22:13, 4 April 2009 (UTC)
 * It would be a lot of work to have to keep going after each edit that puts the source in the edit summary box. I think it would only be worth it if it caused a substantial increase in sourcing. It might be useful to look at the German Wikipedia and take a random sample of edits before and after the change. You could then classify them into vandalism, edits not requiring sources, edits which need a source but don't have one, edits with the source placed on the article and edits with the source placed in the edit summary. The number of edits of each type could then be compared between before and after the change. Tra (Talk) 09:30, 5 April 2009 (UTC)


 * A better solution in my opinion would be to add a note on citing sources at MediaWiki:Copyrightwarning or MediaWiki:Edittools, it would also allow to link Citing sources. Some recent discussion on this here. Cenarium (talk) 23:09, 4 April 2009 (UTC)
 * And we could also implement an editnotice for blps, Template:BLP editintro, but there's still the unresolved issue to hide them. Cenarium (talk) 00:13, 5 April 2009 (UTC)
 * I'd prefer the notice the French Wikipedia uses between the edit box and edit summary, but failing that, this is a great idea, assuming that it increases people posting sources. We can make bots and scripts to pull sources from an edit history making the job of putting them in a mere technicality. We should also pay more attention to avoid supposed experienced editors from including bad sources taken from edit summaries. - Mgm|(talk) 13:49, 5 April 2009 (UTC)


 * Tend to Oppose because Edit Summaries already have to bear a huge burden in a relatively cramped space, chiefly both what you did and why. Besides your motive, "why" also often includes external reasons that justify your edit (such as policy or a source). At the moment, most edit summaries don't meet (at least formally speaking) both the what and the why, often with unfortunate results, such as abbreviations that are incomprehensible to most ordinary editors, or necessarily-terse reasons that look peremptory, arrogant, hostile or just plain rude. There's also overcompression that hides (often unintentionally) something with which not all other editors might agree, such as "RVV" or "cleanup", tell-tale terms that many of us have learned to view with skepticism when posted by an unfamiliar editor. ¶ However, I'm not opposed to the idea of encouraging editors to give some indication of the source or policy (even though I'm a rank libertine and anarchist who thinks the Manual of Style should be far more permissive and about 5-10% its present monstrous size), so long as sources are also properly posted in the footnotes. Would greatly expanding the size of an edit-summary box, or adding a second one for sources help? —— Shakescene (talk) 07:03, 6 April 2009 (UTC)
 * Strongest possible oppose - makes things very confusing, will obviously reduce in-article citations (which are extremely useful), and generally makes it harder to check if things are original-research or not, for example. Also makes us vulnerable to spam/attack page URLs, as summaries can presumably not be edited by admins. ╟─ Treasury Tag ► contribs ─╢ 07:19, 6 April 2009 (UTC)
 * Oppose, unnecessary. – xeno  ( talk ) 19:02, 6 April 2009 (UTC)
 * Oppose, providing sources is not what the edit summary is for. Equendil Talk 12:50, 7 April 2009 (UTC)
 * I oppose this proposal on the grounds that it effectively asks people to put their sources in the edit summary box, which is not where the sources should be—that description would be misleading. Moving sources from the edit summaries to the article could constitute a significant amount of unnecessary work. If we had an "auto-append ref with contents of box X to addition" feature, however, that'd be a different issue { { Nihiltres | talk | log } } 15:15, 7 April 2009 (UTC)
 * Support something needs to be done to stop unverified claims going into articles. People saying it's not what the box is for well the keyword is OR. Pragmatically, there is evidence from the german Wikipedia that sourcing is on the increase. As an aside, I'm sure someone could develop some sort of script or bot to apply the sources from the summary retrospectively. --DFS454 (talk) 16:01, 7 April 2009 (UTC)

Watchlist tweak.
Often when browsing my watchlist, I find something completely unrelated to my interests. It would be nice to be able to remove articles directly from Special:Watchlist, either through an (diff; hist; unwatch) link or through a checkbox. Headbomb {{{sup|ταλκ}}<sub style="margin-left:-4.0ex;">κοντριβς – WP Physics} 08:11, 6 April 2009 (UTC)
 * There are several scripts for this at WP:JS. Algebraist 09:05, 6 April 2009 (UTC)
 * WP:POPUPS works well for this. – xeno  ( talk ) 19:02, 6 April 2009 (UTC)
 * See user:js/watchlist for an easy solution: just install on your monobook.js page as instructed. Gwinva (talk) 09:42, 7 April 2009 (UTC)

Redirect Category:uncategorised to Category:uncategorised pages
The former is a historical category with no pages. I propose a redirect to the proper page. --DFS454 (talk) 18:59, 6 April 2009 (UTC)
 * WP:CfD is the place for this I think. OrangeDog (talk • edits) 23:19, 7 April 2009 (UTC)

Extending Biographies_of_Living_Persons
Can I please suggest that WP: Biographies_of_Living_Persons policy be extended to include the recently deparated, as well as those still living? Recently, I found out (incidentally, from Wikipedia) that the Japanese theologian Kosuke Koyama had died on March 25, 2009, and put up the "recent death" tag on his page. As this is now more than a week ago, this tag was removed as from today (April 4, 2009). However, looking at the talk page, I see that this page still has the bit about biographies of living people having policies that need to be adhered to, and I did not remove this for this reason. I have wondered whether we should not merely have a policy to protect privacy of living individuals, but also those who, for example, have died in the past five years.After all, there are privacy laws which do exist, I believe,for 40 years (correct me if I am wrong). If a person has died and is therefore technically not a case for Biographies_of_Living_Persons, that person could still have (and in many cases, would have) relatives who are still living, so we must be extremely cautious about avoiding contentious statements that could be offensive to relatives of a recently deceased individual. I shall be interested to see whether Wikipedia is going to extend this policy.ACEOREVIVED (talk) 21:29, 4 April 2009 (UTC)


 * Disagree - BLP is a very restricted policy for a very specific purpose: that eventualism is not workable for BLPs for very specific reasons. The case of the relatives must also be specific to material about them; because they may not like an article is not the species of harm caused by a bad BLP, not even close. BLP carries enough practical risk of NPOV violations; its scope must be kept very restricted indeed for this reason - David Gerard (talk) 21:43, 4 April 2009 (UTC)
 * Disagree. While courtesy suggests we wait a decent interval before adding anything that might offend the survivors, we should not enshrine courtesy a requirement in BLP the policy. I agree with David Gerard that the scope of BLP should be strictly limited to living people.   Will Beback    talk    21:54, 4 April 2009 (UTC)
 * The policy did formerly extend to "recently deceased" people, but that seems to no longer be true. In any case, Biographies_of_Living_Persons appears to cover that aspect well enough. — Gavia immer (talk) 04:11, 5 April 2009 (UTC)
 * Support The key point is proper referencing and solid editorial control. Just because a person died and can't sue us, doesn't mean it's a good idea to have unreferenced contentious/controversial material in their article. By not including dead people in an overall People policy, editors tend to ignore the fact that all material should be cited and that contentious material is no different. - Mgm|(talk) 12:52, 9 April 2009 (UTC)

Hide footnotes for printing
Hi,

I would really appreciate if you could include a function so that you can hide the footnotes in the printable version. It would save me la lot printing paper, and it could be an optional setting, sothat the ones who want the footnotes can keep them. Furthermore you could also include an option to hide the Reference out of the printable version.

Sincerely yours, pascal —Preceding unsigned comment added by 87.66.148.198 (talk • contribs)

--—— Gadget850 (Ed)  <sup style="color:darkblue;">talk  -  17:03, 7 April 2009 (UTC)
 * Create an account
 * Edit Special:MyPage/monobook.css
 * Add:
 * Follow the instructions at the top of monobook.css to bypass your cache


 * Excellent suggestion pascal. Gadget850, It might be really helpful to include a button that does the same, for printing. Lots of news sites and web pages have the option to get a clean print. If the option must be hunted for, people aren't likely to know it's there.
 * Here's the first example using a New York Times article on Wikipedia.
 * 
 * The print button there is highly visible and gives us this next page.
 * 
 * Any thoughts? boozerker 18:32, 7 April 2009 (UTC)
 * Not only do we have a link in the sidebar to the printable version, any decent browser will default to the printable version if you try to print anyway. Footnotes are an integral part of the article, so I don't think they should be left out of the printable version by default. Algebraist 19:02, 7 April 2009 (UTC)


 * Print styles are automatically applied unless your browser does not support CSS; for those, we have the "printable version" link on the left sidebar. See Help:Printable for more info (I have been rewriting this help page). We don't print elements such as section edit links, navboxes, article message boxes and more. Printing references should be a matter of personal choice; I don't think this should be non-printable by default. --—— Gadget850 (Ed)  <sup style="color:darkblue;">talk  -  19:09, 7 April 2009 (UTC)

Let me try this again. The previous rule will neither display nor print the references. To display but not print, use this rule: --Gadget850 (talk) 19:48, 8 April 2009 (UTC)

Repurpose of Template:Picture of the day
I recently came across this template, as it was tagged on a file in the Special:UncategorizedFiles. While it being picture of the day is worthwhile and all, I don't think this template should be transcluded on the front of images. Like featured article and good article milestones that are accomplished on Wikipedia, I think this template would be best repurposed to the talk page of the image, instead of the actual image itself. Doing this would stop the false leads into finding uncategorized files (since most featured images are on the commons, a lot of uncategorized images tend to be wikipedia file pages with nothing but the potd template on it). — <font color="DD0000">Moe <font color="0000FF">ε  22:27, 8 April 2009 (UTC)
 * Nobody reads image talk pages. Anyway, anything with a POTD tag on it should also have a FeaturedPicture or a FormerFeaturedPicture on it, which would resolve the problem of being uncategorized. MER-C 08:28, 9 April 2009 (UTC)

RFC: Notability of free open source software
Wikipedia is currently missing a standard of notability for free open source software. I wrote a proposal at Wikipedia:Notability/RFC:Notability of free open source software and would welcome your comments. Thank you, Dandv (talk) 04:45, 10 April 2009 (UTC).

Referencing stats
Not really a proposal, other than we should have better stats regarding quality control. Anyways, at User_talk:Peregrine_Fisher one of the nice bot operators has come up with some stats about referencing efforts. Check it out. - Peregrine Fisher (talk) (contribs) 04:54, 10 April 2009 (UTC)

'Confirmed' usergroup
We had some discussions on the ability to grant or remove 'autoconfirmed' status, for example here, but it wasn't conclusive. So I propose to create a usergroup <tt>confirmed</tt>, with an autopromotion identical to the autoconfirmed requirements. I think it's feasible since the 'editor' usergroup in the extension FlaggedRevs has an autopromotion. So it could be granted and removed by administrators, and would be automatically granted by the software when the user meets the 'autoconfirmed' requirements. Cenarium (talk) 17:56, 25 March 2009 (UTC)
 * Currently the autopromotion system used by FlaggedRevs is different from the one used in the core software. There's a somewhat hacky way to do it with the current core version (create a "non-autoconfirmed" group and require that users not be in it to be autopromoted). <font face="Broadway">Mr.Z-man 18:10, 25 March 2009 (UTC)
 * So we'd need an extension, such as FlaggedRevs, to make it non-hacky ? Cenarium (talk)
 * Or the FlaggedRevs autopromotion system would have to be moved to core. <font face="Broadway">Mr.Z-man 18:17, 25 March 2009 (UTC)
 * Thanks, if there's consensus for this, we'll open a bug then. Cenarium (talk) 18:33, 25 March 2009 (UTC)
 * We may have other groups with autopromotion in the future, so it would be worth to have an autopromotion system available in the core I think. Cenarium (talk) 10:32, 26 March 2009 (UTC)
 * This new user group is supposed to have <tt>'autoreview'</tt> right? Ruslik (talk) 20:05, 25 March 2009 (UTC)
 * In the flaggedrevs proposal yes, like autoconfirmed, but this can be done independently. Cenarium (talk) 10:32, 26 March 2009 (UTC)
 * It can be instead of autocomnfirmed. Ruslik (talk) 11:01, 26 March 2009 (UTC)
 * Autoconfirmed would be deprecated. It would probably require much rewrite. Cenarium (talk) 12:28, 26 March 2009 (UTC)

The usergroup 'uploaders' could also be deprecated as superseded by 'confirmed'. Possible uses could be:
 * granting: when needed, a new user known to be trustworthy (for example, from other projects, or a wmf account), a bot account (for a trial, etc), restoring the confirmed status when previously removed
 * removing: vandalism, in particular on semi-protected pages, when the vandalism is insufficient for a block (confirmed users are able to perform actions like move, edit semi-protected, and are cleared from certain abuse filters, so the potential damage would be much weaker if the permission is removed) Cenarium (talk) 13:12, 27 March 2009 (UTC)

Poll on (auto)confirmed usergroup
This is a poll/discussion to see if there is support to deprecate the 'autoconfirmed' implicit usergroup and replace it with a usergroup 'confirmed' that is granted automatically to users passing the 'autoconfirmed' requirements and can also be granted and removed by admins. So said otherwise, do you support or oppose a modification of the 'autoconfirmed' permission so that it can also be granted and removed by admins ? Cenarium (talk) 18:14, 27 March 2009 (UTC)
 * Oppose - it makes life very complicated, and would require complex structures and policies to be built up (when is it appropriate to add/remove confirmed status? for how long?), and adds little helpful utility. However, I support a system where Abusefilter-editors can re-add the autoconfirmed status of users who have been "wrongly" demoted, if there is not already such a mechanism (not quite clear from the proposal). ╟─ Treasury Tag ► contribs ─╢ 18:22, 27 March 2009 (UTC)
 * This feature does exist. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 18:34, 27 March 2009 (UTC)
 * It shouldn't require complex policies, it didn't require complex policies for removing rollback, or adding it, and it's much easier here. We have a problem when an autoconfirmed user vandalizes and remains unblocked, or is blocked temporarily, because the vandalism activity is not sufficient. Autoconfirmed users are immune to many vandalism-related tools, for example some abuse filters, because it is assumed that an autoconfirmed user has been around enough so that they aren't a vandal - or they would have been blocked. A criteria for removing autoconfirmed should be simple: vandalism. Being able to grant autoconfirmed rights prematurely would be helpful for bots, and good-faith new users needing the rights. Cenarium (talk) 20:53, 28 March 2009 (UTC)
 * Support in principle, but a change to this effect should be enacted by making <tt>'autoconfirmed'</tt> an explicit group in MediaWiki. Essentially the same effect, but with less fuss.  I have complete faith in our ability to cope with the not very complicated at all structures that would be needed. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 18:34, 27 March 2009 (UTC)
 * Oppose the proposal as stated. Just make "Autoconfirmed" removable, and don't automatically readd it if it's been removed. Nothing else is needed. — Gavia immer (talk) 18:45, 27 March 2009 (UTC)
 * Ironically, this is essentially what I'm suggesting in my post, with completely the opposite caption :D <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 18:54, 27 March 2009 (UTC)
 * Yes it is. It's purely a matter of semantics - but I preferred to confound the polling thing a bit. — Gavia immer (talk) 19:22, 27 March 2009 (UTC)
 * We couldn't grant it prematurely then, for bots, etc. According to this, the group is not automatically restored by autopromotion when it has been removed, the status log is checked for removals. Cenarium (talk) 19:32, 27 March 2009 (UTC)

I agree with. <font color="#CC7722" face="Papyrus">♪Tempo <font color="#00008B" face="Papyrus">di <font color="green" face="papyrus">Valse ♪  21:10, 28 March 2009 (UTC)
 * Support the idea of allowing the right to be added or removed. I think that autoconfirmed/confirmed (I don't mind about the name) should be really easy to obtain. Any account that's x days old with y edits gets it automatically, anyone who requests the right should get it immediately (unless their account has been blatantly vandalising). Also, I think this right should be given out to anyone who might need it. What I mean is anyone who posts a question about how to move pages, upload files or edit semiprotected pages should receive the right immediately. I'm not entirely sure about when the right should be removed manually. There probably are some good situations for this, but I would imagine it would be a fairly rare occurrence. Tra (Talk) 19:29, 27 March 2009 (UTC)
 * Oppose, agree with, above. Cirt (talk) 18:40, 28 March 2009 (UTC)
 * Oppose Too complicated. Would be better to simply make the user group removable. <font color="#CC7722" face="Papyrus">♪Tempo <font color="#00008B" face="Papyrus">di <font color="green" face="papyrus">Valse ♪  20:58, 28 March 2009 (UTC)
 * So you mean it should be removable, but not grantable prematurely ? Cenarium (talk) 21:06, 28 March 2009 (UTC)
 * Ehh... then again, it would probably be best just to leave things as they are. Too complicated otherwise, really. <font color="#CC7722" face="Papyrus">♪Tempo <font color="#00008B" face="Papyrus">di <font color="green" face="papyrus">Valse ♪  21:12, 28 March 2009 (UTC)


 * It can already be re-added if a filter wrongly removes it, but for particularly cumbersome vandals, it would be nice if the ability to remove the group was granted to admins as well. - Mgm|(talk) 10:04, 29 March 2009 (UTC)

I have modified the structure of the poll to make it clearer, move your comment if you wish. Cenarium (talk) 21:18, 28 March 2009 (UTC)

In addition to be granted automatically to users after 10 edits and 4 days, do you support to make the usergroup (auto)confirmed :
 * 1) Oppose - I don't think this one actually helps. The aim of (auto)confirm is to ensure some actions can't be done except by users with a modicum of experience or involvement (ie repeat editors). A problem user will just do their 10 edits, then ask for autoconfirm, then vandalize anyway, wasting other users' time. Meanwhile bona fide users will add considerable admin workload that isn't needed, and a user who abuses autoconfirm access is probably a candidate for a block or ban anyway. Open to differing views or reasons why this is poor logic, but for now, no good rationale seems to exist for change. FT2 (Talk 14:43, 3 April 2009 (UTC)
 * Users will still be autopromoted after 10 edits and 4 days. I gave examples of users vandalizing who would not have been indef-blocakable at the time below. Cenarium (talk) 20:00, 3 April 2009 (UTC)

Removable and grantable prematurely

 * 1) Thought it over, and decided that it seems to be a good idea. I misunderstood the proposal at first, and thought that the autoconfirmed group would no longer be given out automatically. <font color="#CC7722" face="Papyrus">♪Tempo  <font color="#00008B" face="Papyrus">di <font color="green" face="papyrus">Valse ♪  21:26, 28 March 2009 (UTC)
 * 2) Certainly - I cam across this due to some minor vandal who IMO does not warrant blocking but needs watching. putting him back into the new users pack would accomplish that. OTOH valid sockpuppets or established users on other wikis could be promoted to be useful right away. Agathoclea (talk) 09:59, 29 March 2009 (UTC)
 * 3) Pretty much what Agothoclea said.--Aervanath (talk) 07:34, 1 April 2009 (UTC)
 * 4) Fine. flSiet (aklt) 09:54, 1 April 2009 (UTC)
 * 5) Support, New users sometimes point out mistakes in semi-protected articles on the article's talkpage. It would be useful to let them correct the mistakes they point out. Tim Vickers (talk) 23:05, 1 April 2009 (UTC)
 * 6) Support. There will be some occasions to use it in a positive sense; and there will certainly be occasions to use it to remove autoconfirmed, especially for SPAs with the minimum number. A good first step before seeing if we need to raise the autoconfirmed numbers.DGG (talk) 04:03, 3 April 2009 (UTC)
 * 7) Support. Per Agathoclea, some people who are disruptive (but perhaps not blockable) should not be able to edit semi-protected articles and if they manage to pass thethreshold should not ruin it for everyone else and cause a page to have to be fully protected. They would also appear on the newbies contribs list. On the other side, some well-established people with valid reasons may create a new account or a legal sock for testing purposes. In this case I think premature auto-confirm is merited and the bit should be in the hands of admins. <b style="background:blue; color:white; font-family:Comic Sans MS;">Valley</b>2 city ‽ 20:17, 5 April 2009 (UTC)
 * 8) Support. Per Agathoclea. -- Alexf(talk) 17:14, 7 April 2009 (UTC)
 * 9) Support with obvious comment As with all admin tools, abuse of such priveleges should be dealt with in the same way as other admin abuse. An obvious statement but one that needs making anyway. Sedd&sigma;n talk 19:11, 7 April 2009 (UTC)
 * 10) Support I support as someone may wish to retire one username and form an entirely new one (tho retain their public identity). If they are trusted then it would make sense to be able to remove the normal limits on a new user account. At the same time I also feel that this can be useful on a case-by-case basis. Basket of Puppies  19:37, 7 April 2009 (UTC)
 * 11) Good proposal Alex Bakharev (talk) 03:02, 8 April 2009 (UTC)
 * 12) support Reasoning above is good. I can't see much reason for allowing premature granting but I can imagine some circumstances that would probably be ok (i.e. you know someone is a productive user from another wikimedia project). The minor nature of this usergroup means that we really won't need any policy for it for now except more or less common sense. JoshuaZ (talk) 05:28, 8 April 2009 (UTC)
 * 13) Support This feature would be a net positive for the project, as it will produce more help than harm. <font face="times new roman"> hmwith τ   16:49, 8 April 2009 (UTC)

Removable (and not grantable prematurely)

 * 1) This is definitely where I fall; I can find no valid reason to autoconfirm a user before 10 edits, but I love the other part as an early-step anti-vandal tool--CastAStone//₵₳$↑₳₴₮ʘ№€ 18:24, 7 April 2009 (UTC)
 * What if a trusted user comes from a very trusted position in other projects & we're sure they'll be trustworthy here? <font face="times new roman"> hmwith τ   16:51, 8 April 2009 (UTC)
 * LOL at saying "trust" three times. It wasn't intentional. <font face="times new roman"> hmwith τ   16:52, 8 April 2009 (UTC)
 * Then they can make ten AfD contributions. Or mod their user page ten times. Or spend 5 minutes looking at and reverting recent changes. Ten edits can be done in 5 minutes easily if you try, and these people will aldeady know how to do it.--CastAStone//₵₳$↑₳₴₮ʘ№€ 16:21, 10 April 2009 (UTC)
 * We could use this for new bots in trial period, for example. Cenarium (talk) 17:37, 8 April 2009 (UTC)

None (no change)

 * 1) The criteria are really too trivial to warrant special treatment. I know there may be arguments in favor of granting instant "autoconfirmed" status to new accounts which are known to be returning "trusted" users, but would saving four days really be worth blowing their cover? I know I'd rather just wait. Also I cannot envision any circumstance where it would it be better to "remove autoconfirmed" status than to simply block the account. Could someone please provide an example of when they would do this? I will say if the numbers were higher, maybe in the order of 40 days and a few hundred edits, granting exceptions both ways would be worth considering, but right now it would be too useless to bother with. — CharlotteWebb 11:50, 29 March 2009 (UTC)
 * Since the autoconfirmed status allows to bypass many protections against vandalism, not only semi-protection, but some abuse filters and other anti-vandalism tools (and they would also have some additional permissions in the flagged protection implementation), having an autoconfirmed user vandalizing around is very unfortunate and they're not always blocked, for examples, see the history of vandalized semi-protected articles, such as Obama: 1, 2, 3, 4. Those have vandalized but have not been blocked indef, or not immediately, and two of them have been able to cause vandalism when their block expired. Cenarium (talk) 14:39, 29 March 2009 (UTC)
 * 1) Auto-confirming lets users move a page and a page to their watchlist. Watchlist doesn't matter, and moving a page can be undone easily. That's why we also have blocking and move protection. Nothing more is needed. <font color="#3E4F51">Jd <font color="#000FFF">027  (talk) 23:25, 2 April 2009 (UTC)
 * Any user can watchlist a page. Autoconfirmed allows to edit semi-protected pages, and bypass certain anti-vandalism tools among others. It's simply proposed to allow to grant the autoconfirmed permission before the 10 edits/4 days, and make it removable. Cenarium (talk) 20:00, 3 April 2009 (UTC)
 * 1) I don't think this is such a good idea to make the autoconfirmed group more than it is now (I see some discussion on removing the right for SPAs). It shouldn't be more than "the account is old enough to edit this page". The user rights are complicated enough. -- lucasbfr  talk 14:58, 7 April 2009 (UTC)
 * 2) I don't see a pressing need. This seems to be another solution in search of a problem. - Rjd0060 (talk) 16:05, 7 April 2009 (UTC)
 * Which problem ? Cenarium (talk) 14:58, 8 April 2009 (UTC)
 * 1) I can possibly see a few use cases for granting it early, but I don't really see any use for removing it. Pretty much any case where it should be removed, it would probably make just as much sense to block the user. <font face="Broadway">Mr.Z-man 16:27, 7 April 2009 (UTC)
 * I gave examples above of users that would have not been indef-blockable. Some have been temp-blocked and vandalized just after that. Cenarium (talk) 14:57, 8 April 2009 (UTC)
 * Apa aff os and labz were clearly vandalism only accounts and should have been blocked indefinitely, and one of them was. The other 2 I probably would have blocked indef as well. <font face="Broadway">Mr.Z-man 20:52, 8 April 2009 (UTC)
 * 1) I agree with Mr.Z-man, usually those who would be candidates for having their autoconfirmed status revoked are usually vandalism only accounts and are quickly blocked. -Senseless!... says you, says me 02:21, 8 April 2009 (UTC)
 * Precisely, it's not always the case (examples above, more can be found). Cenarium (talk) 15:01, 8 April 2009 (UTC)
 * I disagree, either the user should be blocked (indef or not), or just warned (and then no action ought to be taken). Having this extra option is just one more headache to me. Granting it early could be a plus (but having the user wait for 4 days before operating on semiprotected pages is not that big a burden, seriously :)). -- lucasbfr  talk 16:05, 8 April 2009 (UTC)
 * The problem is, after a temp block, the user can resume vandalizing, and bypass anti-vandalism protections like semi-protection, abuse filters, and other anti-vandalism tools ignoring autoconfirmed users, this happened for those users: 1 and 2. [] is also used for vandalism detection, we could modify it so that it lists unconfirmed users (or make recentchanges filterable by confirmed users)(and thus granting a bot in trial period the confirmed group would also have the desirable effect to remove it from there). Cenarium (talk) 17:58, 8 April 2009 (UTC)
 * The problem is some admins being too soft on blatant vandalism. <font face="Broadway">Mr.Z-man 20:52, 8 April 2009 (UTC)

Wikidoc.org
The gentleman Michael Gibson who operates wikidoc is interested in combining wikidoc with wikipedia. I think that this would be a wonderful idea. They are under the same license as wikipedia but have tighter security with respect to vandalism. They are also written more for a medical audience. Not sure if it would be best to attach it as a sister project or combine much of the information into wikipedia ( as that is were much of the information comes from in the first place ). Anyone have any thoughts?-- Doc James (talk · contribs · email) 15:58, 7 April 2009 (UTC)


 * This is an issue you'd have to take to the Foundation, the users can't decide on their own. But I'm fairly sure you'll just get a "no"... ╟─ Treasury Tag ► contribs ─╢ 16:07, 7 April 2009 (UTC)


 * Not sure what kind of format the content would take. I'm fairly certain the Foundation would not host WikiDoc without some form of payment, given the extra traffic it would need to host. As far as combining content, what would the mechanism be for moving content back and forth? This sounds like a GFDL headache.


 * All this apart from the fact that WikiDoc was launched with much fanfare, largely built on Wikipedia's current medical content but without any consultation. JFW | T@lk  09:59, 8 April 2009 (UTC)


 * Maybe I was just out of luck, but for the 5 articles I checked, none came with sufficient sources. Merging the wikis together would only give us a whole bunch of extra unreferenced material. Not to mention we already cover much of the topics they have. - Mgm|(talk) 12:47, 9 April 2009 (UTC)


 * The one article I looked at, Local anesthetic, (yes, I know, inadequate sample) started out life as a Wikipedia article of around 8,000 characters, in October 2007, and (on WikiDoc) had reached 12,000 characters (after 15 edits) as of December 2008 (its last edit). Meanwhile, the Wikipedia article, after about 70 edits, had also reached about 12,000 characters in length. So it would be an interesting challenge to try to figure out what new material in WikiDoc was worth bringing across.  In any case, it makes absolutely no sense (to me) to have WikiDoc as a separate Wiki. -- John Broughton  (♫♫) 23:17, 9 April 2009 (UTC)


 * Well, it's up to the foundation, but I don't think it's a good idea either. WikiDoc is under GFDL, so all changes they have that we don't, we can incorporate into Wikipedia anyway.  So Why  23:27, 9 April 2009 (UTC)

I see this as mainly as a way to increase the number of editors of medicine article. It does sound like a nightmare to combine the two and would be easier to have it as a sister project. This would make the transfer of info back and forth easier. One could write for a medical audience. It would be like have we have simple English as a language. We could have medical English as a language aswell? Just ideas.-- Doc James (talk · contribs · email) 06:14, 10 April 2009 (UTC)


 * It's not at all clear that having that wiki be on a Wikimedia Foundation server would make transfer of information back and forth any easier. We already have a system where (using interwiki links) we can link to another wiki that isn't in a WMF domain.  And we can obviously cut-and-paste from WikiDoc, something that probably wouldn't be a good idea if WikiDoc really was aimed at a medical audience.


 * I suppose it would be easier, if WikiDoc was a WMF wiki, to ask editors of WikiDoc to do (more) editing at Wikipedia, but since WikiDoc seems be be based around visible "ownership" of articles ("editor-in-chief") whereas that is against the rules at Wikipedia, I suspect that very few editors would be willing to switch. And WikiDoc doesn't allow anonymous (IP editing), something that is a core Foundation principle.


 * Obviously editors at WikiDoc are aware of Wikipedia, plus they have MediaWiki editing skills, so if they want to edit here, why wouldn't they already be doing so? In short, the best way to add editors to Wikipedia - if that is the goal - is probably to shut down WikiDoc. -- John Broughton  (♫♫) 14:54, 10 April 2009 (UTC)


 * Wikidoc does not allow anons to edit which I think is great. Some of use get tired of all the vandalism and wish to know more about the editors which I think attacks people to wikidoc.  I do realize that this is a long shot and just put the idea out there.-- Doc James  (talk · contribs · email) 20:39, 10 April 2009 (UTC)

Suggestion for WP software. If the "Edit summary" is left blank...
If the "Edit summary" is left blank then it would be nice if the software would pop-up an intermediate page that gives a little warning and says "You forgot to fill out your edit summary, please fill-out the edit summary to continue." in bold & red letters directly next to the field.

Various online forms do this sort of thing as a reminder. Like when you come across a form that asks you to fill-out your name, address, phone number, email etc. If you forgot a field it will notify you... I must admit sometimes I am flying through something and I click before I realised that I've revised without adding to the edit summary. Because of this I wish the Wikipedia software could pop-up up a warning that the edit summary wasn't filled out. To my mind, I think a LOT of vandalism on WP might also get circumvented this way because if someone has a track record of claiming they are doing something legit (according to the edit summary they posted, but in actuality they aren't) then they will have eventually left a long trail showing they intended to vandalise while making their false edit summary statements claiming they were doing good. Others who are making legit contributions will get a mere small nudge to share what they are changing and will be able to move along thereafter. Would this process add too much load to the WP servers? CaribDigita (talk) 04:37, 9 April 2009 (UTC)
 * There is. Special:Preferences → Editing → "Prompt me when entering a blank edit summary". EVula // talk // &#9775;  // 04:52, 9 April 2009 (UTC)
 * Actually, this is an interesting idea: how about requiring edit summaries as a way to prevent IP vandalism? Calliopejen1 (talk) 12:22, 9 April 2009 (UTC)
 * It's been suggested! ╟─ Treasury Tag ► contribs ─╢ 12:26, 9 April 2009 (UTC)


 * Then they'd just include a seemingly innocent summary making the vandalism harder to spot.- Mgm|(talk) 12:43, 9 April 2009 (UTC)
 * Ditto. I'd much rather have vandals do their things from an IP and no edit summary, the more they stand out the better. Besides, I find it infuriating when some piece of software tries to force me into doing something. Especially with popups. Ain't how tools are supposed to behave. Equendil Talk 23:32, 9 April 2009 (UTC)
 * Oh no you have me all wrong. It would **not** be a "pop-up", as in a Javascript pop-up window. I hate those too.  It would look like the same thing as when you only--- input your username (but not password) on say the Yahoo login or Gmail mail login.  If you don't fill in *both* the username and passwords on those sites they return you to the same page again with the red text reminder asking you to input something in both username and password fields....   In the meantime, great suggestion EVula.  I'm going to turn mine on right now. :-)  CaribDigita (talk) 01:26, 10 April 2009 (UTC)


 * I would prefer mandatory filling of the edit summary for logged-in users in the article namespace. It would be very helpful for page watchers, and also it could prevent having too many edits by the user in a short span of time. Jay (talk) 02:49, 10 April 2009 (UTC)
 * We could start by having the preference "Prompt me when entering a blank edit summary" set to "yes" (that is, checked) for all new user accounts. Then editors could turn it off if they wanted to.  Plus the edit summary would not be mandatory, since clicking the "Save page" button a second time will save an edit even though the edit summary is (still) blank.  -- John Broughton  (♫♫) 15:02, 10 April 2009 (UTC)

Making the "remember this is only a preview" message look like an editnotice
See proposal: essentially with a bit of CSS we can turn the preview bar into a proper editnotice like all the others we have. Comments appreciated over there. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 19:57, 10 April 2009 (UTC)

Adding a note on sourcing in copyrightwarning or edittools
I have often noticed IPs or new users who didn't know how to cite, and messed up with references tags or just didn't format. So we could add a note on sourcing and link to Citing sources in MediaWiki:Copyrightwarning or MediaWiki:Edittools. Of course, it would also help to improve sourcing. For example:
 * Content that violates any copyright will be deleted. Encyclopedic content must be verifiable, please cite your sources. You irrevocably agree to release your contributions under the  GFDL* .

And/or adding a more detailed note on this below Please note:, although it would be less visible. Cenarium (talk) 19:28, 10 April 2009 (UTC)
 * Or something like:

Content that violates any copyright will be deleted. You irrevocably agree to release your contributions under the  GFDL* . Encyclopedic content must be verifiable, references are required for most claims, please cite your sources.

Please discuss at MediaWiki_talk:Copyrightwarning. Cenarium (talk) 20:39, 11 April 2009 (UTC)

Poll: autoformatting and date linking
This is to let people know that there is only a day or so left on a poll. The poll is an attempt to end years of argument about autoformatting which has also led to a dispute about date linking. Your votes are welcome at: Date formatting and linking poll. Regards Lightmouse (talk) 09:05, 11 April 2009 (UTC)

Wikipedia:Advertising discussions
Please see Advertising discussions, a proposal I've made to formalise guidelines on where and how the largest discussions should be advertised around Wikipedia to ensure sufficient input to major discussions. Improvements to the page and input on the talk page would be appreciated. Carcharoth (talk) 10:33, 11 April 2009 (UTC)

Poll on reviewer autopromotion for flagged protection and patrolled revisions
There is currently a poll on the autopromotion of reviewers at Wikipedia talk:Reviewers, for the trial implementation of flagged protection and patrolled revisions. For information, see general documentation and overview. All users are invited to comment, and to participate in the elaboration of a reviewing guideline as well. Cenarium (talk) 13:43, 12 April 2009 (UTC)

Disputed maps templates
Despite the importance of the maps, we have very little editorial tools (or control process) over the maps. We have no templates, inline for map citations, or for map pages, to indicate that a map may be inaccurrate or unreferenced. We only have the POV-map template for indicating on a map page that it may not be neutral, but we have no inline version for caption. I propose creating the five missing templates, see also threads at Wikipedia talk:Dispute templates, Template_talk:Unreferenced and Template talk:POV-map. --Piotr Konieczny aka Prokonsul Piotrus 17:20, 12 April 2009 (UTC)
 * I support this proposal. Incorrect maps can distort an article greatly.HP1740-B (talk) 08:23, 13 April 2009 (UTC)

Subpage feature
We are planning to enable the MediaWiki subpage feature on the namespaces Help, Help talk and Category talk. If anyone has any comments to that, see discussion at Village pump (technical). Technical comments are especially welcome, we want to know if anyone knows anything that might break when we turn that on.

--David Göthberg (talk) 12:12, 13 April 2009 (UTC)

Automatic detection of citation format
I have proposed that Citation bot amends pages using a mixture of 'Cite xxx' and 'Citation' templates so that only one family of templates is used. I would welcome comments on this suggestion here. Thanks, Martin  (Smith609 – Talk)  20:01, 13 April 2009 (UTC)

Quality related proposal - use of a "drafts" namespace.
I was considering the issue of BLPs, and not convinced that any of the current proposals (CSD#10, or otherwise) would make sufficient difference. A possible suggestion:


 * {| style="border:black solid 1px" width="90%"


 * From onwards, all new articles should be of some basic standard, to be added to the wiki. At a minimum:
 * 1) Any claims or statements likely to be controversial must be reliably sourced
 * 2) Any BLPs have sourcing for their major statements, and a reasonable balance of weight for any criticisms or potentially negative content.
 * 3) Any article that relates to a person, group, organisation, web content, or news event should have some reason visible why it is likely to be encyclopedic.

New articles that do not visibly meet these criteria may be moved by any user to a "Drafts:" namespace as follows:
 * The author is notified as follows: "Thank you for contributing to Wikipedia. Your article [NAME] needs a little more work done on it, before it can be added to Wikipedia. The [move log] will explain what issues were found. Otherwise the draft will be removed in 5 days, but you may always ask for a copy of the text by email, for the purposes of improvement and re-posting."
 * The article in the Drafts: namespace has a header added - ''"This draft article is awaiting improvement by its author or any other user, to rectify issues noted in the [log]. Once these are fixed it may be moved back into the main encyclopedia. If they are not fixed within 5 days the draft will be automatically deleted."
 * The Drafts: namespace is forcibly NOINDEXed.
 * No redirect is created for moves to Draft: . Instead a note is added to the "page not found" notice saying to check if a missing page was moved to that namespace


 * }

Advantages compared to current processes:
 * 1) Dodgy or questionable articles (especially BLPs) can be removed from mainspace and indexing, immediately, until the basics are fixed, and "benefit of doubt" is no longer a problem.
 * 2) Articles can be retained for improvement but their new location isn't spidered, so they aren't doing harm while the author is consulted or others work on it.
 * 3) It's more user-friendly to move something to drafts, than to delete it, and informs a well-meaning author what's needed to make it okay. This encourages good faith authors to do more, and to a better standard.
 * 4) All articles added to the wiki henceforth, will be of a basic minimum standard, or else they can be instantly deleted, or Draft-ified.
 * 5) The process is open and flexible, and hence well suited to be extended or updated based upon experience.
 * 6) This has all the advantages of PROD and none of the disadvantages. So PROD can probably be deprecated.

Initial thoughts?

FT2 (Talk 15:12, 3 April 2009 (UTC)
 * Oppose - this is broadly similar to Citizendium or Veripedia or whatever I'm thinking of :p and impairs the concept of a wiki. As long as there are new-pages-patrollers, people should be able to create new articles of any standard that meet the very basic guidelines, and have them improved by the community in general. ╟─ Treasury Tag ► contribs ─╢ 15:17, 3 April 2009 (UTC)
 * How exactly does it prevent any of that? It simply says that if certain common basic issues are noted in the article, it's moved to a separate namespace where it can't do harm, and the author (and others) advised of its defects. Anyone can work on it, anyone can create new articles... these things are unchanged. I think you may have misunderstood the idea. FT2 (Talk 15:20, 3 April 2009 (UTC)
 * Well, I certainly read everything you wrote ;-) The thing is, if you're going to take the "it won't make any real difference" tack, then why introduce such a complex change? And if it is going to make a big difference, than that's my point.
 * I don't understand what practical, tangible benefits the introduction of a new namespace, and the template-messaging of newbies saying "We've stuffed draft: in front of your article title until you complete the following tasks..." (yes, exaggurated, I know), will bring to Wikipedia. ╟─ Treasury Tag ► contribs ─╢ 15:27, 3 April 2009 (UTC)


 * You are essentially talking about a way of using flagged revisions. In one common configuration, the actively edited but not yet delivered to the public version is even placed behind a tab called "Draft". Dragons flight (talk) 15:29, 3 April 2009 (UTC)
 * Flagged revisions is quite different. This would be for new articles only, and not require any new "permissions" or "classes"; its aim is to ensure that at the first addition of a new article to the wiki, at least certain basics are taken care of, or else the author is asked to fix them first. As such there is no "class" or users who can and can't do this - the pages are in a namespace anyone can access, and anyone can re-mainspace them. In effect a genuinely defective 1st draft of a new article is put somewhere safe until the author fixes up the basics and moves it back to mainspace. Flagged revisions is considerably different. FT2 (Talk 15:33, 3 April 2009 (UTC)
 * I believe that this effect can actually be achieved with FlaggedRevisions, or certainly something very similar to it. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 16:13, 3 April 2009 (UTC)
 * Whether it can or can't, Flagged Revisions is not trying to achieve this goal. The aim here is two things -- new articles going forward should at least have reasonable sourcing (especially BLPs) and reasonable notability, and, if they don't, then the dichotomy of CSD/PROD/leave is not necessarily a good one. It may be better to return them to the author (out of mainspace and not indexed) with a request to improve, rather than a simple "delete/don't delete" (CSD) or "leave to be mainspace and indexed while waiting for evidence of appropriateness" (PROD). I've suggested a "draft" namespace but it could as easily be userified. The advantage is that userspace might be indexed, draft space wouldn't be. FT2 (Talk 19:15, 3 April 2009 (UTC)


 * Oppose It's against our editing policy. Our articles are perpetual drafts. Either it's to be deleted and we have processes for that, either it's to be fixed, and moving to a less visible place will make the fixing less likely. Cenarium (talk) 19:46, 3 April 2009 (UTC)


 * Disclosure: FT2 asked me to take a look at this, so here I am. In my view, the opposers are opposing on "anyone can edit" grounds, essentially. They have a point. This proposal does not exactly fit our current culture. But they miss the larger point which is that our current culture ... is broken. It needs fixing. We have quality problems. In some areas it's a so what... that we have the details wrong about an early 19th century landscape composer isn't going to be the end of the world. But in other areas (BLPs for example) it matters a great deal. Disclaimers or not, we do want high quality. This proposal may not work. But it is worthy of further investigation and elaboration. Dismissing it out of hand is wrong. Support further elaboration. ++Lar: t/c 20:21, 4 April 2009 (UTC)
 * If we put a page in a corner where nobody will find it, then its quality is not going to improve. Our articles are steadily improved because of their visibility - and incidentally, because anyone can edit - but forking like this will not result in improvements. Drafts will be forgotten and inappropriate content will stay. The vast majority of our articles, even our best ones, were started as stubs or in bad shape. We need increased coordination for BLPs, and progress in this sense has really started only recently. Cenarium (talk) 22:06, 4 April 2009 (UTC)
 * Unfortunately, there are some articles where sufficient bad shape in key areas is a big enough problem that "eventually" isn't good enough. Hence CSD and PROD. "Yes there happens to be a contentious claim that's unsourced and could do harm if inaccurate but someone'll eventually fix it so never mind" just doesn't work, for a top 5 reference site. This proposal would require articles to be held in abeyance and their authors (or other editors, or patrollers) notified that contentious claims needs to be sourced and cited, before it's fit to be added to mainspace. This isn't contentious - sufficiently inadequate articles are historically often deleted (A7) rather than just passed back for improvement. Drafts (under this proposal) will be automatically deleted in 5 days, as PRODs are, the difference is that a wider range of problem articles will be able to be intercepted and improved, ie, a quality improvement of new articles added to the wiki. We need those adding articles to have it explained at the point of posting, that basic sourcing of anything contentious is part of initial stub writing, not just an afterthought. FT2 (Talk 10:20, 5 April 2009 (UTC)
 * Of course, some BLPs need swift action. But why should we apply such a process in other cases and not let our current editing process apply ? You say that this would be used for new articles and that it would deprecate prods, but prods are not used for new articles only. (Moreover, moving a page that has existed for a long time to the draft page would surely be controversial, and I imagine move wars over this.) Anonymous and new users could not use this process because it requires moving a page, so I would oppose for that only. I would much prefer and support a template that can be put on a blp when it is suspected that it violates the BLP policy, and would put the page in a tracking category, and optionally noindex (removals can be monitored with the abuse filter). Cenarium (talk) 14:56, 8 April 2009 (UTC)


 * Oppose #1 is basically a pseudo-CSD for enforcing WP:V, #2 is a pseudo-CSD nuclear option for enforcing WP:BLP, and #3 is a vaguely-defined version of WP:CSD. This sounds like a bad way to chase off new editors, and a poor excuse for not having consensus for a CSD to enforce WP:V: instead of outright deletion, it shoves the pages off to some obscure corner with no reference to it, where it will be deleted in 5 days. It also seems wide open to abuse where one side decides that it will never accept any source as "reliable" or any wording of criticism as "balanced". I also find the claim that this is somehow the only way to deal with unsourced statements in BLPs to be inaccurate; what ever happened to removing the statements in question instead of nuking the entire article? All in all, it strikes me that Wikipedia is neither Veropedia nor Citizendium, and I'm not convinced that needs "fixing". IMO, the only good idea here is the NOINDEXing of pages pseudo-prodded in this way; but why not just NOINDEX any BLP that is prodded/AfDed for this reason instead? Also, as you allude, the idea (and others like it) is currently having much more in-depth discussion at WT:CSD. How about joining that discussion instead of forum shopping it here? I don't see a single comment with your signature on that page. Anomie⚔ 16:10, 5 April 2009 (UTC)
 * Veropedia locked stable versions of articles down and Citizendium had articles written by proven experts. I don't see how eithe project relates to requiring basic article writing criteria to be met. Veropedia only comes in on 'finished' articles and we still don't put a limit on who can write the article as long as they register as a user. - Mgm|(talk) 08:35, 6 April 2009 (UTC)
 * Both seem to be based on an idea of "only people who 'know enough' and want to jump through our hoops can edit", as opposed to Wikipedia's "anyone can edit". Forcing every new contributor to have knowledge of the intricacies of WP:V and WP:CITE or their contribution gets summarily deleted strikes me as a pretty big hoop, and far beyond the current threshold of "your contribution has to have some basic indication as to why it's worth inclusion in an encyclopedia" given in CSD A7 and A9. Anomie⚔ 12:26, 6 April 2009 (UTC)
 * The problem is that CSD is (as its name suggests) for speedy actions only - that means those where there is pretty much overwhelming cause. We need to tilt a balance slightly more towards quality, say 3/10 rather than 1/10, and asking that basics like letting authors of new articles know "please cite contentious claims in new articles before mainspacing them" is not something that CSD is designed for, so it's not helpful to suggest it on that page. FT2 (Talk 17:22, 7 April 2009 (UTC)


 * I don't oppose the idea of a draft namespace on its own (having a draft space might actually make people stop and think before creating deficient articles in mainspace), but if anything that's no goof after 5 days is deleted, people will simply use userspace as is common practice now. Noindexing already takes care of the outside visibility, so there's no reason to speed up deletion. - Mgm|(talk) 08:31, 6 April 2009 (UTC)
 * That makes sense. If it would help get things moving, then thats reasonable, or at least a longer period. FT2 (Talk 17:22, 7 April 2009 (UTC)


 * Extremely strong oppose and ban suggestion.  Mr. IP  《 Defender of Open Editing 》 09:56, 14 April 2009 (UTC) Personal attack redacted. <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 10:46, 14 April 2009 (UTC)


 * Oppose We already have an option for deleted articles to be moved into user space. I don't think editors other than the creators would trawl through the draft namespace looking for drafts to improve. Those that know the main WP policies and the techniques form implenting them will probably just create decent versions themselves (10 mins max for initial text and a couple of refs). So I think this is a solution in search of a problem. In addition BLPs need much stricter streatment as a "bad" BLP can expose WP to lawsuits and other hazards such as being blocked in some less-develpoed countries. The draft name space would have some trail of links that readers can follow, otherwise it might as well not exist. In that case WP would be exposed to the hazards I've mentioned, even if such articles are not indexed by the search engines. So, much as I dislike speedy deletion in principle, speedy deletion without saving a copy anywhere seems the only solution for "bad" BLPs. --Philcha (talk) 11:00, 14 April 2009 (UTC)

Category:Pages with incorrect ref formatting
I propose some automated (bot) cutting-down of this category. All the 6,119 page included have some issues that result in the loss of information. However, within that there are many distinct causes which a bot (or someone with a lot of spare time on AWB) could sort, leaving the important ones more accessible. The point is that many of these pages - and I wouldn't propose editing anything in article space, don't worry - are now archives, and no-one really cares very much.

That's just a start, but we'll see exactly the community is happy with (editing archives?) before proceeding. - Jarry1250 (t, c) 10:40, 13 April 2009 (UTC)


 * See Help talk:Cite errors. We have been discussing namespace detection for this set of errors. I don't think there should be any issues with removing it from any talk page, but we need to discuss other spaces.


 * As to templates with refs; see Help talk:Cite errors.


 * --Gadget850 (talk) 11:18, 13 April 2009 (UTC)
 * Well, having read a few of the various discussions, I think I'm with debresser - I'd rather fix these than ignore them. As for templates - and I'm sure your experience in previous discussion would be most useful in advising here - that documenting with a Reflist would have an added benefit of alerting people to the fact that the template may cause errors if incorrectly placed in an article. - Jarry1250 (t, c) 11:26, 13 April 2009 (UTC)
 * You want to fix the errors on talk pages? That is going to be a never-ending task. AS to templates, I had a template at template reflist but deleted it after discussion. It can easily be restored if needed. --Gadget850 (talk) 11:45, 13 April 2009 (UTC)
 * Fair enough about talk pages, but we have thousands of never-ending tasks on Wikipedia, and a full backlog-clear would be of no harm, surely? - Jarry1250 (t, c) 16:15, 13 April 2009 (UTC)


 * Agree about removing from this category all archives. If that is technically possible. And if there are a lot of them (500+). Very strongly disagree as far as templates are concerned. And I am willing to fix any template with such a problem (just as I did in Category:Wikipedia pages with broken references). Debresser (talk) 11:51, 13 April 2009 (UTC)
 * What about warning people that these are potentially troublesome templates? Is that not a just cause? - Jarry1250 (t, c) 16:15, 13 April 2009 (UTC)

What do you mean? That is an argument to do what? Debresser (talk) 02:02, 14 April 2009 (UTC)

BTW, fixed the first 5 templates from this category. Their only problem is a missing references section. See my talk page for how to fix this. Debresser (talk) 03:15, 14 April 2009 (UTC)
 * Hmm, I think I've got our wires crossed. That's very much what I'd be for, just (if we we're letting a bot do all the hard work) with the additions of creating and transcluding a doc page if one did not exist, and warning on that that incorrect usage of the template in article space can cause ref errors. In other words, not something we're directly talking about here, but a related tangent. But yes, that's exactly the sort of fix for templates I would like to see mass carried out (I'll do it with AWB if it comes down to it). - Jarry1250 (t, c) 07:24, 14 April 2009 (UTC)
 * I think I understand you now. You are thinking of what will happen when somebody uses such a template in a article without a references section, right? Well, that happens, although usually either the article already has a references section, or the user will notice the problem and fix it. But yes, on my talk page I mentioned that I fixed a few instances where this was cause for a references error. Frankly, I wouldn't worry about it, Even if it happens, it'll get fixed soon enough, especially now with the Category:Wikipedia pages with broken references cleared from its backlog. Debresser (talk) 08:53, 14 April 2009 (UTC)

See my talk page that I fixed all images, all subcategory pages, and all stray templates. Left: templates at letters "I" (from Infobox) and "T" (from Template). Debresser (talk) 14:31, 14 April 2009 (UTC)

In short: I think we need "Article", "Template" and "Category" namespace, preferably also "Help" and even "Image" namespace, "but not "Talk", "Wikipedia" and "User" namespace. Other namespaces I dont care either way. Debresser (talk) 15:01, 14 April 2009 (UTC)


 * That sounds doable— I will look at it later today; gott make a deadline in real life. --Gadget850 (talk) 15:06, 14 April 2009 (UTC)


 * I'm happy you say so. I've come to know you as a person who adds deeds to words, and quickly. I from my side am willing to put in a fair amount of work, as you may have noticed.


 * I think it is not only doable, but more or less logical also. Debresser (talk) 15:10, 14 April 2009 (UTC)


 * And very easy to do now that I found namespace detect showall. --Gadget850 (talk) 15:54, 14 April 2009 (UTC)


 * Namespace detection for MediaWiki:Cite error group refs without references and MediaWiki:Cite error group refs without references have been updated so that the messages show only in main (article), template, category, help and file (image) namespaces. I will wait a day or so for additional comments before updating the other messages in a like manner. --Gadget850 (talk) 18:27, 14 April 2009 (UTC)

11477
That bug was opened almost two years ago and nothing has been done. The proposal has been made again during a discussion at Abuse filter/Requested. -- IRP ☎ 20:21, 14 April 2009 (UTC)

Also made the request here. -- IRP ☎ 23:34, 14 April 2009 (UTC)

Image → File
After the rename of the "image" namespace to the "file" namespace, I propose that we rename links to "images" to be links to "files", if the article is already being edited for some other reason. For example, this can easily be done using AWB while also making other edits, but edits should not be made solely for the change as it is a waste of server energy.

The reason for this proposal is that seeing both "Image" and "File" could be confusing to newer users who aren't aware that there was a change. File is also the more correct term to use after the rename, and being two letters shorter could have some impact on page loading for users with slower connections if there are a lot of files on the page.

Thoughts? –Drilnoth (T • C) 22:45, 6 April 2009 (UTC)
 * I know you said "if the article is being edited for some other reason" but I still don't see the need for a planned process to change these over. I figure if you notice while editing an article, change it if you want, but it won't make any difference. - Rjd0060 (talk) 02:58, 7 April 2009 (UTC)
 * I don't think that there needs to be a specifically planned process to accomplish my proposal, just an acceptance of the change when someone uses AWB or the like and makes it. –Drilnoth (T • C) 12:18, 7 April 2009 (UTC)
 * You've already started planning the process, by creating this thread. :-) I don't see a need for this organized effort, honestly. - Rjd0060 (talk) 16:08, 7 April 2009 (UTC)


 * Using image vs. file will have no noticeable effect on loading time. What matters for most page loads is the rendered text, and "Image:" is always converted to "File:" for the rendered text except in the rare case of unpiped image links like Image:Example.jpg, even then, the target of the link is still converted and a couple bytes isn't going to make a difference, even on a dialup modem. There might an extra microsecond to look up the namespace alias on the server, but the performance impact is basically nil. <font face="Broadway">Mr.Z-man 16:45, 7 April 2009 (UTC)
 * Yep, all excellent reasons why we shouldn't go through and changes these en-masse, but I'm sure the it could be added to AWB's general fixes (if it hasn't already). Drilnoth has a point about consistency and not confusing new editors. It'll be a slow process, no doubt. – xeno  ( talk ) 16:51, 7 April 2009 (UTC)
 * Okay; I just wanted to make sure that I could add the change to my customization of AWB and that there wasn't any real opposition to it (I can't tell if Rjd0060 is opposed or just neutral on this matter). The primary concern was to reduce confusion for newer editors; I didn't know whether the loading time thing was accurate or not. And I just prefer file over image. :) –Drilnoth (T • C) 17:04, 7 April 2009 (UTC)

The change from Image: to File: has not been published very widely, so there are probably quite a few long-term editors who are not aware of it (I wasn't). And then just changing this will actually confuse them even more than new editors, who will simply start using File: to start with. Since there is not any positive effect to be achieved by changing Image: to File, I would still recommend to NOT do combine changes in other edit work. AWB work is often already obscure; please don't make it more obscure. IF the change is necessary/required/decided, then a simply bot can do all the changes throughout WP.  Wim van Dorst  (talk)  19:30, 9 April 2009 (UTC).

We already had problems with editors thinking that changing Image to File was a good idea. I noticed 1 or 2 editors doing only this. If we add it to AWB we will cause more confusion. I think we are ok the way we are. Changing Image to File is like changing redirects with the original title. No gain, more confusion, more editors are making only non-constructive edits. -- Magioladitis (talk) 23:42, 15 April 2009 (UTC)

New search engine option, so everyone is happy. The tags can be blocked from reviews.

 * PROBLEM Many deletionists are constantly trying to delete articles they don't like, much to the irritation or people who like them and want them to remain. There are constant debates for deleting, merging, and editing articles.
 * SOLUTION A simple solution would be to tag things, and then have the search feature filter things accordingly.

With the Google search engine, you can search for a specific term, found only in the tags, and only show those with tags you like, and not those with tags you don't like. Click here to see a search that reveals all those articles tagged as fancruft. You can have Google filter out all searches that have that also, if you don't want to see any fancruft at all.

If you want only want to find article approved as being of a certain quality level, then you can search for those who have an appropriate rating on the Assessment scale and/or the Importance of topic scale. Additional tags can be made. Just determine what some people want(such as articles for every episode, character, and list of weapons in a series), and others do not, and tag them accordingly, so people never see something they don't want to, while others can still have their fun.

Remember, 99% of wikipedia articles are just entertainment. Even some education ones, listing all species of extinct insects, ancient battles from two thousand years ago, etc, are entertainment only for those who like that sort of thing, there absolutely no practical application for that knowledge. And that's just fine with me.

And for all those people who are complain constantly that fancruft and whatnot give wikipedia a bad reputation, to whatever snotty elitists they believe are out there judging us and care about, you can have the default set to filter fancruft and whatnot out, people only finding it if they click the option under the search button, saying they want to see it. That way, everyone is happy, no legitimate complaints left to argue back and forth on.  D r e a m Focus  21:33, 13 April 2009 (UTC)
 * Comment If you want your proposal to go over well, you might want to assume good faith when proposing it. As a "snobby elitist" deletionist, I take offense at your characterisations in this post.  Furthermore, Wikipedia is not, and never was intended to be, "just entertainment". Wikipedia is a serious encyclopedia and what happens on here has serious consequences in the real world.  Them  From  Space  21:44, 13 April 2009 (UTC)
 * Comment Leaving aside Dream Focus' character assassination of many editors who actively work to improve article content, I can't quite see what value there is in this proposal. Surely the best way to ensure that users find content in an encyclopaedia that is, er, encyclopaedic is to work on the actual articles in order improve the chances of finding factual articles that link to other, non Wikipedia, sources.
 * Practically this proposal looks like it would make using Wikipedia more difficult to use.
 * I don't think that whether anybody "likes" or "doesn't like" an article is relevant, nor should it be. pablo <sub style="background-color: #ffc; color: #c30;">hablo. 23:03, 13 April 2009 (UTC)
 * "actively work to improve article content"? Does that mean erasing 99% of the article because you consider it cruft?  Usually when someone speaks of improvements, they end up deleting much of the article, or all of it.   D r e a m Focus  00:32, 14 April 2009 (UTC)
 * What it means is "actively work to improve article content". pablo <sub style="background-color: #ffc; color: #c30;">hablo. 00:39, 14 April 2009 (UTC)
 * I see no value to this proposal - DISCLAIMER: I am an evil evil deletionist (just in case dreamfocus is keeping a list). --Cameron Scott (talk) 23:06, 13 April 2009 (UTC)
 * Careful, that's my registered trademark ;) Cheers, Jack Merridew 07:11, 14 April 2009 (UTC) for the Evil Deletionist® Cabal
 * Its simple. Instead of deleting all the articles you don't like, we simply make it so only people who like that sort of thing can find it.  And it wouldn't be confusing.  See the search button over to the left?  Have a few things under it you can click on, to select them.  That'll add things you can search.   D r e a m Focus  00:32, 14 April 2009 (UTC)
 * Got that bit. So it makes the search more unwieldy (not a benefit) to filter articles on the basis of whether the searcher "likes" them. (not a consideration). Or am I missing something? pablo <sub style="background-color: #ffc; color: #c30;">hablo. 00:37, 14 April 2009 (UTC)
 * Simple? This sounds much more complicated than the current system. At the minimum it requires rewriting major parts of the search engine to replace deletion. I agree with Themfromspace, Wikipedia is in the real world. Even if we filter it out of our own search results, it'll still be in Google results and all the other external search engines and we still have to make sure the articles are quality work. Though if you don't understand the difference between an article on a historic war and one about a video game character, I doubt you're going to be convinced by any of the arguments that people present here. <font face="Broadway">Mr.Z-man 02:11, 14 April 2009 (UTC)
 * Odd that Optical character recognition is tagged diff as fancruft — I didn't realize that there are OCR-fans out there; this proposal is, of course, silly. A far better wiki-world would be one where all the fancruft was on the appropriate wiki. Cheers, Jack Merridew 07:11, 14 April 2009 (UTC)


 * Oppose. 1) That's a solution to a false problem. "Deletionists" are not constantly trying to delete articles they do not like, they are people concerned that many articles created on Wikipedia are inherently not encyclopedic (dictionary definitions for instance), in violation of copyrights, unverifiable, hoaxes, inherently non neutral, adverts etc. The vast majority of deletions are not in dispute. 2) That's akin to a fork of the project. I can't imagine any good coming from that. By the way Deletionpedia keeps pages deleted on Wikipedia. Equendil Talk 16:19, 14 April 2009 (UTC)
 * Oppose some tortured effort to split wikipedia in two to solve some sort of straw man problem that i don't understand. People can already exclude things ("-") when searching on google and the like. There are strong reasons that some material isn't suitable for inclusion in an encyclopedia that have nothing to do with technology, but rather how we chose to organize and display information to maintain credibility, usefullness, etc....Bali ultimate (talk) 20:48, 14 April 2009 (UTC)
 * I'm an inclusionist, but I'm crossing the aisle to join my deletionist friends and oppose this. Wikipedia is optimized not for experienced editors but for readers, in particular for casual readers who come straight off a simple google search, don't know what Wikipedia tags are and would never use such tags to filter their searches.  If this proposal is a replacement for the deletion of certain articles, the effect will be as if those articles had been straight-out kept.  If current policy is too deletionist, the solution is to gain consensus to change policy directly, rather than trying to work around deletionism.  Baileypalblue (talk) 17:49, 15 April 2009 (UTC)
 * I don't see the problem. You would only get search results for "fancruft" if you searched for them. I don't know what kind of search engine would give you Wikipedia articles about Bulbasaur if you were searching for E. E. Cummings. OrangeDog (talk • edits) 23:58, 15 April 2009 (UTC)

Spell checker
To Wiki programmers: could someone add a spell-checker to the edit buttons above? I don't think it'd be a big task, and wiki editors would be forever grateful--would save so much time and hassle. After installation, other wikis could also copy/translate the proceedure, a gain for every Wiki on the planet (I happen to work for hu.wiki). The substitute solutions offered by en.Wiki for having and operating a spell-checker while creating articles are clumsy and troublesome. A spell-check button above would be so much simpler. Please help us out. Thank you,--97.112.153.113 (talk) 00:06, 14 April 2009 (UTC)


 * Actually, I think such a thing already exists, in a way. If you use Mozilla Firefox, then a spell-checker automatically appears in the edit box window, underlining words that haven't been spelled correctly.  tempo di valse  [☎]  00:11, 14 April 2009 (UTC)

Thanks, but I know about Firefox. I don't have it, and don't want to have it. Why wouldn't the above suggestion work? Should I transfer my request to Bogzilla? --168.103.249.30 (talk) 00:15, 14 April 2009 (UTC)


 * I'm not sure, but I think that WikiEd, which is a javascript function available to registered users, features some sort of a spell checker.  tempo di valse  [☎]  00:18, 14 April 2009 (UTC)
 * WikiEd doesn't work in Internet Explorer so you would need to install FireFox to use it. Tra (Talk) 00:21, 14 April 2009 (UTC)


 * Google IE Spell - nifty free spell checker add on for IE. -- AnmaFinotera  (talk · contribs) 00:23, 14 April 2009 (UTC)

Oh please, gentlemen...I read about it all. Can't you just answer my question: why couldn't Wiki install a spell checker into its edit box? Can it or can't it. I can't believe it can't. --97.121.172.3 (talk) 00:47, 14 April 2009 (UTC)

PS. In addition, what I need is a Hungarian spell checker. ieSpell doesn't have that. (FoxFire does, but as I said above, I don't want FoxFire.) But if enWiki would put the spell checker into its own edit box, all wiki sites could instantly install their own. Why is that so difficult? Please don't ignore the proposal, and the innumerable wiki volunteers, all wishing for an easy access to a checker in the editing box. If you can't help, nobody can.--97.121.172.3 (talk) 01:04, 14 April 2009 (UTC)


 * As with most computer related questions, the answer is yes, it is possible. But is it practical to replace an HTML textarea element with a java application or some other complicated structure, when spell checkers are already readily available to the end user?  Probably not.  Is it likely?  Probably not.  If you prefer to use a browser with no built-in spell checking capabilities, that is your choice.  IE usually picks up features popular in other browsers, so maybe a future version will give you the functionality you desire.  -- Tcncv (talk) 02:27, 14 April 2009 (UTC)


 * The spell checker is not likely to happen any time soon, given the availability of Firefox and other similar solutions. Per the FAQ on the technical Pump page:"'No, we will not add a spell-checker, or spell-checking bot. Spell checking has been disabled on the Wikipedia search engine for performance reasons, and also because it is impossible to prevent it 'fixing' legitimate errors (see Teh). You can use search engines like Google to search Wikipedia and correct mistakes in searches: include 'site:en.wikipedia.org' with your searches. And for spell-checking what is in the edit box, you can use a web browser like Firefox, which includes such spell checking.'"--Ckatz <sup style="color:green;">chat <sub style="color:red;">spy  02:32, 14 April 2009 (UTC)

You quote: "Spell checking has ben disabled...for performance reasons...etc." May I ask you this: what about us, i.e. our time? I don't have to elaborate on this, you all know what I'm talking about. All we want is to have a spell checker, that's just a click away, right under our noses; to correct no more than typing errors, as fast as possible. Gentlemen, I want you to know that I wrote to the founder of Wiki, telling him about this problem--for him small, for us fairly big. I hope he will listen and do something about it. Thank you for trying to help. My best regards to you all. --97.121.172.3 (talk) 03:17, 14 April 2009 (UTC)
 * It will probably come with new interface we're getting next year. See Wikipedia Signpost/2009-01-03/News and notes, section "MediaWiki interface to get a facelift".  I doubt it will happen before then. - Peregrine Fisher (talk) (contribs) 03:51, 14 April 2009 (UTC)

Well, thank you, Peregrine Fisher--at last there's one person who understood my plight. I looked up the link you directed me to. Yes, there are many "non-tech" editors (including myself), otherwise able to do lots of valuable things. It's a pity that the "facelift" is so far away. Greetings,--168.103.248.249 (talk) 15:57, 14 April 2009 (UTC)


 * I suppose you could just get Firefox in the mean time... :-p Sillyfolkboy (talk) 16:42, 14 April 2009 (UTC)


 * Yeah, spell checkers are nice, I use one myself right now. But:
 * So, anonymous user with many IPs, what about our time? That is, all us users with slow connections and/or slow computers? The code for javascript spell checking would be huge, thus slowing down page load and page rendering a lot for users like me. And it would also make the editing in the edit box very slow.
 * And what about the time of the MediaWiki developers? It would be a lot of work to implement such a thing. There are many other things that need fixing here at Wikipedia that thus would have to wait or never be done.
 * Oh, and a spell checker would not work especially well for users like you who don't log in. Since one of the things that makes a spell checker usable is that you can add words to it, so over time it doesn't mark all the correct but unusual words you use. But a javascript based spell checker could not remember words you add, since Wikipedia can not know you are the same user that comes visiting again. Unless of course we add cookies so we can track IP users like you... But many users have their browsers set to remove all cookies when the browser is closed, so even cookies wouldn't help.
 * And since the spell checker could not know the preferences of not logged in users like you, what kind of English should it use? British, US, Aussie, South African or some other variant of English spelling?
 * So instead I suggest you install a spell checker plug-in in your Internet Explorer (apparently such things do exist), or if that doesn't work then there are better browsers. But if you are too lazy, or prefer a bad browser, then there's really no way to solve your problem.
 * (Well, there is a way to make a spell checker that doesn't need javascript, that is entirely server based. But it would work badly for users like you who doesn't log in. And it would be fairly clumsy even for logged in users. And it would cost a lot of server resources and a lot of developer time. Resources that we don't have.)
 * --David Göthberg (talk) 13:03, 15 April 2009 (UTC)


 * I would also point out that the development of an English spell checker would not necessarily mean that spell checkers for every other language like Hungarian would be instantly available. At the very least, word lists for each language would have to be found or compiled, and the algorithms used to make suggestions (what good is a spell checker that only says that you're wrong and not how to fix it?) may need to be changed to reflect the different languages. <font face="Broadway">Mr.Z-man 16:44, 15 April 2009 (UTC)

Renaming Articles for Deletion to Articles for Discussion
There is an ongoing proposal to rename Articles for Deletion to Articles for Discussion. Interested editors are asked to comment and make their thoughts known. -- Nick Penguin ( contribs ) 04:30, 16 April 2009 (UTC)

Favourites Section
I'm proposing to include a favourites section in the members 'taskbar' so members can quickly access aticles they like, and also to take their favourites around with them. It could also help students with their studies as they could quickly find the articles they need. It's just an idea and feel free to shoot it down. JRGregory (talk) 23:41, 14 April 2009 (UTC)
 * How is this not redundant with the bookmarks feature every browser has built in? You can easily separate out Wikipedia bookmarks from your others by making a folder for it in your bookmarks bar. A list of pages you want to separate out for quick navigation can also easily be kept on one's user page, or in any offline document. A user's watchlist also functions as a monitor of changes to pages you have taken enough interest in to watch.--Fuhghettaboutit (talk) 01:59, 15 April 2009 (UTC)
 * I'll hazard a guess the OP wants portability from such a feature—faves, perhaps taggable, accessible at home, work, school, and the privacy aspect of only the logged in author able to see the list. –Whitehorse1 02:08, 15 April 2009 (UTC)
 * Watchlist can do all except being taggable. No one can see your watchlist, its accessible soon as you log in, and easy to add/remove entries. -- AnmaFinotera  (talk · contribs) 02:11, 15 April 2009 (UTC)
 * I know. *g* There was an edit conflict, and I typed my comment before the previous commenter added the last sentence. –Whitehorse1 02:15, 15 April 2009 (UTC)

A watchlist is mainly for watching articles that you have edited, or in the process of editing. I'm talking about being able to use your favourites everywhere, with IE or Firefox you have to reinsert your favourties everytime you get a new computer. A favourites section which is intentionally used for favourites, not edited articles. JRGregory (talk) 10:55, 15 April 2009 (UTC)
 * A watchlist is for whatever you want it for. You don't have to ever edit a thing to use it. Browser bookmarks can easily be transfered between computers, it's not an issue, though there's a point to being able to access it everywhere. Why not make a user subpage with Wikilinks to your favorite articles (or even on your main user page?) ♫ Melodia Chaconne ♫ (talk) 11:27, 15 April 2009 (UTC)

What i'm really trying to explain is practicality. People who will use wikipedia for research will not want to go through the lengthy process of saving bookmarks offline or saving them to a subpage. Most people including myself want to be able to quickly get on a website and get started immediately after registering. People will be put off the fact that they will have to redesign their page using code, just to get a favourites page. JRGregory (talk) 14:09, 15 April 2009 (UTC)
 * See WP:VPT. – xeno  ( talk ) 14:13, 15 April 2009 (UTC)

My solution would be to just edit your user page with the desired links to save the developers from unnecessary work. If that's a problem, you can always create a user subpage specifically designated for these links. I've done this many times in the past.-- penubag  (talk) 07:46, 17 April 2009 (UTC)
 * Try the Wikimark script. - Mgm|(talk) 10:19, 17 April 2009 (UTC)

Usage statistics as encyclopedically relevant
This is the slightly revised text of a message that I was directed to post in this forum.

Following my perusal of the discussion regarding whether the British singer Susan Boyle meets notability and BLP criteria, and regardless of either the particular case of that article, or the more general and difficult question of whether brief but massive media attention is always notable, I have come to wonder whether the usage statistics of Wikipedia itself may not be more productively used.

While reported usage statistics from other web services or search engines, (e.g. Google searches, YouTube views), suit me just fine personally to establish how notable a thing is, though certainly not how credible, it may not presently be possible to surmount the problem that most web services, as privately owned or administered, are flatly not credible as the only sources of their unreviewable claims unless their service (and thus methodology), were really, truly completely transparent, which Google is certainly not.

However, what i'd like to emphasize here is that the usage statistics of the Wikipedia itself are *relevant to what people want to find in an encyclopedia* unless one were to propose a rather dubious argument that millions of queries for a phrase or a name, or millions of views of an article, reflect a poor popular understanding of what an encyclopedia is supposed to be.

Although I do not see any obvious solution to the notorious problem that editing seniority has displaced peer review in the Wikipedia project, I think that the Wikipedia does have its merits, and that one of them is an unique opportunity for a definitive encyclopedography, such that is not possible or not worth the effort in a paper encyclopedia.

For the present, I would like to see only a few small changes (that may well be impossible to implement retroactively, but that could still be started later rather than never). I want more usage statistics incorporated into the main article layout; this information is actually valuable to me. I would also like administrators to formulate specific guidelines on the relevance of this type of information for content management. It is as important as a consensus by the editors, or more so, because it is found rather than deliberated.

I'm not in the least suggesting an (accessible) list of current watchers, which, in addition to being unavoidably inefficient, would also in my opinion reflect an inappropriate philosophy for the project. rather, in addition to accessible counts of authors, revisions, and a simple total of views, i would like various subsidary counters describing the actual use of links to an article, links from an article, instances of query entry of the article title, and redirects of alternate titles (so we learn which title is actually more in use!)

I wouldn't necessarily care whether these counters are placed in situ or in an appendix, or tab, or box or whatnot. (links to an article, and the counters for their use, would have to be tabulated in an appendix; links from could have a counter in situ). ideally we can even derive some sort of percentage relevance from these counts. (Isn't that exciting?)

More ambitiously, I would like to know what information is proximal in actual usage, rather than nominally by deliberately creating cross-references. I would like the Wikipedia to sample at random what wikis a given user is looking at before and after the current wiki to whatever distance would probably be relevant. This data could be collected for a good sampling of users without much overhead. The results will have high redundancy with cross referencing, but what we'd get out of this automated process are some new cross references that would not necessarily have occurred to us.

L —Preceding unsigned comment added by 24.83.173.203 (talk • contribs) 09:52, 15 April 2009


 * Yes, it is interesting to see how many visits a page gets, and we actually have a tool that shows that. Here is page view statistics for this talk page last month. At the bottom of that page you can fill in the name of any other Wikipedia page to get the visitor statistics for that page. And you can check earlier months too etc. That tool is linked at the top of the revision history for all pages. So the easiest way to reach it is usually to click the [history] tab of a page, and then click the [Page view statistics] link there.
 * Note that there sometimes are some days or weeks missing from the statistics. That is because the statistics collection some times crashes, or are turned off for other reasons.
 * Sometimes when I wonder if a page is worth the effort to take care of I check the page view statistics for the page, and the result is often that I think "Wow, that many visitors? We better take good care of that page." :))
 * I understand that you want much more statistics than what that tool provides, but it is a good start.
 * --David Göthberg (talk) 17:33, 15 April 2009 (UTC)
 * Because usage statistics can be played like a game, it is inappropriate to use the raw numbers to guide content, particularly page views on WP. As long as there are mob-mentality groups that can inflate these to game the system, we can't use this. --M ASEM  (t) 17:39, 15 April 2009 (UTC)
 * The inclusion of content may as well be subject to 'mob rule', although I think the exclusion of content must not be. On the premise that the popularity of a document directly attests to its social relevance if nothing more specific than that, something to which a large number of people object is just as relevant as something of which a large number of people approve.


 * In any case, the *nature* of content should obviously not be determined ad populum --I'm not suggesting that, and I don't think anyone in their right mind would.


 * Moreover, the underlying assumptions of the argument that 'popularity criteria = mob rule' may be well motivated as the statement suggests a low specificity exclusion of possible vested interests, but I'm pretty sure there's a baby in the bathwater; Wikimedia is in a unique position to make empirical findings about how social espitemology works.


 * (It's also possible that i'm being accused of advocating mob rule because I picked a bio of a reality show contestant as my only example of a deletion flag that I thought shouldn't have occurred to anyone. Much as I dislike reality shows, my pretentious postmodern conscience doesn't allow me to dismiss what people watch. Incidentally, it seems that during the first three days of existence the article was viewed 35000 times. Of course this will dwindle even if Mrs. Boyle remains successful, but even so I don't think we can just delete stuff like that. Nor do I think that this example reflects the self-interested gaming of some part of the user base.)


 * L

Not long before Easter 2009, there was a request from a Wikipedian, who was concerned about articles getting deleted, to have some type of "page view" counter. The answer was - one is already there, if one presses "History" at the top of any article. However, it was pointed out that we should use measures other than how many times a page has been viewed as a measure of notability, and I am inclined to agree. After all, if we were to use these page view statistics as our prime measure of an article's notability, Wikipedia would end up being sadly lampooned as an encyclopeadia of popular media culture. Which of these articles do you think had the most views in early 2009 - Paul Tillich, James Joyce, Ludwig Wittgenstein or Amy Winehouse? Yes, I am afraid it is the answer one might fear. More disturbingly still, did you know that the articles on John Lennon and on Star Wars got more views in March 2009 than the article on the Bible? Well, I think this is evidence that what ever use we attach to page view statistics, they should not be used as either the only or the prime index of an article's notability. ACEOREVIVED (talk) 20:23, 16 April 2009 (UTC)

I agree that giving exclusive or primary importance to a viewing statistic would be an extraordinarily bad idea. I do think there is a place for these numbers in an AfD discussion despite 'page views' being listed as a fallacy in AfD discussions. Of course, one cannot say whether something is notable by referring to page views alone; it is a discrepancy between perceived notability and page views which should prove to be useful when in doubt of notability. There would be nothing wrong with supporting a notability judgement with statistical analysis that predicts how articles in certain categories would be expected to perform, (assuming that existing articles largely pertain to notable instances of that category --if we may thus provisionally reduce the information), compared to the actual performance of the article. (I don't claim to have made such analyses and would hate to try, just to be clear.)

(... also, shame about Wittgenstein; surely the man was unhappy enough to have been just as interesting as Winehouse.)

Irrespectively of relevance to inclusion/deletion debates, applications of query information and views would serve to keep prevalence-sensitive information up to date without any need for sources pertaining to prevalence (esp. of nomenclature; synonyms, metonyms, aliases) --which, *actually*, are quite likely to be inferior to the quantitative data drawn directly from the user base, anyway. (If a poll on the scale in the Wikipedia operates contradicted earlier surveys of prevalence, I would say the earlier surveys were wrong!) E.g., with an extremely simple script & the appropriate database, the most prevalent way of referring to a given subject could always automatically become the title to which all other queries redirect.

The short and skinny of the bigger proposal is that an empirically based, automatically generated proximity map of each wiki in relation to other wikis would be a useful and attainable complement to existing hyperlinks and classificatory elements. The user would be able to look at all 'nearby' wikis whether or not the nearby wikis are 'hard-linked'. It does occur to me that, where the hard links differ from the generated links, the pop culture bias would probably be higher in the latter, but since this scheme would not be intended to replace other ways of framing relationships between wikis, biases, whatever their nature, would actually be desirable. So, how is this different from just using a good search engine cleverly enough? Only in that the contents of the Wikipedia are already selected specifically for expository value.

L

Oh, and one other thought that makes me extremely pleased; if we could classify articles in such a way that their performance (in views/time) may be predicted, we would not merely have an indications that an underperforming article may not have been as notable as we thought, or that a disputed article performs well enough to satisfy skeptics, but also than an *overperforming* article might have been 'gamed'! yay, stats!

Move tab
Is there any particular reason, technical or otherwise why the move tab has no other tabs at the top, ever other tab does, doesn't make sense for this one not to. I'm guessing this is a bugzilla thing but thought I'd bring it up here first--<font color="Blue">Jac <font color="Green">16888 Talk 02:52, 17 April 2009 (UTC)
 * Not sure what you mean. When I click on the "move" tab, the page that comes up has a "special page" tab, as has the "Move succeeded" page. Are you missing (some of) these tabs? Mark Hurd (talk) 04:32, 17 April 2009 (UTC)
 * No they're still there, I'm talking about Page, Talk, Edit, History, Delete and Protect, why are they not there?--<font color="Blue">Jac <font color="Green">16888 Talk 04:40, 17 April 2009 (UTC)
 * AFAIK no "special page" has any other tabs. Mark Hurd (talk) 05:07, 17 April 2009 (UTC)


 * The special pages all ought to be in the toolbox. It's inconsistent to have one of them as a tab. —Remember the dot (talk) 06:22, 17 April 2009 (UTC)
 * What's inconsistent is to have most of the common page actions as <tt>&action=</tt> parameters in the URL, and yet have one action as a special page. I believe, however, that the general feeling amongst the devs is to move towards the special-page system.  We could always add the tabs using JavaScript... <b style="color:forestgreen;">Happy</b>‑<b style="color:darkorange;">melon</b> 09:41, 17 April 2009 (UTC)

Talk page banner
Because my computer isn't working online right now, I'm using my alternate account (meant for use on public computers) instead of my actual one, Nyttend. Each time that I use this account, I have to go to my main account's talk page to see if there are new messages, which I'd like to avoid if possible. Would it be possible somehow to create a system whereby those of us with legitimate multiple accounts could somehow get them "tied" together, so that a message left on one talk page would generate the orange "You have new messages" banner on the other account? Nyttend backup (talk) 12:44, 17 April 2009 (UTC)
 * that would be cool. – xeno  ( talk ) 12:50, 17 April 2009 (UTC)
 * Add your main to your watchlist? ♫ Melodia Chaconne ♫ (talk) 13:09, 17 April 2009 (UTC)
 * [normal computer working now :-)] I could do that, to be sure, but I don't see how that would be any easier than going to the talk page. Nyttend (talk) 15:21, 17 April 2009 (UTC)
 * Well, you wouldn't go there in vain when there's nothing new, because you'd be alerted when there's something new there. -GTBacchus(talk) 16:44, 17 April 2009 (UTC)

I propose a "why don't you run a wiki" section
I've realized after installing a wiki for my personal websites - that only I can edit - that some of the 'fun' of wikipedia is to edit stuff even if nobody else contributes. So if some people are so determined to edit and nothing can stop it even everyone else tells them to stop, "why don't you run a wiki" tell them:p --AaThinker (talk) 18:06, 17 April 2009 (UTC)
 * Are you saying that we should tell vandals to vandalise their own personal wikis. I don't see them listening. Zain Ebrahim (talk) 18:11, 17 April 2009 (UTC)
 * People who want to add in information that others consider fancruft, or not notable, should be directed to www.wikia.com, it existing for that purpose. Many wikis already exist, loaded with vast amounts of information fans find interesting, and enjoy editing.  Star Wars Wookieepedia, Marvel comic books, Gantz, Forgotten Realms novels, and The Simpsons, are good examples of different types of wikis you find over there.   D r e a m Focus  20:44, 17 April 2009 (UTC)


 * Alternative outlets to your right. --Gadget850 (talk) 21:22, 17 April 2009 (UTC)