Wikipedia:Village pump (proposals)/Archive 53

From 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 Template:Sports result table (a template used on around 600 articles) be deprecated in favour of Template:MedalistTable. I believe the latter template to be more versatile and aesthetically pleasing, and it is already in use on a greater number of articles. See discussion here. Sillyfolkboy (talk) (edits)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, AGF. Cenarium (talk) 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)
  • Strong oppose. We currently have over 10 million users of which 150,000 edited in the last month. There is also the countless anon editors. Word of mouth (keyboard??) and the presence of the edit button is sufficient to attract editors. Ads will also clutter up the page unnecessarily. It is refreshing to look at WP pages after coming from pages that are littered with ads. What we need is more quality editors and less vandals. Flagged revisions can help with that. -- Alan Liefting (talk) - 04:17, 24 September 2009 (UTC)
    I was completely on your side until you mentioned flagged revisions. It's entirely possible that my misgivings of any flagged revisions system on en.wikipeida are FUD related, which is why I haven't personally spoken out against (or even about) them, but the impression that their not a good thing is still widespread.
    V = I * R (talk to Ω) 04:43, 24 September 2009 (UTC)
    The way I see it Flagged revs has the ability for WP to remain freely editable and entirely free of with significantly less bad edits. -- Alan Liefting (talk) - 01:34, 25 September 2009 (UTC)
    OK, we'll see (I guess). I don't believe that at all, as is probably obvious, but as I said above I'm withholding judgment until I see the system actually implemented (although I can confidently state that the "and entirely free of bad edits" statement is pure hyperbole, which actually made me chuckle a little bit). I seriously doubt that it will be able to complete a successful test here on en.wikipedia, but I'm at least willing to give it a chance.
    V = I * R (talk to Ω) 02:14, 25 September 2009 (UTC)
  • Mobile Alerts on Watch list: you may be able to charge for that with SMS fees or something. This may not be quite what you want as it only appeals to people who are willing to pay for it but just a thought. Mobile may pick up different audience. Nerdseeksblonde (talk) 19:58, 1 October 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. MBelgrano (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 DMCA, and could hold a copy any given site until the owner sent a 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. Shimgray | 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!) Shimgray | 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! Shimgray | 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. Shimgray | 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, Encarta encyclopedia will follow MSN Groups into Microsoft's mystic underworld on 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 : Wikipedia:Village pump (technical)/Archive 137#question about box
to try to solve it by myself, i copied the said template (the one from 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 IMDB-level notability articles. Full instructions are located at User:Otterathome/Substantial sources. Anything wrong with this before I move it in to template space and use it?--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 tabbed browser, with middle-button clicks enabled to open links in new tabs. That's what I have with Mozilla Firefox. It's a very efficient way of coasting through Wikipedia. Equazcion (talk) 06:54, 10 October 2009 (UTC)
Most current browsers, including Internet Explorer, Apple Safari and Google Chrome now have tabs that you can open with the middle button of a mouse—at least in Windows Vista on a desktop with a Microsoft-type mouse with a middle button or wheel. That's also true of Netscape Navigator, a slightly-older browser available from http://www.oldversion.com, which is based on an older version of Firefox, but also allows you to open a "mini-browser" in the left-hand column. I frequently open Wikipedia in Netscape Navigator because I can then put lists (such as my 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 CC-BY-SA. If you are so licensing the book, you can probably upload it to http://www.wikibooks.org, Wikipedia's sister project (though I don't think they accept PDF books and I'm not sure about all their inclusion policies - it's possible your book wouldn't make the cut). Note that if you are incorporating Wikipedia content into the book (it's not clear whether this is the case) you must abide by Wikipedia's license as described at 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 law. In fact my reading of statute indicates they also are that. I'm quite happy with WP:NOTSTATUTE and WP:IAR however. There are quite enough nit picking rule followers around that one needs to emphasise that people should try harder to use their common sense. As I said on WT:IAR if you break the law for a good reason and judges have discretion they'll let you away with it though you'll have to explain yourself. That's the difference between "should" and "must". 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 Wikipedia:Non-free content criteria or Wikipedia:Biographies of living persons), but those are exceptional circumstances, not the rule about policies. MBelgrano (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 WP:IAR is a good thing to state explicitly rather than being implicit. I see no reason for explicitly diluting other policies though like he wants to - I believe that would cause grave trouble with the wikilawyers pushing fringe ideas. 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  ◄  zzɥɔ  (ʎןddns ʇɹoɥs uı ʎןpɐs) uoɯɯoɔ:dʍ puɐ 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. Dmcq (talk) 10:55, 18 October 2009 (UTC)
  6. There are at least three levels of regulation in common society. Norms are the least, and are generally accepted customs within a community (ie bringing a present to a birthday party); there are usually only minor consequences if a norm is broken. Next are Rules which encompass select members of a community or organisation (eg schools, or company policy). Rules apply only to members of that community, and can be punished within that scope. Finally, laws are regulation which is considered to apply to the entirety of society (within a state); punitive measures are considered to be applied by the entire society against the offender. Wikipedia is a volantary organisation, thus regulation is governed primarily by rules (eg WP:OR) and norms (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"? --Danger (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)
WP:COPYVIO and WP:BLP are certainly prescriptive, and if "the community" ever decided to seriously violate them, "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 should say that "Policies have wide acceptance among editors and are standards that all users should follow." We all know that should is not the same as must, and also that WP:IAR is one of the policies that editors should follow.) The discussion (here) begins with Camelbinky's odd assertion that when 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}} magic word that does what you are asking for. You should not use seasons as dates per 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 (8 September 2009) ruling of the 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 WT:Manual of Style (dates and numbers), although I think in terms of whether metric units or Imperial/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:AIV has been backlogged daily, and someone ends up posting a message at 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 User talk:Wimt (the bot master) and there's a features request page for the bot here. I think 10 requests seems like a good backlog threshold to report to WP:AN (which I think is the better page than WP:ANI). A more meta observation is that I think we're falling behind in admins. My impression is that we're getting more and more frequent backlogs at various places. The canary in the coal mine for me is requested moves where the backlog is now constant, when it used to be almost nonexistent. Other pages seem to be more and more hammered such as WP:UAA.--Fuhghettaboutit (talk) 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 Wikipedia talk:Signatures#Forbid "text-shadow" in signatures)- The custom signature section in the Preferences currently has a summary of 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. MBelgrano (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 the extension PovWatch or a variant, that's a proposal for a step further, for common/shared watchlists, though I'm not aware of a technical support for such a thing as of now, so it would have to be requested. A possible implementation is detailed in full at User:Cenarium/Common watchlists. The idea is to create a system allowing users to share watchlists, maintained by bots, the software directly, or users with appropriate permissions, the system possibly being centralized around a special page Special:CommonWatchlists. Users could see changes to a specific list by going there, and subscribe to a particular list would show changes to the list in their watchlist (with a distinctive mark if not already). Examples of such lists could be: pages with recently lots of traffic (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 Special:SpecialPages, under "High Use Pages," we are listing Special:MostLinkedPages. But this page has been out-of-use for some time now. If possible, we should remove it from Special:SpecialPages. SpecialPages ranks 277 in terms of traffic, and it looks amateurish to link to a dead-end from a high-trafficked page. Andrew Gradman talk/WP:Hornbook 07:11, 21 October 2009 (UTC)

There are probably more like that - see Help:Special page, which lists all of them and indicates which are inactive (or rather were inactive last time anyone checked). I suspect this is something the devs would have to sort out, by taking the inactive special pages out of the system somehow (try asking at WP:VPT).--Kotniski (talk) 09:32, 21 October 2009 (UTC)
okie doke, I pasted this thread there. Andrew Gradman talk/WP:Hornbook 05:59, 22 October 2009 (UTC)

autoconfirmed for unassisted article creation

Following on from a discussion at Wikipedia:Requests for comment/new users#autoconfirmed for unassisted article creation, I'm bringing the proposal here: if the 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 {{Userspace draft}}. And users would then either wait til they're autoconfirmed, or change the template to {{Userspace draft for review}} (hopefully there'd be a clever way of doing that so it was easy, like clicking on the template somewhere). That would place it in a category, where reviewers would then move articles to mainspace if appropriate, or change the tag back to {{userspace draft}} and tell the user why. Basically, drumroll, done right it would be like New Page Patrol and CSD in reverse, and would take over much of their workload. This way wouldbe much less 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)

  • Support strongly. Excellent idea. Ironholds (talk) 15:11, 16 October 2009 (UTC)
  • Support, please, yes. I've seen Article Wizard turn out some great stuff actually. JoeSmack Talk 15:36, 16 October 2009 (UTC)
  • Support - hopefully this will help reduce bite caused by creating poor articles without any substantial downside. --ThaddeusB (talk) 16:18, 16 October 2009 (UTC)
  • Support per ThaddeusB. –Drilnoth (T • C • L) 16:55, 16 October 2009 (UTC)
  • Support - if nothing else it's a good way to help the neophytes learn the ropes and get an idea of what's important. Shereth 18:00, 16 October 2009 (UTC)
  • Support More user friendly than a deletion due to processes/policies newbies won't (and shouldn't be completely expected to) understand. --Cybercobra (talk) 18:34, 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.  Skomorokh, barbarian  19:06, 16 October 2009 (UTC)
    • Could you expand on that? Rd232 talk 19:27, 16 October 2009 (UTC)
  • Comment I guess the core idea is OK. I think the current proposal of sticking things in userspace with a wizard will turn CSDs into MfDs, which is a considerably more heavyweight process. As well, keep in mind that userspace remains indexed in search engines, so all these unreviewed drafts will be visible to the general public under the Wikipedia banner. This wizard might become known as the "publish an autobiography to the world for free" wizard. Gigs (talk) 19:24, 16 October 2009 (UTC)
    • the {{Userspace draft}} template which the wizard employs applies {{noindex}}. Rd232 talk 19:27, 16 October 2009 (UTC)
      • Thanks, but why not {{UserWorkInProgress}}. Gigs (talk) 19:35, 16 October 2009 (UTC)
        • Not familiar with that one. There's also {{Userfiedpage}}, and there may be others! {{Userspace draft}} is associated with the Article Wizard, which uses that terminology (and the template adds dated maintenance categories which link it with the wizard). Rd232 talk 20:56, 16 October 2009 (UTC)
  • Support If I didn't make that clear above. — Jake Wartenberg 20:59, 16 October 2009 (UTC)
  • Oppose Needless bureaucracy, makes it even harder for newcomers to contribute. After checking out the wizard again, I cannot imagine that a person who isn't already deeply addicted to Wikipedia would bother to go through it. --Apoc2400 (talk) 21:42, 16 October 2009 (UTC)
    • Remember this would only apply to users who are not yet autoconfirmed. What looks to an experienced user like tiresome bureaucracy will hopefully look to a newbie like useful tutorial/walkthrough. Anyway, suggestions for improvement welcome. Rd232 talk 22:12, 16 October 2009 (UTC)
      • An improvement would be to cut the whole thing down to reasonable length, a handful paragraphs of text with links to more detailed explanations. Also reduce the ridiculous number of clicks you have to go through. Seriously, has this "wizard" ever been tried on a non-Wikipedian? --Apoc2400 (talk) 22:29, 16 October 2009 (UTC)
        • To answer your question, most of the articles and drafts emerging from it were created by editors with no prior experience. Rd232 talk 11:40, 20 October 2009 (UTC)
  • Support per Thaddeus and Jake. On the whole, looks like a great solution. I have a feeling that we'll have some wrinkles to iron out with usage of the Wizard, but it should be a good balance between non-biting and alleviating the number of speediable new pages. JamieS93 21:45, 16 October 2009 (UTC)
  • Oppose as premature. We need more perspective and time to see how the wizard works on new users, get feedback. And feedback from new users; of course it's difficult because they are 'afraid' to edit and give feedback onwiki - they aren't in a known environment; I've been thinking on ways to get feedback from new users and I'll elaborate on this in the usability community initiative that I hope will soon be launched. I urge the community to not take such decisions in haste, the wizard was created only in September, we can't evaluate its effect in such a short time. We need to take a thoughtful and measured stance on this. I'm also concerned by the number of good submissions that could be lost in userspace. Cenarium (talk) 22:30, 16 October 2009 (UTC)
  • Strong support – that would greatly help as far as quality-control in new pages as well as new page patrol and speedy deletion volume are concerned. In addition, it would help out new editors who may not be familiar with wiki-syntax (let alone other common Internet/computer things). MuZemike 22:32, 16 October 2009 (UTC)
  • Strong oppose as premature. A recent experiment ( see User:WereSpielChequers/Newbie treatment ) has established that Wikipedia is functionally at the moment extremely hostile to new users. That state is not an acceptable sustainable long term place for the community to remain and must be remedied. This particular proposal - making what is a useful guide mandatory - is unfortunately a step backwards on that front. Further analysis of the Newbie treatment experiment is needed, but taking any' steps to worsen the situation at the moment is ill-conceived. I appreciate why new page and recent changes patrolers like this - none of this changes that we do have quality problems and spam problems. But in the long term, chasing all potential new contributors away will kill us dead, and is not an acceptable way for us to operate. We have to understand that problem and work to ameliorate it as we work to keep quality up. Georgewilliamherbert (talk) 23:09, 16 October 2009 (UTC)
    • The obvious answer to this is that forcing use of the wizard would reduce the kinds of problems seen at the "Newbie treatment" experiment. The wizard gives users a series of tests to put their idea through, in order to determine if they should be creating an article for the subject (yet). That might be more welcoming than letting all new users create articles that have a good chance of being deleted; false hope, the crushing defeat of a deletion, and all. On the other hand, that might be a self-serving argument, since our aim is really to reduce our own workload regarding new pages. I've done a little playing with the wizard though, find it pretty reasonable, in that any newbies with good intentions won't mind and may even appreciate the gradual process the wizard affords them. In the end I'm still undecided on this, but I thought these might be helpful thoughts. Equazcion (talk) 23:44, 16 October 2009 (UTC)
      • I think that's a nice theory, and if it actually functionally works that it's friendly enough that it is a net plus then it's a win on that front. What I am saying is that it's not obvious that it will be a net win on that front, and until it's demonstrated so let's not put it into action. It needs some testing and discussion. We are not at the point where deploying this is a good idea. Georgewilliamherbert (talk) 00:31, 17 October 2009 (UTC)
  • Strongest possible oppose The continued life of Wikipedia depends upon attracting as many new editors as possible. We should encourage every conceivable way for people to create articles. Citizendium, for example, has an arrangement where, basically, people simply email their suggested article in any format whatsoever, and people format it for them--if they don't have sources, someone emails back and asks for them. The RA system is even more complicated than starting from scratch. I've been a little doubtful, since I see many really poor articles made with the template, & have even been deleting some as speedies, & I just gave it a try, and it was even worse than expected. I agree it could be improved to help people as an option, after all, a few people actually prefer filling out multi-stage forms & there is no reason to rule them out as contributors either. We should not even be rejecting article ideas without sources, if someone can quickly find the sources. What we need is to actually follow WP:BEFORE as policy, and when someone submits a poor article, someone experienced tries to see if it can be saved, not see if it can be deleted. There's a few of us who do one or two a day at CSD or PROD or NP, but we need a few hundred others. In any case, I see no evidence that autoconfirmed users are better at this than raw beginners. It helps rule out a few one time vandals, but not the ignorant or the self-promotional. DGG ( talk ) 00:59, 17 October 2009 (UTC)
  • Oppose Those above have put it very nicely (albeit lengthily) but essentially I see no reason whatsoever for this. Requiring registration is enough of a block to keep most crap out, and while some gets in, it gets dealt with pretty quickly (despite betacommand's note). As I see it, there are three reasons to register: You want to customize Wikipedia to make reading easier/better, you want to make a quick typo fix (me), or you found a topic without an article that you want to write about. That third group is the one we want to foster the most, and is the only one that would be affected by this proposal. If our main producers of new content are blocked from creating what they want to, why should they bother and stick around? It's the same argument as applied against Flagged Revisions, except applied across the board and only for new users. We've only got a half-dozen or so thousand active editors out of 10M accounts, why make it worse and drive others away upon finding they have to register and make 10 edits? Ten may not seem like much here but those first few can be rough. I don't know why people are bringing up the Wizard as a solution - as far as speedy deletion is concerned, a poorly written article should be just as easy or hard to nominate as good ones. The problem lies in biting users (I've been following Newbie Treatment closely) and over-active speedy nominations. We're adding over a thousand articles a day in spite of all the AfDs, ProDs, and CSDs that go on, so this seems way too aggressive. ~ Amory (utc) 01:51, 17 October 2009 (UTC)
    • You're a bit lengthy yourself there :) I'm largely playing devil's advocate here as I'm personally undecided, but I feel I must repeat the point I stated in reply to Georgewilliamherbet above. When an article you create gets deleted, it's a very disheartening experience that causes many newbies to retire before they even understand what happened. When you have to use a process to gain entrance to a new venue, that can certainly be an annoyance; but does it compare with working hard on an article, thinking it will now be a permanent part of Wikipedia, and then seeing it deleted? If we're going to reject this proposal, let's at least be fully aware of the possible gain that could come from it for newbie retention. Equazcion (talk) 02:02, 17 October 2009 (UTC)
      • We can't evaluate potential gains and the effect on new users/article creation when the wizard has been up for a month and so. We need to get feedback and make a general review on how we deal with new users. Cenarium (talk) 02:32, 17 October 2009 (UTC)
        • Agreed. However you shouldn't just be telling me that. People seem to be opposing this on the grounds that it necessarily increases bite, and I take issue with that because the case may very well be the opposite. Equazcion (talk) 02:41, 17 October 2009 (UTC)
          • By all means, play away! To respond, though, I work at articles for creation in my spare time and when you ignore the copyvios and "my band is awexome" submissions, there are really two kinds left: Those that are quick pieces of text (somewhere between a few sentences and a paragraph or two) because of an editors specific knowledge and those that are essentialy a copyedit and extra source away from wonderful. And remember these are all from IPs - this proposal would apply even more process on users wishing to register. Preventing non-autoconfirmed users from creating articles would prevent the former (possibly forever) and delay the latter. Most people don't have a full C- or B-class article waiting in the works for edit #11 but rather a few sources and some prose about their pet interest, and I just don't see how the Wizard will help significantly there. As for the hurt feelings, they are regrettable, but any fault lies between the individual and the tagger, and is no need to punish all new users. ~ Amory (utc) 02:48, 17 October 2009 (UTC)
            • Boy, lemme tell you what... :) The wizard doesn't disallow people from putting articles directly into mainspace. It just makes you consider a series of questions about your topic/content first, so you can deduce whether or not it's appropriate. You can blow through it in about 20 seconds if you don't care about its questions. Hurt feelings were my main point though -- as well as yours, in your first post anyway; "driving away" new editors and avoiding "bite" are both issues of editors' feelings. It seems unreasonable to think we can solve the problem of hurt feelings by just telling everyone to be nicer (we always seem to be doing that anyway). Instead, we could work to prevent the creation of many deletable articles in the first place, and the wizard is meant to do that. The user who would have become disenchanted, by creating an article that got deleted, might now instead see from the get-go that it wasn't an appropriate article, and stay with the project. Less newly-created articles that require deletion could mean more retained users. That might be a good tradeoff for a little extra time forced on newly-registered users during article creation. Equazcion (talk) 04:11, 17 October 2009 (UTC)
              • Devil's Advocate or not, I was with you right up until the end there - it's that "forced" part that bugs me about this. I simply cannot see a future where more restrictions = more and better content. Wikipedia was and is successful thanks to people who take pleasure in typing whatever they want and then seeing it go live; let's not take that away. As I implied above, I see this proposal as similar in spirit to FR, but for all new editors. ~ Amory (utc) 12:21, 17 October 2009 (UTC)
                • That's a very good point, and I'm not a big fan of added restrictions myself. I agree what's special about Wikipedia is that strange initial trust and power everyone gets. It would be bad if that were lost. Equazcion (talk) 15:43, 17 October 2009 (UTC)
  • Support – in a time when it's increasingly rare to find a notable topic that does not have an article, this proposal is a good idea. —Anonymous DissidentTalk 03:09, 17 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. Wikipedia:Article wizard 2.0/Userfeedback (linked from the bottom of the final page of the Wizard) did lead to some changes, as did comments coming from other sources. But the Userfeedback page is relatively underused. So how are we going to get more feedback from the sort of users who are in the target audience? Suggestions? (b) articles output from the Wizard aren't really any better. This I'm inclined to doubt rather strongly, but there is a question how much of it is a selection effect (people choosing to use it being more likely to produce decent contributions). An unscientific "look-see" comparison with generic New Page output suggests it's worth a trial, but maybe we can figure out a better way to analyse this. (c) other. People opposing for other reasons might like to elaborate them and suggest ways the reasons might be overcome given improvements etc. Really, given the biteyness of deletion, we should seriously consider trialling the biteyness of forcing non-autoconfirmed to use the Wizard (when it's ready). Or perhaps a Wizard - the 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)

  • Absolutely not The article wizard seems helpful, and I don't want to malign its creators or proponents, but we don't need another process between people and participation. Besides, we have an image wizard (where it is arguably necessary to some degree) and avoidance of the image upload criteria continues. I have no way of measuring how much the image wizard reduces uploads which will be deleted so I can't make a complete argument on that point, but the primary benefit of the image upload wizard isn't avoiding deletion by preventing uploading. Protonk (talk) 17:00, 17 October 2009 (UTC)
    • Well if you view the Wizard as "a process between people and participation", it's all gone a bit wrong, hasn't it? It's supposed to be an aid. Maybe the current version isn't good enough, maybe now's not the time, but it seems too many people do try to start something without even a basis of a clue. If we can help them, we can help Wikipedia. If we can help them and reduce the workload of handling errors, we can help newbies better, and generally have more energy for improving. As in many cases, I'd rather design a good trial and see what happens than end up sticking with a poor status quo because a particular idea might cause more problems than it solves. If you don't fail sometimes, you're not taking enough risks. I'm not saying we absolutely have to do this, but in general we are collectively far to scared of trying things. Rd232 talk 21:55, 17 October 2009 (UTC)
      • General point: we need to find better ways to help those users likely to become editors of some substance, and deter those who are just larking about or here for self-promotion (and possibly convert the latter into the former). Basically we have too many editors who contribute My First Article and sod off before learning anything about how policies or formatting or sourcing work, and too few who graduate to some minimal level of knowledge and commitment. I think this Wizard both helps the right people and deters the wrong ones (partly by showing them that what they want isn't permitted), and making it compulsory worth trying, but, y'know, other ideas welcome. Rd232 talk 00:02, 18 October 2009 (UTC)
        • The first problem is that the wizard is based on the idea of learning by (forced) reading of instructions. In fact most people learn this kind of skills by a mix of trial-and-error and by example and imitation. Second, if we expect people to contribute for free, then it has to be easy and trouble free. Those already hooked on Wikipedia seem to take all kind of abuse and will do just about anything to be able to edit, but newcomers won't. Those who are here to abuse Wikipedia for their own benefit on the other hand have other incentives than personal gratification, so they can deal with bureaucracy better and putting up more signs aren't going to stop them. Third, making it easier for admins and rule-enforcers is not the primary purpose of Wikipedia. Newbies messing up while learning is not a problem, it's the natural state of affairs here. --Apoc2400 (talk) 14:46, 18 October 2009 (UTC)
          • There are degrees of messing up. What the Wizard is supposed to do is help people decide whether an article on their proposed topic is likely to be accepted, i.e. not be deleted, and what they need to do to achieve that. People who don't want to read the instructions can click through as fast as the pages will load - the "correct" answer is generally obvious. Of course it can't make them experts on everything Wikipedia - aeons of learning process lie beyond. But at least even in skimming the instructions, some inkling of the ideas and terms they will soon be confronted with when their user talk page gets plastered with delete warnings, say, or talk pages and edit summaries perhaps, hopefully sticks. PS Actually, making life easier for admins and non-admin janitors is a key goal, because (a) there aren't enough for the work and (b) if they ran out of work, they could help newbies more, improve articles more, etc. Rd232 talk 19:57, 18 October 2009 (UTC)
  • Oppose- Wizards should always be optional. Maybe link to when a new user attempts to create a new article but making it mandatory adds needless complications. -- penubag  (talk) 03:12, 18 October 2009 (UTC)
    • Crap, it's reached the point where it's turning into a vote, and people aren't engaging with the arguments any more. Rd232 talk 09:48, 18 October 2009 (UTC)
  • Strongest support We don't need more non-notable/unreferenced/unwikified/inappropriate articles from people with zero experience. The article wizard looks useful and effective. We're at a point where we don't need as many new articles, but rather improvement. New users should be expected to have an idea what they're doing before creating an article. I don't care if it's only one other edit, but there must be some sort of experience requirement before new users can create articles that others must filter and either take care of or delete. If the person has a valid topic and wants to make a nice article out of it, then they can either make a few edits elsewhere or use the wizard. Reywas92Talk 18:40, 18 October 2009 (UTC)
  • It looks like this is going nowhere, and I haven't read most of it. But, biting newbies is a major problem, but I think, counter intuitively, more restrictions need to be placed on their early edits, so that we don't bite them. - Peregrine Fisher (talk) (contribs) 04:59, 19 October 2009 (UTC)
  • Comment - for the opposition, perhaps like a day long trial? it would be bold! JoeSmack Talk 05:53, 19 October 2009 (UTC)
    • I'm all in favour of trials, even of things I think are good ideas. Unfortunately this requires a software tweak to make it feasible, which for a short trial isn't going to be high priority. (Something the opposers might bear in mind: agreement here means probably 3-6 months minimum before implementation.) Anyway unless we're willing to countenance the non-software version I mentioned above (requiring non-auto-confirmed to create drafts in their userspace, which others can then promote if the users can't wait to be autoconfirmed), then the likelihood is this isn't going to go anywhere for a short trial. Rd232 talk 08:14, 19 October 2009 (UTC)
  • Oppose, I can see the advantage of the wizard but I don't think it should be forced upon new users. Frankly I can see many taking one look at it running off scared. Before even considering questions of notability new article creators seem to be expected to read (among others): Wikipedia:Your first article, Wikipedia:Verifiability, Wikipedia:No original research, Wikipedia:Neutral point of view, Wikipedia:What Wikipedia is not, Wikipedia:Reliable sources, Wikipedia:Independent sources. Policies and guidelines are learnt over a period of time, either a user is allowed to create an article or not - this does not seem like a realistic halfway house and in the end good users who will be put off. The good content that will be effectively lost in my opinion outweighs any advantages. Guest9999 (talk) 22:00, 19 October 2009 (UTC)
    • It's a valid point in general, which I think the Wizard respects far more than you imply. Wikipedia:Independent sources is an essay I wasn't aware of, and isn't linked to (though the point about independence is made in the Wizard). WP:RS, WP:NPOV and WP:V are described, and linked to in case people want clarification; it's not expected that users will read them at this point, and they shouldn't have to. I've removed reference to WP:OR, the gist of which is sufficiently covered on the Sources page without getting into that, and reference to WP:NOT as unnecessarily complicating in the Wizard. Rd232 talk 11:50, 20 October 2009 (UTC)
  • Oppose: The wizard as currently implemented is designed to prevent certain classes of article from being created, rather than to help people create good articles. When I clicked on "I'm writing about a company", I got several pages of efforts to discourage me from writing the article. What I expected to get was help on writing an article on a company, perhaps a guide similar to Wikipedia:WikiProject Military history/Style guide#Article content. If we're going to force people to use this, we should design it to help them, rather than to help us. --Carnildo (talk) 22:05, 19 October 2009 (UTC)
    • To be precise, you get several pages of efforts to discourage people from creating spam. I think your suggestion of introducing more detailed/positive help, probably from wikiprojects, is good, but it needs to be a hell of a lot more newbie-friendly than the style guide you linked to. Rd232 talk 11:36, 20 October 2009 (UTC)
  • Weak oppose I am torn, but Carnildo's experience above veers me slightly into negatory territory. I am still undecided about whether forcing a wizard is a less morale-reducing experience than aggressive tagging and deletion of new material by inexperienced editors. Casliber (talk · contribs) 22:11, 19 October 2009 (UTC)
  • Strong Oppose I feel like this would make it unduly complex for new users to create new articles (It is already to complex IMO) and I feel forcing users to go through that process goes against our open "anyone can contribute" spirit. Mifter (talk) 00:21, 20 October 2009 (UTC)
  • oppose Unecessarily difficult, too complicated. Too discouraging. We've had the total number of articles created go down over time. That's true even if we just count articles that aren't deleted (and thus measures what can be reasonably seen as an actual problem). This would increase that problem rather than reduce it. Moreover, it would intimidate new users and make them less likely to stick around JoshuaZ (talk) 03:36, 20 October 2009 (UTC)
    • Suggestions for improvement, then? NB I vehemently contest that the number of new articles declining is a relevant metric at this point in Wikipedia's history. At 3m articles, we have a vastly larger proportion of all the articles we'd like to have than when we only had 100,000 articles. The average user is necessarily less and less likely to come up with an idea for an article on a topic which is both notable and easily researchable. (The long tail of notable topics not covered increasingly stretches into harder-to-research areas which the average user has little interest in and little ability to contribute to.) Rd232 talk 09:56, 20 October 2009 (UTC)
  • Oppose, oppose, oppose. Why would we possibly want to make it even more difficult for new users to create articles? How many wonderful new article could we possibly be losing because a new user sees this bureaucratic structure, get discouraged, and leave? 99.166.95.142 (talk) 16:23, 20 October 2009 (UTC)
    • Yes, it's much better to let users flail around without a clue as to the basic requirements to avoid their article being speedied, PRODded, etc, because they (90% of them anyway) can't be bothered to RTFM if it isn't necessary and it isn't clear that they really really should. Users are much less discouraged if they don't have clue and their article gets deleted. Let's stick with the status quo that's working so well! Rd232 talk 16:31, 20 October 2009 (UTC)
    • PS Describing a wizard as a "bureaucratic structure" is an abuse of the English language. No cookies for you. Rd232 talk 16:32, 20 October 2009 (UTC)
  • Oppose as restricting someone's ability to edit is a violation of Wikipedia:Five pillars. I have gone through the Wizard and found it off-putting. The wizard doesn't appear designed to assist someone to create an article, but is designed to ease the work of existing experienced editors. The telescope is looking the wrong way. For example - this page asks "Does your proposed article have proper sources?" after some text that possibly won't be read. Where's the actual help for the person at this stage? How about using a {{find}} template and suggesting that the editor enters the name of the topic, and let the find template supply some sources the editor can use. The Wizard appears to be telling people that there's a bunch of complex rules they don't understand, so why are they even bothering to try. There's no assistance, just a bunch of Wiki-jargon and nonsense. SilkTork *YES! 19:17, 20 October 2009 (UTC)
    • Cough, I hope you just got the link wrong and weren't actually looking at the WP:AFC wizard... The equivalent Article Wizard page is here: Wikipedia:Article wizard 2.0/Wizard-Sources. And you might like to click on the link there "My proposed article does not have good sources (yet)", because then you'll find, wait for it... {{find}}. PS Constructive comments on what jargon is avoidable welcome. WT:WIZ2, the maintenance/design page, isn't exactly over-run by people suggesting improvements. Rd232 talk 20:44, 20 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 {{find}} template to be more useful; I left a note at 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)
  • Oppose I was about to write a lengthy and partially eloquent rationale why this would be a bad idea™ but DGG already said all there is to say. I think the wizard is a good thing to have for new users but nothing should force people to contribute in a certain way only. We can place a link on the message that shows on non-existent pages that people should use the wizard and encourage its use but we should not force people to do so. Regards SoWhy 07:17, 21 October 2009 (UTC)

Comment. Thanks for everyone's input. To reiterate, the proposal was motivated by discussion at Wikipedia:Requests for comment/new users on how to help new users, and was originally caveated with "when the Wizard is ready". The Wizard maintenance/design discussion page is WT:WIZ2, and I'd encourage everyone to contribute or at least watchlist it. I'd also encourage everyone to participate in Wikipedia:Requests for comment/userfication, because more userfication (if we can develop processes to mitigate the disadvantages of that) will be an alternative way of reducing the WP:BITEyness of "argh, why was my article deleted, well 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, Borough President. I've seen obscure politicians from long ago suddenly change color without warning in editing election tables, and I'm sure the same phenomenon is true of those who make lists of teams, sporting events, 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

Resolved
 – Converted to an RFC, at Wikipedia:Requests for comment/userfication. Comments there please.

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

  • identifies the page creator, and moves the page to their userspace (without leaving a redirect, of course)
  • removes any CSD tags or hangon tags
  • adds {{userspace draft}}
  • notifies the creator of the move.

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

I like the idea of adding this to Twinkle. {{Userspace draft}} places articles in Category:Userspace drafts created via the Article Wizard, which is not quite appropriate. There exists {{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 {{userspace draft}}; there are several of this type) which includes {{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 "You are not currently logged in" message, but the warning triangle and language are too 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 Help:Categorization. We also have Wikipedia:Categorization, which is even longer. Who would ever read that much 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. Kevin Rutherford (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

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 WP:COPYCLEAN has attempted to fill this gap with Wikipedia:WikiProject Copyright Cleanup/Contributor surveys, this solution is not ideal. It is difficult to publicize and to regulate, and in addition it may seem to suggest exclusivity. I hope that generalizing clean-up will encourage other contributors as well as making it easier to publicize the investigation option at relevant policies and guidelines. (To substantiate the need for this, I need only point out the listings currently at Wikipedia:WikiProject Copyright Cleanup/Contributor surveys and those few which have already archived. Additionally, these come up routinely at ANI, where response is hit-and-miss, depending on who is reviewing ANI in a given day.) The processes proposed are based on existing policies and practices for handling copyright problems (I've worked with many of these); the board is inspired in large part by WP:SPI. More information is available at the process page and in the purpose statement at the process talk.

I think this is critically needed. Wikipedia has chosen to address copyright concerns proactively, demonstrating due diligence, and when we know a contributor has widely violated copyright, we must have a streamlined process for handling it. The primary point for text copyright issues, WP:CP, cannot handle this specific situation: a listing such as Wikipedia:CCI/Singingdaisies would bring it to a halt.

Please help address this need. Your comments are much welcome at WT:CCI. :) --Moonriddengirl (talk) 12:14, 24 October 2009 (UTC)

Notability of numerous numeral systems

A discussion of the WP:Notability of numerous Positional numeral systems has begun at Category talk:Positional numeral systems#Notability.

There are currently articles on bases 116, 18, 20, 24, 26, 27, 30, 32, 36, 60, 62 and 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" MBelgrano (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? MBelgrano (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 don't think this is a good idea. Page history should be machine-readable; it should be possible for a machine to find out who did the first edit to a page and statistics about the number of editors and their edit frequency. Also, in my experience, when edit history becomes fragmented, parts of the page history can be lost over time due to admins who delete things without checking the page history. If an admin needs to delete a page with over 5,000 edits, the admin can just ask a steward as they are not subject to the 5,000-revision limit - see the deletion log for "football". In my experience, eletions of less than 10,000 revisions cause the database to lock for only a few minutes at the most, and I can't think of a good reason to delete a page with more revisions than that. The history merge case at apple is exceedingly rare; most pages with many revisions can be adequately history merged using this method.Graham87 15:48, 25 October 2009 (UTC)
      • My concern about admins deleting fragments of the page history probably wouldn't be much of an issue if we educated them about the potential new policy. Graham87 15:52, 25 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)
  • We have a dilemma:
    1. Leave the edit history intact while it accumulates well over 5000 edits, and temporary deletion for housekeeping becomes difficult as in the page Apple incident linked to above.
    2. Split history, and cause difficulty for bots, as User:Mr.Z-man says; but if the archived old sections of the history had a standard addition to the page name, the bot would know where to look for the archived old sections of the history.
    Anthony Appleyard (talk) 22:47, 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. - Jarry1250 [ In the UK? Sign 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, MediaWiki:Welcomecreation, is currently shown once, after successful account creation via 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

  • Support We've got plenty of readers, we need editors. - Peregrine Fisher (talk) (contribs) 07:08, 13 September 2009 (UTC)
    • Nice to see that we are reaching some consensus this quick. I think Wikipedias Main Page need some drastic changes like this one in order to improving the overall standard of Wikipedias articles. And as Peregrine point out we already have readers we need editors and we need to improve the overall standard of our articles.--Judo112 (talk) 07:34, 13 September 2009 (UTC)
  • Support One suggestion: the pool of articles should be those labelled "High Priority" by numerous projects. In this way, the improved article is likely to be a greater contribution to a whole; and if supported by a diversity of subjects, likely to appeal to more editors. Iciac (talk) 08:25, 13 September 2009 (UTC)
  • Oppose – the process for choosing the daily 'featured needy article(s)' would necessarily have to entail either a means of selecting the worst articles on Wikipedia, or the best-but-still-need-a-teeny-bit-of-finishing-off-work articles. Either we showcase the trash, or we showcase good work and pretend that it's our trash. I don't think that this is a viable idea, I'm afraid. ╟─TreasuryTagsenator─╢ 08:39, 13 September 2009 (UTC)
  • Oppose Per treasur tag, and because we should present a good finished face to the world. —Preceding unsigned comment added by Patton123 (talkcontribs) 10:27, 13 September 2009
  • I like it! I suggest we choose articles that are 1) important subjects for an encyclopedia, 2) currently not good and 3) needs general attention more than Wikipedia experience. Take Parent: Everybody knows what a parent is. There is plenty of reasearch about parenting, the role of parents in history and different cultures, etc. Our article is absolute crap and doesn't seem to be getting anywhere. There would be an overlap in purpose with DYK, which is supposed to show new and far-from-finished article. However, DYK has been raising its standards and left room for something like this. That hard question is where to put this on the main page. --Apoc2400 (talk) 11:26, 13 September 2009 (UTC)
  • Support apoc idea: We could do it as Apoc points out. All i am interested in is that it will be on the Main Page so that we see some results.--Judo112 (talk) 13:49, 13 September 2009 (UTC)
    • And for those opposing, what kind of image/face do wikipedia show when we have tousands of stubs and not well references articles that could be helped by this suggestion?. This idea would increase the overall standard of wikipedias article and thereby help Wikipedia get a better reputation in the long-run.--Judo112 (talk) 13:49, 13 September 2009 (UTC)
      • By the way who is the second to oppose.the person hasnt even bothered to sign hes/hers comment.--Judo112 (talk) 13:53, 13 September 2009 (UTC)
        • Parent would be a perfect article for the main page. Friendship, Cuisine, Love letter and World are other examples in the same vein. GeometryGirl (talk) 14:02, 13 September 2009 (UTC)
          • Many of our vital articles are like that – concepts that are so general no one thinks to work on them, like fear, woman, toy, trade, area. In fact, the vital articles list would be a great place to start. —Noisalt (talk) 16:00, 13 September 2009 (UTC)
            • I was thinking about vital articles as well. That would probably last us a few years, if we did vital articles below GA or below B. Random stubs will not work, because a lot of them may need merging or deleting, or the difficulty in researching them is too high. Even though we'll get some help from people who have never edited, the work (that lasts) will still be done mostly by normal editors, so highlighting the vital articles would get them on the way towards the next B,GA,FA, level, which is hard to argue against. - Peregrine Fisher (talk) (contribs) 16:44, 13 September 2009 (UTC)
  • Support: I've both read about and seen for myself that the Wikipedia editors' community is becoming...insular. It isn't what it used to be, that for certain, and that is definitely not just the registered editors' faults. Unregistered vandals make casual editing hard for those who wish to do it. Nonetheless, I believe an 'Articles Needing Help' section could give a jump to the casual editing community, something which Wikipedia needs to maintain, lest it become Conservapedia. Okay, maybe not that far, but... BobAmnertiopsisChatMe! 16:47, 13 September 2009 (UTC)
    • I say for once let the village pump discussion lead to something. Lets make room for this new section on the Main page where it fits so it will be usefull. And let start with the article Toy. that will be a great start.--Judo112 (talk) 16:52, 13 September 2009 (UTC)
      • So feel free to fix it. Would be so happy for Wikipedia if we finally did something new and refreshing for the Main Page.--Judo112 (talk) 16:54, 13 September 2009 (UTC)

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

  • Oppose per Treasury Tag. Do we really want our worst articles on the front page? AniMatedraw 21:34, 13 September 2009 (UTC)
    • Wikipedia is an ongoing process, asking people to help edit some of the poorly written articles just shows that Wikipedia is not complete, and is always looking for proper edits to our articles. warrior4321 21:44, 13 September 2009 (UTC)
      • I second Warrior's reply. GeometryGirl (talk) 21:51, 13 September 2009 (UTC)
        • Yes, but traditionally the front page has been for our best articles. I think the best way to get more and better editors is to highlight the best of our work, not the worst of it. There are other ways to get people to edit articles that fall under this criteria... criteria that doesn't exist, mind you. This seems like something that could be handled by a WikiProject or some other process. Perhaps contacting the folks in charge of the signpost might be a better idea, or creating a template like the {{pic of the day}} that someone could update would work. Regardless, I do not believe this is appropriate for the main page. AniMatedraw 21:53, 13 September 2009 (UTC)
          • "traditionally the front page has been for our best articles" -> This is false: DYK and ITN highlight what Wikipedia does worst; newly created unfinished stubs, and articles on rapidly changing topics prone to editwars. GeometryGirl (talk) 22:04, 13 September 2009 (UTC)
            • So you now want to promote more "unfinished stubs"? Nice. Honestly, DYK, ITN, and FA are great for our readers. One deals with interesting topics they likely haven't heard of, one deals with timely articles they likely have an opinion about, and the third shows off our best articles. These are positive ways to draw in new editors and readers. This new idea would be showing off our crap. This is a negative way to draw in new editors and readers. I'm still opposed, especially since there are other ways to do this internally, like I highlighted above. AniMatedraw 22:25, 13 September 2009 (UTC)
  • Oppose Why would readers be interested in 'articles to improve'? This is clear a change to the long established consensus that the main page is for readers not for editors and while consensus can change, it is important editors understand that the consensus was there and why it was there but I see no mention of this in the proposal which doesn't bode well. In any case, DYK in particular, and to a lesser extent ITN already fulfill the purpose. If really necessary, we could emphasise that editors are needed for DYK articles. Nil Einne (talk) 22:31, 13 September 2009 (UTC)
    • Isn't the goal of a wiki to remove the editor-reader distinction? Cool3 (talk) 22:37, 13 September 2009 (UTC)
      • Who told you that? There are in fact a large number of closed wikis that only allowed selected editors and some people even use wikis for their personal website which only they can edit. Wikipedia does allow anyone to edit, that doesn't mean we think of readers and editors as the same thing. In many areas, even outside the main page, our primary focus is our readers, since we are creating an encylopaedia for readers and not for editors. We would hope many of our readers would be editors, but that doesn't mean we try to force them to be or think there's no distinction Nil Einne (talk) 22:49, 13 September 2009 (UTC)
    • Nil Einne: Why would readers be interested in On This Day? Or Did You Know? They're so boring. But the fact that I'm not interested in it doesn't mean someone else can't be interested in it.

      As for this "consensus that the main page is for readers, not editors", I'm curious as to where that came from. I've never heard of it before now. —Noisalt (talk) 22:57, 13 September 2009 (UTC)

      • Obviously your entitled to think they're boring. I suspect many people are interested in learning more about stuff that happened today in history, it's a common thing in newspapers and websites alike. I guess you can call an interest in history a common human quirk and one of the ways that interest is sparked is by thinking what happened today in history. Similarly while many people may not find most thing in DYK of interest, I suspect many readers will end up reading at least one, we do have a lot of them and change them about every 8 hours, so it's not that hard. As you've acknowledged many people do have an interest in reading more about things which seem boring to you (and it should also be obvious that most people come to wikipedia to read not to edit). It's also quite clear it's our intention with DYK to interest our readers hence why we call it 'did you know' not 'wanna improve these recent articles?' and why we aim for an interesting hook to interest readers.

        As for never having heard of the main page being for readers not editors, have you ever actually participated in any area of the main page? I'm not trying to put you down here but this comes up all the time in Talk:Main Page and also in WP:ITN (it's why we don't put up things which are likely to be of substanial interest but don't yet have sufficient relevant content in the article) and I would suspect every other area relating to discussing the main page. For example this early discussion Talk:Main Page/Archive 4 from 2002/2003 implies it. Notice how there are multiple mentions of what the readers wants and even We're trying to keep editor links to a minumum on the front page. The earliest explicit mention of the main page being for readers not editors that I found is from early 2004 Talk:Main Page/Archive 14#Unique nature of Wikipedia is submerged, I think the explaination there is still of some relevance. Since there was some objection there, I would note it was next expressed at Talk:Main Page/Archive 25#Bootiful! with no objection. I would also note that in many of the other discussion it was implied as in the earlier discussion I pointed out, e.g. you'd find many discussions about how to make things better for readers. You'd likely also find a number of relevant discussions here [13] and [14] since as I mentioned this is often comes up. Nil Einne (talk) 23:38, 13 September 2009 (UTC)

      • I'll second Nil Einne. Stats show that almost anything put on DYK gets a substantial boost in pageviews, which is a good indicator that readers are attracted (probably by the hooks). DYK and ITN articles are theoretically great ways to pull a reader someone into editing - the articles are being actively looked after, so talk page discussions don't take weeks to get a response (or months, or even years as I've seen happen before to new editors, who abandoned the project long before getting a reply!) That means there is more guidance available to help a new editor through the hoops. Since neither DYK nor ITN articles are at featured standard, they often have room for improvement (and ITNs frequently need updating), so new editors have opportunities. Nevertheless they are only linked to from the main page if the article already has passed a certain quality standard, which may help new editors get the gist of what is acceptable. On the other hand, I admit I haven't seen specific evidence that ITN and DYK do draw in new users. We really need a more comprehensive study of what the pathways are to becoming a Wikipedia editor - my bet would be on people who are start editing annoying typos, which doesn't seem strongly linked to main page use though certainly typos often appear in DYKs. (I wonder if we should develop an evil "trapdoor" feature to entice unwary readers into editing, by autodetecting common typos on unprotected pages ... give unregistered users a banner warning that a possible error has been detected, asking them to click if they want to see it ... the typo gets highlighted and an "Is this a typo? Y/N" dialog box appears ... if they click "Y" a tool tip gently points them to the edit button ... and then we've got them ;) Particularly if they get a nice thank you message after saving, suggesting they register for an account, and an automatically tipped-off newbie-greeter leaves them a message, thanking them if it's a genuinely constructive edit, on their IP talk page just in case they don't avail themselves of the opportunity to sign up straightaway. I'm sure this would be a nightmare to program, but I reckon it'd be frighteningly effective!) TheGrappler (talk) 01:26, 18 September 2009 (UTC)

break 4

  • Oppose - Duplicated by DYK, and Random article. Cirt (talk) 23:18, 13 September 2009 (UTC)
    • I wouldn't say that a DYK hook encourages readers to help cleanup the article, but I can see how Special:Random can be helpful to entice readers to starting fixing up articles, as most of the time every second click will result in some stub needing cleanup. Also there's WP:CHALLENGES as displayed in the highly visible Special:RecentChanges page which lists 4 articles instead of one that could use some work. -- œ 23:51, 13 September 2009 (UTC)
  • Oppose The encyclopaedia must be kept separate from efforts to entice readers. It's all very well to attach "edit" tags, and exhortations to get involved at the fringes of our pages, but intolerable on the front page of the product. Our mission must come first.  Skomorokh  23:23, 13 September 2009 (UTC)
    • Reply - Funny, I thought our mission was to build a free encyclopedia that anyone can edit. How does encouraging more people to edit an article that needs help conflict with that mission? If anything, this helps the mission! Nutiketaiel (talk) 16:49, 17 September 2009 (UTC)
  • Additional comment As for the vital article proposal, I can see that as having the potential to destroy vital articles completely and I'm not exaggerating here. As someone who is a resonably regular participant in WP:ITN, Talk:Main Page and has also seen many other trouble hotspots, I know that there is strong concern among many editors of WP:systemic bias and in particular us exposing it on the main page. Indeed when I first read of vital articles (and similar things) a while back, it was one of my first thoughts and while it doesn't look too bad, it's not perfect and I can easily see a number of areas of contention. I strongly suspect one of the reasons why it has survived as well as it has is because many people don't care that much since it doesn't have that much of an effect. Most wikipedians probably don't even know it exists. I can assure you however that once you try to use it to choose articles worthy of listing on the main page for improvement, there will be a lot more attention and very likely some rather never ending and rather nasty arguments about what does and doesn't belong. We already see this to some extent in other areas of the main page, but they're naturally limiting since you need to fulfill other criteria and also have some degree of an established system Nil Einne (talk) 23:38, 13 September 2009 (UTC)
  • Oppose. There are only ~2,600 featured articles, but there are hundreds of thousands of articles needing cleanup. You'd have to either just pick ones at random, which would likely end up putting the occasional offensive or spam article on the Main Page and would routinely pick obscure subjects that few are interested in working on. Or, you'd do it manually and have an organizational nightmare trying to figure out which articles to list from a potential pool of hundreds of thousands. Additionally, things on the main page tend to be vandal magnets, so its questionable how much improvement would actually happen. Mr.Z-man 00:59, 14 September 2009 (UTC)
    • And yet Wikipedia:Article Collaboration and Improvement Drive seems to operate in practice, despite assertions that it is theoretically impossible. ☺ Uncle G (talk) 11:06, 21 September 2009 (UTC)
      • Not a good comparison. Its on an out-of-the way page, seen by a handful of editors per day. If its on the main page, where it will be seen by thousands of people per second, the decision of which article to put there will become a far bigger deal. Imagine if DYK had no restrictions on what articles could be nominated. Mr.Z-man 23:35, 3 October 2009 (UTC)
  • Oppose I imagine the implementation of this proposal would involve a board where editors would decide through discussion exactly which of our articles are in need of help, but not have problems so severe as to be unadvertisable. This would be adding a level of unneeded beauracracy, while the efforts would be better spent actually fixing the articles. ThemFromSpace 02:19, 14 September 2009 (UTC)
  • Oppose, we use DYK for the same sort of thing. Ironholds (talk) 13:42, 14 September 2009 (UTC)
  • My suggestion (also made elsewhere) is to have a "random article needing help" link in the navigation section. Would this be more feasible? Jackiespeel (talk) 13:01, 14 September 2009 (UTC)
    • Yes i like this suggestion. In my opinion those who have stated opposed seems to focus on only the negative possible aspects while not even considering the obviously good aspects of the suggestion. I still in in Support, they also seems to be oppose more because the last few has been oppose and just following the trend.--Judo112 (talk) 13:54, 14 September 2009 (UTC)
      • stated opposed seems to focus on only the negative possible aspects while not even considering the obviously good aspects of the suggestion - I could say the same about those who have supported, after all as I mentioned above you didn't even mention this would be going against the long standing practice of the main page being for readers and not editors and while it's possible to change consensus, it's usually wise to at least mention you are changing it. they also seems to be oppose more because the last few has been oppose and just following the trend - it doesn't sound like you are assuming good faith. I suspect the bigger reason why you got more opposes is as word spread (for example it was linked on Talk:Main Page) people who don't regularly check out VPP came to voice their views. Perhaps the 'conservative people' geometrygirl mentioned Nil Einne (talk) 07:41, 15 September 2009 (UTC)
    • How do you define "article needing help"? If every article that isn't a GA or FA "needs help," that's more than 99% of articles, there would be little difference between that and the normal Special:Random. Mr.Z-man 18:32, 14 September 2009 (UTC)
  • I like the general thrust of this, but I'm not so sure that the Main Page is the right place; flash mobs of brand new editors are hard to handle, and that's what you're mostly going to get by advertising like so on the front page, in my experience. Perhaps something in the village pump header? A watchlist notice? A template, something like WP:CENT? – Luna Santin (talk) 16:50, 14 September 2009 (UTC)
    • Well how do we handle the vandals today on the todays featured article for example.. blocking all non registered users whic is very effective and only takes a minute. So i dont truly see any kind of vandalism problem here. because then the todays featured article would b emutch more in the risk zone. For me still only the pain page is where this suggested feature could be placed. as it else would die out just as fast as it was a new feature on wikipedia. it is as simple as that.--Judo112 (talk) 16:07, 15 September 2009 (UTC)
      • Beg pardon? Articles linked from the Main Page are typically not semi-protected, given the importance of free editing to Wikipedia's culture. I didn't say "vandalism problem" -- yes, there will be one, but I find the maintenance issue to be of greater concern. Flash mobs of brand new users do not, as a rule, lead to quality. Far from "dying out", watchlist notices and centralized discussion have been an amazing success since their inception (attracting numerous experienced users to, among other things, this very discussion). Certainly I can see why you'd disagree with the suggestion, but dismissing it out of hand seems unwise. – Luna Santin (talk) 19:09, 18 September 2009 (UTC)
    • {{COTWCurrentPicks}} already exists, too. ☺ Uncle G (talk) 11:06, 21 September 2009 (UTC)

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! Ikip (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 editnotices to be used more widely, for example to notify of Arbcom restrictions. Currently editnotices only work for Groups based on a page and its subpages. Here's a way to do Flexible Groups: (a) an editnotice template; (b) a (protected) list of pages a particular editnotice template should be applied; (c) a bot which adds the relevant {{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)