Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Princess Ava (talk | contribs) at 18:49, 2 September 2010 (→‎New criteria). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
New ideas and proposals are discussed here. Before submitting:

"Report an error" feature

Hi. During Wikimania 2010, I learnt about a feature installed in Polish an Russian Wikipedias: a link on the left sidebar to report errors. I liked it, so we installed it in Spanish. You can see how it works in this article for example (look at the left sidebar "Notificar un error"). It opens a window where the user can explains the error. Then, the error is sent to a common page es:Wikipedia:Informes de error where wikipedians read and work on them. It would be nice add it in English. The code is here: es:MediaWiki:Wikibugs.js. We are receiving tons of reports per day. This is an amazing tool to involve casual readers (which don't know how to edit a talk page, more, they don't know the about talk pages) in Wikipedia community efforts to improve the encyclopedia. Regards. emijrp (talk) 09:53, 8 August 2010 (UTC)[reply]

Yes, good idea! It could direct to the WP:Content noticeboard, perhaps? Many readers don't know that Wikipedia can be edited or know about talk pages, so this adds another opportunity for some of those many eyes to make our bugs shallow. How would we turn it on at en.wikipedia? Fences&Windows 17:53, 8 August 2010 (UTC)[reply]
Seems like you just Create MediaWiki:Wikibugs.js, copy the whole thing into it (translated into English), put this into MediaWiki:Wikibugs.css, and put the line importScript('MediaWiki:Wikibugs.js'); into common.js. You could try that by copying it into your personal .js to see if it works, and see what wording you'd want in English. Choyoołʼįįhí:Seb az86556 > haneʼ 18:02, 8 August 2010 (UTC)[reply]
Yes, also, you can create the messages MediaWiki:Bug in article (with the text "Report an error" or something like that) and MediaWiki:Bug in article-url (with the title "Wikipedia:Content noticeboard" as you suggested). Then, add it to MediaWiki:Sidebar. But first, we need more community opinions. emijrp (talk) 18:51, 8 August 2010 (UTC)[reply]
Mmm, I see that they were created in 2005 (and Wikipedia:Report an error was deleted later). Why? emijrp (talk) 18:53, 8 August 2010 (UTC)[reply]
OK, it was deleted when this system was in an very early stage (see talk). Today, it is much better. emijrp (talk) 19:00, 8 August 2010 (UTC)[reply]
Open an RfC? This probably needs good support to succeed, as it may flood the content noticeboard. Fences&Windows 22:03, 8 August 2010 (UTC)[reply]
What sort of junk/false-positive rate does it get on the other Wikipedias? --Cybercobra (talk) 23:00, 8 August 2010 (UTC)[reply]
I can say 50%/50%, but the script has filters to avoid empty reports, reports with texts with no spaces, ect. Also, we exclude the "Report an error" link in articles like "MSN", "Hotmail", ect, where many people click to say "MY HOTMAIL DOESN'T WORK, FIX IT PLIZ". I think that it can be tested here, and "invent" ways to reduce the noisy reports. emijrp (talk) 08:08, 9 August 2010 (UTC)[reply]

This seems potentially fruitful and helpful, but I can't help wondering if the link shouldn't just go to the relevant talk page (to keep relevant discussion in one place, plus educate people about talk pages), with the talk page added into a maintenance category so on low-traffic pages people will be able to find it and respond. The "edit request" system of MediaWiki:Protectedpagetext could probably be used as a model. Rd232 talk 09:40, 9 August 2010 (UTC)[reply]

We have all the messages in the same page. If a report is hard to reply and solve, it is moved to the article talk page. A lot of reports are about undetected vandalisms, so, flooding talk pages with vandalism reports is not very useful. emijrp (talk) 10:55, 9 August 2010 (UTC)[reply]
Mm, OK, if it's true that many of the errors turn out to be simple vandalism reports, and if issues better suited to the relevant talk pages are moved there, then this system would be better. Rd232 talk 16:47, 9 August 2010 (UTC)[reply]
And many talk pages have no watchers. Seeing how this is working on two other Wikipedias, I can't see that a trial would hurt. Fences&Windows 16:33, 9 August 2010 (UTC)[reply]

Support This sounds like a great idea, Sadads (talk) 16:43, 9 August 2010 (UTC)[reply]

So, do we open a RfC? emijrp (talk) 09:34, 11 August 2010 (UTC)[reply]

Support - it sounds great. Kayau Voting IS evil 09:36, 11 August 2010 (UTC)[reply]

  • Support Seems worth a try. Calliopejen1 (talk) 14:34, 13 August 2010 (UTC)[reply]
  • Support trial for maybe a month or two. If it gets flooded by abuse, get rid of it. Choyoołʼįįhí:Seb az86556 > haneʼ 22:02, 13 August 2010 (UTC)[reply]
  • Support opening an RfC on a trial run. --Cybercobra (talk) 01:34, 14 August 2010 (UTC)[reply]
  • Oppose The intentions are very good but I'm really not sure about this idea. One of the stated aims of the Foundation over the coming years is to improve participation in the projects. This means people learning how to edit Wikipedia in the main. This proposal presents the user with a kind of shortcut to get content changed. Shouldn't we be pushing for our visitors to change the content themselves? I think I would much prefer to see such a "report an error" link take the user to a "You can edit!" page and give some very basic details as to how the user can make the change themselves. This proposal would set up a barrier between readers and editors; it encourages the notion that there are "some people, like staff" who edit Wikipedia when we should be encouraging the notion that readers are editors too. So I'm against this. --bodnotbod (talk) 10:09, 16 August 2010 (UTC)[reply]
    • That's a valid point, and it's good to be aware of it. But being aware of it, we can address it with eg a good editintro, pointing people (before posting) to the possibility of fixing things themselves, especially if it's simple. And of course make it clear if they do post that it's volunteers answering (WP:HELPDESK already does this I think). Good point, but not a blocking bug. Rd232 talk 10:23, 16 August 2010 (UTC)[reply]
    • We have zillions introduction tutorials and help pages. If a person doesn't want to learn or can't learn to edit, he won't do it. Also, the "Report an error" feature first screen shows some links to Wikipedia:Be bold and it encourages fix them. People can report errors or send pics via e-mail too, are you going to remove e-mail from the Internet? : ) emijrp (talk) 10:52, 16 August 2010 (UTC)[reply]
    • Have you poked around in the spanish wikipedia, where it is in place? When you click the button, there is a pop-up explaining how to be bold, etc: "Si has encontrado un error, por favor, intenta arreglarlo tú mismo, la tecnología wiki permite que cualquiera pueda editar artículos. No dudes en hacerlo, una de las reglas de Wikipedia dice «¡sé valiente editando páginas!». Si no puedes o no sabes arreglar el error, entonces infórmanos de él usando este formulario." -> "If you have found an error, please try and fix it yourself: wiki technology makes it so anyone can edit articles. Don't hesitate - one of Wikipedia's rules is "be bold!". If you can't or don't know how to fix the error, then let us know using this form." And then there are three buttons: edit the article yourself, report an error, or cancel. This actually might make people more rather than less likely to fix mistakes themselves. Calliopejen1 (talk) 17:32, 17 August 2010 (UTC)[reply]
      • That sounds good. I would rather have a text like the above explaining to be bold, and fix it themselves, then a button to take them to the edit page, and even further down a pair of buttons to fill out an error form (which posts it on both a noticeboard and the talkpage? Or posts it on the talkpage, and puts a link on a noticeboard?), and a cancel button. Martijn Hoekstra (talk) 17:41, 17 August 2010 (UTC)[reply]
    • Bodnotbod -- Personally, I think that the more high quality article we have, the more likely people are to get interested in Wikipedia, and decide to contribute. So in my opinion, anything that provides a "shortcut" to improving the articles is a good thing, and will draw in more editors than forcing people to learn how to edit before they can contribute. Perhaps, to address your concern, we could include a link that says something equivalent to "Want to learn how to fix this sort of problem yourself?" which would take them to the edit page ... Anyhow, I don't see your issue as a very convincing reason to prevent this from being developed. -- Jrtayloriv (talk) 05:05, 31 August 2010 (UTC)[reply]
  • Strong support directly or via a trial. This is one of those "I can't BELIEVE we haven't thought of this before!" forehead-slapping features that should already have been in WP by now. Zunaid 18:16, 17 August 2010 (UTC)[reply]
  • Strong support With an appropriate intro, this can only increase readership participation. Randomblue (talk) 15:18, 20 August 2010 (UTC)[reply]
  • Support -- Excellent idea, which will enable an enormous number of currently uninvolved readers to contribute. -- Jrtayloriv (talk) 05:05, 31 August 2010 (UTC)[reply]
This proposal has got a wide support. Can anyone be bold and run a one-week test? You can follow the instructions available in the third and fourth messages in this thread. I can help if needed. Thanks. emijrp (talk) 15:22, 20 August 2010 (UTC)[reply]

Update: I've gone ahead and done most of the work, and left a message at MediaWiki_talk:Common.js#WikiBugs asking for someone to do the final step of putting it live. Rd232 talk 08:52, 26 August 2010 (UTC)[reply]

Thanks a lot Rd232. Some details:
Regards. emijrp (talk) 11:05, 26 August 2010 (UTC)[reply]
OK, fixed now - thanks for the proofreading (always better to have someone doublecheck!). Rd232 talk 11:13, 26 August 2010 (UTC)[reply]
I like it, it's just that...doesn't it take away the point of tutorials, FAQs, etc? --When Chuck Norris takes a step, all humanity dies and gets reborn again Mr. High School Student 13:47, 28 August 2010 (UTC)[reply]

If the report is put on the problem article's talk page, the system can automatically add a template Template:Error reported which'll put the talk page in the category Category:Error reported. That way fixers can check the category, it won't flood any boards, it's in the right place from the start, and makes it easier to see an article's history of errors reported by people scared of reading the HowTos. Since fixers would've had to edit the thread on the board anyway to say it's been fixed so that someone else doesn't think they still need to fix it, they'll now just edit the talk page and remove the template or change it to Template:Error fixed. -- Jeandré, 2010-08-28t15:13z

Random Article - filter out the ugliest ducklings

I've used Wikipedia for several years, as an encyclopedia, and only recently got into editing. Seems to me the Random Article button is, or ought to be, primarily for non-editors, ppl who simply want to browse wiki as an encyclopedia, and not an editor's playground. The Random Article button throws up everything, from the best to the atrociously worst, which probably inclines most casual visitors to view Wikipedia as a "work in progress" - i.e. not yet up to snuff and therefore unreliable. Unworked articles negate the promotional quality of the Featured Article to some extent.

How easy would it be to rename it as Random Edit - and then create a new Random Article button - for ppl who just want to read reasonable content, that filters out unworked articles/orphans/stubs. Seems simple enuf - one button for encyclopedia users - another for editors

Hope this is of interest. Markdask (talk) 03:57, 16 August 2010 (UTC)[reply]

I agree that the random article link isn't my favourite feature. I hadn't thought about this before, but your comment makes me wonder whether it would be better - from the point of view of the more casual visitor, rather than devoted editors - to use some combination of random good article and random featured article, both of which links that I only discovered through a mailing list and are currently services provided by the tools server. I think it is well worth discussing whether we should provide these links as part of the main interface. Random article really has two main audiences; devoted editors and casual readers. I don't think the current set-up really caters for both. --bodnotbod (talk) 09:35, 16 August 2010 (UTC)[reply]
Thank you Bod - and those two links are inaccessible to the general public for whom, presumably, Wikipedia exists. I have also posted to village pump (technical) on the subject, cos they are the people who can implement such changes. I have also registered it as a bug on Bugzilla so hopefully someone will come up with a more enduser friendly form of randomisation on the main page.
Thanks again - Markdask (talk) 18:43, 16 August 2010 (UTC)[reply]
FYI I've merged both threads. –xenotalk 18:54, 16 August 2010 (UTC) As a complete aside, a single comment should all go under the same indent level, if you indent your final commentary and signature further than the comment above it, the one above looks unsigned.[reply]
Thanks Xeno - takes a while to gt the hang of it - Markdask (talk) 09:36, 17 August 2010 (UTC)[reply]
But Wikipedia really is a work in progress, and it really is to a large extent unreliable; if we allow our readers to forget that, they may use the information in our articles uncritically and without paying attention for possible misinformation, wilful or accidental. In any case, it often happens that a reader turns into an editor by finding a low-quality article on a subject they know about—indeed, that's how we've got most of our editors. The "random article" button, as much as links, facilitates this process and thus aids the improvement of Wikipedia. Waltham, The Duke of 11:00, 16 August 2010 (UTC)[reply]
A very good argument Waltham - that was precisely how I myself became interested in editing, but I wasn't suggesting an all or nothing - I only mean to suggest that filtering the least worked, tatty, "in need of rewriting" might lessen the likely negative impact to the impression formed by the casual visitor. I think there should be more emphasis on the end product - the finished meal - and less on the sometimes chaotic preparation thereof. I would hope others will give my suggestion some further thought.
Thanks for your comment - Markdask (talk) 18:24, 16 August 2010 (UTC)[reply]
You are welcome, Markdask. I do appreciate proposals such as this, as they will have us discuss things we take for granted, and perhaps help us learn a few things along the way. However, I remain unconvinced in this case. The practical objection is that any filtering would be fairly arbitrary and ineffective. I can only think of two ways to do it: a plain character count or a system based on quality assessments. The former would exclude pages based on size rather than quality, on one hand excluding many brief but essentially sound articles waiting for someone to expand them, and on the other hand leaving in many long but rambling articles. Working with quality assessments might be more effective, but not all articles are assessed, and there is the added danger that, rather than giving editors an incentive to expand stubs, it will encourage them to fraudulently upgrade the assessment so that the stubs will not be excluded from the "random article" button. Granted, this may be a stretch, but the purpose of quality classes is to aid editors, and not to affect the readers' experience; I'd hate to see this change.
All that said, I still believe that we ought to maintain the status quo even if we could somehow overcome these technical obstacles. I believe a visitor is most likely to arrive at Wikipedia through either the Main Page or an article found as a search result on Google. The Main Page showcases one of the best articles and images we have to offer every day, as well as new little gems ("Did you know"), articles which have received much attention due to their subjects' being in the news, and articles that may not be special but do not have any major problems, either ("On this day"). I fancy that any visitor who doesn't already know about Wikipedia (given that the management of first impressions seem to be the primary motive behind your proposal) would either arrive directly at the Main Page or choose to go there from any article they might have seen first (rather than click on "random article"). Apart from the fact that we don't hide what Wikipedia is like, I hope and believe that visitors are more likely to see the better side of the project before any samples of the abysmal depths to which we sometimes sink. Waltham, The Duke of 22:13, 17 August 2010 (UTC)[reply]
To extend my argument, there is a link to the Featured content portal just two lines above the "random article" link. I consider it a good counter-weight, and I imagine that readers looking for something interesting and informative to read might think of checking what is there. As an added bonus, the examples given in the portal are generated randomly. Waltham, The Duke of 22:29, 17 August 2010 (UTC)[reply]
Wow Waltham, a lot to digest in the above, and thank you for so considered a response. I need to refine my argument/proposal extensively and, if you can bear further comment from me on the matter I will get back. MarkDask 03:28, 18 August 2010 (UTC)[reply]
Hit me with what you have, Markdask; I cannot exclude the small possibility that I'll be pleasantly surprised by a revised proposal which I can support (I'm afraid I have no ideas of my own on the matter). But I can say with some certainty that it will count in your favour not to refer to me as a disambiguation page. :-) Waltham, The Duke of 16:25, 18 August 2010 (UTC)[reply]
Oops sry Waltham, I did not intentionally refer to you as a disam.page. I am rather green with the markup, didn't even realise double sq brackets did that. I was highlighting your name as a courtesy, just as, in my response to his comments, below, I reproduced Intelligentsium's name as he writes it. I assumed such highlighting redirected to your user page.
As for the revision, I hope to pleasantly surprise you shortly :)
As an aside - the three words anyone can edit on the main page are perhaps the first portal the aspiring editor should go to - and yet they are lost in a sentence beneath the large Welcome print above. Could not those words be accentuated more? MarkDask03:08, 20 August 2010 (UTC)[reply]
  • I've merged in a reply from the same thread at WP:VPT. It's probably technically possible to redesign the Random article button, what is needed is consensus as to whether it should be done (so I believe it's best suited here, at proposals). –xenotalk 18:52, 16 August 2010 (UTC)[reply]
Agreed. I had posted on (technical) because EncMstr (talk) had said my proposal involved technical changes that needed addressing by the developers. Thanks for merging - Markdask (talk) 09:36, 17 August 2010 (UTC)[reply]
Whilst we editors are normally not supposed to worry about server performance, I think it is a valid issue here. Special:Random is visited about 10 million times per day. Even a slight increase in the server resources needed to generate the Random Page could be magnified many times. Although I don't know how large an effect this would have on overall performance (it might only increase random page load times), it has already been proposed before here and rejected. Another issue that has come up is that some users do use it to find overlooked articles in need of improvement, including a Random page patrol. (As an aside, your bug is probably a duplicate of the one I linked.) Intelligentsium 19:00, 16 August 2010 (UTC)[reply]
You raise three points here Intelligentsium. I'll treat each point as a seperate comment for ease of reading. Firstly, of course server performance is important - I aint unaware of the fact - which is why I addressed the proposal to the (technical) section, but there might be a great deal gained. What I propose involves virtually no change to the existing Random Artical button beyond replacing the word Article with Edit - so no server performance issue there. Then duplicate the top end of the script as a standalone search option, labeled Random Article as before, but with a tiny amount of script added in the search criteria that excludes articles with certain key admin words at the top, e.g "multiple issues", "stub" or "rewriting". The filter script would be written in, just before the search generates the random article number. The filter would create an excluded article numbers database that then governs the random article number eventually generated. I imagine the filter would add milliseconds to each search and any "slowing down" due to the filter would be impossible for the casual visitor to detect. Also, creating two seperate Random buttons aint gonna double actual user volume, simply seperate out casual visitors from "wee editors". In fact the volume of traffic would decrease as casual users would score more worthwhile hits and therefore need to search less. I hope that lot makes sense to the (technical) intelligentsia. Second point follows - Markdask (talk) 09:36, 17 August 2010 (UTC)[reply]
Secondly Intelligentsium, Just because someone else has proposed a similar change before dont necessarily mean the issue ought never be reconsidered, therefore please recline from the urge to throw my baby out with someone else's bathwater lol. More specifically, the here link is not the same proposal, merely refers to the same issue. That proposal is to censor content in Random search, which was bound to fail, whereas my proposal is simply to seperate out that content already deemed to have met Wiki standards from that content which patently has not, both categories still directly accessible but under two different headings - Random Article and Random Editing, therefore my bug is not a duplicate of the one you linked. My purpose here is not to censor but to enhance. - (breathe) - Markdask (talk) 12:51, 17 August 2010 (UTC)[reply]
Thirdly, "some users - overlooked articles" - you mean editors looking for overlooked articles - I think that more or less makes my point - filter out the "overlooked articles" so casual visitors to wikipedia don't have to keep tripping over them, and then the existing Random Article button, renamed Random Edit, remains for "some users" to go hunting for overlooked articles. I like the term "overlooked articles" - they are precisely what need to be overlooked by a more enduser-friendly Random Article button. Thanks for your comments Intelligentsium - Markdask (talk) 09:36, 17 August 2010 (UTC)[reply]
Perhaps Bodnotbod (above) has the right idea - just move the random good article button from the editorial tools section to the mainpage, for non editors to access, although "good article" implies there are bad articles; perhaps just rename it Random Article, then rename the existing as Random editing,either way 2 Random buttons on main page - one for casual users and the other for editors. Further comments much appreciated. Markdask (talk) 12:51, 17 August 2010 (UTC)[reply]
  • I am of the opinion that something needs to get done with the random article button, how many times does a one sentence French commune come up when you press it? :-). I think it should show the casual reader what we have to offer, maybe not just featured articles as maybe they would frighten a new user who might not be competent with our many rules and regulations. Mo ainm~Talk 16:32, 18 August 2010 (UTC)[reply]
This aint exactly an argument in favour Mo ainm - the chances of getting the same article twice - ever - are infinitismally low - and the French commune is of at least novelty interest. It would be a mistake to conflate the argument for a filter with the terrifying idea of limiting the scope of wikimagic. I am suggesting filtering the more editorially challenging articles from the "shop window" of Random Article to minimise two potentially adverse influences, those being (a) giving the casual wikiuser the impression that wikipedia is amateurish and (b) that editing on wikipedia is simply a waste of time, like tossing a coin into a bottomless pit of dross. But your sentiment is bang on the money. Please keep talking :) MarkDask
As an aside, your name, Mo ainm, Gaelic for "my name" - that's priceless :)MarkDask
  • (edit conflict) The way I'm seeing this, the basic principle (removing the worst articles from the Random button) is an attractive one. But the specifics are difficult. Excluding stubs or basing what to avoid on the quality assessment both have pitfalls which The Duke of Waltham has explained excellently, and using the Random Good Article button would reduce the number of targets to a tiny proportion of the total. So how about this: filter out any article with an {{unsourced}} or {{BLP unsourced}} template on it (including other variations of each, of course)? This would limit the selection to articles with sources, which immediately solves one problem, without removing the thousands of reasonable-but-not-yet-Good articles. I don't how technically possible this is (one for WP:VPT perhaps) but it could be worth looking in to. Alzarian16 (talk) 16:37, 18 August 2010 (UTC)[reply]
Your filtering criteria are better than anything I have been able to come up with, and you are also right about it being a matter of specifics, pretty much as Waltham suggested, and I would hope we can leave the technicalities to Intelligentsium in the technical department,and couldn't the admin department who, presumably, decide matters of BLP and Copyright integrity come up with like a tag that they write in - like a codeword applied to each article to be temporarily filtered? Thank you for contributing Alzarian16. MarkDask
To clarify, I am not a programmer or developer and do not have the technical expertise to actually code any of the suggestions outlined; I was only pointing to and summarizing past concerns over this proposal. If server lag is not an issue and we could have a separate link for editors patrolling random pages, then I might be in support of such a proposal (though I suggest we change the name of the link for common readers from "Random article" to something that conveys the article should be of good quality and/or that would attract the interest of readers, such as "Read an article" or "Suggested reading"). (As an aside, it's not necessary to copy my signature; my plain text username "Intelligentsium" or a link to my userpage is sufficient to refer to me) Intelligentsium 23:16, 25 August 2010 (UTC)[reply]

Using the toolserver to deliver all random pages is not a technically acceptable solution. (The toolserver would be totally swamped.) Some sort of filtering might be introduced to Mediawiki itself if there is clear backing for some specific proposal. Dragons flight (talk) 17:44, 18 August 2010 (UTC)[reply]

Okay yes toolserver is a dedicated portal so not an option - so why involve Mediawiki - which is itself subject/forum specific. Can you elabourate please? MarkDask
Mediawiki is the name of the software that runs Wikipedia. Dragons flight (talk) 08:31, 20 August 2010 (UTC)[reply]
Well now then, Mediawiki don't sound like a software, but at least now nobody can say I'm an experienced Wikiperson so my concerns re the aspiring editor are hot off the keyboard. Thanks for the info. MarkDask
I don't see a great use for "random article", but removing any feature from a user interface because you don't see the use for it is always a recipe for trouble. Add a button or even a pull-down mini-menu if you feel you must, but don't remove features. Wnt (talk) 12:55, 19 August 2010 (UTC)[reply]
Nobody that I'm aware of was suggesting removing the Random Article button - the word removal is no part of this discussion MarkDask
Lots of editors use it to do "Random article patrolling", e.g. Wikipedia:Random page patrol. I've found quite a few articles to improve, fix, or delete by hitting "Random article", and it can while away some time finding what we've got hidden out there (even if stubs of places are overrepresented). Fences&Windows 00:11, 20 August 2010 (UTC)[reply]
So maybe you would agree to rename the Random Article button as Random Edit, and a new button for ppl who don't want to keep bumping into articles in need of life-saving levels of editing :) MarkDask
I sympathise with these points and remain unconvinced that the "random article" button should be replaced. However, I like Alzarian's proposal about excluding articles with major problems, based on their amboxes, which would have the additional benefit that any articles with the same problems but undeclared (i.e., no amboxes) could be tagged as soon as identified. If we do proceed with this at some point, I support this exclusion criterion (at least in principle). Waltham, The Duke of 09:17, 20 August 2010 (UTC)[reply]
The dual button to "replace" the Random Article button was a suggestion, but the concept of a filter to the Random Article was the initial proposal. Do I understand you correctly, that you now support the idea, at least in principle, of a filter to the Random Article button? I must say I am pleasantly surprised. I agree it should be the admin bods who define the criteria for the filter since they apply the amboxes. I suggested earlier that the admin ppl might create a code word they could write into their contribs to simplify the job for the technical ppl. Would that make sense? Mark Dask
I'd favor one minor tweak, which is to require that an article be at least two weeks old to come up as a random article. This will eliminate most articles that have drawn a quick prod or deletion discussion. Alternately, we could prevent articles that are actually nominated for deletion from coming up. Other than that, I see no problem with short articles or stubs coming up, as they are representative of our content. bd2412 T 13:15, 20 August 2010 (UTC)[reply]
Agreed - although the two weeks should be as long as the admin ppl reckon it takes for a new article to be assessed. Nominated for deletion is another good criterion, and yeah stubs should not be filtered as they aint necessarily flawed as articles in themselves. Thanks for contributing MarkDask
I suppose I could have been clearer about this, but here it goes: I do not currently support changing anything, because I have not seen any full proposals that I consider acceptable, but if we were to change something, I might support adding a second "random article" button—so that one of the two would still fulfil the function of the present button—and I'd prefer the filtering criteria of the other button to be as outlined above. The "in principle" was intended to be interpreted as "broadly", because the details would still have to be hammered out regarding the precise filters. As you can see, I still need much persuading; I am a bit conservative with regards to interface changes.
On bd2412's proposals, I don't see excluding articles nominated for deletion as a priority (there's a big red box at the top showing that the article may not be there after a few days), although if we were to be consistent we'd probably have to include this in the quality criteria. The two-week delay sounds like a good idea, though it adds an extra layer of complexity which makes me a bit uncomfortable.
To be perfectly clear this time: I am trying to make constructive suggestions, but all this is still conjecture for me. Waltham, The Duke of 16:17, 20 August 2010 (UTC)[reply]
Okay Waltham I'm going to invest 5 hours, (over 5 days, described below) objectively scanning Random pages and see what percentages of the various categories show up. Then I'll try and bring together the various suggestions on this page into a more structured proposal. I did some data analysis for a psychology degree so it will hopefully be of some worth. MarkDask
  • Just out of curiosity I continued to press the random article button till I got what could be described as an article and after another 14 presses I got this Gary Stevens, so 19 times I had to press to get something that resembled an article. Mo ainm~Talk 18:34, 20 August 2010 (UTC)[reply]
Aah some first hand research. I think it might be worth my time spending one hour per day for 5 days random clicking. I'll name and list every page I find under certain headings like (a)Place, (b)town, (c)person,(d)science, (e)art, and the other categories listed on the Welcome banner. Then I'll grade them 1 - 10 based on their fitness as articles, based on admin comments or their absence. Then I'll upload the overall to my talkpage. I have some experience with data collection and analysis. On that basis it might be easier to suggest what is or is not worth filtering. Of course this would be a much more worthwhile exercise if someone were to replicate it. Would you be interested Mo ainm? I can draft the actual sheet with tickboxes etc and I can just email it to whoever wants to give it a go :) MarkDask
I'm afraid I have no time to assist with this collection of data, but it certainly looks like an interesting experiment. The rating sounds a bit subjective, but it might be better than a list of maintenance templates found in the articles.
PS: Your last few signatures seem to lack time-stamps, Markdask. This could be the result of your using three rather than four tildes; if not, then I have no idea what it is. Waltham, The Duke of 21:37, 22 August 2010 (UTC)[reply]
I will work on the subjectivity and yes its the 4th tilde - ty for pointing that out - MarkDask 22:57, 25 August 2010 (UTC)[reply]
Hmmm, so I've been reading this discussion and I've come to realize, what about the Random Edit button, if we do make it, having two functions-----1) Random Stub-----2) Random Edit-----This way we can choose whether we WANT or DON'T WANT to see a stub, after all, half the point of editing is taking OUT those stubs, right?--When Chuck Norris takes a step, all humanity dies and gets reborn again Mr. High School Student 23:50, 26 August 2010 (UTC)[reply]
I understand what you mean Mr. but that is a secondary proposal to mine about the existing Random article button. Lets get the Random Edit button first yes? Mark Dask 02:51, 27 August 2010 (UTC)[reply]
As an aside - I read your page Mr. - it seems you were permanently banned on your last account, but you sound like an intelligent and well-intended guy so thanks for contributing. MarkDask 02:55, 27 August 2010 (UTC)[reply]
If the articles that the Random Article tool returns are somehow embarassing, the solution is to do something about the articles (improve them or remove them), not to simply hide them from the public by making the random article link not actually random. This is why {{NOINDEX}} doesn't work on articles. If we don't want people to see something in mainspace, it simply shouldn't be in mainspace. Mr.Z-man 04:16, 27 August 2010 (UTC)[reply]
Embarrassing??? You misread me - or I failed dismally to make my point. Casual users aint necessarily interested in editing. My proposal has one focus only - to make the casual users' experience more fruitful. If I want to read a random article I want to read about that specific random subject - not be thrown headlong into the chop shop that is editing - nothing to hide - just seperate the chop shop of editing from actual content - informational content. AND THAT IS POSSIBLE. This does not mean that Random Article should be uneditable, just needing a little makeup as opposed to open heart surgery. I will elabourate when I have fully swallowed your misapprehension but for now, we should want for mainspace to show a body of work - not body parts okay? Two buttons - one for casual user and the 2nd for editors. MarkDask 00:24, 28 August 2010 (UTC)[reply]
Well, to be fair, the whole concept of Wikipedia basically revolves around the casual reader seeing an edit he/she could make, and making it. Wikipedia is a work in progress, after all. But I agree that adding two random article features, one to find an article where one can read about an interesting and well-written topic, and one to find an actual random article that may or may not need substantial improvement, would be a good idea (assuming this does not slow the entire wiki down appreciably/there are no other technical concerns), as I noted in my response above. Intelligentsium 01:24, 28 August 2010 (UTC)[reply]
Thank you Intelligentsium for putting my proposal in clearer terms than I have been able to do thus far. I would want to add one refinement to your comments nonetheless. Where you say well-written topic- it should still be editable, in keeping with core Wiki principle. I am currently running a test sampling of Random Article, graciously being replicated by Mo ainm~Talk, on the basis of which I hope to establish criteria with which to address the tech ppl. But I thought you were a techy. Can you reccommend someone who might advise me on how my proposed 2nd button might stress the system? Much obliged MarkDask 11:32, 28 August 2010 (UTC)[reply]
Every article should be ready for the general public from the very first edit. This is why we have CSD, to quickly remove articles that don't meet basic standards. If short or low-quality articles aren't actual content then they shouldn't be in mainspace at all. Mr.Z-man 03:54, 28 August 2010 (UTC)[reply]
Every loaf of bread should look like bread - and not dough - when you go to buy bread. - the average wiki user wants to read stuff - not repair stuff - thanks MarkDask 11:49, 28 August 2010 (UTC)[reply]
Again, if an article is totally devoid of any useful content, it shouldn't be in mainspace. If it isn't, then a reader may actually want to see it. You may not be especially interested in French villages or Israeli football players, but that doesn't mean no one is. Mr.Z-man 15:42, 28 August 2010 (UTC)[reply]
French villages and Israeli footballers are all valuable articles, I have in mind the syntactically terminal and the grammatically grave. MarkDask 19:24, 28 August 2010 (UTC)[reply]
So what articles would actually be excluded then? A program cannot determine article quality on its own, it would need to work from some metric or category. Mr.Z-man 19:35, 28 August 2010 (UTC)[reply]
Well, at least I know I have someone on my side (Intelligensuim thank you), but yes, we should probably get the random button to crop out what we want first, like you said Mark, then see if the two options are possible without slowing down the wikipedia server, but I imagine it can't since, if we program the system correctly, the server can pre-determine which of the articles are stubs and which are not, hopefully causing no extra lag rather than trying to get it to determine it in real time.The only problem with that is that since stubs and non-stubs are made everyday, an admin would have to run a scan of Wikipedia every few days, but that's manageable I think. And if all the admins are (although I really don't think every one will do so at all) just too lazy to do it, then give the programming to me or another editor if you don't trust me, and I'll try to run the program through C++ (If that's possible, what DO you guys use anyway). And yes, before you SAY IT, I know how long it would probably take to scan Wikipedia. --When Chuck Norris takes a step, all humanity dies and gets reborn again Mr. High School Student 10:38, 28 August 2010 (UTC)[reply]
I dont see why two buttons should slow the system significantly but I'm hoping to speak with a technician shortly to get an answer. As for admin ppl having to scan the system - that already happens automatically when new articles are labeled initially as being, e.g., needs expansion. I am saying that some of those comments should include a marker of some type that excludes the article number from the Random Article counter that runs automatically when u click the button. - It doesn't help to suggest that any admin is lazy. To get an idea of what these guys use as software - check out EncMstr's page MarkDask 19:24, 28 August 2010 (UTC)[reply]
...Well, crap, there goes my chance at semi-admin abilities. I thought the admins did it themselves (they have the manpower to do it without an auto system anyway), but I guess that failed. Wikipedia has a bunch of stuff on it already, an extra button shouldn't slow down the server, so I have to take that back too >,>. However, as a side note, we should also consider unreferenced articles as stubs too, just putting that out there. Well, I'm gonna go and experiment with this programming system, see if I can get anywhere.--Mr. High School Student 01:41, 30 August 2010 (UTC)[reply]
I'm that Middle Eastern Junior at my school that is known as the greatest nerd in my grade (3rd overall), but is gladly pround of it, knows his science, math, programming, and is one of the last ones in the upper school that still games. And because I'm Pakistani I'm picked on DOUBLE than anybody like me. However, my real tragic flaw is English: I have all A's (plus they're all honors with 1 AP) except in English (77...I know, I'm trying to improve but I can't. It's kind of sad really, I'm getting this grade in CP English. So I think you wouldn't help, I'll get better eventually. Anyway, back to the TOPIC, what's your take on what I ACTUALLY SAID?--When Chuck Norris takes a step, all humanity dies and gets reborn again Mr. High School Student 13:11, 28 August 2010 (UTC)[reply]
I've withdrawn that comment Mr High - your English is perfectly fine - its the Chuck Norris thing that fails you, distracting as a punchline :) MarkDask 19:24, 28 August 2010 (UTC)[reply]
Sorry if I overreacted ,_,', I'm just more...sensitive at times. Back to topic now FOR SURE.


  • Oppose changing the random article functionality. Support adding a "Random Good Article" button that chooses only from GA/FA. I like to use the random functionality to find articles to improve, so I definitely would not like it to be filtered. We want more people to see our ugly ducklings, not less. However a feature to give a sample of the best would be nice too. --Cyclopiatalk 11:38, 28 August 2010 (UTC)[reply]
Describe it as you will - the destinction is all - MarkDask 12:15, 28 August 2010 (UTC)[reply]
  • If we are going to call it random article then that's what it should be. I quite like the idea of enabling readers to choose to hit a different button that picks random articles of at least a certain level of quality. But if we skew the random article button to tend to show our better articles we will eventually be castigated for trying to give a false impression of our article quality. Incidentally this is something that would really benefit from statistics, what proportion of those ten million random article hits are followed up by an edit to that article and how does that compare with our sucess at turning other casual readers into editors?ϢereSpielChequers 14:27, 28 August 2010 (UTC)[reply]
As Pontillist describes below - there are a percentage of articles that should be recognised as having died a natural death. When an article is plastered with multiple issues tags, by all means leave the corpse lying around to stink the place out but at least there should now be a tag that admins can apply that automatically excludes dead articles from the casual user experience. That aint likely to be interpreted as skewing the Random Article concept - thats just cleaning house. Random Article should be about articles with at least the ghost of a chance of surviving. The analysis you propose might be possible to work into what I proposed earlier by entering last edit date as one of the criteria. - I can do that but that level of number crunching would need better skills than I possess - and how would one quantify casual readers who opt to edit? MarkDask 00:00, 30 August 2010 (UTC)[reply]
Quite the opposite. The "Random Article" feature can help give these articles visibility, and therefore a chance for improvement. Multiple issues tags mean exactly that the article has to be improved. If we really must skew the RA feature, I'd give priority to visualize more of the problematic articles. We are a work in progress, and we shouldn't be ashamed of that: we should encourage people to work on our problematic articles. --Cyclopiatalk 00:33, 30 August 2010 (UTC)[reply]
Thanks for the quick response. So you think the casual user should be thrown in at the deep end. RA should remain editable of course, thus encouraging new editors, but would they not have more choice with a second - RE button for those who want to get straight into the tough stuff. We should not be ashamed of any article - but neither would it hurt to have two levels of editing available to the prospective editor. It takes time to learn the markup - daunting if you jump in with both feet. I note you are a member of AIW and I appreciate the principles.MarkDask 00:46, 30 August 2010 (UTC)[reply]
Statistics like that are incredibly difficult to interpret, bearing in mind that edits from IP addresses include contributions from registered editors who aren't logged in. For logged-in editors, of course random article should be random because it's a good way to find areas for improvement or deletion. I just clicked it and found an unreferenced article where the last actual edit was May 2007 and everything since then has been a tag (Wikify @ Feb 2008, Prose and Unreferenced @ Nov 2008, Orphan @ April 2010). I can't see how that sort of stub is helpful to inexperienced readers, even if it is plastered with multiple issues tags, so I think that if you aren't logged in either (a) random article should point to known good stuff or (b) the button should be replaced with a "best of Wikipedia" link to a randomly selected FA or GA. - Pointillist (talk) 20:52, 28 August 2010 (UTC)[reply]
This sounds like we're getting off the point a bit - would it not be simpler to think in terms of any article with three tags is flagged for exclusion from the Random Article button, while Random Edit button is ALL inclusive, even the dead ducks. Perhaps this is too simplistic but it can hardly be that difficult for the techies to come up with a patch in the search process that simply skates over any article showing three tags. 2 buttons, Random Article and Random Edit, or one could choose Cyclopia's options of Random Article and Random Good Article. It should be for the admin ppl to elect the criteria for exclusion, and most of the above contributors seem to favour the concept in one form or another. MarkDask 00:00, 30 August 2010 (UTC)[reply]
Well, that's my argument in a nutshell, except one thing. As you said we should have the Random Article button to take out stubs (and non-referenced) articles out of the picture, but the flaw I see, as I've ALSO said this earlier, making the Random Article button have a part of Wikipedia, while the Random Edit button have ALL of it. This would make it possible that you can get the same article result from both buttons, and that would take away some of the point of two separate buttons, no?--Mr. High School Student 01:41, 30 August 2010 (UTC)[reply]
Some stubs and unreffed can be well-written so I dont support filtering them. What I think need filtering are the badly written articles with admin tags like multiple issues, but only the really bad, - as in the title of this proposal, the ugliest ducklings. As for same articles possible in both buttons, - the whole point here is to afford the casual user two levels of editing options - the first, RA, invites the casual user to edit on a relatively easy level, while the RE button is anything possible. I consider that the worst articles are off-putting to the prospective editor. MarkDask 02:59, 30 August 2010 (UTC)[reply]

It completely escapes me why should we want to filter out "bad" (i.e. tagged) articles. We're an open project, we do not hide what's bad under the carpet. If we want to put a button under the FA of the day with "Go to a random FA", that's fine with me, but it has nothing to do with the random article thing. --Cyclopiatalk 13:37, 30 August 2010 (UTC)[reply]

I have never meant to suggest that (ALL) tagged articles should be filtered out – that would be plain daft. Most tags are constructive suggestions for further editing – most ducklings are kinda cute. Random Article should refer to articles which more or less meet wiki standards, whether or not they have one or two tags that offer guidance for improvement.
Where an article has, say, three tags however, suggests that it does not much meet with Wikipedia standards and ought therefore be placed in a separate category – Random Edit – where all articles are randomly accessible, thereby offering the user two different levels for editing, and simultaneously tidying up casual user use. The term Filter out has censorial connotations and I regret using it. Better if I had initially used something like Split edit level by number of tags, but the argument still stands.
As for your Random FA button, there is already a link to more FA beneath, which is duplicated by, identical to, the Featured Content button at top, and now you wanna randomize FA as well? I don’t think so. MarkDask 05:10, 31 August 2010 (UTC)[reply]

Species bot

I would like get the community opinion on this bot approval request to create approx. 10,000 Gastropods species and genera articles based on data downloaded from the WoRMS database. The articles will be created after each family is approved by the Gastropods project. Alvania and Alvania angularis are two sample articles that the bot created. Thanks in advance for your feedback. — Ganeshk (talk) 02:36, 19 August 2010 (UTC)[reply]

Awesome. bd2412 T 14:08, 19 August 2010 (UTC)[reply]
Very, very cool, might want to get help from similar species projects and figure out a way to get that stuff on WikiSpecies, Sadads (talk) 14:26, 19 August 2010 (UTC)[reply]
Not sure about the Description and Distribution sections in Alvania angularis, each flagged {{Empty section}}. The WoRMs record does actually contain distribution details: "European waters (ERMS scope)", with a popup reference and a link to the VLIZ Marine Gazetteer definition (here). Isn't there a way to bring across this rich distribution info automatically? - Pointillist (talk) 14:49, 19 August 2010 (UTC)[reply]
I use web services to download the data. WoRMS do not publish the distribution information in the web services funcitionality. They do not have plans to add new data elements at this time. [1][2]. — Ganeshk (talk) 23:44, 19 August 2010 (UTC)[reply]
Sweet! I say, go for it. --mav (reviews needed) 13:05, 21 August 2010 (UTC)[reply]
To me this sounds like a great idea, I was impressed with the sample article I looked at, and I don't think this question/concern should be taken as not supporting the idea. But one thought/concern: does the source data ever change (creation / updates / deletions)? If so, given that it appears there is a lot of it, how can those changes be detected and populated in the Wikipedia articles? It would seem at first glance that a large set of auto-generated articles like this might be very hard to maintain. I.e., once there are a few manual edits, automatic bot updates (if desired) could become much harder. David Hollman (Talk) 11:27, 27 August 2010 (UTC)[reply]
The bot may not be able to update the actual articles, but it can alert editors about the changes. For example this week, I did a compare of all the bot-created with WoRMS and created the Wikipedia:WikiProject Gastropods/Unaccepted page. The page lists all the species that have an unaccepted status at WoRMS (where the status has changed from accepted to unaccepted). Similar checks can be done on taxonomy and other fields. Humans can then update the articles to keep them in sync with WoRMS. — Ganeshk (talk) 11:44, 27 August 2010 (UTC)[reply]
If the bot updated the talk page periodically with any required diffs that could be a good method to keep track of things. Anyway sounds like if the differences are possible to identify you won't have any major problems knowing about changes. Sounds good to me (whatever that is worth). David Hollman (Talk) 19:40, 27 August 2010 (UTC)[reply]
Very impressive, we need more people like you on Wikipedia. There may be some flaws in the beginning with this I easily suspect, but hopefully those will get fixed.--When Chuck Norris takes a step, all humanity dies and gets reborn again Mr. High School Student 11:10, 28 August 2010 (UTC)[reply]
I like the genus entry but I'm concerned about the individual species articles - when all's said and done, Alvania angularis merely states "this is a species of X, it is called Y, here is a link to database Z", all of which information is already present in the index at Alvania. I'd be opposed to creating a large number of individual species articles until we can add some definite content to them, more than simply restating the metadata. Perhaps run the bot only for genuses, and create redirects for species names for the time being? Shimgray | talk | 12:39, 28 August 2010 (UTC)[reply]
Shimgray, The gastropods project team has been adding additional information to these individual species articles. They would add images and distribution information to start with. For example, there are more images of snails on Commons than there are articles for them on Wikipedia. Expanding all the stubs into full length articles will take years. Human editors on the gastropods project have been creating similar one-liner stubs for years. It is tedious and repetitive; they would like to spend time on expanding articles than starting them. — Ganeshk (talk) 14:16, 28 August 2010 (UTC)[reply]
I agree entirely that having a "preformed" article to expand from is better than starting from scratch - the problem here is that in order to help the editor who eventually writes the article, we're creating an awful lot of pseudo-articles that really don't have significant independent content until that person gets around to it, and so aren't of much use to the readers. There are a few possibilities to get around this - would it be possible, for example, to create the blank entry as a hidden comment to a redirect? This would mean that the content is all there for the editor, but we don't leave ten thousand essentially unwritten articles lying around in the mainspace. Shimgray | talk | 18:57, 28 August 2010 (UTC)[reply]
Shimgray, I like your idea. This could be our plan B. — Ganeshk (talk) 16:11, 29 August 2010 (UTC)[reply]
I don't buy that stubiform entries aren't useful. They verify existence, give editors a non-redlink to link to, and include at least a modicum of information. --Cybercobra (talk) 23:56, 31 August 2010 (UTC)[reply]

Alternative versions of articles

Wikipedia articles need a tab named "Alternate Versions." When a user clicks on it, she accesses alternate articles on that topic.

A cool feature would be the ability to look at alternate versions according to how its consensus self-identifies. For example, in reading the article on Jerusalem I might want to see the consensus Muslim version (i.e. what Muslim editors agreed upon as neutral, reliable, etc.). And, I might be very interested in comparing that to the consensus version among Jewish or Christian editors. Or I might want to compare versions of Jerusalem written by residents of the Middle East to that written by residents of North America. And, it would be interesting to compare those versions to the main consensus version. In order to this, self-identification would have to involve more than a User box. Accounts would need some sort of logged profile for Users (totally optional, of course), to correspond to how the alternate versions of articles are flagged.

It would reduce edit warring. Wikipedia is a battleground because everybody believes their version of reality is the right one. Nobody goes around thinking "I'm deluded." Yet, we all disagree about many things, sometimes in a way that suggests one of us must lack the grasp on reality that our happiness requires. Wikipedia allows limited outlet for everyone to be right. There is one version of a topic that is presented at any one time, and only one version. Allowing multiple versions would better reflect the uncertain and diverse nature of knowledge. It would relieve pressure that leads to edit-warring. Perhaps most importantly, it would interesting. It would be educational. It would provide readers with more information about what lies beneath the surface of any topic. It would be inclusive.

It would also help address systemic bias. Noloop (talk) 17:05, 19 August 2010 (UTC)[reply]

Bad idea. That's a can of worms that we don't have enough manpower to monitor, who determines what goes in the alternate "scholarly" view then? Sadads (talk) 17:08, 19 August 2010 (UTC)[reply]
Oh, and then we are no longer a encyclopedia or neutral, see WP:Five Pillars, Sadads (talk) 17:10, 19 August 2010 (UTC)[reply]
God no, goes against everything we stand for. We aren't here to pamper to every special interest group, we are here to provide a summary of subjects based on reliable sources. --Cameron Scott (talk) 17:09, 19 August 2010 (UTC)[reply]
Wikipedia is not Knol. We should thus not be adding technical features designed to encourage content forking. --Allen3 talk 17:15, 19 August 2010 (UTC)[reply]
Not a good idea at all. Completely against the spirit of WP:POV, and it would encourage WP:POVFORK-ing. A better suggestion might be to propose a new wiki where particularly POV issues can be written about in multiple ways, but I doubt it'll catch on. Alzarian16 (talk) 17:24, 19 August 2010 (UTC)[reply]
It's been brought up before, and unsurprisingly rejected. ♫ Melodia Chaconne ♫ (talk) 18:06, 19 August 2010 (UTC)[reply]
IMO NPOV is based on Scientific Method. Paleontology describes experimental and historical science. --Philcha (talk) 18:13, 19 August 2010 (UTC)[reply]
I like the motivation behind the proposal, but it would be a real can of worms. In the end, it would reduce to everyone having his pet version of the article, disgregating work completely. An alternative wiki could be an idea: good luck with that (sincerely). --Cyclopiatalk 18:21, 19 August 2010 (UTC)[reply]
No WP:POVFORKs; full stop. Perhaps you would prefer Wikinfo. --Cybercobra (talk) 00:00, 20 August 2010 (UTC)[reply]
Agree w/ the above. Coming to some sort of agreement and arguing your points is one of the challenges of wikipedia, but also what keeps it alive. Choyoołʼįįhí:Seb az86556 > haneʼ 00:19, 20 August 2010 (UTC)[reply]
White supremacists (Metapedia) and the Christian right (Conservapedia) already have their own playgrounds masquerading as encyclopedias. I see no reason for Wikipedia to host more such monstrosities. Fences&Windows 00:28, 20 August 2010 (UTC)[reply]
It would be educational to go to Jerusalem and see how Muslims write such an article and how Jews write it. That's not a desire for a POV-fork, that's a desire for a kind of knowledge. Noloop (talk) 00:29, 20 August 2010 (UTC)[reply]
These "kinds" of knowledge are called POVs. Choyoołʼįįhí:Seb az86556 > haneʼ 00:38, 20 August 2010 (UTC)[reply]
POVs can possibly be documented in neutral articles, eg X's view of Y. That would be the Wikipedia way (assuming the topic is sourceable - WP:SYNTH would be a hazard). Rd232 talk 00:49, 20 August 2010 (UTC)[reply]

Nope - violates a central pillar of the project, Neutral Point of View. All sides should work together to form a consensus v ersion of one article; the fact that is is hard is not a valid reason to compromise one of our core founding principals. Extra articles simply cover different aspects of a topic in varying levels of detail, they should NOT cover alternative interpretations. --mav (reviews needed) 13:12, 21 August 2010 (UTC)[reply]

Oppose per all above especially Cybercobra. Kayau Voting IS evil C U NEXT YEAR 13:14, 21 August 2010 (UTC)[reply]

Wikinfo has already been doing this, more or less, since 2003. Angus McLellan (Talk) 19:09, 21 August 2010 (UTC)[reply]
Where are the alternate versions on wikiinfo? I looked at their article on God [3], a logical candidate for an alternate views article.
I don't agree that it would violate any neutral point of view guideline. There are already non-English wikipedias; by nature they will be somewhat culture specific and differ substantially from this one. Either they all may have a neutral POV, or none do. The consensus process tends to equate "average" with "neutral", which is a fallacy. Noloop (talk) 01:28, 22 August 2010 (UTC)[reply]
Wikinfo is open to alternative views, but it needs actual people to put them in. So far there's been a shortage. Peter jackson (talk) 15:48, 2 September 2010 (UTC)[reply]
It would violate NPOV becasue the pages would be writen from a POV. Cultural bias is a problom, but having multiple pages oin one subject (bhow many by the way lets take Gaza Flotila. Jewish, Muslim, Chrisitan, British, Turkish, American, Passangers, IDF, NGO's amd uncle tom cobbly and all. It would be a mess. Also it would not really adress your real concearn. We would still need to have an offical page, which wouod still represent the POV coonsensus you are concearned about. The proper place for alternative POV is on the page in question.Slatersteven (talk) 15:11, 22 August 2010 (UTC)[reply]
"There are already non-English wikipedias; by nature they will be somewhat culture specific and differ substantially from this one." That might be true, but that doesn't mean we want that to be the case. We should fight against cultural and systemic bias, not accept it. The purpose of Wikipedia being in multiple languages is simply for comprehension, not to allow each country/culture to present their preferred version of reality. Wikinfo has "sympathetic POV", with opposing views put on another page. The end result is not appealing, and the site has been ignored by most people. Noloop, this idea is sunk: don't waste any more time arguing for it. Fences&Windows 01:48, 23 August 2010 (UTC)[reply]
Arguing? Waste? What happened to "interesting discussion"? I don't really think the idea has been understood. It's not that there should be pages that push a POV. It's that different communities will have different versions of reality--and many can be right. An article on Jerusalem written by North Americans will differ from one written by Middle Easterners, and the knowledge of the difference is worth having. Such knowledge is currently lost. That doesn't mean such articles would push a POV. Think of it in terms of color. Having one consensus version of a topic is like presenting the world in black and white. Having multiple articles is presenting a spectrum. Noloop (talk) 03:18, 23 August 2010 (UTC)[reply]
No, one article should say that there N points of view. Otherwise we may end up with N forks. And if some of the POVs can't take the heat, they could stay out of the kitchen. --Philcha (talk) 03:45, 23 August 2010 (UTC)[reply]
I cant stand this idea that "everyone has the right to their opinion" and it is "neutral" if we present them all and not neutral if we exclude someone's beliefs. What's even worse is when people say this is a "liberal" belief. It isnt being liberal, its being ignorant. There are facts, the world is flat, gravity exists, and yes evolution is real (and no Obama is not a Muslim). We dont need to allow each and every fringe idea their own article to put forth their claim that the US did not go to the moon and that Iraq was indeed involved in 9/11 (and had weapons of mass destruction too!). "In science, any compromise between a correct statement and a wrong statement is a wrong statement."- by user:Stephan Schulz, pulled from User talk:JzG. Instead of trying to end POV edit wars by giving everyone a compromise and a say we need to stand up and say "we are an encyclopedia based on reality and scientific understand of the world" just like every respectable encyclopedia out there.Camelbinky (talk) 03:14, 24 August 2010 (UTC)[reply]
Yes. Good articles might indicate the "uncertain and diverse nature of knowledge" (if it is significant to the topic), and might even cover any significant alternative viewpoints, but only with regard to due weight. And some "alternative viewpoints" might be covered as topics in their own right (e.g., Moon landing conspiracy theories), but that does not justify adopting them. If different communities have different viewpoints, and they are significant enough (see WP:WEIGHT), then possibly the article should cover that ("color"). That does not warrant giving fringe theories the equal standing. - J. Johnson (JJ) (talk) 22:42, 27 August 2010 (UTC)[reply]
I didn't propose anything about fringe theories. Noloop (talk) 01:42, 29 August 2010 (UTC)[reply]
The Japanese bow. Most of the world shakes hands. Do the Japanese therefore believe in the "fringe theory" that bowing is the proper greeting? Noloop (talk) 01:43, 29 August 2010 (UTC)[reply]

Change /r/ in English IPA transcriptions to /ɹ/

I bet this has been proposed before, but I think that Wikipedia should stop using /r/ (the symbol for the alveolar trill) in IPA transcriptions of English, and replace it with /ɹ/ (the symbol for the alveolar approximant). For example, I think that "Barack Obama" should be transcribed /bəˈɹɑːk oʊˈbɑːmə/, not /bəˈrɑːk oʊˈbɑːmə/. Here's my thinking:

  • It's accurate. The vast majority of (native) English speakers use /ɹ/, not /r/. Few dialects use the trill. Even if you're going for a broad transcription of English, it makes more sense to use /ɹ/.
  • It keeps things specific. I don't think that /r/ should be able to stand for multiple sounds, depending on context. It goes against the point of the IPA, and it can be confusing. Using /ɹ/ isn't confusing.
  • I don't see any reason not to use /ɹ/.

On a related note, I think that /ər/ and /ɜr/ should be changed to /ɚ/ and /ɝ/ when appropriate, or at least to /əɹ/ and /ɜɹ/.So yeah. Skrodl

Aaaah - I have loved the English language as a quintessential instrument of human expression from the year dot, ala (Milton), but I definitely don't know as much about it as you appear to. I'm sure we can both agree that language is organic, so here's my take on your proposal - an upside down r is an upside down r. I hope this helps :) MarkDask
Looking at the articles on /ɹ/ and /r/ (disambiguate not to select the important option for the 4chan board name) and listening to their sounds, it seems like you are right. And yet when I look up your proposed ɚ, I am led to an article that synonymizes it with "vocalic /r/", and uses "/r/" extensively in the text. This throws a sour note into the arrangement - but if you can explain that issue, then maybe it's time to implement your idea. Wnt (talk) 23:53, 21 August 2010 (UTC)[reply]
I honestly think that the article on ɚ that synonymizes it with "vocalic /r/" is just another example of the way Wikipedia uses "/r/" to refer to the /ɹ/ sound. The r-colored vowels used in some dialects of English (mainly /ɚ/ and /ɝ/) are vocalic versions of /ɹ/, definitely not /r/. They have nothing to do with the trilled /r/, so whatever we end up doing, we shouldn't write them using "/r/." Writing these r-colored vowels as /ɚ/ and /ɝ/, /əɹ/ and /ɜɹ/, or even /ə/ and /ɜ/ (their typical pronunciation by non-rhotic speakers) is simply more accurate. And yes, Markdask, an upside down r is an upside down r. Skrodl 17:14, 22 August 2010 (UTC)[reply]
So does anyone take issue with the idea? Why don't we implement it? (Sorry if I'm being obnoxious; I'm just a bit impatient.) Skrodl (talk) 23:39, 25 August 2010 (UTC)[reply]
I think this is extremely annoying. You appear to be right, which is the most annoying thing of all. The reason that it's annoying is that 95% of readers will have no idea what the upside-down r signifies. Too bad IPA didn't make the approximant the one with the normal-looking letter. --Trovatore (talk) 00:00, 26 August 2010 (UTC)[reply]
And this is why we have respelling pronunciations. --Cybercobra (talk) 11:11, 26 August 2010 (UTC)[reply]

The proper place to discuss this is WT:IPA for English. AFAIK /r/ is used instead of /ɹ/ because the whole thing is a broad phonemic (or rather, diaphonemic) transcription where such details do not matter (in which case it is preferable to use a simple ASCII symbol familiar to less IPA-savvy readers), it's common in English phonetics literature to do so, and after all there are English dialects where this phoneme is pronounced [r].—Emil J. 12:36, 26 August 2010 (UTC)[reply]

Practically all books teaching English as a foreign language use the /r/, not /ɹ/ symbol. It's a long standing tradition in rendering English in IPA. True, [ɹ] is more frequently heard than [r], but it is never a phonemic distinction, so using /r/ is not incorrect. Technically /ɹ/ might have been a better choice, but it does not serve a purpose for WP to deviate from common practice. −Woodstone (talk) 15:15, 26 August 2010 (UTC)[reply]
  1. This should be at WT:IPA for English, not here.
  2. In a broad transcription, it is common for Roman letters to be used where possible. See the IPA Handbook, p. 28.
  3. On Wikipedia, it is easier to enter Roman characters (which can be done directly from the keyboard) rather than IPA characters, which must be entered by a more convoluted method.
  4. Not everyone uses [ɹ] for /r/. Many rhotic accents use [ɻ]. In Southern England, it has become quite common to hear [ʋ]. Some accents have [ɾ] as an allophone.
  5. I don't think that /r/ should be able to stand for multiple sounds, depending on context. It goes against the point of the IPA, and it can be confusing. Not correct. Please review the notion of the phoneme. A phoneme, by definition, can "stand for multiple sounds, depending on context". And the IPA explicitly allows use of the IPA for phonemic transcriptions, within slashes (//). See the IPA handbook reference I pointed to earlier. Grover cleveland (talk) 18:38, 26 August 2010 (UTC)[reply]
What you're saying is true. I guess I had the false impression that the current system that the IPA uses for English could lead to ambiguity, but now that I read what you're saying, I can see that's not true. I guess there's nothing wrong with using /r/ for English. (And sorry that I submitted this at the wrong place; I'm not an experienced Wikipedia editor.) Skrodl (talk) 23:01, 26 August 2010 (UTC)[reply]
It's just because it's English, english in general can be contradictory and confusing almost all the tim--When Chuck Norris takes a step, all humanity dies and gets reborn again Mr. High School Student 11:16, 28 August 2010 (UTC)[reply]

Images

I myself think that wikipedia needs many more images or if images better updated ones. I think Wikipedia needs to hire and pay people to take images or get them from google or some search engine beacsues if you are doing reports you need examples such asimages to show you what you are reading about. — Preceding unsigned comment added by Bilbo234 (talk • contribs)

It is not a good idea to pay people, because we are a volunteer community. If you want an image, you can take one yourself and add it to Wikipedia. Kayau Voting IS evil C U NEXT YEAR
In its early phase, Wikipedia can focus on free contributions, due to the desperate need of our society to pull away at the consumerist level from a nearly infinitely inefficient copyright restriction model, where people could access all the world's information but were allowed only a tiny fraction. But in the longer term, free culture must also address the production of content, which is to say, the fees once directed to copyright royalties need to be replaced with a form of subsidy for content creators that does not depend on limitation of copying.
One form this may take in early days is a philanthropy to Wikipedia which provides for user rewards to productive editors. Someone might donate two million dollars to Wikipedia, which would be awarded by a multidisciplinary board to applicants who claim a productive record of contributions for the past year, perhaps in several tiers and subcategories. At first the awards may be largely symbolic, more an honor than a salary, but in the longer term they should demonstrate a means of replacement for the royalties of former times. Wnt (talk) 00:03, 22 August 2010 (UTC)[reply]
There is absolutely NO reason why we need to start paying anyone for pictures. If you really think we need good new pictures, I would recommend starting a project drive to get photographers to take good pictures and hand them over to wikipedia. Or a project to place banners on pages asking for nice photos. If you are interested in doing something like that I will help you. BE BOLD Shabidoo | Talk 09:13, 22 August 2010 (UTC)[reply]
Wikipedia is already the most illustrated non children's general encyclopedia in history. It also has a database of 7.2 million images. If you feel an area lacks images please let us know what it is.©Geni 17:37, 23 August 2010 (UTC)[reply]
There are a lot of images out there with licensing compatable with use on wikipedia - more specifically look at http://commons.wikimedia.org/wiki/Main_Page , a lot of image there can be used to illustrate, and the number is growing. For example in the UK images on www.geograph.org.uk are being uploaded constantly as they are useful illustrations for articles. There's also http://commons.wikimedia.org/wiki/Commons:Picture_requests if you have a specific need.77.86.59.49 (talk) 21:11, 23 August 2010 (UTC)[reply]

I think there's been 100s of these type of proposals in the years, so as every one has been replied to: No, I don't think we will pay people, this is a FREE institute, thus every part of it should be free, besides, who will pay. Also like before though: we could get a group of admins to scour google and get some pictures. I kind of disagree with Shabidoo because it would probably take too much effort for ACTUAL photographers, going through Wikipedia and putting pictures everywhere is hard enough

--When Chuck Norris takes a step, all humanity dies and gets reborn again Mr. High School Student 23:39, 26 August 2010 (UTC)[reply]

The phrase "an obvious reference"

I propose that you Wikipedia types run a search-and-replace on the entire wiki and change "an obvious reference" to "a reference." You should do this for two reasons:

  1. "An obvious reference" means that the reference was obvious to the author, making it a clear case of OR.
  2. The phrase is incredibly obnoxious, as it essentially boils down to the author telling the rest of the world that he's proud of himself for getting the reference. This makes me want to punch him.

Thank you. --An attractive and successful IP (talk) 15:51, 23 August 2010 (UTC)[reply]

That's one of dozens of poor wordings listed in WP:EDITORIAL. Editors are welcome to fix 'em when they find 'em, and I think there are some semi-automated tools (WP:AWB, etc.) that could help but that I have not used. I think around 200–500 pages are affected by this specific wording. I doubt this wording rises to the level of a "we'd better do a search-and-replace across the whole wiki right away!" urgency though. DMacks (talk) 16:01, 23 August 2010 (UTC)[reply]
Doing with AWB, will find and replace ones that don't help the meaning of the sentence, Sadads (talk) 16:10, 23 August 2010 (UTC)[reply]
Though, would it staying help make a better identifier for OR? Pausing AWB activity, to wait for input Sadads (talk) 16:26, 23 August 2010 (UTC)[reply]
I agree that the phrase is not encyclopedic and I'm fine with you removing "obvious". While removing, may want to tag with {{OR}} or try to find a reference, though I suspect the latter is unlikely since individual allusions aren't often reported upon. I venture to claim many of these are trivial homages, though some describe the reference to explain parts of plots. However, I don't actually think editors are always trying to boast that they understood the allusion, but rather genuinely believe that the reference is apparent for people familiar with the other work. —Ost (talk) 18:37, 23 August 2010 (UTC)[reply]
If there is no more input, I will commence in removing statement and adding {{OR}} to the pages in which the statement is made without a reference, Sadads (talk) 13:31, 26 August 2010 (UTC)[reply]
My only caution would be to take care that you don't change (or tag) any instances of the phrase that are part of quotations from a source. Otherwise I don't see why there would be a problem with updating this phrasing to something more appropriate wherever it appears. --RL0919 (talk) 13:36, 26 August 2010 (UTC)[reply]

 Done I have taken care of this in mainspace, didn't touch anything archived or files or talk pages, Sadads (talk) 04:18, 29 August 2010 (UTC)[reply]

An obvious reference
I agree in principal that the term "a reference to...." is adequate and perhaps preferable to "an obvious reference to..."
On the other hand, I want to comment on this comment:
....propose that you Wikipedia types run a search-and-replace on the entire wiki and change "an obvious reference" to "a reference." You should do this for two reasons:
1."An obvious reference" means that the reference was obvious to the author, making it a clear case of OR.
2.The phrase is incredibly obnoxious, as it essentially boils down to the author telling the rest of the world that he's proud of himself for getting the reference. This makes me want to punch him.
I find this "incredibly obnoxious" and presumptuous. The term "an obvious reference to..." does not necessarily mean:
  1. That the statement is a clear case of OR.
  2. Neither does it necessarily mean author [is] telling the rest of the world that he's proud of himself for getting the reference.
It can mean that the reference is, in fact, a very obvious reference that anyone who looks will see immediately for themselves. Amandajm (talk) 07:46, 29 August 2010 (UTC)[reply]
That image is not an "obvious" reference if you don't have a schooling in Western scientific and Artistic culture. We write for as many audiences as possible, not just our prime one (which happens to have at least a vague familiarity with the image which yours references to). "Obvious" is a not a NPOV word, and "Obvious reference" implies that the author thought it was obvious that that is a reference, therefore stating something without any verifiable source to back it up. In all 300+ articles I changed it in, only 4 or 5 of these statements had references anywhere near by! Sadads (talk) 20:01, 29 August 2010 (UTC)[reply]

Visibility of tags

Having seen bot going round tagging articles to indicate the date format used in the article and if it written in British or American English. I wondered if there could be some way of making this information more easily available, possibly via a gadget, so that you could see what was the prevailing style for an article. This would save time hunting for the templates or looking at the talk page to see if there is a tag on it indicating the style to use, especially when trying to determine if a change is valid or not. Another possibility would be to generate an automatic page note when you go into edit to indicate the date format and language preference to editors. Any thoughts? Keith D (talk) 16:11, 24 August 2010 (UTC)[reply]

It can be done via edit notices. i.e.: If you go to edit National Hockey League, there is a notice stating the article is written in Canadian English. We've added them on an as-needed basis in cases like the NHL article. Resolute 16:25, 24 August 2010 (UTC)[reply]
I know you can create an individual edit notice on a per page basis. I was wondering if it was feasible or desirable to automatically generate one from the templates the bots are currently adding to articles. Keith D (talk) 16:46, 24 August 2010 (UTC)[reply]
I think you can show hidden categories by setting it in your preferences when signed in - assuming that these templates have "noinclude" categories, then this should show the info in the cat box ? maybe ? Sf5xeplus (talk) 21:44, 24 August 2010 (UTC)[reply]
This probably falls under the "encyclopedia/Wikipedia-specific features MediaWiki ought to have" category of suggestions; we should really fund the devs to move a bunch of currently jury-rigged template-based stuff into MediaWiki extensions. --Cybercobra (talk) 11:18, 26 August 2010 (UTC)[reply]
Seems like I do quite a bit of article cleanup just trying for consistency within an article. I started a list of options at User:Gadget850/Article style options (incomplete). ---— Gadget850 (Ed) talk 17:25, 26 August 2010 (UTC)[reply]

Bot to remove {{Coord missing}} from pages that already have a {{Coord}} template.

Hey wikipedia, Just wondering if people would be OK with me running a bot to remove {{Coord missing}} from pages that have a {{Coord}} template. There are roughly 2,000 articles that would be affected. Thanks, Tim1357 talk 22:59, 25 August 2010 (UTC)[reply]

You'd probably need to contact one directly for something like this --When Chuck Norris takes a step, all humanity dies and gets reborn again Mr. High School Student 23:23, 26 August 2010 (UTC)[reply]
@Mr. Student: ...what? Did you read the few sentences that Tim wrote?
@Tim: It sounds good, but I'm not sure what the botreq are. I'm perfectly fine with it, for whatever that counts for. :-) Killiondude (talk) 23:30, 26 August 2010 (UTC)[reply]
Should be a no-brainer. Unless there are some bureaucratic hoops... Choyoołʼįįhí:Seb az86556 > haneʼ 23:35, 26 August 2010 (UTC)[reply]
Sounds good, with a good edit-summary pointing to a page explaining it, a good log, and some testing (maybe run on 50 articles or something, and check things over). Sounds like you need WP:BRFA.  Chzz  ►  07:11, 29 August 2010 (UTC)[reply]

Editor Advocate Admins

I don't trust the admin community to be careful or fair. A few thoughts and a suggestion:

  • Consensus is process of communication. Generally judging consensus merely by looking at edit histories is a mistake. It will consistently disadvantage minority views.
  • The rule is not "Mass addition of material doesn't require consensus, but mass deletion does." Yet, admins act that way.
  • Admins clearly default to a position of supporting each other, and making the accused bear a high burden of proof.
  • The admin community values quantity over quality. Maybe that's necessary, because of the size and complexity of Wikipedia. But, it leads to a lot of hurtful mistakes, and to errors like judging consensus just by looking edit histories.

That leads to my suggestion for change: Maybe Wikipedia needs an "Editor Advocacy" team of admins. It would have the narrowly defined mission of looking at conflicts with admins from the editor's point of view, and taking more time than usual.

The idea comes from a dispute with my broker. They botched a stock trade. I complained to customer service. It was denied very automatically, like the person handles dozens of such issues a day. Quantity over quality. I complained again, and was told it was being referred to a Customer Advocate. The role seemed to involve examining the issue from the customer's point of view, with a quality-over-quantity approach. The problem was fixed. They've probably found it helps with customer retention.

An Editor Advocacy team of admins could fill a similar niche. It could be by referral, to avoid trolling. It could help retain editors, especially those interested in minority views. It would reassure editors who feel admins are just supporting each other that their concerns are taken seriously. Noloop (talk) 23:11, 25 August 2010 (UTC)[reply]

Claiming a problem exists is not the same as showing a problem exists. Can you provide examples of what has led you to this conclusion, and examples of how your advocates would rectify the problems you claim? Resolute 23:23, 25 August 2010 (UTC)[reply]
My personal experience is just the background, not part of the proposal. Noloop (talk) 00:45, 26 August 2010 (UTC)[reply]
I didn't see a call for your personal experience but concrete examples of where this is seen. You propose a solution to a problem but you haven't provided evidence of the existence of the problem. At best, those examples would demonstrate that this problem is pervasive in admin conduct.--Fuhghettaboutit (talk) 05:25, 26 August 2010 (UTC)[reply]
Very well, since you will not provide examples, I am left to respond with my first impression of your proposal: First, it seems very odd that you open by claiming a distrust of administrators as a whole, then propose the value of having a small panel of admins effectively stand above the rest. Your repeated use of "minority views" also caught my eye. As such, my first impression is that you are not happy that Wikipedia does not give greater prominence to fringe viewpoints and are seeking a mechanism to force the community to accept them with much greater ease. As in your example with your broker, the advocate "fixed the problem", and I suspect the board you envision would "fix" your problems with Wikipedia by forcing it to accept your viewpoint. That cannot happen as Wikipedia is governed by community consensus. Resolute 13:46, 26 August 2010 (UTC)[reply]
Very well said. I have all the same concerns and more. Most of the points sound like they stem from specific examples, but until one's provided it's just conjecture about some things that admins might do wrong. Even if they had happened, the processes already in place would be far more capable of dealing with them that this idea would. Alzarian16 (talk) 13:58, 26 August 2010 (UTC)[reply]
I'm guessing it's about Jesus. No joke. Choyoołʼįįhí:Seb az86556 > haneʼ 14:11, 26 August 2010 (UTC)[reply]
I don't recognise this description, and it seems predicated on the view that content issues are normally resolved by admins, which is untrue outside well-defined contexts like judging WP:Consensus in deletion and move debates. In terms of the comparison with your brokerage (assistance with complaint handling), I wonder if you're aware of the Wikipedia:Mediation Cabal? But really, the comparison is invalid. Unlike with the brokerage service, you are empowered here in a number of ways (dispute resolution) to address problems you face with anyone, including admins. Rd232 talk 07:51, 26 August 2010 (UTC)[reply]

This has been tried before (I cannot remember the link) and failed spectacularly. →ROUX ₪ 07:59, 26 August 2010 (UTC)[reply]

Wikipedia:Ombudsman comes to mind. I'm pretty sure there are a few others lying around. --Izno (talk) 13:45, 26 August 2010 (UTC)[reply]
It looks like the Ombudsman was never tried. It's not really analogous to what I proposed, anyway. I didn't propose any system of sanctioning admins. The essence of the point is that admins tend to follow a quantity over quality strategy of handling problems. They aren't very careful. A team of admins dedicated to editor retention might be effective. Noloop (talk) 14:43, 26 August 2010 (UTC)[reply]
Again, you are speaking about a solution to a problem you assert is present in vague generalities without providing a single example of existence, despite now repeated calls for any concrete example at all. How could anyone decide your proposal has merit when it addresses a cipher?--Fuhghettaboutit (talk) 15:31, 26 August 2010 (UTC)[reply]
If it's not your experience (or otherwise credible) that admins emphasize quantity over quality, then ignore this thread. Noloop (talk) 18:09, 26 August 2010 (UTC)[reply]
WP process is based on consensus of all interested and anyone who might be affected, not just an echo-chamber of supporters seeking to impose their new or altered system or idea on others. DMacks (talk) 10:39, 27 August 2010 (UTC)[reply]
I think Roux is referring to Wikipedia:Association of Members' Advocates. –xenotalk 18:13, 26 August 2010 (UTC)[reply]
So, we have a group of a thousand or so active admins with a (supposed) problem of using a "quantity over quality" approach. The solution is to handle this problem with an even smaller group? If people are using a quantity over quality approach, that is because the quantity of problems is too large to deal with with sufficient quality. A smaller group would either be overwhelmed or underused. In the case of your brokerage service, that sounds like a rather standard customer service approach. In order to save money, the low-level people aren't authorized to do anything except apologize and make you feel better without actually giving you anything. Once they realize that you aren't going to go away, then the upper level people start giving in. Its more a case of "the squeaky wheel gets the grease" than actually caring about customer service. The loudest people getting their way is already how a lot of things work on Wikipedia, we need less of that, not more. We need to make the existing processes better, not just add more processes for people to complain to. Mr.Z-man 04:14, 27 August 2010 (UTC)[reply]
I'm not sure where you're getting this "smaller group" stuff. I didn't say we should have fewer admins. I suggested a team, specifically dedicated to reducing the unfairness that comes with a quantity over quality approach. It would probably help retain editors, which in turn would help increase the number of admins. Noloop (talk) 05:57, 27 August 2010 (UTC)[reply]
The smaller group would be the very team you're speaking of. →ROUX ₪ 06:47, 27 August 2010 (UTC)[reply]
Once again, can you show examples of the existence of the problem you are claiming, and can you explain how you expect your advocate board would solve said problems? Resolute 15:53, 29 August 2010 (UTC)[reply]
There are already mechanisms in place for getting review of administrative actions. They are open to input by all editors: the active admin can explain more detail about why something was done, other admins can criticize, the affected editors can voice their concerns, and other editors can comment as well. Why do we need a new system, involving only some of these communities, to handle it? That seems less open/consensus-based than present (just those chosen few having special review powers), not an improvement for a problem based on claims that consensus is not being read properly. Again (as others have said) without a clearly demonstrated problem (i.e., your whole premise is WP:WEASEL), there's no reason to make new systems/procedures/etc. DMacks (talk) 10:47, 27 August 2010 (UTC)[reply]
I didn't propose sanctioning admins. I didn't propose special review powers. Noloop (talk) 01:39, 29 August 2010 (UTC)[reply]
Then how would this team accomplish anything? If they can override another admin's decision then, by nature, they have more power than a standard admin. Going by your Customer Advocate example, these Editor Advocates would have more authority than standard admins. Not to mention you'd have fewer EAs than standard Admins, so you're concentrating more power into fewer hands.
Oh, and I know a guy who worked Customer Advocacy for a cell phone company. They sat in some cubes and took billing complaints from a queue. They had more access to the customer's records than your normal phone rep, and could investigate all the exchanges in multiple systems to figure out where the error was. This could take a long time in some cases. A Wikipedia equivalent would have some bits that most Admins don't. Right now, those bits tend to be spread out (aka CheckUser rights go to a few people). Without said bits, these EAs wouldn't be able to investigate all the potential issues brought to them, nor would they have the access to fix the problem in some cases (such as WP:REVDEL).
Overall, I don't think this is a good idea. We already have several different venues for resolving problems, and the step above Admins is generally WP:ARBCOM. If it's not something that needs to go to ArbCom, I doubt an intermediate step would help either. — The Hand That Feeds You:Bite 16:55, 31 August 2010 (UTC)[reply]

New ref tag options: <ref name="name" see="p.5" sname="source5"/>

Proposal (respond at discussion area, not here)

Note: This has been updated after initial round of discussions.

Verifying content in sources can be tedious when multi-page sources are cited without specific pages noted. This is compounded by the fact that information must be rewritten in our own words to avoid copyright issues, often rendering the "ctrl+f" find function on a browser to near-uselessness (unless you're lucky). As a result, sometimes properly sourced content is removed simply because future editors can't ctrl+f the information in the source even though it is buried in there... somewhere.

With the current system, you generally have to make a new ref-name each time you want to specify a page or section of the document. Unfortunately, when this is done, citations often end up being all over the place and the ref list gets cumbersome in length.

As you may have guessed from looking at the title above, I propose creating a few additional ref tags to point to specific locations in a multi-page text or web source without having to make a new ref-name. The following demo should be self-explanatory: (ref links coded to click and highlight just like in a real reflist, so feel free to click to see them in action)

Content

Lorem ipsum dolor sit amet, consectetur adipiscing elit.[1] Quisque adipiscing, justo ut ultrices scelerisque, leo ipsum lacinia arcu, id euismod arcu ante non diam.[2] Phasellus in metus vitae magna semper interdum sed eu lorem. Mauris vitae ligula erat.[1]

Vivamus dictum fringilla magna quis accumsan.[3] Nullam id libero at massa sodales venenatis. Ut adipiscing feugiat erat, quis scelerisque quam porttitor a.[1][3]

Maecenas et elit a magna tincidunt vestibulum.[1][3] Vivamus tempus nunc vestibulum nisi elementum vel interdum arcu iaculis. Integer sollicitudin velit sit amet enim faucibus varius.[1] Pellentesque eu libero augue.[3]

References

1. ^ ap.12 cp.31 b d e Source name, access date, etc.
2. ^ch.5 Source name 2, access date 2, etc.
3. ^ a d[4][dead link] bUser talk:... c Hydro, Code. User:Codehydro. Wikipedia: The Free Encyclopedia. 2010.
== Content ==

[[Lorem ipsum]] dolor sit amet, consectetur adipiscing elit.<ref name="name" see="p.12">Source name, access date, etc.</ref> Quisque adipiscing, justo ut ultrices scelerisque, leo ipsum lacinia arcu, id euismod arcu ante non diam.<ref name="name2" see="ch.5">Source name 2, access date 2, etc.</ref> Phasellus in metus vitae magna semper interdum sed eu lorem. Mauris vitae ligula erat.<ref name="name"/>

Vivamus dictum fringilla magna quis accumsan.<ref name="hydro2010" see="[http://en.wikipedia.org/wiki/User:Codehydro/Demo]{{deadlink}}" sname="hydrodemo">Hydro, Code. ''[http://en.wikipedia.org/wiki/User:Codehydro User:Codehydro]''. Wikipedia: The Free Encyclopedia. 2010.</ref> Nullam id libero at massa sodales venenatis. Ut adipiscing feugiat erat, quis scelerisque quam porttitor a.<ref name="name" see="p.31"/><ref name="hydro2010" see="[http://en.wikipedia.org/wiki/User_talk:Codehydro User talk:Codehydro]"/>

Maecenas et elit a magna tincidunt vestibulum.<ref name="name"/><ref name="hydro2010"/> Vivamus tempus nunc vestibulum nisi elementum vel interdum arcu iaculis. Integer sollicitudin velit sit amet enim faucibus varius.<ref name="name"/> Pellentesque eu libero augue.<ref sname="hydrodemo"/>

== References ==

{{reflist}}

Notice how you can use standard wiki markup in see= for more interesting effects like linking via url. You can also use sname= if you want to use the same markup again, and do so without typing name=. Also note the truncation if its longer than 10 characters. Moreover, to reduce ambiguity, all ref tags with (and without) see= are clustered together, and those ref tags with identical sname= are also grouped for compactness.

First round new ref discussion archive

Note: this part of the discussion was for a version that had a url= option, which has since been merged with see=.

As a note, this ref method may be possible already in theory through the manual creation of a WP:LDR, albeit highly cumbersome, confusing, and easily mislinked. However, list-defined references are rare on Wikipedia and converting reference styles on established pages to LDR is cumbersome, whereas my suggestion above could be used on any page without redoing all other refs. Coding the options into the ref tag should be relatively simple, and I can probably do it myself if nobody else will. —CodeHydro 16:07, 26 August 2010 (UTC)[reply]

Sounds good, similar solution to Harvard footnotes except integrated into the more standard notes. I like it, not sure how much it would take to integrate it technically, Sadads (talk) 16:10, 26 August 2010 (UTC)[reply]
Great idea! Buglet in demo (important point for implementation): refs without see= or url= should be listed in the footnote after those with these tags. The second use of [1] ( <ref name="name"/> at end of first paragraph) is placed as b in References entry 1 preceding c (I assume in order of use in article body). But c is "p.31" (from <ref name="name" see="p.31"/> at end of third paragraph). The resulting layout "b cp.31" suggests that b is also p.31 rather than loose for the whole biblo entry. Would be clearer/correcter as "cp.31 b" (assuming a/b/c in order of link appearance in article) or "bp.31 c" (looks cleaner here, but might require multiple parser passes through the article to collect the data). DMacks (talk) 16:19, 26 August 2010 (UTC)[reply]
Ah, I see what you mean. With the way I have above, it seems to imply that both b and c are from p.31. In short, you are suggesting that ref tags with either see= or url= should be group together in front and all those without should be group in the end like this (new labels d and e added):
Content

Lorem ipsum dolor sit amet, consectetur adipiscing elit.[1] Quisque adipiscing, justo ut ultrices scelerisque, leo ipsum lacinia arcu, id euismod arcu ante non diam.[2] Phasellus in metus vitae magna semper interdum sed eu lorem. Mauris vitae ligula erat.[1]

Vivamus dictum fringilla magna quis accumsan.[3] Nullam id libero at massa sodales venenatis. Ut adipiscing feugiat erat, quis scelerisque quam porttitor a.[1][3]

Maecenas et elit a magna tincidunt vestibulum.[1][3] Vivamus tempus nunc vestibulum nisi elementum vel interdum arcu iaculis. Integer sollicitudin velit sit amet enim faucibus varius. Pellentesque eu libero augue.[1]

References

1. ^ ap.12 cp.31 b d e Source name, access date, etc.
2. ^ch.5 Source name 2, access date 2, etc.
3. ^ aurl bUser talk:... c Hydro, Code. User:Codehydro. Wikipedia: The Free Encyclopedia. 2010.
Good idea, less ambiguous :) and perhaps identical see= page numbers could be clustered as in the original proposal except with the second ref name="name" also saying see="p.31" —CodeHydro 16:50, 26 August 2010 (UTC)[reply]
I hate the formatting messes resulting from autolinkified URLs displayed in references (http://example.com), and the "url" linktext displayed if "url= but no see=" is an improvement. But that's a nonstandard way of hiding URLs from what I can see: a normal URL link that doesn't have a name displays as [5]. That is, in pseudocode:
if (url) {
  if (see) {
    "[${url} ${see}]"
  } else {
/* current approach
    "[${url} url]"
*/
/* more standard, matching other contexts */
    "[${url}]"
} elsif (see) {
  "${see}"
}
Although, I'm confused by what happens when both are used anyway. Could you clarify the "ellipsis after 10 characters in the reflist" feature? What is the display-string that is being truncated here ("${see}:${url}", "${see}:url", is see= truncated if no url= passed)? DMacks (talk) 16:45, 26 August 2010 (UTC)[reply]
Oops, I did mess up on the trunc. The original tag should have been <ref name="hydro2010" see="User talk:Codehydro" url="http://en.wikipedia.org/wiki/User_talk:Codehydro"/> but I only typed in "User Talk" in the version you originally saw. I have fixed it. And as for the non-standard url thing when omitting the see=, I guess we can just use the standard [6] to keep it simple, though I think it to be ugly :P —CodeHydro 17:02, 26 August 2010 (UTC)[reply]
Brainstorming further (sorry I keep getting ideas after posting previous ones!), what about scrapping url= altogether and letting see= just be normal wiki-markup? That way see=[http://example.com/reprint-of-page-5 p.5] and see=[http://example.com/reprint-of-page-5] behave like editors expect (not have to learn special syntax/feature of linking for this context). And see=http://example.com/reprint-of-page-5 displays the actual URL (autolinkified by wiki engine as usual) and looks terrible just like it always does, again encouraging editors to actually add something intelligent to display like a pagenumber or even just square-brackets. Bonus is that would allow additional standard annotations there, for example, see=[http://example.com/reprint-of-page-5]{{deadlink}} (important type of feature, needs to be targetted to the URL not the whole footnote ref entry and not where the footnote-link is in the article body). DMacks (talk) 16:55, 26 August 2010 (UTC)[reply]
Hmm, that's a neat idea. I "see" now that url= is probably unnecessary ;) Okay, everybody, hold off on posting for a short while. I am going to update the proposal above. —CodeHydro 17:14, 26 August 2010 (UTC)[reply]
See Template:Bug for a similar proposal. ---— Gadget850 (Ed) talk 17:19, 26 August 2010 (UTC)[reply]
It's a minor detail but I would suggest that "label" is more generic than "see". I'd also lean towards superscripting the entire label, e.g. something like:
1. ^ a: p.21 b: p.67-80 Smith, John. Encyclopedia of Wacky things.
But that's a relatively minor formatting point. In general, I am supportive of ideas like this. Dragons flight (talk) 17:50, 26 August 2010 (UTC)[reply]
Simply put, I love this idea. Would solve a lot of different issues that I have grappled with and seen many users complain about. {{Rp}} was created by another user specifically to stop my whining about an aspect of this problem, but this is a better solution than having the page numbers in the article text.--Fuhghettaboutit (talk) 22:20, 26 August 2010 (UTC)[reply]

Discussion area for new ref options, update 1

Okay, done adapting suggestions into proposal. As for the last idea before the section break, I decided not to add it because that would make the ref bulkier. By not having what is in see= superscripted, it is more compact by two characters ":" and a space " "... anyhow, there may be bugs in the demo, because I don't want to hold off the discussion too long before updating it. Please let me know if you find any. —CodeHydro 18:05, 26 August 2010 (UTC)[reply]

You may wish to view WP:Centralized discussion/Citation discussion#Redux, which specifically references a proposal to add what I would claim to be a better set of functionality. This proposal isn't exactly included there, but I'm sure it would be a good improvement to make (I'm more concerned that "see" and such are ambiguous: the software should be dealing with this based on items such as the author name automatically). --Izno (talk) 18:20, 26 August 2010 (UTC)[reply]
Interesting discussion there, but I believe this is of a very different nature. Those are suggestions to create citation templates for specify styles like APA or MLA. While those ideas are focused on templates that help other editors retrieve their own copy of a source that's cited, this proposal focuses on locating information within the source that's already on hand but too lengthy for easy verification of individual pieces of information. —CodeHydro 18:44, 26 August 2010 (UTC)[reply]
Hardly. What I'm suggesting is that we take your suggestion and add it to the other suggestions there. The software should be able to see similar <ref ... > code and put two and two together on its own. For example, the software should see automatically that the "name" is the same, the "work" is the same, but that the "pages" are different, and be able to handle it automatically in the same fashion as your suggestion. That avoids making new parameters and increase usability in the same fashion as you desire. --Izno (talk) 01:32, 27 August 2010 (UTC)[reply]
I've added a link on that page, informing people that this proposal is here. I'm not still sure about moving it, so I'll let others decide if they want it moved. —CodeHydro 13:15, 27 August 2010 (UTC)[reply]

References

  1. ^ Book title
That injects the code into the text around, and I personally wouldn't want to see that outside of the <ref> or the references section… --Izno (talk) 01:32, 27 August 2010 (UTC)[reply]
Yeah, Fuhghettaboutit mentioned {{rp}} in the first round of discussions and said the same thing about rp disrupting the text. —CodeHydro 13:15, 27 August 2010 (UTC)[reply]


In the long term, we need to transition to a footnote system that fits in better with the wiki way so that everyone will be able to understand it and easily use it without making the wikitext hard to read. Adding another attribute to an already confusing system makes it even more difficult for newbies to use.

  • Abolish the ref name="..." syntax. Use only numbers to identify specific footnotes.
  • Linking to a specific footnote should be as easy as [[From #2 34-35]]. Although it currently renders as From #2 34-35, it should become, for example, [2b]. (Footnotes that are not citations would use the word Note instead of From.)
  • Defining a footnote should be as easy as including [[From #2]] Miller, E (2005). ''The Sun'', Academic Press. Pages along with all others within a single pair of <footnotes></footnotes> tags (just like the current <references></references> tags, better if the footnotes appear in a separate text box).
  • Footnotes should be automatically renumbered whenever the page is saved.
  • Example appearance of footnotes (borrowed examples from WP:CITE):
    1. Brown, R (2006). "Size of the Moon", Scientific American, 51(78). Pages 8-9
    2. Miller, E (2005). The Sun, Academic Press. Pages a) 80-105; b) 34-35; c) 22
  • Is this a reasonable approach? PleaseStand (talk) 16:14, 27 August 2010 (UTC)[reply]
"Footnotes should be automatically renumbered whenever the page is saved." means the whole page content is automatically changed (all the "From #___" actual text strings in the article)? Seems like that would make reading revision-diffs incredibly painful. You're just swapping one weird syntax/feature for another. I think you're addressing an interesting annoyance: if I want to add another cite using an existing one, I have to dig into the article-source to find the <ref name=> tag rather than just looking at the References section. But that seems less of a problem than having small article edits making a huge resulting "change" to the article sources. DMacks (talk) 17:53, 27 August 2010 (UTC)[reply]
Yes, that would require major changes to the way diffs work. However, even [[From #Brown2006 34-35]] is much better than <ref name=Brown2006 see=34-35/>. That's six less characters to clutter the wikitext. PleaseStand (talk) 19:01, 27 August 2010 (UTC)[reply]
Yes — abolish the ref name="..." syntax! It seems its primary purpose is to avoid having to stuff bibliographic details into more than one <ref>, but I say that is misguided, that bibliographic details should not be in the refs in the first place. More generally, <ref> is a structural "container", and modifying it with details of its contents entangles structure with content. (I thought we had learned better with HTML.) So: opposed to adding <ref> parameters that encode content.
Also yes to automatic renumbering of footnotes. Occasionally it is inconvenient to have them change, but they should be in sequence, so there is no avoiding a change when a note is inserted.
But the approach above ["Pages a)..."] is misguided. The general approach I recommend is to set up all of the bibliographic details in a References section (using {{cite}} or {{citation}}) templates, then link with {{Harv}}. Sure, Harv has some rough spots, but I don't see that the current proposal improves on it. - J. Johnson (JJ) (talk) 22:12, 27 August 2010 (UTC)[reply]
There is not a chance in hell that developers will allow any proposal where the wiki source code is automatically renumbered when you save. (It would fail horribly with templates and transclusion, for starters.) The rendered content can be automatically numbered, but no developer is going to allow automatic renumbering to happen in the source code. Dragons flight (talk) 22:59, 27 August 2010 (UTC)[reply]
I agree. We have a system where the software automatically numbers things. Having to put numbers in the wikitext sounds like a step backward. Using names is a lot more intuitive than arbitrary numbers, even if it takes up a little more space. Arbitrary, non-constant numbers are impossible to remember when editing compared to well chosen names. And if the numbers automatically change, how would you handle, say, inserting a reference in the middle of an article (triggering a renumbering) and then linking to that same footnote elsewhere in the same edit? If the new ref would be number 4 but it triggers a renumber, then all links, including the one you just added, would be changed to number 5. Mr.Z-man 03:54, 28 August 2010 (UTC)[reply]

Refs - alternate suggestion

"1. ^ a: p.21 b: p.67-80 Smith, John. Encyclopedia of Wacky things." strikes me as extremely cryptic, and if your browser doesn't support the CSS :target pseudo-class (e.g. you're using IE, or a printout) you have no way to know which [1] is which page. I would find something like this to be much easier to make sense of:

  1. ^ a Smith, John. Encyclopedia of Wacky things.
    1. ^ b p.21. "Blah blah blee blee blah."
    2. ^ c d p.67-80

The in-text refs for b, c, and d should be shown as something like [1.1] and [1.2]. This would also allow the sub-references to sensibly contain quotes from the source and other bulky information, as shown in "b".

If I were to choose a syntax for the ref tag, I'd prefer something like <ref name="Smith">Smith, John. Encyclopedia of Wacky things.</ref> ... <ref in="Smith">p.21</ref> ... <ref name="p67-80" in="Smith">p.67-80</ref> ... <ref name="p67-80" in="Smith" />; this naturally allows wikitext in the sub-references. The code must, of course, support the case where the "parent" comes after the "child" (and especially the case where the "parent" is a list-defined reference and the child is not). Anomie⚔ 03:21, 29 August 2010 (UTC)[reply]

I like this. Its similar to what I suggested on bug 13127 with the benefit that the software doesn't have to guess as often what you meant. As for determining the parent ref, I suggested another attribute (though that was before LDRs existed). So to determine the parent, something like 1) Ref with "parent" attribute set, 2) List-defined ref, 3) First instance in page text. Mr.Z-man 04:25, 29 August 2010 (UTC)[reply]
Yeah, list-defined refs handily solve the problem of "how to specify the parent if we don't need to use it anywhere in the article". Anomie⚔ 15:49, 29 August 2010 (UTC)[reply]
(edit conflict) I am concerned that the References section would be much "taller" (i.e. if editors do not actually include quotes from sources), making it more difficult to use the scroll bar (yes, some people still do use it) and wasting tons of pages in a printed copy. And using a ref name solely to identify page numbers would be a bad thing. It's already a problem with shortened footnotes since <ref name="Smith, 67-80">Smith, 67-80.</ref>...<ref name="Smith, 67-80"/> is far more confusing (when making large edits to articles) than <ref>Smith, 67-80.</ref>...<ref>Smith, 67-80.</ref>, especially because AWB's general fixes change the latter to the former. Your suggestion also does not address the complexity (as perceived by the user) of the current ref tag system; not everyone understands XML syntax. I suggested [[From #Smith2010 67-80]] for two reasons: 1) is based on the wikilink syntax used throughout articles (looks "easier" to the user); 2) is concise and readable (we don't, for example, make links using "<a href="...">...</a>") for a reason). PleaseStand (talk) 04:51, 29 August 2010 (UTC)[reply]
In a tradeoff between length and comprehensibility, I'd pick the latter. Your concerns over people not understanding XML syntax are not really relevant to this particular discussion (and people can always use {{#tag:ref}} syntax if they want), your concerns that named refs are "confusing" do not seem to be shared by the community at large, and your suggestion of using <ref>Smith, 67-80.</ref>...<ref>Smith, 67-80.</ref> is contrary to your earlier complaint about the size of the references section. As for your alternate syntax, it would be easy to confuse it with a targeted link to From, and it may be that the devs don't want to add more weird special cases to the [[...]] syntax like we already have for categories, files, and interlanguage links. Anomie⚔ 15:49, 29 August 2010 (UTC)[reply]
I could go for this alternate idea. Actually, before I decided to go with the more compact version for the proposal, my original idea was to break it up almost exactly like Anomie shows it above with the multi-lines and have them clustered under the main reference (though the ones below the main need not be numbered since there are the tiny letters). Either way, it is better to keep references to the same text in the same area... I don't like looking at disorganized lists like those shown in Latin#Notes. —CodeHydro 17:03, 29 August 2010 (UTC)[reply]
We do need some way to indicate that a particular use of the reference refers to a particular subreference, and without requiring the reader to click and have a browser supporting the CSS :target pseudo-class. Otherwise how do you know if [1] refers to the whole thing (a), page 21 (b), or pages 67-80 (c and d)? While [1a] is a possibility, I thought [1.1] might be easier to follow. Anomie⚔ 19:08, 29 August 2010 (UTC)[reply]
As mentioned various times in this discussion, that is basically the {{rp}} template, which makes a ref like this[1]: 1  which is largely unused due to disruptions in the text flow—CodeHydro 02:16, 30 August 2010 (UTC)[reply]
[1]: 367–380  is quite frankly ugly, and it's not at all clear to the reader what those hovering numbers next to the reference indicator might really mean. Anomie⚔ 11:26, 30 August 2010 (UTC)[reply]
I don't care how this is done, as long as: using a new system is not required, old system still works as currently, and refs are not nested like the above example. More repeat numbers = more confusion when reading long lists of refs. [a]:p. # seems fine to me, though. —fetch·comms 18:07, 30 August 2010 (UTC)[reply]
Generally concur. The concept of nested sub-references seem particularly ill-advised, and tending to impair reading (verification of sources) and deter maintenance editing. - J. Johnson (JJ) (talk) 21:45, 31 August 2010 (UTC)[reply]
The problem is that [a]:p is vague and of limited use. There's nothing to indicate that the second number is a page number, especially given that the first number is just a number and has nothing to do with the source itself. It also visually separates the page number from the source; I don't think I've ever seen any sort of referencing system where the page number is completely on its own, with no direct indication as to which source it refers to. With a system like Anomie's, it could also be used for things other than page numbers. How exactly would this "deter maintenance editing"? Mr.Z-man 23:12, 31 August 2010 (UTC)[reply]

diffs/line number should be a link

In a diff like this it would be nice if 'line 149' was a link to an anchor at line 149. Just granpa (talk) 12:32, 28 August 2010 (UTC)[reply]

Good idea, AWB does that, maybe there would be a way to integrate that into the main software?Sadads (talk) 16:15, 28 August 2010 (UTC)[reply]
There's a feature request for something mostly like this - #2313 - but it looks like it's not been touched since 2005. Shimgray | talk | 17:27, 28 August 2010 (UTC)[reply]

A rating system

I was at the branch of the English Wikipedia Wikibooks, and I noticed they now have a rating system used as a feedback system, and looking into the page a little more I was thinking, would the main Wikipedia be helped by this too? I mean, it's nowhere near necessary but it would be something to be looked at by the people and editors. It should only be voted on by the Wikipedia users for better reliability. In the end, it's a feedback and voting system. So, what do you guys think?

--When Chuck Norris takes a step, all humanity dies and gets reborn again Mr. High School Student 13:53, 28 August 2010 (UTC)[reply]

We already have rating systems for articles, but the concern about the wikibooks type approach is the fear that it might encourage people to criticise things instead of fixing them. I suggest we watch how the implementation goes on Wikibooks and ideally on a smaller language wikipedia, then if the statisticians can come up with convincing evidence that this could be implemented here without diverting editors away from improving articles it would be worth looking at it for here. ϢereSpielChequers 14:11, 28 August 2010 (UTC)[reply]
Yes, I do agree I suppose. —Preceding unsigned comment added by Mr. High school student (talk • contribs) 17:08, 28 August 2010
They use the same system (with a slightly different look) at Wikinews:. (and please shorten your signature) -- Quiddity (talk) 19:43, 29 August 2010 (UTC)[reply]

Email client built into the MediaWiki software

I am suggesting that an inbuilt email client should be developed for MediaWiki. Every user will have an inbox, and the Special:EmailUser/<username> will be used to send messages to that inbox. I persoally think that is much better than the current system. (Of course, it will need PDF support) Access Denied talk contribs editor review 17:14, 28 August 2010 (UTC)[reply]

That would be the same as a "private messaging" feature like many forums and social networking sites have. I myself think that would be useful but it's likely to be rejected because there are some that think that would make WP too forumy or myspacey. --Ron Ritzman (talk) 17:20, 28 August 2010 (UTC)[reply]
It's a nice idea but will never be implemented on Wikipedia due to the social networking aspect of it, as Ron Ritzman says. Wikipedia is meant to be collaborative on the wiki. Emails are a privilege. Of course, it could work on other wikis where that's not such a strong ethos. Aiken ♫ 17:28, 28 August 2010 (UTC)[reply]
Never say "never" :) We do have the "email this user" feature for those occasions where it is necessary to contact an editor privately. A private messaging system would be more convenient for some. I myself check my talk page a lot more often then I check my email. However, I can see the other side if it too. It might encourage people to use WP as a social networking site or even as an alternative to email. On the plus side it might make it easier for those who usually don't use email to contact arbcom, request oversight, etc. --Ron Ritzman (talk) 17:45, 28 August 2010 (UTC)[reply]
Is there really a dramatic benefit to this over and above integrating with people's own mailboxes? I can't quite see how it's better to send messages to a site-stored inbox (and then presumably have to send out notifications etc) than it is just to send them directly to the person. Shimgray | talk | 17:39, 28 August 2010 (UTC)[reply]
Well, you could get a notification similar to the (new talk paage message) one we already have, so that we wouldn't have to ping each other's talk pages all day. Access Denied talk contribs editor review 17:43, 28 August 2010 (UTC)[reply]
You don't have to "ping" anything all day. You should be improving articles, not chatting all day by email. Aiken ♫ 17:45, 28 August 2010 (UTC)[reply]
I don't ping all day; I have seen it happen with longtime contributors though. Access Denied talk contribs editor review 17:49, 28 August 2010 (UTC)[reply]
You should be improving articles, not chatting all day by email Or, you could remember that everyone is a volunteer, and do what you wish. 18:04, 28 August 2010 (UTC)
Or, you could remember that everyone is a volunteer, and do what you wish. No, you can't just "do what you wish". Wikipedia is an encyclopedia not a social networking site. Aiken ♫ 13:02, 29 August 2010 (UTC)[reply]
You're missing the point. You said "you should be improving articles", but no one 'should' be doing that if they don't want to. But it seems too many people think WP is some sort of job where people have obligations...but they don't, outside a select few. ♫ Melodia Chaconne ♫ (talk) 13:57, 29 August 2010 (UTC)[reply]
When they are on Wikipedia, that's exactly what they should be doing. Nobody forces you to log on, but when you do use Wikipedia, it ought to be for improving the project, not nattering with mates over email. Aiken ♫ 14:23, 29 August 2010 (UTC)[reply]
So I'm some horrible person for being always logged on but rarely doing all that much "improving" of articles. Gee, thanks. ♫ Melodia Chaconne ♫ (talk) 16:09, 29 August 2010 (UTC)[reply]
Nope, never said that. Re-read what I've said, particularly about only using the site to socialize. Aiken ♫ 00:20, 30 August 2010 (UTC)[reply]
Yeah, but... again, those two users could just use email, which doesn't require you to be logged in to read and reply to it, and allows people the flexibility to handle how they deal with it as part of their normal workflow - including however they manage their message notifications. I really don't see the payoff from implementing this (probably quite logistically complex) system when we can use the existing, far more powerful, and well-adopted email infrastructure. Shimgray | talk | 18:49, 28 August 2010 (UTC)[reply]
I don't see a benefit; I've been discussing similar, re. 'instant message' integration, and suchlike. My first reaction is indeed to recoil at the possible MySpace-type effect, and the huge overhead in policing such a system (taking time away from building an Encyc. by dealing with problems, e.g. what if people abuse the mail, post libel, copyright, etc. etc) and my more considered reaction ('never say never') is that Wikipedia should stick to what it does, and leave other things to other websites; why re-invent the wheel. We're not a telecoms company, so we don't provide voice-chat; others do that better. We're not an instant-messaging thingy, there are plenty of those, so why not just use them. Same for email; other web services do it well, so what is the point in us trying. In addition, for email, people do things their own way; having yet-another-inbox to check would be a pain.  Chzz  ►  07:05, 29 August 2010 (UTC)[reply]

Since this is turning into an argument rather than a discussion, I recommend we do it this way. If you're FOR the PM system, put in bold Approve, if you oppose, well, put Oppose, then put your signature. If we get enough people into this thread, and get them to Approve, then we may get an Admin involved to sort it out one way or the other. If we get too many people opposing to approving, it's already over. Pretty self explanitory, and hopefully more people join so that we can get some REAL opinion into this. Now let's start

Approve -- Mr. Upper School 02:04, 30 August 2010 (UTC)[reply]

You think its turning into an argument instead of a discussion, so you're turning it into a vote? Mr.Z-man 02:26, 30 August 2010 (UTC)[reply]
Polling is not a substitute for discussion --Cybercobra (talk) 02:39, 30 August 2010 (UTC)[reply]
Oops, didn't know that was a rule-- Mr. Upper School 18:23, 30 August 2010 (UTC)[reply]

We already have a facility to email other users when they have it enabled in their profile at [[Special:Emailuser/<USERNAME>]] (and can be found in the toolbox section of their user (and user_talk) page), which gets sent to their email address, what benefit(/s) would introducing a full system into MW bring? Peachey88 (T · C) 02:50, 30 August 2010 (UTC)[reply]

I think it would even be counterproductive, and would encourage discussing article content in private, rather than publicly where others will see it and help. Of course this is possibly now, but I think most of us treat using it as an exception. DGG ( talk ) 20:21, 31 August 2010 (UTC)[reply]

Dictionary of National Biography auto-generated content

Hi. i'm in two minds as to whether I should post here given that I know a lot of people are opposed to auto generated content but I was wondering what the views would be on a bot which transfers the 3800 or so missing public domain Dictionary of National Biography encyclopedia book articles on notable UK figures already written and stored in Wikisource. The texts are already written but may require some minor wikifying. If I can sort a bot to transfer these texts with some wikification and would only require manual edits after creation to Categorize and some very minor organization work what would the general view? The text is already written. Its just otherwise its going to take years tp transfer this content when it could be done within days by a bot and more time spent on improving them. I need some form of general consensus here as to whether or not we really want these articles. The vast majority of them are notable biographies from Tudor times to the late nineteenth century like Christian ministers and theologians, naval officers, judges, politicians, antiquaries, physicians etc. In my view they are all articles which an encyclopedia like wikipedia should engulf. If I have some indication here that the community wants these biographical articles I can form a bot proposal which will create these articles with as minimal manual work needed as possible. A trial run of a small number of course would be performed first to see if they have the seal of approval. Any thoughts? Dr. Blofeld 13:06, 29 August 2010 (UTC)[reply]

They're certainly all notable figures (indeed, were they not quite notable, we could argue a DNB entry tips the balance there anyway), but the problem is that the articles are pretty elderly. I've written several articles on figures with DNB entries, and almost without fail there's some significant changes made in the newer ODNB entry (the ODNB, a successor project, includes everyone in the DNB); I would go so far as to say that we can probably predict that, overall, every DNB entry contains at least one major error compared to recent scholarship. I'm not sure if we should think of this as a showstopper or not.
If we do run such an import, though, it might be worth producing a second list - all figures with DNB entries whose articles are currently stubs - for possible manual merging. Shimgray | talk | 13:20, 29 August 2010 (UTC)[reply]
I don't like the idea of copy and pasting it, and as Shimgray says there may well be numerous errors. And I don't believe every entry is notable either. Inclusionists often cite WP:DEADLINE, so I will too. It doesn't matter if they aren't here yet, Wikipedia will be here tomorrow. Of course, I don't object to manual creation, but umpteen articles which are no doubt badly formatted, strewn with errors and maybe not even notable have no place on Wikipedia. Creating articles should never be a bot process, creation should take as much care as deletion. Aiken ♫ 13:40, 29 August 2010 (UTC)[reply]
Can I just say that these articles would be created anyway and are in the process of being copied. The point is that the manual time would then be better spent improving the texts rather than being spent copying and pasting them. Dr. Blofeld 13:41, 29 August 2010 (UTC)[reply]
Then that's ok. As long as you're taking care when creating them and not copying in the errors, there is no problem. It would be better, imo, to improve texts as you import them, rather than importing them all then doing it after. Aiken ♫ 13:46, 29 August 2010 (UTC)[reply]
Well ideally they would all be like my article Sir Robert Ainslie, 1st Baronet. The idea eventually is that all of these DNB articles I want transferred are written like this. No there is no time limit but I am just looking for something to simulate the manual copying and pasting and to encourage people to build on what we have. Dr. Blofeld 14:04, 29 August 2010 (UTC)[reply]

Yes DNB does have the occasional error like other encyclopedias but the vast majority of it is correct. What is important here is that we have the raw text founded. Once we have the article there additional sources can be added, Oxford Dictionary Biography updated sources, peerage sources etc to build upon the articles and make it our own. But we need the raw power to get them onto here in the first place. Otherwise a year of my editing will be spent just copying the texts when it could instead by spent improving the texts and doubly verifying them. UPon creation by the bot I propose that they go in a category in which they can all gradually be checked manually over time. The most important thing I thinkis to have the texts when the vast majority of it is accurate. I do believe that they will improve wikipedia as a resource, and gradually when other sources are compiled to build upon them we'll have better articles than the original and any Oxofrd articles on them. We need something to work with though, th occassional error can't be avoided. Dr. Blofeld 13:36, 29 August 2010 (UTC)[reply]

Mmm an idea would be to write into the Template:DNB that the text will require additional sources for verification. That would alert the reader that there may be an occasional error or claim which needs further support/updating, The DNB though is a highly respected resource and was owned by many aristocrats over the years so as a resource it does have a lot of repute. Dr. Blofeld 13:44, 29 August 2010 (UTC)[reply]

The Catholic Encyclopedia and 1911 Brittanica templates contain no such disclaimer; adding one would be against precedent. --Cybercobra (talk) 02:45, 30 August 2010 (UTC)[reply]
  • Well, yeah, it's well regarded. I like it; I still keep a printed copy on the shelves at work! It's also unavoidable that once people sat down and rewrote every article, glaring discrepancies occurred - the fact that it was treated as good for so long, and bought as a standard component of a lot of libraries, doesn't mean we should assume it was as reliable as it seemed. It's the fact that there is a better version in existence that makes me a little wary of adding the old material, I think.
  • Perhaps a useful approach would be to have the bot explicitly link the "old" articles to the ODNB articles, which are available online, by noting it under further reading as a "revised version" or the like? Everyone with an article should be in the new one, and it means we can steer readers towards the hopefully more comprehensive one until such time as we develop a better article ourselves. Shimgray | talk | 14:47, 29 August 2010 (UTC)[reply]
    • That sounds like an excellent idea. Pretty much the only downside with ODNB entries is that they aren't free (beer or speech), linking to them would be a positive. Oh, and I support the whole project. - Jarry1250 [Humorous? Discuss.] 12:11, 30 August 2010 (UTC)[reply]
      • I think this is a fantastic idea, if implemented properly. I'd love to see it happen, especially because if it works for the DNB, there are other encyclopedias for which it would be useful. I know dated information is a concern, but we've been using public domain material as the basis for articles for quite some time now, so there is precedent. And I like Shimgray's bot idea as a way to bring the new edition of the Dictionary into the picture. Some things, such as categorization, would need to be done manually, but that's not a tricky task, especially if the bot-generated content is placed in its own hidden category, or marked in some other way to make it more accessible in a block to editors. --Ser Amantio di NicolaoChe dicono a Signa?Lo dicono a Signa. 21:38, 30 August 2010 (UTC)[reply]

+::The CE and the EB templates certainly should have carried a disclaimer that they are out of date, that the contents may no longer be accurate, and may not represent a NPOV. It is not just a question of errors, but of further work and reinterpretations--not to mention updated references. It was an uuderstandable but very poor idea to import this material as is originally, with any other intent than that of using it as one of the sources for articles. In this particular case, all of the people in the old DNB are also included in the current one, which is not free content but is widely available as a source for writing or updating articles-- in the UK, at every public library & online to those with a library card. As a minimum, I would agree with the suggestion that each article imported carry prominently a link to the corresponding article in the new DNB with an appropriate comment requesting updating. DGG ( talk ) 20:18, 31 August 2010 (UTC)[reply]

  • Well, at least form me, there wouldn't me any objections to adjusting the CE and EB templates to add such a disclaimer. I think that the inclusion in the DNB is probably sufficient cause for there to be an article, however. I don't myself know how complicated the bots which autogenerate articles are, but one possibly acceptable option, if it's possible, might be for the bot to simply add certain pre-designated information in the original draft. Things like birth, death, profession, and the like might be included. That would likely resulting in autogeneration of stubs, granted, but even stubs are better than nothing. John Carter (talk) 17:12, 2 September 2010 (UTC)[reply]

Problem

I have a problem. Can I whrote a artical, about one person, but, the subject of articls be a ,,Famous people in the shadows¨, or something like that ? --WinstonSims (talk) 17:28, 30 August 2010 (UTC)[reply]

If you want to write about a person, you should write the article using their name as the title. The person should be notable, as shown by significant coverage of them in multiple secondary reliable sources. We do not write essays or opinion pieces, which is what "Famous people in the shadows" sounds like. Also, this is not really the place to discuss this; this noticeboard is for discussing new proposals of Wikipedia guidelines or policies, not new content. Fences&Windows 18:20, 30 August 2010 (UTC)[reply]

Miscellaneous PROD

As I look at Wikipedia:Miscellany for deletion, more and more I'm see utterly uncontested deletes. Now, while MfD doesn't usually have an overly large backlog, many of these uncontroversial deletions are still a waste of everyone's time; the outcome is never really in doubt. What I'm proposing is development of a PROD process for misc pages. This would work essentially the same as the regular PROD process for articles (WP:PROD), just for misc pages. If such a thing were developed, it might also be a good idea to merge Wikipedia:Proposed deletion (books) into it, although if there was any great desire to keep that separate it wouldn't be a problem. I'm holding off on creating a formal proposed policy page for now, mainly because I'd rather not go to that trouble if the idea is wholesale rejected by the community. Any input would be welcome.--Fyre2387 (talk • contribs) 20:51, 30 August 2010 (UTC)[reply]

Good idea, but with these restrictions:
  1. User pages and subpages only.
  2. No user talk pages unless the corresponding userpage is also tagged.
  3. No userboxes, regardless of namespace.
  4. Must use one of these reasons:
    1. WP:FAKEARTICLE not edited for > 1 year.
    2. Secret page and/or sister components (barnstars, etc).
    3. Blatant violation of WP:NOTMYSPACE or WP:NOTWEBHOST.
— Train2104 (talk • contribs • count) 23:08, 30 August 2010 (UTC)[reply]
  • Oppose everything that removes an opportunity of discussion from the community. PROD is already a disgraceful idea in itself, let's avoid extending its tentacles further more. Deletion of stuff should follow consensus. --Cyclopiatalk 12:10, 1 September 2010 (UTC)[reply]

Watchlists of banned users

Promoted from Wikipedia:Village pump (idea lab)

The thought has occurred to me that blocked/banned users remain able to log in, and remain able to access their watchlists. For short-term blocks/bans, that's fine. But for indefinite-banned users or long-term banned users, it seems likely that this would encourage socking. Of course they can duplicate watchlist behaviour in a number of ways, but a big part of the socks-of-banned-users problem has to be habit: so blocking their watchlist would seem helpful. What if, just as admins can revoke talk page access when blocking, if required, there was an option to block access to the watchlist? This ought to be very easy to implement in the software (he says), and potentially quite useful (in a way that's probably hard to quantify ...) Rd232 talk 09:08, 24 August 2010 (UTC)[reply]

Just because someone is banned from contributing to WP doesn't mean they should be banned from reading it. I have many pages on my Watchlist that are there because I'm always interested in potential updates to info about the subject. ♫ Melodia Chaconne ♫ (talk) 13:55, 24 August 2010 (UTC)[reply]
There's something to that point, but it has to be noted that the idea wouldn't prevent anyone from reading Wikipedia; it merely makes it harder to identify recent changes to articles (which is primarily about editing). In addition, there are other ways to keep up with updates to existing articles (which is both a weakness and a strength of the idea) - for example, every article has RSS feeds for recent changes. And to clarify, I imagine that policy on removal of watchlist privileges would limit it to indefinite-banned or long-term banned users (eg >30 days block, or even >3 months). Or even restrict it to cases of proven socking by blocked editors - which would have the distinct merit of providing an additional sanction for people who engage in it! Rd232 talk 14:13, 24 August 2010 (UTC)[reply]
You're right, watchlists of banned users do help them with their socking. Fences&Windows 23:01, 26 August 2010 (UTC)[reply]
You need to distinguish between a ban and a block. Here you mean (I'm almost certain) to say "indefinite block", in place of ban, because a "ban" is a social concept and not a technical one. Which then runs into the issue of "a banned user may be indefinitely blocked, but an indefinitely blocked user may not be banned", which certainly then also implies Melodia's issue. --Izno (talk) 04:10, 31 August 2010 (UTC)[reply]
I think that's unnecessarily confusing, and anyway somehow (I'm not clear how) seems to prejudge how policy might be written for use of the proposed technical option. Rd232 talk 09:40, 31 August 2010 (UTC)[reply]
Hardly "unnecessarily" confusing. I'm just asking you to be precise and to use the terms as the Wikipedia culture uses them. I know for one that you might get into hot water if you weren't able to distinguish the terms at, say, RFA. >.> --Izno (talk) 12:56, 31 August 2010 (UTC)[reply]
I'm quite able to distinguish thank you. What's confusing me is you raising the definitional issue at all, since the reference to blocked users was in the context of just the opening sentence, talking about watchlist access (because the technical measure proposed could be applied to merely blocked users if the community so wished). After that it only talks about banned users, because it's those that the proposed technical measure is expected to be used for. Rd232 talk 15:22, 31 August 2010 (UTC)[reply]
I don't think this will be effective; most socks don't attack that many articles, and even if the list exceeds their memory, Special:Contributions will have the list of everything they ever edited. WhatamIdoing (talk) 05:45, 31 August 2010 (UTC)[reply]
This proposed technical option is not about socks; it is about sockmasters. And in particular, it's about banned users socking, whose socking is supported by allowing them continued access to their extensive watchlist built up over time at their original/main sockmaster account. (So already you can see we're talking about a small number of users - banned users with quite chunky watchlists.) Will removing that access make socking impossible? No, but it'll make it harder, and I think it would also make it more likely that sockmasters trying to be careful to avoid arousing suspicion might find that more difficult too. I mean, RSS or Special:Contribs is certainly an imperfect replacement for the watchlist. Besides that, as I said, some part of the socking problem is people being unable to break the wikihabit; there is an element of addictiveness which hangs substantially on the Watchlist (cf the way people get addicted to checking email). Finally, retaining it as a possible sanction for sockmasters caught socking is an extra sanction when sometimes (for an indef-banned user who can't be hard-blocked due to using too large an IP-range) there currently is none. Rd232 talk 09:40, 31 August 2010 (UTC)[reply]
For someone who can't be blocked by IP, this would be almost trivial to bypass. Mr.Z-man 15:44, 31 August 2010 (UTC)[reply]
What? Please explain? I'm talking about blocking access to the watchlist, which requires the user to log in, making IP issues irrelevant. (Of course RSS access to the watchlist would be blocked too.) Rd232 talk 17:06, 31 August 2010 (UTC)[reply]
All they would have to do is make a "watchlist" sock that logs in but doesn't edit. If their IP was hardblocked, that would make it a little more difficult. Mr.Z-man 20:42, 31 August 2010 (UTC)[reply]
"All they would have to do..." - I don't really care what they would have to do (though with the large watchlists I'm imagining, duplication is non-trivial and doing so perfectly from memory not possible). My main point is that for editing Wikipedia there is a habit element, and turning off the watchlist can help people break the Wikipedia habit, if they have any inclination to do so whatsoever. Normally when they login they see X, Y, Z edits that they can't respond to; with this, they simply won't. Curiosity will make them jump to a couple of pages of recent interest, but it's slightly breaking the pattern, taking away the addictive "rush" element of the watchlist, and they're more likely to look at recent edits/conversation, complain to themselves, but not do anything. Basically, my main angle is psychology: I'm not really making it much harder for determined sockers, I'm making people less likely to sock. Rd232 talk 21:31, 31 August 2010 (UTC)[reply]
This sounds like an inconvenience for some to solve a relatively low-priority issue; users can easily check which pages they edited by using Special:Contributions, so I'm not sure how removing a watchlist will prevent them from following pages that they edited. —Ost (talk) 21:39, 31 August 2010 (UTC)[reply]
I'm sorry, did you actually read the comment to which you are responding? It doesn't sound like it to me. This is not about technical prevention of Determined Socker, it is about psychological help for Banned User Who Might Consider Socking If They Keep Logging In, See Edits Happening, And Feel The Need To Respond. Rd232 talk 09:33, 1 September 2010 (UTC)[reply]
In that case, I still don't think it will help that much. If someone gets to the stage that they're considered community banned or banned by ArbCom, then they're almost certainly at the "Determined socker" stage already. If you want to reduce the liklihood of socking, you would have to do it before people start. But that would mean removing watchlist access for almost all indef-blocked users. Mr.Z-man 12:05, 1 September 2010 (UTC)[reply]
I'm not sure how true that is: how many bans (and it's not just ArbCom bans - why exclude community bans?) involve socking? Certainly not all. And even having socked before isn't actually proof that deactivating the watchlist (let's avoid the word "blocking" for clarity) would have no effect on the probability of future socking. Beyond that - sure, using it more widely, eg for all indef-blocked users (maybe with a delay to permit appeals) would make it have more impact. But I don't want to get into arguing that at this point because I feel that's a later policy issue which would obscure the basic advantages of implementing this technical option, and deciding actual use now is premature, given that its implementation ought to be quite low-cost. Rd232 talk 14:14, 1 September 2010 (UTC)[reply]
I don't think I did exclude community bans (I did say "or" ...). Even if someone hasn't yet resorted to socking, a ban means that they've almost certainly been blocked several times, meaning they're already dedicated to disrupting. I would point out that there also isn't any proof that it would have an effect on future socking. Mr.Z-man 22:17, 1 September 2010 (UTC)[reply]
Uh huh, so your answer to my psychological argument that checking the watchlist is an addictive element parallel to the well-established phenomenon of email addiction [7] is... what? These people are all, without exception, so addicted that they cannot avoid socking no matter what help we give them? (Even if they haven't even socked yet.) And you know this how? ... Look, just for fun, what if you tried arguing for the proposal, instead of taking against it and then trying to prove you're right? Rd232 talk 22:59, 1 September 2010 (UTC)[reply]
Yeah, let me support something that I don't support. That sounds like fun. Though a lot less fun then presenting a proposal with no evidence to support your assertion, then waiting until someone calls you out on it to provide the evidence just so you can act superior. Because obviously I was just supposed to make the connection between "my main angle is psychology" and a "parallel to the well-established phenomenon of email addiction." Mr.Z-man 23:10, 1 September 2010 (UTC)[reply]
Well (a) I already mentioned email addiction as a parallel above, in a comment you replied to dismissively, missing the point entirely (b) you've still not engaged with my psychology argument seriously (c) you are by far the most consistently negative person around here when it comes to proposals, always ready to criticise. That needs doing, sure, but it would a lot more helpful if you channelled the critiques into some constructive alternative (eg "it's made of straw... but if it were made of brick, it might be worth doing..."). And every time I remark on this (once in a blue moon, but this is hardly a novel state of affairs) you react like I've insulted your mother. I don't mind telling you, given how vocal you often are, it feels quite demoralising. Rd232 talk 23:20, 1 September 2010 (UTC)[reply]
A) You haven't made a substantial reply to any of my points either. My first comment was "irrelevant", then you "don't really care" about my second, then every comment after that has been met with comments about how I'm being dismissive. B) The fact that socking exists is evidence that this may not help much at all. We block a user from editing, they create another account, we hardblock their IP range, they use an open proxy, we have a bot block 150,000+ proxies, they edit from Starbucks, we create edit filters to prevent their edits from saving, they make subtle changes to their patterns, etc. Its an arms race and this is just another weapon. I'm not saying it certainly won't deter any. I'm saying that its not likely to deter very many, especially given the ease of bypassing. Taking away watchlist access seems like a slap on the wrist when combined with being banned from the site; like sending someone a notice of a 25 cent library fine while they're in prison for robbing the library. C) If everyone supported every proposal on this page, we would probably rewrite every policy every month and have 10 times as many processes. I've made substantial comments on 4 of the 21 threads currently on this page. I've supported one of the suggestions ("Refs - alternate suggestion") and of the 3 that I opposed, at least 1 ("Editor Advocate Admins") has nearly unanimous opposition. I may not be as "progressive" as you when it comes to proposals, but I'm hardly the extremist you paint me as. Not every proposal needs an alternative. Sometimes things just aren't necessary. In my opinion, this is one of those things. We have a ton of anti-socking measures at our disposal, each provides some marginal benefit. Though I wonder how many people are more encouraged by their ability to bypass our numerous countermeasures than they are deterred by them (I seem to remember we had a template warning for people who intentionally tripped edit filters, but I can't find it). Some vandals create socks with obvious sock-puppet usernames just because they can. They know they'll be blocked immediately; they do it anyway to create more work for us, and because they can. I don't feel like you've insulted my mother, I feel like you've insulted me. It seems like every time I oppose a proposal of yours you reply with a holier-than-thou attitude like you're a better person (or I'm a worse one) because you provide "new ideas." Mr.Z-man 00:57, 2 September 2010 (UTC)[reply]
(a) I don't need to make substantive replies to irrelevant points. Your criticisms have largely missed the point here. It's the equivalent of saying of Alcoholics Anonymous "but it doesn't prevent people buying alcohol". (b) Your points about socking go off and miss the point again, as if this was a technical measure to defeat someone 100% certain to sock. Those people are not the target audience (although I have argued the measure may usefully inconvenience them in a minor way). (c) I'm not at all claiming holier than thou! I'm asking merely why you always seem to oppose my proposals, without having anything good to say about them at all. Is it just something you have against me then? Given the number of my proposals which have ultimately been implemented it can't be that my ideas are 100% shit (though obvious there's hit and miss). And by the by, asking for something positive to say is not the same as asking for support, which not only implies endorsement of the proposal but also suggests endorsement of the proposal as it stands. But fine, if you're happy you're being as fair and constructive as you possibly can be, then I guess it's my problem. (d) I guess my frustration here is partly founded on your serially missing the point of this proposal - which isn't usually the case. Your criticisms are usually perceptive, even when I disagree about the weight to be assigned to them. Rd232 talk 02:03, 2 September 2010 (UTC)[reply]

Perhaps you could clarify what group this is targeted at then. Banned users, who haven't turned to socking before the ban, who are determined enough that they might sock, but who aren't so determined that basic countermeasures will be ineffective? That sounds like a rather small group. Most people in Alcoholics Anonymous are people who want to change their behavior. That doesn't really sound like most banned users. If someone doesn't actually want to stop drinking, then yes, some sort of measure to prevent them from buying alcohol would likely be necessary. Mr.Z-man 02:26, 2 September 2010 (UTC)[reply]

See my reply to MBelgrano below. My view is that propensity of banned users to sock is a statistical phenomenon. On the left of the distribution, some users will accept a ban, and sod off and leave Wikipedia alone. On the right, some users will sock come what may (maybe were socking already). In between, there is a group of users who are undecided about socking. How large is that middle group? Who can say; I don't know what shape the distribution is and neither do you. But if we can take simple measures that make it more likely that members of this group decide not to sock, why wouldn't we? Rd232 talk 14:21, 2 September 2010 (UTC)[reply]
Well, it can't be that large, given that the group of banned users is not very large. If Category:Banned Wikipedia users is complete, then we have less than 700 banned users (WP:LOBU has less than 500 and includes temporary bans). Even if the group is 90% of banned users, its still only 1 or 2 users per month. I would also disagree that this is a "simple" measure. Changing the software is about as complicated as measures get, short of taking off-wiki action somehow. And, just as a bit of information, I tested how long it takes to copy a watchlist to another account. I copied my watchlist (450 pages) to my sock account; it took less than 2 minutes using Special:Watchlist/raw. Mr.Z-man 14:47, 2 September 2010 (UTC)[reply]
Well I appreciate the attempt to inject some numbers, but even if they are small, we're talking about the more disruptive users, so even small numbers may be worthwhile. Whilst in general software changes range from the hasslesome to the mindboggling, I do feel this is a very simple thing (for someone who knows what they're doing with the MediaWiki software) which would easily slot into the software at a couple of points without complex knock-on effects. Beyond that, I don't know why you copied stuff using the watchlist, since (a) the whole point is you wouldn't have access to it and (b) once again, the issue is not (primarily) how hard it is to reproduce the watchlist elsewhere (and it's not quite as easy as you make out). Rd232 talk 16:14, 2 September 2010 (UTC)[reply]
The comment that I replied to is what prompted me to write, as I check contributions often enough to realize that patterns can develop from techniques that are nearly as effective as watchlists. You acknowledged that it may "slightly" break a pattern; I understand the intent behind the proposal and I respectfully disagree that the option is needed. —Ost (talk) 13:49, 1 September 2010 (UTC)[reply]
Well OK. (I guess when you say "needed" you mean "any use".) Rd232 talk 14:14, 1 September 2010 (UTC)[reply]

Is this technically possible to begin with? MBelgrano (talk) 14:25, 1 September 2010 (UTC)[reply]

I don't see why not - should be analogous to the software option to block user talk editing. All the software needs to do is check whether the "deactivate watchlist" option is on (maybe double-checking the user is blocked too) when serving the watchlist. If it is, it serves an alternate message. Rd232 talk 14:55, 1 September 2010 (UTC)[reply]
Watchlists of indef-blocked users should be wiped clean, but not necessarily for the reasons set forth above. They should show up as unwatched pages (unless, of course, someone else is watching them), so we are not lead to believe that they are being watched by someone who might, for example, revert a vandal. bd2412 T 15:28, 1 September 2010 (UTC)[reply]
Watchlist and talk pages are of a different nature. The user own's talk page is, in the technical sense, a page like any other, that may be (technically speaking) protected or unprotected from editing like any other. The watchlist is a special page, with an unique way of working and uniques ways of being edited, and it's surely beyond the hability of being protected or unprotected. MBelgrano (talk) 17:59, 1 September 2010 (UTC)[reply]
Nobody's suggesting the watchlist be protected from editing. All it takes is a line or two in the MediaWiki code before the watchlist is loaded which says "wait, is the account's watchlist deactivated? No, OK proceed. Yes - stop, and show a No Watchlist For You message". This is analogous to users not being able to edit their own talk pages because that protection is nothing like ordinary page protection either, applying only to the account in question. Rd232 talk 19:44, 1 September 2010 (UTC)[reply]
As I said, it should be confirmed if the mediawiki can be altered that way before making such proposal. In any case, I find it a "punishment" so easy to get around that I doubt developers would even take the efford of adding it. Let's say you close the watchlist of a master of puppets, so that he can't get access to it. What's the benefit? Do you think it would be so hard to simply remake the watchlist in one of the puppet accounts? All that would be needed to be done (and any experimented user as to get banned would find out by himself) would be to open the category page of the favourite topic, open all pages in new tabs, and press "watch" in each one. Repeat with other categories, dismiss unwanted pages in the category, and that's all: punishment circumvented. Even more, it doesn't involve a single edit, so nobody would ever find out. --MBelgrano (talk) 23:15, 1 September 2010 (UTC)[reply]
As noted above, the "punishment" element of this is minor, and perhaps I shouldn't have mentioned it at all if it's going to distract people that much (though given that it's an additional sanction where currently there is none, I see some use in it even if the sanction is tiny). The primary motivation is to tackle the addiction element of the watchlist (analogous to email addiction - a "hit" from clicking and finding something has happened you need to respond to). There's a case to be made that whilst this addiction element plays some part for all prolific Wikipedians, it especially plays a role for those who continue to want to contribute despite not being willing or able to fit in - and hence get banned. Such social malcontents are more likely to have addictive personalities. Unless we assume that 100% of the target audience immediately go off and recreate their watchlist, then the measure would have some impact. Since the measure is low cost, it doesn't matter if the benefit is low (especially as it's impossible to say how low, and probabalistically it might turn out to be better than "low"). Rd232 talk 02:12, 2 September 2010 (UTC)[reply]

I give up. Psychology 101: epic fail, the lot of yez. Rd232 talk 23:22, 1 September 2010 (UTC)[reply]

It matters little if the intention is to punish, to be harsh "for your own good", or whatever. For someone in that position, it would be an obstacle, and a very easy to evade without leaving traces. Only newbies wouldn't realize it, but we don't talk about newbies here.
In any case, your logic has a fatal flaw: you consider that such a banned user would check changes through his banned account, then jump to the puppet account to answer, then go back to the blocked one. Unlikely. If he creates a new account to keep editing and evade the ban, he would use the new watchlist, adding to it the articles he may be interested to follow. MBelgrano (talk) 03:14, 2 September 2010 (UTC)[reply]
I know for certain that at least some banned users continue to log in to their primary account in order to check their extensive watchlist, even with a well-established several months' old sock. Of course once they create a sock they will develop, gradually or in an intensive effort, a watchlist in the new account. But as I keep saying, what I'm imagining is that at least some people would give up, and not sock. Psychology says that there must be some (maybe many) who are in a sort of "oh fuck 'em, let 'em be" kind of mode when banned, but can't resist keeping up with ongoing developments, and only later eventually succumb to the temptation to sock. Some evidence for that: socks are often created some time after the ban, rather than before (the user can usually see it coming, and could take pre-emptive measures) or immediately after (though of course escaping detection is a factor there). I could add that I speak partly from experience on the addictive aspect of the watchlist, both in my everyday use of Wikipedia, and on occasions when I've blocked myself (by a variety of means including actual self-blocking and measures on my computer) to try and get some work done. I can safely say that if I was ever banned, it would be a battle between my conscience and my desire to continue editing; and I know that having access to my watchlist would make it more likely my conscience would lose that battle, because I could so easily see recent stuff, nonsense, vandalism going on. Can I be unique in this? I argue not, because it's similar to email addiction (clicking refresh on the inbox), which is a well-established phenomenon. Rd232 talk 14:09, 2 September 2010 (UTC)[reply]
There's an additional argument I haven't made: often a banned user's disruptiveness is focussed on a particular topic. Deactivating the watchlist makes it slightly more likely that even if they do sock, they will focus more energies elsewhere (maybe not avoiding the topic entirely, but engaging with it somewhat less, for instance focussing on some key pages or pages of recent interest, rather than a wide spectrum of pages across the topic). Again, won't apply to everyone to the same degree, but statistically, it should have some effect. Rd232 talk 14:09, 2 September 2010 (UTC)[reply]
Additional argument: another way having the watchlist of the banned account accessible helps the sockmaster is in managing separate sock accounts to help conceal their identity and avoid getting caught. Having to recreate the watchlist elsewhere makes it more likely they'd end up editing with that account, and maybe slip up. But being forced to choose which sock account to log into after seeing something on the sockmaster watchlist (because the sockmaster account is blocked from editing), makes it easier not to make a mistake. Rd232 talk 14:25, 2 September 2010 (UTC)[reply]
  • Support blocking banned users' watchlists in the absence of a good reason against. Lambanog (talk) 14:33, 2 September 2010 (UTC)[reply]
  • Support - not just 'blocking' but deleting, so the articles do not show up as being "watched" merely by being on those lists, and so the banned user can't just copy and paste his old watchlist to a new account. bd2412 T 14:43, 2 September 2010 (UTC)[reply]
    • They wouldn't be able to copy-paste the watchlist anyway (from raw mode), as that would obviously be blocked as well (it's part of Special:Watchlist). Deleting permanently would be technically simple but raise issues about people returning later, and deleting temporarily would be substantially more technical hassle to implement than just deactivating access to it (you'd have to back it up somewhere). I appreciate the point about pages wrongly showing up as "watched", but this function isn't used that much anyway (the public watch numbers aren't shown below 30 watchers). Rd232 talk 16:22, 2 September 2010 (UTC)[reply]

Links: open in new tab

Okay, so I've always had this problem with Wikipedia for a long time and I wish to address it and possibly fix it. It's no big problem, but whenever one clicks a link, external OR internal, it goes to that page in the same tab. So, whenever I need to keep a large amount of Wikipedia articles open in the same time or don't want to close the one I'm on currently while going to an external site, we should make it so that the links open in a new tab. It would probably be in exponent form like this being the same link as the original phrase right next to it. It would be a www like that. I hope this at least goes into good consideration. -- Mr. Upper School 14:39, 31 August 2010 (UTC)[reply]

Perhaps you should just hold down your browser's "open in new tab" modifier key when clicking on links? I see no reason to code a feature into Wikipedia that is already—and probably better–handled client-side in the reader's browser. (Myself, my browsing behaviour is 50/50. When I want to open the link on the same tab, the default behaviour is perfect; when I want to open a link on a new tab, I just hold down a modifier key while clicking on it, and I get a new tab.) —C.Fred (talk) 15:13, 31 August 2010 (UTC)[reply]
I agree—a link is a link. It's preferable to let the user choose how it opens. Click the mouse wheel, or use CTRL+click, or whatever can be made to work in your preferred browser. PL290 (talk) 15:18, 31 August 2010 (UTC)[reply]
Firefox has extensions like Tab Mix Plus that can force links to open in a new tab if you wish. Rd232 talk 15:24, 31 August 2010 (UTC)[reply]
You can change your preferences so that external links open in another tab/window. Go to your preferences, then selesct the gadgets tab. The 3rd from the bottom of the User Interface gadgets is "Open external links in a new tab/window". Then you would need to adjust your browser so they open in a new tab vs window. ~~ GB fan ~~ 15:33, 31 August 2010 (UTC)[reply]

WP:AFDPP

Note: Please keep the discussion about the general concept of postponing rather than arguing the merits of any specific mass deletion.

I have written an essay for a new policy WP:AFDPP. Please read it at the link. Thank you for your patience in reading the whole essay before responding here. —CodeHydro 19:10, 31 August 2010 (UTC)[reply]

I changed the wording of the template a little, to avoid confusion with the existing Deletion Review process. DGG ( talk ) 20:03, 31 August 2010 (UTC)[reply]
Opps, thanks. I have updated the wording of the essay a bit to avoid similar confusion. —CodeHydro 12:18, 1 September 2010 (UTC)[reply]

New Wikiproject for hospitals

Something I've noticed is that there are oodles of hospitals with notability comparable to (and sometimes exceeding) that of high schools that are not covered by Wikipedia. We find them notable enough to compile lists like List of hospitals in Florida, yet many included in such lists have indefinately remained redlinks. For schools, we have WP:Wikiproject Schools, but hospital articles are only covered by WP:Wikiproject Medicine (which I would compare to having all school articles under WP:Wikiproject Education. I'm thinking of building up some of our existing hospital articles and creating ones for notable facilities not covered, and perhaps creating a new WP:Wikiproject Hospitals to support the project. PCHS-NJROTC (Messages) 19:36, 1 September 2010 (UTC)[reply]

Wikipedia:WikiProject Council is thataway. --Jayron32 04:24, 2 September 2010 (UTC)[reply]

"Biographies of living companies" guidelines and relationship to pending changes

I probably should know already whether this is the right place to post this, so, if it isn't, I sowwy, I scwewed up. But there has already been serious discussion regarding adjusting the pending changes function to include all BLPs. Personally, I get the impression that if anything main articles or history articles of active companies might be just as susceptible to the same sort of editing, particularly if they have recently been involved in some significant controversy. So, I guess I'm raising two points, and, like I already said, I know this may not be the place for one or both:

  • 1) Should we have clear guidelines or policies regarding articles or content relating to active companies or business? and
  • 2) If pending changes are approved for continuation, would it make sense to include articles about active companies, corporations, or whatever in the group of articles automatically or semi-automatically include in the pending changes list? John Carter (talk) 16:27, 2 September 2010 (UTC)[reply]

A-Class Review

There should be a place to review A-class articles. Some people have raised concerns that only WP:MILHIST has proper facilities to review A-class articles, and I wish to create a place like WP:GAN to review A-class articles. WikiCopterRadioChecklistFormerly AirplanePro 18:30, 2 September 2010 (UTC)[reply]

New criteria

It seems the old criteria on who gets listed on the banned list gives recognition to obvious trolls. I like to propose new criteria on who gets to be listed. Please see this diff: [8] Princess Ava (talk) 18:49, 2 September 2010 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=382526507"