Spanish Wikipedia that they have several links to several tools on a page's history page. You can click to get a list of editors, contribution details, search the history, get general statistics on an article, or check the number of visits to a page. Check out this page. The Herramientas are tools (list of editors, contribution details, and history search), the Estadísticas are statistics (general stats and number of visits). We should add this to our pages too. ~~Dr Dec(Talk)~~18:59, 14 September 2009 (UTC)
Strange, the box those are in doesn't even show up if your language is set to anything other than English... I wouldn't be opposed to using some of those links here. EVula// talk // ☯ //20:20, 14 September 2009 (UTC)
But it would be much better if they were integrated into MediaWiki (unlike the Spanish wiki). This would give a nice editing and monitoring framework for the WPedian. Eklipse (talk) 08:09, 16 September 2009 (UTC)
Their right at the top of every history page... *confused* Their also just as much "built in" here as they are on the Spanish Wikipedia, their just using plainlinks for external links (which I don't think is a good idea, since those links are actually outside the site, but that's just a style choice). The Spanish Wikipedia is using the exact same tools (their all on Wikimedia's toolserver), they just format the links differently is all. — V = I * R (talk to Ω) 15:11, 16 September 2009 (UTC)
I've just clicked the history tab for this page. There aren't any tools on that page; top or bottom! I know that the tools already exists, but we need to navigate onto another site, choose the tool, type in the page name. If it were integrated like it is on the Spanish Wiki then the info would be one click away. ~~Dr Dec(Talk)~~22:39, 16 September 2009 (UTC)
OK, I cleaned up the images and our discussion a little bit. As for the issue itself, I see that you're using Google Chrome and Vector. Are you using any custom CSS/Javascript? Do the tools show up if you use IE/FF or if you log out and look at a history page? Something in your config is obviously hiding that section. — V = I * R (talk to Ω) 15:05, 17 September 2009 (UTC)
Thanks for cleaning up the pictures. I am using Google Chrome and the Vector Skin along with Wikipedia Beta. I left Beta and changed my skin to monobook and there were still no tools. The same goes for Firefox. I've just logged out and the tools are there. I have a custom JS, but not a custom CSS. The custom JS is empty though. I did have something in there for an online/offline icon but I deleted that a while back. (See here). As for IE and FF, well, I don't know what you mean. ~~Dr Dec(Talk)~~ 15:21, 17 September 2009 (UTC) p.s. AH, I see: Internet Explorer and Firefox. Well the tools are there in every web browser; provided I log off and access Wikipedia as an IP address. ~~Dr Dec(Talk)~~15:25, 17 September 2009 (UTC)
well, I just looked at all of your subpages, and you're right... no custom CSS, and your custom javascript is empty. You could try actually deleting User:Declan Davis/monobook.js, but somehow I doubt that will help. The best idea I can come up with right now is to go into your preferences and start taking off Gadgets, and see if one of them is doing this too you. — V = I * R (talk to Ω) 16:21, 17 September 2009 (UTC)
I've asked a sys-op to delete my monobook.js – after they had deleted my vector.js - and still no difference. The only gadgets I use are Twinkle and Friendly. I turned them both off and still no joy. I have two interface gadgets: adding an edit link to the first section, and changing the UTC time to my local time. I took both of these off and still no joy. I really appreciate your help! If you don't know what else to do then could you formulate a question for the help desk? You seem to know what you're talking about better than I do. ~~Dr Dec(Talk)~~17:11, 17 September 2009 (UTC)
←I'm stumped, sorry. I'd think that the best thing to do for the Help Desk is to simply point here. A half decent summary would be something like: "toolserver links section on history pages disappeared while logged in", or something like that. Hopefull someone will come along who can help, though. — V = I * R (talk to Ω) 18:41, 17 September 2009 (UTC)
I've added a post to the help desk, and a post to the Village Pump's technical section. Let's hope someome comes along that knows the answer. Let me thank you all for your help... ~~Dr Dec(Talk)~~20:18, 17 September 2009 (UTC)
Community service?
What if Wikipedia granted community service time for its editors? Would this promote more editing? Would this promote more unconstructive editing? Would this be possible from a techincal standpoint? How would edits convert to 'time'? Dipotassitrimanganate (talk) 14:39, 17 September 2009 (UTC)?
We can't verify the time required to make an edit, there is no editor in chief who can legally certify the time, there is no proof which human being made an edit, so I don't think it is possible. MBisanztalk16:23, 17 September 2009 (UTC)
You just put images in my head of Chris Brown being forced to edit articles. I can see the Scouts in my Boy Scout troop asking if editing Wikipedia fulfills the community service requirement for advancement. ---— Gadget850 (Ed)talk19:27, 17 September 2009 (UTC)
My god, this is like saying doing homework for community service. Students write book reports and essays and use bibliographies and footnotes to reference them. Wikipedia is almost the same thing. How can you reward someone with community for doing like homework like editing? warrior432121:25, 17 September 2009 (UTC)
A proposed small but helpful design change
This suggestion is for the webmaster, I think. It's not a software bug, however, so I wasn't quite sure where to post it.
I would really appreciate it (and millions of other users, I believe) if you could have the Search field on the main page and subsequent pages configured so that the cursor is automatically active in the Search field when the pages open.
That way, you can start typing in your search term as soon as Wikipedia opens, instead of first having to use your mouse to click in the Search field to place the cursor there before you can type, and then switching back to the keyboard.
There's no other field in which to begin typing text anyway, so it's not like you are actually choosing among various text boxes in which to type. That's no reason to have to click to place / activate the cursor in the Search field each and every time you use Wikipedia.
Thanks very much for all the work you folks do. It's a huge service to people everywhere. —Preceding unsigned comment added by Skipjack MD (talk • contribs)
No, we will not use Javascript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See b1864. There is an accesskey property on it (default to accesskey="f" in English), and for logged in users there is a gadget available in your preferences. — V = I * R (talk to Ω) 22:45, 17 September 2009 (UTC)
Hello : This is refreshing as often websites jump to leading edge and you get all kinds of junk- I think pubmed for example went to a tabbed layout and sometimes the cute pix overlap the search box and it takes forever to render on some combinations of windoze os and browsers and it is impossoble anymore on most phones although they do have a text site. The saving grace there is that they have an eutils api facility but that doesn't help much on phones. I would go with the GEICO approach on this and continue to appeal to the primitive cavemen. encyclopedic information is often best conveyed with words and maybe limited pictures, adding extra stuff that may be fine for google earth would probably not add much here. Flash, PDF files, various equivalents ( don't want to pick on adobe as in some cases pdf is great ) would probably not help here and a fancy JS or other gui may produce much less consistent results. I'm not suggesting making a command line API for wiki although that may have some merit or restricting the navigation features but simplicity is nice. As it is, I have a hard time getting the main site to render on a cell phone( I think it leaves off the tabs on the blackberry). While you could have a separate page version for every device and OS it hardly seems helpful given the nature of the site. If anything, make it more primitive so same html runs on phone or desktop. For the particular feature requested by the user you could maybe provide a simple page that does this or just type the url into the address bar ( assumiing your search is an http get using the urlencoded query as some part of query string). Nerdseeksblonde (talk) 00:36, 18 September 2009 (UTC)
I believe you can set your preferences to do this by using the "Gadgets" tab and looking at the "User interface gadgets" section. ~ Amory (user • talk • contribs)01:35, 18 September 2009 (UTC)
Tooltips
I'm sorry that I missed any discussion, but I really don't appreciate the addition of tooltips to my watchlist and history pages. I know what the N, m, and b mean, and there's a key at the top. It is very annoying to have a line below each of them and a question mark and text box show up when I scroll over the letters. Can I please be able to at least disable the tooltips on these pages in my preferences? Thanks, Reywas92Talk02:30, 17 September 2009 (UTC)
I'm a JavaScript newbie (self-taught due to Wikipedia! :) ), so I'm still working on the exact code you'll need, but I figured out so far that you can use .removeAttribute('title') on the nodes of each of those letter's containers to remove the tooltips. The dotted line below is annoying as well, but CSS can accomplish that, so it's way easier. In the below CSS, I also remove the question mark cursor, which I don't mind but you seem to find annoying:
I hope that helps, and I'll comment again once I've got a complete script for you that will remove the tooltips. I don't guarantee that anything will work in IE, though, so be warned… {{Nihiltres|talk|edits}} 03:04, 17 September 2009 (UTC)
Eh, I just realized that those tooltips appear on every appearance of the minor edit tag, and that I don't quite know enough JavaScript yet to do a proper job of it quickly. Try asking on the technical village pump in the meantime and perhaps someone more familiar with certain JavaScript objects can come up with an implementation. {{Nihiltres|talk|edits}} 03:11, 17 September 2009 (UTC)
What does disabling the tooltip actually affect? You don't see them unless you hover over them. If you don't want to see the tooltip... just don't run your cursor over it. :) Removing the underlines, however... I actually just did that on mine. Bleh, looks ugly. EVula// talk // ☯ //03:40, 17 September 2009 (UTC)
Their annoying, and there's the "don't press that button!" effect. Once you know that tooltips are there, being told to just not look at them is no solution, it's just a lame excuse. Are these particular tooltips actually useful or helpful in any way? What problem do they solve? — V = I * R (talk to Ω) 16:24, 17 September 2009 (UTC)
Take a look at the help desk archives and check the number of times we have been asked what the numbers mean on the history. A legend should appear by default, but should be able to be disabled. ---— Gadget850 (Ed)talk19:30, 17 September 2009 (UTC)
That's all that's being asked for here, is a way to turn them off. I don't see anyone saying that those tooltips aren't useful at all, it's just that once someone sees these particular tips once it's not as though thay will forget. The whole things should be dismissible right there in the watchlist. This is basic interface usability design stuff we're talking about here, it's not as though these complaints are coming out of the blue. When some (very) established users are complaining it should be obvious that something is off kilter. The underlying idea (helping new users understand the interface) is fine, it's the implementation (using tooltips, and forcing that on everyone) that is problematic. — V = I * R (talk to Ω) 20:06, 17 September 2009 (UTC)
"all that's being asked for here, is a way to turn them off" And that was provided, in the form of the CSS code to add to your monobook.css file. EVula// talk // ☯ //20:15, 17 September 2009 (UTC)
How long have these tooltips been there, anyway? I just noticed the underlining this morning. Seems kind of redundant, there's a legend one line up... --KingÖomie20:26, 17 September 2009 (UTC)
No one one here has provided a way to remove the tooltips, just the underlining and the question mark cursor. There is a post at WP:VPT#Legend discussing removing the legend completely, but I am yet to see a solution to remove the tooltips, as I believe Ohm's Law is specifically trying to disable. —Ost (talk) 20:33, 17 September 2009 (UTC)
And I'm left wondering what the actual problem is. The fact that the tooltips even exist strikes me as an amazingly silly thing to be upset about. EVula// talk // ☯ //02:13, 18 September 2009 (UTC)
I too think that the underlines and the cursor question mark are extremely obtrusive and distracting. I think the title popups are a good compromise between annoying experienced users and helping newbies. I therefore propose to turn off the cursor and underline effect by default but to keep the title. Cacycle (talk) 01:31, 19 September 2009 (UTC)
I find them distracting as well, and redundant. Watchlists are very "busy"-looking pages already. Another minor point: watchlists are HTML-heavy enough, and adding dozens or hundreds of title="This edit was performed by a bot" attributes (the title is repeated at every occurrence of the mark; it's not like a reused variable) makes the page size that much larger. I have at least 200 of these on my watchlist (it's a long watchlist); that's some 8kb of added size, and Firefox says the document size is 139kb, so that's something like a 6% increase in page size. Outriggr (talk) 01:52, 19 September 2009 (UTC)
Idea
Has anyone thought of a possible group that would keep users out of the recent changes list? I know that there are many editors who are squeaky clean in their contributions, and the whole autoreviewer group is there, but why not have a whole autochange group? Kevin Rutherford (talk) 23:14, 19 July 2009 (UTC)
Chilling. Additionally, the recent changes list serves as a reader resource showing what's happening at any given time in terms of content contribution to en-wiki; restricting it would negate its utility. –Whitehorse102:41, 16 September 2009 (UTC)
In general, I'd oppose. All edits should be up for scrutiny by RC patrollers, else the potential for misuse is too great. ƒ(Δ)²17:19, 19 September 2009 (UTC)
What is the hCard/vCard supposed to accomplish in a biography? And why should we make private information (phone numbers/email addresses etc) public? Wouldn't such information also fail WP:INDISCRIMINATE and WP:NOTDIR? And what method is proposed to ensure that the information doesn't go stale (which would happen quickly when artists realize that their private information is now public)? And how do we prevent abuse? (Think: want to terrorize your ex? Post her number in a public toilet)
All in all, this hCard stuff sounds like a really bad idea in an encyclopedia. We already provide a facility to link to artist's website, and that should suffice (and that is where a reader should go for contact info). -- Fullstop (talk) 13:48, 18 September 2009 (UTC)
@Fullstop: You appear to be under some misapprehensions; allow me to reassure you.
No vCards will be involved.
The hCard microformat adds semantic meaning to text data, by wrapping it in meaningful HTML class names.
No addresses or telephone numbers will be published. The hCard mark-up will be used solely to give semantic meaning to names.
In this case, specifically, they will specify that the text is either the name of a person, or a group.
The relevant existing HTML markup is <table><th>; this change will add two class names, to make that either: <table class="vcard"><th class="fn"> or <table class="vcard"><th class="fn org">. Nothing else will change.
Wikipedia already emits hundreds of thousands, probably well over a million, microformats.
Microformats are emitted by some of our most-used templates, including {{Coord}}, {{Infobox settlement}}, {{Infobox person}}, and the templates based on them.
hCards in particular are already emitted by most infobox templates, about people, places and organisations.
Partner organisations such as Google parse our microformats; our use of them has been praised by Yahoo.
A navbox is unlikely to include "information" as an infobox does. The purpose of a navbox is to provide links to related topics, I think adding microformats to navboxes is not really helpful to add semantic data. Locosepraix ~ Beastepraix19:11, 18 September 2009 (UTC)
Can you provide an example of an instance of this navbox which does not contain any information (bearing in mind that the name of an artist or band is a piece of information; and that a name is the only mandatory property for an hCard microformat)? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits19:27, 18 September 2009 (UTC)
No progress is being made with revision pruning meanwhile I'm getting tired of wading through pages of bot edits when studying an articles revision history. At least couldn't SmackBot's date maintenance tagging just be integrated as a feature into the MediaWiki software to do this automatically? What I mean is, any time someone adds a maintenance tag, the MediaWiki software can recognize this and automatically append "|date=CURRENTDATE" to the tag after the page is saved without it being logged in the revision history. Does this sound feasible? -- Ϫ16:31, 18 September 2009 (UTC)
No only no, but hell no! It's not that I don't agree with the underlying reasoning, but the problem is that doing something like that would create a horrendous software dependency. The effect of this suggestion would be that the type of templates that SmackBot, AWB, and other tools fix would be required, undeletable, unmovable, and even worse that the content of those templates would be unadjustable (the date parameter couldn't be removed or changed in any way).
Actually, I don't think that the underlying reasoning is that much of an issue either... although, it is. It depends on the article, really. I suggested a vandalism flag and the ability to modify the minor edit flag on revisions about a month ago. That sort of change would be the best solution to reducing the signal to noise ratio in revision histories, in my opinion. — V = I * R (talk to Ω) 19:16, 18 September 2009 (UTC)
Hmm ya, the thought just popped up.. I wasn't aware of the technicalities involved. oh well.
There is this things called configuration, this does not have to be hardcoded, it actually could be configured, with a list of all templates that should be checked and the name of the parameter that should be added per template. So that is not an argument. Actually interesting idea, a scripting interface in the code that can do a edit when it detects a pattern (regexp), so basically an addition to the current FILTERs, when filter is triggered, do action on page. Should be very possible to do, but the action now will have much higher impact, so might be questionable from that point. --Stefantalk02:12, 20 September 2009 (UTC)
Those are mostly interwiki bots, why are you singling out poor Smackbot? Wasn't there some discussion a while back about optimizing and centralizing the way we do interwikis? –xenotalk19:22, 18 September 2009 (UTC)
That was just one idea of how to reduce bot edit clutter.. I just decided to use that link as an example to emphasize the problem.. I think SmackBot's doing a wonderful job. :) I don't recall any discussion about optimizing interwikis..
Hey, hang on a second... isn't there a way to mask minor and bot edits on page histories? You can on watchlists, I don't see those links in the page history linked to above. — V = I * R (talk to Ω) 19:34, 18 September 2009 (UTC)
Ya, that's the problem.. you can't hide bot edits in revision history.. i think it's because of T13181.. apparently edits are only marked as 'bot edits' for 30 days. -- Ϫ02:17, 19 September 2009 (UTC)
Timelines
Seem like they would be good to use here and there and can be very effective. I think they are included in many encyclopedias if I'm not mistaken. Avoiding original research as far as what to include might be an issue. Have people used them? Are they best separated from articles? Integrated as image like illustrations? Used in section form? Comments, insights, thoughts, vitriol, welcome. Thanks. ChildofMidnight (talk) 00:15, 28 February 2009 (UTC)
Can a "cite youtube" template be created, or would it be considered unnecessary? A number of networks such as Fox Business now have a youtube channel with videos, and the {{cite video}} doesn't seem well suited for citing videos on youtube.Smallman12q (talk) 17:00, 19 September 2009 (UTC)
Aside from the fact that quite a large proportion of stuff on Youtube is a copyvio and shouldn't be cited anyway, the existing templates seem fine. Stifle (talk) 15:28, 20 September 2009 (UTC)
That's not inherently true, though (the copyvio comment). There are plenty of legitimate, professional sources who are utilizing YouTube now. YouTube is simply a platform, after all. — V = I * R (talk to Ω) 16:50, 20 September 2009 (UTC)
While there are some valid reasons to cite youtube videos occasionally, a "cite youtube" template wouldn't really help much, as youtube is only the host, not the author or the publisher. I guess you could save a little space by just having it use the video ID instead of the full URL, but that's about it. Mr.Z-man17:07, 20 September 2009 (UTC)
Fact checking is one of those jobs that many people are not good at. Articles for Fact Check could be a way for editors dedicated to accuracy fact-check under-sourced articles. An article would be nominated, an editor would fact check and report back their findings. Note that something similar may exist, but I can't find it. Gosox5555 (talk) 20:16, 19 September 2009 (UTC)
Every article could always use fact checking. That's the one of the inherent problems with a site that anyone can edit. The person doing the fact-checking likely has no formal training and has no obligation to do a thorough job. Even if we ignore that, the "fact-checked" status of an article is only good until someone makes another substantial edit to it. Mr.Z-man21:49, 19 September 2009 (UTC)
What do you mean by fact checking? If all the facts are true? Let me tell you, every article that isn't FA and possibly GA will have some original research or need "fact checking". More than 3,000,000 articles require "fact checking". hIf an editor wanted to this, fact checking, he/she could press the Random Article in the sidebar on the left, and check the facts for that article. warrior432113:07, 20 September 2009 (UTC)
I wouldn't be giving FA or GA articles a pass in the fact checking department. The simple fact is (pun intended), Wikipedia articles are not, and almost by definition cannot be, reliable. Fact checking is an inherent aspect of simply reading an article. If you're relying on a Wikipedia article for anything, then you need to check that the references actually support what they reference. It's just the nature of how Wikipedia operates. — V = I * R (talk to Ω) 16:47, 20 September 2009 (UTC)
Disambiguation
I am an academic and understand the need for formal technical terms. I also understand that the word “disambiguation” has some history in linguistics as a technical term for clearing up ambiguities between similar or identical words. I also understand the need for Wikipedia to follow high standards in presentation and procedure. There is, however, another view. Wikipedia is a kind of “peoples” encyclopaedia and should not use complex terms when adequate and perfectly clear substitutes are available that can be immediately understood by all users - including those that are young or less educated than those familiar with the word “disambiguation”. I am saying it is not a very “user-friendly” word and suggest it be replaced with something like one of the following. “Clarification”, “Different senses” “Different meanings for this entry”. I’m sure there must be a simple word or phrase which does the same job and I would be happy with any of these suggestions. A global replace would then be a relatively simple matter. Granitethighs (talk) 23:44, 8 September 2009 (UTC)
I'm very much not an academic, and my reaction to this is... huh? Sure, "disambiguation" isn't a common word, but it's meaning is immediately clear when it's first encountered. — V = I * R (talk to Ω) 23:57, 8 September 2009 (UTC)
And I would agree with that. However, in this case you're saying "Why say "obfuscation" when you can say... something else. What would be simpler? Do you have any suggestions?" Hey, I'm all for simpler myself, and in most cases I'd likely be on your side. This though... what else would you call a page with makes an ambiguous title not ambiguous? This is what we used to call "Nuking it"; over thinking and over analyzing a common task, process, procedure, etc.. (in this case a word) until it turns into a problem. — V = I * R (talk to Ω) 00:36, 9 September 2009 (UTC)
To be a pedantic academic for a moment - I think the use of the word "ambiguous" and hence "disambiguate" here is not the most appropriate word anyway. It is a subtle point but it seems to me that the the words themselves are not ambiguous, they just have different meanings ... the same words with different senses. I suppose what is "ambigious" relates to the particular meaning the enquirer is seeking. Anyway, I gave my suggestions. What is wrong with "Different senses" or “Different meanings for this entry”? If they are regarded as unnecessarily long then "Clarification" would do the trick. Do you have children? If they were using Wikipedia do you think "disambiguation" is the way to point out that the same word or phrase can have different meanings? Granitethighs (talk) 01:16, 9 September 2009 (UTC)
Actually, I remember my first few days on Wikipedia. The first time I saw a disambiguation page, I did not know what was meant by a disambiguation page, until I actually went to more than one disambiguation page. This showed me, that a disambiguation page was merely a index to other pages. It can be confusing to all, and we've all gotten past it smoothly, others will too. It's all part of the learning process, we call life. warrior432104:04, 9 September 2009 (UTC)
This is like saying "why SMS CU4T when we all understand that it means "See you for tea" - - - learning English is part of the language learning process in life that we must all undergo so just put up with it and write "See you for tea". The point is that it is simpler, easier, and therefore more efficient and appealing to say CU4T (or "Clarification"). Granitethighs04:15, 9 September 2009 (UTC)
I think I'd encountered the word disambiguation before I went on Wikipedia or else apprehended its meaning from etymology once I had. But that didn't tell me what it was; it just looked like more of that forest of incomprehensible technical jargon best avoided when possible. And knowing an ordinary English meaning of a word can sometimes be positively misleading, as I found out when I learned that "deprecation" didn't just mean what it had meant to me for the previous three or four decades, "deplore" or "disparage". Something like "alternative meanings" or "alternate uses" would be much clearer. And editors should forbear from "dab" as an abbreviation for diambiguation; it's certainly not intuitive. —— Shakescene (talk) 04:55, 9 September 2009 (UTC)
Granitethighs is right, and the existence of Simple English Wikipedia is not a reason to make this one inaccessible. However, I'm not sure about the suggested alternatives. --Apoc2400 (talk) 09:44, 9 September 2009 (UTC)
What I was saying is that they don't even see using the word as a problem there, and that's a simplified version of this Wikipedia. I think most young readers can establish what the word means based on its roots, or at least relate it to ambiguity or ambiguous, and gather the meaning from that with the addition of the prefix. hmwith☮13:52, 9 September 2009 (UTC)
The moment you can find a single word which expresses what we mean to express with "disambiguation" I'll support changing the name. Protonk (talk) 02:41, 14 September 2009 (UTC)
Hello! I just thought that maybe a fun section of the project could be for unanswered questions we have concerning topics. For example, we post a question on something we want an answer to as a means of seeing if we have an article on it and if not if we can have an article and then go and write one. Granted many of us just do that anyway (that is how a few articles I created were established), but maybe have a general area for it where we can help each other out and it may be a good way to come up with likely redirect search strings for topics, no? To see what I mean, I am curious on the following:
My father claims that a guy came up with some kind of shatter proof window for skyscrapers and tested it himself, only to fall through the window to his death. True or urban legend? Do we have an article on this man and his windows if true? Or is the rumor notable enough to justify an urban legend page on it?
I saw on the news a few minutes ago, something about some fetus looking bizarre creature that washed up on shore and reportedly went for children. Is it merely a newsstory and on Wikinews, or something worthy of current events on Wikipedia?
There's a little bit of this going on, mostly for vandalism protection. Whenever Colbert mentions Wikipedia, the topic he's talking about tends to be semi-protected, etc etc. From what I understand, stories like the crazy fetus-fish-monster are Wikinews fodder, as it's unlikely to maintain the lasting notability required for Wikipedia inclusion (since it's almost definitely a hoax, like that beaked monster on the beach a few months back). --KingÖomie14:39, 21 September 2009 (UTC)
Who speaks for you and Wikimedia projects at public events?
On February 7, 2007, a list of people who are willing to speak publicly--to schools, organizations, etc.--about the goals, progress and aspects of Wikimedia projects was created over on Meta at Meta:Public speakers. For those of you unfamiliar with Meta, it exists to coordinate the inter-project activities and discussion of broad Wikimedia initiatives and goals. Suddenly, the list of Meta:Public speakers became controversial after Angela Beesley[3] and Jimmy Wales[4] were removed by a Wikimedia critic for being 'inactive', and then began adding critics of our entire project as public speakers on behalf of Wikimedia. Think having Dick Cheney speak on behalf of the goals and good work of Amnesty International. Surprisingly, for the sake of "openness", it is being argued that people looking for folks in local communities to come talk about what we do, and why, might instead stumble across anyone who is willing to air their grievances and accolades about Wikimedia. The debate has just begun, and more people who are interested in who is out there speaking about the work they do here on Wikipedia should take part Meta:Talk:Public speakers. -->David Shankbone13:22, 21 September 2009 (UTC)
Disambiguation
I am an academic and understand the need for formal technical terms. I also understand that the word “disambiguation” has some history in linguistics as a technical term for clearing up ambiguities between similar or identical words. I also understand the need for Wikipedia to follow high standards in presentation and procedure. There is, however, another view. Wikipedia is a kind of “peoples” encyclopaedia and should not use complex terms when adequate and perfectly clear substitutes are available that can be immediately understood by all users - including those that are young or less educated than those familiar with the word “disambiguation”. I am saying it is not a very “user-friendly” word and suggest it be replaced with something like one of the following. “Clarification”, “Different senses” “Different meanings for this entry”. I’m sure there must be a simple word or phrase which does the same job and I would be happy with any of these suggestions. A global replace would then be a relatively simple matter. Granitethighs (talk) 23:44, 8 September 2009 (UTC)
I'm very much not an academic, and my reaction to this is... huh? Sure, "disambiguation" isn't a common word, but it's meaning is immediately clear when it's first encountered. — V = I * R (talk to Ω) 23:57, 8 September 2009 (UTC)
And I would agree with that. However, in this case you're saying "Why say "obfuscation" when you can say... something else. What would be simpler? Do you have any suggestions?" Hey, I'm all for simpler myself, and in most cases I'd likely be on your side. This though... what else would you call a page with makes an ambiguous title not ambiguous? This is what we used to call "Nuking it"; over thinking and over analyzing a common task, process, procedure, etc.. (in this case a word) until it turns into a problem. — V = I * R (talk to Ω) 00:36, 9 September 2009 (UTC)
To be a pedantic academic for a moment - I think the use of the word "ambiguous" and hence "disambiguate" here is not the most appropriate word anyway. It is a subtle point but it seems to me that the the words themselves are not ambiguous, they just have different meanings ... the same words with different senses. I suppose what is "ambigious" relates to the particular meaning the enquirer is seeking. Anyway, I gave my suggestions. What is wrong with "Different senses" or “Different meanings for this entry”? If they are regarded as unnecessarily long then "Clarification" would do the trick. Do you have children? If they were using Wikipedia do you think "disambiguation" is the way to point out that the same word or phrase can have different meanings? Granitethighs (talk) 01:16, 9 September 2009 (UTC)
Actually, I remember my first few days on Wikipedia. The first time I saw a disambiguation page, I did not know what was meant by a disambiguation page, until I actually went to more than one disambiguation page. This showed me, that a disambiguation page was merely a index to other pages. It can be confusing to all, and we've all gotten past it smoothly, others will too. It's all part of the learning process, we call life. warrior432104:04, 9 September 2009 (UTC)
This is like saying "why SMS CU4T when we all understand that it means "See you for tea" - - - learning English is part of the language learning process in life that we must all undergo so just put up with it and write "See you for tea". The point is that it is simpler, easier, and therefore more efficient and appealing to say CU4T (or "Clarification"). Granitethighs04:15, 9 September 2009 (UTC)
I think I'd encountered the word disambiguation before I went on Wikipedia or else apprehended its meaning from etymology once I had. But that didn't tell me what it was; it just looked like more of that forest of incomprehensible technical jargon best avoided when possible. And knowing an ordinary English meaning of a word can sometimes be positively misleading, as I found out when I learned that "deprecation" didn't just mean what it had meant to me for the previous three or four decades, "deplore" or "disparage". Something like "alternative meanings" or "alternate uses" would be much clearer. And editors should forbear from "dab" as an abbreviation for diambiguation; it's certainly not intuitive. —— Shakescene (talk) 04:55, 9 September 2009 (UTC)
Granitethighs is right, and the existence of Simple English Wikipedia is not a reason to make this one inaccessible. However, I'm not sure about the suggested alternatives. --Apoc2400 (talk) 09:44, 9 September 2009 (UTC)
What I was saying is that they don't even see using the word as a problem there, and that's a simplified version of this Wikipedia. I think most young readers can establish what the word means based on its roots, or at least relate it to ambiguity or ambiguous, and gather the meaning from that with the addition of the prefix. hmwith☮13:52, 9 September 2009 (UTC)
The moment you can find a single word which expresses what we mean to express with "disambiguation" I'll support changing the name. Protonk (talk) 02:41, 14 September 2009 (UTC)
Hello! I just thought that maybe a fun section of the project could be for unanswered questions we have concerning topics. For example, we post a question on something we want an answer to as a means of seeing if we have an article on it and if not if we can have an article and then go and write one. Granted many of us just do that anyway (that is how a few articles I created were established), but maybe have a general area for it where we can help each other out and it may be a good way to come up with likely redirect search strings for topics, no? To see what I mean, I am curious on the following:
My father claims that a guy came up with some kind of shatter proof window for skyscrapers and tested it himself, only to fall through the window to his death. True or urban legend? Do we have an article on this man and his windows if true? Or is the rumor notable enough to justify an urban legend page on it?
I saw on the news a few minutes ago, something about some fetus looking bizarre creature that washed up on shore and reportedly went for children. Is it merely a newsstory and on Wikinews, or something worthy of current events on Wikipedia?
There's a little bit of this going on, mostly for vandalism protection. Whenever Colbert mentions Wikipedia, the topic he's talking about tends to be semi-protected, etc etc. From what I understand, stories like the crazy fetus-fish-monster are Wikinews fodder, as it's unlikely to maintain the lasting notability required for Wikipedia inclusion (since it's almost definitely a hoax, like that beaked monster on the beach a few months back). --KingÖomie14:39, 21 September 2009 (UTC)
Who speaks for you and Wikimedia projects at public events?
On February 7, 2007, a list of people who are willing to speak publicly--to schools, organizations, etc.--about the goals, progress and aspects of Wikimedia projects was created over on Meta at Meta:Public speakers. For those of you unfamiliar with Meta, it exists to coordinate the inter-project activities and discussion of broad Wikimedia initiatives and goals. Suddenly, the list of Meta:Public speakers became controversial after Angela Beesley[5] and Jimmy Wales[6] were removed by a Wikimedia critic for being 'inactive', and then began adding critics of our entire project as public speakers on behalf of Wikimedia. Think having Dick Cheney speak on behalf of the goals and good work of Amnesty International. Surprisingly, for the sake of "openness", it is being argued that people looking for folks in local communities to come talk about what we do, and why, might instead stumble across anyone who is willing to air their grievances and accolades about Wikimedia. The debate has just begun, and more people who are interested in who is out there speaking about the work they do here on Wikipedia should take part Meta:Talk:Public speakers. -->David Shankbone13:22, 21 September 2009 (UTC)
Interesting idea, but how would that be different from a featured portal? I see portals as the reflection of work carried out by a Wikiproject, although others might disagree with me. Clarify, please? Thanks! Hardtofindaname07:17, 15 September 2009 (UTC)
I think that the first step would be to start a conversation with User talk:Schutz, who operates Zorglbot. I'm fairly certain that he could add a task to either fix links or move all of the sub-pages. There are a lot of them, but their isn't an infinite number, so this is a perfect bot task (I'd gladly run it on my own bot if it was ready to go). User:JPG-GR seems to be someone who should be brought into these discussions, as well. — V = I * R (talk to Ω) 17:47, 16 September 2009 (UTC)
There's also the issue Andy brought up about the multitude of bots that patrol that page. An infrastructure has built around that and AFD over the last five years; moving the foundation is going to be a haul. --KingÖomie17:49, 16 September 2009 (UTC)
A redirect should take care of the immediate problem for most bots and users (and any bot that is hard-coded with the page name ought to break regardless). — V = I * R (talk to Ω) 17:53, 16 September 2009 (UTC)
Well, I just meant that the operators should be found and notified that they need to update their bots, or at least prepare them for the eventuality. A page move might rename TFD itself, but individual posts will still retain the 'Deletion' name, and any new posts created through Twinkle (and similar tools) will as well. I'd still recommend a wholesale move of every page (obviously through a bot). There's probably 4,000 pages. --KingÖomie18:04, 16 September 2009 (UTC)
I feel we should add links of websites that we come across during everyday net surfing. I feel that Metallurgy field is most devoid of links to websites, but actually most of the educational articles on wikipedia have an extremely small number of links. So i think that we should add a link to a relevant wikipedia article whenever we come across a nice website, during our everyday net surfing.
The real problem is almost always too many links. 0 sounds a good number, 6 is too many (and I think that most/all relevant external links can be added into articles). Dougweller (talk) 16:43, 18 September 2009 (UTC)
I did say "ideally". Achieving an ideal is rarely, if ever, practical. The vast majority of EL's in Wikipedia are completely superfluous, is the real point, and 0 external links is not at all a "horrible" ideal. Of course, naming an actual upper limit is bad as well, but that's a different subject. — V = I * R (talk to Ω) 18:36, 18 September 2009 (UTC)
I think there will always be things that are outside Wikipedia's scope, but still educational to link to. There are a lot of great science websites out there. I wish we could link to them when relevant without allowing lots of crap links in. --Apoc2400 (talk) 18:56, 18 September 2009 (UTC)
I support your view Apoc because if you really look at technological and scientific articles, then you will find that almost all of them especially, the technological articles suffer from Content Drought too. So if no one has enough time to put enough work in them as technological articles in my opinion require a lot of hard work and lot of reading to make an article knowledgable and yet lucid, so no one has found the time to enrich the wikipedia articles, but i feel that most people do find many useful and knowlegde giving fantastic websites. It is true that most portions of these websites can be junk or useless but some portions of them is really fantastic. For example the Bayer Science Website doesnt looks very useful to me for reading about technological things (at least its not very easy to find good stuff there) but i found a very lucid explanation of figures depicting Engineering Draft and i used that link for the Engineering Draft stub at [7],So my point is that when no one has enough time to write good technological articles in wikipedia, so cant we just add links to the stubs, so that someone can get all the vital information about a topic through wikipedia itself even if it is actually not on wikipedia. Afterall wikipedia's goal is to bring knowledge to a person and not to exert its supermacy and thus not providing any external links even if its articles are not good at all on tht topic. cheers!
Cumbersomeness of having too many links attatched to a stub or even "full fledged featured article" can be avoided by attatching suitable taglines to the links. this is easy and makes the reader decide what links to click onto.
Please people, dont just take into account some few special cases. Think about the whole bunch of technological articles and scientific articles too. Because whenever i have learnt something worthwhile from a wikipedia article, it was mostly when i read the wikipedia article and also followed some of the nice links provided in those articles. It was a very satisfying experience. cheers!— Preceding unsigned comment added by 210.212.55.3 (talk) 06:29, September 18, 2009 (UTC)
Uh, isn't that what we are encouraged to do now? Yes, Wikipedia is not a directory to the Internet, but if I find a link to a resource worth adding to Wikipedia & don't have the time to properly digest & integrate it into an article, I'll add it at the bottom as an "External link" or "Further reading". I know I'm not the only one who does this. (The problem is when someone indiscriminately adds links to articles of website which are not helpful; in those cases, the links are pruned by folks who are disappointed at this abuse -- like me.) -- llywrch (talk) 22:14, 21 September 2009 (UTC)
actually the aim here is to somehow spread the word through word of mouth to those people who create or enrich technological articles that since technological information is sometimes hard to digest for adding it to an existing wikipedia article, so they can conveniently leave suitable links in that article so that a reader can still have access to knowledge. cheers!— Preceding unsigned comment added by 210.212.55.3 (talk) 03:58, September 24, 2009 (UTC)
Creating micro-opportunities: a new colour for stub wikilinks
NOTE: I don't really have the will to pursue this proposal (although I think it would be a positive feature for Wikipedia). Anyone is welcome to take up this proposal if they feel they can make something useful of it. GeometryGirl (talk) 23:55, 16 September 2009 (UTC)
Description
What?
Wikipedia currently uses two colours for links, namely blue for existent articles and red for nonexistent articles. This proposal suggests using yet a different colour for stubs. The goal is to engage readers in article contribution, specifically stub expansion.
Why?
Micro-opportunities for user participation currently exist, such as red links, that stimulate article creation. However, red links have become rare and the focus is nowadays on expansion and improvement, rather than creation. With most links blue, an impression of completion transpires, and not much enticement to participate is provided. This proposal attempts to address both the deceptive appearances and the lack of enticement.
Why stubs?
Because stub pages not are appropriate for an encyclopedia: "A stub is an article that is too short to contain suitably encyclopedic material". Also, in many ways, stubs are much easier to improve than developed articles.
Non logged-in readers will not be affected, to avoid confusion. This will be an opt-in option (i.e. not enabled by default) for registered users, advertised via a sitenotice or a watchlist notice.
Which colour?
The choice of colour will be left to the discretion of each user, according to preference and sight (e.g. colourblindness).
Which Wikipedia?
This proposal is first intended to the English Wikipedia, but other Wikipedias may be interested in a similar functionality.
"I have a script like the ones mentioned above for some time and find it very helpful. Anything that encourage a growth in quality is good in my book."
"Having coded my own version of this into my monobook theme, I have noticed how much of an effect the orange links have on me. They immediately stand out above things and they make me want them to be blue."
Potential problems
Stub articles are not necessarily articles that people want to edit.
The extra colour merely suggests stub editing, like red links suggest article creation.
This proposal assumes that stubs are Wikipedia's worst articles.
The extra colour focuses on undeveloped articles, no assumption of quality is made.
This adds complexity to the linking system and will cause confusion.
Only logged-in users will be affected to limit confusion, and registered users can decide not to use an extra colour.
Some undeveloped articles have no rating.
Links to these articles we be blue until appropriate rating is done.
There are potential performance problems.
No programmer has expressed his/her concern as of yet.
A different colour for stubs might prove obnoxious for some readers.
Each registered user will decide if he/she wishes a new colour for stubs.
The colourblind may not distinguish the different colours.
Each registered user will be able to decide the colour he/she wishes to use.
I admire your dedication, but I'm still not convinced that the basic underlying idea is a good thing here. What exactly is a stub article? Those articles that are less then X bytes? Articles with a {{stub}} templates on them? Without addressing the fundamental question of how to unambiguously determine the state of all articles I'm unwilling to support any of these proposals. I personally am ready and willing to discuss the addition of some sort of added "quality field", "assessment property", or some other such thing to articles, but unless and until that it implemented all of these proposals are premature. — V = I * R (talk to Ω) 12:43, 9 September 2009 (UTC)
I tried to in the first proposal, but the bulk of that seems to have been overlooked. Before any of these can be implemented, something needs to be added to the software itself so that internal links can be given CSS classes based on article quality. Using the category system is a bad idea for two reasons:
Categories are not required to be used on articles at all, which is important because we're talking about replying on some property to determine how pages are rendered. If there isn't a specific property for the software to rely on, then these proposals are pretty much dead in the water from a programming perspective.
Categories are not intended to be used in this matter. They currently are, but that could be changed at any time, and then where would that leave this system (assuming that it was somehow implemented)? Assessments can currently utilize the category system because nothing in software is currently reliant on article assessment, but if that changed then something would specifically need to be done to prevent the categories from ever changing.
Stubness suffers from the exact same issues here. This doesn't even address the concerns with the current quality assessment systems in use here on the English Wikipedia, which I think are fairly significant. The fact is that some significant groundwork is required before even considering these specific proposals. — V = I * R (talk to Ω) 13:20, 9 September 2009 (UTC)
For who: "All readers by default." Why on earth? People have heard tales of Wikipedia's upcoming "orange text" system, adding orange links at this time would confuse readers to an INCREDIBLE degree. Leave it as a gadget, if anything (I'd certainly use it), or even a custom userscript. --KingÖomie12:48, 9 September 2009 (UTC)
I haven't heard of "tales of Wikipedia's upcoming "orange text" system". And saying that "orange links at this time would confuse readers to an INCREDIBLE degree" is highly speculative. GeometryGirl (talk) 12:58, 9 September 2009 (UTC)
I'm not making the error. I'm saying rolling out orange links after a slew of news about orange text will confuse others. --KingÖomie14:01, 9 September 2009 (UTC)
Oh, I get it... well, even if this were to suddenly gain tons of traction and everyone was onboard with implementing it, it would likely be months before an actual implementation went live on Wikipedia. By then I doubt that confusion with Wikitrust would be an issue. Or... it could still be an issue, I suppose. Regardless, the actual color used would be the last thing to consider, so specifically using orange is just a minor detail. — V = I * R (talk to Ω) 14:05, 9 September 2009 (UTC)
I think this is a marvelous idea and wholheartedly support it. I have a script like the ones mentioned above for some time and find it very helpful. Anything that encourage a growth in quality is good in my book. —Charles Edward(Talk | Contribs)16:10, 9 September 2009 (UTC)
Thank you for your support Charles Edward. Since you have experienced using such a script, can you give us feedback as to what are the advantages, and what are the possible drawbacks? GeometryGirl (talk) 16:35, 9 September 2009 (UTC)
Discussion settled: By default or not by default?
There is some utility to this suggestion (I currently am trying it out through a little CSS hack and a preferences change). It certainly is interesting to those who have an interest in developing stubs. That said, I don't think the color change is useful enough to the general population to enable this as for all readers by default. Perhaps as a gadget, this would be nice. Shereth17:41, 9 September 2009 (UTC)
There isn't much to add, really. There are some editors who enjoy expanding stubs, and to offer this as an option to these editors makes sense (ideally with the option to pick a color of their choosing). However, to those editors who are not generally interested in expanding stubs, the addition of another color of links could prove obnoxious. This is not something that should be enabled by default, but rather an option for interested editors. Shereth21:17, 10 September 2009 (UTC)
I understand your concerns Shereth. May I point out however that red links have been successful precisely because they where obnoxious/annoying. Editors will want to "change links to blue". GeometryGirl (talk) 21:39, 10 September 2009 (UTC)
Some undoubtedly will; some undoubtedly will just be frustrated at multiple colors. Red links also serve to let people know that a link does not exist and that clicking on it would not result in seeing any information. Leaving links to non-existent articles undifferentiated would be disingenuous. Blue implies something exists, red implies it does not, and this is a wholly objective difference. The addition of any other colored links will result in necessarily subjective and/or arbitrary differences. Like I've said, this is a useful suggestion for those interested but it should be optional, not standard behavior. Shereth21:44, 10 September 2009 (UTC)
If we make it a gadget then I fear this would not at all have the same impact. There is an interesting question raised here: Are the potentially massive benefits of this proposal more, or less, important than the potential frustration for some? I don't have an answer... GeometryGirl (talk) 21:51, 10 September 2009 (UTC)
I believe you are overstating the "potentially massive benefits" of this proposal. I also believe that intentionally "annoying" users as a means to an end is a wrongheaded approach to a problem. However as these are inherently subjective questions and points, and there is no objective "right or wrong" answer, it appears we are going to just have to agree to disagree, as it is apparent we have different views on the matter and we don't seem to be swaying one another. So I'll just reiterate my stance and leave the community to further discuss this issue : I think this is a fine idea for a gadget but should not be enabled by default. Shereth21:57, 10 September 2009 (UTC)
Exactly, may the community decide. But what about an option for frustrated editors to disable the new colour? That would solve the problem, no? GeometryGirl (talk) 22:03, 10 September 2009 (UTC)
What about this: If and when this is implemented, for every account have a message basically saying "Coloured links for stubs is new. Do you want to enable them? YES PLEASE/NO THANK YOU". GeometryGirl (talk) 22:14, 10 September 2009 (UTC)
I support this. It encourages participation, which wikipedia certainly could use more of. I don't think orange is the right colour, but that is a later issue. Having coded my own version of this into my monobook theme, I have noticed how much of an effect the orange links have on me. They immediately stand out above things and they make me want them to be blue. I think this is useful for all signed up editors, but not for visitors, who may be unaware of the system in place. - ʄɭoʏɗiaɲτ¢18:23, 10 September 2009 (UTC)
That's great. I agree with you that orange is not the best colour and that this should probably only be for signed up editors to avoid too much confusion. What do you think of purple? I can't find any appropriate colour at HTML color names. It is a shame that green gives out the wrong impression. GeometryGirl (talk) 20:02, 10 September 2009 (UTC)
That purple is too similar to links you've already clicked on in many browsers, but another may work. I'd suggest a vibrant shade of blue (Perhaps an electric blue), or a mix between blue and green (Perhaps turquoise) that wouldn't cause a color-blind issues (Though in all reality, any color is going to be hard to see by a certain small percentage of the population who can't distinguish colours well). Another option could be bolding the text. I like the orange the best myself, but I just think it may cause confusion with others. - ʄɭoʏɗiaɲτ¢21:19, 10 September 2009 (UTC)
Comment As I have my own css preferred link colours set, I am not sure how this would work for me. Would it interfere, against my will, with my colour preferences? (I haven't read all the stuff in the box above - too detailed and strenuous a read.) Can't anyone who wants to expand stubs just look under the thousands of stubs? Plus, the designation "stub" variies from full articles to one sentence pages. Xme (talk) 00:07, 11 September 2009 (UTC)
This is not a default option, just an opt-in option for interested users. Users who already have a preferred link colours set will not need such a feature. GeometryGirl (talk) 12:36, 11 September 2009 (UTC)
Question Maybe I'm missing something here, but this is already implemented, at least in the monobook skin. Go to 'My preferences', click on the 'Appearance' tab, and scroll down to 'Advanced options'. There you should see a box labelled 'Threshold for stub link formatting', where you can set the threshold in bytes for what you consider a stub. Such links will then appear in a slightly darker red than a normal red link. The actual colour is defined for the class a.stub in http://en.wikipedia.org/skins-1.5/monobook/main.css. Individual users could of course override this colour in their own monobook.css. Dr pda (talk) 02:09, 11 September 2009 (UTC)
Stubs I wanted to add a comment here about something said at User talk:Cacycle#coloured links for stubs. The quote from there is "4) Stub pages not are appropriate for an encyclopedia: "A stub is an article that is too short to contain suitably encyclopedic material".". I understand that there is probably a policy or guideline page that says that somewhere, but the fact is that it's simply not true. There are many "stubs" that do need to be expanded, but there is also a significant portion of them that really should not. I know that I'm far form the only one to have that view as well, so I'm fairly comfortable in saying it. — V = IR (talk to Ω) 12:50, 11 September 2009 (UTC)
A article with no sources surely should be expanded. There exist small and developed articles... The smallest featured article is not much longer than Fastflow. GeometryGirl (talk) 14:54, 11 September 2009 (UTC)
This is just a wording issue. There is "lengh (prose) expansion" and "sources expansion". Both are expansion. Improvement is done on something already existing. I can improve the existing prose, but I certainly can't improve the current sources, since there are none! :) GeometryGirl (talk) 15:08, 11 September 2009 (UTC)
Just as a point of information, in my experience, an article like Fastflow, with so many sentences clamoring for elaboration, could easily be doubled in size once sources are provided to support the claims made. Geometry guy21:39, 11 September 2009 (UTC)
The other aspect of this is that I'm addressing the idea that was brought up, which is why I haven't and will not provide specific examples. As a concept, the idea that stub must be expanded is simply wrong. They are definitely good candidates, as a class of articles, for expansion (statistically, you're much more likely to find an article needing expansion by looking at stub articles). — V = I * R (talk to Ω) 15:12, 11 September 2009 (UTC)
Support This would be great. Encouraging stub expansion is something I've seen for the first time, and it makes well enough sense. warrior432123:38, 10 September 2009 (UTC)
Supportonly because of: "Registered users will the prompted to use a new colour". You can do what you like, and you can even advertise for it in a limited fashion and I wouldn't mind in the least. When you cross over into actively pushing me to adopt something that I'm not looking for myself, then I'm very likely to just tell you to hush and ignore whatever you're saying. Aside from that, the post above applies to myself as well. I have custom colors, and I would appreciate it if everyone else were able to respect my personal choices. — V = I * R (talk to Ω) 00:18, 11 September 2009 (UTC)
There is no question of enabling this by default. We shall advertise it via a sitenotice or a watchlist notice. (See Shereth's comment below.) I have rephrased the proposal to remove any confusion. GeometryGirl (talk) 12:30, 11 September 2009 (UTC)
OK, changed to support, as long as it's understood that this is a gadget, and not a proposal to change the MediaWiki software. (I likely won't use it, but I'm certainly not going to stand in the way). Thanks. — V = I * R (talk to Ω) 12:41, 11 September 2009 (UTC)
Support per my above comments. In response to Ohms plight, perhaps it could be enabled by default, but can be disabled in preferences. Current users would default off and have to enable it themselves, only new users would have it checked by default. - ʄɭoʏɗiaɲτ¢02:24, 11 September 2009 (UTC)
As I indicated previously, I am okay with the creation of a gadget of some kind that people can use to provide this kind of functionality. I am also okay with advertising it via a sitenotice or a watchlist notice, or the like. So long as it is opt-in and not opt-out (enabled by default) I am okay with it. Shereth05:16, 11 September 2009 (UTC)
Support An excellent idea. The easiest way to implement it would be enable to settings mentioned above as a default setting, or to create this as a gadget accessible throuugh preferences and enabled by default. Then if users don't like it, they can simply change the setting. —Charles Edward(Talk | Contribs)14:20, 11 September 2009 (UTC)
Support The argument for the proposal makes a lot of sense. I don't see much of potential problem, either. -- Taku (talk) 23:49, 11 September 2009 (UTC)
Strong oppose. (1) This would be a usability nightmare. (2) It is technically not possible at the moment and it is completely unlikely to be implemented anytime soon. One reason for this is the enormous resource intensity to make it happen: the articles for every single link on a page would have to be retrieved and searched for a certain string for every page call. (3) The proposal conceptually mingles English-Wikipedia specific content with a function of the underlying general software. (4) We do not necessarily want stubs to become expanded, especially by people not qualified to do this, and, (5) more importantly, nobody will go and expand stubs just because their link is displayed in a different color. (6) Other triggers for a new link color would be much more useful, such as disambiguation pages[1]. (7) It is out of the question to make this the default behavior. (8) Whoever wants the functionality anyway, can already use a user script such as User:Anomie/linkclassifier.js. Cacycle (talk) 03:09, 11 September 2009 (UTC)
Thanks for having now clarified your proposal into a real opt-in option. But if all this fuzz is only about having a new gadget then I see no reason to vote for it here. Ask somebody to adapt an existing script and go through the approval process on Wikipedia:Gadget/proposals. Cacycle (talk) 12:49, 11 September 2009 (UTC)
It is easy to say "ask somebody to write code". Who is that somebody? Also, we need consensus that this is a worthy enough cause to have a sitewide notice. (May I also ask you to remove your "strong oppose"?) GeometryGirl (talk) 14:31, 11 September 2009 (UTC)
The code is already there, only the category/template names need to be adjusted to stub categories/templates. User:Anomie/linkclassifier.js uses a relatively fast and resource friendly api call that (afaics) does not require full text analysis server-side. Cacycle (talk) 23:32, 11 September 2009 (UTC)
Oppose - 1) I don't think this is important enough for a sitewide notice. 2) If we're going to encourage as many users as possible to use this, we should be promoting the already existing "stub threshold" user preference rather than creating inefficient scripts. Mr.Z-man17:04, 11 September 2009 (UTC)
Haha, my bad. This idea could be adapted to the stub threshold preference by adding the ability to choose which colour you use instead of the default maroonish colour. Many people, myself included, have modified our theme.css to make it a different colour. - ʄɭoʏɗiaɲτ¢20:35, 11 September 2009 (UTC)
It could be, yes, but we've apparently moved from discussion to voting, and it wouldn't really be proper to change the proposal after several people have already voted. Mr.Z-man21:11, 11 September 2009 (UTC)
Not with the current stub system. Currently, we have tons of stubs that are just marked as stubs because they are small. I just opened a random article: Octávio Machado. While that article could be improved, I don't see that it needs particularly more attention than any other random article. — Sebastian15:57, 12 September 2009 (UTC)
Other
Indifferent as to gadget status, which is neither here nor there; Strong oppose to any mention of this being default or opt-out. (Moved, direct response to Charles Edward) --KingÖomie14:31, 11 September 2009 (UTC)
As above don't mind or care if it is just an optional opt-in gadget but absolutely opposed to this being a default setting for anyone and/or anyone having to opt-out to stop seeing it. Wikipedia is here for the readers first and foremost and anything that makes the experience worse for them (as I think this will by making article links more obtrusive - 3 different colours in an article is not a benefit for readers). It would also discourage people from linking to stubs (featured articles already have a de-facto no redlink policy and stub links would I'm sure be discouraged if they were a different colour). Davewild (talk) 16:27, 11 September 2009 (UTC) p.s. if the views of those in support who want this an opt-out device pervail then consider this a strong oppose. Davewild (talk) 16:29, 11 September 2009 (UTC)
True but I notice the relinks did get a comment on the discussion on promoting the article to FA status and had to be defended there. I could change my statement to "relinks are viewed negatively at FA". Davewild (talk) 16:50, 11 September 2009 (UTC)
Redlinks are not disallowed in FAs (one of several misconceptions about FA and related processes), although I do agree that reviewers often like to see red links blued where possible. Dabomb87 (talk) 21:12, 11 September 2009 (UTC)
I honestly don't care if this is a gadget (or just a user-script), but it'd be nice if the same proposals weren't rehashed day after day after day. If I see one more blasted thread about changing link colors, I'm going to scream. EVula// talk // ☯ //19:38, 11 September 2009 (UTC)
Current weather
I came across mw:Extension:AccuWeather a few months ago, and thought it was a neat feature. Then, after thinking about it this evening, I decided it would be an excellent idea to implement something similar that would be put into place on city articles, specifically in {{Infobox settlement}}, that would display the current temperature at a given city in both Fahrenheit and Celsius. At first this seemed like a bit of a crazy idea, but it seems like it would be a rather minor, albeit useful, addition. Additionally I expect this will be technically feasible. Any thoughts? –Juliancolton | Talk02:51, 12 September 2009 (UTC)
Support I like this idea a lot, though I think a new extension would need to be coded for it to work. I think the best application would be to include current conditions, and perhaps the chance of precipitation in the next 24 hours in infoboxes. — JakeWartenberg03:04, 12 September 2009 (UTC)
I was just thinking in terms of technical functionality; it is nice to have more options than less. We can decide what to put in the articles later. — JakeWartenberg03:27, 12 September 2009 (UTC)
I would warn on the possible issue of promotion. This would rely on an external service, presumably accuweather.com, but then what would be the appearance ? If it were silently encoded, it would be okay, but if for example a link to their website mentioning it is required... Cenarium (talk) 03:43, 12 September 2009 (UTC)
Oppose: 1) Not really encyclopaedic knowledge, 2) Would have to rely on a third party service for the data, 3) Almost impossible due to the caching that we require. Peachey88(Talk Page ·Contribs)06:44, 12 September 2009 (UTC)
The weather data would be stored on a third party service compared to our servers, so it would require additional requests on page loads making things slower pluse additional issues if something was to go wrong on their end. Peachey88(Talk Page ·Contribs)01:45, 13 September 2009 (UTC)
Conditional Oppose, to using an AccuWeather version of weather info. If it was anyone but AccuWeather (or any other branded commercial weather service, for that matter) I wouldn't mind one bit. Wikinews has weather info, so if we're going to do something like this it should be coming from there. I like the core idea of adding weather info, but using a commercial service to do so, here on Wikipedia, seems wrong. — V = I * R (talk to Ω) 09:18, 12 September 2009 (UTC)
Encyclopedias include information about a location's climate, not weather forecast. That's more Wikinews' forte. I oppose. wodup09:27, 12 September 2009 (UTC)
To be fair, comparisons between Wikipedia and traditional encyclopedias can only go so far, and this is one of the areas where a direct comparison cannot be made; it is absolutely impossible for a traditional encyclopedia to include current information about a location's weather. EVula// talk // ☯ //14:50, 12 September 2009 (UTC)
Other encyclopedias that are on paper, cannot include current temperature. They print a copy maybe every 5 - 10 years? There is no plausible way to give current temperature. This is one of the advantages of using a website, instead of a book. warrior432114:56, 12 September 2009 (UTC)
Of course not. But that doesn't mean that a "weather right now" should be in Wikipedia just because it can be. It's simply not an appropriate thing to put in an article, here. ♫ Melodia Chaconne ♫ (talk) 16:17, 12 September 2009 (UTC)
Oppose including this information in articles by default. Wikipedia is an encyclopedia. The current weather is useful, but it has nothing to do with the purpose of this encyclopedia. We also don't do plane fares, local movie times, or directions. These are all useful things that the internet is very good at, and that print encyclopedias cannot do, but that doesn't mean we need to do them. These things can already be found on the rest of the internet, by people who are much better at it than we can ever be. But if you want to implement this as a Gadget, then sure. —Noisalt (talk) 16:24, 12 September 2009 (UTC)
Oppose - Any such service creates a dependency on a third-party site for the information. If the site goes down, the gadget breaks. If the site gets slowed down (like from having a top-10 website suddenly start getting its data for thousands of pages), then our site gets slowed down. There might also be copyright issues for the data, the way its presented, and the software the service uses. The AccuWeather extension linked above has several other problems that would pretty much guarantee it would never be enabled on Wikimedia sites in anything close to its present form. Mr.Z-man16:44, 12 September 2009 (UTC)
Comment, your first few concerns could be resolved by caching the mined data. Also, the NOAA publishes its findings into the public domain. As for the AccuWeather bugs, I'm sure our developers would help us if we formed a consensus in support of this addition. –blurpeace(talk)00:00, 14 September 2009 (UTC)
Cache it for how long? Current weather data is pretty much useless after a couple hours. NOAA only covers the US, presumably we would need worldwide coverage. The problem with the Accuweather extension is not only bugs (though it does have several), the problem is the design. To go into detail:
It relies on JavaScript with no fallback. Users who the JS doesn't work for, or who have JS disabled will just see a big blue box.
The JavaScript is just a thin wrapper around an embedded Flash object. Flash uses non-free technology, and there's also no fallback for browsers without Flash support (this is a problem with accuweather, not the extension)
It gets content directly from the accuweather site, creating a potential privacy issue, by giving them the IP address of every person who visits an article that uses the extension.
Oppose. Mr.Z-man has succinctly characterized the core issue. And to clarify: Yes, we use some outside tools, but these are used only for maintenance and not for content.---— Gadget850 (Ed)talk16:52, 12 September 2009 (UTC)
Oppose – this is an encyclopedia. No encyclopedia that I know provides up-to-the-minute tourist information. Shall we also update the status of London Underground lines? "The District line is currently closed due to a signal failure," would not befit Wikipedia, and it's precisely the same principle. ╟─TreasuryTag►Woolsack─╢ 17:00, 12 September 2009 (UTC)
Oppose this well-intentioned idea per the valid reasons made by others above. In contrast, it makes perfectly good sense for pages about cities to state things like average yearly temperature and rainfall, but not this. --Tryptofish (talk) 17:22, 12 September 2009 (UTC)
Qualified support/oppose: If you had something that gave the reader an idea of the most recent weather over a reasonably long period, say the last three or six months, that might be helpful. For example, an article about New England would say that we have hot humid summers, but that hasn't been true this year and without correction a reader would have to assume that the New England summer of 2009 was also hot and humid. But 2010 might be different, so a moving or self-refreshing source that avoids the other possible problems with Accu-Weather might be useful, and the kind of Wikipedia function that printed works can't offer. —— Shakescene (talk) 23:52, 12 September 2009 (UTC)
Weak Support. It's a nice idea and useful. Will this be possible without a user having to download an applet and will it jack up the kbs of of articles? Valley2city‽05:31, 14 September 2009 (UTC)
As others have mentioned, this kind of info is more of a Wikinews thing than for an encyclopedia. On the other hand, if Wikimedia wanted to better integrate the various projects, I imagine you could have a Wikinews box (maybe a template) in major city articles that could update things like weather and local news headlines on a daily/weekly basis. This kind of mini-In The News could potentially give locals a greater incentive to contribute to Wikinews if they knew their headlines would show up somewhere on WP.Joshdboz (talk) 13:39, 15 September 2009 (UTC)
Agree/Support I like User:Shakescene's suggestion has quite a bit of merit. While I agree wikipedia isn't a news service, but current weather news doesn't serve well as it happens in a relatively short amount of time. A hurricane, Major Tornado, Droughts, and Major flooding (and recovery) can happen over an extended period of time.
Comments: I have several COI issues on this topic but I would oppose this idea based on the goal of creating an encyclopedia and the performance issues mentioned above. Further, the NWS/NOAA provides some climate data but also now seems to charge for some of it. An external link to their free stuff may not be unreasonable, much like many gene/protein articles have links to entries in pubmed. The gov sites provide a lot of useful free information on a bunch of topics but most of it is computer generated so it makes good information for an encyclopedic article but none of the sites themselves seem to be encyclopedias.
Strongly Support This would be cool, and yes it would be encyclopedic. If someone needed to know climate for a project, they could then have past and current climate data.Accdude92 (talk) (sign) 14:16, 17 September 2009 (UTC)
Strong support- While I generally agree with Mr. Z-man, I must say that he is a bit misguided on the technical portions. Certainly, wikipedia would be requesting info, but it would then be cached and served from wikipedia's end(any third party would create a serious privacy concern). It would be fairly easy to implement, the bandwidth usage would be easy to control based on how often the update is.— Preceding unsigned comment added by 65.51.38.194 (talk) 23:28, September 23, 2009 (UTC)
My comment was based on how the AccuWeather extension actually works right now. Doing caching locally in a way that doesn't completely break the existing caching system (which caches pages for far too long to cache weather data, 30 days or until an edit IIRC) would be far more difficult. And it would still require us to find a source for free (in terms of both price and IP) weather data that doesn't use Flash. Mr.Z-man00:16, 24 September 2009 (UTC)
There are already such things as bots, and they are responsible for considerable amounts if edits in Wikipedia.However, I strongly oppose the above suggestion. Wikipedia gives human editors the chance to be creative and to write articles on subjects whichthey have some knowledge. We do not really want to turn Wikipedia into a purely machine-driven,robot-generated list of facts, which would most probably reduce the quality of most articles. The Wikipedia in Volapuk had many articles by a bot, but it did not appear to be superior to the English Wikipedia. ACEOREVIVED (talk) 23:00, 14 September 2009 (UTC)
Why go to all that trouble when a robot can do it instead? The content of articles is purely informational and objective, and since references are required and original research is prohibited, all the editor does is just reflect the information. This is a good task for robots, not humans. Of course there would have to be a human oversight and humans would still be able to edit, but this idea would allow for a mass production of articles and significantly help the public at large. --William S. Saturn (talk) 00:31, 15 September 2009 (UTC)
I used to do AI in school. What you're asking for would be awesome, but is currently impossible. It would require a bot that understands English, and if you can solve that problem, you've solved most robot problems by extension (and they would soon take over the world). - Peregrine Fisher (talk) (contribs) 00:55, 15 September 2009 (UTC)
There have been bots that extract information from a database and create articles. Recently there was one creating articles on algae, but it was more clueless than a human, and could not handle articles already existing, on the same topic or same name different topic. Another case was the mindless creation of stubs on rivers with almost no content. Graeme Bartlett (talk) 14:02, 15 September 2009 (UTC)
Even if a bot could do this, a "perfect" paraphrasing would lead to massively inconsistent articles, as they would still be in the same general tone and style of the source. It would need to be able to both paraphrase it, and convert it to Wikipedia's style. Mr.Z-man16:33, 15 September 2009 (UTC)
On a side note, Microsoft Word has an auto-summerize feature that sort of does a bit of what you're asking for. I ran it against an article on creating a lunar DNA bank, and it actually did a pretty nice job. Of course, it doesn't aggrigate across multiple sources. A Quest For Knowledge (talk) 17:02, 15 September 2009 (UTC)
Key to the problem is plural: paraphrasing a single cohesive text is peanuts, but no robot can stitch together pieces picked from different sources. Collecting, selecting, collating and presenting multiple sources will inevitably take more time than any manual "paraphrasing" and, guess what, once the homework is done properly it's not necessary at all. NVO (talk) 18:57, 15 September 2009 (UTC)
Oh ye of little faith!
You insist that there is something that a machine can't do. If you will tell me precisely what it is that a machine cannot do, then I can always make a machine which will do just that. — John von Neumann
The key word in that quote is "precisely": once you give me a precise definition of "a robot that would paraphrase sources and actually write the articles for us", I'll be happy to code up the bot. Keep in mind that you'll get exactly what you ask for, so if you're not careful in how you define "paraphrase", "sources", and "write the articles", you're likely to get a high-tech nonsense generator. --Carnildo (talk) 23:06, 16 September 2009 (UTC)
This whole discussion seems to be pointing to one of those nightmare discussions about whether human electronic, electrical or mechanical devices will ever replicate human intelligence. Can I just say that when, in 1997, Kasparov was beaten by a computer called Deep Blue at chess, the people were saying "Oh, how clever a computer". However, a letter appeared in "New Scientist" pointing out the following. The event actually showed how intelligent humans must be to have constructed a computer that could out-smart Kasparov. ACEOREVIVED (talk) 19:21, 23 September 2009 (UTC)
Revert alert
I propose to have a feature whereby if a user's edit gets reverted, then that user would get notified (on a "revert list", or maybe on their talk page). GeometryGirl (talk) 21:54, 17 September 2009 (UTC)
Although I can see a use for this feature for legitmate edits that are reverted, I can see too many editing conflicts/wars becoming escalated due to it. Especially in articles where heated edit wars often occur (eg anti-americanism), such a tool would promote even further reverts, without little justification. Also, it would place an unnecessary weapon in the hands of vandals. OpposeIciac (talk) 23:33, 17 September 2009 (UTC)
Comment. I think she means she would like a warning generated everytime somebody reverts her, just like the PROD and CSD warnings one gets if the article they created receives such a tag. warrior432123:44, 17 September 2009 (UTC)
Those warnings aren't generated automatically, either the tagger or a bot has to add it, having that for every revert would be extremely excessive and result in thousands more edits a day. If a user cares about the edits they make its assumed they have the page watchlisted, often if a revert is major users will talk to the user they're reverting anyway, the whole WP:BRD system--Jac16888Talk23:50, 17 September 2009 (UTC)
Not really. You know when you tag an article for PROD or CSD with Twinkle, it automatically sends a warning to the initial contributor? If somebody reverts with Twinkle, the same warning should be able to be made, without a bot. warrior432100:30, 19 September 2009 (UTC)
yes but those edits are still made, by you, they are still listed in recent changes and contributions and therefore would still be excessive--Jac16888Talk10:13, 23 September 2009 (UTC)
I don't think making things hard to force a certain behavior is ever a good idea for Wikipedia. I also want something between a watchlist and my contributions. I may want to know if someone reverts me or edits soon after, but not follow every edit to the article until I manually remove it from the watchlist. --Apoc2400 (talk) 19:06, 18 September 2009 (UTC)
In addition to the valid concerns Jac16888 and Iciac raise, this sort of thing would only support people in their efforts to control a given article. If someone cares and/or worries that much about a particular edit, I'd suggest discussing it on a talk page first. ~ Amory (user • talk • contribs)19:22, 18 September 2009 (UTC)
On the contrary, those who OWN an article surely have on their watchlists. This would help visting editors notice if they are reverted by the article regulars. I also still hold that we shouldn't speculate on how people might use a technical feature at all. The interface should help editors find information and edit, not restrict information in an attempt to control. --Apoc2400 (talk) 01:27, 19 September 2009 (UTC)
Unhiding reference errors on User-namespace pages
(forwarded from Help talk:Cite errors#Broken refs on user pages) A while back, the various MediaWiki messages for errors generated by broken <ref> tags were adjusted to be hidden on talk pages, after numerous complaints about how "useless" they were there. I was testing references in my sandbox, and discovered that the namespace detection also hides the error message in the User namespace.
I don't suggest adding user pages to the reference error tracking categories (that would be about 3147 of them, after all), but would anyone be opposed to making this edit so we can see the errors? Anomie⚔22:55, 18 September 2009 (UTC)
My suggestion on a tracking category was only to see how many pages would be affected— your API query answers the question. My only issue is if we would have a large number of readers getting confused when error messages start showing up. Could we wrap the message in a class that would normally hide it and allow editors to opt-in? ---— Gadget850 (Ed)talk23:29, 18 September 2009 (UTC)
That would work for me, although why someone would have refs on their user page (or user subpage) and not care that they're broken is beyond me... Anomie⚔02:20, 19 September 2009 (UTC)
Well, we had all those references copied to talk pages without a <references /> tag. Instead of actually fixing it, folks just wanted it to go away. And that's how we got here today. Anyway, it's just a thought— let's see what others think of it. ---— Gadget850 (Ed)talk02:47, 19 September 2009 (UTC)
I have pages in my user space with references without a <references /> tag. There are many reasons for this, not every page in userspace is a proto article. Some are just pieces that are intended to be inserted in an existing article. Some refs are just there to record where information came from, it is not necessarily desirable to clutter the page by actually displaying the information. There is one like that on my userpage which it looks like you are now going to force me to either delete or rework my page. SpinningSpark20:00, 23 September 2009 (UTC)
If you have references for copying and pasting into different articles, put them in <pre></pre> so you don't have to view the source to copy the text. If you have an article section (rather than the whole article) on a userpage, why not throw a References section at the bottom so you can see that the references are being formatted correctly too? If you're wanting strange "refs" that go nowhere just to hide the source information in the wikitext, why not use <!-- comments --> to do it more straightforwardly?
This is not my idea, but I think it is a good one: Allow readers to ask questions if an article doesn't have what they're looking for. GeometryGirl (talk) 00:03, 21 September 2009 (UTC)
I could see something like that. I know on many pages, when someone asks a general question they might get a reply (or even their question removed) with a terse "not a forum", but maybe through asking these questions, i.e. through that discourse we can wind up thinking of ways to improve the articles, especially if sources come up in the discussions. Sincerely, --A NobodyMy talk02:13, 21 September 2009 (UTC)
After some thought and after going through the experience myself of climbing the ladder from newbie to established, I can safely say that my successful climb was based purely on determination to continue despite the odds.
What I mean by this, is the difficulty of new users in learning the ropes, the policies, the rules, and the little ins and outs of the encyclopedia. While they are all linked, these policies are laid out to be stand alone policies, and thus new users have to read through a lot of information, and often give up.
I propose a page that lays out all the cornerstone policies all at once, in a simple manner. Each policy would link to its standalone article, where the user could get more specifics. However, this all-in-one page would cover all the important information in one swift blow. This page should be linked directly from WP:Introduction.
Maybe it would help some newbies, but in my own experience I have still never after 3 years, one as an IP and two on this account, ever ever ever ever NEVER read wp:introduction or the 5 pillars, neither can I tell you what the five pillars are (1-There is one God, 2-Mohammad is his prophet, 3-pray 5 days a week....oh, I only got 3 of the five! darn!). I imagine there are more than just me who got hooked on Wikipedia (and drugs) from experimenting on a single article or group of related articles in a topic that they really care about. Are there alot of potential newbies who right now are saying "I wish I could grow up to be an administrator on Wikipedia! But how?!". I think throwing at them our policies and guidelines and trying to make them "good little editors who follow the rules" is the wrong image we want to give. We want them to have fun, experiment, learn by doing. We dont want them to have to memorize a bunch of rules first and expect them to conform right away. We and our consensus driven policies and guidelines need to evolve and grow, and they do so by having newbies who question the purpose of them and point out new ways of doing things. Do we want to crush that spirit so soon when they get here? How about this- when you first sign up an account you get a page that says "Welcome! Now have fun, if you have questions go to xxxx. We do have some policies and guidelines that we have come up with to solve most problems that may arise, you may want to check them out when you have time, this is where you may find them (wp:list of policies)" or something less corny, or maybe more corny to lighten up the mood. First and foremost any message to newbies needs to convey that we want them to have fun and that they have all the rights and responsibilities of someone who's been here 5 years.Camelbinky (talk) 03:36, 23 September 2009 (UTC)
I'm very happy to say that I actually agree with Camelbinky. The one and only real rule is: Ignore all rules. If the goal is to make new editors feel more welcome and to just help them out in osme manner, the answer is certainly not new procedures, new rules, new process, or anything like that. There is already far to much process here, far too little community, and just too much angst and drama for little purpose. — V = I * R (talk to Ω) 05:33, 23 September 2009 (UTC)
I think if thats the case then in turn we need to be more lenient on these new editors for ignoring all rules. I agree otherwise though. I didn't mean a long droning page on the rules, I meant something that sums up the wiki-lifestyle of experienced editors to help assimilate the new editors in. Too many editors join and don't become long standing, non-SPA members, which we need more of. - ʄɭoʏɗiaɲτ¢06:48, 23 September 2009 (UTC)
The thing is, there's really nothing here socially other then negative, confrontational items for editors to be involved in. I'm decidedly not advocating for some sort of attempted conversion to facebook or anything like that, but almost the only reason that anyone has to talk to each other here is to discuss how we disagree. The whole underlying structure of Wikipedia is negative.
LiquidThreads should be a fairly significant step in the right direction, but the anti-social aspects to Wikipedia are endemic in policy and guidelines as well. — V = I * R (talk to Ω) 17:27, 23 September 2009 (UTC)
WP:AGF goes a long way - or at least it should - to addressing this problem. We need to remember that most newbie editors are not ignoring rules, they are simply ignorant of them. There is certainly some merit in the idea of trying to educate them up front to try and keep them from getting involved in a firestorm down the line, but the "antisocial" aspects that you allude to need to somehow be addressed. Unfortunately, I don't know how you can force established editors and administrators to be more welcoming to newcomers and forgiving of mistakes. Shereth17:37, 23 September 2009 (UTC)
Generally speaking people can't be forced, but they can be overwhelmed and may "see the light" (so to speak). Thre are good technical reasons to limit discussions on Wikipedia, since the software really isn't designed for forum like communication. It's (relatively) perfect for single document collaboration, but there's a good reason that no forums use wiki-style software for their underlying platform. LiquidThreads will at least remove one major problem (edit conflicts), and significantly address several more minor issues (automatic sigs, watch-listing specific conversations rather than pages, etc...), so that's a definite first step. We'll see where it goes from there. — V = I * R (talk to Ω) 18:05, 23 September 2009 (UTC)
Personally when I come to wikipedia, though there are some articles that I have personal investment in, I come with the intent of working together. I know I'm not perfect (I know my sentence structure and grammar are horrendous), and I hope to work with others to create perfect articles. We need to make an effort to work that attitude into new editors. You can't teach an old dog new tricks, but you sure can lead the puppy to success (Sorry for the really aweful metaphor) - ʄɭoʏɗiaɲτ¢03:52, 24 September 2009 (UTC)
Articles for Conversion to Redirects
What I am proposing is a procedure midway between deleting and merging an article. The proposed conversion to redirect would be discussed and if the consensus is for conversion the resulting redirect would be placed into Category:Redirects from conversion. It may also be desirable to have an administrator seal the history of the page at the point of conversion to prevent reversion. If approved this proposal will affect Wikipedia:Articles for Deletion and Wikipedia:Redirects for Discussion as the procedures for these will have to be changed. -- allen四names18:04, 22 September 2009 (UTC)
Converting to a redirect is a standard option we have have long used at AfD as one of the results of discussion. As note in the first paragraph of WP:AFD, following an overview of the process: "Then the page may be kept, merged or redirected, transwikied (copied to another Wikimedia project), renamed/moved to another title, userfied to the creator's user page or user subpage, or deleted per the deletion policy." (emphasis added) Please see these search results. Are you proposing something that would be necessary separate and apart from this existing process and if so, how is it different and needed to supplement it?--Fuhghettaboutit (talk) 18:18, 22 September 2009 (UTC)
Articles for Conversion would proceed in a manner similar to Articles for Deletion without any need for an administrator to close it. A vote to delete would require WP:AFD, and a vote to merge will simply result in the standard merge. The edit summary of a conversion would indicate if administrative involvement was desired to seal the history as I pointed out above. -- allen四names19:38, 22 September 2009 (UTC)
This is, and should be, an integral component of the existing AFD process. The need for admins in AFD discussions is purely technical as well, not procedural. Admins are not moderators, they are simply trusted with responsible use of the tools, and can therefore perform actual deletions. One thing that should be done though is to rename all of the "X for deletion" processes/pages as "X for discussion", simply to reinforce the point that deletion is not even remotely the only action possible from an XFD discussion. A couple of other recent (more specific) conversaitons have occured along this vein, with the largest hangup being technical (changing the archiving bots to use "discussion" in place of "deletion" seems to be the largest hurdle). — V = I * R (talk to Ω) 19:59, 22 September 2009 (UTC)
There is no reason to fork this out of the AFD process, as has been stated above. WP:NAC specifically allows for non-admins to close these discussions as a redirect if the consensus indicates as much. Creating a dedicated forum for proposing an article be made a redirect is somewhat redundant and would add unecessary confusion and complexity to the process. Shereth20:04, 22 September 2009 (UTC)
You know, someone should probably take on the task of re-writing the deletion policy to make it clear that admin action is unnessesary for anything other then the actual deletion task. — V = I * R (talk to Ω) 20:11, 22 September 2009 (UTC)
AFAIK, the reason it has not is because WP:NAC is not policy, and doing so would essentially elevate it to policy. Perhaps there is some merit to the idea of refining WP:NAC and elevating it to a policy, as it seems to be fairly well adhered to. Shereth20:15, 22 September 2009 (UTC)
I have read WP:NAC and see that it may need editing if my proposal is approved. A closure of Articles for Conversion will not need an outside editor or administrator as long as the discussion about it is made. Otherwise the conversion can be reverted just like any other article edit. if an Article for Conversion discussion leads to conversion to redirect any reversion can be considered vandalism. -- allen四names20:32, 22 September 2009 (UTC)
I am really not seeing the need for this process, and it strikes me rather as a solution in search of a problem. Can you elaborate on the need for it when the mechanisms for doing this already exist within AFD? Shereth20:38, 22 September 2009 (UTC)
I forgot that you are thinking of this within the AFD context. There are merges in name only out there and I hope for a formal process. -- allen四names20:50, 22 September 2009 (UTC)
I believe the process you are looking for is called the Article Talk. If someone thinks an article should be merged or redirected, the proper thing to do is discuss it on the talk (or simply be bold per WP:BRD). There is no need for a centralized discussion on the matter. Shereth20:56, 22 September 2009 (UTC)
Okay. I still think something needs to be done so we do not have to pretend we are going to merge a page's content into another when using one of the merge templates, but I withdraw my proposal. -- allen四names21:50, 22 September 2009 (UTC)
For what it is worth, the use of a template isn't really even necessary. If it seems like an uncontroversial edit, it's probably safe to just redirect it without even initiating any discussion on the matter. If there is some room for contention, it can be brought up on the discussion pages. If you like, a version of the {{mergeto}} and {{mergefrom}} can be made to specifically address redirects. Shereth21:55, 22 September 2009 (UTC)
A "Requested mergers" task group, along the same vein as Wikipedia:Requested moves, would be worth attempting, if anyone feels up to the task. As something less then deletion, and a task which requires little if any admin activity, it could certainly be helpful. — V = I * R (talk to Ω) 00:03, 23 September 2009 (UTC)
Just so you know, newpages patrollers routinely redirect new articles without any discussion, and as reviewing admin on some speedy deletions, after some declines I will then redirect. If discussion is needed, the talk page serves, and if it should not be a stand alone article but the redirection is reverted, then a formal decision can be sought at AFD where, if a need to protect the redirect is found, that too be implemented by an admin doing the close. In short, now that what';s sought has been clarified I see nothing that current process (or lack of process) doesn't already address.--Fuhghettaboutit (talk) 00:34, 23 September 2009 (UTC)
Upload form usability
Our upload form is quite a mess right now in terms of usability. Here are just a few things I've noticed:
Why is "uploading images and multimedia" linked? I would expect such text to link to an upload form, but I'm already on the upload form!
"Go here and here to ask..." - so which link do I click? The first link is about copyright questions, and the second link has nothing about questions at all.
"other questions" - so what questions am I supposed to ask here and not at the other two links?
"Uploading a free image or media file?" - so if I'm uploading an image that isn't free, I go to the next section?
"...or a historically significant fair use image" - why is this on the same line as promotional photos? And what is a historically significant fair use image, anyways?
"A cover or other page from a book, DVD, newspaper, magazine, or other such source" - when I click the link, I go to a page that doesn't mention books, DVD, newspapers, or magazines. Did I do something wrong?
Why the heck is there a question mark with a C on this page? I'm not here to ask a question!
I agree that the upload form is very confusing for new and established editors alike. I get frustrated even looking at it, then I just go directly to Special:Upload. I'm not sure the best way to fix things, but your ideas seem like a great place to start discussion. hmwith☮17:02, 20 September 2009 (UTC)
The Foundation has received a grant from the Ford Foundation to improve the usability of uploading multimedia, and is currently hiring a full-time person to work on this project. — Werdna • talk12:37, 21 September 2009 (UTC)
I had similar thoughts about the upload form over a year and a half ago, after getting sick of seeing people endlessly uploading unencyclopedic crap (everything from random crude thumbnails pulled from Google Images to peoples CV's in PDF format; trawling through Special:Newfiles and Special:ListFiles is (or used to be) enough to make one weep), and also being annoyed with images transferred to Commons having their histories obliterated, so tried to design a new page to better direct people to the right place from the beginning. It's in my sandbox: User:Anakin101/Sandbox. I haven't done anything with it ever since so it's probably out of date with current policies and such, but feel free to butcher any aspect of it that seems useful. • Anakin(talk)12:59, 22 September 2009 (UTC)
I really like your new upload page Anakin. Perhaps, his page should be properly reviewed, and be proposed to change the current upload page. warrior432123:49, 24 September 2009 (UTC)
There needs to be a way to switch easily between Wiktionary and Wikipedia on every page...—Preceding unsigned comment added by GaryGermeil (talk • contribs) 02:43, September 26, 2009 (UTC)
I think what was meant was a link you can click on (a bit like the foreign language links, I suppose). Ordinary readers aren't going to know or remember about the "wikt" trick.--Kotniski (talk) 09:15, 26 September 2009 (UTC)
Collapse hidden cat and template lists on edit page
With regards to the edit page, can we please make it so that the hidden categories and transcluded templates are collapsible, and collapsed by default? On long pages these list can become quite unwheldly, and it seems odd that it is presumed the majority of people want to see them all the time. They are a major source of visual clutter on the edit page, and must be confusing to new users. -- Anxietycello (talk) 14:26, 26 September 2009 (UTC)
Someone could easily enough create a gadget to collapse them for you. As for the assertion that "[it] must be confusing to new users", . Anomie⚔18:12, 26 September 2009 (UTC)
Was the original question about collapsing templates in the edit textarea, or collapsing the list of "Templates used in this preview" at the bottom of the page (underneath the symbols box)? I know the Usability people are working on the former, but I haven't heard anything about the latter. Anomie⚔21:37, 26 September 2009 (UTC)
It was the latter; I'd like to see both lists that often appear on the edit page, the ones that read "Pages transcluded onto the current version of this page:" and "This page is a member of n hidden categories:" be hidden by default. In that those sentences still show, but have a [show] symbol next to them, that when clicked displays the full list to which it refers. I'd also quite like to see the wording of the template list changed, to something like "This page contains n transcluded templates:" so as to look more consistent, and to helpfully give the number of templates used.
Can we please tidy up and simplify the warnings on the edit page?
My proposed version (right) contains all the text of the current version (left), but presents it in a more logical and clear fashion. It also includes a request that all work submitted be neutral, verifiable and encylopedic - the core of our complex rulebook. Note how it also takes up less room.
Currently, there are three sources of the warning text on the edit page: MediaWiki:Wikimedia-copyrightwarning sits between the edit window and summary box, MediaWiki:Wikimedia-editpage-tos-summary sits between the summary box and the edit tools, and MediaWiki:Edittools generates the edit tools, as well as a section of warning text that follows it. I feel this is unsightly, confusing, and unnecessarily hard to spot and read. I propose that these messages be merged -- the first two should be deleted, and the text from all three be merged into something I would call "MediaWiki:Editwarning" (or something similar) which would be placed immediately after MediaWiki:Edittools, and would contain all the most important warning text of the three old messages, and some new, equally important text that I feel is currently missing. Above is a mock-up of my idea (the code used to generate it can be found at User:Anxietycello/Interface). -- Anxietycello (talk) 18:02, 24 September 2009 (UTC)
That's just to indicate that all these messages are important, and ideally should all be read when first spotted. I tried it with a thin grey line, but it just got lost in all the other thin grey lines around it. I also quite like the way it looks with the emboldened 'please note' header. -- Anxietycello (talk) 19:38, 24 September 2009 (UTC)
I see what you're getting at, but... meh. It's not an issue that is a deal breaker for me by any means, but I know from past experience that eye-catching formatting like this becomes annoying fairly quickly. The "Please note" text being larger and bold is fine, but the box is just too much. — V = I * R (talk to Ω) 19:50, 24 September 2009 (UTC)
A 2px black line isn't all that offensive is it? At least there's no flashing animations... I feel the (modest) border is akin to the image copyright notices. -- Anxietycello (talk) 20:38, 24 September 2009 (UTC)
I don't really have any "proof" to point to, but outlines tend to draw my eye in a similar fashion as blinking does. Well, not quite to that extent (obviously), but more then bold text does. Outlines are just not as common as text bolding is, so there's... a psychological difference? Bolded text you'll tend to pay more attention to while you're reading the actual sentence, but you'll tend to ignore it otherwise (it's not distracting). Headings draw your attention in a similar manner, in that you notice them while scanning the page but not so much while reading the prose. Outlines just seem to draw the eye to them regardless of anything else, which is what my weak objection is all about. — V = I * R (talk to Ω) 21:27, 24 September 2009 (UTC)
Is your problem with my little black line, or is it with attention-grabbing graphics in general? Because this in't really the place to wax philosophical... I'm not worring that people will be so drawn to my black line that they'll neglect to read the text. Bullet points are very easy to read. -- Anxietycello (talk) 22:52, 24 September 2009 (UTC)
FYI you can hide all of that crud thru your css. See mine, for example. Though I do think yours looks cleaner for those who haven't opted to do this. –xenotalk20:01, 24 September 2009 (UTC)
The position of MediaWiki:Wikimedia-copyrightwarning was dictated by legal concerns: by putting the GFDL/CC-BY-SA text between the edit box and the "submit" button, it's impossible for someone to claim they didn't realize they were releasing their contributions under those licenses. I've been trying to keep that text focused on license issues, but apparently the majority of the people on this website think that the solution to notices not being read is to add more notices. --Carnildo (talk) 21:23, 24 September 2009 (UTC)
I agree that that copyright notice is a little swamped at the moment, and that was one of my main motivators; to deobfuscate and so make it all easier to read. Is having it clearly written on the page not precautionary enough? How often to people try and claim they own the rights to the text they write? -- Anxietycello (talk) 22:52, 24 September 2009 (UTC)
Having the "You agree" language before the save button is important to us as Carnildo explains. (It can possibly be shortened a bit, but we have to be careful not to lose essential meaning .) That should still allow for a lot of cleaning/neatening of the current edit screen, though.--Eloquence*23:45, 24 September 2009 (UTC)
How about leaving "You agree to irrevocably release your contribution under CC-BY-SA 3.0 and GFDL licenses. You agree to be credited, at minimum, through a hyperlink or URL when your contributions are reused in any form. See Terms of Use for details." there, as it is currently (sans the first two sentences), merging all the other text into MediaWiki:Wikimedia-editpage-tos-summary (the warning just after the Save button), and moving the (trimmed) edittools up to sit below the the edit window? -- Anxietycello (talk) 12:16, 25 September 2009 (UTC)
Upon viewing your proposed layout, this was my concern as well, that the legality of the click-wrap could be affected. It seems to me that leaving the legal agreement in place and moving the rest would be a good improvement. 05:01, 27 September 2009 (UTC)
Uninvolved admin batsignal
Not so long ago, I copied {{adminhelp}} and the corresponding category Category:Wikipedians looking for help from administrators from their basis in {{helpme}} so that editors could quickly lure an admin to their talkpage for some uncontroversial gruntwork. The idea was to make it easier for editors needing help to find willing admins and vice versa, and to take some (relatively trivial) traffic away from the administrators' noticeboards. It seems to work well.
Perhaps it's just me, but I think our norms on what constitutes involvement for an administrator (and perhaps for others) have gotten stricter lately. I've also noticed increasing laments that various issues and venues were suffering from a dearth of uninvolved administrators. So I wonder if it would be a good idea to implement a similar system to {{adminhelp}} except for use in drama disputes on any talkpage where those involved feel that the situation could benefit from an unimplicated admin. There would be a template ({{freshadmin}}?) for editors concerned at potential admin abuse to deploy, and a category for similarly concerned administrators to monitor (perhaps also through IRC if that was deemed desirable). Again, this would make it easier for those in need of help to find appropriate helpers, and result in fewer unnecessary reports to admin boards (in this case, ANI dramafests). Like {{editprotected}}, the template should be nullified once the uninvolved admin arrived on the scene, and the category should be regularly cleared out. The template could look something like this, and include the category:
It could look something like the following (or perhaps might be better as a box at the side):
Update: Ah, after a little digging, it looks like there has been an abortive project along these very lines, at an obvious title: {{uninvolved}}. A tip of the hat to the arbitrator emeritus. Is this something we should be pushing forward? Skomorokh 08:19, 26 September 2009 (UTC)
Can't do any harm, and I can see it being helpful. The main issue is making easy for editors to find such tools - I've been editing since autumn 2006, and have being doing GA reviews since autumn 2008, but I've never heard of {{adminhelp}} or {{uninvolved}} until a few seconds ago. --Philcha (talk) 08:43, 26 September 2009 (UTC)
Aside from my philosophical view that there cannot be such a thing as an "uninvolved administrator"... the key to these things is simple: SPAM! Start adding notifications bout the existance of the template to obvious places. ANI and AN spring immediately to mind. Sprinkle mentions of the template throughout policy and guideline documents. Mentioning it in the AFD documentation probably couldn't hurt. I'm sure there are other places as well, but the kep concept is to reach that "critical mass" point of awareness. — V = I * R (talk to Ω) 08:50, 26 September 2009 (UTC)
I would like to propose that we create unique div tags for each edit notice so that they can be hidden via css by users who dont want to see a particular notice. βcommand23:47, 24 September 2009 (UTC)
Support I can certainly see this being helpful. Many pages, like AN, have edit notices that are geared toward new users and can take up more than half a page. — JakeWartenberg23:54, 27 September 2009 (UTC)
Support, but optionally, certain editnotices should not be dismissible (easily), for ex. in cases of editnotices used to handle edit wars. However, would this add a [hide] link (and be available to anons), or do we have to edit our css ? (I had requested optional disimissibility of editnotices in the past.) Cenarium (talk) 00:21, 28 September 2009 (UTC)
Question: "Unique div tags for each edit notice" sounds like you want a unique id per notice. I can see that this could be done based on the page name. Editors would have to hide each specific notice. ---— Gadget850 (Ed)talk00:37, 28 September 2009 (UTC)
that was what I was thinking. The BLP edit notice could be ignored while leaving all other notices in tact, or you could ignore any others that needed it via a single line in your monobook.css .DIVNAME {display:none;} and then not have to worry about it. For Cenarium's comment it would not be a javascript function, with a "hide" button, but rather a discreet method for removing annoying edit notices that users are familiar with. βcommand00:48, 28 September 2009 (UTC)
that is unique to each page while some edit notices are across multiple pages IE the BLP notice. and Im not sure how to remove just the edit notice without affecting other parts of the page. βcommand00:57, 28 September 2009 (UTC)
It will simply involve adding some code to the edit notice pages, and will ony effect users who add certain code to their monobook.css files. — JakeWartenberg02:19, 28 September 2009 (UTC)
How about make a spheric puzzle in the shape of Wikipedia logo and sell it somewhere (maybe not even in a site related to Wikipedia, sell it on geek gadgets and toys sites) this way the profits could help a little with the costs. There are some nice spheric puzzles in the market.
Maybe plushies of Wikipedia logo, Wikipe-tan plushie/doll, etc could be done latter. Teruo (talk) 03:59, 26 September 2009 (UTC)
This is probably something you should contact the Wikimedia Foundation about. To be frank, I doubt that interest would be high enough. I'm sure WMF buys premiums (pens with logos etc) for handing out at conferences and such, but when ordering things like you're talking about you need to order a lot at a time, and the ROI probably wouldn't be that high. → ROUX₪04:01, 26 September 2009 (UTC)
All they need is to make them in comercial scale! On another note, I think that store need more advertisement. Seems like it's not much known to the public. (my usermname was deleted by the system and I had to register again, is this "normal"?)Teruo (talk) 10:27, 28 September 2009 (UTC)
Kosovo naming convention revived
Because the manual of style for Kosovo has been outdated as a result of many factors (mainly independence and heavy disagreements) there is need for a new manual that would pave the way for naming standardization on Kosovo related articles.
Here are some examples of non-standardized usage of names:
Pristina (the capital) in its article has the name written with an 's', not 'sh' or 'š', but in many other pages the name is written with 'sh' or 'š'. (eg. here: "...was opened as one university in Yugoslavia, in the city of Priština...", or here: "...career in Tirana and the second one in Priština...", or here: "...households (94 in Priština...") — There are more easy to find examples just on Pristina that tend to be subject of edit-waring. Other cities that have the same problem are Pejë or Pec or Peja, Djakovica or Đakovica or Gjakova or Gjakovë... basically all cities with majority Albanian population. Other cities with Serbian majority (enclaves) seem to be more likely agreeable (see: Gračanica, Kosovo).
Another problem is the city infobox. In some cases the first name is written International/Albanian/Serbian(eg. Pristina), in other Serbian Cyrillic/Serbian/Albanian(eg. Vitina), other Serbian/Serbian Cyrillic/Albanian(eg. Đakovica)... This has been subject of heavy edit-waring as well.
A reasonable solution would be to use UN and OSCE naming convention: OSCE and UN, considering that there is no standard formula (Search results of most names have, approximately, similar results). —Anna Comnena (talk) 17:33, 27 September 2009 (UTC)
I was under the impression that the Pristina/Prishtina/Priština issue in particular was essentially resolved by this RfC. Is there a reason why the consensus there is no longer relevant? Happy‑melon21:42, 27 September 2009 (UTC)
No, Pristina/Prishtina/Priština seems to be solid. However focus is needed on standardization of names and naming style, as other cities and municipalities use different ones (as shown on request). If this (Pristina/Prishtina/Priština) style is also set as an example for other Kosovo municipalities that it would be very helpful if noted somewhere. —Anna Comnena (talk) 21:52, 27 September 2009 (UTC)
How did Wikipedia forget to put Birth of Confucius 551 B.C.E. on the This Date in History Margin
Using Metacritic and other aggregators for albums
Hello, what I am proposing is using aggregator websites in the Professional Reviews tab of album pages when there are 1) No other reliable professional reviews or 2) on albums with only one reviewer. I hope to implement this to avoid bias, as an aggregator website can often give a better impression of an album than one done by a single editor, like say Allmusic.
I used Black Flag because they are one of the strongest examples of this occuring.
It should be noted, however, that the practice of placing several different reviews by several different critics is just as effective. However it often seems that the catch-all for albums is AllMusic. I am simply proposing that shouldn't be allowed and aggregators be encouraged.
Since Metacritic pulls ratings from a peer list far greater than what can fit on Wikipedia, wouldn't it be easier and more accurate to use it? For example, if I were to go onto Metacritic to find reviews for 'Album', what if the four or five I pulled up were mostly negetive, even if the album recieved mixed to positive reviews? Wouldn't that be bias?
Would it be easier to sort through reviews until I find a couple that even themselves out, or just post the MetaScore for an accurate idea of what the critical community as a whole averaged it at?
Okay, enough ignoring this. Somebody explain to me why this shouldn't be used? It's the perfect tool to fight bias and takes the responsibility to aggregate reviews off of Wikipedia's editors and onto websites that practice it as their namesake! --Iron Chef (talk) 21:59, 30 September 2009 (UTC)
Hidden pages
There has been argument at Mfd about hidden pages. I strongly agree that they shouldn't exist on Wikipedia, as they serve no beneficial purposes in the project scope. Some say it violates WP:MYSPACE, others say WP:USERPAGE. I believe it violates both and this game is beginning to be my pet peeve. Many of those hidden page games consist of multiple subpages and that crowds the encyclopedia. I propose a guideline for this situation (sign books are heading the same direction) and get rid of the nonsense. ZooFari03:02, 24 September 2009 (UTC)
To my mind the examples up for MfD are already in violation of WP:NOTWEBHOST, but maybe we need to add "web-based games" or some such to the specific list of things mentioned as inappropriate. --RL0919 (talk) 03:22, 24 September 2009 (UTC)
I agree, to an extent, but no page is really 'hidden'. You can bring up a complete list of a user's subpages with a prefix search.
Some users utilize subpages to great effect, but others do indeed border on WP:MYSPACE content. Then again, there's no significant performance hit when you compare 200k in one page to 200k across five pages (not that we're supposed to worry about performance anyway). --KingÖomie03:28, 24 September 2009 (UTC)
The problem in these cases isn't whether the pages are truly "hidden" or not. It is that the pages are just being used to play games, rather than do anything even remotely related to the encyclopedia. --RL0919 (talk) 03:54, 24 September 2009 (UTC)
I think that a change in policy should dictate that hidden pages should not be used for playing games, as they serve no purpose to the encyclopedia at all. warrior432103:57, 24 September 2009 (UTC)
I am not sure that we need any new guideline or change in policy, as opposed to a change in how existing policy is implemented. There is already plenty of documentation of the fact that this sort of thing is not acceptable. The most direct mention that I know of is the following, to be found in a list of examples of unacceptable matter in the user page guideline: Games, roleplaying sessions, and other things pertaining to "entertainment" rather than "writing an encyclopedia", particularly if they involve people who are not active participants in the project. That seems to me to quite unambiguously cover this. There are also, of course plenty more relevant statements, including the much-cited WP:NOTWEBHOST: Wikipedians have their own user pages, but they may be used only to present information relevant to working on the encyclopedia etc. Thus we already have plenty to say that this sort of stuff must not go on. In fact I am against adding still more specific prohibitions of this particular thing. Trying to legislate for each individual case that comes up is, in the long run, a losing game, as people sooner or later come up with some other similar and equally unacceptable behaviour which is not quite covered, so you add legislation for yet another special case, and the process never ends. Using the general principles already in place, which quite clearly cover this case, is much better. I think what we need is a mechanism for dealing with this more effectively. I think adding this to the speedy deletion criteria could be helpful. It wouldn't work miracles, not least because certain unhelpful Wikipedians would be there removing every speedy deletion tag they saw, but it might help to get rid of some of these pages more conveniently, and it might convey the message that it is really against Wikipedia consensus. Another idea which might help is this: Instead of proposing each case for deletion as we find them, collect a list of cases and then propose deletion in one go. This might this mean saving a good deal of frustration and effort by having one deletion discussion instead of many. Conceivably it might also send a more effective message to the hidden pages fraternity, if they found that quite suddenly their plaything had been seriously hit. Some sort of task force or patrol group might be suitable. Any thoughts? JamesBWatson (talk) 08:56, 24 September 2009 (UTC)
I just think they're a big waste of time. We don't have a real space limitation, but as pointed out above, there's no point in making a "hidden" page game if Special:PrefixIndex will find it. Ten Pound Hammer, his otters and a clue-bat • (Many otters • One bat • One hammer)13:11, 24 September 2009 (UTC)
One of the MfD participants has pointed out WP:UP#Games, which already contains a specific guideline against hosting games in userspace. So there shouldn't need to be any further specification required on that front. I support JamesBWatson's suggestion above that such pages should be added to the criteria for speedy deletion. Doing repetitive, lopsided MfDs for these is a waste of effort. --RL0919 (talk) 13:30, 24 September 2009 (UTC)
Yes, I agree that WP is not MySpace or a webhost. However, when personal computers started becoming common in corporate America in the early 1990s, many managers, executives, and IT departments opposed and often removed games from Windows, especially the Solitaire game included with every copy of Microsoft Windows, claiming they were non productive. What they forgot was that playing Solitaire with a mouse increased hand-eye coordination, a Good ThingTM, as it made them more productive for real work. I was able to get my aged father to learn to use a computer by playing Solitaire. Yes, hidden pages, and awarding barnstars for finding them, is not directly related to writing articles, but if not abused, it can give newbies a chance to do some editing that doesn't hurt actual articles. I don't oppose making it a PROD criteria (I think CSD is too quick on the trigger), but lets use it sparingly, at least when a young user starts out, per WP:BITE, unless it's fairly clear the user has no intention of contributing and most likely never will. Maybe we can get some productive editors that way, rather than pushing them away. We all didn't start out knowing the WP edit window, markup language, subpages, and so forth. Playing around is learning, at least initially. So lets exercise some judgment about this rather than proscribing it arbitrarily and totally. [Full disclosure: I won one such barnstar, but it has nothing to do with my argument.] — Becksguy (talk) 15:57, 24 September 2009 (UTC)
These sort of pages have been pretty controversial. There is a lot of history, though I think the trend has gone from accepting it as harmless fun towards a more aggressive approach in the last few years. I think that both sides have some very reasonable arguments, and you can find some more info at User:Bahamut0013/Secret pages. Some history (light reading, eh?):
Wikipedia:Requests for arbitration/MZMcBride: triggered when MZM started deleting these pages. Note that the ArbCom found as fact that they don't meed the criteria for speedy deletion and that there was no consensus at the time.
These pages are not mentioned in the speedy deletion criteria now. That doesn't mean they shouldn't be, which is something for the community to decide. Consensus can and does change, so we'll see how this round of MfDs goes. One has already closed as "delete". --RL0919 (talk) 05:19, 25 September 2009 (UTC)
Why do we care so much about this? We are not actually paying any of these guys so it is only their own time they are wasting. There are plenty of vandals and trolls to hunt down in article space. What is going on in user space is largely irrelevant to our readers. It is even irrelevant to those editors who just want to do "serious" work. Unless it starts to interfere with article writing or an account is doing nothing but playing games it is a waste of effort to police it. SpinningSpark16:14, 24 September 2009 (UTC)
That's a reasonable argument on its face, but it's an argument against WP:NOTWEBHOST in its entirety. The problem is that they're using server space and bandwidth paid for by the Foundation for their own entertainment, without regard for what the Foundation actually wants it used for. --KingÖomie16:25, 24 September 2009 (UTC)
Give me a break, the amount of storage required for all these pages added together is minuscule. More server resource has been used up discussing them than they are actually wasting themselves. They are all very short, text-based pages. WP:NOTWEBHOST is aimed at people using their account to set up a free web site or to host their holiday snaps or to promulgate their own POV or OR. It is not aimed at editors indulging in some harmless amusement - as is shown by its specific exception for humorous pages. SpinningSpark16:40, 24 September 2009 (UTC)
Eye-rolling sarcasm really isn't required. If I've missed your point, just tell me.
I take it you're referring to this passage. Would you care to clarify how 'hidden' userspace pages are 'appropriate namespace', or even related to Wikipedia? Links of funny diffs are one thing- userspace scavenger hunts have absolutely no relevance to the encyclopedic 'portion' of this site. --KingÖomie16:58, 24 September 2009 (UTC)
The only part of my post that could be described as unnecessary was "give me a break". I am quite good at eye-rolling sarcasm but I am fairly certain that is not it. And yes, that is the passage I was referring to, although you seem to have contrived to mistakenly omit the key words in it. SpinningSpark17:57, 24 September 2009 (UTC)
I posted the second half of the relevant paragraph exactly as it appears, the only part that seemed relevant. The first part states specifically that userspace is only to be used for the improvement of the encyclopedia, and that any other ventures are to be taken outside wikipedia- I don't see how it agrees with your statement, unless you're misinterpreting the meaning of "hosting included with your Internet account". I certainly didn't contrive to do anything, and I really don't appreciate your attitude. --KingÖomie18:30, 24 September 2009 (UTC)
I apologize; I see I incorrectly fixed a category link when I corrected the broken URLs (omitted the leading colon)- leading to the appearance of missing text. I didn't notice at first, because the text certainly appeared in the edit window. --KingÖomie18:48, 24 September 2009 (UTC)
Thanks, that's saved me having to use my killer sarcasm again. I concede that this game cannot be argued to be directly Wikipedia useful. My point is not that; my point rather is that it really doesn't matter and we shouldn't waste our time on it. SpinningSpark18:56, 24 September 2009 (UTC)
Do I detect sarcasm in your description of sarcasm? Wait...
Support it as a rule? The essay doesn't advocate anything, it just gives the history of the debate and a summary of the supporting and opposing viewpoints. I've tried to simply tell users what the game entails as well as a neutral summary of the controversy surrounding it. I woud hardly describe an essay describing the game a cheatsheet, as that information would certainly be of interest to both supporters and opposers. bahamut0013wordsdeeds04:51, 25 September 2009 (UTC)
The bottom of this page at #The Use of the word "as," instead of because or since has degenerated into a very juvenile game of punctuation (had had had had.... buffalo buffalo buffalo buffalo.... etc etc etc etc) which is in no way connected with improving the encyclopedia and, I notice, has involved editors who in this post are vehemently opposed to the "secret pages" game. Is someone now going to propose deletion of the Village Pump page because it is being used for playing games? No, of course not; let it be, everyone plays games sometimes, even those who claim to be above it. SpinningSpark16:14, 25 September 2009 (UTC)
No one is going to suggest that, because that would be stupid. I might toss Wikipedia:Village pump (policy)\Signbook up on MFD though. This discussion is about pages created and maintained for the sole purpose of screwing around in a manner entirely unrelated to the encyclopedia. Casting it in any other light is purely hyperbole. --KingÖomie16:19, 25 September 2009 (UTC)
(out) - "Yes, hidden pages, and awarding barnstars for finding them, is not directly related to writing articles, but if not abused, it can give newbies a chance to do some editing that doesn't hurt actual articles." (Becksguy above) I agree with this 100%, because that is what got me involved on Wikipedia in the first place (2006). Sure, I left for 1 1/2 years after that, but I came back and I hope that I am helping the project a lot now. ;-) —Ed(talk • contribs)23:55, 25 September 2009 (UTC)
I agree. Within reason of course, we should be welcoming to newbies and allow them to get their "feel" of the place. What better way than to introduce themselves socially to other like-minded editors through guestbooks and a few hidden pages? Finding their way around this anonymous and sometimes intimidating place is for some people the first step toward great future contributions. Dr.K. logos 04:49, 26 September 2009 (UTC)
My primary concern here is the attitude of either entitlement or ignorance that often comes from the people maintaining these pages. "It's my user page I can do what I want" is the usual refrain. If these MfDs/deletions raise awareness that we actually do have policies about userspace, then I'm all for that. This is all even more important because user space remains indexed, and is a "public face" of Wikipedia. At the same time, my bar would be pretty low. A game that was related to the encyclopedia in a way other than "uses wiki markup", and was otherwise inoffensive, I'd probably say keep. Gigs (talk) 04:54, 27 September 2009 (UTC)
The Use of the word "as," instead of because or since
I have noticed a trend of using the word 'as' instead of since or because. This is improper grammar and is not scholarly, though this is what we attempt to show with it/— Preceding unsigned comment added by 137.54.26.68 (talk) 18:34, September 24, 2009 (UTC)
"Improper" grammar according to whom? And what exactly makes it "improper", anyway? Regardless, Kingoomieiii is correct, the MOS is the more appropriate venue for this sort of discussion. — V = I * R (talk to Ω) 19:16, 24 September 2009 (UTC)
I'm thinking this is anecdotal from someone's English teacher. I'd love to see a cite to this effect, though- I'd hate to think I'd been using incorrect English for years (no snarky response from the more nationalistic Brits required =P) --KingÖomie19:21, 24 September 2009 (UTC)
I'm no prescriptivist, but I think (contrary to what the IP suggests) that "as" is a whole lot better style than "since". They're both time-related words that have been co-opted to refer to causality, but lots of serious writers use "as" for this purpose while few use "since". "Because" is also fine, of course. rspεεr (talk) 03:01, 25 September 2009 (UTC)
This is a prime example of word efficiency at the expense of readability. Even with punctuation I had to read that twice. --KingÖomie12:58, 25 September 2009 (UTC)
"As" is not "improper grammar" (some moralistic attachment there?): it's just a badly engineered word in English, and particularly troublesome for non-natives. Sometimes it's impossible to determine, even from the larger context, whether it means "while" or "because". Drop it, mostly, is my advice, and use "since" or "because". Tony(talk)07:53, 1 October 2009 (UTC)
RfC to increase the default thumbnail size of images
It was set at 180px many years ago. There is prima facie evidence of considerable support to increase this, probably to 220px. Please have your say here (initial discussion above on that page). Tony(talk)07:46, 1 October 2009 (UTC)
Request for working group on images of biographical subjects
There are a number of biographies where, if you go to the talk page, you can see a request that a picture of the person should be inserted. At times, if one then goes to Google Images and types in the person's name, you can see a lot of pictures of the person are on the web - although some of them might be copyright, others may well be in the public domain. Can I request that a working group is formed on Wikipedia to look after insertion of images of people? Obviously, this would need to involve people who are skilful at downloading images; also, the group could ensure that any images which have been put on Wikipedia which are NOT in the public domain, i.e. are copyright, get deleted. This could be a good challenge for some technologically able Wikipedians. The group could function to ensure pictures of people are updated and do not violate any rules of copyright. ACEOREVIVED (talk) 23:03, 29 September 2009 (UTC)
Sounds to me like a Wikiproject. Every element of your idea is currently performed by some dedicated group of people - we have a copyright noticeboard for questionable images/content, for example. The only element not present is an organised group of people trawling for images. Since that's a relatively minor thing, I'd suggest you should set it up yourself as a Wikiproject if you can get others interested. Ironholds (talk) 00:07, 30 September 2009 (UTC)
Thank you, I have wondered whether this is better served as a task force within the WikiProject group on biographies (I have left a request on the talk page there). ACEOREVIVED (talk) 21:29, 2 October 2009 (UTC)
I'm really interested in creating some tutorials on using Wikipedia. I haven't really fleshed out this idea yet, but I would probably combine screen recording with voice over, and produce short clips of a few minutes on different areas and aspects of editing. I'd start with the basics, of course, but I could move on to introducing things like adding inline citations, uploading images, DYK review, etc.
I discussed this with another editor, and he pointed out that flash would probably work best for screen capture, and that it isn't supported on WP. Hurdle number 1. Assuming that I could use an alternative to flash that would be supported on WP, would the community accept video embedded on Help pages? If it couldn't be embedded, would it be ok to host the videos elsewhere and link to them from help pages? Instead of embedding help pages with videos specific to the content (which would be restricting for me), would it be viable to create a separate help page devoted to the videos? Would the community want to vet them first? How would it be established that they were appropriate?
Another aspect I am wondering about is privacy concerns. Would there be objections to screen shots that would, inevitably, show dozens of user names and some of their associated edits? Would I have to cover up the WP logo?
Has this idea been tried or suggested before and failed?
I hope that's not too many questions for one post! I'm really curious to know if this would work and am interested in hearing feedback. I really think that videos could help us retain editors who find WP initially bewildering. Plus, it would be fun to make them! Also posting to Village pump (technical) Maedin\talk18:40, 2 October 2009 (UTC)
Black background to save energy
I want to suggest a modification in Wikipedia's background color from white to black (and the font from black to white and from blue to yellow) as a means of saving energy. You could even also do as blackle.com does and publicly announce the amount of energy being saved.— Preceding unsigned comment added by 141.156.143.89 (talk) 00:23, September 18, 2009 (UTC)
Using black backgrounds doesn't significantly save energy, all studies show variable results. Using all upper-case letters has, however, been proven to kill unicorns. --Golbez (talk) 01:32, 18 September 2009 (UTC)
With modern LCD monitors, the difference is trivial — and some LCDs may actually use less power when displaying white compared to black: [19]. If you really want to save some electricity, shut down your computer and go outside — quit wasting time on Wikipedia. TenOfAllTrades(talk) 14:37, 18 September 2009 (UTC)
That article concludes the opposite of what you seem to think it says.
As I read that article (and I'm not judging either way), it says that because Cathode Ray Tube (CRT) monitors use so much more energy overall than Liquid Crystal Display (LCD), there would be a measurable and perhaps significant overall energy savings if many popular sites (or the web in general) switched to black backgrounds. Looking at Blackle myself with old eyes on a relatively-small, unadjusted desktop Flat Screen (Compaq FS7600), I found the type too faint and small to read. And those old eyes belong to someone who's been around long enough to have used white or green on black monochrome screens at school (Tandy Radio Shack 64 - 256K) and at work as a BASS TicketMaster operator, and that contrast can be tiring to the user. In fact I often tweaked the screen to make the background light green and the type black. Much more restful, when set dimly enough. —— Shakescene (talk) 05:58, 20 September 2009 (UTC)
The suggestion shouldn't be dismissed so glibly. So the difference would be "trivial" for LCD's? So what? A difference is a difference, the argument from "trivial" savings can be used with anything; in the aggregate the savings might be substantial. (people always make this kind of "it's just a drop in the bucket" argument against economy, ignoring the fact that, guess what, buckets can actually be filled by drops.) Webpages are increasingly being viewed on all sorts of displays, not just LCD's, some of them extremely large, many of them rarely shut down. Unless you can show that a dark background uses more energy, the objections to the suggestion aren't convincing. Wikipedia and Google should try dark backgrounds. They're easier on the eyes anyway.
Baseball Bugs, I have an even better idea! We can all edit using BASIC in MSDOS, forget mouses and Windows! Imagine the savings in electricity if every Wikipedia editor didnt plug in a mouse!Camelbinky (talk) 23:55, 2 October 2009 (UTC)
MSDOS? That wasn't released until 1982. Use a real operating system! I learnt to program using BASIC on CP/M, and I'm only 22... --Tango (talk) 00:00, 3 October 2009 (UTC)
Actually 1982 is probably the first year I started actually using a computer, Commodore 64; used Commodores all my life right up through Amiga 3000. Then it has been Compaq or Dell ever since. I never knew someone your age who even knew what CP/M or BASIC even meant let alone used it in real life!Camelbinky (talk) 00:22, 3 October 2009 (UTC)
I learned PC's and BASIC at the then brand-new Vista College in the early 1980's on 64k–512k Radio Shack computers that used TRS-DOS. But I didn't learn much of TRS-DOS itself. Then (since the WordStar discs had all been answered for), I learned the utterly-useless MultiMate (to replicate the Wang word processor on IBM) on Peanut (IBM PCjr) terminals without the template, thus having to memorize even-more-useless codes like Alt-Shift-7 for things like "move paragraph". —— Shakescene (talk) 00:55, 3 October 2009 (UTC)
Please note that the software would automatically promote users with 10 edits and 4 days, and only the software.
Autoconfirmed is an implicit permission, that is, I gather, the software checks if the user meets the autoconfirmed requirements (10 edits, 4 days on enwiki) whenever a restricted action is performed, and when linking restricted actions (e.g., the move tab). So it's unlike rights like Sysop, Rollbacker, etc. Not being an explicit permission has several downsides, for example it's difficult to check if the user is autoconfirmed or not (especially for non-admins who can't see deleted contributions, and even more with the edit filter, capable of removing autoconfirmed status), we don't know easily how many users are autoconfirmed, etc. However, it is now possible for the software to automatically assign a userright when certain conditions are met. This change would offer many advantages: easier to know if an account is autoconfirmed, number of autoconfirmed accounts at Special:Statistics, the list of all autoconfirmed accounts at Special:Listusers, scripts and bots can use this information, and also, automatic promotions would be logged at Special:Log/rights (and noted in recent changes), an example entry would be:
I think the removal of the autoconfirmed permission by the edit filter, and possible restorations, could also be logged. In July, the confirmed usergroup was created to allow admins to grant permissions associated to autoconfirmed before the automatic promotion, maybe we should rename this group to "preconfirmed", as confirmed alone could be unclear. If there's consensus for this change, it'll be requested at bugzilla. Cenarium (talk) 01:53, 20 September 2009 (UTC)
*Totally, completely, irrevocably, Opposed. I dont' think that there could possibly be a good reason to do this, so admittedly I'm very biased against the idea, but I don't see any real reason given above to do this now regardless. Sorry, I'm sure you're an intelligent person and a valuable editor, but this is a Bad Idea. — V = I * R (talk to Ω) 02:11, 20 September 2009 (UTC)
You seem to have misunderstood, I never proposed that admins should be allowed to grant or remove Autoconfirmed. The promotions will be done automatically by the software. It's nothing but a cosmetic change. Which disadvantage would you find over the current system ? Cenarium (talk) 02:22, 20 September 2009 (UTC)
...OK, obviously I'm completely misunderstanding the intent here. I just re-read the original post again though, and I don't see where. You bolded a statement saying that essentially nothing would change, but then the proposal still essentially talks about removing the software mechanism to assign it. I'm confused. — V = I * R (talk to Ω) 02:31, 20 September 2009 (UTC)
The software checks if the user meets the autoconfirmed requirements every time an action is made, as opposed to checking if the user is in a usergroup. It's proposed that instead, the software automatically assigns the autoconfirmed userright when the conditions are first met, so it will give us all the advantages of an (explicit) permission, but change nothing in who gets the permission. So for example, we'll have (autoconfirmed) in Special:Listusers, the number of autoconfirmed users at Special:Statistics, bots and scripts will be able to use the data, we'll know when a user is granted autoconfirmed, so vandals, disruptive users, sockpuppets aiming to become autoconfirmed may be 'exposed', etc. Cenarium (talk) 02:45, 20 September 2009 (UTC)
Ahhhhhh, got it. The thing is, this isn't really Wikipedia related (other then the fact that Wikipedia obviously runs on top of MediaWiki), which probably one reason for confusion. This seems to be a purely technical, and efficiency related, change request to me. It would change the way that Wikipedia operates slightly, but not in any really meaningful manner as far as I can tell. Just go ahead and start a bug report for it. — V = I * R (talk to Ω) 03:17, 20 September 2009 (UTC)
It's best to discuss beforehand, some may have objections on specific parts, for example logging because 'it would clog the user right log', although a filtering may be possible. Also if there's a definitive support, the developers will likely pay more attention and be more motivated (as I expect this change would require non-negligible technical work). Cenarium (talk) 03:46, 20 September 2009 (UTC)
Generally I agree, but in this case it sounds like you could make an efficiency argument. I'm not that familiar with the MediaWiki internals (or PHP, to be honest), but the way that you're describing this here it sounds as though edits are currently an O(n) operation based on number of users. I'm not positive that logging the autoconfirmed property would turn that into an O(1) op, but I can't imagine that it would do anything but improve performance (obviously the actual cost of "n" is so miniscule as to be basically negligible, but still...). — V = I * R (talk to Ω) 05:21, 20 September 2009 (UTC)
(edit conflict) Hmm... interesting. However, I see the userrights log as being just oversight to keep admins and 'crats from making improper promotions. In popups, it shows the date registered and edit count, so I can very easily see if the user is autoconfirmed. Honestly, there aren't enough not-autoconfirmed users for this to be a problem.--UnionhawkTalkE-mailReview02:13, 20 September 2009 (UTC)
See above reply. It's a problem for bots, scripts, relying or analyzing data on autoconfirmed users, etc. Popups can't see deleted versions AFIAK, and doesn't know if the edit filter has removed the autoocnfirmed status. It would be a strong benefit for anti-vandalism purposes. Cenarium (talk) 02:22, 20 September 2009 (UTC)
Also there are something like 633,500 autoconfirmed users, compared to 10,564,920 users, so there are approximately 9,931,420 users who aren't autoconfirmed, it's a lot. Cenarium (talk) 02:45, 20 September 2009 (UTC)
So how many of them have 1–9 edits? I think the criteria are too trivial for the corresponding data to be of any practical use. Unless there is also some new option to ignore certain promotion types, the user-rights log would become completely useless—being flooded by every user's 10th-edit bar mitzvah. — CharlotteWebb03:48, 20 September 2009 (UTC)
Well, they may not be logged at all then, if it can't be filtered, or maybe logged separately, but it would be useful for certain users in dealing with vandalism I'm certain. As for the data itself, it would be of use, for example see here (for scripts), and also for statistical purposes, and analyzing the population of autoconfirmed users (as of now, it's especially cumbersome). And it would also make sure the edit filter doesn't remove a userright and nobody knows about it except by directly checking the edit filter log; in the new configuration, a removal of autoconfirmed by the Edit filter would appear in the user right log. Cenarium (talk) 04:03, 20 September 2009 (UTC)
So it makes a little less than 5 million accounts with edits but not autoconfirmed, compared to circa 633,500 autoconfirmed users. The autoconfirmed threshold is not only additional permissions, but also clearance from anti-vandalism and anti-spam measures (edit filter, captcha, etc), it's important to be able to distinguish it. Cenarium (talk) 04:38, 20 September 2009 (UTC)
I totally agree, it is useful and important for a user's autoconfirmed status to be easily and reliably determinable by bots, scripts and humans. Happy‑melon10:11, 20 September 2009 (UTC)
Comment. I do not see any problem with deleted contributions. As I know they do not count to autoconfirmed status. So, if a user has 10 contributions and all of them are deleted, then the user is not autoconfirmed. Ruslik_Zero11:20, 20 September 2009 (UTC)
Brion said here that it's based on the edit count, which counts all edits performed, even if subsequently deleted (the one in Special:Preferences). It may have changed since but I don't think so, as if only non-deleted edits counted, a user could be autoconfirmed at a time, then no longer when some of the articles they edited is deleted, then again, so it wouldn't be stable. Cenarium (talk) 12:35, 20 September 2009 (UTC)
I have moved a page with this account which had only two non-deleted edits at the time, so deleted edits are included in the count. However there's the TOR issue, which makes the current autoconfirmed permission unstable, in my opinion autoconfirmed should be stable. If it's granted after 90 days and 100 edits to users when using a TOR network, it won't change very much from the current situation. Cenarium (talk) 14:47, 20 September 2009 (UTC)
Well, I was mistaken about deleted contributions. Still I think it will not be helpful if promotions to autoconfirmed status are shown in the userrights log—they will simply overwhelm it. What would be useful, however, is additional information on Special:Userrights page: if an account is autoconfirmed and when, if its autoconfirmation is suspended by an abuse edit filter. This page should also have a button allowing administrators to reautoconfirm the account. (currently this is located on Special:AbuseFilter/tools.) Ruslik_Zero18:28, 21 September 2009 (UTC)
I think the best would be to be able to hide automatic promotions, like we can hide patrols, maybe default hidden; I think it's possible if there's a specific log_action 'autopromote' for automatic promotions.
If autoconfirmed becomes a userright, it'll be shown in Special:UserRights, but we won't be able to modify it (probably best to keep using (pre)confirmed for users wishing some autoconfirmed rights before autoconfirmation, and I don't think we'd have consensus to allow admins to remove autoconfirmed). We could explain how to restore autoconfirmed when it's been suspended by the edit filter in MediaWiki:Userrights-groups-help. I don't know how the filter would remove autoconfirmed, if it suspends it like how it does now, or would remove then restore the right. It's not particularly important, though, as we don't use the action Block autopromote for now. Cenarium (talk) 17:23, 23 September 2009 (UTC)
I had a look through bugzilla and it seems we really need a consensus for this change to be completed by the devs, I'd request more comments (also on renaming confirmed to preconfirmed). Thus added to Cent. Thanks, Cenarium (talk) 23:11, 27 September 2009 (UTC)
Support Both ideas sound fine. But would it be possible to simply allow admins to grant the autoconfirmed right, if not remove it? — JakeWartenberg06:28, 28 September 2009 (UTC)
As we have the confirmed usergroup, it wouldn't be necessary. It would no longer be 'auto' too, so it could be confusing, or we would have to rename but it may be difficult, because autoconfirmed is very much embedded in the system. It would also be safer from a security viewpoint to keep the rights separate. Cenarium (talk) 12:43, 30 September 2009 (UTC)
If it's not too much trouble to add, I imagine it could be handy from time to time, specifically relating to scripts, bots, and AbuseFilter actions. Discussion above already seems to cover most issues that come to mind for me, all but one: we'd be doing this in such a way that it doesn't flood the user rights log too horribly, right? – Luna Santin (talk) 23:58, 30 September 2009 (UTC)
I'm fairly certain developers can develop a filter for autopromotions, probably using a LOG_ACTION for those, there's actually T19293 for filtering all logs by log action, and they could even hide autopromotions by default (like the patrol log); but it may take time to be finalized. Well, I think there's consensus so I'll open a bug soon for this. Cenarium (talk) 00:07, 3 October 2009 (UTC)
Hello together, are you interested in the introduction of the de:Wikipedia:WikiProjekt Metadaten (WikiProject Metadata) to en-WP? The purpose of this project to centralize often changing data (e.g. population numbers) in so calles Metadatenvorlagen (metadata templates) (e.g.: de:Vorlage:Metadaten Einwohnerzahl AT-1, see source code: [21]. By embedding these templates into articles (directly or also via infoboxes) these data are automatically updated by update of the templates. Technically the templates are based on the switch-command. Regards --Septembermorgen (talk) 11:17, 26 September 2009 (UTC)
Can someone run off a rough translation or precis it into English so us non-German-speakers know what's being discussed? The description above looks very good. Pseudomonas(talk)13:41, 26 September 2009 (UTC)
(Technically I always feel this sort of thing shouldn't be called "metadata" though - to me that would mean data about data - but the idea's great.)--Kotniski (talk) 13:55, 26 September 2009 (UTC)
I'd definitely be curious how this works. Hopefully we can get a translation because this does sound like a worthwhile task.↔NMajdan•talk16:25, 28 September 2009 (UTC)
Still in the early phases of this, but progress is being made. The template {{Meta-Population}} has been created (it might be renamed) and it has been populated with Oklahoma data. So, giving {{formatnum:{{Meta-Population|USA|OK|Tulsa}}}} now returns 385,635.—NMajdan•talk23:54, 2 October 2009 (UTC)
Radical suggestion against vandalism
Hi, i have a quite radical but very effective suggestion against the vandalism on Wikipedia. Let only registered users be able to do edits. Non-registered users like it is today stands for more than 60%-70% of the vandalism here i would guess and that would be mutch less vandalism if only users with user pages could do edits. I think i have warned like 70-80 non-registered users in the last 2-3 months not and only 2-3 registered users. English wikipedia has become to big in my opinion to have no restrictions on who gets to do edits. This suggesiton would also make it a mutch better chance that the registerated user actually wants to do good for wikipedia as most vandalisers would not take the time to register.--Judo112 (talk) 16:26, 15 September 2009 (UTC)
This is a suggestion that is made perennially. It never has passed consensus. My guess is that it never will. One argument against this sort of restriction is that, if a user is truly bent on vandalism, they would register first. Then where would we be? At least now you can be suspicious when all you see is an IP number. --Tim Sabin (talk)16:45, 15 September 2009 (UTC)
IPs are responsible for the majority of worthwhile content on this site - that bears reminding every time this comes up. Losing them would stop enWiki in its tracks. ~ Amory (user • talk • contribs)16:49, 15 September 2009 (UTC)
I would personally be interested in hearing a serious defense towards implementing this idea. I've wondered for a while now what the big deal with vandalism really is. I mean, it occurs, and it is sort of annoying, but... so what? Why is any attempt at preventing vandalism necessary? I'm not being flippant here or anything, I'm simply interested in trying to understand this viewpoint is all. — V = I * R (talk to Ω) 19:55, 15 September 2009 (UTC)
Ever worked on an article that gets lots of sneaky vandalism mixed in with good edits? Just reverting everything would frustrate the good editors, but sorting through all the intermediate edits would take inordinate time. These two common reactive strategies are less-than-ideal in such a case. Gimmetrow21:18, 15 September 2009 (UTC)
Yes, I have worked on articles that are subject to vandalism, although I suspect that what you qualify as "sneaky vandalism" is more likely to often actually be content issue(s).
I should clarify that by stating that I don't recall ever talking with you prior to this, and I'm not intentionally leveling any accusations. That statement is really a more general observation then it's written as, since in my perception editors often tend to label content disputes as vandalism, likely out of a desire to win points for their position.
You're absolutely correct that reverting a series of edits is not normally a good practice (I would say that it never is, but I'm sure that there is the rare instance where it could be warranted). This still doesn't address the question that I'm posing however: why should any of us proactively try to prevent "vandalism" at all? What is wrong with being reactive? It may be difficult to straighten out occasionally, but so what? — V = I * R (talk to Ω) 21:37, 15 September 2009 (UTC)
Are you personally volunteering to do any and all work necessary to reactively handle all vandalism on this site? Nobody has any right to be generous with other people's time cleaning up vandalism. Preventing what vandalism can be prevented in the first place would be a good thing. Gimmetrow22:03, 15 September 2009 (UTC)
I clean up vandalism all the time. I disagree with pretty much any "preventative" measures but whatever, if this is going to become some sort of emotional, personal issue, then I'd really rather just drop it. I was simply attempting to understand the other viewpoint, I wasn't trying to get yelled at. — V = I * R (talk to Ω) 22:36, 15 September 2009 (UTC)
I'm not saying the specific preventative idea here is good, but I disagree with the notion that we should never attempt any preventative measures. Gimmetrow16:19, 16 September 2009 (UTC)
This is the proverbial "rock and a hard place". Problem: IPs create 97% of vandalism. Solution: Ban unregistered IPs from editing. Problems with solution: 1) Unregistered IPs create a huge amount of good edits (I don't remember the exact figure, except that it's somewhat north of 50%), 2) Unregistered IP vandals will now register before vandalizing, thus negating any good that would be done by this exercise. Plus, we lose that 50%+ of good edits. Our position after the exercise: Backs against the wall. Frustrated editors leaving in droves. Rampant vandalism (you think it's bad now?). Reputation of Wikipedia down the tubes. Jimbo Wales would not be proud. --Tim Sabin (talk)00:21, 16 September 2009 (UTC)
That already can be, and often is, done. The process is simply not automatic, and for good reason. For any sort of automatic heuristic to really be effective would require non-trivial computing resources. A truly "automatic 24 hour ban" actually implies a completely "dumb" system that has no heuristic at all. Either way, the false positives would be a nightmare, and adding in the issue with dynamic IP's then makes the situation much worse (consider the fact that most editors behind temporarily banned IP's could simply release and require a new IP address, for one thing). — V = I * R (talk to Ω) 17:31, 16 September 2009 (UTC)
Obviously the whole ban IP editors is a perennial proposal, and there are some people who will never be convinced to do it, but there's the thing. Anonymous editors are 7842 times more likely to be vandals than logged-in users. So, why couldn't we do a one week trial where anonymous edits are turned off; just one week, and see what happens. As for "it's somewhat north of 50% above", that's not true, anons contribute only about 26.8% of non-vandalism edits. Cool3 (talk) 16:32, 16 September 2009 (UTC)
Because in doing so we would be telling 1 week's worth of anonymous editors "Your edits are no longer welcome here; go away." Good luck getting them back. Shereth16:34, 16 September 2009 (UTC)
There are several very active, very proficient editors who do not log in. That is their preference. We should not require them to create accounts. 99.166.95.142 (talk) 16:50, 21 September 2009 (UTC)
A difficulty here could be that people who are new to Wikipedia, and who may be quite sincere editors, may still be learning about how to set up userpages. After all, we should remember Wikipedia: Please do not bite the newcomers. ACEOREVIVED (talk) 20:29, 25 September 2009 (UTC) And looking back few years, I see that my earliest edits were signed by a name in red letters - "ACarl" - before I had really learnt to set up a userpage on Wikipedia.(N.B. this was not sock puppetry, since "ACarl" was never the name of a userpage, hence the red letters). This proposal would probably eliminate a lot of newcomers to the Wikipedia project. ACEOREVIVED (talk) 22:51, 2 October 2009 (UTC)
I agree with Aceorevived and Ohm's Law, both of which I believe fought with me just last week against a very similar proposal, which wanted to, among other things, make having an e-mail address mandatory for creating an account. This proposal is not just a perennial one, it is one that comes up before the previous one is even closed out and archived, and shows up at multiple discussion forums, both Village Pump (proposals) and (policy). I have a better proposal- lets ban any whose proposals are to ban IP's or make it harder to create a new account and if someone proposes such a proposal then they are banned for one week. Yes, IP's do vandalism, some of that vandalism though may not be intentional vandalism, and some of that vandalism is kids who dont know better and who may not be the main users of that IP address, to ban all users of that IP address because of one's mistakes (intentional or otherwise) is wrong. So lets ban all who propose to restrict IP's or any of these proposals to restrict newbies because by constantly proposing these proposals over and over and over they are being just as disruptive. As I stated in another discussion we have the ability to make regulations that would once and for all proactively end all vandalism, but it would make us lose all the free spirit and fun that makes Wikipedia what it is, it is not worth it; just as it is possible, by giving away our democratic freedoms, we can end practically all crime in the US (or UK, France, Australia, wherever). We dont, because it is against our ethics and the core of what makes us unique. Wikipedia was founded with certain principles and those principles have evolved, let us not devolve by enacting any of these proposals that would be, in essence, a "Patriot Act" of Wikipedia. Vandalism is not killing anyone.Camelbinky (talk) 23:48, 2 October 2009 (UTC)
Oh, and has anyone noticed that the proposer of this proposal has been labeled as a potential sockpuppet? So why are we taking this serious? Ironic that one who should be banned is proposing to ban others.Camelbinky (talk) 23:51, 2 October 2009 (UTC)
Thank you, but I do not think I contributed to that proposal myself, if it is the one I am thinking of (the one about new introductions for new editors).ACEOREVIVED (talk) 23:12, 3 October 2009 (UTC)
Oh, I did not mean "fought with me" as in "fought against me" I meant it as in with me as in on the same side of the position as me. I had thought in that other discussion you were on the same side with me, and that Ohm's Law was as well, perhaps you werent involved? I get confused easily!Camelbinky (talk) 23:21, 3 October 2009 (UTC)
Thank you for clarifying this - at first, I thought you meant "fought against" but now that you have clarified what you actually meant, I feel somewhat better! However, I am still not sure which proposal you meant - if you go to the history of this page, you may find the one. ACEOREVIVED (talk) 20:07, 4 October 2009 (UTC)