Wikipedia:Village pump (proposals)/Archive 53

Source: Wikipedia, the free encyclopedia.

Pushing IPA and non-English content to Wiktionary

There was a topic that was sort of related to this earlier [1] that dealt with placing the IPA and other word-related "meta-data" content into a template which would conceal the date until a reader asked for it. I wanted to propose 1)actually implemeting that (which I will likely do soon), and 2) somehow pushing the data behind the implementation into Wiktionary.

IPA and other pronunciation meta-data is fundamentally dictionary (lexicographic) data, so pushing the bulk of that information into the "Wiktionary space" seems to make logical sense to me. More importantly though, the need for it, in an "encyclopedia" sense, is important but seems somewhat secondary.

Keep in mind here that I'm not proposing a sudden change, or something that I'm personally unwilling to work in. I'm willing to at least start some development of a template, and to personally do a good amount of data entry in both Wikipedia and Wiktionary. My one concern is that there seems to be an (odd) undercurrent here on Wikipedia against utilizing\leveraging sister WMF projects, so if there is going to be any resistence I'd really rather not start on a project that will be undercut by resistance. Therefore, if there is any criticism to moving IPA data to Wiktionary please speak out here.

I realize that it's hard to evaluate anything that isn't implemented at all, so I plan to at least create a "reference implementation" on a couple of items\articles, probably tomorrow. I will link to them after creation.
V = I * R (talk to Ω) 06:43, 24 September 2009 (UTC)

No criticism, but include {{respell}} support in the new template if you could. --Cybercobra (talk) 06:53, 24 September 2009 (UTC)
Oh yea, I was going to say that I'll definately include all of the ((tl|respell}} functionality. I didn't even know that template existed...
V = I * R (talk to Ω) 19:37, 24 September 2009 (UTC)
While I do find the idea interesting, wouldn't there be a problem in that Wiktionary's inclusion criteria are different from Wikipedia's? We can only implement what you're suggesting if there's a Wiktionary entry for each word in Wikipedia that would have pronunciation. Somehow I doubt that all Wikipedia articles with pronunciation have, or justify, a corresponding Wiktionary page. {{Nihiltres|talk|edits}} 19:11, 24 September 2009 (UTC)
I should say that I don't really know the answer to your question, but just thinking about it... I don't see why that would be an actual problem. I mean, it's not as though we'd be picking random words and generating content for Wiktionary for them where it didn't exist before... Aside from that, if something doesn't have a Wiktionary entry then we could simply not link to it.
Anyway, after thinking about this overnight and checking some things out on Wikitionary itself, I've concluded that my original idea was a bit too ambitious anyway. Since Wiktionary is structured just as loosely as Wikipedia is there's really no reliable means of actually "moving data to Wiktionary". I mean, we could and should copy items such as IPA back and forth between the two, but there's no means to rely on the existence of IPA data appearing in a Wiktionary entry. Maybe we could start creating standard sub-pages there or something (for example wikt:Beijing/IPA for wikt:Beijing), and I've posted a proposal along those lines here: wikt:Wiktionary:Grease pit#Special fields. In the meantime, we could at least link to Wiktionary and implement the collapsable text, as originally proposed.
V = I * R (talk to Ω) 19:36, 24 September 2009 (UTC)
I agree with you in spirit. IPA is meaningless clutter to the vast majority of readers. Gigs (talk) 04:57, 27 September 2009 (UTC)
I'd really hate to lose any IPA and etymology from Wikipedia. I don't think things would get edited enough if one had to fiddle with a different site to do it. Pseudomonas(talk) 12:31, 3 October 2009 (UTC)

new gadget suggestion

I think it would be cool if we had a gadget that was for barn stars. It could just be like friendly, but have the different types available.Accdude92 (talk) (sign) 17:04, 1 October 2009 (UTC)

Hmm. Easy enough to program with Friendly as a template, I'd imagine. --King Öomie 17:07, 1 October 2009 (UTC)
Sounds good to me. Anyone want to create it? Gosox5555 (talk) 12:14, 3 October 2009 (UTC)

To be honest, I think that barnstars shouldn't be given out so liberally/frequently that they need their own gadget. They're supposed to be for relatively "outstanding" contribution; the least you could do to reward that is manually paste a couple of lines of code! ╟─TreasuryTagco-prince─╢ 12:20, 3 October 2009 (UTC)

Yeah, how hard is it to go to
WP:STAR and find the appropriate barnstar?--Unionhawk Talk E-mail Review
12:29, 3 October 2009 (UTC)

Proposal to merge Category:English illustrators with Category:British illustrators

I have found after spending some time looking into predominantly fantasy illustrators' coverage on Wikipedia that many of the Anglo-illustrators are listed as either belonging to the categories English illustrators, British illustrators or even both. The creation of a seperate English category seems to me over-specialized, and after all, England is a part of Britain, as is Wales and Scotland, and something that makes it harder for users interested in the subject to research names and articles, where English illustrators might be omitted from British category and so on. Scot and Welsh illustrators, whilst the article might happily specify their place of origin, also fit neatly into the British cat. It's also perfectly possible that the two cats were originally created entirely independently of each other and without knowledge of the other's existence.
I want to put forward a proposal to merge the two cats together, putting all those listed in English illustrators into the British category page, a simple matter of editing each article page listed in the former category so they point to the latter, and deleting the remianing old cat page.
Does anyone have any feelings on this, or any objections, or know of anywhere else I should put forward the proposal? LSmok3 (talk) 13:45, 3 October 2009 (UTC)
Scratch that, I didn't realise the category structure at the time I made the suggestion, but see now that English illustrators is a subcat of British illustrators, which is itself a subcat of Illustrators by nationality, a subcat of Illustrators. . . Nevermind. LSmok3 (talk) 16:34, 3 October 2009 (UTC)

Marketing strategy - involve parents through their children

I was just thinking, we should really try to get parents of school-aged children to edit/contribute to Wikipedia by communicating to them (through blogs, forums, maybe an email campaign) the fact that their children will be turning to us as a research resource - and if all the parents of children who look things up on Wikipedia were to pitch in just a little time and knowledge, they would be helping their kids to succeed in their education, and in life. I can see the potential downside of bringing in parental POV, but we already deal with bias well enough to risk it. bd2412 T 20:27, 4 October 2009 (UTC)

Wikipedia does not, as a rule, advertise. The idea of administrators or devs essentially spamming through email addresses is to me personally distasteful. That being said I'd support a little dismissable "why not contribute to wikipedia?" banner or something at the top of the site. Ironholds (talk) 23:58, 4 October 2009 (UTC)
Neg on this, chummer; it's antithetical. Neg on Ironholds' idea as well. This is an encyclopedia, not Jimmy the Shark holding a baseball bat while "suggesting" you edit. -Jeremy (v^_^v Tear him for his bad verses!) 00:02, 5 October 2009 (UTC)
I imagine our powers of coercion to be rather limited - but there are still large segments of the population out there who don't realize that they have the ability to edit Wikipedia, and a reason to do so. bd2412 T 05:18, 5 October 2009 (UTC)

I have proposed that

Join WikiProject Athletics!
18:47, 5 October 2009 (UTC)

Proposal for fixing the unreferenced BLP mess.

Located here. Input requested. → ROUX  03:24, 6 October 2009 (UTC)

Ads, but not for money

We need more editors. We used to have a tag at the top saying something like "You can edit this article right now" (I forget exactly what it said, and it changed a bit over time). Now it's "The encyclopedia that anyone can edit", which isn't as motivating. Because of our decline in editors, I think we should do something even more punchy. We should do adds that emphasize that you can edit this article, with some sort of advertisement. I know that ads for money are a perennial proposal that have been rejected, and maybe this it too, but I think it could really help to increase the improvement of articles. We could do it for every 100th visitor (I think, with current capabilities) or we could add it to stubs, or do it on every article for a week, or whatever we want. - Peregrine Fisher (talk) (contribs) 03:21, 11 September 2009 (UTC)

I'm quite sure, that anybody who is already on the site knows that you can edit it. The advertisements that we could use, are ads on the internet, inviting users to come to this site. warrior4321 03:27, 11 September 2009 (UTC)
Those would be nice too, but that cost money I don't think we have. I disagree that readers are really that aware that they can edit, or at least they need a little push. - Peregrine Fisher (talk) (contribs) 03:49, 11 September 2009 (UTC)
I agree that a little push to invite readers to become editors would be nice. This is essentially my proposal above... Other forms of advertising would be nice as well. GeometryGirl (talk) 12:23, 11 September 2009 (UTC)
On-wiki advertising for the wiki itself? Kind of like seeing a commercial for a show you're already watching. You can already add this into your userspace- see Template:Wikipedia ads. Users are fully aware they CAN edit, I honestly don't see how reminding them again and again will do anything but irritate them. If they don't want to edit, they won't. --King Öomie 13:29, 11 September 2009 (UTC)
Well, they do have ads for shows that you are watching while you are watching them, so apparently marketing gurus have deemed this a good thing to do. Ads in userspace are the ones where people are fully aware that they can edit, so those aren't going to bring in new users. Also, people are not really aware that they can edit wikipedia. They've heard things, but don't really understand what it means. They pretty much read the article, and don't give editing a first or second thought. The usability study found that people were very unsure how to edit, and I think people who were interested in editing were chosen. I thought we had a small weak add saying "the encyclopedia that anyone can edit" but it looks like we don't even have that. When I log out, I see "Wikipedia is sustained by people like you. Please donate today." Maybe that says different things at different times, I don't know. - Peregrine Fisher (talk) (contribs) 17:19, 11 September 2009 (UTC)
Those messages displayed to anons are defined at MediaWiki:Monobook.js, most are on donating, and there's one linking to Wikipedia:Contributing to Wikipedia. We'd need to better introduce editing to newcomers, for example by linking the introduction in the sidebar. Cenarium (talk) 22:09, 11 September 2009 (UTC)
  • Strong Oppose banner ads on articles. This is an encyclopedia, not a blog. Hatnotes are a different story- as I recall, that "you can edit this page now" tag resulted in a lot people treating the entire encyclopedia like the Sandbox. --King Öomie 19:29, 11 September 2009 (UTC)
  • Oppose We don't need ads to tell people to edit. People are very aware that we can edit. We do not have a lack in editors, we just more more vandals than editors, we just have more people adding unsourced information than people adding proper cited information. What we need are people who want to edit and improve the encyclopedia. We have more than enough editors, we just lack strong good ones. warrior4321 21:01, 11 September 2009 (UTC)
We lack 'good' editors because we fail to well introduce editing to newcomers. Cenarium (talk) 22:09, 11 September 2009 (UTC)
Well, the majority of "bad" editors are IP users. Most IP users have no interest in editing and improving the encyclopedia, that is why they don't even want to sign up. warrior4321 22:12, 11 September 2009 (UTC)
Many "would-be-good" editors don't contribute because it seems too difficult for them or we don't explain editing well enough. Making 'good contributions' is relatively difficult (formating, sourcing, etc), while vandalizing Wikipedia is easy. We need to better introduce editing on Wikipedia to good-faith users. While I would oppose ads, a link 'introduction to editing' in the sidebar could help in achieving this. Cenarium (talk) 00:15, 12 September 2009 (UTC)
Until this claim is anything but "baseless", you'll forgive me taking it with a grain and a half of salt. --King Öomie 00:59, 12 September 2009 (UTC)
Haven't you heard of the usability team's findings (linked several times on this very page) ? We get a multitude of new user's comments confirming this, as well as other investigations and surveys conducted by the wmf (it's one of the reasons they launched the usability initiative) and other parties. This is a widely recognized problem. Don't say a claim is 'baseless' if you have no idea if it actually is, please, ) 01:52, 12 September 2009 (UTC)
I agree w/ Cenarium and there is not a shortage of research indicating that wikipedia has a great deal of trouble hanging on to new good editors, for a variety of reasons (and in my opinion not least among them is our willingness to succumb to a number of logical fallacies in asserting that the majority of bad editors are IP editors). Protonk (talk) 02:21, 12 September 2009 (UTC)
We definitely have a problem. It looks like this is going to be a knee-jerk bunch of opposes and die on the vine, but how about this: Put ads on 10 pages, leave them there for a week, and see if it attracts new editors. We've got 3 million pages. What could it possible hurt? Worst case scenario, it works and we're forced to think about more ads. - Peregrine Fisher (talk) (contribs) 02:27, 12 September 2009 (UTC)
We do not need ads asking people merely just to edit. This will result in edits full of testing and vandalism, and the editors will blame the ad on the page for asking him/her to edit. I'm pretty sure everyone who comes to Wikipedia is aware that they can edit the page. What we need to do is educate the people to follow our policies and guidelines and eradicate the vandals. This is why I stand by the thought that everyone should be able to read Wikipedia, but only registered users should be able to edit. warrior4321 05:00, 12 September 2009 (UTC)
Sounds like you've made up your mind, but everything I've read says that people have very little understanding of wikipedia. If you think the elderly, minorities, people without the internet at home all understand WP perfectly, then whatever. As far as IPs go, I believe the consensus is that we'll accept them. If that changes, we can prevent editing without logging in, which is unrelated to my proposal. - Peregrine Fisher (talk) (contribs) 05:08, 12 September 2009 (UTC)
If senior citizens and minorities do not know that they can edit Wikipedia, then they probably do not know how to cite sources and create strong and proper articles. We do not have a shortage of articles or editors, we just have a lack of FA's and GA's versus all articles, just as we don't have a lack of strong, interested editors versus vandals and uninformed editors. We need to properly educate the editors we already have, not bring in more inexperienced users for the sake of increasing the number of editors. warrior4321 17:49, 12 September 2009 (UTC)
That sure worked out for citizendium. Protonk (talk) 08:15, 12 September 2009 (UTC)
The issue that most people have with editing isn't due to a lack of understanding that their allowed to edit. The problem is largely the interface, which relies on a "technical" text formatting system. It's not WYSIWYG editing, so most people simply won't take the time to learn the "language". This is a completely separate issue from what any advertisement could possibly address.
V = I * R (talk to Ω) 17:50, 12 September 2009 (UTC)
There have been a number of studies done on how Wikipedia evolves; this is an accessible one. Essentially the studies show that the majority of Wikipedia content is added by IP accounts. The majority of registered accounts clean up, categorize, format and discuss. There are a noticeable percentage of registered accounts which do add content, and there are a noticeable percentage of IP accounts that simply vandalise - but on the whole the IP accounts add a substantial amount of content. Because IP accounts add content, we need to be careful about semi-protecting pages, and it would be totally inappropriate to ask people to register to edit. SilkTork *YES! 21:43, 19 September 2009 (UTC)

We should make them subliminal like in "they live" *EDIT NOW*, *SOURCE THIS*, *GIVE JIMBO MONEY* --Cameron Scott (talk) 22:16, 11 September 2009 (UTC)

  • Strong Oppose we need more ads in this world like we need extra holes in vital body organs. Hell no! - Denimadept (talk) 22:24, 11 September 2009 (UTC)
  • NONBHNO Protonk (talk) 01:15, 12 September 2009 (UTC)
  • Support exploring various avenues for attracting contributors. In order to maintain momentum, we seriously need more dedicated editors, and among our readers are vast numbers of would-be assets to the project. I think the best way to proceed with this is think of the different ways something like this could be implemented (e.g. banner ads, sidebars, hatnotes), creating mockups, testing, and then coming back to propose the best means here.  Skomorokh  02:59, 12 September 2009 (UTC)
    Honestly, I'm not so sure that we need more editors. I mean... we don't want to discourage people from editing, but I just don't see a real editor shortage issue now or going into the future. The level of editors has plateaued, but so what? That was bound to happen eventually, and it's a good thing because it shows that the project has matured. The number of editors hasn't actually declined, and isn't likely to, so what's the problem?
    V = I * R (talk to Ω) 09:28, 12 September 2009 (UTC)
    It has declined, starting in 2007. There are signpost articles on it, and videos about it from the last wikimania. The usability thing is one thing being done to try and stop the decline. - Peregrine Fisher (talk) (contribs) 16:12, 12 September 2009 (UTC)
    Futile. There are editor-editor interactions which repel people, which are unavoidable. The project strikes me as healthy. Adding ads of any kind will repell more editors, and maybe users as well. If I see ads, I'm likely to start my own MediaWiki project on my own terms, to fix what I see as problem with this one. For details, ask on my talk page. - Denimadept (talk) 16:40, 12 September 2009 (UTC)
    The number of regular editors (those with more then a handful of edits) has plateaued, it hasn't dropped. The stats are available for anyone to look at.
    V = I * R (talk to Ω) 17:42, 12 September 2009 (UTC)
  • Oppose Ads are more likely to annoy people than make them edit. I know it would annoy me.
    Chillum
    16:33, 12 September 2009 (UTC)
    • That's kinda like saying ads are more likely to annoy people than make them buy something. Apparently they work. - Peregrine Fisher (talk) (contribs) 16:42, 12 September 2009 (UTC)
      • Actually, ads work for a number of different reasons, and not as well as people might think. In this case I think wikipedia has a good reputation for being ad free and unobtrusive (save the occasional hideous donation notice). It is more important that we maintain that image (IMO) than we remind people they can edit in a banner ad. Protonk (talk) 18:01, 12 September 2009 (UTC)
  • People are often reluctant to edit. Essentially everyone I know uses Wikipedia--most of them would make good editors, with interesting things to write about and the skill to do it. All of them see things in Wikipedia that they think should be edited--but yet they do not edit. Any way we can think of encouraging them is for the good--If our advertisements convert 1% of them, it will double the number of active editors. It's not just usability. Wer're concerned with getting people to fix errors initially--it often leads to further contributions. DGG ( talk ) 00:12, 13 September 2009 (UTC)
  • Perhaps if targetted. I would not like to see a banner above every article, but maybe it would be ok in articles are in categories that are known to be weakly covered. Alternately, maybe a banner could appear for IPs known to be from colleges and universities. Gmail was first marketed this way, as I recall. Abductive (reasoning) 04:06, 13 September 2009 (UTC)
    • I do think we should have a strategy of some sorts, to (hopefully) maximize adding editors, without big glaring ads on every page, every view. - Peregrine Fisher (talk) (contribs) 04:15, 13 September 2009 (UTC)
  • Support, but with Reservations When I told a friend of mine that I've started being an editor at Wikipedia, her response was, "Why doesn't Paul do this? He loves Wikipedia!" I.e., there are people out there who definitely have something to contribute, but for one reason or another, need that extra little push. I'm not a strong supporter of this initiative because I can see it being misused, offending readership, and turning people off in general. The use of this would definitely have to be very judicious. --Tim Sabin (talk) 19:28, 13 September 2009 (UTC)
  • Oppose - We need to focus more on teaching people how to edit and/or making editing easier. Just getting people to the editpage won't help all that much if they're totally clueless on what to do when they get there. Mr.Z-man 22:18, 13 September 2009 (UTC)
  • Oppose I agree that we need some sort of effort designed to increase the amount of editors here, but this isn't the way to go about it. Our articles should be intrusive of any sort of advertising, even advertising for Wikipedia. Our articles already encourage editors to contribute in templated cleanup tags and an edit box on the top of every article section. This isn't a disagreement about the problem, just the proposed solution. ThemFromSpace 00:20, 14 September 2009 (UTC)
This is a great little idea, as mentioned above in various forms, this is basically all the Disney channel does - that is, market itself on its own network. Definitely one would have to work out where it would go, who would see it, and when, but I'm a bit baffled by some of the opposition. We need more creative ideas like this to promote editing, which is statistically on decline in terms of new articles and active members. If it could be targeted, perhaps on all IPs and registered but inactive users? Or just start with the inactive users over say a month and see if there's an uptick in that category (we're currently hovering just under 150k active over 10,500k registered, or under 1.5% active userbase). No gain? No harm done. Joshdboz (talk) 01:29, 15 September 2009 (UTC)
  • Mobile App: I guess one issue is time and I am always looking for things to do with dead time- stuck in traffic, waiting for an appointment or a car to be fixed, and I usually have a blackberry. A mobile app that you could make available some how, maybe ads on like-minded sites that could be free, would help. I'm actually working on branded phone apps that are like a browser but can be customized for some other uses and I'm open to thoughts here. It is hard to do research on a smart phone and a lot harder to try to compose on a phone but maybe with something specialized to wiki it could get people going instead of playing video games. I'm obviously trying to push an idea I've had for a while and one in which I may have a financial interest but it is something to consider. I acutally have a wiki app that is just a browser shortcut and it has a big "W" desktop icon on BB and goes to the "recent changes" page. Didn't seem that useful as-is but again I'm open to thoughts. I'm also trying to make a research browser, not sure what that is yet but again thinking. FWIW. Nerdseeksblonde (talk) 01:45, 17 September 2009 (UTC)
* Mobile App Ad Support : I just modified a browser and mailed myself some notes I took that could be automatically inserted into an article, or maybe a talk page until you can edit from a real computer. I think something like this would help pick up opportunistic editors. That is, instead of playing suduko, you could collect citation clips from a mobile phone more easily than with a normal browser. For example, I have a floating toolbar over the browser that lets me have limited copy and paste into a text buffer. Each past operation includes a wiki style citation stub and whatever info I can get automaitcally like a source url or maybe page title. Not sure if it is quite easy enough for pleasant spare time use but I was able to mail myself some research results. And, the base app is already ad supported. Just a thought any comments? Nerdseeksblonde (talk) 18:51, 1 October 2009 (UTC)
  • Pile-on Oppose People already know that Wikipedia can be edited by anyone. Banners (or other ads) will just spoil the overall look of the pages, for insignificant gains. ƒ(Δ)² 17:17, 19 September 2009 (UTC)
  • Oppose It is common knowledge that anyone can edit Wikipedia. I don't think reminding people will do any good. Captain panda 16:16, 23 September 2009 (UTC)
  • Support "common knowledge" really isn't that "common". And while it might be annoying to IP users, certainly there has got to be a way that will not show ads to people with accounts. Oldag07 (talk) 19:12, 23 September 2009 (UTC)
  • Weak support- If done correctly, it may actually encourage editors. I for one find the "edit this page" tab the only reminder that anyone can edit wikipedia. It should be done in a very limited manner though...say the ad would only be served up 5% of the time...no need to state that wikipedia can be edited too much. The other problem I find with editing wikipedia is its truly appalling GUI...it lacks anything more than the simplest of edit boxes...no spell check, no help with reference templates, just a simple simple simple edit box. Perhaps if the user interface were overhalled to be made more appealing to editors, more people would edit again. Wikipedia otherwise hasn't changed its interface in years.65.51.38.194 (talk) 23:23, 23 September 2009 (UTC)


  • COI Mobile App: I'm working on an ad supported mobile app ( I have various conflicts here ) but I have found it useful for mobile article research, see some results here http://en.wikipedia.org/wiki/Talk:Law_of_maximum_entropy_production and was curious to get some feedback on what others would be interested in here. I personally like to use dead time- waiting, on beach, etc- to do research from a mobile phone. Maybe with netbooks or laptops you could just use a regular browser but if all you have is a blackberry, it can be hard to take notes or even get to pdf files sometimes and copy/paste. Anyone interested in something like this or know of other products that would do the same? Essentially this allows you to accumulate a bunch of notes and tags them with a wikipedia format reference which you can then mail to your default email address and edit later or just paste on article talk page. Composing and typing is difficult but copy/paste notes from text can be quite helpful. Nerdseeksblonde (talk) 12:18, 8 October 2009 (UTC)

Transcluding google

I think it would be a help to editors on wikipedia to transclude google above the editing space. It would also improve verifiability and reliability. --William S. Saturn (talk) 18:44, 7 October 2009 (UTC)

Why? Nearly any modern browser has a Google search bar directly in the browser interface, and multiple tabs or at least windows to use it at the same time one is browsing Wikipedia. --Stephan Schulz (talk) 18:59, 7 October 2009 (UTC)
I explained "why" above, but I will repeat, "a help to editors & [to] improve verifiability and reliability." Not every browser gives the option for extra tabs, and switching between windows or even tabs is somewhat time consuming. It will also serve as a reminder to new users or any user that information they add must be verifiable. What exactly is your objection?--William S. Saturn (talk) 22:29, 7 October 2009 (UTC)
Googling from the Wikipedia tab or window will take you away from the page you are working on, which I wold consider very much inferior to Googling in a second window or tab. In short, I don't believe that it would "be a help to editors [and] improve verifiability and reliability". On the other hand, it would clutter the interface and burden us with what I consider a useless feature. --Stephan Schulz (talk) 22:39, 7 October 2009 (UTC)
It would be transcluded, therefore you would remain on the editing page. Also do not misquote, I do not use poor grammar as you suggested above. --William S. Saturn (talk) 22:44, 7 October 2009 (UTC)
Sorry about the typo. Fixed. I still think it would be useless clutter. And HTML support for transclusion is limited, so you would need to rely on fairly advanced CSS/Javascript support, and less browsers support that than tabbed browsing. Also, usability would suffer, since you only would have very limited space for the results. --Stephan Schulz (talk) 23:14, 7 October 2009 (UTC)
(e/c) The time it takes to switch between tabs or open up new windows is truly negligible. I also don't see how simply providing the link translates to reminding people of verifiability. It's far too attenuated a relationship. I second that it's not a good idea to add anything to the interface that takes users away to a new site (though it could probably be made to open in a new tab or window by default). By the by, I don't think Wikipedia should be endorsing any specific search engine by transcluding it, and doing so may have some significant legal ramifications. It would probably require permission from Google (which I imagine they'd fall all over themselves to give), but then Bing and Yahoo! etc. might want to get involved and wonder how this lucrative windfall had been provided Google (let's not forget if we did this to the interface there would then be a link to Google on all of our 60,302,117 pages, on a site that gets millions of hits a day and is ranked in the top 10 most visited sites in most countries on the Earth and 6th in the US!)--Fuhghettaboutit (talk) 23:29, 7 October 2009 (UTC)
It's not merely a link and it would not open in a new page, it would open in the same page, while keeping the editing screen active below. This would be easy for any programmer to do, the problem is wikipedia does not allow the transclusion of other websites (or so I've been told). However, Wikimedia could make a ton of money on this while helping editors. I don't have seperate tabs on my browser and therefore when searching for sources, I often have many windows open (I'm not the only one). This would be a big help to me and other editors as well, while reminding others of the importance of verifiability (a reminder could be placed above the transcluded google). And choosing Google over others makes sense, I'm sure (but not certain) it is the most recognizable and most widely used search engine in the world. --William S. Saturn (talk) 00:11, 8 October 2009 (UTC)
Plenty of people already take issue with all the stuff on the edit page, and putting another thing there that would amount to increased clutter and server drain wouldn't make sense. Besides, as you imply, the WMF is not in the business of welcoming what amounts to advertising and promotion on this website. You can, however, rig your preferences to allow the Wikipedia search bar to search the web using search engines. ~ Amory (utc) 12:37, 8 October 2009 (UTC)
Google is not the main tool to help with verifiability or reliability, it's just a starting one. Although it's useful if well used, references must come from reliable websites (not just the first website that google offers), or even better, not from websites but from books (see
FUTON bias
). Anyway, learning to use web search engines is the ABC of web browsing: I think we can easily asume that people who don't know about them or how to use them, won't be able to find their way to this web page (wikipedia) to begin with
A better alternative would be to write a help page detailing how to properly use a web search engine to find acceptable material for wikipedia (images, references, external links, etc.), setting apart what is good and what isn't. Such a help page may be later linked somewhere it can be useful for novice editors.
talk
) 12:58, 8 October 2009 (UTC)
(edit conflict) I agree entirely. There's two or three threads open HERE talking about reducing the amount of clutter on the edit screen. And if a user is still legitimately using IE 6 (I can't think of another browser without tabs)... I don't think any amount of help in the world is going to matter. They're just "not computer people", and likely wouldn't be very effective at using Google to find reliable sources anyway. Just my two cents. --King Öomie 13:00, 8 October 2009 (UTC)
Another argument against adding Google to the edit page ist hat it privileges Google over alternatives. (After starting to write this, I see Fuhghettaboutit already made the point, so this becomes a support for that point). I use Google a lot, but there are people who choose alternatives, sometimes for ideological reasons. Put Google in a preferred position, and reps from alternatives may push for equal billing. If you think the page is cluttered now, imagine cramming a dozen alternative search options.--SPhilbrickT 13:41, 8 October 2009 (UTC)
Or, they could be people working at a company where IE6 is required to launch one of the main LOB applications, because the scripting that the company used doesn't run in anything later. Just saying. :-) --SarekOfVulcan (talk) 13:51, 8 October 2009 (UTC)

Search page: "Content pages" or "Articles"

On the search page, I suggest that "Content pages" be replaced with "Articles", as the tooltip says "Search in (Article)". I think this makes it clearer what is meant. (All pages here have some sort of content anyway.) And I think the tooltip should be modified too, e.g. "Search encyclopedia articles", if not just "Search articles". Iceblock (talk) 14:01, 8 October 2009 (UTC)

When GeoCities shuts down, how should we handle links to its sites?

  • This may not be the perfect place for such a question, but the Policy and Technical Village Pumps didn't seem to fit very well, either.

Yahoo!'s latest drive to stay solvent includes the closing of unprofitable or duplicative sites such as Yahoo! Photos, Yahoo! Briefcase and, three weeks from now, GeoCities, a 14-year-old free web-hosting service that must be the destination of thousands of current links in the Wikipedia universe. See GeoCities#Closure.

How can we anticipate the sudden breaking of all these links? Some (although not in their most recent version) will already be on the Internet Archive's Wayback Machine; others won't be posted there until three or six months after GeoCities shuts down; and many others (being personal projects) will never find their way there. However, according to our own article on GeoCities,

With the GeoCities closing announcement the Internet Archive announced a project to archive GeoCities pages, stating "GeoCities has been an important outlet for personal expression on the Web for almost 15 years. With the recent news from Yahoo that GeoCities is going to be discontinued on October 26, 2009, the Internet Archive is working over the next few months to ensure our collection of GeoCities sites is as deep and thorough as possible." [Internet Archive (2009). "Saving a Historical Record of GeoCities". Retrieved 2009-08-17.]

Would it be a good idea for someone to set up a 'bot to locate and test these links now, and then to search for mirror sites with a view to rewriting or redirecting the old links? Should we archive some pages' content at WikiCommons (if that's even legal)? How easy or difficult a project would this be, from the technical point of view?

It's true that as a free hosting service for personal web-sites, GeoCities won't have the highest concentration of Reliable Sources, but often these pages are the only place to find things that are already in the public domain (such as historical documents) or inherently reliable because (for example) they're a politician's campaign web site or lists of an independent band's, artist's or author's works and tour dates. —— Shakescene (talk) 03:57, 5 October 2009 (UTC)

Legally, we'd be on shaky ground if we tried to wholesale copy those materials (although we'd be covered by the
cease-and-desist notice). If we have the technical capacity, we can contact the individuals who have posted the sites from which we have linked material and asked them to release those materials under the GFDL, or into the public domain, so that we can host them somewhere. bd2412 T
05:21, 5 October 2009 (UTC)
Alternately, you could try and get WebCiteBOT to do a run over all the geocities links in Wikipedia. Last time I heard, the bot's associated service was having capacity issues though. --Cybercobra (talk) 05:26, 5 October 2009 (UTC)
As I implied above, where there's already another site (the site-owner's own transplanted site on another host or a third-party archive like the Wayback Machine) which still houses the words or image currently cited in Wikipedia, then what I'd want the automated or manual process to do is just to change the Wikipedia link. ¶ The trickier problem is what to do with potentially-orphan material (e.g. from an abandoned site) that isn't so far archived. On the other hand, the originators of such sites (so long as they're not embarrassing in some way) would be less likely to have objections to Wikicommons' or Wikipedia's salvaging, storing and publishing such material. —— Shakescene (talk) 05:41, 5 October 2009 (UTC)
Scope of the task: I got around to doing a search on Wikipedia for "geocities", "www.geocities.com" and "http://www.geocities.com", with similar results each time, about 20,000 entries, give or take a few hundred. Some of those are false positives, where the reference isn't to a hyperlink, but others will be passages or lists with more than one geocities link. Given about 15-20 possible situations for each link (different possible hosts, mirrors and archives, link already dead on GeoCities either before or after archiving on a mirror site, etc.), and only three weeks until Oct. 26, 2009, this looks like it's neither largely-impossible nor at all trivial. —— Shakescene (talk) 06:14, 5 October 2009 (UTC)
I do not think a search finds links, it only checks the text. I get 35,067 links [2] using SPecial:LinkSearch. Why not just get all pages found using Special:LinkSearch, do a replace of "[*geocity*]" to "[http://web.archive.org/web/*geocity*]", that shoudl fix everything, as long as web.archive have the page, if not do nothing. My guess is that web.archive will get all pages by the time geocities closes down. --Stefan talk 10:01, 5 October 2009 (UTC)
I'm extracting a list from special:linksearch; I'll trim it down to *just* mainspace links and post it in a short while.
talk
| 10:11, 5 October 2009 (UTC)
...and a text list is here, 23558 mainspace entries including a few from Template: and Category:, for what use it may be. (I had trouble putting it into an edit window to leave on the wiki!)
talk
| 11:34, 5 October 2009 (UTC)
But what to do now? Is there any issues with just adding http://web.archive.org/web/ in front of all geocities links? Except that we might get a newer version that is not the same as before. How do we fix things, just attack with AWB or give to a bot? A simple reg exp replace is all that is needed, but to check that the link actually exists in web.archive makes it much more complicated. --Stefan talk 11:49, 5 October 2009 (UTC)
If the Internet Archive offers an API, we could screen out all the ones *without* IA copies, then run the AWB/bot approach. If not, I can write a script to manually check each one, see if it's valid or not, and screen that way - but it'd be a bit messy!
talk
| 12:46, 5 October 2009 (UTC)
...yeah, the script approach is a bit clunky. On the plus side, it's let me do some sampling - 51 of 75 links tested have an archive.org copy.
talk
| 13:41, 5 October 2009 (UTC)
While we are on this: we still have a fair number of links to MSN Groups, which has been defunct since February.[3] ---— Gadget850 (Ed) talk 13:36, 5 October 2009 (UTC)
Out of those 1164 links, only about 351 is to main space. Checking a few of them (maybe 10) I could not find a single one in IA. --Stefan talk 14:28, 5 October 2009 (UTC)
How many, if any, might have migrated into the Windows Live or Multiply successors to MSN Groups? ¶ With GeoCities, a different problem, we won't need to do anything about those geocities sites that opt to join Yahoo!'s paid web Hosting service, because Yahoo! itself will provide redirects to those URL's —— Shakescene (talk) 00:36, 6 October 2009 (UTC)
I've asked ThadeusB to comment here. He is the owner of User:WebCiteBOT, which adds links to the WebCitation.com archive. Instead of taking 6 months to appear (as it does with the Internet Archive) the WebCite archives appear in little less then a day. Keep in mind that the Internet Archive takes 6 months to archive a page before it appears. If they said that they will try and archive all of GeoCities, they probably will, you just wont see them for 6 months. Also, you can manualy archive pages too both WebCite.com AND archive.org.
Response, prt 2
I have been told MANY times that using just the "web.archive.org/web/" method, is NOT a good idea. It is more important to have a archive from near the date of original retrieval.Tim1357 (talk) 23:31, 6 October 2009 (UTC)
  • When this was originally announced several months ago, WebCiteBOT was just getting started and I said I would have the bot run through all of our links to GeoCites and archive them. Unfortunately, due to a combination of problems on my end, on WebCite's end, and problems with the API the bot hasn't been nearly as active as planned and I hadn't got to doing the GeoCities ones specifically. Considering, we have nearly 40000 GeoCities links (some duplication obviously), I still think that is the only viable option. Obviously time is short here, so I am going to make the necessarty code modifications tomorrow and start archiving ASAP... as it happens webcitation.org is currently down. --ThaddeusB (talk) 00:31, 7 October 2009 (UTC)
So, just so that a complete technical neophyte like me is sure that his or her understanding is correct: you or someone else at Wikipedia will be trying to archive all the currently-extant GeoCities sites and their pages independently, rather than trying to find the new sites where they might have migrated or been archived? For many purposes, if the glitches and shortage of time can be overcome, this would be an ideal solution. Many of these sites are now orphan sites, since (for whatever reason) the person who created them won't or can't come back to save, move or archive them. And trying to guess a new location for each site by trial and error will take lots of the former and result in significant amounts of the latter. A secondary problem that doesn't face an October 26th deadline is finding the sites that have already moved somewhere else without leaving anything at GeoCities today. At some point, I need to revisit the users' FAQ at http://www.geocities.com to see a list of most likely hosts that these sites might have found. —— Shakescene (talk) 00:53, 7 October 2009 (UTC)
Yes, that is correct. If all works out an archive copy will be created for each page that it linked to from Wikipedia. It will then add a link to this archive to the relevant Wikipedia page(s).
While I'm at it, I'll have the bot also create a list of all GeoCities pages that are already dead for human review. --ThaddeusB (talk) 15:00, 7 October 2009 (UTC)
I don't understand all the secondary uses of Categories; would it be worth having the 'bot put all pages with resolved or unresolved GeoCities (and for that matter MSN Groups) links in categories such as "Pages with [un]resolved GeoCities links"? I did a little of the research I promised, and here are the sites that Yahoo! GeoCities suggests for its clients seeking another free web-hosting service:

Yahoo! no longer offers free hosting options. If you prefer not to pay for web hosting, you might consider one of these free services:

The sites that migrate to Yahoo!'s paid web-hosting services will be automatically redirected, so they're not an immediate concern (although of course we'd eventually want the most direct URL.) Our article on GeoCities mentions another free web host † which offered to take GeoCities accounts.—— Shakescene (talk) 21:54, 7 October 2009 (UTC)
I would think a regular {{dead link}} tag should be sufficient for marking such articles. The list I was referring to would be a userspace page listing the pages the bot couldn't do anything with, solely for convenience reasons. --ThaddeusB (talk) 01:49, 8 October 2009 (UTC)
  • † Here's the free web-host mentioned in the Wikipedia article as one among several welcoming migrations from GeoCities: Jimdo's Lifeboat for GeoCities. I don't know the details of other possible refuges. —— Shakescene (talk) 04:42, 8 October 2009 (UTC)

Another fly in the ointment or spanner in the works: Encarta

As bubbles burst and the Web goes through yet another reweaving,

Hallowe'en, except for Japanese Encarta, which will linger on in this world until New Year's Eve. According to the site's home page:

Important Notice:

On October 31, 2009, this Web site, and all other MSN® Encarta® Web sites worldwide will be discontinued, with the exception of Encarta Japan, which will be discontinued on December 31, 2009.

See also: http://encarta.msn.com/guide_page_FAQ/FAQ.html

My simple search in the Search Box yielded nearly 3,000 hits for "www.msn.encarta.com" in Article space and about twice as many for everywhere (Talk pages, Portals, etc.) But a more-sophisticated engine would probably give more-accurate results.

This presents slightly-different problems from GeoCities, as few encyclopedia pages will have migrated to other sites or been orphaned by absent owners, but unless the Internet Archive is also archiving Encarta (on the far-from-likely assumption that Microsoft will even let them), there will be very few backups for Encarta links in Wikiworld. —— Shakescene (talk) 04:42, 8 October 2009 (UTC)

A count using the API returns 3107 mainspace links to encarta.msn.com (and 2 to www.encarta.msn.com); there are also 105310 in User and 102790 in Wikipedia. Anomie 12:24, 8 October 2009 (UTC)
There will still be Encarta CDs out there, so what we should do is make sure the references has enough to find the article on a CD. --Apoc2400 (talk) 18:06, 8 October 2009 (UTC)
I was aware of this pending closure as well. Archiving the mainspace links is second on the agenda, after the GeoCities links. --ThaddeusB-public (talk) 19:12, 8 October 2009 (UTC)
Thaddeus, you again seem to be about a mile ahead of us here, which is very comforting since it's a little late now to leave the starting gate in pursuit of the robotic rabbit. ;-) By the way, in reading the documentation for the original WebCiteBot, I see that it doesn't look for External Links. Is it worth including them in combing our GeoCities, Encarta and MSN Groups links? As for the Encarta CD's (I have the Encarta 2000 CD, for whatever little it might be worth), I think they had less information than the web site, so some references wouldn't be backed by a CD.—— Shakescene (talk) 21:46, 8 October 2009 (UTC)
Yes, I am planning on having it do external links for this task since sometimes the "External links" section is really just a mislabeled references section. I figure it is easier for a human to remove the EL+archive later if they deem it inappropriate then it is to recover the content once its gone. :) If I get complaints, I might disable the EL part, but for now that is the plan anyway.
Officially, there is no guidance on linking to archives in the EL section, but it is generally frowned upon. See also this current discussion on whether archives are OK in the EL section. --ThaddeusB (talk) 01:21, 9 October 2009 (UTC)
Your logic makes perfect sense to me. Sure, when someone visits an External Link that's dead but archived, there are limits to what he or she will find, but presumably many of the External Links were considered worth seeing at the time they were posted by the person who posted them. And in case of debates, it's better to have them after an archive has been created, since there won't be anything to consider once the page has vanished. —— Shakescene (talk) 05:20, 9 October 2009 (UTC)

Template:Wikipedia ads generic

So we now have a nice new template {{Wikipedia ads generic}}, which bundles up all the generic {{Wikipedia ads}} (i.e. excluding all the regional and specialist wikiprojects). It includes things like (random 5) WP:BITE; Wikimedia Commons; Be Bold; Wikipedia Graphics Lab and Peer Review. How/where could we use this more widely to annoy people educate people and draw them to places they don't know about? I'm thinking, for instance, that people who deal a lot with newbies might have it on the user or user talk page. Thoughts? Rd232 talk 16:24, 7 October 2009 (UTC)

See the discussion (in which both Rd232 and I have already participated) at Wikipedia:Requests for comment/new users#Wikipedia Ads —— Shakescene (talk) 22:04, 7 October 2009 (UTC)
NB That discussion wasn't really going anywhere, so others please feel free to comment. Rd232 talk 22:46, 8 October 2009 (UTC)

question and/or problem with sandbox

i posted a question :

Chelo’s Burden) in a private subpage and in Wikipedia:Sandbox : it does not work : you get some manga face instead of the correct image = not practical if you want to practice, isn't it?! -- thanks in advance for any comment kernitou talk
08:50, 5 October 2009 (UTC)

That's because the file in the infobox is a non-free image, meaning its usage is limited by the fair use guidelines. Essentially, there needs to be a fair-use rationale for each usage of a non-free image in an article. As such, there is therefore no using them in any other namespace for those legal reasons, which is why Wikipe-tan is showing up instead. I would suggest finding another free image to test it out with, or just use the preview button on the article's page. ~ Amory (utc) 20:56, 5 October 2009 (UTC)
for universe's sake, it's just to make tests: it lasts like 5 minutes!
AND: i can use the same image in my personal sandbox but not in the box in my sandbox: not very logical!!! kernitou talk 22:30, 5 October 2009 (UTC)
No, you cannot use the image in your personal sandbox, however you include it. If you add it manually, a bot will swiftly come round and remove it again, as will any editor that finds it. The non-free content criteria require that non-free images are not used outside the article namespace. So please don't do that. Happymelon 19:58, 8 October 2009 (UTC)
it seems both Amory and Happy-melon are bots which do only repeat rules without understanding them and/or which do not understand questions ?! my point is: i just want to test! kernitou talk 04:14, 10 October 2009 (UTC)

New template

User:Otterathome/Substantial sources This template is for articles that only trivial coverage in independant sources, so can be applied to

Otterathome (talk
) 20:24, 7 October 2009 (UTC)

You could possibly shorten the bolded section, or de-bold part of it. It reads very much like a wall of text at the moment. --King Öomie 20:33, 7 October 2009 (UTC)
It is more lengthy than other templates because it is more specific, which makes it more helpful.--
Otterathome (talk
) 20:36, 7 October 2009 (UTC)
That's all well and good; people shouldn't have to read it twice. You could alternately phrase it as "non-trivial references in third-party publications" (or similar)- see Center embedding. --King Öomie 20:40, 7 October 2009 (UTC)
The IMDB is already considered an unreliable source, so this template wouldn't be necessary in that case anyway. --SarekOfVulcan (talk) 20:42, 7 October 2009 (UTC)
Check out Tubefilter and Poor Paul for two articles where Otter would be likely to use this template. --SarekOfVulcan (talk) 20:43, 7 October 2009 (UTC)
You might want to correct the spelling in the template. I'm pretty sure you didn't mean to use "manor" there... causa sui× 20:44, 7 October 2009 (UTC)
I got (edit conflict)'d twice trying to say just that, went to fix it myself, and lo and behold, already fixed. I've made a slight presentation change to hopefully improve readability- what do you think? --King Öomie 20:46, 7 October 2009 (UTC)
  • We already have the which does this just fine. I find occasion to use that template a great deal. The rationale of this template (based on the italics and the explanation above) seems to be to emphasize the "non-trivial" part of the GNG. I agree that we should be as specific as possible, but the way to do that is by a comment on the talk page saying specifically what the problem is--e.g., that source 1 and 2 are mere mentions. That provides a real focus for discussion. Leaving this template is rather likely to confuse. DGG ( talk ) 21:42, 7 October 2009 (UTC)
    I agree. Use the talk page to explain what exactly is wrong with the sources. We don't need a new template for every possible occurrence. causa sui× 21:48, 7 October 2009 (UTC)
    The instructions provided encourage editors to use the talk page. I don't know how this would be confusing unless editors don't know what the word trivial means.--
    Otterathome (talk
    ) 18:07, 9 October 2009 (UTC)

Link description popups

Hi,

One thing I have noticed is that when I am reading a more technical page on an unfamiliar subject, I may encounter several words/concepts that I do not know the meaning for and am forced to open the links into new windows simply to obtain a general definiton. This is frustrating as I am not necessarly interested in loading so much detail on these secondary pages.

What might be better, is for the each page to have a special "summary tag" that consists of a single sentence, perhaps of no more than 20-25 words that summarises the definition of a subject. Then when users hover their mouse over a link pointing at the page this special summary tag is displayed in a popup. That way you can immediately continue reading without having to break the flow and wastefully load pages you have no intention of reading. —Preceding unsigned comment added by Sethnk (talkcontribs)

Have you tried Wikipedia:Tools/Navigation popups? PrimeHunter (talk) 17:13, 9 October 2009 (UTC)
¶ Just to explain: a
navigation popup, when you run your mouse over a wililink, shows the title and (usually) the beginning of the introductory paragraph of the page that's wikilinked. If the lead's well-written, the few dozen words that appear should serve the same function as the summary you propose. Of course that's not always the case. The leads to some technical and procedural pages can be full of technical jargon or details that are only explained further down. See, e.g., Albert Einstein. On the other hand, you can't use these popups until you've registered at Wikipedia/Wikimedia and set your user preferences. That's a very distinct minority of all people who visit and read Wikipedia. —— Shakescene (talk
) 22:20, 10 October 2009 (UTC)
Or try a
Mozilla Firefox. It's a very efficient way of coasting through Wikipedia. Equazcion (talk
) 06:54, 10 October 2009 (UTC)
Most current browsers, including
WP:Watchlist) in the left-hand minibrowser and then open the links one by one as needed. —— Shakescene (talk
) 22:20, 10 October 2009 (UTC)

'Ancestrology' Promotional Wiki Publication

Wiki Community,

Over the past two years I have written a family 'ancestrology' using the resources of Ancestry.com and Wikipedia.org extensively. Although this work was simply intended to satisfy my intellectual curiosity and for the benefit of the family, I believe it could be modified to appeal to a broad public audience and provide substantial exposure as a promotional tool for Ancestry and Wikipedia. The book is being reviewed by the YPB Library Services making it available to all US libraries and my New York agent has expressed interest in representing the work to publishers.

I have a brochure I can upload and can make the whole book available online in PDF form (110MB). Collaboration between Ancestry, a successful for profit company, and the complimentary information provided by Wikipedia to Ancestry content and context could be very beneficial and demonstrate a broad use of the Wiki resources.

The book consists of 300 full color pages which traces my direct ancestors from today through American expansion, Civil & Revolutionary Wars, Jamestown & Plymouth, European origins, Royal connections and related stories all the way back to Flavius Afranius Syagrius, Gallo-Roman Senator, born in 330 AD and my 46th great grandfather (http://en.wikipedia.org/wiki/Flavius_Afranius_Syagrius).

I hope to hear of your interest.

Sincerely,

Davis Jones


W. Davis Jones Jones & Hoggard LLC P. O. Box 12952 Raleigh, NC 27605 (919) 616-6882

It's not really clear what you're proposing. If you want to upload the book to a Wikimedia project, Wikimedia only accepts content freely licensed under
WP:REUSE. Failure to do so is a copyright violation, and is particularly troubling if you are having the book published commercially. Calliopejen1 (talk
) 20:49, 10 October 2009 (UTC)

Let's have a poll regarding laws!

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Archived as (a) not a proposal (b) somewhat
WP:POINTy (relating to a current dispute elsewhere) (c) it's well established that policies and guidelines are not, in any meaningful sense, laws. They describe good practice with varying degrees of community agreement, and in describing it, prescribe it with varying degrees of force. If any particular purpose might be served by discussing this, it should be clearly identified, and the discussion should take place elsewhere (probably via RFC). Rd232 talk
17:33, 18 October 2009 (UTC)

Due to a dispute; in which, yes I am a participant of; at wp:Policies and guidelines I would like to propose a friendly and conflict free poll. I would like it to be as comprehensive of Wikipedians as possible, so feel free to tell as many editors as you happen to see especially those that normally dont come here, spread it around if you could for me to every editor you know. I frankly dont care about the outcome anymore, I am just curious as to what the Community at its broadest may feel about this. I dont want a debate or argument or justification or trying to sway others with your opinions, just which side you are on. Sign your name under the category you support. Most importantly dont be serious, relax and just vote your view.Camelbinky (talk) 03:25, 18 October 2009 (UTC)

  • Are Wikipedia's policies and guidelines in fact "laws" even though they are not in name called such a thing? Does IAR apply only in the sense that an ambulance can break the law by running a red light in order to save a life? (not my analogy)
  • Policies aren't laws. This is common knowledge and clearly stated in many places on Wikipedia. I don't see any need for a poll. I saw the dispute you're involved in, and that user is just unaware of -- or stubborn regarding -- what Wikipedia policy is about. Equazcion (talk) 03:48, 18 October 2009 (UTC)

Yes, policies are laws

  1. As far as I can see the policy fulfills all the qualifications of being
    Dmcq (talk
    ) 09:20, 18 October 2009 (UTC)
  2. Vote here, but with reserves. Policies are laws just in the broadest of terms. Wikipedia is an encyclopedia and not other things, articles must have a neutral point of view, must use reliable sources, must be about notable topics, etc. Those things must be done, there's no discussion about it: what may be discussed, however, is the best way to achieve such goals. Some policies, on the other hand, have to be followed more carefuly (such as
    talk
    ) 13:48, 18 October 2009 (UTC)

No, policies arent

  1. Camelbinky (talk) 03:25, 18 October 2009 (UTC)
  2. Laws are more absolute. Policy is just an agreement of what we should do; we can change our minds, have exceptions, edge cases, jokes. Policy is an extension of the idea of "consensus"; we can agree on the general principles we should uphold, so we take those principles and make them policy. If one person disagrees with a policy, it can stand—they're probably wrong. If just about everyone disagrees with a policy, we change it! {{Nihiltres|talk|edits}} 03:42, 18 October 2009 (UTC)
  3. The difference is that ambulances don't break the law by running red lights, the law had to be modified to allow them to do that. We don't have to modify policies to cover every possible nuance and exception, we just acknowledge that exceptions may exist. Mr.Z-man 04:25, 18 October 2009 (UTC)
    Actually the example I gave was a car not an ambulance. He was mixing it up with my other analogy of the wikilawyers who would stick a wheel clamp on an ambulance which is why I think
    Dmcq (talk
    ) 13:32, 18 October 2009 (UTC)
  4. Wikipedia has policies; that is a documented statement of intent and practice. Wikipedia also has a very few
    Rules which are the equivalent of law - they are the Wikipedia:Five pillars. Of special note is pillar 5, "Wikipedia does not have firm rules besides the five general principles presented here. Be bold in updating articles and do not worry about making mistakes. Your efforts do not need to be perfect; because prior versions are saved by default, no damage you might do is irreparable."(emphasis mine) Thus, policies are not law. LessHeard vanU (talk
    ) 10:12, 18 October 2009 (UTC)
  5. (ɔʇn) 9002 ɹǝqoʇɔo 81 '95:80
    sǝןnɹ ןןɐ ǝɹouƃı:ɐıpǝdıʞıʍ
    ɹǝd"
    Thanks for the link giving "Why isn't "use common sense" an official policy? If you need to be told that this is a rule, you've missed the point entirely." Now if only the one sticking this poll here could take that on board rather than trying to do exactly that to a policy it would be good. ) 10:55, 18 October 2009 (UTC)
  6. There are at least three levels of regulation in common society.
    WP:DBTN). None of us are going to go to jail for vandalism, but we might be banned - exluded for breaking a rule. Certain issues, such as copyright obviously fall under US law, however general policy is not so. Had fun responding to a trivial straw-poll. :) Iciac (talk
    ) 14:41, 18 October 2009 (UTC)
    Contrary to several assertions here, laws are not always punitive. Civil law is almost entirely non-punitive. The laws imposes no punishments when it declares that the state will build a road, house the homeless, or teach little children how to read. WhatamIdoing (talk) 15:26, 18 October 2009 (UTC)
Haha thanks for picking that up. It was late and I was thinking about banning vandals when I wrote that :). I wouldn't say Civil Law is non-punitive - rather is outlines a framework for dealing with disputes between individuals instead of the state. Punitive process still applies to the losing party. Iciac (talk) 15:51, 18 October 2009 (UTC)

Fence-sitters

  1. Laws as in "law of gravity" or laws as in "rule of"? --
    talk
    ) 06:27, 18 October 2009 (UTC)
Law as in "do this (or dont do that) or face the consequences of a specific punishment that has been predetermined for this crime" If you believe in the "law theory" then you believe that policy is "prescriptive of what you can or cant do", if you take the opposite view then you believe policy is "descriptive of past consensuses, and things are still changing, take policy with a grain of salt and common sense" (I am on one side of this issue, so my description may not be as NPOV, there may not be anyone who can give you a perfect answer, someone of the other side may also answer your question, but as I said above- this is not a debate, just a poll to get the Community's views)Camelbinky (talk) 06:50, 18 October 2009 (UTC)
"the office" could simply turn off the servers. Other policies are purely descriptive. The difference between prescription and description is not what makes something a law or a policy. WhatamIdoing (talk
) 07:42, 18 October 2009 (UTC)

Question is
WP:POINTy

  1. I agree with Equazcion about the needlessness of this poll. Camelbinky is involved in a dispute about whether
    WP:POLICY says "should", it means "must", and that therefore the page is trying to define policies as laws -- in defiance of both basic grammar and long-established use.
    This poll was started because Camelbinky claimed to have already obtained support for his view here.
    I suggest that editors consider not just the question that is technically being asked, but also the context in which it is being asked. For example, you might choose to respond specifically to whether you think users "should" follow policies in the normal course of editing, or if you think that a single-sentence definition of "policy" should emphasize their optional nature. WhatamIdoing (talk
    ) 07:34, 18 October 2009 (UTC)
  2. People should just take a sensible approach to things, and everyone will get along fine. Simple. ╟─TreasuryTagassemblyman─╢ 09:17, 18 October 2009 (UTC)
    I think that should should be a must, must it be a should? ;-)
    Dmcq (talk
    ) 09:29, 18 October 2009 (UTC)

Unfortunately, if you look at the way

ArbCom operates and communicates, it seems that right at the top (high enough up that we can't just ignore it) there is indeed a perception that Wikipedia has something analogous to laws, a system of justice for enforcing them, and punishments for breaking them. These "laws" might not be exactly what's written on policy pages (it seems that ArbCom in fact decide themselves what the law is going to be for each case), but if we think the law-based approach is the wrong one, we should be telling it to the Arbs, not talking about it here.--Kotniski (talk
) 16:00, 18 October 2009 (UTC)

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

Result of this poll

Well, the cynics among us were right again: Camelbinky has announced[4] [5] that this 'poll' justifies his removal of the years-old description a policy is from

WP:POLICY
and replacing it with whatever he wants (apparently still to be determined).

Those interested in this subject might choose to look at the mess currently unfolding at the RfC. (If I were a gambler, I'd bet that this will not be the only RfC on this page in the coming week.) WhatamIdoing (talk) 21:15, 18 October 2009 (UTC)

Last time I'm going to ask you to be civil and stop your POV pushing of what I am or am not doing/going to do. You outright lied right there. I'm still waiting for an apology for the other times. I realize this post of yours is probably a bit old compared to the other ones, but I'm just finding it now. Dont speculate on what I'm thinking and dont try and make me look bad (I can do that just fine on my own). Next time I'll be sending the diffs of every one of your comments to an admin for review. Be civil or dont mention my name.Camelbinky (talk) 04:29, 19 October 2009 (UTC)

Idea for dates in articles

Okay, this is my first time suggesting a proposal, and I'm not well-versed in the technical aspects of the MediaWiki software. But I was thinking about the many different formats for dates one can find in Wikipedia, and sometimes within a single article, that can be very confusing to viewers. So I propose a new kind of date template. One that does not require the date-providing editor to specify a formatting style parameter, instead formatting dates to the standard formatting style of the country that the viewer's IP originates from. Logged in users can also override their country's standard formatting style with the date formatting option in their preferences. A bot can be programmed to then apply this template to all existing dates. What do you think? Sounds good?

Another issue is confusion about vague future dates, such as Q1 2010 (based on which fiscal year?) or Spring 2010 (Spring of which hemisphere?). I'm not so sure how to fix this problem, though. BlazerKnight (talk) 23:15, 30 September 2009 (UTC)

We have the {{#dateformat}}
Wikipedia:Manual of Style (dates and numbers). There is no proscription on financial quarters, but that they are ambiguous and probably should not be used. ---— Gadget850 (Ed) talk
00:01, 1 October 2009 (UTC)
I think the reasonable thing is that if there is an article about a geographic place then we can go ahead and keep and continue to use terms like "spring" or "winter" since the average reader can understand that we are talking about that place's particular season and not that of the reader or anywhere else. We dont have to bend over backwards for people with no common sense in a misguided attempt to seem "global" and not "Americancentric".Camelbinky (talk) 00:28, 1 October 2009 (UTC)
Wow. It's great that the magic word exists already. Maybe the date delinking bots can add this to their tasks, so we can use it to format all dates in Wikipedia? As for the seasons and financial quarters, they're often used in (re Camelbinky: international) press releases about future product releases, financial projections, etc. which then gets added to articles, so I was wondering if we could add some context to the vague date. BlazerKnight (talk) 00:37, 1 October 2009 (UTC)
I work primarily on geographic/settlement articles, so that is where my thoughts are regarding. I have no opinion on formating seasons or financial quarters in press releases. Though for things like Microsoft, GE, etc that put out statements regarding commercial product releases the quarters mentioned are not fiscal ones, they are the standard quarters starting Jan 1st as first quarter for three months, then 2nd quarter, etc etc, ending fourth quarter on Dec 31st; as these products are for consumers who are not in-tune with the fiscal year. My opinion on still using seasons is regarding articles about
Perth, Australia or Albany, New York or Hong Kong. There should never never never be a push to remove such terms from settlement articles, or region articles, or nation articles as it is abundantly clear that the season being referred to is that of the article's subject.Camelbinky (talk
) 00:48, 1 October 2009 (UTC)

I don't believe, as implied above, that the #dateformat magic word has this effect. It formats dates for people who have expressed a preference (some tiny percentage of readers), but doesn't take account of anyone's IP. The only way to ensure consistent dates within articles is to write them consistent - the best way IMO to help editors keep dates consistently formatted is to have them written in the most intuitive way, i.e. simply to write the date without any special formatting or magic words - that way anyone (not only those versed in the technical tools) can correct mistakes and inconsistencies as they find them. KISS. --Kotniski (talk) 06:46, 1 October 2009 (UTC)

BlazerKnight, rather than "Wow", I have to say that this syntax toy is a very bad idea indeed. What Kotniskis said. We've been there and done that with Dynamic Dates, which was an utter failure. What is about dates that gets people going on templates? Just leave them alone, please. Tony (talk) 07:50, 1 October 2009 (UTC)
You can set a default style with #dateformat; for example {{#dateformat:October 1, 2009|mdy}} will format the date as mdy for those who are logged out or have no preference; those with a preference will see it in the desired style. And there is a bugzilla request for a DEFAULTDATEFORMAT magic word to set the style per article. Although technically feasible, I really don't think it is worth it. ---— Gadget850 (Ed) talk 11:07, 1 October 2009 (UTC)
Hiya Tony & Kotniski. Generally I agree with your point to simply enter dates using (full) month name, day, and year, and in practice I try to do that as much as possible. The fact is though that most of us often don't for one reason or another. What is being discussed here should be seen in the light of the secondary, maintenance editor(s). As a maintenance editor, your responsibilities are distinctly deterrent from the primary editor's job of entering the original data. For original editors (who are more akin to writers then editors, which is likely where the viewpoint difference comes from), entering the date correctly is an important point. From the maintainers perspective, adding {{#dateformat:October 1, 2009|mdy)) actually adds useful editorial information to the source text. Granted, that information is not particularly important to the readers, but it is important for the collaborative editorial process. From a purely maintenance perspective, the ability to "fix" the display of dates without altering the actual source text is much preferred.
V = I * R (talk to Ω) 11:12, 1 October 2009 (UTC)
I'm not sure I follow - how can you change anything without altering the source text? How does it help collaboration to have weird codes that many editors won't understand? --Kotniski (talk) 11:52, 1 October 2009 (UTC)
If you wrap the existing text within a magic word, the underlying original text is unchanged.
V = I * R (talk to Ω) 23:42, 1 October 2009 (UTC)
So what is the benefit in having wrapped it in a magic word? Why should dates (as opposed to anything else) be wrapped in this way?--Kotniski (talk) 06:13, 2 October 2009 (UTC)

Re Kotniski: Yes, I realize that it doesn't take account of IP addresses, but that would be a nice addition. I also realize that not everyone will understand/use the magic word, thus I suggested giving the task to a bot, so it can format all plaintext dates entered by editors. It might make the code even more inaccessible, but not much more so than it already is (I hope for a WYSIWYG interface). Re Tony: What was Dynamic Dates about, and why did it fail? I'm just suggesting to standardize the display of dates within Wikipedia to reduce reader confusion. BlazerKnight (talk) 23:55, 1 October 2009 (UTC)

There was (is) a function that formats dates according to user preference, but only works if the dates are linked, as in
1 January 1999. That meant we had people linking dates (not generally considered a good idea, as it leads to overlinking) just in order to make the formatting work. In effect, all readers of the eneyclopedia were being given misleading links just to satisfy the whims of a tiny few registered users who could and did set their date preferences. Thankfully that idea is now deprecated, and there was supposed to be a bot that would go round converting the remaining linked dates into unlinked ones (I don't know how close that is to happening). The #dateformat magic word is a less bad "solution" because it doesn't force linking, but I think it still has no significant benefit (it won't solve the problem you're talking about, for example) to outweigh the clear harm of additional complication to the wikicode. --Kotniski (talk
) 06:13, 2 October 2009 (UTC)
I just happened to be glancing over the latest (
Wikipedia Arbitration Committee in the grim reckoning for the Great Date-Autoformatting Bloodbath, and 'bots were apparently forbidden in late June from either linking or delinking dates for six months. This was to allow time to develop different technical methods of addressing readers' date preferences and to develop a new consensus around them. (Which may be hard to do with so many of the leading advocates on both sides of the subject placed under 12-month bans from such discussions.) No doubt the 'bots are hoofing and whinnying impatiently in their stables, like police horses straining to be let out onto the public streets. —— Shakescene (talk
) 06:51, 2 October 2009 (UTC)
The {{#dateformat}} magic word does solve exactly the issue being discussed, however. I've seen this criticism mentioned elsewhere, and I have yet to see an actual definition of how the magic word supposedly fails. If you are referring to the fact that IP users have ISO dates set as their default setting (which is true), then the solution to that (ignoring the obvious solution of simply changing their default) is to use the format parameter ({{#dateformat:2 October 2009|mdy}} or {{#dateformat:2 october 2009|dmy}}). The fact is however, that IP users (currently) have ISO dates as their default setting isn't actually an issue, since if all dates in an article used the magic word then they would all display the same regardless of the setting.
V = I * R (talk to Ω) 06:58, 2 October 2009 (UTC)
I'm confused (as I always am when these date technologies get discussed) - what is the problem that this is the solution to? The problem that some articles contain dates in different formats? Why is that better solved by wrapping them in a magic word and then making the format the same for all of them, rather than just by making the format the same for all of them?--Kotniski (talk) 08:02, 2 October 2009 (UTC)
It would be nice if everyone simply entered all dates in a consistent format, but the fact is that they don't. Rather then attempting to establish a monolithic format (which will not always be appropriate) and/or attempt to enforce one style (which may not be obvious if an editor is editing a single section, or even the whole document), you simply wrap the date in a #dateformat magic word. It should be simple and uncontroversial that way. I guess that it's too late for it to be uncontroversial now, but it is at least simple. It would be nice if the magic word were shorter, and it would certainly be nice if the default date format for IP's was something other then ISO, but for the maintenance editor using the magic word is generally one less issue to worry about. There's no need to stop and really think about what it should be, you just wrap it in the magic word and move on. I guess that it's a matter of perspective.
V = I * R (talk to Ω) 08:47, 2 October 2009 (UTC)
Is there some feature of this magic word that I don't know about? How does it mean that you don't have to think about what it should be? AIUI, you still have to know which date format is appropriate for the page you're editing, and indicate that format. I may be missing something, but I really can't see how this is supposed to help anyone. (In fact I don't believe that ISO is the default format - the default is whatever format is fed to the magic word.)--Kotniski (talk) 09:30, 2 October 2009 (UTC)
You are correct, the default format for IP users (and the default for registered users, but they can change it) is "display the date as entered with no reformatting". There is a patch to add a {{DEFAULTDATEFORMAT}} magic word to MediaWiki that would allow overriding that per article (i.e. stick {{DEFAULTDATEFORMAT:mdy}} at the top of the article, and all IP users and registered users with the default pref would see marked dates in MDY format on that article). As for the magic word being shorter, it could always be wrapped in an appropriate template. Anomie 15:43, 2 October 2009 (UTC)
OK, if a patch like that were implemented, it would arguably have some use, I agree. (It still seems like a sledgehammer-and-nut situation to me though, especially as we're told by usability people that nwe editors find template formatting and so on offputting.)--Kotniski (talk) 16:44, 2 October 2009 (UTC)
I know I wasn't the only one at the last RfC to state that any attempt to wrap dates in any kind of template (or wikilink syntax) is a bad idea as it leads to confusion for new editors and, in general, clutters up the edit window where encyclopedia writers/copyeditors are actually trying to get work done. A majority of the community at that RfC stated that they did not want any form of autoformatting. Please, please can we finally drop these types of discussions? Karanacs (talk) 16:54, 2 October 2009 (UTC)
I have yet to see a majority of people on either side of this issue, anywhere, although there is no end of people who have declared that there are majorities of people who support various aspects of this debate. Which question is being discussed has a significant impact on who supports and who opposes, as well.
V = I * R (talk to Ω) 20:25, 2 October 2009 (UTC)
Since there are indeed so many different ideas of what should be done, I'd like to have this question answered by anyone (or everyone)- why is it so important that a single way of formatting dates be implemented by Wikipedia, and what harm does not having one single way of doing it cause our encyclopedia, and how would Wikipedia benefit if it did have one single way? I am curious and can not make an informed opinion without those three related questions being answered. Thank you in advance!Camelbinky (talk) 20:43, 2 October 2009 (UTC)
I don't think anyone's suggesting a single way of formatting dates - basically there are two ways (May 1, 1999 and 1 May 1999), with the possibility of using 1999-05-01 where space is limited, as in tables. It is generally considered desirable that a single format be used in the text of any one article (in the same way that we stick to US or UK spelling within any one article). There are a few people who think that this can be best achieved using some sort of special syntax; there were at least two very well publicized RFCs where a clear majority of people rejected this idea (and I'm sure if we asked new editors what they prefer, the majority against would be even more overwhelming). --Kotniski (talk) 08:57, 3 October 2009 (UTC)
Okay, it looks like I have unintentionally opened an old can of worms. Can someone provide links to previous discussions about the subject? I would like to read them for context. Anyway, I understand that date templates would intimidate new editors, that is why I've said several times to give this task to bots. Editors can just enter plaintext dates and bots will come around and format them. At least, that would be ideal; I don't know about the technical limitations of bots. I am not calling for the whole of Wikipedia to use dmy or mdy, but to at least present a standard date format to readers, which will reduce their confusion. Why not use the dynamic date thing but minus the date linking? BlazerKnight (talk) 04:12, 5 October 2009 (UTC)
That's a whole lot of reading for context you're setting yourself - if you've got the time, start with the archives of
WP:MOSNUM from the second half of last year. But yes, we could have a bot which (and this is all it would need to do - adding formatting would just be technical wizardry for its own sake) took an article, looked for everything that looks like a date, used some algorithm to decide whether mdy or dmy was more appropriate for the article, and changed all dates from the other format to that format. But it would make mistakes, it would occasionally identify things as dates that weren't, it wouldn't know what to do with commas after dates, it would sometimes use American-style dates for British-related articles and so on - generally people wouldn't trust it. So this is really something best done by humans using semi-automated tools (scripts) to help them. People were doing that at one point, but because of all the fuss that was kicked up over linking and autoformatting, they had to stop while ArbCom sorted it all out. Now it is sorted out, perhaps they'll start doing it again.--Kotniski (talk
) 08:52, 5 October 2009 (UTC)
While I have no illusions that this specific proposal will actually happen, because of all the history of the date linking issue, I still want to point out a fundamental flaw with it. It proposes the use of the formatting style of the country that the viewer's IP originates from. That is a bad idea. IP numbers are not reliable indicators of the preferred language settings of a user. In fact, IP numbers are not reliable indicators for any localization related information. They might be semi-reliable as indicators of the current location of the user, but that does not mean that the user can be assumed to prefer the language and number formatting used at that location. Those of us who don't live in a country with English as the main language should be able to recall the annoyances a couple of years ago when Google insisted on defaulting to limiting search results to e.g. pages in Swedish, from Sweden. Please, let us all prevent Wikipedia from making assumptions based on the same fallacy. On the other hand, if it is technically possible to obtain the user's actual locale settings e.g. from the browser metadata, that might be useful for choosing a default date format./Coffeeshivers (talk) 14:59, 10 October 2009 (UTC)
Your idea was seriously raised, seriously discussed and seriously considered at
U.S. customary units of measurement should appear first before showing a conversion. You'd need to search through the more-recently-archived pages. I can't remember the details, but it was generally thought that IP was a poor indicator of location, and location was a poor indicator of what the user would understand most readily. —— Shakescene (talk
) 22:53, 10 October 2009 (UTC)
(sidebar comment) I am an anglophone living in the Philippines. It is a frequent source of irritation to me that Google redirects me to Google.ph, which frequently and arrogantly reverts the default language of its pages to Tagalog for users whose IP addresses place them in the Philippines. Wtmitchell (talk) (earlier Boracay Bill) 00:54, 12 October 2009 (UTC)

Have General Fixes Applied Automatically Server-side

My Idea is to use AWB's 'General Fixes' automatically each time an article is edited. Tim1357 (talk) 19:49, 10 October 2009 (UTC)

I think this would be really confusing to novice editors. AWB users are experienced and won't freak out about extra changes, but new users will probably wonder where the hell the other edits are coming from and whether they will break the article. Maybe somehow this could be done with opt-in user preferences but that seems (based on my uneducated guess) like it would be impossible. Calliopejen1 (talk) 20:53, 10 October 2009 (UTC)
AWB isn't (and can't be) correct in every situation. When another human editor is applying it and you revert what you think is an incorrect, inaccurate or inappropriate "general fix", you have someone to argue with, which is good both ways. You can work out between you, sometimes with other editors, and hopefully in a constructive and civil way, whether the fix or the reversion was more justified (or if there's some better third solution that's beyond a robot's capabilities.) But I'd have to know how such an application of AWB would work; would you look like the party responsible for all the fixes that AWB made while you were adding a statistic or adjusting a date? —— Shakescene (talk) 21:56, 10 October 2009 (UTC)
How bout a box that pops up saying "Would you like to apply General fixes? Take note that you are responsible for Its Edits", and then the options "No thanks" or "Preview Changes and submit". Or something of that natureTim1357 (talk) 22:29, 10 October 2009 (UTC)
Not if it's called "General fixes". "Automated suggestions for general fixes", perhaps. Rd232 talk 15:13, 12 October 2009 (UTC)

I am considering building a tool that can generate personalized welcome messages for new editors. More details can be found here. Inputs would be greatly appreciated. Wondrousrecall (talk) 23:38, 6 October 2009 (UTC)

You mean like SuggestBot plus
WP:FRIENDLY? --King Öomie
16:51, 14 October 2009 (UTC)

Little slideshow

Earlier this month, in a discussion at the India talk page, I came up with an idea to better the concept of rotational-images. The problem at hand was too many (good & informative) pictures but just two image places. The current solution is just a rotational image box that changes the displayed image hourly or daily.

But i still feel that a country as diverse as India (having more than fourteen distinct architectural styles) cannot be justly portrayed by a couple of Images, as no architectural style is greater than another and neither can one portray the other.

I suggested at the India-talk page that a little slide show be put up. The slideshow would look exactly like an image box but it would progressively change the displayed image (and obviously the subtext as well) every 5 to 7 seconds. This box may have an extra 3 buttons '<' ,'||' & '>' (previous , pause and next respectively), just in case the user would wish to manually browse and see the slide show. The pause when pressed would changi to a play button, just like the one under a Wiki Sound box.

Wikipedia has perhaps outgrown all the book encyclopedias, thanks to its wiki software. We have to maintain a balance.. by using simple software coding to enhance the Wikipedia, without making it look tacky or snazzy. I see the little slide show a useful contribution to the usability and flexibility to the Wikipedia.

The little slide show is just an idea, i want to promote it so that it becomes a part of Wikipedia. --HFret (talk) 07:26, 13 October 2009 (UTC)

Reference template

I was recently thinking back to when I started editing Wikipedia, and one of the most difficult things to come to grips with was referencing. It wasn't that I had trouble finding references for a subject to go with prose, it was that including these references was tedious and unintuitive. Most of the time I found myself loading featured articles to use their referencing system as a guide, easily doubling the time it took to edit a single article. Editors familiar with the Harvard system of referencing perhaps don't have this difficulty, however I can see a lot of new editors facing similar trouble and simply dumping the information without a reference whatsoever (experienced editors often revert the apparent

WP:OR). In short, I propose that a referencing template/generator could be included on the edit page (not just the <ref/ref> available) allowing for author/date/webpage/etc like the one found at [6]. A quick and simple reference generator could reduce editting time for even experienced users, and benefit to the project as a whole. Iciac (talk
) 08:02, 14 October 2009 (UTC)

You can add a cite button to your toolbar at Special:Preferences > Gadgets > refTools, adds a "cite" button to the editing toolbar for quick and easy addition of commonly used citation templates. refTools is not compatible with the enhanced toolbar, so ensure that Editing > Enable enhanced editing toolbar is not enabled. ---— Gadget850 (Ed) talk 09:45, 14 October 2009 (UTC)
Thanks =) Iciac (talk) 12:22, 14 October 2009 (UTC)

Dealing with frequent AIV backlogs

It seems lately that

WP:ANI
about it each time. In case it isn't obvious why AIV backlogs are a problem: AIV is where editors report repeat vandals for blocking by an admin, following a final warning. If the list of vandals reported there builds, and isn't tended to rather often, it means that vandals are being allowed to continue vandalizing, and the editors who reported them are usually left to keep on top of reverting them, until an admin takes notice. I thought it might be prudent to get some brainstorming going regarding how to deal with this.

My own idea is to have the AIV helper bot automatically post a message somewhere, perhaps to ANI, or to an opt-in list of admins (or both), when the AIV list reaches a certain number -- or when any item in the list reaches a certain age. Welcoming any other ideas as well. Equazcion (talk) 06:43, 10 October 2009 (UTC)

That sounds like a good idea. You could drop a note at ) 19:03, 10 October 2009 (UTC)
Or
WP:AN3 which at this moment has 17 open reports. Next step: programs to collate evidence about open reports to help admins in closing them? EdJohnston (talk
) 19:35, 10 October 2009 (UTC)
What about a page along the lines of Wikipedia:Backlog noticeboard where people report backlogs requiring immediate attention? That way we don't clutter up ANI. –Juliancolton | Talk 00:51, 12 October 2009 (UTC)
I'm not sure if the creation of another separate page will be effective. We'd have to get people to watch it, when everyone watched AN(I) already. AN messages also tend to be most effective at lighting a fire under the collective ass. A separate page just seems like another page to make a list that could frankly get backlogged itself. Equazcion (talk) 01:04, 12 October 2009 (UTC)
It would be relatively easy to attract attention to it, so I don't think that would be an issue. It was just a thought, though, so I'm not entirely set on establishing such a page. –Juliancolton | Talk 01:10, 12 October 2009 (UTC)
A backlog noticeboard for general backlog notices actually sounds like a good idea. I'm just concerned that AIV backlogs are more of an immediacy than other kinds. The message at ANI, if we went that route, would just be a header and a one-line message, I think. I'm not sure myself what would be best. Equazcion (talk) 01:15, 12 October 2009 (UTC)
What about an "admin notice" similar to the site notice. It could be updated with urgent information and dismissible with CSS. — Jake Wartenberg 23:23, 15 October 2009 (UTC)
Ah, you mean like those notices that appear on top of our watchlists whenever there's a meetup or election or something? That is a nice idea. I wonder though if a bot could be given permission to post those. I'm not sure how they work exactly. Equazcion (talk) 07:00, 16 October 2009 (UTC)

Touring Members section on band pages

Why don't we have a touring members section as part of the infobox? In addition to members and former members, I think it would be good to have a Touring members section for band pages; it can help clear the air about who contributed in the studio, who was there for the tour. A band's live history is just as important for fans as their recording history is; I think this section could be beneficial for properly representing everyone who contributed to a band. —Preceding unsigned comment added by 216.248.228.149 (talkcontribs) 20:53, 14 October 2009

Preferences change- Signature section

(From

WP:SIG- I propose that the page actually link to the policy, asking the user to read over it before changing their signature. Never again must anyone witness a signature containing <blink>. --King Öomie
22:37, 15 October 2009 (UTC)

I have done this here. Not sure how many folks will take the time to read it, but the link makes sense. — Jake Wartenberg 23:06, 15 October 2009 (UTC)
Thanks much! Wow, that was fast. --King Öomie 14:00, 16 October 2009 (UTC)

backlinks

each subsection of an article often links to another article through {{main| }}. Why not have a section at the end of each article called 'backlinks' which lists links to all of the subsections (of the other articles) that link to that article using {{main| }}? and links directly to the subsection that has the link. The only trouble I can see with it would be that the list might sometimes get a little long. For that same reason I am not suggesting that all articles that link (by any means) to that article should be listed but rather just those that link to it using {{main| }}. Lemmiwinks2 (talk) 00:50, 13 October 2009 (UTC)

You want the "What links here" function in the sidebar under "toolbox". --Cybercobra (talk) 18:28, 13 October 2009 (UTC)
No, that is a place where "all articles that link (by any means) to that article" are listed, i.e. precisely what the OP does not want. —JAOTC 18:56, 13 October 2009 (UTC)
You're being a tad harsh there. There currently isn't anything that does exactly what the OP wants (well, there's possibly some obscure toolserver or bot thingy for it); WhatLinksHere is the closest extant thing to what the OP is looking for (though yes, it gives all links, not just {{main}} ones. --Cybercobra (talk) 23:12, 15 October 2009 (UTC)
I don't know of anything like that, but it might be useful. Sections containing main article links are supposed to summarize what's in the main article, so it would be useful to be able to find all instances of that and check them for accuracy as the main article develops. Equazcion (talk) 23:30, 15 October 2009 (UTC)
It would also be useful for finding closely related articles which might help one to better understand the main article itself. Lemmiwinks2 (talk) 02:09, 17 October 2009 (UTC)

Footnoted categories

Would there be some way footnoting of categories could be possible? I think some technical changes would probably have to be implemented for this to work, but I think this could be especially helpful in cases of BLPs and the like. If it were technically feasible, would this be something that would have support? The footnote #s would appear on the category bar on the bottom of the article page (again, if this could be technically implemented). IronGargoyle (talk) 21:54, 17 October 2009 (UTC)

Message notification colours

The notification box for new messages is rather intrusive. The default colour scheme makes it nearly impossible not to see (and that's probably good as a default), but I suggest an option in the user preferences to switch to blue, green or purple background, like the

Main page
boxes. This is more friendly and more comfortable to look at. I also suggest centring the text.

Default:

You have new messages (last change).

Suggestions for optional colours:

You have new messages (last change).
You have new messages (last change).
You have new messages (last change).

I know it is already possible to change colours using

user style, but everyone might not be aware of it or know how to do it. If this suggestion becomes an option in the preferences, e.g. under Appearance, maybe we should add a note on the message notification about the customisable colours. Iceblock (talk
) 16:41, 12 October 2009 (UTC)

I don't think that this is a necessary function that we ned to offer. This is a place where people are supposed to be building an encylopedia, not developing a design style. ╟─TreasuryTagdirectorate─╢ 16:57, 12 October 2009 (UTC)
I think it's important to keep the notification colors "impossible not to see". Messages on people's talk pages, such as warnings, are currently used as evidence that a user must have been aware of something. If we introduce the ability to change the notification to be less-noticeable, we also introduce the excuse that "I changed my notification color so I missed that message", etc. Equazcion (talk) 17:02, 12 October 2009 (UTC)
You have a good point, Equazcion. If the ones who wants a friendly notice bar can change it that way, then those who get warnings of course can do so too. Thank you. I withdraw the suggestion. Iceblock (talk) 17:20, 12 October 2009 (UTC)
For anyone who does want to do this, here's how (for monobook at least):

Add the following code anywhere into your Monobook.css file

.usermessage {
   background-color: #ff0000;
   border: 1px solid #ffa500;
   color: black;
   font-weight: bold;
   margin: 2em 0 1em;
   padding: .5em 1em;
   vertical-align: middle;
}

This will change your new message bar into a screamingly bright blood red color that you'll never have to worry about not being able to see. I imagine that's not what most people want, but just for fun I'm going to use it myself for awhile. Note that the only two lines that matter in this code are "background-color" and "border"; you can exclude the rest, but I've left them in in case anyone wants to change more than just the colors. -- Soap Talk/Contributions 19:12, 12 October 2009 (UTC)

Should we reserve orange or red only for urgent warnings?

This does raise an interesting question. Perhaps we should retain orange (or red) for talk page messages that are urgent (you will be blocked! you're being reported! why did you block me?, You Have Been Warned! The next time you...) and allow a softer, less intrusive colour for less urgent messages (Thanks, Barnstars, Could you proofread this for me please? Your Signpost has arrived. Your Wikiproject has a meet-up. You might be interested in this discussion. A request for comment has been opened. I've found the reference you were looking for. I disagree with you because... etc.) —— Shakescene (talk) 08:41, 13 October 2009 (UTC)

I think this is a good idea. Several times I find that, in the middle of a big task, the orange bar appears across my screen because someone thanked me for something I did a few minutes ago, a few hours ago, or even days. If the orange bar is retained only for urgent messages, while others are marked with other colors, then I would know if I need to interrupt my task to read&respond. עוד מישהו Od Mishehu 13:16, 14 October 2009 (UTC)
It might be a good idea but I'm not sure how feasible it is. Currently there's no distinction in the software between a warning message and any other type of message. Simply any significant addition to your user talk page makes the new message notification appear. There would need to be some type of flag added to warning edits, to tell the software what type of message it is. I'm not sure how that might work. Equazcion (talk) 15:55, 14 October 2009 (UTC)
This would certainly require a software change, but perhaps a checkbox next to the minor edit and "Watchlist this page" ones labeled "Mark this urgent". Messages delivered with automated tools could also use urgent delivery when appropriate. — Jake Wartenberg 23:18, 15 October 2009 (UTC)
It might introduce new problems though. A new etiquette and likely a guideline would develop regarding when to use the urgent flag. People might complain about deliberate annoyance from those marking their messages urgent when they're really not, and conversely, those trying to sneak warnings and notifications onto people's talk pages without them noticing. I'm not sure if it's worth all that.
Maybe instead there could an option to have the orange box only appear within a set interval, like once every 30 minutes. for every other message that arrives after the first within a 30-minute period, the box would be softer-colored. This way at least those people who constantly receive a lot of messages wouldn't be constantly hammered on every page load with the annoying box. Equazcion (talk) 23:27, 15 October 2009 (UTC)
This isn't a bad idea either. I would remove the box completely on all page loads after the first time the user sees the orange bar, though, and instead just bold and color the link to the user's talk page at the top. I don't see any reason to put the box back after 30 minutes. — Jake Wartenberg 00:24, 16 October 2009 (UTC)
My concern with removing it after one page load is that pages aren't always loaded at the top. When someone clicks an anchored link or refreshes a page not at the top, they might miss the message. As for after 30 minutes, I think it should be put back if there have been new messages and the user hasnt check the page yet. I think users should be somewhhat "forced" to check it when there are new messages, I just think it doesn't need to be done as often as it is currently. Warnings and such might be important. Equazcion (talk) 00:43, 16 October 2009 (UTC)

Personally, I think the bar works perfectly fine the way it is. I wouldn't want it appearing and disappearing randomly, and adding yet another checkbox for "urgent" just seems

unnecessary. Anomie
03:02, 16 October 2009 (UTC)

Agreed. This seems to be a case of "If it ain't broke, don't overengineer it." Mr.Z-man 03:09, 16 October 2009 (UTC)
Quite right. The current system is absolutely adequate. ╟─TreasuryTagsundries─╢ 16:08, 19 October 2009 (UTC)
I was thinking kinda an AJAX pop-up (maybe looking like those Gnome message notification boxes, so it'd kinda look like a small Notice ambox thing. ViperSnake151  Talk  14:44, 19 October 2009 (UTC)
Ugh, there are few things I hate more on websites than unrequested JavaScript popups (usually things like survey requests), and since they aren't "real" popups, popup blockers can't prevent them. Having a new message on your talk page is not that important. Mr.Z-man 17:30, 19 October 2009 (UTC)

Message notification

Of course, it's possible that with LiquidThreads, this suggestion will be fairly off-topic, but for a while, I've wanted the ability to be notified immediately of changes to other pages than my talk page -- for example, if my userpage is vandalized, I want to know about it right now. Would there be any way to add an "urgent notification" list of pages? --SarekOfVulcan (talk) 17:35, 19 October 2009 (UTC)

Discourage inclusion of duplicate data in multiple related pages

From my database background, I always find duplication of data troublesome because that leads to what us DBMS folks call "update anomalies". In other words, as long as you have duplicate data, every once in a while you forget to update one of the copies while updating another one, and suddenly you have inconsistency within your work that is misleading, difficult to resolve at a later date, and easily leads to doubts over the veracity if any given data element you do have. This happens even in the strictest of formal databases, which is why they're usually designed from the ground up to prevent duplication from happening in the first place, or otherwise the presence of duplicate data is formally recorded, and maintenance of consistency between the several copies is enforced automatically.

Obviously in a free-form textual database like Wikipedia, neither option is available. Nor would good encyclopedia style permit such a draconian rule to be applied without hindering usability, readability, editability, or so on. Nevertheless I think that far too often information is duplicated across articles that have related and/or overlapping content, without thinking about the long-term consequences. In my experience that leads to inconsistency that is detectable on a daily basis -- it just takes a single, panoramic (i.e. everything is interesting, so just about everything surrounding an interesting article is promptly tabbed and also read shortly thereafter) reader like me to see the problem over, and over again. It is very difficult to believe I would be the only one experiencing the dilemma.

Thus, I'd like to propose some kind of editorial guideline which would gently prod people to limit unnecessary duplication, in the longer term perhaps set some guidelines on what can or cannot be "resaid" on a topic, in the even longer term to incentivize people to place information at the one, proper page in the cloud surrounding a given topic, and then in the very shortest term and at the most practical level, to arm those of us with the deduplicating mindset/habit with something we can refer to in the edit summary when we deem it beneficial to deduplicate some data, inevitably deleting and moving text around. Some form of correlated update involving multiple different articles would also help in this kind of work, though I acknowledge that would probably be a bit difficult to implement given the current version control infrastructure. Decoy (talk) 18:01, 19 October 2009 (UTC)

You may be interested in WikiProject Tabular Data --Cybercobra (talk) 21:55, 19 October 2009 (UTC)
Bad idea, if applied too broadly. (1) Readers don't have
WP:pop-ups and won't jump around between articles to extract relevant facts (we don't do it ourselves, and common intuition has apparently been backed up by Wikipedia user studies). (2) In an enterprise like Wikipedia, redundancy is a good thing; it's another check on creeping error. The great weakness of single-entry databases, is that one error infects everything else: your name is misspelled renting a video or enrolling in class, and suddenly (or years later) you can't get a passport. Just think what a malicious vandal could do if he had to change only a single datum. (3) It's often handy to have the same data arranged in different formats for different tastes or different purposes. (4) Many articles (e.g. World War II, Solar System, History of New York City), while able to stand alone, serve principally as summaries and guides to more specialized articles, which would inevitably duplicate data. ¶ However, some system for cross-checking facts is a good idea; editors often don't even know that a different datum is lurking somewhere else. Some of the problem is alleviated by having common data stored in templates or in Wikicommons. —— Shakescene (talk
) 22:10, 19 October 2009 (UTC)
Commons is just for hosting images and other files, it can't help with article texts issues.
talk
) 14:49, 20 October 2009 (UTC)
"Data" is one thing, and does carry the associations of databases and the very real problems of update anomalies. (In some contexts it is better to be wrong than inconsistent, but I don't think that applies here, as Wikipedia is not a "database".) But perhaps the concern here is duplication of whole blocks of text? When googling it's fairly annoying (and fairly common) to have multiple hits on what is essentially the same page (often a copy of the Wiki article!). Is that really starting to be a problem on Wikipeida? - J. Johnson (JJ) (talk) 22:04, 20 October 2009 (UTC)

Cognitive Mapping of Wikipedia

Someone ought to create a cognitive mapping option in Wikipedia. Look at the Wonder Wheel new to Google search. It is a wonderful tool. With the way Wikipedia is organized this would be a relatively easy feature to add. Maybe Google will even provide help. —Preceding unsigned comment added by 146.244.145.206 (talkcontribs) 22:45, 20 October 2009 (UTC)

Common watchlists

Recently, there's been a proposal to enable

popular pages), articles linked on the main page, articles with potential edit-wars, sensitive BLPs, articles linked from google news (see here), etc. Cenarium (talk
) 22:35, 18 October 2009 (UTC)

Related changes (toolbox column on every page) functions this way already, in a technical sense. Editors can create pages with lists of links, and the related changes link would show recent changes to all pages linked there. Equazcion (talk) 22:39, 18 October 2009 (UTC)
I thought of this, and actually it's used for pages like Template:Popular articles and Wikipedia:Biographies of living persons/Noticeboard/Watchlist, we could indeed develop shared watchlist-pages like this. But there's no way to add all pages linked on a given page to your watchlist dynamically, you need to access to the linked changes, it takes time, so not a lot of users would do it, or not often; it could also be prone to abuse. While a link could be given on standard watchlists to the global watchlists central page, and the system would be easy to use, so it could be used widely. Cenarium (talk) 23:03, 18 October 2009 (UTC)
Bugzilla for PovWatch is here. — Jake Wartenberg 23:53, 18 October 2009 (UTC)

I've made a proposal for this at the strategy wiki, and filled T23223 for a feature request. Cenarium (talk) 17:43, 21 October 2009 (UTC)

Some minor cleanup is needed at Special:SpecialPages

At

WP:Hornbook
07:11, 21 October 2009 (UTC)

There are probably more like that - see
WP:VPT).--Kotniski (talk
) 09:32, 21 October 2009 (UTC)
okie doke, I
WP:Hornbook
05:59, 22 October 2009 (UTC)

autoconfirmed for unassisted article creation

Following on from a discussion at

Article Wizard 2.0 was considered good enough (or improved til it is), it might be an option to restrict new accounts from creating articles without using the wizard. Once auto-confirmed, users can create articles without going through the wizard. I'm pretty sure it would require a software tweak to implement this (to allow the Article Wizard to somehow be an exceptional case in this way), so this proposal is essentially about whether to (and/or how to) file a bug requesting that tweak. Rd232 talk
13:12, 14 October 2009 (UTC)

Expanding on that, it occurs to me it could actually be done without a software tweak, if we created somewhere/some way for non-autoconfirmed users to list article drafts they want to put "live" in mainspace, after creating the draft in their userspace. Advantages: no software tweak needed, and an inbuilt review mechanism (replacing most of the workload of CSD and some of PROD/AFD) before new articles go live. Disadvantages: very new users can't put their articles live without assistance by another user; new maintenance backlog (albeit probably mostly replacing other backlogs). Rd232 talk 21:16, 14 October 2009 (UTC)
Sounds a lot like
WP:AFC. Anomie
21:30, 14 October 2009 (UTC)
I don't see how. AFC gives feedback on article ideas, this would merely be reviewing drafts and saying yes/no to moving into mainspace. Rd232 talk 23:15, 14 October 2009 (UTC)
I though
WP:RA was for ideas without content. Anomie
23:21, 14 October 2009 (UTC)
AFC is for drafts also, and upon approval they're moved into article space. Equazcion (talk) 23:47, 14 October 2009 (UTC)
That's exactly what AFC is. We give feedback and try to improve the submissions when we can, because we're nice boys and girls. That being said, the issue of non-autoconfirmed users not being able to create pages is still being raised. ~ Amory (utc) 23:54, 14 October 2009 (UTC)
Well, let me be clearer about what I meant. I envisaged (in the alternate, non-software tweak version) that drafts would be in userspace marked with {{
WP:BITEy, among other advantages. Rd232 talk
10:28, 15 October 2009 (UTC)

RFC

(RFC closed)

Anyway, let's not get bogged down with the alternate version or the implementation. What about the core idea of preventing non-autoconfirmed users from creating new articles, unless they use the Article Wizard? Rd232 talk 10:31, 15 October 2009 (UTC)

Does not seem like a bad idea at all. Should help to curb the staggering about of inappropriate pages we get now. Users often feel bitten when their hard work gets nuked, so this should improve new editor's experiences. — Jake Wartenberg 23:11, 15 October 2009 (UTC)
I thought you already had to be autoconfirmed to create a new article - is that not the case? (Or is it just that you need to have an account?)--Kotniski (talk) 10:38, 16 October 2009 (UTC)
No, you can create a new article within seconds of signing up. Rd232 talk 12:16, 16 October 2009 (UTC)

Absolutely, let's do it. I prefer the alternate proposal of starting in user space, but the original proposal is still fine. --UncleDouggie (talk) 13:27, 16 October 2009 (UTC)

  • Question No firm position on the proposal at this point, but have we had any feedback on the Wizard from noobs or from the Usability brigade? Last I looked at it, it was 10 rounds of "are you sure you haven't done this wrong?" which might prove frustratingly condescending.
    barbarian 
    19:06, 16 October 2009 (UTC)
    • Could you expand on that? Rd232 talk 19:27, 16 October 2009 (UTC)
  • Not so at all. There are areas that are almost completely covered, but also areas that are barely covered at all. --Apoc2400 (talk) 23:47, 17 October 2009 (UTC)
  • Opppose - I agree that this is premature. If we're not ruling out software changes, I don't see why we should limit ourselves to an entirely wiki page/preload based system; its better than a blank slate, but its still rather clunky. Once you get into changing the software, the sky's the limit as to what you can do. However, I disagree with some of the other opposers about encouraging article creation. What we need to encourage is people to do normal editing - adding content and sources - in topics that they have an interest in. We have 3 million articles: nearly half of them are stubs, more than 150,000 have no references at all, and over 130,000 are orphans. This is almost entirely the fault of the quantity over quality approach that we've had since pretty much forever. That made sense when we only had a few thousand articles and needed to improve coverage on important topics; now that we have 3 million articles, it makes less sense to continue that into obscure subjects. In the minutes that I spent writing the last 2 sentences, 15 more article have been marked as stubs. Assuming that the only way to retain new editors is to continue with this approach is short-sighted at best. Mr.Z-man 04:17, 17 October 2009 (UTC)
  • Support Definitely, we should do all we can to let newcomers know about our article formats and what is expected of new articles. I disagree that this will discourage new contributors, as our most valuable new contributors would work to ensure that their articles would meet our standards. This proposal will help alleviate the already strained deletion processes we have and hopefully thin out the backlogs of speedy deletions, the AfD list, and the cleanup categories while promoting the creation of quality articles. Z-man's oppose above raises some good points, but I think his concerns would be alleviated by the article wizard mandate. I disagree that this proposal is premature , although I would suggest that nothing be inacted from the consensus of one RfC; we would need more time to discuss how exaclty this would work. I think the key to this is having a newbie-friendly and non-bitey wizard, which admittedly isn't our forte, but I think we can make it happen. ThemFromSpace 04:58, 17 October 2009 (UTC)
    • The wizard helps people build passable articles, not good articles. At best it might get people to add references, they will still be stubs and many will still be orphans. And it still continues the quantity over quality approach. I'm saying that we need to focus on improving existing articles, not (just) make less-crappy new ones. Mr.Z-man 14:15, 17 October 2009 (UTC)
  • Strong Oppose The software for the article wizard is premature. More feedback is required from new users. Forcing users to use the article wizard is annoying and tiring to many people, and will just push them away. If a vandal wants to create an article on a test page over and over again, like many do, don't you think they can click any links in the wizard and get through to the end? It would help new users if they are directed to use it, not be forced by it. Forcing new users to do something complex will result in a drop of new users. warrior4321 05:05, 17 October 2009 (UTC)
  • Strong Oppose This is a core change to Wikipedia policy; with the recent and ongoing discussions about flagged revisions, and all the press coverage on the statistical reports concerning the increasingly closed-in nature of Wikipedia, a change this significant needs very careful thought. I agree that it is becoming impossible for new users to simply join up and create an article, without wading through lots of policy...but I remain unconvinced that a Wizard is the answer to this. I don't understand people saying how great the wizard is; please - glance through Category:Unreviewed new articles from October 2009 and make up your own mind about the calibre of the articles. Moving CSDs to userspace MfD will not 'fix' the problem; new users need guidance and help, support from the community - not an automated program saying "You can't do this". If only we put a fraction of the enormous (very valuable and appreciated) anti-vandalism efforts into helping newcomers, perhaps this wiki could again open up to wide debate, instead of the alarming current tendency to move toward a closed, elitist group who make all the decisions. A lot more discussion is needed before we take another step which widens the gap between old and new users.  Chzz  ►  10:20, 17 October 2009 (UTC)
  • Oppose—this places too much importance on the article-wizard. I would consider a proposal to allow only autoconfirmed users to create articles full stop, but the -wizard doesn't seem special to me. ╟─TreasuryTagco-prince─╢ 13:16, 17 October 2009 (UTC)

Some stats, all based on entirely voluntary usage: In October, the front page of the Wizard is getting about 2.5-2.7k hits per day [7]; the second page, about 1k [8], the fourth about 500 [9], and the sixth (final before the edit screen) about 400 [10]. The final page has a bit less than 5k hits in October, while Category:Unreviewed new articles from October 2009 has about 400 articles, and Category:Userspace drafts created via the Article Wizard from October 2009 has about 350 drafts. Do we have any comparisons at all with how well newbies do without assistance? What proportion actually create articles, what proportion of those articles get deleted? Rd232 talk 13:40, 17 October 2009 (UTC)

Comment: opposition to this seems to be based on a number of related points. (a) The Wizard isn't ready yet; we need more feedback/development. Fair enough - originally this proposal was caveated with when we think the Wizard is ready.

original Wizard is still around and requires only two clicks to get to the edit page. Rd232 talk
13:52, 17 October 2009 (UTC)

Comment: Also, perhaps those opposing the Wizard might comment on

WP:VPR#MediaWiki:Welcomecreation -> Welcome notice as an alternative way of helping newbies. Yes, it's the much-ignored section immediately before this one! Rd232 talk
13:58, 17 October 2009 (UTC)

Thank you for that. I clicked on "My proposed article does not have good sources (yet)" and was pushed out of the wizard onto a page which effectively says that I should go away and come back later. The wizard at this point doesn't help me make the article or find sources. On that kick-off page {{
find}} is located, but it doesn't help me find sources, nor show me how to use it. I think the Wizard would need re-thinking from scratch, rather than simply tidying up a few words here and there, and I don't have the time to deal with what I have on my plate at the moment so I cannot get involved in reworking the Wizard - though I can see how such a Wizard, appropriately and imaginatively structured, would be an aid to new (and some not so new!) editors. I wish you well. Regards SilkTork *YES!
08:36, 21 October 2009 (UTC)
OK, well I think it would need something quite clever for the {{
WT:WIZ2. And while you may be busy now, do put contributing to improving/reimagining on your todo list if you have any interest; it took me nine months from forming the intention to actually drafting the Wizard, and now it's used by a 1000 people a day. Rd232 talk
09:20, 21 October 2009 (UTC)

Comment. Thanks for everyone's input. To reiterate, the proposal was motivated by discussion at

frak off then". Rd232 talk
17:17, 22 October 2009 (UTC)

Could open up new pages for IPs

This is a Good ThingTM, imo. --Izno (talk) 21:25, 16 October 2009 (UTC)

Interesting idea. I'm on the fence as far as forcing new users to use the wizard, but allowing IPs to create articles via the wizard might be good. Perhaps a trial run of a couple weeks might be telling. Equazcion (talk) 21:45, 16 October 2009 (UTC)
  • Good idea. It would also help allay concerns about restricting new users by, in fact, expanding the way in which anons can edit. Ironholds (talk) 23:33, 16 October 2009 (UTC)
  • Hugely premature again, but to be considered. Cenarium (talk) 23:38, 16 October 2009 (UTC)
  • Support trial. Interesting idea. Allowing IPs to create articles, but only through the Wizard, might well be a good thing in itself, but it would also be a good way of trialling the likely effect of requiring non-autoconfirmed to use it. Definitely worth a trial. Rd232 talk 13:55, 17 October 2009 (UTC)
    Out of interest, how is it technically possible to enable creation-via-wizard only?! ╟─TreasuryTagpresiding officer─╢ 14:43, 17 October 2009 (UTC)
    No idea, but I'm sure devs could figure something out. But it was to avoid this issue that I started thinking about a non-software way to do it, which precedes the RFC subsection of this thread. Rd232 talk 15:09, 17 October 2009 (UTC)
  • I'd support a trial run for this one. -- penubag  (talk) 03:13, 18 October 2009 (UTC)
  • Vehement oppose This has been discussed before after an admin frighteningly was about to let open the floodgates to IPs. This would do absolutely nothing but allow even more crap that must be cleaned up by users who could be doing something else: AFD, CSD, prod, and just patrolling. We don't need more non-notable/unreferenced/unwikified/inappropriate articles from people with zero experience. If someone serious, they can create an account. We should be tightening restriction on who can create articles, not loosening them. Reywas92Talk 18:33, 18 October 2009 (UTC)
Comment How does that correlate to the slogan, "the free encyclopedia that anyone can edit" ?  Chzz  ►  08:08, 19 October 2009 (UTC)
Edit is not the same as create crappy/vandalized new articles. We've had registered-only for years now and it has successfully kept out a lot of spam and other CSD/AFD/prod material, but it isn't enough. Reywas92Talk 21:39, 20 October 2009 (UTC)
  • Weak oppose I think creating an entity is a good thing and helps with attribution, hence am not thrilled with moves away from this. Casliber (talk · contribs) 22:14, 19 October 2009 (UTC)
  • Support This looks like it will help get the good in and keep the bad out. Captain panda 00:30, 20 October 2009 (UTC)
    • What?? Opening the floodgates to anonymous creation will do nothing but let so much more bad in. Reywas92Talk 21:39, 20 October 2009 (UTC)
  • Oppose Back when IPs could create new pages, the large majority of pages on Special:Newpages were in fact IP creations. Not all of them needed to be deleted, but a lot of them did, and a lot of the ones that didn't need to be deleted were so poorly written that they were not really a contribution towards an article on that topic. Jimbo's decision to disallow IP creation of articles was not for that reason, but it seems to me a sufficient reason in itself. --Trovatore (talk) 00:42, 20 October 2009 (UTC)

Deleting well-referenced entries from comparison tables because the item doens't have a WP

This thread is somewhat similar to the thread on deleting empty sections, and an argument for keeping redlinks was that they indicate omissions, instead of giving a false sense of accuracy, where in fact none exists.

My question is whether there exists a policy on removing well-referenced rows from comparison tables because the items they describe do not yet have a Wikipedia page. A particular example are this edit and this subsequent edit, crowned by this edit to Comparison of SSH clients.

If such a policy doesn't exist yet, could we have one? My vote would be to keep redlinks (remove extlinks if that breaks some other policy), for the following reasons, along with the WP counter-reasons:

  • the row information is useful in making a choice based on the comparison table, even if the item doesn't have a page (WP:USEFUL, WP:VALINFO)
  • there was valuable work done to reference the comparison table entry contents (WP:EFFORT)
  • redlinks indicate that there is work to be done. Simply deleting the item does not help anyone:
    • visitors will remain ignorant of the missing item
    • new editors who want to recreate the entry will not know that it has been deleted already,
      • so they will waste time re-creating it,
      • while possibly having it deleted again,
      • and searching for deleted entries is not exactly easy (in the example above, no edit summary contains the word "XShell", if an editor wanted to add an entry for that item)
    • the status of "consecrated" items is not improved by deleting redlinks or extlinks; it would still be plainly clear that an item has a Wikipedia page vs. and external link or a redlink.
    • editors who have a reference for the status of one criterion of an item in the comparison table are less likely to create an entry in all the tables in a page just to add that criterion reference, compared to the situation when the rows were left alone and only one cell needed to be added the reference.

In closing, I think that all that's done by tidying up redlinks and extlinks in a comparison table is giving a false sense of accuracy, where in fact none exists.

-- Dandv (talk) 09:14, 15 October 2009 (UTC)

Redlinks are acceptable as long as there is a realistic and good faith belief that an article on the topic is likely eventually. Just because it is a red link does not mean it cant be in a table.Camelbinky (talk) 12:24, 15 October 2009 (UTC)
there are some lists where by long and unfortunate experience it is unrealistic to have a GF belief that an article is possible. For these, where promotional material is very frequently added, some of us, myself included, watch one or two and remove redlinks unless they seem for some exceptional reason worth trying to source. DGG ( talk ) 01:03, 17 October 2009 (UTC)
I question the phrase 'well-referenced' used in the header above. This edit to Comparison of SSH clients, which was cited by the original poster, did not remove any items which had third-party sourcing. The 'references' were just links to the vendors' sites. Wikipedia needs to see more than just proof that a product exists and is being sold. EdJohnston (talk) 01:23, 17 October 2009 (UTC)
To DGG- if a table or list is to truly represent the article it is important to list everything. Instead of removing the redlink wouldnt it be better to simply de-wikify the particular entry while still keeping the entry? Example- List of World Trade Centers, is either an article or a table in an article (I'm not wikifying the name cuz I'm not sure of the correct name, its not important), but it does not (last I checked) have every every one of the 100 or so WTCs in the world. Wouldnt it be better to have all of them listed and some wikified and some not (and some that may have an article in the future redlinked) instead of having an incomplete list?Camelbinky (talk) 01:29, 17 October 2009 (UTC)

When a lists are of officeholders, elections, teams, contestants, prize-winners, athletic leagues, the constituent parts of a political entity, or sporting competitions, it's essential to keep them complete, regardless of whether each entry has (or will ever have) a separate dedicated article. Anything else would cause serious distortion and remove useful information from the reader. Keeping the red-link or dewikifying it is really a matter of judgement. See, for example,

Oscar contestants and the biggest companies in a particular field or time. —— Shakescene (talk
) 19:10, 17 October 2009 (UTC)

Shakescene, you are perfectly correct for what you mentioned; & I work on such lists too, such as the list of members of the National Academy of Sciences, where all are notable by WP:PROF, and all redlinks should be filled in. . I was thinking more in terms of a list of book stores, or computer programs of a particular sort, or manufacturers of something or other, or librarians, where a list could conceivably include even the least notable of the group. Even there, if someone puts into a list something with enough indication that it probably would be notable, that's OK--& the thing to do is often to write a stub. But otherwise the relevant policy for that sort of list is NOT DIRECTORY. DGG ( talk ) 17:28, 22 October 2009 (UTC)

Easier/better userfication

Suggestion: make it easier to userfy pages. Add a new button on the Move page (after clicking the Move tab) for admins, which when clicked

Could be a WP:Twinkle thing. Rd232 talk 12:45, 16 October 2009 (UTC)

I like the idea of adding this to Twinkle. {{
userfiedpage}}, and a category was discussed at Wikipedia:Userfication some time ago. ---— Gadget850 (Ed) talk
13:17, 16 October 2009 (UTC)
Mmm, well we can certainly use that template instead. On the other hand, we could change the cat name that {{userspace draft}} applies. It employs dated maintenance categories and that may be useful in future. Rd232 talk 13:40, 16 October 2009 (UTC)
Also, minor point perhaps, but I like having "draft" in the name of the template. It clarifies the purpose! Rd232 talk 13:42, 16 October 2009 (UTC)
We could probably merge the templates and add a switch for cats and content. It should refer back to the userfication process for userfied pages. ---— Gadget850 (Ed) talk 14:29, 16 October 2009 (UTC)
Yes, that would be neat. Rd232 talk 14:34, 16 October 2009 (UTC)
I very much like this suggestion. Perhaps also a one-step method to use the last revision of a deleted article (for admins of course). --King Öomie 13:59, 16 October 2009 (UTC)
Good point, you'd need an equivalent on the Undelete tab, for userfying deleted pages. Rd232 talk 14:03, 16 October 2009 (UTC)
Or even just have the Userfy tab function differently on a deleted page. --King Öomie 14:23, 16 October 2009 (UTC)
I was hoping to avoid adding yet another tab! Hence putting it on the Move tab page (which deleted pages obviously don't have). Rd232 talk 14:32, 16 October 2009 (UTC)
We also have Wikipedia:Article Incubator as a variant of userfication. ---— Gadget850 (Ed) talk 14:29, 16 October 2009 (UTC)

Just pointing out that userfication is not exclusively directed toward the page creator (and in fact a large portion of pages I have userfied have been requested by editors who are not the original page creator). Any gadget/button/script that does this should ask for a target rather than assume it is the original page creator. Shereth 14:35, 16 October 2009 (UTC)

OK. My suggestion was coming from a CSD sort of direction, where it's (almost?) without exception the page creator. In other contexts I guess that's not so. Rd232 talk 14:55, 16 October 2009 (UTC)
Visual draft lazily made in paint- [11]. --King Öomie 14:59, 16 October 2009 (UTC)
I wonder how long Wikipedia would be down if the server actually attempted to move the sandbox (and its 30,000 revisions) into userspace. --King Öomie 15:09, 16 October 2009 (UTC)
Moving a page is not a particularly expensive operation, the revisions themselves aren't touched. Mr.Z-man 16:02, 16 October 2009 (UTC)
I love this suggestion, with Shereth's addition of an optional target other than the creator.--Fabrictramp | talk to me 22:45, 16 October 2009 (UTC)
I like the idea, but a caveat might be editors deciding a lot more often, and a lot more erroneously, that articles belong in userspace. Maybe this should be an admin-only function, so they can use it for CSD, certain AfD closings, etc. I'm not sure how much positive use would result from giving this to regular editors. Equazcion (talk) 22:53, 16 October 2009 (UTC)

As I see the process that would be required:

  • Move the page to user subpage, article incubator or project subpage
  • Remove Prod or AfD templates
  • Comment out non-free images
  • Comment out categories
  • Add draft/userfied page notice

---— Gadget850 (Ed) talk 23:08, 16 October 2009 (UTC)

A similar proposal was discussed last month at WT:Twinkle/Archive 17#Adding userfication to Twinkle. Flatscan (talk) 02:43, 17 October 2009 (UTC)
Yes, and perhaps the major concerns arising there are the two linked concerns (a) that stuff gets userfied, but is still search-engine indexed, so it's an easy way to keep something sort-of-on-Wikipedia (b) most userfied stuff goes absolutely nowhere. A can be addressing by adding a template (like {{
noindex}}, or even by changing the way we index userspace (... there was a big RFC on that, referenced in the WT:Twinkle link above). B can be addressed by developing a rule and consequent system for enforcement which basically says that userfied pages are drafts of mainspace articles, and that there is a limited period of time to get those ready, after which the drafts are considered abandoned. It might be a year, and of course the user should be notified, and given plenty of time to respond and perhaps an option to get more time. But the core idea would be "abandoned drafts shouldn't live forever". Of course, if A is fixed, B is less of an issue. Rd232 talk
07:35, 17 October 2009 (UTC)
I think you are missing the 3rd substantial objection - that we shouldn't be encouraging new page patrollers to remove pages from mainspace considering the large % of CSD taggings that are done in error. Noindexing these pages would actually increase the strength of this objection as it would make the process even more like a backdoor CSD than it already is. Thus, the only way I support this if it was admin only. --ThaddeusB (talk) 21:29, 17 October 2009 (UTC)
I take your point, but think it through: isn't it better for non-admin patrollers to userfy incorrectly than to CSD tag incorrectly? Certainly from a
WP:BITE point of view, I'd say that's much preferable. (And that's assuming bad CSD tags caught, and it's just the scary warning message - and surely not all are, leading to some actual deletions.) The problem would be if patrollers start userfying a lot more pages than they would CSD tag; but that's something which might be addressed in various ways (not least limiting userfy access to admins whilst we figure out how to handle it). As long as we're aware of the problem and set up ways to track (a) userfication and (b) subsequent deuserfication (c) some judgement on whether the userfication was way off base, we have to nothing to fear from a trial. Rd232 talk
21:46, 17 October 2009 (UTC)
My point wasn't related to bite - but rather about the removing of valid content from mainspace. Trust me, I am all for reducing bite and also for reducing our dependence on CSD, if at all possible. The thing is that too many patrollers don't really understand the CSD criteria, and far fewer know when its a good idea to userify. The number of errant taggings is partially due to the ease of use of Twinkle, Huggle, etc. and I strongly suspect is there was a new userify option it would be poorly used. That said, I'm not 100% against trying it out as seeing what happens. --ThaddeusB (talk) 04:40, 18 October 2009 (UTC)
How diligent are admins at reviewing
WP:CSD#R2, e.g., following a non-admin userfication? It's plausible that a poor quality article on a viable topic would be userfied indefinitely versus being fixed at AfD. WP:Article Incubator would get the outside input, but could be overwhelmed. I think a, b, and c are great, but I would prefer that a tracking implementation precede a trial. Flatscan (talk
) 04:07, 18 October 2009 (UTC)

Comment. Well it seems I've probably underestimated the misuse issue, both in current practice, and especially if userfication is made much easier via this proposal. But I think that doesn't negate the idea, so much as make a really good tracking/followup mechanism quite important. That should be doable using dated maintenance categories and perhaps bots, and thinking of some guidelines on how/when to userfy and how/when to deuserfy or delete things which the user has abandoned. That sounds like a bigger challenge to hash out than can be handled here - but well worth doing I think. Perhaps we should have an RFC on this issue? If so, what should it cover? Rd232 talk 11:09, 18 October 2009 (UTC)

In the mean time, {{uw-draftfirst}} has been created and added to WP:Twinkle's "Single-issue notices" menu. Rd232 talk 21:06, 19 October 2009 (UTC)

Request: I've drafted Wikipedia:Requests for comment/userfication. I'd like some feedback/suggestions on how to improve this RFC before putting "live" and comments are actually requested. So comments on form, not substance - though any comments on how to make the RFC a success (in terms of having a good, clear debate, not in terms of getting proposals accepted) would be welcome. Rd232 talk 15:25, 20 October 2009 (UTC)

Thanks for writing this up. Where should one give feedback? I have some minor polishing edits that would be easiest to make directly. Flatscan (talk) 03:01, 21 October 2009 (UTC)
Thanks. For minor changes just go ahead. Anything you feel would be better discussed, use the RFC page's talk page. Rd232 talk 08:57, 21 October 2009 (UTC)

Done, converted to Wikipedia:Requests for comment/userfication, thanks for input here, now please comment there! Rd232 talk 16:15, 22 October 2009 (UTC)

Change page that appears when you go to a nonexistant article

New users create speedy-deletable articles all the time, wasting the time of new-page patrollers and admins. See #autoconfirmed for unassisted article creation above for another proposal to solve the same issue.

If we change the text of the page that comes up when a person goes to a nonexistent page in article space to prefer using the article page wizard, more new users would use the article creation wizard and be forced to think about what they are doing.

Current:

Proposed:

This may require a software change, but I pursue this only if there is sufficient support. davidwr/(talk)/(contribs)/(e-mail) 18:32, 21 October 2009 (UTC)

This is produced by MediaWiki:Noarticletext, which any admin can change, if there is agreement. Seems a fairly minor change, but the section above shows a fair difference of opinion on the value of the Wizard... Rd232 talk 15:40, 22 October 2009 (UTC)
I often create a list of redlinks, and click on them, and then click the "search" option, to see if a redirect can be created. I also sometimes type in a possible article direct into the URL, and similarly click "search" to see if I can find something. I do this when logged out sometimes, when finding an article to refer to, not just when logged-in. Not everyone clicking on redlinks or checking for possible articles are actually intending to create articles. Sometimes they are searching without using the search box. I think the current preliminary screen to filter out those who want a different action, is better. At the moment (I'm logged in) the main options on that screen (I wish I could easily find the Mediawiki page that produces that screen) are:
  • Start the XXXXX article, using the Article Wizard if you wish, or add a request for it.
  • Search for "XXXXX" in existing articles.
  • Look for pages within Wikipedia that link to this title.
With other options below that, and a sisterlinks template to the right. I have seen different options displayed when not logged in, so I think non-logged in people get a different message. Non-autoconfirmed accounts, I don't know. Carcharoth (talk) 04:05, 22 October 2009 (UTC)

Should There Be A Wikipedia Foundry?

There should be a Wikipedia:Foundry - Blue if created

The Foundry should be like the sanbox but Foundry content should stay until it's deleted and the Foundry should have games like Word Association (Currently in sandbox but it should be moved there.), Wikipedia Word Game, and the elusive Wikipedia Foundry Game.

I thought Wikipedia was an encyclopedia, not a game. I think the sandbox is just fine. Aiken 09:40, 22 October 2009 (UTC)
Ugh. No. 99.166.95.142 (talk) 16:44, 22 October 2009 (UTC)

Block transiant AP hosted news

Common hosts of AP news, such as http://www.google.com/hostednews/ap/* and http://news.yahoo.com/s/ap/* quickly expire, making them useless in references. These urls should be detected and blocked from being added to wikipedia, perhaps with the spam list. There should be some sort of helpful notice to users on why these urls are blocked, and suggesting they quote from the article, or find other sources for that news.Scientus (talk) 09:33, 22 October 2009 (UTC)

Or they could be encouraged to use a website like Webcite to store the page. Aiken 09:43, 22 October 2009 (UTC)
Could a bot find an alternative AP source, and suggest it somehow (eg to the poster, or on the talk page, or in an HTML comment)? Rd232 talk 13:17, 22 October 2009 (UTC)

Category edit notice

This discussion has been moved to Template talk:Editnotices/Namespace/Category. --David Göthberg (talk) 10:26, 23 October 2009 (UTC)

I've notice anons and new editors frequently (couple of times a day?) trying to add pages to categories by typing them on category pages. There may also be lots more who try this but don't save it when they can't understand why the wikitext doesn't list the other pages in the category, and instead lists loads of indecipherable interlanguage links. Would it be helpful to add an editnotice (Template:Editnotices/Namespace/Category) to inform users of how categories work? Or would that be too annoying to the vast majority of editors who know what they're doing? Something like this?

It should be

kept simple. • Anakin (talk)
04:50, 21 October 2009 (UTC)

Great idea. But given how often Category pages are edited in practice, I'd make it substantially more eye-catching (needs to be for the newbies-in-a-hurry we're aiming at), including use of the warning icon, because that's what's going on here - we're warning people not to make an error (and an info icon is much more likely to be ignored):

Rd232 talk 08:52, 21 October 2009 (UTC)

Using {{PAGENAME}} to give instruction is a great idea, and I agree the blue i is too bland, especially as it's the same one anons see for the
bitey. Something more neutral?  ? • Anakin (talk)
10:11, 21 October 2009 (UTC)
Orange warning icon seems good. I decapitalised the NOT. Do you mean something else about the language being bitey?

Tweaked the first line too, to remove a somewhat confusing-to-newbies reference to "header", and clarify category page use. Rd232 talk 10:58, 21 October 2009 (UTC)

I think this is a good idea. I've noticed this a number of times myself. I actually started working on a user notification template to put on user talk pages when I have to remove this type of material, but many of these edits are from IP addresses where user notifications are often of little effect. A reminder that appears before they complete the edit would be much better. --RL0919 (talk) 17:54, 21 October 2009 (UTC)
I would remove "edit this page to show information about the category, and to list the category's interwiki links and parent categories" completely. It took my 3 read-throughs to parse that sentence and I've been here for 5 years already. This is aimed at newbies specifically, they wouldn't be editing category pages anyway (except by mistake). More experienced uses - who do intend to edit the category - will ignore the warning in any case. Also, please bold the entire sentence To list a page in this category, do not edit this category page. Regards. Zunaid 19:07, 21 October 2009 (UTC)
I'm concerned that anything more than two lines is may annoy some users, and starts to turn into instruction creep. Was there anything wrong with very plain wording similar to how I proposed initially?
I also added {{nowrap}} around the category markup, so that maybe it's easier to copy and paste. I'm still concerned about biting newbies though. The vandalism level in this namespace is very low. Mostly they just aren't sure what to do. • Anakin (talk) 21:43, 21 October 2009 (UTC)

Zunaid makes a good point, so I took out that first line. Still don't see what you (Anakin) mean about biting newbies though.

WP:BITE
usually refers to attacking, admonishing or sanctioning newbies for not knowing things oldtimers know. This is an info message, albeit in a didactic "pay attention!" mode.

Good to go? Rd232 talk 13:26, 22 October 2009 (UTC)

PS While we're on the subject, the link there,
Help:Categorization, could be quite a lot friendlier and more easily understandable for newbies. Rd232 talk
13:27, 22 October 2009 (UTC)
I think that edit notice is okay. I agree about
instruction to categorize one page? I for one have certainly never read it. • Anakin (talk)
15:35, 22 October 2009 (UTC)
Implemented, then.
Help:Categorization, in fact, is supposed to be more technically oriented than Wikipedia:Categorization, though there's a lot of overlap. I've changed the link in the editnotice to Wikipedia:FAQ/Categorization. Rd232 talk
17:13, 22 October 2009 (UTC)

Note: added a div so CSS customization can be used to hide the message (

WP:CSSHIDE). Also semi-protected the template as a precaution. Rd232 talk
07:34, 23 October 2009 (UTC)

Cool. Note that all subpages of Template:Editnotices/ are fully protected automatically by the rule in MediaWiki:Titleblacklist. Only admins can create or edit any of them. It's quite clever. • Anakin (talk) 08:48, 23 October 2009 (UTC)
Oh yes, I forgot about that. Rd232 talk 09:02, 23 October 2009 (UTC)
And I moved the surrounding DIV id into the {{fmbox}} id parameter instead. That is what that id parameter is for. I also added the same name as class parameter, so both using "#category-namespace-editnotice" and ".category-namespace-editnotice" works for the users in their personal /monobook.css.
--David Göthberg (talk) 10:26, 23 October 2009 (UTC)
I have copied this discussion to Template talk:Editnotices/Namespace/Category. I suggest that any further discussion is done there, so it is available for reference in the future to people who edit that namespace editnotice.
--David Göthberg (talk) 10:26, 23 October 2009 (UTC)

How quickly to move new images to Wikimedia?

  • I am tempted to ask about the rights and wrongs of letting new images stay in this Wikipedia for a week or so before sending them to
    Wikimedia. This would help in cases when, as often, someone sets up a page advertizing a pop music group or a company or etc, with a linked-in image showing the company's logo or suchlike. Someone sees the new page and speedy-delete-tags it. An admin finds the page listed in Category:Candidates for speedy deletion and deletes it. He sees that, to finish tidying up, the linked-in image is used only in the advertizing page being deleted and is of use only as part of the advertizing page, so he goes to delete the image, but cannot, as already within a day of being created it has been sent to Wikimedia. Anthony Appleyard (talk
    ) 22:02, 23 October 2009 (UTC)

Idea

Would it be worth it to create a holiday similar to the Great Dramaout where we can tag the some 3,800 odd U.S. government images on this site with correct tags, since the category doesn't really need to be that big, and all of these images can be moved somewhere else? Thanks.

talk
) 19:27, 23 October 2009 (UTC)

Wikipedia in large print project

I know some elders or seniors have a hard time seeing small print so i was just wondering if a large print edition of wikipedia might happen? Seabanks (talk) 00:19, 24 October 2009 (UTC)

If you just mean bigger text size, almost all browsers have an option to adjust the font size used on webpages (usually under the View menu). If you mean a dead-tree version in large print, I haven't even heard of any effort to produce a regular print edition of English Wikipedia, so a large print seems unlikely. --Cybercobra (talk) 00:35, 24 October 2009 (UTC)
And holding down CTRL while scrolling with the mouse wheel will increase/decrease the font size too. Lugnuts (talk) 17:33, 25 October 2009 (UTC)

A board & process to address multiple point copyright infringers

  • WP:CCI

Wikipedia has several processes in place for dealing with limited copyright concerns--single articles or files, even a small grouping of these--but no workable process for dealing with massive multiple point infringement. While

.

I think this is critically needed. Wikipedia has chosen to address copyright concerns proactively, demonstrating

Wikipedia:CCI/Singingdaisies
would bring it to a halt.

Please help address this need. Your comments are much welcome at

12:14, 24 October 2009 (UTC)

Notability of numerous numeral systems

A discussion of the

Positional numeral systems has begun at Category talk:Positional numeral systems#Notability
.

There are currently articles on bases

64
.

Please join the conversation if you are interested. It is a little lonely right now :( Thanks, — sligocki (talk) 09:54, 25 October 2009 (UTC)

My new Template

Hey Guys, I get really angry when i find a dead link on wikipedia. I did some digging, and it turns out that roughly 10 percent of the 2.5 million external links on wikipedia are dead. So, i created a template. This template would be added to all pages that transclude {{Dead link}}, at the top of the article. The template links to a suggestion tool built by User:Dispenser. I hope you like it and tell me what you think!


Tim1357 (talk) 22:49, 13 October 2009 (UTC)

Hopefully User:WebCiteBOT will one day be capable of on-demand runs.—NMajdantalk 23:58, 13 October 2009 (UTC)
My Request is to add this to every article that uses the {{dead link}} template. Can I? I don't know the process that a template has to go through, but I thought I'd post it here before i do the task. If I don't get any complaints then ill be bold and do it. Tim1357 (talk) 02:10, 14 October 2009 (UTC)

Please don't add it to the top of the page. Add it to the top of the section that has the dead links (references or EL). Dead links are not important enough to be posted at the top of the page (unlike unsourced or AfD notices or POV or so). Deadlinks don't indicate a serious problem with the content of the article, but possibly with the verifiability (and even that is debatable, when it is e.g. a proper citenews template where the off-line source is still available).

Fram (talk
) 08:05, 14 October 2009 (UTC)

I don't think this template is necessary. Dead links seem pretty easy to fix, and aren't worth tagging for someone else to fix. Things like article expansion, reference issues, and copy-editing seem more like situations where we need to be able to say "There is a problem, and fixing it would take an effort I can't put in at the moment". This doesn't seem like that kind of problem. Equazcion (talk) 08:33, 14 October 2009 (UTC)
PS. As far as the process a template has to go through, there really is no process. You're already in the best place to try and gauge how useful people think a new template will be. You can try simply using the template, and just wait til someone expresses issue with it. Equazcion (talk) 09:00, 14 October 2009 (UTC)
{{dead link}} is used on about 10,000 articles, so trying it on all of them at once (which would probably take about 33 hours with AWB) isn't really advisable. Mr.Z-man 17:00, 14 October 2009 (UTC)
The part that I really want to get across is the "We have suggestions" link. Dispenser's tool is incredibly useful, but only gets a few hits a day. I want to use this template to increase traffic.Tim1357 (talk) 00:16, 15 October 2009 (UTC)
I still think you could probably use the tool and fix the links about as easily as you could place the tag. But in that case I would consider slimming down the template, perhaps to the height of a single line (probably just requires editing down the text and making the graphic a alot smaller). The current size makes it seem too prominent for the issue it needs to communicate. Equazcion (talk) 00:26, 15 October 2009 (UTC)
Completely unneeded, a dead link does not affect a citation's legitimacy and therefore isnt something that is so necessary to fix and make it seem like we need to encourage a whole new class of editors who think its their job to go around fixing dead links. Maybe more time finding new information to add to articles is a better use of time? It's time to get back to actual fact-finding and AUTHORSHIP versus "EDITOR"-type duties and nitpicky "administrative" functions (not to be confused with the functions of an Administrator on enwp).Camelbinky (talk) 00:33, 15 October 2009 (UTC)
What about {{
internal links}}? It does the same job of advertising a tool that is pretty easy to use. Also, I cannot fix the over 200,000 dead links that exist on the wiki, thats why I was hoping to add this template (with a bot or with AWD) to advertise a tool that can do the job fairly quickly. And i have to contest Camelbikni's opinion that dead links are not important. Wikipedia has no credibility without its sources, a large majority of which are external links. When the links die, wikipedia looses some of its credibility because the information becomes less easy to verify Tim1357 (talk
) 00:42, 15 October 2009 (UTC)
I respectfully disagree with Tim's assertions, though I can understand where he is coming from. The information is/was verifiable at some date, the fact that the internet site no longer is at the url we have on file does in fact make it harder to "verify" but does not make it any less credible. As someone else pointed out many of the deadlinks are to newspapers that move their articles to a different place for archiving or dont archive at all and therefore the print version exists (at a local library on microfilm or wherever) but maybe not on the Web. This puts the information sourced at a redlink in the same category as a print citation that has no URL to begin with. We dont disregard information or discriminate against information that requires you to go to a library and actually do something to look at it. Yes, verifying citations sometimes takes money, time, and effort. It will not always be so easy as clicking on a link in two seconds. "Verifiable does not mean verified by YOU, THIS INSTANT, RIGHT NOW, FROM YOUR COMPUTER CHAIR, FOR FREE, WITH NO EFFORT" is a quote many besides me have used at RS/N and OR/N regarding whether or not something is legitimate just because they cant verify it right away. I believe we recently linked WP:V to a new essay because it became a perennial question, here is the essay created by several at RS/N at my suggestion to help point to our consensuses regarding the issue of "difficult" or "undue burden" on verifying citations.Camelbinky (talk) 01:29, 15 October 2009 (UTC)
In response to Camelbinky's earlier comment, I have to disagree with people who look at the community's editing effort as a finite resource that can only be devoted to one task or another. Presenting the option to go around fixing dead links won't necessarily divert effort away from other "more important" tasks, and refraining from presenting that option won't necessarily mean there will be more effort devoted to other tasks. This may in fact attract attention that otherwise would never have been there in the first place. Authorship is good and "editor-type duties" are also good, and I encourage everyone to help out in any way they can. The task of fixing dead external links in articles is a perfectly valid proposal. Fixing them can only help the encyclopedia. My only concern is that adding new maintenance tags should be done carefully, especially since there are those who think there are already too many, and we don't want articles to get overrun with tags. I would be fine with this tag as long as it is made less conspicuous, and as long as it's placed in the external links section rather than at the tops of articles. I might work on a slimmer version and present it here for consideration. Equazcion (talk) 02:33, 15 October 2009 (UTC)
Here's are my versions:
{{Dead link header/sandbox2}}
{{Dead link header/sandbox}}:
I think those are the less likely to cause "trouble", while still doing the job. Equazcion (talk) 02:52, 15 October 2009 (UTC)
I like the rewrite that Equazcion did to make it less conspicious and agree that at the EL or Ref section is the best place rather than at the header of the article itself. With that perhaps there may be a way to make it clear that tagging these sections does not imply that "if a three months or a year or two years passes and nobody did anything to rectify the deadlink then go ahead and remove the source". Too often this is what happens when someone finds a "citation needed" or "dubious-discuss" tag on a sentence and this idea may be carried over to when you find an old "fix dead links" tag, legit though it may be for citation needed templates to remove them if nobody found a source within a year. Obviously we dont want to make the deadlink header longer or anything, but I just dont want it to be abused. Perhaps, some clarification on a page on how to "use it and not abuse it"? My opposition to this template has always been about it being just another tag that will be abused and used to remove legit information simply because it has been tagged for a long period without the tag being addressed. Could have any ideas ahead of time on stopping the potential abuse before we implement it and we see people arguing on talk pages and the RS/N about "well the deadlink tag was on it for over a year and nobody did anything to fix it, so I decided to remove the information and the link because I cant verify the information" (add your own whining voice when you read that quote).Camelbinky (talk) 03:14, 15 October 2009 (UTC)

I see this tag as simply informative, not like a refimprove tag that warns of impending removal; though we may need more input on that, which we might only get once the template starts appearing in articles. We could leave the date parameter out entirely for now, til more discussion ensues. Equazcion (talk) 03:22, 15 October 2009 (UTC)

My rule of thumb is: if it takes the same work to tag an article than to fix the problem it mentions, then be bold and fix it already. Dead external links can be removed on sight, there's nothing to doubt or check. Even if the web page was moved, gets removed for being a dead link, and it's restored later with the current location, the article wouldn't be considered "incomplete" in the meantime.

Notice that external links and references are not the same thing. A dead link that was used as a reference for something is a problem that may need detailed attention and possibly seek a working replacement, and justify a maintenance tag. External links are not references, they are more links of the type "Foo official site" or "X foo at the Foo Database"

talk
) 13:24, 15 October 2009 (UTC)

A dead EL shouldn't just be removed on site for being dead, as there may very well simply be a new URL that doesn't have a redirection. Just recently I had to change the URL of a very useful page because the hosted site changed its system a bit, but it took me all of ten seconds to figure out what to fix. Of course, there's also a very good chance a deal link will be on the Wayback Machine, in which case changing it to that would be far better than removing it. ♫ Melodia Chaconne ♫ (talk) 14:22, 15 October 2009 (UTC)
Yes, the tool linked in the template can check wayback machine automatically. Also, while external links are sometimes listed as "further reading", other times they are also used as source material for the article. MBelgrano also mentioned the effort it takes to place the tag vs. fixing the problem: My feeling was the same at first, however the OP suggested placing the tag via AWB or bot. Equazcion (talk) 17:19, 15 October 2009 (UTC)
First and foremost- PRESERVE. Tagging is good- removing information is bad. I agree with Equazcion and I for one will start using the tag immediately whenever such a situation presents itself (though I mostly specialize on creating articles from scrap so I dont have this situation often as I dont visit existing articles old enough to have deadlinks very often). If information in an article is sourced to a dead link I really really really hope no one thinks removing the information, the source, or the old link is something they should do. By simply tagging it you can let people know what the old url was, what the information was, and that it needs a new website; people can then find a new one. By removing any of those things you make it harder for someone to know "hey this information, which was here, and now not visible, was important and needs to be updated". Preserve, preserve, preserve.Camelbinky (talk) 01:49, 16 October 2009 (UTC)
I created {{
deadlinks}} for use. It combines the small and large versions I presented above. Default display will be the centered long slim version, and the parameter small=yes will display the short left version. Will add documentation soon. Be very prepared for complaints though, just warning you. Equazcion (talk
) 02:51, 16 October 2009 (UTC)
Great!, ill get to adding those soon. I agree that the information should NOT be removed because of a dead link. Can anybody help me with some regex? I want to be able to add this template after the heading on a section that contains a {{dead link}}. Any Ideas? Tim1357 (talk) 11:01, 16 October 2009 (UTC)
I don't understand. What information does a dead link provide? What is there to preserve by keeping them?
talk
) 12:22, 16 October 2009 (UTC)
They provide clues as to what kind of link should be found to replace them. Like I said, the tool linked in the template can automatically check Wayback Machine for previous archived versions of the same page, and automatically replace dead links with those. Sorry Tim, I don't know much regex. Equazcion (talk) 15:53, 16 October 2009 (UTC)
Thanks to User:Rich_Farmbrough for the regex
Find (\n==+[^\n=]+==+ *\n)((?:[^=\n][^\n]*\n)*)([^=\n][^\n]{{[ _]*[Dd]ead[ _]+link[ _]*[\|}\n])
replace with $1{{dead link header}}\n$2$3

Tim1357 (talk) 00:26, 21 October 2009 (UTC)

BRFA filed here Tim1357--(what?...ohhh
) 01:47, 25 October 2009 (UTC)

BRFA removed do to lack of consensus- lets get some discussion going here. So tell me wikipedia, what do you think of this template? Tim1357 (talk) 21:19, 26 October 2009 (UTC)

A use for cut-and-paste moving?

  • It is often said that cut-and-paste moving a page is a Very Bad Thing, and as an administrator I often have to history-merge to repair old cut-and-paste moves; but there seems to be one place where cut-and-paste would avoid a difficulty.
    If the number of edits in a file's history gets over or near 5000, deleting it (including temporary deleting as part of some tidying operation) is not allowed except for a few special people. (I know why: there have been incidents when trying to delete a page with an enormously long edit history has made Wikipedia crash.) This restriction on long deletion can cause inconvenience, as in an incident with page Apple which is described by Talk:Apple#Old cut-and-paste moves affecting this page and Wikipedia:Village pump (technical)/Archive 44#Page deletion revision limit. I am tempted to suggest discussion of (but NOT to advise it until it has been throroughly discussed):
    1. If a page's edit history gets near 5000 edits long, what would be the rights and wrongs of moving the page to an archive name and cut-and-paste moving it back to its correct name, to stop its edit history from getting too long?
    2. When finding if the page's history has over 5000 edits, the deletion software should count the edits in the page's history exactly and not by estimating: see the end of Wikipedia:Village pump (technical)/Archive 44#Page deletion revision limit.
    Anthony Appleyard (talk) 10:44, 23 October 2009 (UTC)
    • I could be getting this all wrong cause I'm not an admin, but... You could just do your proposed move to the archive when you need to delete a page with a long history, rather than archiving being standard practice when a history gets to a certain limit. You wouldn't even need to copy & paste back, just create a blank page in its place, delete it, then move the page back from the archive. This could be defeating the purpose of the delete to begin with though, or something, cause like I said I'm not an admin. Just theorizing :) Equazcion (talk) 05:50, 24 October 2009 (UTC)
  • That is, if a page with greatly over 5000 edits can be moved easily. Leaving large amounts of deleted edits sitting under a visible page may cause trouble if the page must be temporarily deleted and then undeleted for some housekeeping operation. Anthony Appleyard (talk) 10:38, 24 October 2009 (UTC)
  • Comment: I frequently do selective deletions in handling copyvios, and this seems like a potentially useful idea for me, so long as (of course) attribution is provided at the start with a link to the archive and probably the use of {{copied}} at the talk page (in accordance with the under-proposal Wikipedia:Copying within Wikipedia). I think to avoid vandalism on these unwatched archive pages (some of which will certainly involve living people, for instance), protection might be a good idea. --Moonriddengirl (talk) 11:30, 24 October 2009 (UTC)
  • Currently, I cannot delete some edits, but only delete all the edits and then undelete some of the edits; and the deletion runs into the same snag as in the Apple incident, if it has around or over 5000 edits. Anthony Appleyard (talk) 18:35, 24 October 2009 (UTC)
I agree that the revision history should be kept intact so it can easily be read by computer programs. With
RevDel, there are extremely few reasons why pages will need to be deleted and undeleted, especially well-established ones. Mr.Z-man
21:20, 25 October 2009 (UTC)
How often do such maintenance works have to be done on articles with 5000+ edits? Mr.Z-man 23:49, 25 October 2009 (UTC)
Not very often - apple and football are the only pages that I know of where it really needed to be done and it was difficult. It would've been nice at WalMart (see the early history with duplicate edits, which now can't be un-separated due to the way MediaWiki works with deleted revisions), and I somehow managed to bypass the restriction while working with the RMS Titanic page. Speaking for myself, I've gone through many of the pages with the most revisions in case they needed a history merge, and none of them needed one that would require selective deletion. The ones that do are incredibly obscure cases.
As for updating page history analysis programs, most tools like that are written and then forgotten about later, and people are reluctant to update them. Graham87 08:49, 26 October 2009 (UTC)

Revision deletion - the solution?

Isn't this the sort of issue Wikipedia:Revision deletion is intended to solve? Hiding T 14:25, 26 October 2009 (UTC)

It wasn't designed to solve this issue, but it
probably can be used that way. Graham87
16:36, 26 October 2009 (UTC)
Maybe not, especially when edits would significantly overlap; see this message at Wikipedia talk:Revision deletion. It deletes pages in a different way than regular selective deletion. Graham87 16:40, 26 October 2009 (UTC)

default javascript variables for page layout colors

how about defining some default javascript variables like 'foreground color', 'background color', 'link color', 'highlight color', 'user message color', 'warning message color', 'infobox color', ...etc then people can redefine them in their user javascript page and editors can use those variables when creating the layout for a page. yes i know that some of these can already be set in user css but there are some div's and span's in some pages that cannot be set because they are given no id. Lemmiwinks2 (talk) 18:47, 26 October 2009 (UTC)

I would suggest Bugging it up to get IDs on those things that might be wanted... --Izno (talk) 05:02, 27 October 2009 (UTC)

Share price information

Hi all. Wikimedia UK recently received a phone call from a UK company interested in providing information on share prices to articles on businesses, in a regularly updating way. Their follow-up email said:

... the page that I was looking at was BAE Systems and on the right hand side you feature general information on the company - It’s location, history, sectors and financial position - the one thing missing from here is the shares price of the company – yesterday’s closing price and possible some historic information. Now I have much more information available than just this, for example I hold the historic share prices for all listed companies going back ten years, their financial reports all regulatory news filings and much more. So I’m very open to a wider discussion over what information would be of use to add.

My initial reaction to this is that it's a good idea, and that it should be technically possible (e.g. a bot could be written to keep the information up to date on a daily basis). This isn't my area of expertise on Wikipedia, though, so I'd welcome everyone's viewpoints on whether it's worth pursuing. So, what do you think? Mike Peel (talk) 16:31, 20 October 2009 (UTC)

I'm not sure share prices are encyclopaedic, really. They are just arbitrary numbers unless you actually want to buy or sell the shares. The
market capitalisation updated daily and a 52 week high and low market caps might be more useful. --Tango (talk
) 16:44, 20 October 2009 (UTC)
Historical numbers (highs and lows, yearly averages or whatever) would be useful. More frequent data - no. Also, we'd have to be sure they actually have permission to provide that data - it might depend on how they acquired the data. Rd232 talk 16:52, 20 October 2009 (UTC)
The closing prices are public knowledge, as usually are 10-15 minute (depending on the exchange) delayed intraday prices. We certainly don't need real time prices. In fact, going directly to the exchange would be better if we do want this data - they probably have RSS feeds of it or something, a bot could easily read an RSS feed and update the infoboxes. --Tango (talk) 19:40, 20 October 2009 (UTC)
I really don't like this idea. Useful does not imply notable and if people want this information there are other places to get it. What would be next, up to the minute weather conditions for major cities? traffic reports? local TV listings? Notability generally does not change over time and what will not be notable tomorrow is certainly not notable today.--RDBury (talk) 22:39, 20 October 2009 (UTC)
Notability is not a content criteria (excepting certain types of lists), it's an article topic criteria. But yes, we do have to ensure articles aren't full of trivia cruft. --Cybercobra (talk) 00:57, 21 October 2009 (UTC)
As noted above, share price in isolation is rather meaningless. However, I do believe the market capitalization data is an important piece of information. I don't think we need daily updates, but perhaps once a week updates would be good. --ThaddeusB (talk) 01:15, 21 October 2009 (UTC)
I'd have strong reservations about anything requiring more than annual updates. Rd232 talk 08:37, 21 October 2009 (UTC)
It also relies on an outside tool to provide dynamic content. ---— Gadget850 (Ed) talk 13:03, 21 October 2009 (UTC)
How about we don't include the market cap, we just include the 52 week high and low market caps (and perhaps the dates they were hit)? We can then update that on a regular basis (daily would work, since they won't actually be changing very often so a given article won't be updated that often). --Tango (talk) 13:15, 21 October 2009 (UTC)
  • Generally a bad idea, but all-time highs or all-time lows might be useful for very large companies whose extreme highs or lows were related to major outside events. For example "Acme Widgets supplied Widgets to the government and industry from its founding after the civil war through 1920s, but the combined effects of a military procurement scandal and the Great Depression led to their bankruptcy in 1931. At its peak in 1928, they were valued at $123M with a share price of $15 1/4, ranking in the top 50 United States companies by market capitalization." For famous companies, e.g. Fortune 500 or national equivalent, the market capitalization as of the preceding December 31 might be useful. More useful would be the company's ranking within its home country by market capitalization as of the previous year-end. davidwr/(talk)/(contribs)/(e-mail) 18:41, 21 October 2009 (UTC)
    Yes, that's the kind of thing I was thinking of. Rd232 talk 13:31, 22 October 2009 (UTC)

PLEASE please PLEASE - can I be a voice against any suggestion that Wikipedia gives us daily news of the stock exchange? Sorry, but I get bored enough with the fact that on weekdays, the BBC news, several times a day, tells us how the 100 share index and the Dow Jones index are faring. I do not know about other people, but I have long considered the news of the 100 share index and the Dow Jones Index by far the most boring thing on

BBC Radio Four. ACEOREVIVED (talk
) 20:53, 27 October 2009 (UTC)

Numeric data tickers

Many of the articles contain numeric data which is updated frequently and hence is out-of-date or contradict similar data on other articles (e.g. Zimbabwe's population). A database of tickers of numeric data should be created, to which links from the articles' code will point and pull out the necessary number to be embedded into the text. That way, updating a numeric data will be done only once and data across different articles will be consistent. The ticker will be a seperate page on Wikipedia which can be easily updated. It will contain a number, a date of last update and the source of the data. An appropriate refernce can be automatically created on the article in whch the ticker was used.


This is how the code will look like:

 Zimbabwe's total population is <<numticker==population_zimbabwe>>.

This is how the text will appear in the article:
Zimbabwe's total population is 12,000,000
[1].

References

  1. ^ numticker:population_zimbabwe last updated July 14th 2007, source: Zimbabwe on the CIA's World Factbook

The Good Samaritan (talk) 17:17, 25 October 2009 (UTC)

This is essentially what WikiProject Tabular Data is working towards. --Cybercobra (talk) 18:10, 25 October 2009 (UTC)
Is this necessary? It seems like a good way to make things much more complicated than they need to be. • Anakin (talk) 20:36, 26 October 2009 (UTC)
It's annoying to update a statistic in 5 different places (and then 2 out of the 5 get missed because the updating editor doesn't happen to know the stat is being used on those pages). --Cybercobra (talk) 21:12, 26 October 2009 (UTC)
That is true. However, it may be the lesser of two evils [that is, this proposal is the worse], since something like this would make lots of articles a lot harder for the "amateur" to edit. I appreciate the problem, but most people know such figures can be out of date. -
the petition
! ] 22:02, 26 October 2009 (UTC)
To allow the editing of data that is displayed in several places in a single place is an excellent idea. It could even apply across different languages. We already have templates and wiki markup used liberally, this seems no harder to grasp than usual. Fences&Windows 00:05, 27 October 2009 (UTC)
It would be considerably harder for somebody with little knowledge of WP to edit it, or confuse them entirely. The question is whether that's a price worth paying (it may be, I personally don't think so). Compare:
  • The population of Eritrea is estimated to be 4,141,000.<ref>UN report...</ref>
  • The population of Eritrea is estimated to be {{Eritrea-population}}.
Unfortunately, the template name could be more complicated as well (for clarification, for example). Smaller issues is the ref inside the punctuation, because of the template system, not being able to edit the ref obviously (or figure, less importantly), and different ref styles for different articles. These are problems, but I can understand the positives - less factual confusion for example. - Jarry1250 [Humorous? Discuss.] 21:02, 27 October 2009 (UTC)
Another problem with that idea is the fact that a centralized data repository would probably have to be protected (owing to its transclusion on several pages) and inaccessible to many users; an open project like Wikipedia should be striving to have as few "protected" areas as possible. Shereth 21:34, 27 October 2009 (UTC)

MediaWiki:Welcomecreation -> Welcome notice

MediaWiki:Welcomecreation

The welcome notice above,
WP:SIGNUP
. I imagine most newbies click right through it, which is a shame, as it's quite useful (and of course could no doubt be improved...)
Proposal: ask for a software change so it's shown at the top of every user talk page, until such time as they click a "Dismiss this notice" button. (There could be a preference option to re-enable it.) This approach leaves the talk page redlinked, whilst providing very accessible information to the user.
To be clear, on registered accounts, the software would then take newly registered users to the user's talk page, instead of this screen, showing the user where that help info can be accessed anytime. It would be shown permanently at the top of the user talk page, until the user dismisses it. Rd232 talk 22:00, 17 October 2009 (UTC)
If they don't want to read it, then they don't have to. Wikipedia already has too much instruction creep, and adding more instructions that aren't read anyway rarely improves anything. --Apoc2400 (talk) 14:50, 18 October 2009 (UTC)
I can't think of a less appropriate response to this proposal that doesn't involve llamas. ... This isn't more instruction, it's moving the existing instruction to somewhere new users can always find it easily (until they no longer want it), whilst at the same time showing new users where their user talk page lives. And the reason I'm speculating that most users click right through it is that users will generally sign up in order to DO something specific, so they want to get on with that, and perhaps if they get stuck or have issues afterwards they might be willing to RTFM. I created a test account recently and my immediate reaction was "er, how do I get back to that help screen?". The proposal comes from the context of the debate about Welcome bots and Welcome messages, a large part of whose function is to give newbies tips on where to find help. Rd232 talk 08:15, 19 October 2009 (UTC)
Any user who's been welcomed has a string of handy links at the top of their talk page, and yet, many of them seem to have very little knowledge of how/what to edit, or appropriate ways to do so. It's not that people don't have the tools at their disposal- they just can't be bothered to use them. --King Öomie 14:26, 20 October 2009 (UTC)
"Any user who's been welcomed" - yes, but many users aren't welcomed, or aren't welcomed very soon after signing up. This takes care of that. It doesn't ensure world peace, or make all newbies RTFM. It just ensures they have no excuse for not knowing where the manual is; and hopefully a few will be helped. It just moves a message from somewhere newbies can't find it again to where they can - that is all. Rd232 talk 14:36, 20 October 2009 (UTC)
EH! It seems like an attempt at making all newbies "conformists" and "good little editors who dont question how we've already decided how to do things". Our policies and guidelines are specifically stated to "not be laws" and that Wikipedia "does not have a rulebook". We should be encouraging newbies to NOT be conformists, and while they should respect and adhere to the spirit of our past consensuses encoded in policy and guidelines and essays etc, they should feel free to question "why?" and "wouldnt it be better if..?" The next newbie might have an interesting new perspective and thought that gets encoded into policy. If we start "indoctrination" as soon as they sign up we might lose that and they become "rules quoters" and "strict interpretationists" about our policies and guidelines. All Wikipedians are entrusted EQUALLY in enforcing policy, newbies should know that AND they should know they get EQUAL say in how they should be written. There was no cut off where we say "oh, you werent around when we wrote WP:xyz, sorry your opinion is too late; cant rewrite this law, this is the way it is". I've helped rewrite policies and guidelines and essays, I contribute to AN/I, OR/N, and RS/N and yet I probably have not read every single policy let alone every guideline, and I know the 5 pillars of Islam more than I know the 5 pillars of Wikipedia; so thinking that newbies must read them or be encouraged to read them is ridiculous. I know its getting long, but I'll sum it up thusly- any "welcome message" should say this and only this- "Thanks for signing up. The only thing you need to know is that as long as you are improving the encyclopedia we ask that you- HAVE FUN AND ENJOY YOURSELF!"
Wrongo. WP:V and a handful of others are rules, and rightly so. We should encourage newbies to conform to them. They're entirely free to question why, but not in their first edits to WP itself. There's scads of evidence that large numbers of people have fun and enjoy themselves [Are these two distinguishable?] while even managing to convince themselves that they're improving matters by adding firsthand observation, gossip, stuff half-remembered from third-rate teevee shows, and miscellaneous other truthinesses. Yes, people should be welcomed. No, they shouldn't be expected to read WP's turgid policy pages before advancing further. But having fun and/or enjoying oneself shouldn't be overpromoted. -- Hoary (talk) 02:46, 25 October 2009 (UTC)
When's the last time someone saying "wrongo" to you felt good? But I digress. Equazcion (talk) 06:09, 25 October 2009 (UTC)
  • This is a good idea. The responses above which essentially say "new user need less instruction, not more" baffle me. --ThaddeusB (talk) 06:02, 25 October 2009 (UTC)
    • Thank you! Most of the responses so far have baffled me somewhat. Criticism of the contents of the existing MediaWiki message has nothing to do with the usefulness of its location. Anyway, I should point out that, technically, if this were implemented we'd be talking about creating a new MediaWiki message and adding a switch (if there isn't one already) to turn the existing one off. This would be necessary for backwards compatibility; on English Wikipedia, we'd then turn the current message off, and only use the new one, in the new location. That happening would probably be a good opportunity to talk about redesigning the contents of the message, but that's completely separate. I fear I should have posted this on
      WP:VPT... Rd232 talk
      12:49, 25 October 2009 (UTC)
Brilliant solution. I've just created a new account to test this, and as soon as I'd logged out and logged in again it was gone. My suspicion is that many newbies lose that screen without realising that they can't get it back. ϢereSpielChequers 21:57, 26 October 2009 (UTC)
Exactly. Does anyone know how to file a bug to request this? Rd232 talk 14:32, 27 October 2009 (UTC)
It's pretty easy to start a bug report. I can do it, if someone wants to write a proposal (should be detailed, something the programmers can use to make it happen without too much more discussion). Rd232, with all the feature proposals you make, you might like to make a bugzilla account and start finding your way around the site, so you can file requests yourself :) Equazcion (talk) 17:25, 27 Oct 2009 (UTC)
Ha, well I have an account (used to vote on a couple of bugs) but filing a bug seems a bit more scary, I'd rather avoid that learning curve, at least for now. Incidentally, I found (from bug 4914) Extension:NewuserMessage [12], which automatically adds a welcome message into user talk pages (but as far as I can see, it turns the redlink blue, and we don't want that). Is this specific enough? (a) a switch to turn off MediaWiki:Welcomecreation; (b) a new message MediaWiki:Welcomecreation2, to be shown to new users at the top of their user talk page (maybe in the sitenotice location, maybe below the "User talk: X" header), until they dismiss the message, by clicking a "Dismiss this message" box. (c) a switch to turn MediaWiki:Welcomecreation2 on. Rd232 talk 17:46, 27 October 2009 (UTC)
I have to run out right now, but if no one else has done this when I get back in a couple hours I'll do it. In the meantime though could you just explain what you mean by "a switch"? Do you mean a permanent change, deprecating one notice and activating another? Or woudl that be a dynamic switch? I'd just like to understand fully what I'm posting at bugzilla. Thanks. Equazcion (talk) 17:54, 27 Oct 2009 (UTC)
By "a switch" I mean "a variable". So adding two variables to the software (LocalSettings.php, I think) to control display of the two messages, and in the case of English Wikipedia, setting the variables so MediaWiki:Welcomecreation2 is displayed, and not MediaWiki:Welcomecreation. Rd232 talk 18:29, 27 October 2009 (UTC)

Another thought: this is simply too long. How many people really read all of that? We need to boil it down to two, maybe three bullets so that people might actually look at it. What is the essential information needed? I'd say that we could dump "To customize the site's appearance and other options, change your preferences.", "Don't forget to sign your posts on talk pages by typing ~~~~, but don't sign encyclopedic articles.", "You are welcome to upload and insert images in articles, but it is imperative you follow the strict image use policy and respect the rights of the image's creator." (I think that Special:Upload has enough about this), and "(Please note that we can only assist you with Wikipedia-related help. For general enquiries, you may wish to ask at one of the reference desks. We cannot offer medical or legal advice under any circumstances.)" could go, at the minimum. —Ed (talkcontribs) 04:58, 27 October 2009 (UTC)

Possibly, but I'm not interested in discussing the content at this point. Please start a new thread (or discuss on the relevant talk page) if you are. Rd232 talk 14:32, 27 October 2009 (UTC)

Website navigation/usage changes

I'd like to make a few suggestions with the aim of transforming WIkipedia into a more functional study/learning tool.

  • "Saved pages" linking a page to an account, similar to bookmarking on browsers but available via a wikipedia account so it may be used away from one's own computer.
  • Highlight function, available on your own saved pages to selectively highlight text
  • Possible linkage to email accounts

I apologise if any of these have been discussed already.

Aarafat (talk) 08:12, 27 October 2009 (UTC)

How are #1 and #3 not already the case today? For the first suggestion, there is the special:watchlist; for the third, you can choose to enable an email in special:preferences. --Izno (talk) 13:29, 27 October 2009 (UTC)
For #1, I had something a bit simpler in mind, its very informative but clunky. Perhaps just date and article name with the rest viewable on mouseover? With #3, how about linkage to email such as signing in with that email onto the wikipedia site similar to the system in youtube, widgets within an email site for say random articles/facts which would work well with google wave (although that would have to be managed by google, as its probably out of scope). But then again these aren't that necessary to the use of this site. Aarafat (talk) 12:17, 28 October 2009 (UTC)
There is also
WP:WIKIMARKS. –xenotalk
15:54, 28 October 2009 (UTC)

Main page feature suggestion

Hi i have suggestion, to have a "Today's featured article" section is great, but wouldnt it be good to have a "Article that needs your help" section to (or similar name). Where everyday 1 or up to 5 articles are posted which are in need of help, which could be any article basically. As long as it is not a Featured article. My suggestion would be to have a similar style like the "Todays featured article" with one listed article everyday that is todays help article, or to have a list of 5 articles that is todays articles that need help from the editors. Please come with more suggestions and we might get some consensus. would be nice. But my main suggestion is to have one article per day that is under the "Article that needs your help which perhaps could stand beside todays featured article or in a small column or similar. --Judo112 (talk) 21:24, 12 September 2009 (UTC)

  • My main reason for the suggestion is that i think that there is thousands of articles that could be mutch improved if more people knew about them and paid them attention. I also believe that it is a project that could improve the overall standard of articles on Wikipedia.--Judo112 (talk) 21:33, 12 September 2009 (UTC)
  • Support Gosh, I think this is a very good proposal. (Be warned Judo112, that you will certainly meet great resistance by a few very loud and conservative people. But don't discourage! I'm also happy to help you out if you feel discouraged.) GeometryGirl (talk) 21:35, 12 September 2009 (UTC)
  • Dont worry im up for a fight;) No but seriously i hope that most of the Wikipedians see the greatness in this idea and that it will improve the overall standard of Wikipedias articles tat sometimes is low and sometimes is very high.--Judo112 (talk) 21:47, 12 September 2009 (UTC)
  • Strong support. The idea of a temporary collaboration has sprung up in myriad incarnations since 2001 – COTW, ACID, all kinds of WikiProject collaborations – but I think this is the kind of idea that needs a full-force reboot. Putting one article on the main page every day to be improved would do so much: it would rekindle some of the community magic lost in the last few years; it would encourage new users and help train them; it would actually convince people to start editing again. This is far more important, in my view, than ITN or DYK.
    If you have too many articles, people will just ignore it. Highlighting a single article (which would be chosen much in the same way as the main page FA – underrepresented subjects, with clear and actionable paths for improvement) and giving it as much attention as possible would go much further than anything we've tried before. I absolutely support this idea. —Noisalt (talk) 21:44, 12 September 2009 (UTC)
    • Yes, and per Noisalts idea i change the first suggestion to One single article everyday as it will be the most effective. Hope to see a strong support for this so that we can start having this feauture on the main page up soon. Also agreeing that the "DYK" section could be moved or removed in favour of this new section which would be so mutch more productive.--Judo112 (talk) 22:03, 12 September 2009 (UTC)
  • I guess I'm loud and conservative. Protonk (talk) 23:17, 12 September 2009 (UTC)
  • Support I love this idea, and this would be a great way to improve articles. However, a few questions remain.

    1. Which articles will be chosen?
    2. How do we nominate and choose articles? Will it be like FAC?
    3. Will new criteria have to be created?
    4. Won't it be a huge vandal attractor? Will it have to be semi-protected? Does that ruin the purpose? warrior4321 23:38, 12 September 2009 (UTC)
  • Certainly any vandalism it attracts because of it would be dealth with swiftly for the same reasons. ♫ Melodia Chaconne ♫ (talk) 00:08, 13 September 2009 (UTC)
    • A possible answer for questions 1, 2 and 3 would be: pick a stub at random. There would be no nomination, no criteria, etc. GeometryGirl (talk) 00:20, 13 September 2009 (UTC)
      • The fact that you said stub means that you want criteria. The proposal is for the improvement of articles, not expansion of articles. This would mean that even a GA article aiming for FA would be able to fit in this proposal. This is why criteria is required. What do you mean stub chosen at random? By whom? When? If we allow stub choosing at random, we would get around 500 putting their stub that they just created over there. For something that is going to go on the main page, this will require some organization. warrior4321 00:27, 13 September 2009 (UTC)
        • This was just an idea. Basically there are thousands of stubs. My idea was to pick out one stub of all the existing stubs at random (using a functionality similar to Special:Random) where all stubs are equally likely to be picked (so that there is no bias). GeometryGirl (talk) 00:40, 13 September 2009 (UTC)
          • The main page is intended for readers, not editors, so perhaps it wouldn't be best to put this on the main page? Of course there is also the issue of where you would put it, the main page is full already. Prodego talk 00:41, 13 September 2009 (UTC)
    • Which articles will be chosen? How's C-class or lower sound? Will new criteria have to be created? I would suggest that articles be on approachable (non-technical, non-obscure) topics; those which a random, but interested researcher without specific expertise could reasonably make constructive contributions to. How do we nominate and choose articles? Will it be like FAC? I hope it would be lighter-weight than FAC. --Cybercobra (talk) 01:33, 13 September 2009 (UTC)
      • My one concern with this proposal is: we have a huge backlog of articles that are very long and moderately well-written but just don't have any sources cited, so they languish outside the GA/FA process. New editors aren't going to be interested in adding inline citations, so we'd just we adding to that backlog. —Noisalt (talk) 02:34, 13 September 2009 (UTC)
        • Any article should be able to be choosen as long as its not a featured article according to me. If B-class should be a highest level of artcile can be discussed(but sounds good to me). In my opinion we could remove the DYK section in favour of this one. What i also mean is that people can do whatever they can to help improving the article listed, i mean every article is helped when there is many edits .--Judo112 (talk) 06:17, 13 September 2009 (UTC)
          • I also think that FAC process of choosing article for the day is the best way. If there is vandalism we just have to protect it when it comes to that. On Wikipedia there will always be vandals but most people wants whats best for the wikipedia.--Judo112 (talk) 06:19, 13 September 2009 (UTC)
  • Historically, the general consensus has been that the Main page should be for our readers not our editors. That is why the selected articles (bolded items) on the Main Page are chosen based more on their quality, not based on how much their subjects are important or significant. That is why there are only a few links to encourage new editors, not an entire Main page section devoted to it. Thus, a dedicated section for existing editors to find something new to do or work would contradict this general guideline. What you propose might be better suited on Wikipedia:Community portal instead. Zzyzx11 (talk) 06:21, 13 September 2009 (UTC)
    • Zzyzx11 your proposal often leads to that the new feature in the end isnt used at all and doesnt result in anything and in the end is blocked and becomes some sort of historic rememberance of a try to help articles. Also i think that the new section should one day include an article like Kaka Ferskur that is in need of expansion and references and then the next day an article like Anna Anderson or similar..So we get a wide range of articles. But i personally definitly think that the new section should be on the main page because else it will not attract many wikipedians and in the end it will not be used.--Judo112 (talk) 06:25, 13 September 2009 (UTC)
      • I just want to point out that i can only see this suggestion work if the section gets a place on the Main Page, or else it will just die out like that other project that one article was choosen for work during a week. I saw that it had been blocked and not touched since like 2007. I am afraid this suggestion will see the same faith if not it doesnt get priority over the Did you know section which seems ineffective anyway.--Judo112 (talk) 07:04, 13 September 2009 (UTC)

break 1

break 2

  • Opposed The main page is for readers, not editors.
    V = I * R (talk to Ω) 16:57, 13 September 2009 (UTC)
    • As already pointed out before, readers we have... and plenty of... editors is whats needed. And this kind of new feature is what could bring the Wikipedia to have an overall better quality of articles and also get many new editors. And i believe you are wrong to because if the main page was only for readers there wouldnt be any attempt to get editors to edit pages like todays featured article etc etc.. then it would only be a big Wikipedia news kind of main page or wikipedia information whxih its not.--Judo112 (talk) 17:33, 13 September 2009 (UTC)
    • I have now said everything i can say, and told all my point of views that can be find in this section of discussion. Now i leave it up to the Wikipedia users to decide. Hopefully i will see this feature up on the main page soon.--Judo112 (talk) 17:37, 13 September 2009 (UTC)
      • We don't need more editors, or different editors, we need better editors. This isn't a solution to that issue, as people will edit articles that their interested in and that they are capable of writing for. The main page itself is for readers because it shows articles which are primarily intended to be read, and it should remain that way. This proposal is specifically tailored to highlight articles which are intended to be edited, and while that's a fine and admirable goal it should not be something that is featured on the main page.

        Here's one suggested remedy: develop a page in the Wikipedia namespace which accomplishes the goals of this task, and after it's up and operating we can talk about adding a link to it to the sidebar. That should accomplish a similar level of attention while leaving the main page alone.
        V = I * R (talk to Ω) 20:08, 13 September 2009 (UTC)

        • A better suggestion is for people to go and see what Wikipedia already has before proposing things here. This is the third section of this page as it currently stands where people are proposing things that already exist. Uncle G (talk) 11:06, 21 September 2009 (UTC)
  • Support Fine idea. I've long maintained that higher priority should be placed on improvement of existing articles. However the fact that anything linked from the main page becomes a vandal-magnet is concerning... It would be interesting to compare how much vandalism the article gets versus the amount of productive edits. -- œ 18:40, 13 September 2009 (UTC)
    • This problem can be solved easily by todays Wikipedia. Blocking all unregistered users from the singel article for a few days,hours or weeks is the easiest way and is quite often used on Todays featured article when the vandals are to many. There will always be vandals but you have to believe tht most users are on Wikipedia to help...thats my philosophy:)--Judo112 (talk) 20:30, 13 September 2009 (UTC)
  • Support There are many bots out there that can help in creating the list and picking articles neutraly, based on tags on the page (User:B. Wolterding/Cleanup listings for example). And with the number of articled needing attention growing by then minute, I'm sure a constantly changing list could be done. Maybe something like:
  • Support, but it should not be on the first page, maybe the village pump.— Preceding unsigned comment added by 207.161.190.232 (talk) 19:52, September 13, 2009 (UTC)
    • IP:207.161.190.232 please edit more than one article before getting involved in serious discussion like this one. And get an user page here on Wikipedia to.--Judo112 (talk) 20:23, 13 September 2009 (UTC)
      • Judo112, I'd appreciate it if you withdrew that comment. It seems unduly like
        biting a potential newcomer. The point raised by the IP editor is actually a fair one, and should be judged on its merits, not the lack of an account or apparent shortage of previous contributions (since many people have dynamic IP addresses, it is entirely plausible that this is somebody who has edited anonymously previously, or even that it's just a user who hasn't logged on). The awareness of the existence of the village pump suggests a certain level of familiarity with Wikipedia already. However, to the IP user: I too recommend that you you register for an account if you have not done so already. You will find it makes communication, keeping track of edits and watching articles you are interested in, much easier :) TheGrappler (talk
        ) 00:20, 18 September 2009 (UTC)
  • Support having it on the main page absolutely. This gets us back to the roots of what a wiki is all about, and I think it would do a lot of good. I think something selected truly at random (rather than by a nomination process) would be best. Cool3 (talk) 20:17, 13 September 2009 (UTC)
    • Good and i hope everyone agrees with me when i say that the new section has to be placed on the Main Page, because else it will only be visited less and less and in the end no one will use it and it will be blocked and only visited as a cemetary for some old project that died out like so many times before here on Wikipedia.--Judo112 (talk) 20:21, 13 September 2009 (UTC)
    • I would suggest having a script which chose an article C class and lower at 0:00 UTC. warrior4321 20:24, 13 September 2009 (UTC)
      • Very good idea Warrior. Maybe we could fix this up soon as it seem to be many people who is supporting this suggestion.--Judo112 (talk) 20:27, 13 September 2009 (UTC)
        • I agree that this is Main Page or bust. Anywhere else kind of defeats the purpose. On further reflection, though, I do have an idea about the article; it's sort of a waste if we end up with an utterly inconsequential stub. So, what if we take a random article C class or lower that has received a "Top" or "High" importance rating from the appropriate WikiProject? Cool3 (talk) 20:33, 13 September 2009 (UTC)
          • Even better Cool3:) good ideas!!--Judo112 (talk) 20:36, 13 September 2009 (UTC)
            • I would suggest further that the new section is either placed where DYK section is today or close to it. But i would prefer to have it where DYK is today and that DYK is moved a step down.--Judo112 (talk) 20:36, 13 September 2009 (UTC)
              • I like the idea that we first tackle page which have received high or top importance in WikiProjects. I just hope this doesn't lead to abusing the importance of pages, and we suddenly see pages which aren't essentially high importance, as high important just for the improvement. warrior4321 20:39, 13 September 2009 (UTC)
                • I really dont see any worries, we have to take the good with the bad, overall i dont see anything bad coming out of this. lets try it and if it doesnt go well we can always try something else. Would be best if someone fixed this new section up tonight for a first article so that we can see how it works.--Judo112 (talk) 20:42, 13 September 2009 (UTC)
                  • The Main Page need some new style anyway. If someone is wiling to do the edits we could have it up by 0:00 UTC tonight i guess. It would be great if someone did it.--Judo112 (talk) 21:05, 13 September 2009 (UTC)
                    • I think that may be a bit premature. The real thing is for someone to create a prototype/mockup of what it would look like. Then, an RfC or similar would be needed. Main page redesigns are pretty major events. Cool3 (talk) 21:29, 13 September 2009 (UTC)
                      • We aren't going to revamp the main page after a mere 24 hours of discussion that occurred over the weekend at the village pump. We also still have no process in place for choosing possible articles. AniMatedraw 21:34, 13 September 2009 (UTC)

break 3

break 4

break 5

  • Support Much of the needed improvements come from readers too, and it is important to show new articles being made and fixed, to show that Wikipedia is changing and that anyone can help. It will bring more editors in. Also, it doesn't have to be a terrible article, just one that needs improvement, like Pleasure, or other articles from the Wikipedia:Challenges page. We could also feature pages that require translation, or just other generally easy tasks that can be done by new users. And the articles for improvement don't have to be terrible stubs, just important enough to be well known, and easy to fix by new users.

    'Random article needing help [going by Open Tasks tags)' - or a section at a time 'Random stub' (getting on for 55 000 of them), 'Random most wanted article' etc. Jackiespeel (talk) 16:39, 15 September 2009 (UTC)

  • Oppose any article featured so would end up protected with in half an hour, defeating the purpose. Icewedge (talk) 05:36, 16 September 2009 (UTC)
    • Because we always need to protect Featured Articles too, right? Bsimmons666 (talk) 01:18, 17 September 2009 (UTC)
  • Comment People suggesting "Random article needing help" in the sidebar are so completely missing the point I wonder if they even understand the original proposal. We're not looking for an easy way to find articles needing help (they all need help); we're looking for an easy way to encourage many editors to work on one article at the same time. —Noisalt (talk) 00:15, 17 September 2009 (UTC)
    • Then look. These things already exist. Uncle G (talk) 11:06, 21 September 2009 (UTC)
  • Support - I think this is a great idea. I think it would do alot to help draw people who see the main page into helping edit instead of just viewing, and benefit the project as a whole. Nutiketaiel (talk) 16:44, 17 September 2009 (UTC)
  • Support Good Idea! But maybe have it in a sepperate area of wikipedia, and have a link to that page. Or better yet, just like the random article link, we could have a random article to fix link.Accdude92 (talk) (sign) 16:53, 17 September 2009 (UTC)
    • (a) I'm fairly certain this will fail in practice; (b) We should trial it anyway, preferably having agreed a trial period and certain criteria for "success" beforehand. "Good signs" would be a rise in the number of editors joining (even if no statistically significant rise is found, I appreciate editor recruitment figures are likely to be "noisy" and suggest that we should heed anecdotal evidence of particular users joining as a consequence), or that the nominated articles tend to improve (even if this is done by semi-regular or regular editors, and we fail on recruitment, that's still a plus point). "Bad signs" would include the nominated articles getting shredded; to some extent an accepted negative of this scheme is that it in some way degrades our front page and makes us appear less reliable/professional but I can't think of a way of measuring the specific effect of this initiative on that. My suspicion lies heavily that things on the main page often attract negative editing so this initiative would be very likely to fail. But until it is trialled who can say for certain? Unlike many websites we can reverse changes easily if they don't work out; conservatism here doesn't seem to offer serious gains. TheGrappler (talk) 01:01, 18 September 2009 (UTC)
      • These proposals have already been trialled. Wikipedia:Collaboration of the week is currently marked historical. If you think that these ideas are workable, get CoTW up and running again. Anything less is simply requesting that somebody else work on the problem. Uncle G (talk) 11:06, 21 September 2009 (UTC)
  • Comment Unrelated to my previous point (that we should run a trial), is the problem of what articles should be listed. This has been discussed above by several users, I'd like to give my $0.02 on a variety of options:
    • Stuff that definitely must not go anywhere near the front page: two things spring to mind for me, biographies of living people and any article likely to attract controversial nationalist/religious/political points of view.
    • Poor standard "vital articles": the pro is that almost anyone knows something about these even if they're not an expert, which might encourage editing. But actually in turn that's a problem, since most non-expert edits will end up being reverted. The reason so many vital articles are in a poor state is that it's incredibly difficult (and often requires a range of expert knowledge in multiple disciplines) to structure and balance an overview article on a very general topic. It's widely suggested that the best way to do it is to deal with all the sub-articles first, then weave these improvements into the main article. It may also require extensive planning on the talk page to get the structure right. My comparison would be to the "well-meaning" damage that many FAs suffer when listed on the main page; they get random additions of overly-specific general knowledge, usually by "drive-by" editing, that tend to distort the balance of the article. Complex vital articles on subjects such as "toy" seem likely to suffer the same fate. Vital articles seem extremely likely to backfire.
    • Esoteric articles requiring expert attention: most people who see this listed won't have any way to change it or feel drawn to it. I suppose for an expert, the "wow, actually I could do something about that" may be proportionately bigger though. Perhaps there's a risk of a non-expert adding googled tidbits of (possibly not 100% true) info, which could be a pain to verify since it would require a real expert to check! I am aware this is a recurrent problem on e.g. physics, philosophy and economics articles in general, but am unsure whether a main page campaign would make things worse.
    • Articles that require a copyedit/wikifying/other primarily formatting issues: I've heard plenty of anecdotes that this is what draws many new users into Wikipedia - the opportunity to correct a typo seems a particularly common pathway to addiction :) On the downside, if you're just starting, the wiki markup language can look scary to edit, and it's difficult to judge a good level of wikilinking. On the plus side, this is still going to be easier than adding substantive content (especially if they get nagged into dealing with
      WP:V
      and coping with all those hard-to-grasp referencing templates). And it wouldn't require extensive coordination with other Wikipedians on the talk page, which may also help new users to just get on with it without finding they are reverted five minutes later.
  • We could of course try a variety of these different types, rotating every couple of hours if we found that we drew enough attention by putting an article up for 3 hours, say. But if a particular class of article (e.g. broader "vital" articles) seems to draw more trouble than it's worth, then I suggest we focus on those types that give a more positive response. TheGrappler (talk) 01:01, 18 September 2009 (UTC)
  • I oppose for a few reasons: first, I agree that we should strive to keep readership separate from editorial work as often as possible. Second, we should be promoting our highest-quality work on the main page; while I'm all for encouraging participation amongst our readers, the main page should remain free of our "Featured crap". Lastly, I agree that this seems like a duplicate to DYK. A well-intentioned proposal and without doubt a reasonable suggestion, but I don't think this would work well. –Juliancolton | Talk 02:32, 18 September 2009 (UTC)
  • Support We need more and better recruiting. People know that it's possible in some abstract sense to edit but I don't think they have a sense that they can help out on a specific thing right now. I'm kind of surprised this hasn't made it to perennial proposals yet because it's come up several times before and has always failed, but I'll throw my support behind it again... (at least on a trial basis for now) Calliopejen1 (talk) 13:50, 18 September 2009 (UTC)
  • Oppose Having an article that needs editing right on the front page would cause hundreds of edits to happen to the article almost instantly. Doing this would make the article almost impossible to edit. This would cause constant edit conflicts and massive amounts of useless content. I could understand 20-30 "articles that need your help" being shown in a list on the front page but having one is ridiculous. --Yair rand (talk) 18:26, 18 September 2009 (UTC)
  • Comment - I think the selection of one article would not be productive - the 'pedia is too big now, and much generalised info has been added. Also see
    WP:ACID which works (or doesn't) in the same vein. So I'd oppose a specific article but support a link tagged 'Articles needing help' or somesuch to a random article with a tag on it (selected from expand, refimprove stub and some other ones which do not require specific wiki-knowledge like wikify or uncategorised. Casliber (talk · contribs
    ) 21:36, 18 September 2009 (UTC)
  • Strong Support I like it. And I disagree with the "presenting our best articles" argument. We need to recruit more editors, and this is the best way to do it. Also, if I may extend the proposal, we could divide the section into sub-sections (Science, Arts, etc.) to attract more people with localized interests. ƒ(Δ)² 17:15, 19 September 2009 (UTC)
  • Strong support maybe we can make some of our readers editors!
    talk
    ) 06:58, 20 September 2009 (UTC)
  • Oppose enough said already, starting with "don't confuse casual reader". The message "anyone can edit" is still there and serves the purpose well.
    NVO (talk
    ) 16:25, 20 September 2009 (UTC)
  • Support as attracting new editors does seem like a good idea, especially when it results in article improvement. I am sure the fine points of such a proposal would have to be worked out, but a nice good faith idea that merits at least trying. As Wikipedia does not have a deadline, we do not have much to lose by at least giving it a whirl. Best, --A NobodyMy talk 02:19, 21 September 2009 (UTC)
  • Support, inspiring people to contribute is an important part of our mission. It has been a long time since there was an 'edit' link on the Main Page; this would bring back a bit of that spirit. +sj+ 04:46, 26 September 2009 (UTC)

break 6

  • If it is not practical to have a 'random article needing help' on the main sidebar, would it be possible to have something similar elsewhere: eg on the various 'Category:Wikipedia articles in need of ...' pages? If suitable tags are devised and there are 'lists of topics on xxxx (insert subject of choice)' a similar arrangement could be made in subject areas.
The long lists on category pages may discourage people from pursuing. 16:27, 21 September 2009 (UTC)
  • Support. This is an absolutely great idea, give it a trial run! Someone go and be bold already. If it doesn't work out, so be it, but why waste a bunch of time trying to predict the outcome, when a simple experiment will show us right away. HiDrNick! 19:25, 21 September 2009 (UTC)
  • Would add the various 'Collaborations by topic' lists and similar listings. Possibly having a 'Select random article needing help in this category' box link or subheading at the bottom of the page might be more appropriate - 'the point being' to encourage people to deal more actively with the pages needing most help. If suitably devised (on list pages etc) might be appropriate to retain even if there is only a trickle through response. Jackiespeel (talk) 10:37, 23 September 2009 (UTC)
  • Oppose - there are already more than enough collaborations that everyone already ignores. Adding yet another one would be rather counter productive. Putting it on the main page, would just be silly. --T-rex 02:41, 25 September 2009 (UTC)
  • Support - right now we need more casual readers to become editors, and I think this is an excellent, prominent and enticing way to do just that. JoeSmack Talk 05:40, 28 September 2009 (UTC)
  • Support – if we make sure to put out articles that are important but currently poor, this could be a very positive thing indeed. As an aside, I think that the idea that we should shy away from confronting readers about Wikipedia's collaborative, all-in model is toxic. We shouldn't be standoffish; rather, we should be trying to recruit and engender the involvement of every reader. —Anonymous DissidentTalk 14:49, 30 September 2009 (UTC)
  • Support Good idea! Wikipedia keeps getting hammered in the press for being incomplete/inaccurate/libelous and people sometimes forget that editing the 'pedia is a community thing. Anything that embiggens the community is a good thing. One caveat: it should never be a BLP in the "article to improve," because that's a tough thing for new people to understand and is just asking for a lawsuit.--24.131.95.3 (talk) 17:26, 5 October 2009 (UTC)
  • Strong Support - a combined collaboration effort is an awesome idea, and putting it on the main page will allow it to actually get off the ground faster than old whole-Wikipedia collaboration efforts have.--Unionhawk Talk E-mail Review 18:26, 5 October 2009 (UTC)
  • 'Strong Support* - This is an awesome idea! i agree with others who have stated that there are loads of poor quality articles and this would help a great deal! Also, i think that more wiki users will be encouraged to write if all they had to do was log on and find something they are interested in to improve!  :) —Preceding unsigned comment added by Malone94 (talkcontribs) 08:40, 9 October 2009
  • Strong Support More editors is good. mkehrt (talk) 09:09, 9 October 2009 (UTC)
  • Support with Qualifications: I think this is a promising idea, and it might have the reverse positive effect of luring editors every now and then to look at the same main page that readers see, rather than Watchlist (where I start), New Articles, etc. I think that (despite the PR implications) the best way of choosing an article for improvement would be to pick one that's closely-related to that day's Featured Article. For hypothetical instance (and in complete ignorance of the actual articles), suppose that Florence Nightingale (the nursing pioneer from the Crimean War) were the Featured Article and Clara Barton (the American Red Cross founder who started in the American Civil War) were a worthy article that needed all kinds of help. (Or assume the reverse hypothesis.) Then readers who were fascinated by the Featured heroine (or who already knew something about nursing and public health) might be inspired to see what they could contribute to the other's article. The one big caveat I would want to add is that there should be fair warning on the improvable article's Talk Page, and if the identities of two or three principal previous editors were clear, they should also get personal notifications. Nothing would be more demoralizing after painstakingly doing such cleanup as one could to a stubby, poorly-written or biassed article than to have a host of strangers suddenly descend on it en masse with the very best of intentions but little knowledge of its past history. As for the PR implications (or Putting One's Best Foot Forward), I think this might be an honest and straightforward way of showing how the best features of Wikipedia are built from the ground up, indulging in neither boasting nor self-reproach. —— Shakescene (talk) 09:37, 9 October 2009 (UTC)
  • Qualified support. I think this is a good idea in principle, but the objection that it could cause loads of people to fall over themselves editing it (editconflictitis) is a valid one. So it would need to be done in a well-thought-out way to avoid that. For instance, there might be a daily pool of Articles To Be Improved, which are rotated rapidly enough to spread out the edits across articles. (There may be technical issues with that, like breaking caching; depends on what we can come up with on implementation.) PS Objections that it would duplicate existing collaboration efforts seem off the mark - very different audience. Rd232 talk 09:42, 9 October 2009 (UTC)
  • Support I love this ides —Preceding unsigned comment added by Tim1357 (talkcontribs) 19:53, 10 October 2009
  • Comment - This sounds like a good idea, however there are some things to consider. Though Wikipedia's regular participants are aware of its goals and inner-working, the average shmo has no clue. As unbelievable as it might seem, most people are under the impression that Wikipedia is a finished product. Even many frequent readers are still unaware that they have the ability to edit the encyclopedia. This is part of the reason we get a lot of flak in the media about our article quality. Wikipedia is a widely misunderstood animal, and no matter what we do, it seems it always will be (we even tried making the slogan "The encyclopedia anyone can edit", and even that didn't really work). The decision to make the main page an accommodation purely to readers as opposed to editors is a way of dealing with this public perception. We try to put on our best face to the public, so that they won't criticize us as much for being unreliable and amateurish; and consequently, this is the reason there will be resistance to changing the main page according to the proposal. "We" (those concerned with Wikipedia's public image) don't necessarily want everyone to see immediately "behind the curtain", because most will undoubtedly not understand, as has proved to be the case in the past. The prerequisite for this proposal is a much larger change. It would be putting on a different face to the public. The pros and cons of that would have to be weighed carefully before this should be implemented. Equazcion (talk) 20:25, 10 October 2009 (UTC)

break 7

  • Oppose - For several reasons: 1) the main page should highlight our best work; 2) The article would either have to be chosen at random or go through some sort of selection process. If the former, we could end up promoting non-notable and/or obscure topics. If the later, the article could just be improved rather than wasting effort deciding which article should be improved; 3) If successful, it would lots of people trying to "improve" the same article over and over again when the effort would be best spread out among several lacking articles. It could also potentially lead to edit conflicts, edit wars, and other unpleasantness that could turn off newbies; 4) The page would most likely have to be semi-protected which would rather defeat the point of trying to convert readers into editors: "Please help us edit this article... except you can't because we had to semi-protect it because of persistent vandalism." --ThaddeusB (talk) 20:38, 10 October 2009 (UTC)
  • Very well-said, and I agree entirely. –Juliancolton | Talk 00:54, 12 October 2009 (UTC)
  • I think most of the potential problems you have just brought up will not be real issues if a different article is attributed to each page request (or that the page requests be split up for different articles). Alternatively, we could have a robot that would work as follows: Put article X1 on the main page until some number of different editors have made an edit (say, for the sake of argument 10) at which point a new article X2 is put on the main page until X2 has received edits from 10 different editors, etc. GeometryGirl (talk) 14:38, 12 October 2009 (UTC)
  • I like that bot idea, good thinking. As for Thaddeus's other points, whether or not we should purely be showcasing our best work is one of the questions under discussion. Just saying we should continue to do that doesn't really address the issue. People have provided some decent reasons to perhaps shift from that tradition. The process doesn't need to be much of a process, if the articles will only be staying on the main page temporarily. The bot could choose articles based on maintenance categories, like copyediting required or stub, or there could be a list that autoconfirmed users could just edit at will. Equazcion (talk) 05:22, 14 October 2009 (UTC)
  • “the main page should highlight our best work;” — fundamentally disagree with this, the main page should highlight what we do. We improve articles. Alex Muller 09:45, 15 October 2009 (UTC)
  • Question Would this be a featured article that remains on the Main Page all day, or a random one that is different for each page request. If it were on the Main Page all day, then it should not be Random, rather it should be selected much in the way a Featured article is selected.Tim1357 (talk) 20:48, 10 October 2009 (UTC)
  • Oppose The main page is a "reader-facing" page. It's primary purpose is to put a smiling face on the Encyclopedia for outsiders. Adding a feature for solely editors and not readers breaks this metaphor for no strong purpose. It is important to remember that while the distinction between "Reader" and "Editor" is not crystal clear, there is undeniably a distinction. The vast majority of the people who read encyclopedia do not edit it and are not interested in editing it, and that's a good thing. That's who the encyclopedia is for. APL (talk) 22:23, 14 October 2009 (UTC)
    • But the whole point of Wikipedia is that it's the encyclopedia anyone can [and does] edit. Readers are just editors who haven't got their feet wet yet - and we always need more! And does adding a small Article For Improvement to the front page really take away the Smiling Face? Most substantively of all, we should be reminding readers of the editable nature of Wikipedia, and this would help. Rd232 talk 09:58, 15 October 2009 (UTC)
  • Support The main page should reflect the whole project, and should freely admit that it is an incomplete resource. It would give new editors a place to start. --PretzelsTalk! 14:11, 22 October 2009 (UTC)
  • Oppose per ThaddeusB. Also, my experience with DYK indicates that even getting 10,000 views in one day does almost nothing to attract contributions or new editors, and i doubt this would either.YobMod 12:37, 29 October 2009 (UTC)

Subproposals

  • Taking on board the discussion above, I suggest the following as an alternative. For a trial of just one hour, have a random article from a suitable class of articles displayed for 1 minute each on the front page, as an Article Needing Improvement. Evaluate the impact, and go from there. The difficulty is identifying a suitable class of articles, but old unwikified ones might be OK. What's the worst that can happen? If that turns out OK, develop a longer trial, for maybe a day. Suck it and see, I say. Rd232 talk 09:51, 14 October 2009 (UTC)
  • Question How do trials work on WP? What if it goes up for its trial, but then there is no consensus to remove it? Suddenly a feature for which there was no strong consensus has been added and can't easily be removed. APL (talk) 22:23, 14 October 2009 (UTC)
    • Being a trial, it would presumably be removed at the predetermined end of the trial. The fact that it's a trial implicitly includes consensus to remove it at the trial's conclusion, I would think. --Cybercobra (talk) 23:13, 14 October 2009 (UTC)
      • Precisely. It's a defined-length trial, with reversion to the status quo ante afterwards, while the trial is assessed. Rd232 talk 10:00, 15 October 2009 (UTC)
  • Oppose I oppose this for the same reason I oppose the above. I don't doubt that it might have some sort of interesting impact, I simply believe that it will reduce the overall impact of the mainpage to outsiders. A trial won't help that one way or the other. APL (talk) 22:23, 14 October 2009 (UTC)
    • It's just a trial though. Why not give it a shot and see what people think from there? Equazcion (talk) 23:05, 14 October 2009 (UTC)
  • Support The objective of trying to encourage participation in editing is an excellent one and the main page is a good place to do this. But there needs to be a good structure for this to prevent the highlighted article from being swamped by too many well-meaning newcomers. The idea of just exposing each candidate article for a brief time is a good one. Another possibility is a Master class - a demonstration in which one or more expert editors work upon a selected article as a living example of our methods. As well as demonstrating important editing techniques like citations, images, categories and so forth, a team of masters could also demonstrate our methods of collaboration such as the use of edit summaries, the talk page, good article review and so on. There might be a sidebar in which a commentator explains what is being done, as it happens. Such demonstrations might be organised as special occasions or, if there are enough volunteers, they might run continuously. Colonel Warden (talk) 23:32, 19 October 2009 (UTC)

Problems

I may have missed it in this long thread, but I see a few problems with some of the later proposals. To be shown on the main page, people would have to write a blurb (like for DYK or FA), other people have to agree with the blurb, and then it gets on the main page (no matter if this is done randomly from a pool of approved blurbs, or with a fixed format like DYK). The time needed to do all this could better be used in actually improving the article (above, the example of unwikified articles was given: just wikifying them doesn't take longer than the process described). Remember also that when you have a pool of articles to choose from, you need a de-pool process as well, to remove sufficiently improved articles.

Any other system, like somehow transcluding the first paragraph of the article on the main page, does not protect the main page from vandalism. And if you portect the page, it can no longer be edited, invalidating the purpose of the exercise.

Fram (talk
) 09:56, 15 October 2009 (UTC)

Fair points, but there may be solutions. The Article may be listed without a blurb - just the pagename, under an appropriate generic heading + "what is this/what do/how to do it" intro. And if we base selection on standard maintenance categories, then removing tags after improvement will depool candidates. Rd232 talk 12:30, 15 October 2009 (UTC)

Main page Article Editing - reboot

A lengthy discussion above produced diverging views on the idea of having an "Article to be Edited" on the Main Page. Without wishing to rehash the entire lengthy thing, the discussion produced some points permitting some further development of this idea which may produce something worth trialling.

Advantages of figuring out a way to make this work: a) get more people on board as editors, via a route not determined by their

conflict-of-interest
desire to create an article about themselves or their company; b) more clearly communicate to readers exactly how Wikipedia works. Yes, some people are still a bit vague on what "the free encyclopedia anyone can edit" really means. ("Surely not just anyone?" Well, yes.)

Drawing on the above, then, I propose a short, definitely temporary trial of the idea, of the following form:

  1. A trial of just 1 (one) hour, with no further action unless the results indicate further, longer trials are a good idea
  2. Add a new section "Some articles in need of editing" (or similar)
  3. In that section, provide a short intro on what the section is for, and links to appropriate help pages (depending on what help we expect the articles to need)
  4. List perhaps 5 articles, just the pagename, no blurb.
  5. List each set of 5 articles for just 1 minute, to keep exposure manageable
  6. Choose articles at random (possibly favouring older tags) from standard maintenance categories, eg Category:Wikipedia articles needing copy edit
  7. Articles will automatically be removed from rotation when the appropriate maintenance tags are removed by editors seeing sufficient improvement.
  8. Articles listed on main page in this way be logged on a list (or possibly in a dated maintenance category) to allow established editors to review results after 24-48 hours of being listed.

Crucially, in this version the main additional workload is in setting up, rather than continuous: it's choosing which maintenance categories to work, and what standard (per maintenance task, not per page) intros to create for them, and creating appropriate bots to choose/rotate articles, etc. Well, I'm ignoring the additional workload involved in cleaning up after vandalism, and checking edits, because it's mostly not a new process - it's covered by Recent Changes, with an additional mechanism (list/category) to ensure Recent Changes Patrol doesn't miss things on these (briefly) high-traffic pages. Comments? Rd232 talk 16:50, 22 October 2009 (UTC)

For it to get on the main page at all, it would require a substantial amount of work to fit it in somewhere and make sure that the main page design still looks good on common browser/screen resolution configurations. For a short trial, you would have to do all of the setup work except some of the setup for a formal process to add the pages (so probably about 75+% of the work). I don't think the amount of benefit from a 1 hour trial really justifies the amount of work required to set it up. Additionally, the section appearing and disappearing from the main page while we do multiple trials and, if successful, create a formal process, could be confusing and annoying to readers. Mr.Z-man 17:51, 22 October 2009 (UTC)
I take your point about the work, but it may be worth the risk - and if we get people with some know-how, it may not be that much work (enough to justify doing it, anyway, because of the potential benefit if the trial works well and ultimately leads to implementation). As for the design, that needn't be any work at all - just nick the "Today's featured picture" format and duplicate that. Good enough for a trial, at least. And is changing a web page a little bit really going to start annoying end users? That's a stretch. And for the trial it won't affect that many. Rd232 talk 20:50, 22 October 2009 (UTC)
How many articles do you plan to put at once if you want to have a full-width section? The featured picture takes up more space than the featured article. It may not annoy them, but a new section appearing and disappearing, possibly multiple times, could certainly be confusing. The main page typically gets 5-7 million views per day, so a 1 hour trial would be seen by ~200000-290000 people. Mr.Z-man 02:18, 23 October 2009 (UTC)
Well I find it hard to put much weight on that, because websites change all the time, and we're only talking about a single trial, and maybe 1 or 2 more, longer trials after there before it might become permanent. Websites change all the time, and this is not a dramatic change. As for the "full width" point - I said 5 articles above, and I expected to take up the rest of the width with explanation of the section and help /summary links for editing. If it's really too much space, maybe split into two columns, one for each of two types of maintenance category. Rd232 talk 02:26, 23 October 2009 (UTC)
Facebook has just changed its homepage layout for the 5th time, affecting all of its 250 million users. Top ten websites change their appearance on a monthly basis. Our main page has not chnaged significantly since March 2006, getting on for four years. Wikipedia needs to be much more willing to experiment with new layouts. Like RfA, many people agree that the main page is in need of an overhaul, but no one can agree on a complete new system. The natural way to break that deadlock is to try small changes and see what works and what doesn't. If Rd232 is prepared to put in the work to prepare such a feature, it is entirely disingenuous to use the effort involved as an argument against it. Happymelon 11:21, 25 October 2009 (UTC)
Facebook probably isn't the best example, as several of their interface changes have made the news for being heavily disliked. I'm more concerned that Rd232 does not know what the design work involved is and is currently proposing to just sort of "half ass" it - "just nick the "Today's featured picture" format and duplicate that. Good enough for a trial" - I'm concerned that most of the proposal here is focusing on the easy things, particularly the new list just added below. The 2 most important things - the design of the section as seen by readers and the examination of the results - are being given almost no consideration. Mr.Z-man 17:55, 25 October 2009 (UTC)
The picture section is a set of three nested HTML tables. Duplicating that set should not have knock-on effects on the rest of the page. Nor should splitting one of those tables into two columns (or adding another nested table into the currently innermost) cause issues. No big deal, I'd say. As for the post-mortem: I've specified the creation of a list of affected articles to enable it, but beyond that, I don't see why I should do all the legwork working that out when dozens of people commented in the earlier discussion. Personally, I don't think this needs to be specified in advance; eyeballing would be sufficient for a general impression on effects. Detailed analysis (requiring automation) I'd think would be required for a later, longer trial, as there the volume of data would be too great. Rd232 talk 18:11, 25 October 2009 (UTC)
Wikipedians tend to have a rather short attention span. For every 10 people who comment on a proposal discussion, maybe 1 will actually follow through past the initial proposal. Another issue is that trials on Wikipedia have a tendency to become permanent, so people may be wary of a proposed trial without a detailed plan. Mr.Z-man 18:19, 25 October 2009 (UTC)
Yes, well... on the latter part, I can't see how what's proposed here has any risk of becoming (unintentionally) permanent. The "trial becoming permanent" issue is more for software things being turned on, and it not being clear enough under what circumstances/time frame it would be turned off again. Rd232 talk 10:19, 26 October 2009 (UTC)

Well it isn't really that much work.

  • Blurb for the section (describing Articles for Improvement)
  • Choice of maintenance categories
  • Blurb for each of two maintenance categories (what/how/help links)
  • A bot to do 60-second updates to that section, taking 5 articles at random per section (excluding previous selections), and to note on a subpage the articles it lists.
  • Somebody to take responsibility to create the section, run the bot for an hour, and then delete the section.
  • Post-mortem.

It should be easy to do such a bot (for an experienced bot writer - which I'm not!), and I'm sure we can manage the others too. The issue which actually bothers me, which hasn't be discussed AFAIK so maybe it isn't an issue, is how such frequent updates would interact with caching. Rd232 talk 12:41, 25 October 2009 (UTC)

I agree with Happy Melon about the need to have a easier process for making changes to the main page. And rd232's idea of doing a 1 hour trial seems like it might be worth a try. I would like to know however what would happen after the experiment is over. Should the criteria for success be decided on beforehand? Should there be a control group of pages that weren't listed to allow for comparison? There isn't much point in running the test if it's only going to result in more indecision when in comes time to figure out what to do about it when it's over.--RDBury (talk) 16:32, 29 October 2009 (UTC)
I haven't been involved, but some people have a lot of experience with having Featured Articles on the main page unprotected. There must have been some efforts to evaluate the effects of that. Perhaps we should cross-post on the Main Page talkpage. Rd232 talk 17:21, 29 October 2009 (UTC)

Arbitration committee structure for 2010

I have initiated an RFC on the Arbitration Committee size and terms for 2010. If we are to have a clear number of seats determined before the the upcoming election begins, vote now! ;-) But also add views at the bottom and come back after a week or two and review your decision after considering what others have to say. --John Vandenberg (chat) 09:20, 29 October 2009 (UTC)

Flexible Groups for Editnotices

I have an idea for allowing

template}} transclusion reference into each page's editnotice (i.e. Template:Editnotices/Page/X
where X is the pagename). It could even work based on Categories being added to the list - the bot could easily interpret that as adding editnotices to all members of the category.

Discussion: This would be a little bit of work to set up, but not an enormous challenge for one of our experienced bot writers. The question is, is it a good idea to use editnotices much more widely, in the way this would enable? Rd232 talk 22:34, 29 October 2009 (UTC)

Good idea, and definitely doable, but this would have to be done by admins, and since admin bots are always controversial, I think manually would be faster.--Unionhawk Talk E-mail Review 22:48, 29 October 2009 (UTC)
Unionhawk: Rd232 recently told me that this is about adding an editnotice to 1000 - 10,000 pages at a time. And if I understand it right, then doing it again to some other large group some time later. So doing it manually isn't really an option. But you are right that it would have to be an adminbot since all the editnotices in article space are auto-protected.
Everyone: Note that doing mass edits to editnotices isn't especially disturbing, since those edits won't show up on user's watchlists, since it doesn't cause any edits to the articles themselves. (Only if a user is watching the editnotice itself will he see it in his watchlist.)
--David Göthberg (talk) 23:10, 29 October 2009 (UTC)
Well it could be about adding an editnotice to 1000 - 10,000 pages at a time... I'm thinking for instance of an editnotice for articles covered by Arbcom restrictions. But at this point it's just a quite general, open-ended idea. Rd232 talk 23:20, 29 October 2009 (UTC)
It wouldn't really need to be an admin bot. Technically, it's enough for the bot to have the tboverride right, which could either be given to the Bots group (I don't see a reason against it) or that specific bot could be put into the Account creators group (a bit weird and hacky, but probably easiest). Amalthea 14:30, 30 October 2009 (UTC)

What could allow us to do this easily (without hundreds or thousands of edits) are per-category editnotices (see

Wikipedia:Editnotices#Dismissibility and per-category editnotices) - which could also replace and much improve the editintro for disambiguation pages and BLPs, but this would require the resolution of T20596. Cenarium (talk
) 19:37, 1 November 2009 (UTC)

Proposal to merge articles: Aerolift CycloCrane and Thermoplan, with Hybrid Airships.

They're hybrid airships, & it's better to have one article on the subject, not three. Archolman User talk:Archolman 01:18, 11 May 2014 (UTC)