Wikipedia:Village pump (proposals)/Archive 19
This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214
Automatic addition of merge template on sister article
When a person adds a merge template to an article, A to be merged with article B (i.e. {{merge|B}}), then automatic addition of the corresponding template to the sister article, B ({{merge|A}}) would save the editor time and effort. You wont need to notify anyone of the change, 'cause they'll notice it themselves when they go to the second article. A {{mergeto|B}} template will obviously invoke a {{mergefrom|A}} on the sister article. ----Seans Potato Business 22:46, 2 February 2008 (UTC)
- Is this something too cumbersome for editors to do? I don't see the need for this, although I could write a user script, if you want. GracenotesT § 00:01, 3 February 2008 (UTC)
- The idea is to automate more tasks - how can there be no need to free up editor's time? If it's something a computer can do, I figure a computer should do it instead of a human editor. It's a bother to do it manually, especially for slower internet connections, since it involves three extra (hopefully unnecessary) page loads. If you write a script, can it be implemented throughout the project? ----Seans Potato Business 00:08, 3 February 2008 (UTC)
- Increased automation is usually good, so long as we don't develop a disdain for doing tasks simply because they can be automated. (This is usually accompanied with thinking that the converse is true – that bots can do nothing but the simplest tasks, since they're sub-human, etc.) The script would be implemented for anyone who installs it in their monobook.js, and would still load pages, but in the background. GracenotesT § 00:28, 3 February 2008 (UTC)
- In order for people to install it, they'd have to know about it. In order for everyone to benefit, it should be automatic for everyone. People shouldn't be penalised for not knowing about it. Imagine if someone else had made this suggestion instead of me, and you'd written them a monobook script and that was that. I'd still be doing it the old fashioned way like a chump. I don't see the reason that anyone would object to this proposal - it helps everyone that uses at least one merge template and I don't think it hurts anyone. I just need to gather consensus support so I can take it to the bug report facility (assuming it's not something that can be implemented without their involvement (since the feature needs to be called immediately upon insertion of the template, in order for the second template to have already been inserted before the user gets to that page). --Seans Potato Business 00:41, 3 February 2008 (UTC)
- It's not something that would be built into MediaWiki software, since to the parser, merge tags have no semantic meaning beyond a set of curly braces transcluding a template called Template:Merge. WP:US exists so that anyone wanting user scripts can get what they want, or ask; if one doesn't know the proper place to look, it's too bad, but there's not anything we can do about it. Giving the script to everyone would produce the same kind of misuse and abuse that giving the toolbar to everyone has produced. Adding two merge tags is by no means a penalty, in my opinion – it's the normal process for editing. GracenotesT § 01:05, 3 February 2008 (UTC)
- "Normal" isn't necessary a good thing. It's the "old way" of editing, that isn't streamlined. I don't see how it would be open to abuse... vandals don't usually bother suggesting merges do they? And I don't think they'd be encouraged to try it... If this isn't done automatically then it isn't worth doing at all, since no-one would know that the thing existed and probably don't suggest merges frequently enough to make it worth the hassle of figuring out how to work the monobook. I think it is owed to Wikipedians, to make it as easy as possible to perform the tasks that they've volunteered to do. ----Seans Potato Business 02:27, 3 February 2008 (UTC)
- I'm not as concerned about abuse so much as misuse; as I mentioned, the same happens with the toolbar all the time (e.g. [1]). If someone clicks a "merge" button with knowing what it does, that's a problem. That a user runs software that adds the text {{merge|A}} to article B does not imply that the user wants to suggest merging A into B; he/she could just be testing. Merging is a high-level editing procedure, and it's worked for the past four years with users adding templates. GracenotesT § 02:44, 3 February 2008 (UTC)
- I see. I had not considered the possibility of someone testing the merge template. Would it not be possible to detect also the removal of the merge template, so then it could be automatically removed from the sister article? It's worked for four years, but that doesn't mean it can't be improved. ----Seans Potato Business 10:32, 3 February 2008 (UTC)
- I'm not as concerned about abuse so much as misuse; as I mentioned, the same happens with the toolbar all the time (e.g. [1]). If someone clicks a "merge" button with knowing what it does, that's a problem. That a user runs software that adds the text {{merge|A}} to article B does not imply that the user wants to suggest merging A into B; he/she could just be testing. Merging is a high-level editing procedure, and it's worked for the past four years with users adding templates. GracenotesT § 02:44, 3 February 2008 (UTC)
- "Normal" isn't necessary a good thing. It's the "old way" of editing, that isn't streamlined. I don't see how it would be open to abuse... vandals don't usually bother suggesting merges do they? And I don't think they'd be encouraged to try it... If this isn't done automatically then it isn't worth doing at all, since no-one would know that the thing existed and probably don't suggest merges frequently enough to make it worth the hassle of figuring out how to work the monobook. I think it is owed to Wikipedians, to make it as easy as possible to perform the tasks that they've volunteered to do. ----Seans Potato Business 02:27, 3 February 2008 (UTC)
- It's not something that would be built into MediaWiki software, since to the parser, merge tags have no semantic meaning beyond a set of curly braces transcluding a template called Template:Merge. WP:US exists so that anyone wanting user scripts can get what they want, or ask; if one doesn't know the proper place to look, it's too bad, but there's not anything we can do about it. Giving the script to everyone would produce the same kind of misuse and abuse that giving the toolbar to everyone has produced. Adding two merge tags is by no means a penalty, in my opinion – it's the normal process for editing. GracenotesT § 01:05, 3 February 2008 (UTC)
- In order for people to install it, they'd have to know about it. In order for everyone to benefit, it should be automatic for everyone. People shouldn't be penalised for not knowing about it. Imagine if someone else had made this suggestion instead of me, and you'd written them a monobook script and that was that. I'd still be doing it the old fashioned way like a chump. I don't see the reason that anyone would object to this proposal - it helps everyone that uses at least one merge template and I don't think it hurts anyone. I just need to gather consensus support so I can take it to the bug report facility (assuming it's not something that can be implemented without their involvement (since the feature needs to be called immediately upon insertion of the template, in order for the second template to have already been inserted before the user gets to that page). --Seans Potato Business 00:41, 3 February 2008 (UTC)
- Increased automation is usually good, so long as we don't develop a disdain for doing tasks simply because they can be automated. (This is usually accompanied with thinking that the converse is true – that bots can do nothing but the simplest tasks, since they're sub-human, etc.) The script would be implemented for anyone who installs it in their monobook.js, and would still load pages, but in the background. GracenotesT § 00:28, 3 February 2008 (UTC)
- The idea is to automate more tasks - how can there be no need to free up editor's time? If it's something a computer can do, I figure a computer should do it instead of a human editor. It's a bother to do it manually, especially for slower internet connections, since it involves three extra (hopefully unnecessary) page loads. If you write a script, can it be implemented throughout the project? ----Seans Potato Business 00:08, 3 February 2008 (UTC)
The 'save changes' button
Please redirect me to Bugzilla if this does require a change in software but could we please have the 'Save changes' button no longer being the default (perhaps the 'Show preview' button would be a better default). I request this because when attempting to use the shift and/or delete keys I sometimes accidentally hit the return key which automatically saves the page with the typos etc I was trying to correct. I realise that this is due to my own clumsiness but it would make editing just that little bit easier. It would also make edit histories slightly less of a mess because I would not have to make another change to correct my own mistakes in the main article or in the edit summary. Any thoughts? --Hydraton31 (talk) 04:34, 3 February 2008 (UTC)
- Some language versions of Wikipedia do force preview before you can save, so it is built into the software - just not turned on in the English Wikipedia. A workaround is to enable "Prompt me when entering a blank edit summary" in the Editing section of "Preferences".-gadfium 07:42, 3 February 2008 (UTC)
- It would be a change to MediaWiki:Common.js. However, at the moment, I don't believe it has consensus. fr.wiki requires previewing for anonymous users only.... --MZMcBride (talk) 07:54, 3 February 2008 (UTC)
- I don't understand. If you hit the return key while the cursor is in the edit text box, this should insert a line-break and not initiate the saving of the page. --Seans Potato Business 13:02, 3 February 2008 (UTC)
- It happens when you are in the "edit summary" box. Is has happened several times to me too. Very annoying. In that case the setting "Prompt me when entering a blank edit summary" does not help either. −Woodstone (talk) 18:26, 3 February 2008 (UTC)
Here's a simple user script that asks "Are you sure you want to submit?" when you submit the form:
addOnloadHook(function() {
var editform = document.forms["editform"];
if (!editform) return;
editform.onsubmit = function() {
return confirm("Save changes to " + decodeURIComponent(wgPageName.replace(/_/g, " ")) + "?");
}
});
If accidentally hitting return in the edit summary box is the main problem, or this one gets too annoying, I could write another script that causes hitting the key to do nothing when a form element is focused. (I personally find form submission from the edit summary box useful...) GracenotesT § 20:54, 3 February 2008 (UTC)
- Is there any way to ensure that the save page button will only be activated by a mouse click. Personally I rarely use the return key to save page changes anyway but this may just be me. --89.242.143.22 (talk) 06:02, 4 February 2008 (UTC)
Sorry, forgot to login! --Hydraton31 (talk) 06:03, 4 February 2008 (UTC)
April Fools Day
Every year google has an april fool's hoax (see Google's hoaxes ). Should wikipedia have something like this? It would be a great publicity stunt (like the google hoaxes) and increase the circulation of the other lesser know Wikimedia brands as well as livening up the image of wikipedia (as a dull lifeless encyclopedia).... and before anyone bags the idea, consider the advantages over the disadvantages Talk to symode09's or How's my driving? 12:15, 2 February 2008 (UTC)
- We normally have a strange topic on the main page - last year was George Washington (inventor). Will (talk) 12:21, 2 February 2008 (UTC)
- I don't mean a strange topic, I mean something big (ie. a notice saying wikipedia has been taken over by Microsoft and will be called wikiencarta or something! Talk to symode09's or How's my driving? 12:31, 2 February 2008 (UTC) —Preceding unsigned comment added by Symode09 (talk • contribs)
- Been there, done that. Sam Korn (smoddy) 13:03, 2 February 2008 (UTC)
- It is usually not a good trick when it says "THIS IS A JOKE" at the top of the page - and I am saying we should add something to the header for everyone to see :) Talk to symode09's or How's my driving? 14:53, 2 February 2008 (UTC) —Preceding unsigned comment added by Symode09 (talk • contribs)
- On April 1 2005, it didn't have the banner. Personally, I would also remove it now as well... Sam Korn (smoddy) 16:11, 2 February 2008 (UTC)
- It is usually not a good trick when it says "THIS IS A JOKE" at the top of the page - and I am saying we should add something to the header for everyone to see :) Talk to symode09's or How's my driving? 14:53, 2 February 2008 (UTC) —Preceding unsigned comment added by Symode09 (talk • contribs)
- Been there, done that. Sam Korn (smoddy) 13:03, 2 February 2008 (UTC)
- I don't mean a strange topic, I mean something big (ie. a notice saying wikipedia has been taken over by Microsoft and will be called wikiencarta or something! Talk to symode09's or How's my driving? 12:31, 2 February 2008 (UTC) —Preceding unsigned comment added by Symode09 (talk • contribs)
- For 2007, Wikipedia:April Fool's Main Page was used to create a collaborative Main Page where each of the main panels - Today's Featured Article, In The News, Did You Know, Selected Anniversaries, and Today's Featured Picture, were all unbelievable but true. I think that's a good model to aim for this year, but you'd better get started on it now to have it ready in time. Confusing Manifestation(Say hi!) 04:16, 4 February 2008 (UTC)
- Oops, looks like they're already working on it, but you're free to join in! Confusing Manifestation(Say hi!) 04:17, 4 February 2008 (UTC)
- Join in... where?Wjhonson (talk) 05:17, 4 February 2008 (UTC)
- Oops, looks like they're already working on it, but you're free to join in! Confusing Manifestation(Say hi!) 04:17, 4 February 2008 (UTC)
Compartmentalization (article title) vs. Compartmentation (correct for US usage)
Apologies if this isn't the right place for article title questions--feel free to redirect me.
With several other editors, I've been working on a cleanup of the various articles about intelligence (i.e., military or national). There is an unsourced stub article Compartmentalization. When I try to search on "Compartmentation", I get redirected to a disambiguation page on compartmentalization, which has a link to intelligence use of the term. It is mentioned that "compartmentalisation" is the UK usage.
Unfortunately, the US usage is "compartmented" or "compartmentation". This is mentioned correctly in Sensitive Compartmented Information Facility, and in the Classified information in the United States articles.
My proposal would be to rename the "compartmentalization" article to "compartmentation". I'm willing to take that article in hand, source the term, and add examples, and/or creating an article on "Sensitive Compartmented Information". I might also create an article on "Special Access Program", which is the military equivalent of the "SCI" term specific to intelligence.
The disambiguation page on compartmentalization would also need to change the intelligence-related link to compartmentation. I can check with a UK editor on what they use as the term.
How should I proceed? Howard C. Berkowitz (talk) 19:09, 2 February 2008 (UTC)
- Go ahead and be bold. What's critical is to have only one disambiguation page, and only one article. In particular, I'd recommend that there not be a separate article on "Special Access Programs"; articles at Wikipedia are about topics, not names. We're not a dictionary; better to have one longer article than two shorter ones. -- John Broughton (♫♫) 21:51, 3 February 2008 (UTC)
- Help me understand your thinking. At this point, (unless I'm missing a spelling) there are no separate articles on "Sensitive Compartmented Information" and "Special Access Program". There is an article on "Sensitive Compartmented Information Facility". The two categories are mentioned briefly in "Classified Information in the US", but I'm not sure it would occur to a new user to look there. I could see redirects for the two terms going to that article, and conceivably merging the SCIF material there.
- I'm not immediately sure how to straighten out the redirects of compartmentation to compartmentalization -- I'll try, but I don't want to break anything by doing so. Far too many programmers I have known had their last professional words be "relax, this is easy"! Howard C. Berkowitz (talk) 22:08, 3 February 2008 (UTC)
- I am confused as to exactly what it is you are proposing to do with the compartmentalization article? Do you mean Compartmentalization (intelligence) specifically, or the current definition/disambiguation page at compartmentalization? LinaMishima (talk) 17:36, 4 February 2008 (UTC)
Vandal color signal
My proposal relates to the treatment of vandals. I do my share of recent change patrol and discovered, that our treatment of vandals is quite ineffective. First we warn them. Then, if it's a IP address, we usually don't do anything, because this could affect innocent users too. If it's a registered editor, we delete his account. That's something, which hurts only real editors with many contributions. As long as they don't go crazy, these editors usually don't vandalize wikipedia. The typical vandal is not interested in his account. For him it's easier to create a new account, than it was for us, to delete the old one. We only lose the trace of the vandal and he can begin anew.
Therefore my proposal: Is there a possibility to give the administrators a tool, which changes the color of dangerous IP addresses and/or editors in the article history and the recent changes page, by adding something to the userpage or page of the ID. Today, all names of users with user pages, which were not edited, appear in red. Dangerous IP adresses or users would appear in yellow, brown or another color. To be able to discover them, would make it easier to fight them. I think, that's more effective than to delete their acounts, just to have them create a new, unknown account, one minute later.--Thw1309 (talk) 20:33, 2 February 2008 (UTC)
- Sounds like a good idea if it could be done. I doubt most vandals would notice the change of colour of their username, and even less would know what it meant. ----Seans Potato Business 23:26, 2 February 2008 (UTC)
- Try reverting vandalism using irc://irc.freenode.net/cvn-wp-en, which uses its own blacklist system. Making an internal MediaWiki blacklist would be controversial, and some overly enthusiastic admins could drive away potential editors. An external blacklist system, however, is entirely doable. The software that runs the #cvn-wp-en IRC channel automatically blacklists blocked users, greylists those reverted by admins and whitelisted users, and can store reasons for inclusion in those groups. In short, it's a system that has worked for nearly 2 years, and seems to do what you describe, but is external to MediaWiki. GracenotesT § 23:38, 2 February 2008 (UTC)
- When I click on that link, Firefox tells me it doesn't know how to deal with the IRC protocol. People shouldn't have to download special software to identify vandals. Besides, it doesn't address the issue; the issue is vandals creating new accounts from which to vandalise. What's the point of a blacklist of blocked users? Blocked users can't vandalise by definition. You suggested that admins might drive away potential editors, but I don't think that turning someone's username orange and paying super-close attention to their edits is going to drive any more people away than blocking/deleting their account. Besides, most new editors are unlikely to persistently vandalise as part of their "getting to know wikipedia" process. --Seans Potato Business 00:14, 3 February 2008 (UTC)
- Simply put, you're talking about a Scarlet Letter system. Or worse. (Must... not... trigger Godwin!) We aren't going to antagonize users with a system like this. Not to mention it being ripe for abuse. If you want to do it for yourself, I'm sure someone can come up with a JavaScript option. But I don't see any way this could gain consensus on Wikipedia itself. We do not punish users for vandalism, we block persistent vandals to protect the encyclopedia. -- Kesh (talk) 21:26, 3 February 2008 (UTC)
- No, I'm not talking about a Scarlet Letter system, because I don't want to punish someone, but to protect the encyclopedia. It is useless to block persistent vandals, because they are able to create a new account. By the way, the criminological effect of a Scarlet Letter system bases on the permanent feeling of being identified as a criminal (or/and sinner), creating a permanent feeling of shame. This does not work in an anonymous system. The Scarlet Letter does not create any effect, as long as the bearer is allowed to wear a mask too. So, for the vandal, such a system is a minor limitation of his rights, compared to a complete block, and to us, it is a better chance to fight vandalism.--Thw1309 (talk) 08:15, 4 February 2008 (UTC)
- Simply put, you're talking about a Scarlet Letter system. Or worse. (Must... not... trigger Godwin!) We aren't going to antagonize users with a system like this. Not to mention it being ripe for abuse. If you want to do it for yourself, I'm sure someone can come up with a JavaScript option. But I don't see any way this could gain consensus on Wikipedia itself. We do not punish users for vandalism, we block persistent vandals to protect the encyclopedia. -- Kesh (talk) 21:26, 3 February 2008 (UTC)
- When I click on that link, Firefox tells me it doesn't know how to deal with the IRC protocol. People shouldn't have to download special software to identify vandals. Besides, it doesn't address the issue; the issue is vandals creating new accounts from which to vandalise. What's the point of a blacklist of blocked users? Blocked users can't vandalise by definition. You suggested that admins might drive away potential editors, but I don't think that turning someone's username orange and paying super-close attention to their edits is going to drive any more people away than blocking/deleting their account. Besides, most new editors are unlikely to persistently vandalise as part of their "getting to know wikipedia" process. --Seans Potato Business 00:14, 3 February 2008 (UTC)
Real names
Some commercial sites like amazon note whether the name used by a user is their "real name" or not : it is checked with the name on their credit card.
Wikipedia allows people to use any name they wish, which is fine. But some people would like to use their real name and prove it is their real name (like myself).
Surely it would be possible on wikipedia to set up some mechanism for doing this.
I personally think that except for a very small number of situations where it is not safe to use your real name, real names are much better and encourage honesty and directness.
John C Mullen 90.11.74.49 (talk) 08:56, 3 February 2008 (UTC) (real name!)
- The key issue there is "prove it is their real name." There's very few ways to do this aside from entering a credit card number, which is really against what Wikipedia stands for.
- Further, real names do nothing to "encourage honesty and directness." Try reading some blogs on the Evolution vs. Intelligent Design debates, for instance. Even though these people use their real names, often many of these individuals (on both sides) resort to ad-homs, indirect insults and other rude acts. And don't even get me started on politics!
- Personally, I use a pseudonym because I've been harassed under my real name before. You'd be surprised how much information people can find about you with little effort, and twist around to use against you. -- Kesh (talk) 21:33, 3 February 2008 (UTC)
- I wouldn't mind some optional way to verify identity, outside of proving it personally to the wikimedia foundation. Obviously Wikipedia:Admins willing to make difficult blocks and the idea of registering to hide one's IP are built on the basis of anonymity. But, for those whose users names make it blatantly easy to find them (mine for example, Jimbo, David Gerard, etc), it really wouldn't make a difference. Sometimes its nice to be able to refer to a person by their actual name, as opposed to some unpronouncable usernae. MBisanz talk 02:55, 4 February 2008 (UTC)
It is possible in some circumstances to identify yourself to the foundation. This is only done when necessary. You can also use crypto-keys to self-identify (though I haven't done so yet). I wonder if we could get pubkey login for wikipedia. :-) --Kim Bruning (talk) 03:11, 4 February 2008 (UTC)
We already have confirmation of real life identity for users with CheckUser access and Arbitration Committee members. This is for legal reasons and I understand it's necessary but the process is impossible to implement on a larger scale.
I wouldn't mind any real identity confirmation process for regular users and administrators, as long as it is strictly voluntary. Puchiko (Talk-email) 17:10, 4 February 2008 (UTC)
Encrypted/https access to Wikipedia
I apologize if this has been discussed previously; I haven't been able to find any comments on this so far.
I know this is a big request, but I suggest providing access to Wikipedia over an encrypted/https connection. This would allow users to explore and contribute to Wikipedia without concern about eavesdropping by overly-curious governments, ISPs, neighbors, etc. (And, I'm hopeful that it would set a precedent. I'd like to eventually see pervasive encryption of even the most innocuous network traffic.) 24.6.86.200 (talk) 08:40, 4 February 2008 (UTC)
- See https://meta.wikimedia.org/wiki/Talk:Don%27t_leave_your_fly_open?oldid=588199#secure.wikimedia.org. I've looked for info on this service in the past and failed to find anything at all beyond the address. HTH --Jeremyb (talk) 09:03, 4 February 2008 (UTC)
- Yes, it's not well advertised, but it is certainly there, and (at risk of being slapped with a trout by the devs) I use it exclusively. See https://secure.wikimedia.org/wikipedia/en/wiki/Main_Page. Problem is it puts a much higher load on the servers, and is much slower. • Anakin (talk) 18:03, 4 February 2008 (UTC)
What if Wikipedia were to allow original research (if tightly defined)?
Wikipedia currently has a policy against Wikipedia allowing original research but what if an academic knows of original research which is currently at "in press" statement - would this count as "original research"? It has long been my view that what ever the faults of Wikpedia may be, it surely has the merit of being the world's most up-to-date encyclopaedia. To ensure up-to-date coverage of academic topics, how about a policy where academics can cite articles for publication which are not yet published in print form, but which are currently "in press", even if these are articles which the academics themselves have written? ACEOREVIVED (talk) 20:34, 25 January 2008 (UTC)
- If the material is not available to the general public (having to pay a fee is allowable, as long as everyone may do this), then it should not be used as a source, as no-one will be able to verify the information. Furthermore, as I understand it, 'in press' could mean undergoing peer review, which may decide that the article is not fit for publishing at this time. LinaMishima (talk) 21:07, 25 January 2008 (UTC)
- Unfortunately, there's no way to readily verify the contents of 'in press' materials. Wikipedia can cope with waiting a few months for the article to be available through normal channels. (Note that this does not rule out the use of materials from journals that do 'advance online publication'; there's no need to wait for paper copies to be available if the documents are officially available from the journal website.)
- Taken to an ugly extreme, we could face a situation where Dr. Joe Bloggs decides that his pet theory of the universe should be in Wikipedia, so he adds it to cosmology with an 'in-press' citation. We have no way to independently confirm that Nature really has accepted his paper, or even that any peer review has taken place.
- From the standpoint of the paper's authors, it may not be wise to 'publish' material ahead of its appearance in a journal. Many journals get very upset if you distribute (and republish) preprints or articles prior to the article's appearance in print. TenOfAllTrades(talk) 17:37, 28 January 2008 (UTC)
- We are not trying to create "the world's most up-to-date encyclopaedia"; if we're viewed that way, it's nice; but we aren't trying to meet a deadline here. We'd rather be reliable and verifiable than "up to date" and neither. --Orange Mike | Talk 17:46, 28 January 2008 (UTC)
- I think there is an argument to loosen up WP:OR. As I read it, it came about precisely just because of the scenario present above, to stop crank science.
- I think it is a good policy within the "hard sciences", i.e. physics, biology, engineering etc but I think it fails in the "soft sciences", e.g. sociology, anthropology, even perhaps psychology (where it tetters off toward parapsychology). Why?
- Well, firstly, let's face it there is a big difference between a physics or maths paper and a sociology or anthropology paper. In the former, the sums have to add up; in the latter, its far more just someone opinion that might have gone straight from school, straight to university and straight into research. The peer review system cannot be empirical or even "evidence based".
- So then we end up limiting the Wikipedia to the limitation set by "establishmentary academia" and any one that argues that "establishmentary academia" covers the entire scope and sum of human knowledge or IS NOT governed by funding instituted fads, fashion and censorship is a damned dishonest fool, e.g. there was a great 'Sociology of science paper written on Cold Fusion. Ditto, limiting one's self merely to the production of the academic peer review system, excludes all the science that does not pass that way, e.g. industrial, military and unfashionable science, for whatever reason, e.g. there was no general awareness of Operation Suntan - the CL-400 hydrogen power jet between 1954 and 1976, because it was a Skunk Works project and it exits only in one book of Nasa history, if you ask any engineer about hydrogen powered jets, they will know nothing of it because it is was never taught in tech school. it still does not exist on the topic page despite burning $250 million back then.
- Then we look at the cultural chauvinism inherent in a white, male, primarily middle-classed based (and pro-America) educational system and its product ... the Wikipedia. The moments topics start heading off towards sub-cultural, racial or minorities issue ... topics and "references" dry up because they just are not done. "Peer review" is just fervent in, say, sub-cultural gang environments ("who d you know?"), it just isn't done across bi-annual peer review journals.
- There is also another development that one cannot over look here, as the quality and commitment to the Wikipedia improves, increases and broaden; it is, of course, becoming its own peer review system (albeit an unaccountable, unqualified in places and somewhat skewed one). All the same, the Royal Academy has been accused of worse and got better as time in its own time. it is "getting real". Perhaps we should move forward to a point where the democratization of the peer review system, in place of the obesience to established hierarchies extends further than just pushing angry electrons back and forward at each other in edit-wars. --Lucyintheskywithdada (talk) 09:53, 29 January 2008 (UTC)
Thank you for raising these points in response to my earlier suggestion. I am now happy to recant - in particular, TenofAllTrades, I felt, had a good point about journal editors getting upset if material is too widely distributed ahead of distribution! The only point I would challenge in the all above comments is the attempt to belittle social sciences (I think that some sociology academics might be rather annoyed by suggestions that their papers are less than "academic"); however, I do wish to offer thanks to all who responded. My final decision - let us just stay as we are! ACEOREVIVED (talk) 20:13, 29 January 2008 (UTC)
Very early on, IIRC some scientists (experts in their field!) would add clues to new stuff they were working on to wikipedia. It's an old trick, to establish that you were the first person to work on/discover something. Due to NOR being expanded way beyond its original parameters (where it was only there to stop cranks), this kind of thing is no longer possible, and at times we may need to wait years before the same information is added. --Kim Bruning (talk) 17:42, 5 February 2008 (UTC)
Template for requesting a translation of (a section of) an article from English into another language
I have recently come across an article (Sadaqah) that I feel would benefit with having a translation of its title into Arabic at the start of the article (rather like articles like Zakat). However, I did not manage to find any appropriate template for this, and was forced to create Wikipedia:Translation/Sadaqah, although that is not quite what I want.
I therefore propose that a template be created for when people want specific sections or words in articles in the English Wikipedia to be translated into other languages. —Preceding unsigned comment added by It Is Me Here (talk • contribs) 09:27, 1 February 2008 (UTC)
- I think there's a WikiProject for translation tasks, or there might be one for your target language. Hunt them down and see what tools, such as templates, they have. Or just ask in their Talk page. -- SEWilco (talk) 16:12, 1 February 2008 (UTC)
- I searched existing templates already and haven't been able to find anything; what is the link for this WikiProject's talk page? —Preceding unsigned comment added by It Is Me Here (talk • contribs) 17:32, 1 February 2008 (UTC)
- Please see Wikipedia:Translation. -- Wavelength (talk) 21:36, 1 February 2008 (UTC)
- I searched existing templates already and haven't been able to find anything; what is the link for this WikiProject's talk page? —Preceding unsigned comment added by It Is Me Here (talk • contribs) 17:32, 1 February 2008 (UTC)
- OK, I'm really confused now. It says to use the "language links at the top or side of this page" for translations from English into another language, and I can't see any apart from the usual
- "Languages:
- العربية
- Беларуская
- Deutsch
- Ελληνικά
- Español
- فارسی
- Français
- [etc.]"
- "Languages:
- However, I can't submit a request on http://ar.wikipedia.org as I don't actually know Arabic; I just want someone to translate that one word on the Sadaqah page on http://wiki.riteme.site.It Is Me Here (talk) 12:01, 2 February 2008 (UTC)
- You can look for a Wikipedian who speaks Arabic, at Category:User_ar. -- Wavelength (talk) 00:00, 5 February 2008 (UTC)
- However, I can't submit a request on http://ar.wikipedia.org as I don't actually know Arabic; I just want someone to translate that one word on the Sadaqah page on http://wiki.riteme.site.It Is Me Here (talk) 12:01, 2 February 2008 (UTC)
- And there are other useful links at WP:EIW#Transl. -- John Broughton (♫♫) 00:06, 6 February 2008 (UTC)
Empty sections
I haven't fully read through Help:Sections, but I don't think it says anything on this matter. Should we have any recommendations on empty sections? I think these look rather unprofessional, and generally keep them within hidden comment tags myself. This also applies to sections which aren't empty per se, but have only a 'this section is a stub' or 'this article cites no sources' tag. It's very 'scaffoldy' and I think we should avoid these. However, I have no idea whether others will agree on this. I would bring it up on the respective page, but there won't be any replies, and it's one of those meta crossover pages where I have no idea which talk page to use anyway. Richard001 (talk) 00:19, 4 February 2008 (UTC)
- Scaffoldy is good. It indicates where you still need to add stuff. :-) --Kim Bruning (talk) 02:25, 4 February 2008 (UTC)
- It is amateurish and unnecessarily messy, and I have always removed them on sight. I hope that all editors are bright enough not to need what amounts to the equivalent of a sign that states "put more text here". If a page is in need of expansion, it can be tagged as such if absolutely necessary. Adrian M. H. 03:21, 4 February 2008 (UTC)
- Oh, that's not good. Never remove things like that, only expand. Otherwise people won't know that the article "isn't finished yet". Some people also remove redlinks for similar reasons. That is equally unwise. Wikipedia is a wiki, and these kinds of things help show where we are still weak and need improvement. All you are doing by tidying up is giving a false sense of accuracy, where in fact none exists. --Kim Bruning (talk) 03:39, 4 February 2008 (UTC)
- I think empty sections clutter the page. If you want to indicate the need and/or plans for new sections, use the talk page.--Patrick (talk) 11:05, 4 February 2008 (UTC)
I'm just old fashioned, see:
http://nostalgia.wikipedia.org/wiki/Rules_to_consider
specifically:
- Always leave something undone
- Make omissions explicit
I think I still agree with the reasoning presented there. --Kim Bruning (talk) 17:36, 5 February 2008 (UTC)
- Redlinks are valuable. On the other hand, empty "See also" and "References" sections, for example, are pointless. Nor, in a stub bio, do I see a point in setting up a half-dozen sections with little or no content - it just makes the article difficult to read.
- If in fact an article needs information that isn't obviously missing, I suggest putting a note on the article talk page.
- What Wikipedia doesn't need is someone who spends huge amounts of time adding empty section headings, thinking that this is more useful than actually adding real content. -- John Broughton (♫♫) 23:53, 5 February 2008 (UTC)
search box is too low
Location of search box: left margin is fine, but it should be placed higher, more towards the top of the page. —Preceding unsigned comment added by 167.135.37.84 (talk) 19:36, 5 February 2008 (UTC)
- Agree; the search box is most useful (and obvious) if it's at the very top of the quickbar (left column), just below the logo. -- John Broughton (♫♫) 23:39, 5 February 2008 (UTC)
- I'd have to see a preview, but I'm really used to it where it is and it's perfectly fine to me. Reywas92Talk 02:39, 6 February 2008 (UTC)
New Archive Box
I have created a new archive box to replace the current {{archives}}, {{archive box}}, and {{archive box collapsible}} templates. It incorporates all of the necessary parameters. Could I please get some comments/suggestions on it. And how would I go about implementing it? Thanks, MrKIA11 (talk) 03:18, 6 February 2008 (UTC)
Proposal to Implement a Software System for Currencies, Conversions, etc.
There exist on Wikipedia a huge number of figures converted from some unit to another. When the ratio used for this calculation changes, the numbers given become less accurate. A system whereby a measure could be given a unit (e.g. U.S. Dollars) and a date (1988) could be added to the Wikipedia software that would automatically update this number for inflation at some regular time interval. Another example of where this could be useful is in the price of a commodity such as gold. On pages where dollar amounts for gold are given, these sums could be dynamic, changed by the software to reflect the current market value of the holding. An additional use for an arrangement such as this could be giving figures in Euros (or any other currency) their current equivalent dollar value, or vice versa. The necessary information is available from a huge number of websites, but I don't know what their use policies are. —Preceding unsigned comment added by Reb42 (talk • contribs) 21:53, 31 January 2008 (UTC)
- It could be done with a set of templates, and not be too difficult either. ParserFunctions make the MediaWiki template syntax pretty powerful. E.g., if we had a Template:Inflation, it could be used like this:
{{inflation|USD|1988|99.95}}
- which would convert $99.95 from it's worth in 1988 to its current equivalent. Or to save a lot of {{#switch:}} commands and bloated templates perhaps it would be better to use separate inflation templates for each currency. A search reveals Template:USD_inflation, but it just makes a web link to a site with inflation figures, not the same thing. Also, information can't be copyrighted, so obtaining currency and inflation conversion figures should not be a problem. • Anakin (talk) 16:02, 1 February 2008 (UTC)
- It may be encyclopedic to inform the reader of the present value of old monetary amounts, but it also is encyclopedic to inform the reader of the exact amount which was used at the time. The exact amount at the time of a transaction does not change. There are two issues: 1. How should both original and converted amounts be shown? and 2. Technically, how can Wikipedia convert across monetary units and time?. -- SEWilco (talk) 16:11, 1 February 2008 (UTC)
- I can answer the first question. Just write it out fully like:
- "The takeover was worth $300 million (worth $1,298 million in today's money)."
- Something like that anyway. I'm not sure about the second question; would it work to use an inflation template, passing the output into a currency conversion template? Or is monetary conversion more complicated than that? • Anakin (talk) 16:26, 1 February 2008 (UTC)
- Just experimenting, I implemented a test template in my sandbox. E.g., ${{User:Anakin101/inflation usd|1988|99.95|round=2}} generates: $175.21. Automatic inflation conversion is technically possible. Whether it's a good idea or not is another matter. • Anakin (talk) 16:48, 1 February 2008 (UTC)
- Templates are only updated when a page is edited. Pages that lie fallow would become inaccurate (to say nothing of forks and print versions). It's always necessary to include a date, although that date may be updated as well with each edit. Dcoetzee 20:30, 6 February 2008 (UTC)
Suggest removal of 'please fix double redirects' message after page move.
After moving a page, the following message is presented:
Please check whether this move has created any double redirects, and fix them as necessary. For this purpose, you can use the following text: #REDIRECT [[Eight-cell stage]]''
However bots exists whose speciality is checking the list of double redirects and correcting them automatically, less than half an hour after their creation.
Humans have a special ability to think in a way that bots cannot, and their time should not be wasted on this pointless, tedious, demoralising work that is practically designed for a piece of mindless computer code. The time of a human editor is better spent on things that a bot cannot do, and sparing it in this way, will free the time for more productive purposes and boost the morale of all. ----Seans Potato Business 14:44, 31 January 2008 (UTC)
- Why is this issue being ignored? It's a simple way to stop people from wasting their time, so please support it! ----Seans Potato Business 00:42, 3 February 2008 (UTC)
- I changed it: MediaWiki:Movepage-moved.--Patrick (talk) 11:52, 3 February 2008 (UTC)
- My hero!! Thanks :) ----Seans Potato Business 13:02, 3 February 2008 (UTC)
- Has the frequency of bot fixing of double redirects changed? The MediaWiki message now says If this move has created any double redirects, they will be fixed automatically within 30 minutes, but I thought that the bots used the page Special:DoubleRedirects, which is only generated every couple of days, to fix double redirects.
- If in fact nothing has changed, then please adjust the message - there are advantages to editors fixing double redirects, though it's not a big deal to let them sit for a couple of days. -- John Broughton (♫♫) 21:43, 3 February 2008 (UTC)
- I changed it to "couple of days".--Patrick (talk) 00:09, 4 February 2008 (UTC)
- How about keeping the former text, but also mentioning that editors need not fix the double redirects if it inconveniences them? "automatically" is a not a good word to use here, in my opinion, since the double-redirect fixing is not part of MediaWiki software, but rather some client software that runs whenever it's needed. Rather than a "couple of days", how about "the next time the bot runs"? There's nothing wrong with editors fixing double redirects themselves, and it is a good thing to feel useful :), so I do support including that as an option. GracenotesT § 03:40, 4 February 2008 (UTC)
- The distinction between MediaWiki software and client software does not seem relevant for a user. Also, probably more people understand "automatically" than "bot". A time indication is useful, otherwise it could be seconds or years. I don't mind adding something about fixing redirects oneself, but even now "They will be fixed automatically within a couple of days" implies that having it done faster requires doing it oneself.--Patrick (talk) 10:59, 4 February 2008 (UTC)
- My suggestion is: include information about how to fix any potential double redirect problems, but also say that a bot (with the link) does it periodically, i.e. every couple of days, and that it's not necessary to fix. What you want to do is shield the user from information, and even distort the inner workings of the automated double-redirect fixing system so as not to bore the user with technical distinctions, which is not beneficial to anyone, in my opinion. A user who reads that a bot fixes the problem may be interested in learning to make a Wikipedia bot. (Hypothetical, of course...) The best way to learn what a double redirect is in the first place is fix one, so I see no harm with saying "here's how to fix it, and if you don't want to it'll be taken care of for you". GracenotesT § 16:38, 4 February 2008 (UTC)
- I rephrased it again.--Patrick (talk) 23:32, 4 February 2008 (UTC)
- Thank you. I may suggest some further wording down the line on the talk page, but that's probably enough editing for now :) Cheers, GracenotesT § 23:49, 4 February 2008 (UTC)
- I agree completely with Gracenotes. I am probably (again) too late, but my opinion is that editors should not be encouraged to just let bots clean up after them. Not only do they miss the chance to gain some very useful experience, but bots lack the judgement necessary in some cases; yesterday I had to retarget WT:I from Richard Evans (British author), which is insane on three different levels. The expansion of bots must be checked. Waltham, The Duke of 12:02, 6 February 2008 (UTC)
- Thank you. I may suggest some further wording down the line on the talk page, but that's probably enough editing for now :) Cheers, GracenotesT § 23:49, 4 February 2008 (UTC)
- I rephrased it again.--Patrick (talk) 23:32, 4 February 2008 (UTC)
- My suggestion is: include information about how to fix any potential double redirect problems, but also say that a bot (with the link) does it periodically, i.e. every couple of days, and that it's not necessary to fix. What you want to do is shield the user from information, and even distort the inner workings of the automated double-redirect fixing system so as not to bore the user with technical distinctions, which is not beneficial to anyone, in my opinion. A user who reads that a bot fixes the problem may be interested in learning to make a Wikipedia bot. (Hypothetical, of course...) The best way to learn what a double redirect is in the first place is fix one, so I see no harm with saying "here's how to fix it, and if you don't want to it'll be taken care of for you". GracenotesT § 16:38, 4 February 2008 (UTC)
- The distinction between MediaWiki software and client software does not seem relevant for a user. Also, probably more people understand "automatically" than "bot". A time indication is useful, otherwise it could be seconds or years. I don't mind adding something about fixing redirects oneself, but even now "They will be fixed automatically within a couple of days" implies that having it done faster requires doing it oneself.--Patrick (talk) 10:59, 4 February 2008 (UTC)
- How about keeping the former text, but also mentioning that editors need not fix the double redirects if it inconveniences them? "automatically" is a not a good word to use here, in my opinion, since the double-redirect fixing is not part of MediaWiki software, but rather some client software that runs whenever it's needed. Rather than a "couple of days", how about "the next time the bot runs"? There's nothing wrong with editors fixing double redirects themselves, and it is a good thing to feel useful :), so I do support including that as an option. GracenotesT § 03:40, 4 February 2008 (UTC)
- I changed it to "couple of days".--Patrick (talk) 00:09, 4 February 2008 (UTC)
- I'm still frustrated that the software doesn't simply follow multiple redirects. There are cases where multiple redirects are useful - for example, where one may wish to split out part of the page later to one of its redirects, not at all an unlikely scenario. Why are we flattening the useful structure of multiple redirects instead of fixing the software to deal with this efficiently? Dcoetzee 20:28, 6 February 2008 (UTC)
- Not following double-redirects is the easiest way to keep the software from getting caught up in infinite redirect loops. --Carnildo (talk) 06:04, 7 February 2008 (UTC)
Bots to edit protected pages
When preforming mindless tasks such as fixing double redirects with a bot, you often encounter pages protected (generally for vandalism). These would have to be dealt with manually and this is quite irritating. And they eventually pile up if left unattended.
I propose the idea that bots be allowed to edit protected pages. Since all bot edits are REQUIRED to be non-controversial this shouldn't be an issue. I am posting this to start a general discussion on the mater.
-- Cat chi? 23:27, 4 February 2008 (UTC)
- Bots make lots of mistakes, and are often approved for things on the theory that if they do make a mistake it's easy enough to revert. Wikidemo (talk) 05:19, 5 February 2008 (UTC)
- I don't think there is any evidence that anything important piles up because bots can't edit fully protected pages. These are few and far between, and fixing double redirects can be done by changing a redirect page (I'd be surprised if more than one or two of these are protected, if any).
- Then there is the technical issue that the software treats bot accounts exactly as if they are human editors, except that some (doing the most mundane tasks) have a bot flag. So the software would have to be changed to treat bots differently - essentially, to give them admin powers. And that, I can pretty much guarantee, is a non-starter. -- John Broughton (♫♫) 23:43, 5 February 2008 (UTC)
- Yes, to edit protected pages there would either have to be a change in how the software treats accounts with a bot flag, or bots would need to be given admin privileges. The only bot I know of with admin powers is User:RedirectCleanupBot, and despite doing a decidedly non-controversial task, its request for adminship was still pretty contentious. jwillbur 02:12, 7 February 2008 (UTC)
A proposal to alter Template:User for interwiki.
I wrote some code which would allow Template:User to be interwikied.
- Jimbo Wales (talk · contribs), English Wikipedia (original)
- Jimbo Wales (talk · contribs), English Wikipedia (with new redundant parameter!)
- Jimbo Wales (talk · contribs), French Wikipedia
- Jimbo Wales (talk · contribs), Japanese Wikipedia
- Jimbo Wales (talk · contribs), Dutch Wikipedia
- Jimbo Wales (talk · contribs), Spanish Wikipedia
- Jimbo Wales (talk · contribs), German Wikipedia
- Jimbo Wales (talk · contribs), Polish Wikipedia
- Jimbo Wales (talk · contribs), Italian Wikipedia
- Jimbo Wales (talk · contribs), Portugese Wikipedia
- Jimbo Wales (talk · contribs), Swedish Wikipedia
Etcetera. It works for all wikis.
Useful, huh?
If you think so, leave a comment at Template talk:User#Altering template-user to allow for Interwiki. ☯ Zenwhat (talk) 08:08, 6 February 2008 (UTC)
Gadget proposals
This has been sitting around for a while, so I thought I'd get this page some attention. Wikipedia:Gadget/proposals has a few gadget proposals (such as the log table and metadata scripts) that have been there for quite a long time with no objections, some support, but not many people commenting. I'm requesting some more input on these proposals or, better yet, for an administrator to simply make them into gadgets.
Please respond at Wikipedia:Gadget/proposals. Pyrospirit (talk · contribs) 00:42, 7 February 2008 (UTC)
Wikimessenger
I think to make conversations easier between people an instant messager should be introduced. Many people would be allowed to contribute to the conversations and also consensus building would be done much more quickly and effectively. Anybody up for a trial run of Wikimessenger? --Hadseys (talk • contribs) 13:37, 28 January 2008 (UTC)
- Hmm... we have some Internet Relay Chat channels. I'm not sure if the Mediawiki software could support an instant messenger, especially since all non-free software (Flash,
Java) can't be used. Puchiko (Talk-email) 13:59, 28 January 2008 (UTC)
- I think we should simply advertise the #wikipedia and #wikipedia-en IRC channels on freenode more widely - it's easy to get on with any of a number of freeware clients (I prefer Colloquy, in general), or in-browser with java.freenode.net (which is freenode's official in-browser way to log in to IRC). Nihiltres{t.l} 14:17, 28 January 2008 (UTC)
- Sorry about that, my information is really outdated.
Anyway, I think that building an instant messenger on Wikipedia itself is infeasible and needless.IRC should cover our instant messaging needs, and we could have other off-wiki places designed for socialisation (Facebook groups etc.) I don't think that this should (or could) be built into the MediaWiki software.
A small improvement could be done to the talk pages, though. Some other Wikipedias have clearer ways of showing who replied to whom on talk pages (look at eo:Diskuto:Ĉefpaĝo or fr:Discuter:Accueil). Puchiko (Talk-email) 18:12, 28 January 2008 (UTC)
- Sorry about that, my information is really outdated.
- We have a jabber chatroom too, but it's hardly ever used. IRC is useful. Martinp23 18:22, 28 January 2008 (UTC)
- The trouble with this idea is that, currently, consensus can be gauged by reading a conversation on a page. With IM, there's less time for reasoned discussion, research and proper consideration of other's ideas. But the real problem is: to assess consensus, we need a 'record of the discussion. The IM applet would have to log all the various discussions going on, which can be fragmented and hard to follow. Not to mention it would dramatically increase the number of pages the server has to handle, and can be easily spammed into infinity. -- Kesh (talk) 20:51, 28 January 2008 (UTC)
- I suppose that, ideally, if a group of people reach a consensus on IRC then they should together at least summarise what they've agreed on somewhere and each sign it, in the interests of keeping the wiki's information "complete". Complete logs of conversations sounds like a recipe for trouble, though. :-) --tiny plastic Grey Knight ⊖ 20:53, 28 January 2008 (UTC)
- Public logging is prohibited, unless you have the permission of all cited persons. I don't think decisions should be made on IRC, because of the reasons Kesh gave. The advantage of talk pages is that people from across time zones can communicate with each other, you just have to wait 12 hours for a reply. Also, interested contributors are likely to have the page on their watchlists, so you know when someone makes a comment related to the page. I think IRC is great for socialisation, helping new Wikipedians, and collaboration. I don't think it's a good place to form consensus though. Puchiko (Talk-email) 10:27, 29 January 2008 (UTC)
- It would be potentially useful to automatically chat with people editing the same page at the same time, to coordinate effort, but in practice I think the rooms for almost all pages would be empty. The "slow-motion conversations" of talk pages work better. Dcoetzee 23:53, 31 January 2008 (UTC)
When possible, real time communications are to be preferred. (see: OODA loop). --Kim Bruning (talk) 23:28, 7 February 2008 (UTC)
Proposal to Form Uniform Policy in Criticizing Issues in "Political Positions of" Articles
Hi, I was wondering how to best handle the certain situations that happen in "Political Positions of" articles for both politicians and commentators such as Politics of Bill O'Reilly and Political Positions of John Edwards. There seem to be criticism articles of people, such as Criticism of Bill O'Reilly, but I wanted a policy defined for when to post a criticism. Again, using Bill O'Reilly as an example, if someone was found criticizing him or his actions it should be mentioned in the "Criticism of" article, but if they had a criticism of his particular policy it should be mentioned in the "Politics of" article.
A criticism of policy would be "so and so believes that Bill O'Reilly's position on immigration does not take into account..." as opposed to a general criticism of either conservative or liberal ideology/positions. If there is a criticism of conservative (or liberal) positions in general, such as "being against pro-choice (or pro-life) is bad because...", then I personally think it should not be included.
Again, just using O'Reilly as an example here. It should be applied to all commentators and politicians both. Of course, all criticism should follow BLP and the editor must still maintain NPOV when citing the criticism. What do you guys think, allow the criticisms or disallow them? Arnabdas (talk) 19:17, 31 January 2008 (UTC)
- My vote is to allow them all. If the criticisms are legitimate to the positions themselves, we should let the reader determine if they are valid or not. We should let the reader in on info if the politician or pundit is hypocritical on an issue or if there are flaws to his or her issue. Arnabdas (talk) 19:39, 7 February 2008 (UTC)
Changing the action of clicking on Random article
When in a portal, clicking on Random article, should return an article within that portal. Eav (talk) 21:47, 1 February 2008 (UTC)
- What do you mean by "an article within that portal"? An article that's linked from the portal, an article in the portal's scope, or some mix of the two? GracenotesT § 21:50, 1 February 2008 (UTC)
I would give my kingdom for "random unpatrolled". The community dynamics would be really useful. (unlikely that 2 people patrol the same page, and a quick way to up your edit count. Who wouldn't use it?) --Kim Bruning (talk) 00:00, 2 February 2008 (UTC) not that I need to up my edit count
- Don't understand. If you're talking about "Show me a random article, not on my watchlist", even having a watchlist of 10,000 articles would still mean less than 1 in 200 of getting a watchlisted article when you click the normal "random article" link. -- John Broughton (♫♫) 00:04, 6 February 2008 (UTC)
- No. Since late last year, all recent edits by untrusted users get flagged as "unpatrolled". A trusted user can then mark those pages as "patrolled" again. Currently there's several ways to check for patrolled pages, but the most useful method (show a random unpatrolled page) is missing so far. (If everyone gets sent to a random unpatrolled edit while patrolling, odds are good that everyone gets sent to *different* unpatrolled edits, leading to much less duplication of effort and/or edit conflicts) --Kim Bruning (talk) 23:25, 7 February 2008 (UTC)