Wikipedia:Village pump (proposals)/Archive 99

I am a high school student, I use Wikipedia so much all the time. I would love it if you guys would implement facebook into your website. My reasoning behind this is due to the fact that if you were to add this people would start using it and others will read your articles. Growing the community, making people smarter by reading, and you guys will also have a higher ranking website. If this is not enough reasoning to add a fb button then please reply back to me with concerns or questions or comments.

There is no chance of this happening. Firstly, Facebook is a private company (of severely dubious repute), and it would damage the image of the charitable Wikimedia Foundation to endorse it; secondly, if we endorse one company we need to endorse its rivals, which will result in a mess of links on every page to Myspace, Bebo, Google, LinkedIn, Baidu and around 800 others. Since Wikipedia is currently the sixth most visited website in the world, I don't believe "having a higher ranking website" is something we're particularly concerned about. 84.13.26.181 (talk) 19:49, 6 February 2013 (UTC)

See Wikipedia:Perennial proposals#Share pages on Facebook, Twitter etc. This has come up many times in the past and every time it was rejected by the Wikipedia community. -- Toshio Yamaguchi 19:56, 6 February 2013 (UTC)

I checked that Perennial proposals page. It's unfortunate that it doesn't link to any previous discussion, but the reasons for rejection are very unconvincing. Like many discussions on Wikipedia, the reasons are based on the editor, not on the reader. What reader knows they can create an account and add a sharebox? The choosing the websites is the only reasonable issue, but that can be fixed by doing research on a number of news organizations and see which links they most often use. The New York Times uses Facebook, Twitter, Google+, Tumblr, LinkedIn, and Reddit. The Washington Post features Facebook and Twitter, and also has Tumblr, reddit, stumbleupon, digg, delicious, and google+. We could also do like NYT does and feature the main ones, with a share button that brings up more for the others. Ryan Vesey 20:05, 6 February 2013 (UTC)

The NYT is aimed at the US and so features those sites popular in the US; the BBC is aimed at the UK and features those sites aimed at the UK etc etc etc. Wikipedia is aimed at a world audience, so would (rightly) be accused of bias if we didn't include at the very least those sites popular in every English-speaking territory; thus as well as the usual Facebook, Twitter etc we'd need to include Baidu (#1 in Hong Kong), Bongoline (#1 in Tanzania), Bebo (#1 in Scotland), MySpot (#1 in South Africa) and …well, you get the idea. (Facebook is so ubiquitous in the US that it's sometimes hard to remember that it's not the world-dominator it likes to present itself as.) If we stuck with only US/UK sites, or gave them high prominence while relegating other countries to a "see also" button, there would be absolute uproar from the rest of the world about cultural imperialism, which is not what Jimmy Wales wants. 84.13.26.181 (talk) 20:16, 6 February 2013 (UTC)

We'd focus on the English speaking world. BBC gives Facebook, Twitter, Stumbleupon, Reddit, Digg, and Delicious. Australian Broadcast Corporation uses the same but adds LinkedIn. While I understand that there are tons of regional social networking sites, we should attempt not to weigh them too highly as they're unlikely to be useful to a majority of our readers. I checked the Scottish Sun [1] which uses Facebook, Twitter, Google+, Digg, MySpace, Fark, Buzz Up, Delicious, Reddit, and Now public. We could also do what I suggested below and only do Facebook, Twitter, and Google+ since they're the main ones. Then we wouldn't need to make any decisions. Ryan Vesey 20:25, 6 February 2013 (UTC)

In plain word, as nice a term such as social plugin may sound, the FB like button is essentially nothing more than a marketing tool. This raises privacy concerns, as it can be used to track visitors to a site, even if those users are not Facebook users at all (see Like button#Plug-in). -- Toshio Yamaguchi 20:33, 6 February 2013 (UTC)

(edit conflict)I understand the points by 84.13.26.181; however, I think this is a good idea. We're one of very few websites not to have a share button. I wouldn't see a problem with having a share button on the sidebar with Facebook, Twitter, and Google+. Ryan Vesey 19:58, 6 February 2013 (UTC)

The last major discussion is at Wikipedia:Village pump (proposals)/Archive 87#Share button where I listed 14 previous discussions and there have been a few since. Again, I fail to understand how simply sharing an article turns Wikipedia into a social networking service. Editors engaging in a collaborative work form a social network, thus Wikipedia is social networking, but we keep discussions focused on improving content. --— Gadget850 (Ed) ^talk 20:46, 6 February 2013 (UTC)

Over at Wikinews, they have links for linking to articles on other sites via a template at the bottom of every article. It could probably be turned into a script for those certain users that want to share articles, since it isn't needed for widespread use here at Wikipedia. --J36miles (talk) 22:32, 6 February 2013 (UTC)

That's the exact problem I mentioned above though. It focuses on the editors, without taking care of the readers. There's far more of them so they're far more likely to share articles. They can't use a script. We could create a script to turn it off for editors who want it off though. Ryan Vesey 00:07, 7 February 2013 (UTC)

Let me expand on Ryan's perspective: Wikivoyage has a great little "essay": voy:Project:The traveller comes first. That concept is at the heart of most policy discussions on WV - does the proposal benefit the traveller, who is the actual user of WV's content? In our case, we should be reminding ourselves to "put the readers first". Will our readers want this? Judging by how much use share buttons are used on other websites, yes, they will. It is standard fare on websites these days. Our readers may have privacy concerns, but these can be worked around easily (we are not obliged to use Facebook's own social plugin, and WMF probably wouldn't let us anyway). Put the reader first, not the editor. — This, that and the other (talk) 11:16, 7 February 2013 (UTC)

Two questions though. One, is there ANY language version of WP with a share button or similar? And two, are there are other major websites with said buttons that are non-profit and don't have any advertising? ♫ Melodia Chaconne ♫ (talk) 14:37, 7 February 2013 (UTC)

Just what problem are we trying to solve here? Has some web browser out there had an update that removes the ability to copy and paste URLs? It's easy to post a Wikipedia link anywhere else without giving up user privacy. Just because "other websites" don't respect user privacy doesn't mean that hosting social websites' tracking code would somehow be providing a service to our readers. Ntsimp (talk) 16:07, 7 February 2013 (UTC)

The tracking code issue is a bit tangential. While it's been brought up in the earlier discussions - and I agree entirely it's a thing we should never countenance - it seems that it would be practical to implement (eg) a Facebook share button without using any of Facebook's own code, or allowing them to track our readers in any way. There are reasons for and against a share button, but the horrendousness of some of the default-provided ones isn't an issue. Andrew Gray (talk) 18:12, 7 February 2013 (UTC)

So what exactly do people want to do with this? Is it going to be implemented or?

An WP:RFC would probably be the next step. — This, that and the other (talk) 07:04, 9 February 2013 (UTC)

The Sharebox user script uses the AddThis bookmarking service to add e-mail and share buttons to the Wikipedia toolbar. As of February 2013, AddThis supports 344 services. A few highlights:

• Blogging platforms— LiveJournal, Twitter, Tumblr, TypePad and WordPress
• Bookmarking sites— including the reference management sites CiteULike and Connotea
• Email— generic, AOL Mail, Gmail, Hotmail and Yahoo! Mail
• Social news— Digg, Fark and Slashdot
• Social networks— Facebook, Google+, Myspace, orkut, LinkedIn and Plaxo
• Shopping— Amazon.com and Kaboodle
• Tools— Google Reader, Google Translate, W3C HTML Validator, print tools, PDF tools, screen capture tools and Whois

A couple of issues:

• Our resident vandal-catcher bot User:ClueBot_NG would like to expand its dataset of human-reviewed edits.
• The Welcoming Committee would like to welcome all new constructive contributors to the project, it's been noted that often the first message received by new users is unfriendly and offputting.

So...

In the course of Cluebot's operation, if could form a list of every edit from a user with a blank talk page. Welcome Committee members could then review these edits, adding {{subst:Welcome}}/{{subst:anon-welcome}} or {{subst:uw-vandal1}} (or something else) as appropriate. These reviews would also be fed back to the Cluebot dataset.

It's an idea! Would obviously require a little tech. Thoughts, tweaks? --LukeSurl ^{t c} 14:50, 8 February 2013 (UTC)

Not a good idea, with 15,000 new users a month the list will be totally unmanageable from day 1. Additionally regarding the Cluebot review dataset, it's imperative to have as little noise as possible, and there's no problem with this specificity coming at the expense of additional database size. It's very much quality over quantity in an already decent-sized manually curated machine learning dataset Jebus989^✰ 15:01, 8 February 2013 (UTC)

If people are willing to welcome newbies there is no shortage of prospects at recent changes or special new pages, so I don't see the benefit of an additional list. What would be useful would be to have a bot as a backstop - if someone has made say 50 edits without being warned or welcomed then an automated welcome would be better than nothing. That still leaves welcoming as a semiautomated rather than automated process, but just uses automation to fill in the gap where we lack volunteers. ϢereSpielChequers 15:24, 8 February 2013 (UTC)

• If the problems are (1) noise and (2) the list is too long, why not filter it? Have ClueBot add a name to the list every time it registers, say, 5 or 10 non-problematic edits. Ironholds (talk) 18:42, 9 February 2013 (UTC)

There's something I dislike about editing on Wikipedia. The ref tag contents are the same exact color as the rest of the text in the editor. When there are a ton of refs bundled in with the rest of the text, as is often the case, then it often takes some searching. I think that refs, and possibly certain other elements, should be color-coded in the editor, to streamline the editing process by making it easier and quicker to find the text you're trying to edit. Maybe make refs red or something. I'm sure there are many editors who hate hunting through a forest of refs to find the text to be edited. Just my 2 cents. --Humorideas (talk) 16:42, 9 February 2013 (UTC)

Click here, check the box that says "Dot's syntax highlighter", hit save. This would be a very bad idea for universal roll-out rather than an opt-in checkbox, as color-coding would screw up screen readers. 89.242.85.135 (talk) 16:50, 9 February 2013 (UTC)

Thanks. Doesn't seem to work all of the time, but it should do. --Humorideas (talk) 17:16, 9 February 2013 (UTC)

In the US, there is a general belief that we currently live in an age where anything can be learned free of charge online - with Wikipedia as one of the main learning routes. While Wikipedia does contain a great deal of information that is generally reliable, this information is not always presented in a usable fashion. Other Village Pump sections address many of the reasons for this lack of usability - for example, articles that may be overly technical. However, none of these sections seem to address the need for a "recommended reading order."

As an example, let's imagine someone with close to zero background knowledge would like to use Wikipedia to learn about computer science. That person may start at the main article but not even read a full paragraph before s/he has to read other links in order to even understand an introductory article to computer science. The person may "get lost" by having to flip back and forth between so many articles. Additionally, let's image that this person had instead started at an article on computer programming without realizing that this was a subset of computer science (per se) - that person may end up reading about typing systems, programming paradigms, and memory allocation in a completely random order that also leads to confusion. While some learning styles (e.g. global learners) may excel under this "random order" format, it is generally believed by the US educational community that many other learning styles - including sequential learners, the most common learning style - struggle under these conditions. They do best if there is a recommended order in which to read topics so that a person who reads them in order will (theoretically) always understand the majority of an article that s/he is reading. To go back to our basic example, a person should be able to click on "learn computer science" and have a recommended order for reading articles that will start with basic background and lead to more complex articles in a way that ensures that the learner will thoroughly learn as much about the topic as desired in a way that is not "confusing." For those who start in less basic areas (in our example, at programming instead of general computer science), there should be an indicator that denotes that there are more basic articles (and which ones there are), as well as more advanced ones.

I think that it would be possible for Wikipedia to crowd source such a project to available experts. For example, college instructors should be able to list which articles should be "pre-requisites" for later articles. Then, these lists could be added to portals or made available on the main page. I think they would greatly improve Wikipedia as a general learning tool and would help establish Wikipedia as an alternative to mainstream (e.g. college) educational practices.

At the very top right of the Main Page, there are links to eight different portals (such as the Arts or Technology), plus a link to Portal:Contents/Portals, which is an excellent resource for anyone wanting to start at the "ground floor" for a particular topic. But for an actual education-minded path, I don't think that's a good fit for Wikipedia itself; we're a reference website, not an education website. What you're talking about seems like a much better fit for Wikibooks. EVula // talk // ☯ // 20:33, 7 February 2013 (UTC)

Sounds more like Wikiversity. Rmhermen (talk) 02:17, 8 February 2013 (UTC)

I suggest you also check out the Wikipedia-Books project. It provides sequenced lists of articles pertaining to a particular subject area, that can (as a bonus) be downloaded as a PDF or even ordered in print form. — This, that and the other (talk) 04:31, 8 February 2013 (UTC)

Structuring our content in a hierarchical way is what outlines are for. Many of them are in a poor state however and I am not sure how much support they have from the community in general. Maybe we could try to improve our outlines in a more systematic way. It would be cool if they could be made more visually appealing by restructuring them as organizational charts. I don't know how that could be implemented though. -- Toshio Yamaguchi 13:01, 12 February 2013 (UTC)

Wikipedia:Article_Incubator#Time_limit states that: Content intended for mainspace should not be kept forever on subpages.... and Pages in the incubator may be nominated for deletion through Wikipedia:Miscellany for Deletion after a reasonable time has been allowed for development. No guidelines are given regarding what is reasonable. I would like to suggest that time is of the essence and that a month should be ample for a dedicated editor to get the article into good enough shape to return to article space. I would further like to suggest that a bot identifies pages in Category:Articles in the Article Incubator that have not been edited for more than 30 days and moves them to Category:Articles in the Article Incubator nominated for deletion, by setting the parameter | status = delete in {{Article Incubator}}. These pages can then be manually reviewed and submitted to MfD. Illia Connell (talk) 01:58, 10 February 2013 (UTC)

(BTW, I notified the AI project of this proposal here. Illia Connell (talk) 00:21, 12 February 2013 (UTC))

The community essentially abandoned the Article Incubator about 2 or 3 years ago. There are still a bunch of articles in there that were updated at the time but have never been reviewed by anybody. A shame really. Part of the problems of a declining community I guess. 64.40.54.47 (talk) 17:02, 11 February 2013 (UTC)

I'll just add that most articles today are userfied instead of incubated. Also, if anybody wants to review the incubated articles, I'm sure the original authors wouldn't mind (although I doubt they are still here). 64.40.54.47 (talk) 17:08, 11 February 2013 (UTC)

Thanks for the info. Perhaps we should delete all the articles per WP:STALEDRAFT and mark the project as {{tl:historical}}. Regards, Illia Connell (talk) 17:27, 11 February 2013 (UTC)

Lets userfy anything less than 1-year old, as a practicable time limit, and delete those older than 1-year old with no activity for 1-year. Those older than 1-year old, and having activity in the last year, should be userfied as well. Any article (regardless of age) seemingly in acceptable condition for creations an article should be moved to WP:AFC and flagged for consideration. -- 65.92.180.137 (talk) 21:52, 11 February 2013 (UTC)

NOTE, WP:AFC now has a draft/working-copy process to flag under construction articles not yet ready for consideration, so perhaps AI should be merged into WP:AFC... where users improving articles created by others work on this draft-article process? -- 65.92.180.137 (talk) 21:55, 11 February 2013 (UTC)

All great ideas, although userifying and merging with AFC is above my pay grade! Also, can we compromise on a shorter time interval to send articles to MfD - how about 6 months? Regards, Illia Connell (talk) 00:18, 12 February 2013 (UTC)

I am not that much aware of the (de)merits of the Article Incubator. Yet I think that userfying is probably not a good idea. While in the Incubator it is relatively easy to search - Special:PrefixIndex/Wikipedia:Article_Incubator - and check them; and there is a (small but non-zero) chance of someone improving them. Or sending to deletion. Scattered around on user subpages they're harder to find. So I do not support the idea to userfy, I do support MfD'ing old ones. I never looked much into AFC, but the concepts are similar, so a merge may be useful. - Nabla (talk) 00:40, 12 February 2013 (UTC)

I support MfDing the hopeless old ones. I do not support MfDing any which have promise of becoming an acceptable article. And that's what I thing about AfD also. Just as there is no deadline on improvements of an existing article, there ought to be no deadline in constructing an article either, as long as it is NOINDEX and is not harmful in some positive way, such as abuse or advertising or a gross BLP violation or copyvio. Sorthing out the hopeless ones will not be rapid, because they all really need an individual check to see if they have potential, and I think any attempt at trying to remove them faster than they can be checked would be counterproductive. My advice, here as always when there's a large body of questionable material, is to start at both ends, removing the worst and improving the best. DGG ( talk ) 01:00, 13 February 2013 (UTC)

• Comment I just checked a random one (Wikipedia:Article Incubator/Billy Corben), threw a {{Find sources notice}} on the talk page, checked news & book hits and found it easily passes WP:GNG. This can simply be moved to article space (over the current redirect) as it's a start class article already. Doing the easy ones would be a quick way of making some progress. 64.40.54.22 (talk) 08:20, 14 February 2013 (UTC) P.S. I just listed this at WP:RM/TR, so that's one down. 64.40.54.22 (talk) 08:42, 14 February 2013 (UTC)

I plan to start a large scale manually performed NFCC enforcement editing task soon. This message is being left here as a courtesy for information of the community. For details regarding the task, please see User:Toshio Yamaguchi/NFCC task. -- Toshio Yamaguchi 23:44, 13 February 2013 (UTC)

Have you thought about working with some of the editors that use WP:FURME, Some are listed here. They may be willing to simply fix the fair use rationales that need fixing. Perhaps you could post a note at Wikipedia talk:FurMe and ask for help fixing the problematic fair use rationales. Just a thought. I don't work in this area, so I'm not familiar with all the related issues. 64.40.54.22 (talk) 07:50, 14 February 2013 (UTC)

As long as WP:NFCC is policy and WP:NFCCE is part of it, the burden to provide a rationale is upon the people who want to use the non-free content. Anyway, since I publicly announced this task and the tagged files will be added to a maintenance category and stay there for at least 7 days, anybody is free to provide a rationale. Also note that I will not touch files (at least while performing this task) where there is a rationale which may simply be bad. -- Toshio Yamaguchi 08:15, 14 February 2013 (UTC)

We certainly need to limit our fair use images and the ones we have absolutely must comply with NFCC. You have policy on your side, but sometimes these things can be complicated. A few people that have worked in this area have seen some resistance from the community. And a few have been raked over the coals because of their work in this area. What I'm trying to say is that you might not get much feedback now, but after the images start disappearing, you might get some upset people complaining. It's best to be aware that this might happen so you can be prepared for it. Taking some precautions now may help you later. Sometimes the community can be rather harsh in its response. Best regards. 64.40.54.22 (talk) 14:23, 14 February 2013 (UTC)

I separately notified the users of FURME of this task at Wikipedia talk:FurMe. I think I've made nearly any form of announcement that seems plausible. Now of course nobody can predict what will happen, so we'll see. -- Toshio Yamaguchi 15:20, 14 February 2013 (UTC)

I've posted a draft Individual Engagement Grant proposal on Meta: meta:Grants:IEG/Wikipedia Massive Open Online Courses. If you're interested in the idea of a Wikipedia course on one of the new MOOC systems like Coursera or edX, please take a look and give feedback.--ragesoss (talk) 02:57, 12 February 2013 (UTC)

I've commented there, but I may as well do so here, too... I like the idea in principle but, please, anything but Coursera! --jbmurray (talk • contribs) 07:03, 12 February 2013 (UTC)

Why not Coursera? Lova Falk talk 08:09, 12 February 2013 (UTC)

Well, there are many critiques of the Coursera model out there: in short, it's part of a massively-capitalized attempt to capture the digital commons. See here, for instance. Note incidentally the last line of that post, on "Wikipedia, which, come to think of it, makes an interesting foil for the nascent for-profit MOOC industry..." It'd be sad to see Wikipedia become complicit rather than a foil to this burgeoning industry.

Me, I'm not against MOOCs per se. I'm more with Cathy Davidson's comments on the topic. --jbmurray (talk • contribs) 08:38, 12 February 2013 (UTC)

Doesn't the existence of Wikiversity make some conflict that may make the course get rejected? -- 65.92.180.137 (talk) 09:05, 12 February 2013 (UTC)

Wikiversity is largely a failed project. Sven Manguard Wha? 22:35, 16 February 2013 (UTC)

Note that discussion is picking up at the proposal talk page.--ragesoss (talk) 16:48, 12 February 2013 (UTC)

Similar to the "minor" edit checkbox when you make an edit, I think it would be a useful feature if there were a vandalism checkbox for when you undo or rollback an edit. The statistics would have obvious uses identifying possible problem IPs or users.TeeTylerToe (talk) 09:43, 16 February 2013 (UTC)

Comment The edit summary could be used to do that with the help of some kind of script, I'd think (if it is actually used and some form of the word "vandalism" appears there). GenQuest ^{"Talk to Me"} 09:57, 16 February 2013 (UTC)

Most active vandal fighters use tools like twinkle that give them the option to choose to mark edits as vandalism. see also WP:ROLLBACK#Additional tools. Beeblebrox (talk) 16:29, 16 February 2013 (UTC)

Hi. This is just a gentle reminder that Wikipedia:Requests for comment/Article feedback is scheduled to wrap up on Thursday, February 21. Any and all editors are encouraged to participate in the discussion. --MZMcBride (talk) 06:38, 17 February 2013 (UTC)

I want to request so everyone have to fill up the "Edit summary" before you can submit your edit to reduce vandalism and to explain changes. As some people seem to not explain their change/s after edit on the "Edit summary" regardless if it's a vandalism or not. --Mr. Washee Washee (talk) 11:46, 13 February 2013 (UTC)

Given that edit summary prompts have been perenially proposed and rejected, I think it's safe to say that this more extreme version of the same idea is not going to get consensus. Yunshui 雲‍水 11:53, 13 February 2013 (UTC)

Question: Is this proposal to promote Help:Edit summary to guideline or policy? If not, then I'd oppose this, because there is no requirement to use edit summaries. -- Toshio Yamaguchi 13:43, 13 February 2013 (UTC)

Anyway, forcing editors to always use edit summaries might be counterproductive. -- Toshio Yamaguchi 13:47, 13 February 2013 (UTC)

There has just been a long discussion about this here. Lova Falk talk 14:43, 13 February 2013 (UTC)

Wow, I didn't know that guys, thanks. I just had a quick look and saw what you mean. Toshio Yamaguchi, in a way yes. I also wonder if some editors (mostly unregistered or new users) even recognise if it's there. But I still stand up to what I requested and hopefully one day it will pass. But I can also see why it wouldn't pass either once I had a look at what other people say on this section and other section similar to this. --Mr. Washee Washee (talk) 21:01, 13 February 2013 (UTC)

It is a good idea in theory, but check out my edit summary for this post to see why mandatory summary input isn't likely to change much. Resolute 21:23, 13 February 2013 (UTC)

Vandals tend to not tell the truth regarding their edits. Most do not announce that they have just torn an article to shreds. I've seem some really crafty and sly edit summaries that one would swear would be a good edit if you didn't take the time to check it out. ツ Fylbecatulous talk 14:17, 18 February 2013 (UTC)

Why do you think that forcing people to submit an edit summary would make them less likely to commit vandalism? On the contrary, requiring an edit summary would make vandals and newbies a little harder to spot. I'd accept that disadvantage if there were an advantage that outweighed it, but I don't see why requiring an edit summary would lose us any vandals. It might however just lose us the occasional goodfaith newbie who just wants to fix a typo or correct some error and gets thrown by the final straw of a little extra complexity. ϢereSpielChequers 14:41, 18 February 2013 (UTC)

When I started editing Wikipedia, there was a watchlist notice with a goal to add references to all unreferenced BLPs. Clicking a link in that notice would bring you to a random unreferenced BLP for you to add references to. There was a progress bar that showed the process of clearing the backlog. I would like to propose that another Wikipedia-wide backlog reduction goal be set. I don't have a huge preference in regards to which category we use. Personally, I think referencing is a huge issue and we should start with Category:Articles lacking sources from October 2006 (or create a new category with some combination of categories from Category:Articles lacking sources. Per Special:Statistics 134,639 registered editors have made an action in the last 30 days. If each one of those editors tackled two articles from the category, the entire backlog would be removed. I'm sure requests like this are normally spammed on other noticeboards, but I have no idea where to spam this to, so if anyone wants to do so, please go ahead. Ryan Vesey 21:18, 17 February 2013 (UTC)

I've informed the watchers of MediaWiki talk:Watchlist-details. Ryan Vesey 21:20, 17 February 2013 (UTC)

• I've got a busy week and will be gone for the next 7 days. If people want to discuss this proposal in the meantime, go ahead, otherwise I'll reintroduce it when I am back editing again next week. Ryan Vesey 22:56, 18 February 2013 (UTC)

From one month alone, 1,434 unreferenced templates have remained in place for more than six years. I wonder how many have been removed? That would indicate how successful this template approach has been at addressing the issue. It may be that these articles just don't have the necessary references available. Or there could be other explanations. Praemonitus (talk) 01:16, 19 February 2013 (UTC)

A while back, HotCat was enabled by default for all registered users, after this discussion. Since then, I've spotted a recurring issue with new users: on user talkpages and some other talkpages, inexperienced editors are using HotCat in an attempt to start a new thread. The logic behind this is understandable (new sections go at the bottom of the page, there's a lttle + sign at the bottom of the page, + means "add something", it opens a field you can type into: QED, that little + button is how you add a new section), but the result is invariably the addtion of a redlinked category and a confused new user. User:Zerosprite was recently blocked for repeatedly trying to start a discussion using HotCat, which brought home to me the seriousness of the problem. Several potential solutions present themselves:

• Disable HotCat by default, and make it an opt-in gadget again.
• Disable HotCat on talkpages.
• Change HotCat's interface appearance to make it less easy to confuse with a content addition tool.
• Limit HotCat so that it can only add preexisting categories, not any text added.
• Do nothing, and simply explain to new users that they've make a mistake when it happens.
• Change the MediaWiki interface so that a New Section link appears at the bottom of talkpages as well as/instead of at the top.

I'd be interested to hear other's opinions of these ideas, or any other solutions to the problem. I'd also like to know if other people are encountering this; I do most of my work with newer editors, so I may be getting a biased sample. Yunshui 雲‍水 10:01, 18 February 2013 (UTC)

I love having HotCat and use it meaningfully and correctly, I hope. One thing that did surprise me though, when I first was gifted with it: If you just click on the empty + sign at the end of the row to the right and enter something (anything), it is an automatic save: no chance to review or change your mind. Only if you click on the "modify several categories" option way at the left of the page are you then presented with a preview of what you've just done before your edit can be saved. This happens automatically when you click on save, if you are modifying several; there is no way to save until, at least, the edit preview screen shows up to give you a chance to tinker. When I was first experimenting with how HotCat worked, I accidentally entered some crazy category by doing the single + sign edit choice at the right side of the category row and had to revert myself. Perhaps this could be changed. Fylbecatulous talk 14:36, 18 February 2013 (UTC)

Hi folks. Two grant proposals I submitted for an individual engagement grant are up for review:

• The Wikipedia Library - An expansion of the Wikipedia Library program, to attract new donors, improve outreach to research databases, and prepare for improved technical integration and management of donated accounts
• The Wikipedia Adventure - Creation of an interactive, educational, guided journey for new editors, integrated with the new Guided Tours functionality.

I'd love your feedback, comments, questions on either/both proposals. Cheers, Ocaasi ^{t | c} 20:33, 18 February 2013 (UTC)

In Infobox about a person, the "birth_name" displays as "full name". This is a problem with people like Garry Kasparov, whose birth name is different from his full name now. Could "birth_name" display as "birth name"? And could there be a "full name" field? Bubba73 ^{You talkin' to me?} 02:30, 19 February 2013 (UTC)

In my opinion the proliferation of prominent scare banners at the top of articles, often timestamped with increasingly ancient dates, sometimes five years ago or more, makes Wikipedia look like it is broken and unmaintained. 86.130.67.84 (talk) 18:43, 14 February 2013 (UTC)

What do you suggest? --j⚛e decker^talk 19:56, 14 February 2013 (UTC)

Make them less prominent and less damning of whole articles (except where the entire article really is crap, which is a small minority of cases). When a reader first alights on a mostly worthwhile article, informing them that someone in 2008 thought the article needed more citations is not the screaming priority that this system of banners seems to assume. 86.130.67.84 (talk) 20:53, 14 February 2013 (UTC)

Maybe Wikipedia is a bit broken and unmaintained... But I somewhat agree you. Maybe people tend to cooperate by *adding* up their contributions, so there is less of a tendency to remove warnings then to add them. - Nabla (talk) 21:12, 14 February 2013 (UTC)

Er, it's not just that "someone in 2008 thought the article needed more citations". Often it's more like "someone in 2008 thought the article needed more citations - and no one has disagreed since". And in that case it is doubtful if we are really dealing with "a mostly worthwhile article"... After all, sources are the most important part of the article. The text simply gives context to sources.

Likewise, "makes Wikipedia look like it is broken and unmaintained" is not a problem. Well, many articles are "broken and unmaintained". Why should we hide that? It's not like we should dishonestly inflate the reputation of Wikipedia.

On the other hand, if the tags mark a non-existing problem, they should be removed. But you do not need Village pump for that. --Martynas Patasius (talk) 23:11, 14 February 2013 (UTC)

Indeed. This category might be a worthwhile example. Take a look at what's in there, and tell me what you find. You don't have to look at all 400, a dozen or two will do.

More importantly, I really don't believe that making the tags less visible is going to make them less objectionable to folks. It may reduce how often they actually get acted on, but .. of course, what we want *is* for them to be acted on. --j⚛e decker^talk 02:15, 15 February 2013 (UTC)

Maintenance banners that note credibility or neutrality issues are probably useful for visitors. Banners that are directed solely at Wikipedia editors (such as notability templates and merge requests) may be too distracting. Could the second category be hidden, or made less visible, for non-registered visitors? Praemonitus (talk) 02:29, 15 February 2013 (UTC)

Unfortunately in my experience tags "that note credibility or neutrality issues" are an extremely bad predictor of whether such issues actually exist, & rarely encourage any of our dwindling band of text editors to sort out issues. I'd agree the long-term ones (ie not merge requests & similar) could well be smaller, or even visible only to registered users who have set a preference. "This article needs more citations" or whatever is little use to most readers and, again, a fairly poor predictor of whether the article has fewer citations than most. In the pioneering days of WP people actually used to go round clearing up tagged articles, but there's little of that now, as the queues show. Johnbod (talk) 20:36, 15 February 2013 (UTC)

Yes, that does seem to be the case. Perhaps the approach needs a re-think? Praemonitus (talk) 00:31, 16 February 2013 (UTC)
P.S. The {{Orphan}} template can probably be automatically removed in many cases.

I fully agree that the banners can be shorter. Banners for editors (those that are not useful for readers) can be put on the Talk page. Lova Falk talk 08:21, 16 February 2013 (UTC)

Shorter—OK; Talk page—No. They would be missed there. Consequently less editors realizing a fix is needed. Less incentive for a newbie to try to help out by making their first edits. GenQuest ^{"Talk to Me"} 09:47, 16 February 2013 (UTC)

Have any studies been performed that demonstrate a correlation between the presence of a maintenance banner and the number of constructive edits performed by new editors? For me at least, some of the banners actually deter constructive edits. I sometimes perceive a "it's not worth the significant effort required to fix this broken article" message.

For example, I just randomly came upon the Chloe O'Brian article. It has five year old banners and plenty of anonymous edits, but none of them appear intent on actually addressing the banner messages. It would require significant effort to address those concerns, so why bother? Praemonitus (talk) 22:19, 16 February 2013 (UTC)

I've spent a high proportion of my time here in the last 3 years doing cleanup, and I've noticed a few things. Things get tagged primarily by bots, single editor crusades (often AWB or database report driven) or NPP work and a lot less by "natural attrition" or normal editing. Things get untagged by changing the rules (ie orphans used to be <3, now it's 0), by single editor crusades or the occasional backlog drives (ie GOCE's work, or some WikiProject collaborations). Most editors just don't seem to care about the tags. I'm very proud that I was involved in the work that WP:URBLPR did getting the CAT:BLP down from over 50,000 to essentially 0 (only deletion candidates). But when we looked closely at who was doing the work, it was about 10-20 of us doing 90% of the work, and probably 3-5 doing 50% of the work. Likewise, I'm very proud that my preferred project, WP:WikiProject Australian rules football has it's cleanup list down to under 9% of articles (of course I know that it doesn't mean that we have 91% perfect articles, but we (I) try to fix what's been tagged). When you look at how most other projects are going, very few move by more than a couple of articles each week, unless it's a bot pushing it up, or an editor/project drive pushing it down. In late 2011 it was suggested that we drive to clear all of the 2006 and 2007 tagged articles in WP:Australia... and we (well, not really we, it's again only 2 or 3 editors, not me) are still going. Natural attrition spread amongst 4 million articles doesn't do much.

So I generally agree with the ineffectiveness of banners. It's the associated categorisation that may lead to improvement, not the banners. I'm all for inline templates ie {{citation needed}}, as they highlight a specific issue about a specific section of content in the article. But overarching tags like {{refimprove}} don't really do much to the reader, and are shown to be fairly ineffective to prompt editing.

Proposal: Could we have a system where the full banner is shown for the first 3 months after it is tagged (ie only show the ones dated Dec 2012 - Feb 2013 at the moment, auto change to Jan to March 2013 on March 1) and then automatically hide or shrink it (small box to the right, like the "Wikimedia Commons has media related to:" box size, saying "this article has issues to be resolved" or similar. {{side box}} seems to be the box generator) to be less obtrusive after that. Keep the categorisation going, so that cleanup lists track it, but make the article look better whilst it's waiting to be improved. Because having giant banners has been proved not to work by the existence of the extensive backlog in most cleanup categories. The-Pope (talk) 07:11, 17 February 2013 (UTC)

And why is "mak[ing] the article look better whilst it's waiting to be improved" a good thing? I would understand if it simply means that the tags are not beautiful - but in such case the solution is making tags beautiful, not hiding them. But having a hidden tag will simply take all flaws from having a tag and not having one. In some cases tags are not removed when the problems are gone. Well, they will stay for even longer periods if one won't be able to notice them.

The problem is that you seem to assume that tags are meant to encourage newbies to correct the articles. But there are more objectives:

1. To mark the articles for the editors that specialise in cleanup (for example, you).
2. To show the readers that there is something wrong with the article and they should be especially careful.
3. To show the readers (potential and actual editors) that this article should not be used as an example for other articles in some respects (in other words, to educate the potential and actual editors about Wikipedia's policies and the like).
4. To show the writers what they did wrong.

Hidden tags are not going to perform functions 2 and 3. Functions 1 and 4 will also be impeded.

Finally, there is one more thing. In many cases the articles actually are really hard to clean up. No tags are going to change that. If we want real improvement in such case, then a tag like Lithuanian "lt:Šablonas:Beviltiškas" should probably be used. It says that the article is hopeless (having numerous problems that make it almost impossible to adapt it to Wikipedia) and if one can write just a couple of reasonably good sentences to replace it, one should do this. In a sense, it is a "dispensation" from WP:PRESERVE. If that doesn't work for several months, the article gets deleted, leaving red links. That's the solution if someone really wants to reduce backlogs. But in such case it should be agreed that "in some cases, deletion is 'clean up'"... I am not sure if community is ready to endorse this... --Martynas Patasius (talk) 16:37, 17 February 2013 (UTC)

I like the gist of The-Pope's suggestion, although I'd suggest a longer interval such as a year. Regarding Martynas Patasius's points: #1 – doesn't need to be visible to readers; #2 – most of the templates don't serve this purpose, and those that do are directed at editors rather than readers; #3 – seems purely punitive; #4 – shouldn't this be be handled through user talk pages? Of these, #1 can be handled via editor-visible markers, while #2 should be specifically focused at the reader rather than the writer. Both #3 and #4 seem instruction-focused, which strikes me as an invalid use. Praemonitus (talk) 18:54, 17 February 2013 (UTC)

I guess a reminder that there is no significant difference between "editors" and "readers" is in order. All readers are potential editors. All. In many cases this potency doesn't get actualised (to use jargon of Aristotel or St. Thomas Aquinas), but it doesn't mean that it doesn't exist. Thus all declarations like "doesn't need to be visible to readers [but has to be visible to editors]" are invalid.

"#2 – most of the templates don't serve this purpose, and those that do are directed at editors rather than readers;" - which do not? In the previous version of your post ([2]) you mentioned an unreferenced article (relevant to everyone reading the article, since it is the references that give articles value; the text just gives us them context), "a three year old notice about an article reading like an advent that has long since been addressed but never removed" (would be relevant to everyone reading the article, if the problem was there; but the tag is even less likely to be removed if no one can see it) and "[a] four year old notice telling the reader that the article is an orphan" (actually, I don't think that orphan tags are useful to anyone - some lists would be more useful in this case). I don't see how your objection applies to any of them...

"#3 – seems purely punitive;"... Punitive..? So, who gets punished..? I don't think I understand this objection.

"#4 – shouldn't this be be handled through user talk pages?" - yes, that is one alternative. But it requires more work and the benefit is not necessarily worth the effort.

"Both #3 and #4 seem instruction-focused, which strikes me as an invalid use." - well, it doesn't look like invalid use for me... Would you like to elaborate..? --Martynas Patasius (talk) 20:46, 17 February 2013 (UTC)

The difference between editors and readers is the person's own intent. Our aim is to be useful to people who come here to look stuff up. Our means includes the fact that they can also change stuff, if they like. Just because the same person can act in both capacities doesn't mean there isn't a distinction, or that it isn't useful to keep the distinction in mind. It should be kept in mind when deciding how to present information on the article's topic, versus "meta-information" on the article itself. --Trovatore (talk) 21:01, 17 February 2013 (UTC)

I agree with Trovatore. Nobody is an editor until they click on the edit button; until then they are readers. Logically, the concern of a non-editing reader is the information on a page; not with Wikipedia editing policies, cross-article linking, notability requirements, potential merges, article structure, or even trivia. The reader wants reliable information about the subject. Warnings about potentially unreliability, neutrality, advertising, and possibly about poor writing would seem most relevant to a reader. Praemonitus (talk) 22:14, 17 February 2013 (UTC)

Er, you might count that nobody is an actual editor until pressing one of edit links. But the reader is always a potential editor. Let's keep the terminology (as in Potentiality and actuality)) correct.

Still, I'd say that actualisation of the potential to be an editor already starts when one makes a decision to edit (if not earlier). That happens before pressing any link.

And at that moment the future editor is indistinguishable from future non-editor. That's one reason why all talk about "readers" and "editors" as if they had nothing to do with each other is flawed.

Finally, I find all talk about needs of readers strange. We do not know what thousands and millions of our readers need. Let's not pretend that we do. Let's make a good encyclopedia for its own sake. That's our mission anyway, and the readers are likely to benefit (or otherwise they shouldn't be readers). --Martynas Patasius (talk) 00:03, 20 February 2013 (UTC)

Well, quibbles about self-imposed terminology aside, I believe the discussion is focused on making a good encyclopedia. The original point being that the banner messages don't make for a good reading experience. An encyclopedia perpetually littered with "under construction" signs is not an encyclopedia that is focused on its readers. If the percentage banners don't fade away over time, then they're not doing their job. But that is something that Wikipedia could, and perhaps should, be measuring statistically. As for what the readers need, well we're all readers as you repeatedly stated. Praemonitus (talk) 02:00, 20 February 2013 (UTC)

Well, perhaps I should have added a smile after "Let's keep the terminology [...] correct."...

Still, good terminology does help to formulate the arguments precisely. For example, you say "As for what the readers need, well we're all readers as you repeatedly stated.". Well, I guess it means that some of your arguments that have been worded in the way that concerns what the readers want, actually mean that you do not like tags. Well, maybe you should actually say so, instead of calling yourself (and, I guess, the ones who agree with you) "readers"..? For, well, I am a reader too and I like the tags. So, I guess that in this unrepresentative sample half of the readers like tags and half do not..?

And that precision would help. I can ask you why do you dislike tags. I cannot ask "the readers". I can try to persuade you, to negotiate with you. But I cannot do that with "readers". I can only dismiss "their" concerns as uninformed and irrelevant. --Martynas Patasius (talk) 22:39, 20 February 2013 (UTC)

On the whole I was simply agreeing with the OP and expanding upon the concern a little.

If you want a personal perspective, then my additional concerns are two-fold: (1) many of the banners appear to only be of interest to a pool of dedicated editors who are intimately familiar with Wikipedia policies, and (2) the banners occupy a region of the display that represents part of the interface rather than being part of the article. The first issue may potentially be a source of distraction and confusion to visitors. The second looks to my eyes like a useability hindrance.

Obviously I can't say how much of a problem these represent for others; for me they appear to be an interface design issue that can be addressed without significantly hindering the purpose of the templates. For example, the templates could appear for some interval of time (say ~5 seconds), then retract into a smaller form that can be manually expanded (perhaps via JavaScript). Praemonitus (talk) 02:51, 22 February 2013 (UTC)

• As a result of this discussion I've made this proposal below. Ryan Vesey 21:36, 17 February 2013 (UTC)

Many users of Wikipedia simply read articles and don't get involved in editing them, possibly because they don't know that they can actually do this, or perhaps because they are unsure of what to do, or are nervous about getting it wrong. Help and guidance is available, but it isn't necessarily easy for newbies to find.
I propose adding a link to Help:Getting started at the top right of every screen that IP users see, next to the Create account and Log in links. This should help new users to more easily understand how Wikipedia works, and how they can contribute. Bazonka (talk) 08:58, 17 February 2013 (UTC)

What about using Help:Contents instead? That's already linked in the "interaction" sidebar under "Help" - the idea of making it more prominent for users who aren't logged in makes sense to me.. – Philosopher ^{Let us reason together.} 20:44, 17 February 2013 (UTC)

Yes, Help:Contents would be OK as well, but as you say, it is already linked on the page. Help:Getting started seems more appropriate for beginners, but I don't have strong feelings either way. Bazonka (talk) 19:50, 19 February 2013 (UTC)

For consideration - since Help:Contents is displayed under the ► Interaction tab on the left side of all pages. I just made (3 days ago) Wikipedia:Help index - that has it all - one stop shopping - editors can find any help by topic there instead of the runaround you get with other pages. Moxy (talk) 19:56, 19 February 2013 (UTC)

I am using wikipedia extensively to research particular knowledge using a particular path of search, and I found it rather insatisfactory that I can not save somewhere on my account in any satisfactory way these particular paths, so that I can return to the information whenever I need, with ease. I am sure this type of improvement is very simple, and yet extremely powerfull for a lot of people looking for info using wikipedia. Hope to see this feature soon.

"search path" is not well defined, so it's hard to claim this with certainty, but presuming these "search paths" can be expressed in a textual form, you can save them in your userspace: just press "sandbox" on the top menu, and you'll get dropped in a personal page in your userspace. you can open as many such pages as you want - "Sandbox" is just the default name, but has no special meaning. for instance, if you want to save a specific searchpath, and call it, say, "Queen Elisabeth II", what you want to do is type in the searchbox "Special:MyPage/Queen Elizabeth II" (without the quotes) and hit ↵ Enter .

in the form that will open, you'll find an option to create this page (the name of the page will be "User:<YOUR USERNAME>/Queen Elizabeth II). choose it, paste in your searchpath (again, assuming whatever it is you call seachpath can be expressed textually), and hit "Save".

later, you may have many such searches saved, and you may not remember them all: one way to get to them is to go to your user page (i.e., click on your username in the top menu), choose "Page Information" from the toolbox, and from there choose "Subpages of this page". you will see all the previously saved searches.

peace - קיפודנחש (aka kipod) (talk) 17:17, 19 February 2013 (UTC)

• Wikipedia doesn't currently log the reading patterns of individuals (which would be needed for automatic "saving" like this to work) and for privacy reasons it is very unlikely we will start doing so in the future. Andrew Gray (talk) 18:23, 19 February 2013 (UTC)

• Use the bookmark feature in your browser. Easy breezy. EVula // talk // ☯ // 16:23, 22 February 2013 (UTC)

The articles in the name of PROPER NOUNs may be titled in a fashion that would enable one to easily differentiate it from the same word/phrase literally meaning itself, without having to actually visit the corresponding page. In the case of presence of more number of articles that naturally have the same name, we use (description) like xxxxxxxx_(philisophy), etc. What I am actually trying to convey here is that - what if the same kind of notation is globally adapted for all the articles in Wikipedia, that would help one to decide whether to visit an article page or not by clicking a link from the currently seeing page.

User:Mariraja2007 — Preceding unsigned comment added by Mariraja2007 (talk • contribs) 03:00, 20 February 2013 (UTC)

I'm not sure I understand what you're suggesting. Could you give an example? —Theopolisme (talk) 22:02, 20 February 2013 (UTC)

Here is an example of what I was trying to convey.

When I was going through the Wikipedia article Polaroid_(polarizer), under Related Topics I was able to see Impossible Project. With the curiosity and temptation to find out about it, I wanted to visit that page (An activity which I would later realize as a sheer waste of time). After hitting that link, I found that it is rather the name of an Enterprise that works with photographic materials. Although I was never interested in knowing about such a company, without my willingness I was persuaded to visit that page; which is partly due to my curiosity and partly due to an inherent blot in Wikipedia’s system of naming/titling an article page. This is just an instance, which happened recently so that I remembered. I have faced this several times and also many others would have faced the similar situation of intending to see something and landing up somewhere else.

What I would like to propose here is the usage of one word description of that article in a bracket as in: Mercury (element), The Apple (1980 film) and Einstein (novel) for all of Wikipedia’s Proper noun articles. I know that the same scheme currently exists for disambiguation cases, when conflict arises as described in Wikipedia:Disambiguation. Why not do we extend the same for all of Wikipedia’s articles with a Proper noun as the article’s subject using suitable bracketed tags like: vvvv (Place), wwww (Enterprise), xxxx (Scientist), yyyy (Philosophy), zzzzz (Organization) and so on.

For a person like me, who is a frequent Wikipedia visitor, I believe that bringing such a change would definitely make sense by help avoid wasting time (that happens due to persuasion caused by the system of Naming/Titling).

—Mariraja2007 (talk) 09:21, 21 February 2013 (UTC)

We only use disambiguators when necessary to allow natural linking in most cases. This is much easier than trying to guess what disambiguator would be necessary for each link in a text. Rmhermen (talk) 16:33, 22 February 2013 (UTC)

I propose that the topics "On this day..." and "Did you know..." also appear on the mobile version of the main Wikipedia pages. The ammount of extra data is downloaded is not significant and one of the major and most interesting sections of the main page would also be available for mobile devices. — Preceding unsigned comment added by Guilherme Paredes (talk • contribs) 20:13, 27 January 2013 (UTC)

Hello WP collective,

I'm curious as to whether we've given consideration to any kind of ranking or rating system for edits and editors. I'm thinking some kind of thumbs up/thumbs down system similar to what's used on user comments on news sites but for WP edits instead.

It strikes me that some kind of ranking system should be easy to implement, and might help give clearer picture as to which editors are producing consistently helpful and beneficial edits on WP.

I'm sure I'm not the first person to have this kind of idea. Can anyone point to a previous discussion on a topic like this? I'm curious to know what pros/cons were brought up. NickCT (talk) 16:11, 14 February 2013 (UTC)

I'll gladly look into this for you. But I am pretty sure you wouldn't get much support; many editors would likely feel that the system could be abused or overused, resulting in a less collegial atmosphere between contributors. dci | TALK 00:17, 15 February 2013 (UTC)

I'm also curious to know what the "pros" of such a system would be since I can't imagine how this would improve our content. Beeblebrox (talk) 01:45, 15 February 2013 (UTC)

@Beeblebrox - I can think of two potential pros.

1) It's good to recognize "good" editors or editors who done extraordinary work, right? At the moment, there isn't really a good mechanism to make a rapid assessment of editors' contributions beyond basically looking at edit counts.

A big part of the genius of WP is crowd sourcing. Creating a plus/minus system might be a good way of crowd sourcing recognition of good editors.

2) A plus/minus system might help admins make assessments about editors in ANIs and Enforcements. If I'm an admin looking at an editor and I can see most of that editor's edits are rated pretty negatively, it might influence actions towards that editor.

@dci - re "the system could be abused" - Oh sure. But frankly, how many ideas for new features have you heard about which one couldn't say "it could be abused"? NickCT (talk) 03:42, 15 February 2013 (UTC)

Anyone who would use the number of "likes" and "dislikes" a user has as a way of evaluating a user subject to an ANI thread or other request for sanctions shouldn't even be here. This is not a popularity contest. Admins would get disliked by anyone they had ever blocked, meanings the most effective, dedicated admins would be the most disliked. No, just. no. Terrible idea that is completely incompatible with the idea that we make decisions based on strength of argument and consensus, not numbers. I am confident that I speak for the majority in saying that there is basically no chance this will be supported anytime in the foreseeable future. Beeblebrox (talk) 18:49, 15 February 2013 (UTC)

I agree with Beeblebrox. Terrible idea. Most editors do as well as they can, and if they make mistakes, a friendly note is much better than a load of thumbs down from other editors. Lova Falk talk 19:10, 15 February 2013 (UTC)

I think something in this area is worth exploring. A big part of how Wikipedia works is establishing trust - partly through experience, partly through simplistic cues like "userpage is red". A more systematic way of measuring trust could be useful (with due caveats not to overrely on it, since like any system it would be abusable). For instance, if I could assign users a trust level of 1-10, I could then use that to filter my watchlist (or Recent Changes) - if I'm pushed for time, I might say "show only edits by users with trust level of 5 or lower"). The older Wikipedia gets, the more we need to think outside the box for ways to make maintenance easier. Even if trust levels were kept 100% private (nobody ever knows anyone else's trust ratings, given or received), it could be a useful tool. Rd232 ^talk 19:24, 15 February 2013 (UTC)

See WikiTrust.—Wavelength (talk) 19:44, 15 February 2013 (UTC)

@Wavelength - Interesting site. I like the WikiTrust uses sophisticated "data mining" algorithms that assess the credibility of editors (users that make changes to a wikis content) by tracking their contributions.. I wonder what my WikiTrust score is....

@Beeblebrox - I don't think you're really trying to see the point. We're not talking about "popularity". We're talking about usefulness and productiveness. If I came up for ANI and you were easily able to see that great majority of edits I'd made had been deemed useful and productive by the community at large, you might reasonable look on me differently than if the great majority of edits I'd made had been deemed unuseful and unproductive.

Outside the ANI thing though (which was really just a side point), you really don't see any usefulness in having a tool that would let one rapidly assess the level of contribution of individual editors?

@Rd232 - Yeah. I guess my original thought wasn't one of trustworthiness, but I think that's a interesting line of thought worth pursuing. NickCT (talk) 22:24, 15 February 2013 (UTC)

Actually i think you are the one missing the point. You are talking about how this would work ina perfect world and I am talking about how it would work in reality. Unless 'every single edit by every single user was reviewed by a completely neutral and honest third party this would not do what you think it would, it would just be a tool for miscreants to go on about how they don't like something and conversly a tool for POV pushers and tag team edit warriors to support one another. No good would come of it. This is not facebook and the vast majority of Wikipedians don't want anything that makes WP more like facebook.

If you seriously want to propose this and seriously expect it to happen you need to realize that this would be a very big change in the entire culture of Wikipedia. A thread here is not going to be sufficient, you would need to open a formal request for comment and list at WP:CENT and possibly get watchlist notices and so forth for it as well. If you really believe this has a chance in hell of happening you can go ahead and do all that, but I am telling you right now it would just be an enormous waste of time and this idea will be very strongly rejected by the community. Beeblebrox (talk) 16:40, 16 February 2013 (UTC)

. Tarc (talk) 17:01, 16 February 2013 (UTC)

Suppose everyone starts with the same base score; but those who have less contributions/more negative contributions have a lesser bearing on the difference their vote makes on the overall score. Then the miscreants would have a much lower score themselves, and would not be able to hugely affect the scores of others. TheOriginalSoni (talk) 17:45, 16 February 2013 (UTC)

As for this idea itself, it is a fine idea, and one worth thinking about. I think we should look into the various possibilities and pros and cons and how the algorithm could or could not work. And then try to chalk out a proposal for the same. A well-thought proposal for this might be able to garner community consensus through CENT and RFC. TheOriginalSoni (talk) 17:45, 16 February 2013 (UTC)

I we start getting scored and it is taken the least bit seriously I am sure I am not the only one who will immediately quit this project. Luckily, as i said I do not believe this has any realistic chance of happening anytime soon so I'll leave you all to discuss this absurd, useless fantasy amongst yourselves. Beeblebrox (talk) 17:50, 16 February 2013 (UTC)

Back in 2004 we briefly had an experimental web of trust system - Wikipedia:Trust network. It was a good idea. However, it never took off. Perhaps it's time to give it another try. — Hex (❝?!❞) 18:56, 16 February 2013 (UTC)

Horrid idea, per Beeblebrox. If you want to show someone that you approve of them, leave them a talk page message or something. Sven Manguard Wha? 22:34, 16 February 2013 (UTC)

Talkpage messages don't scale. It's a bit like saying "we don't need an editcount, you can just look at individual edits". The main argument against is really that a public rating would be like editcountitis times a million. Hence my thinking about an entirely non-public system. Rd232 ^talk 16:20, 20 February 2013 (UTC)

@Beeblebrox - re "If you seriously want to propose this" - If you look at my initial post, you'll notice it was more of a question about whether this idea has been discussed before rather than a proposal that it should be so. re "work ina perfect world " - I agree with that definitely. It would be really difficult to get this to work in a way which wouldn't be an unhelpful "popularity contest", but I'm not sure that's a reason to disregard it out of hand. Regardless, I'm a tad surprised by the amount of apparent animosity this idea developed. I think I'm just going to slowly walk away.

Thanks all for the notes about WikiTrust. That appears to be the closest effort to an editor rating system that's been done so far. NickCT (talk) 07:36, 18 February 2013 (UTC)

Bad idea. It would encourage competitive-style editing and it would lessen the collaborative atmosphere. There are already mechanisms to reward and admonish editors through barnstars and templates. Not to mention that thumbs up/thumbs down systems have various problems on other websites. Jason Quinn (talk) 16:46, 24 February 2013 (UTC)

In a history, "updated since my last visit" was added several months ago, which is nice. But it would be even nicer to have a button to click on to show all changes since my last visit. It would be much easier for the user, not having to look at how far down the history that message goes and clicking in the appropriate radio button, and then the show button. Bubba73 ^{You talkin' to me?} 17:23, 19 February 2013 (UTC)

You can click the "cur" link on the most recent non-"updated since my last visit" revision instead of messing with the radio buttons. That's a slight improvement. Anomie⚔ 13:57, 20 February 2013 (UTC)

Yes, but it would be better if the computer could do that for you. It knows which edits have been made since the last visit, so it should be easy to have one button show only those changes (since your last visit). Bubba73 ^{You talkin' to me?} 15:36, 20 February 2013 (UTC)

Hi, Bubba73. I'm not sure what you mean by the "updated since my last visit" feature. I tried to locate it but failed. (I'm using Vector.) Could you describe where (or whit) it is detail? Jason Quinn (talk) 16:52, 24 February 2013 (UTC)

If I go to the "view history" of an article (or talk page), it shows the list of recent edits. Next to the edits that have been done since the last time I viewed the page, it shows "updated since my last visit". Bubba73 ^{You talkin' to me?} 18:10, 24 February 2013 (UTC)

Or on my watch list, click "history" and it shows it. Bubba73 ^{You talkin' to me?} 03:10, 25 February 2013 (UTC)

What about Sweet Brown? Sweet Brown is an american woman, known on Internet for the sentence ain't nobody got time for that she said at KFOR-TV as a witness of a fire near her house. Ĉiuĵaŭde ^Discuss 21:24, 23 February 2013 (UTC)

You personally will need to add a request for that at the proper forum, Wikipedia:Articles for creation. GenQuest ^{"Talk to Me"} 22:03, 23 February 2013 (UTC)

Ĉiuĵaŭde, I can't find significant mention of Mrs Brown in independent reliable sources. This means that we are left with very little biographical information about her, apart from her own declarations about respiratory illness and preference for particular beverages. This would make it difficult to write an article about her. (She does seem to pop up on other articles, though.) --Demiurge1000 (talk) 22:10, 23 February 2013 (UTC)

Discussion Closed.

I had a specific question about notability, so I decided to try looking for the answer in our policies and guidelines, and I quickly discovered you need to have a degree in law to even begin to understand it all. Where is the page that lists out the nutshell version of our policies? I know we have some "broad pages" like the five pillars, but it not helpful in showing an editor where to look to answer their own questions.

Also, why are there no links to our policies and guidelines on the Main Page, or Community Portal? Why do I have to search for policies, shouldn't this information be right there, easily accessible to any user that has a question about content? If we are trying to encourage quality editing, shouldn't we display a general breakdown of how things are? If I were a new editor and I had no clue about how things run around here, I would likely be shocked to discover the thousands of lines of text governing the encylopedia anyone can edit. I think we would do well to showcase the rules we edit by, it would do a lot to encourage a more informed level of participation. --NickPenguin_(contribs) 19:30, 22 February 2013 (UTC)

The very first link on the Wikipedia:Community portal page goes to the Wikipedia:Department directory. There one finds many useful things, including a link to Wikipedia:RULES. However, one does not want to drown new editors in all the policies and guidelines. They are not so central that they should interfere with getting started. The quick overview for beginners is Wikipedia:5P. LeadSongDog come howl! 19:59, 22 February 2013 (UTC)

Honestly I have been to the community portal dozens of times, and I have never noticed that link, it is certainly not indicated to be as important as the content it contains. And even within the Department Directory, the sections on the page appears to be placed randomly. For example, "Fun departments" has more space as "Policy creation and revision", and are both located near the bottom of the page.

I understand we don't want to drown editors in policies, but if we consistently run into problems with new editors creating articles and making edits that are unproductive, shouldn't we introduce concepts like the 5 pillars while they are still readers? Aside from that, my more general concern is that the tome of policies and guidelines as not centrally organized or easy to access. --NickPenguin_(contribs) 20:17, 22 February 2013 (UTC)

Third time this month I have seen a complaint about the way policies and guidelines are organized/presented - perhaps time to turn Wikipedia:List of policies and guidelines into a comprehensive descriptive directory like Wikipedia:Help index or make a new article called WP:Community standards and advice and have it set up with main policies and guidelines and there related essays on advice like with the section Wikipedia:Help index#Community standards and advice. We have Wikipedia:List of guidelines and Wikipedia:List of policies that have some descriptions but again with no relevant advice pages there.Moxy (talk) 20:30, 22 February 2013 (UTC)

That looks like the kind of organization I was expecting. Some indicator of where to look for a certain thing. I would enjoy being part of an endeavour like this. --NickPenguin_(contribs) 21:19, 22 February 2013 (UTC)

I'll add a "me too". Policies and processes just seem hard to find. It took me a while to notice that Department directory link. Praemonitus (talk) 01:39, 24 February 2013 (UTC)

• I think User:Okeyes (WMF) woud be a good contact person from the Foundation for something like this. He was involved n a major restructuring and reorganizing of help pages over the last couple years. Beeblebrox (talk) 23:21, 22 February 2013 (UTC)

Reading Okeyes' talk page brought me to this recent discussion on Jimmy's talk page, which is along a similar line but about Help Pages. The theme between the two problems, is too many pages has resulted in fragmentation of the information. It is just as difficult to find information on Help as it is for Policies and Guidelines. One user suggests it is a problem of having an adequate search function. --NickPenguin_(contribs) 00:37, 23 February 2013 (UTC)

Wish that conversation was seen by Jimbo before it was archived - one bad thing about his page is the archive is set to archive more often then hes at the page. O well - that said i am thinking of starting "Community standards and advice" article over the next few weeks.Moxy (talk) 18:44, 23 February 2013 (UTC)

I get the impression he checks it frequently, he just doesn't always respond. — The Hand That Feeds You:^Bite 23:25, 26 February 2013 (UTC)

The answer is that you keep looking until you find the policy you are looking for or become somewhat certain that one doesn't exist. Yes, the policies are sprawling but this is largely due to numerous issues that must be addressed. Detailed policies are necessary and while summary policies serve a purpose, they do so at the expense of duplication and more policies. The rather imposing collection of polices is a tribute to Wikipedia's success although it's easily missed as such. Jason Quinn (talk) 16:58, 24 February 2013 (UTC)

equally to the point, the real effect of our policies is the way they are applied. Some of them are applied consistently without any controversy, but some are applied to a variable extent, and some have no real consensus about how they should be applied. There is really no practical way to learn all this besides observation and asking questions.`— Preceding unsigned comment added by DGG (talk • contribs) 19:13, 26 February 2013‎ (UTC)

I'd like to propose the revitalization of Template:Plagiarism. I think we need a template to flag articles that plagiarize other pages but that don't implicate copyright violations. To give a specific example, I was checking out George Bourne just a few minutes ago due to a flag it had regarding possible copyvio. It turns out that most of the article is a wholesale copying of a journal article from 1882. So it's clearly not a copyvio, but it's also clearly inappropriate because of WP:PLAGIARISM. I don't have the time or interest to fix the entire article, but I'd like to flag it as problematic and all of the templates I find seem to add it to copyvio lists or otherwise imply that the page is suspected of having copyright problems. This is of course a moot proposal if such a cleanup template already exists, but if so then it should be added to the list of cleanup templates and Template:Plagiarism should be redirected there. Otherwise I say we need a template like this, though. Does anyone agree? -Thibbs (talk) 18:38, 26 February 2013 (UTC)

I do not see anything bad in using out of copyright texts in Wikipedia. The only "fix" required is an appropriate attribution. There no need to tag George Bourne as problematic because it is not. Ruslik_Zero 19:19, 26 February 2013 (UTC)

It seems incredibly sloppy and somehow dishonest to me, but on closer review I think you're right. And there are templates that are supposed to be used for this kind of verbatim copying of public domain material. Namely, Template:Source-attribution and Template:Citation-attribution. I'm pretty sure the George Bourne article will meet Wikipedia's requirements if one of these templates is added. I'll get to that tonight. -Thibbs (talk) 19:32, 26 February 2013 (UTC)

I'm so sorry to drag this out, but I have a problem with the closing statement. Firstly, there were not "only two arguments" made. Usefulness was discussed and accounted for a lot of the discussion, but it was not the only rationale behind comments. A sample of the other rationales:

• Several users (e.g., Trovatore, Future Perfect, Spartaz) argued that SEWP was of insufficient quality to justify giving it priority over other languages in the list. And NaBUru38, It Is Me Here and Kaldari argued that there should simply be no priorities when it comes to the language links.
• This, that and the other argued that it was easier to locate the item in the list if it was in correct alphabetical order.
• Dougweller expressed concern about the effect this might have on contentious articles at SEWP.
• Jayron32 and Legoktm argued that we should make an effort to make this wiki more accessible, instead of relying on SEWP.
• WereSpielChequers agreed that something needed to be done, but argued that we should allow users to set their own language preferences (and thus sort the language bar links accordingly); although I countered that this didn't help the people the proposal was intended to help.
• Melodia, Titodutta, Apteva, Thryduulf, Nouniquenames, Ryan Vesey, Hut 8.5, GRuban, Lukeno94, argued that SEWP was different to other entries in the list in that it wasn't a different language, and that mixing it in the middle made no sense.
• Ajraddatz argued that we shouldn't be promoting SEWP. Hahc21 and 188.26.163.111 argued that they didn't like SEWP. And Futuretrillionaire didn't understand the issue.

A large number of participants gave no opinion as to whether sorting the link at the top would be useful, and the closing statement indicates to me that the user didn't read the thread.

I also have a problem with the tally that the closing editor made. If you just go through and count each of the users that have prefixed their comments with a "support"/"oppose", then, yes, this is the tally you get. However, several users stated their opinion without doing that: Eptalon and CBM explicitly stated that they were in favour of the idea. Apteva and Melodia also expressed similar opinions, and Titodutta indicated that we should either go with the proposal or highlight the link in a different colour. Also, the OP clearly stated that the initial thread had to be closed due to a procedural mistake. Since the original participants in that thread were not notified that the proposal was restarted (and advised that their opinions had to be restated), you shouldn't ignore their opinions. Shearonink and Mirokado, who weren't notified of the proposal being restarted, should also be taken into account.

Numbers can indicate the level of consensus, but we should also be taking into account the strength of each argument. Osiris (talk) 07:24, 25 February 2013 (UTC)

Could this be submited for review from another administrator? I am sure that the strength of the arguments and the numbers together get this issue a go-ahead, even if it has some amount of opposition. I am sure that if one does not read between the lines, some arguments will end up carrying more weight than others (David Levy's point made a lot more sense per se than the one by 188.26.163.111) TheOriginalSoni (talk) 11:08, 2 March 2013 (UTC)

I noticed that there's a book-specific cleanup tag template at {{Cleanup-book}}, but not one for movies. I created one based on Cleanup-book in my userspace: User:Atlantima/Template:Cleanup-film. What do you think? I wanted to get other people's input before I move it to mainspace and start using it, just in case there is already some other template that covers this.--Atlantima (talk) 14:41, 1 March 2013 (UTC)

If you do move it to mainspace, don't forget to add it to the list at WP:AWB/DT. Anomie⚔ 14:52, 1 March 2013 (UTC)

Over at Wikipedia:Help desk#Template variables for number of visits or number of page views? we had a discussion about the {{NUMBEROFVIEWS}} Magic word, and why it doesn't work on the English Wikipedia. (Also see Wikipedia:Village pump (technical)/Archive 98#NUMBEROFVIEWS Magic word.)

I can see how turning it on would be a huge performance hit, but my inner geek is wondering whether a reasonable amount of functionality can be restored if we are willing to accept a once-per-day or even once-per-month update frequency. Or perhaps reduced accuracy with some sort of sampling scheme would work -- just get the numbers for one small part of Wikipedia and apply a best-guess multiplier to get an estimate of the total.

Needless to say, it wouldn't have to be called NUMBEROFVIEWS -- that magic word would likely need to be left as is because other Wikis use it. I would suggest ESTIMATEDNUMBEROFVIEWS.

Even having a human take an educated guess and hand-enter in a number once a week would be better than no number at all.

So, is there any way we can get even a limited "number of views" magic word functionality? --Guy Macon (talk) 00:25, 28 February 2013 (UTC)

There is an external tool that gives you article traffic statistics. --J36miles (talk) 17:30, 1 March 2013 (UTC)

I got the impression from the help desk post that Guy is looking for a project-wide cumulative total. -- John of Reading (talk) 18:42, 1 March 2013 (UTC)

That is correct. The following wikimarkup...

<div>As of {{CURRENTDAYNAME}}, {{CURRENTDAY2}} {{CURRENTMONTHNAME}} {{CURRENTYEAR}}, {{CURRENTTIME}} (UTC), The English Wikipedia has {{NUMBEROF|USERS|en|N}} registered users, {{NUMBEROF|ACTIVEUSERS|en|N}} active editors, and {{NUMBEROF|ADMINS|en|N}} administrators. Together we have made {{NUMBEROF|EDITS|en|N}} edits, created {{NUMBEROF|PAGES|en|N}} pages of all kinds and created {{NUMBEROF|ARTICLES|en|N}} articles, which have been viewed '''-->{{NUMBEROFVIEWS}}<--''' / '''-->{{NUMBEROF|VIEWS|en|N}}<--''' times.</div>

...generates this:

As of Friday, 15 November 2024, 12:49 (UTC), The English Wikipedia has 48,268,007 registered users, 121,930 active editors, and 852 administrators. Together we have made 1,252,786,063 edits, created 61,843,571 pages of all kinds and created 6,910,892 articles, which have been viewed -->{{NUMBEROFVIEWS}}<-- / -->-1<-- times.

Note the results between the two pairs of "-->" and "<--" pointers: 0 and null. --Guy Macon (talk) 19:58, 1 March 2013 (UTC)

Surely we don't have any data with which to populate this, even if we did give it a static value every month or so? We have (reasonably reliable, but not perfect) traffic stats back to 2008 or so, but before that nothing - it's not like we could sum up all the stats.grok.se logs since 2001 to get an overall total. Andrew Gray (talk) 21:21, 1 March 2013 (UTC)

Good point. Number of views in the last 12 months? Last 24 hours? Just come up with a best guess for the missing data and call the result an estimate? It just seems like we should be able to come up with some sort of statistic that reflects how many people read Wikipedia. All the numbers I use above are about editing Wikipedia. --Guy Macon (talk) 22:00, 1 March 2013 (UTC)

But then what do the other WPs do for pre-2008? What result does the magic word give for them? DGG ( talk ) 03:06, 3 March 2013 (UTC)

After some reflection, it occurs to me that a) the Mediawiki installation here isn't actually gathering any of this data, so it will always have to be manually updated; b) a magic-word that gives a static value from something updated by hand is functionally the same as a template. So we may as well just create {{estimated number of pageviews}}, populate it with a rough guess, and have a bot update it from stats.grok.se every day... Andrew Gray (talk) 22:23, 3 March 2013 (UTC)

Normally, I use metric units for distances and add the automatic converter so that the unit is also available in imperial units. In the page Barauni–Gorakhpur, Raxaul and Jainagar lines, Rao Ravindra has put in a question:What is the need to convert all the lengths from km to miles and removed many of the conversions? Can someone enlighten me about what the Wikipedia rule book says? - Chandan Guha (talk) 02:40, 3 March 2013 (UTC)

You are correct, and I was going to undo the edit because it is established procedure to provide metric/imperial units in the worldwide encyclopedia. However, I can see that an argument could be raised that having nine converts in the very short "New lines" section is cumbersome. In general, procedures here don't come in neat packages that are universally applied—there can be exceptions. Probably best to discuss on the article talk page. Johnuniq (talk) 03:19, 3 March 2013 (UTC)

I'm generally in favour of inserting conversion factors very freely, even though the discussion, now archived, at Wikipedia talk:Manual of Style/Dates and numbers doesn't positively require that. I plastered metric conversions that probably mean very little (yards to left field, etc.) all over the dimensions tables at Yankee Stadium (1923). In some lists of Olympic record holders, I pasted a conversion table for different events (220 yards, 200 metres, etc.) at the end, rather than individual conversions for each event. An article about a Late Victorian creation in India is particularly tricky, since even though the gauge was metric, the builders almost certainly thought of line and spur lengths in yards and miles (or perhaps their Indian equivalents). Although I'm personally a permissivist who hates treating the Manual of Style as a iron-bound book of universal laws, the passage that's being sought is probably this one: Wikipedia:Manual of Style/Dates and numbers#Unit conversions. But once you're familiar with the issues and common practices, the best place to talk this over is probably on the article's own talk page. —— Shakescene (talk) 07:20, 3 March 2013 (UTC)

Thanks for the analytical elaborations. I will leave it at that. - Chandan Guha (talk) 14:50, 3 March 2013 (UTC)

Dear All,

This article is a duplicate of the full article and this one doesn't has any information about the mentioned Person:

The article should be deleted: [[4]] The full correct article: [[5]]

So please review and take the proper action.

for any query please email me: (Redacted) — Preceding unsigned comment added by Talas9 (talk • contribs)

This is en.wikipedia. You need to bring the issue up at ar.wikipedia. --Onorem♠Dil 01:44, 4 March 2013 (UTC)

Of all of us involved in the Village Pump, some might be watchlisting it only because they want to keep track of only one or two proposals at the Pump, and not all the rest (I know I do it). So I think an option to watchlist only a particular section of the Pump might be a good and relevant opt-in feature for anyone who does not want to see all the proposals, regardless of whether it involves that person's interest or not. TheOriginalSoni (talk) 15:10, 1 February 2013 (UTC)

You can already do that: if you watchlist Wikipedia:Village pump (technical), for instance, you'll only get watchlist notifications if threads under the technical section change. Chris Cunningham (user:thumperward) (talk) 15:25, 1 February 2013 (UTC)

No. That means you watchlist only the technical. My point is that I am interested in only 3-4 topics out of 18 that make up a 200k "Proposals" page on the pump. I would want to see the changes in only those few of them, and not every time someone else changes something at the pump. TheOriginalSoni (talk) 15:38, 1 February 2013 (UTC)

That's something I'd support wholeheartedly. I made a similar proposal in the past, where I suggested that the Village pumps contain only transcluded subpages and when you edit a section, you automatically edit the subpage. (I'd need to look for the proposal in the archives). There was also a BRFA in the past for a bot that could mirror discussion threads on some other page (that bot never materialized, however). -- Toshio Yamaguchi 15:30, 1 February 2013 (UTC)

My memory was incorrect. I was thinking of Wikipedia:Village pump (proposals)/Archive 89#Subpages at TfD and Wikipedia:Village pump (proposals)/Archive 74#Change TfD to use subpages, both of which are concerned with TfD. However, I also found this. -- Toshio Yamaguchi 10:10, 5 February 2013 (UTC)

Actually, a capability along these lines could be useful in lots of places. There are times when I want to watch a thread at a particular noticeboard without watching the entire noticeboard. --Tryptofish (talk) 19:50, 3 February 2013 (UTC)

Subpages are good, but they have some limitations -

a) For systems structured on a per-article basis, they have a natural structure - WP:AFD/ARTICLENAME, WP:RFC/USERNAME, etc. Any page titles which collide are almost guaranteed to have a meaningful connection in some way and can be dealt with by hand. For something like the VP, though, we have a lot of less meaningful section titles - "Option to watch a Section of the Village Pump" is good, but things like "Fonts" and "MathJax" are going to produce a lot of title collisions.

b) They're a lot trickier for new users. "Create this page, edit this page, and add a transclusion" is a lot more off-putting than "hit edit and add something". Andrew Gray (talk) 12:47, 5 February 2013 (UTC)

c) They make it much more difficult to casually watch all discussion on the page. Right now, I just load the diff since the last time I read the page and see what changed. With a subpage scheme, I'd need to be watching and unwatching subpages all over the place. Anomie⚔ 13:13, 5 February 2013 (UTC)

I dont really think subpage is the best way to deal with this situation. Someone with more technical expertise on the same could really comment on what will be the best way to do it. What I intend is a button/star along with section headings (near the edit button) which could allow me to watchlist or unwatchlist only that section of the page. Whether or not it is done through subpages, or made opt-in (through Preferences), or be implemented on all pages could be decided by further discussion on the same. But as such, it would be a lot simpler for a lot of people if we could just have the option to watchlist only certain sections of the page. TheOriginalSoni (talk) 11:30, 9 February 2013 (UTC)

Subpages can be done as-is, but "proper" per-section watching on a single page would require some pretty heavy lifting on MediaWiki itself. This has been a requested feature since 2004 - T2738 - and it seems that the lack of a practical way to do it is the major stumbling block. Andrew Gray (talk)

Is there any forum which might be useful to discuss if this and how implementation is possible? TheOriginalSoni (talk) 10:38, 17 February 2013 (UTC)

See Wikipedia:Perennial_proposals#Watchlist_changes. Jason Quinn (talk) 16:40, 24 February 2013 (UTC)

• I'd support this, and in fact I'd say this should be extended to everything outside article space as well (and maybe talk pages)! Lukeno94 (talk) 08:57, 4 February 2013 (UTC)

• Strong support This would be very useful and enable one to better follow the discussions one is interested in without the need to use liquid threads (which I've never been a fan of). -- Toshio Yamaguchi 10:14, 5 February 2013 (UTC)
• Comment I also support this because I know that Wikipedia:Mirror threads isn't going to happen (unfortunately), which would be even more useful. -- Toshio Yamaguchi 10:21, 5 February 2013 (UTC)
• Strong support All notifications for changes I'm not interested in also increases the risk that I miss the ones I would like to see. Lova Falk talk 10:58, 9 February 2013 (UTC)
• Support. It's not clear how one would implement this, but if it were magically possible to watch individual sections on these big noticeboard-like pages, that would be amazing, so I obviously support it. (On the other hand, had I only been watching one section of this page, then I wouldn't have seen this discussion!) Mark M (talk) 11:47, 9 February 2013 (UTC)

Regardless of how useful it would be, it's not technically feasible. The software can only tell you when a page is changed, not a sub-section of said page. As pointed out earlier, you really should look at Wikipedia:Perennial_proposals#Watchlist_changes, it's already been hashed out several times. — The Hand That Feeds You:^Bite 22:47, 26 February 2013 (UTC)

Well, it IS technically possible, if the page only consists of content transcluded from subpages, thus any edit to a subpage would show up on your watchlist (if you have the respective subpage watched). Of course you would need to ensure that you have all the discussions you are interested in on your watchlist. I think adding a link like Watch this thread or something to any transcluded thread should also be technically possible. -- Toshio Yamaguchi 10:33, 2 March 2013 (UTC)

See Wikipedia:Perennial proposals#Watchlist_changes. I oppose making the village pump pages a bunch of subpages, so that keeping track of the whole page will require me to add every single section (thousands of items over the course of a year) to my watchlist. Separate subpages work best for a process that is either enormous (AFD) or that has very few, very long sections. WhatamIdoing (talk) 18:57, 7 March 2013 (UTC)

Just saw an(other) example of a new, teen-aged "patroller" pissing off useful new older contributor with a good article (10 sources eventually) by proposing something for speedy in 2 minutes. Seriously...this is not a new record. Has been going on for years. Why not make this a flag to be added (or perhaps taken away) by admin fiat?

And I am really not into admins or trinket awarding or any of that. But since we need to have speedy and have patrollers (to fight the waves of crap), why not have some more accountability and organization. A flag would make things easy. Probably help with newbie attracting and making a nicer environment and less of a first person shooter that Sue complains about. Is a very easy fix too.

TCO (talk) 08:52, 21 February 2013 (UTC)

You are correct that this has been an issue for years. I'm not sure if it's technically possible to restrict this because it is just adding deletion templates to the articles. I've seen people propose that WP:NPP and WP:RCP should be userrights, which is possible but the idea hasn't gained any traction so far. Another proposal was that articles be given a grace period of X amount of hours, but this was shot down because of concerns about WP:BLPs and attack pages. The usual reccomendation is to educate the people that are doing it wrong. There may have been other suggestions, but I don't recall right now. 64.40.54.147 (talk) 01:33, 22 February 2013 (UTC)

Bad speedy deletion tags will alkways be an issue, just as bad edits and creation of bad articles will always be an issue. Education is not just how we do we deal with these issues, it is how we should deal with them. We need CSD patrollers to find all the crappy articles being created every minute of every day. It never lets up, so making users jump through more hoops before we even let them tag an article would not, on the whole, be helpful.

I find it troubling that there seem to be an increasing number of users who apparently desire the creation of new policies preventing everything that they don't want to deal with. Wikipedia does not need to become a police state, there are more than enough rules already. Talk to users who are doing it wrong. (there are even templates for this if it is too much trouble to write a paragraph explaining the problem) If they won't listen, open a community discussion such as WP:RFC/U about it. Beeblebrox (talk) 20:54, 22 February 2013 (UTC)

• I did some data analysis on this recently in my official role; actual, undone reviews are few and far between. Novice patrollers are few and far between. Frankly, we need far more of them, and I don't quite understand how creating an additional hoop for potential patrollers to jump through will achieve anything except "you're less likely to have someone take issue with your article, because nobody will ever review your article, regardless of how terrible it is". I share Beeblebrox's concerns. Ironholds (talk) 00:30, 23 February 2013 (UTC)

@Oliver, as community liaison for the WMF, you have done an incredible job making things better, so I have faith in what you're saying. But I hope you will understand that I still have a concern. The general public knows that Wikipedia is a hostile place for new users. The news media has been reporting this for over half a decade. See Wikipedia uncovered (2007) and Editors depart as Wikipedia becomes 'hostile' (2009) as just two of the many examples. The community has known of these issues since at least 2006 when WP:QUIT was created. The community confirmed the problem with WP:NPP when it ran the WP:NEWT experiment in 2009. The scientific study in 2010 by the WMF at strategy:Editor Trends Study and specifically strategy:Attracting and retaining participants#Barriers to increased participation also confirmed the problems at WP:RCP and WP:NPP. And Sue reiterated the problems with reverts and deletions at RCP and NPP in the strategy:March 2011 Update. As an IP editor, the community treats me the same way as the general public or any new user so I am keenly aware of these issues. I prefer being an IP specifically for this reason, because it allows me to judge the health of the project and to see if it's getting better or worse. If you have new data that shows these issues are no longer a problem, it would be great news. 64.40.54.122 (talk) 14:56, 24 February 2013 (UTC)

It is true that we still get novice new page patrollers who learn on the job and in some cases commit seriously bad mistakes before they improve or go away. I recently came across someone who thought that if an assertion of importance was unsourced it was not credible, so he was tagging articles for speedy deletion simply because they were unsourced. In that sense the problems we found during wp:NEWT are very much still with us. I'm not convinced that the solution is to make prodding or newpage patrol a userright, though we could perhaps create some training material for new patrollers. We also need to simplify an over complex set of rules and make things less bitey. Delayed action tags for goodfaith articles would be useful here. That would enable us to give goodfaith articles a period of grace whilst at the same time zapping the badfaith stuff as fast as it comes in. I'd also like us to reduce template bombing by replacing some of the unnecessary templates like uncategorised with an auto generated hidden category for maintenance purposes. Easy ways to make things less bitey also include making it mandatory to at least tell someone that you'd tagged their article for speedy deletion, I recently came across an editor who regularly tags articles for deletion whilst leaving the author with a redlinked talkpage. Currently that sort of bityness is allowed - we don't allow people to file AN/I reports on each other without telling them and it seems inconsistent to me that we allow people to deletion tag without informing the authors. We could also go some way to reducing the problems at NPP by tweaking the Mediawiki code to resolve more simultaneous edits without rejecting so many edits as edit conflicts. But sadly the WMF gives a higher priority to bad ideas like the AFT than to important and useful things like resolving more edit conflicts whilst losing fewer edits. ϢereSpielChequers 13:54, 25 February 2013 (UTC)

I agree that a user right for WP:NPP and WP:RCP is not a good solution. I only mentioned that others suggested it in the past. Another suggestion that was made a few years ago was an NPP school for new patrollers. But that never got off the ground. I still believe that NPP and RCP are the most bitey places for new users and that we should try to fix that problem somehow. I would like to see WP:Page Curation for the front of the queue focus exclusively on BLP vios, attack pages, copy vios, and other urgent stuff. And that issues that are only Quality related would be on hold for a few hours so that the writer wasn't tagged in the middle of an edit session while still building the article. Best regards. 64.40.54.4 (talk) 18:16, 25 February 2013 (UTC)

My experience in examining articles tagged for speedy before I delete them is very different from what Oliver reports, but perhaps that is because I try to work with the tricky ones, and am more concerned with catching errors than in doing the obvious. And I see at least as many errors in failing to tag the major problems, such as copyvio, as in over-tagging. I do not think there is an easy solution to be achieved by tinkering with policy. The only real solution is to identify patrollers who need education, and educate them, and very few of us actually work at that. I wouldn't want to restrict anyone from tagging--we must identify problems while we can catch them. But I think it would help is some minimal degree of experience were required before marking pages as patrolled, perhaps the level for review at PC.(and similarly for approving or rejecting articles at AfC) DGG ( talk ) 19:25, 26 February 2013 (UTC)

Oppose Unsurprisingly, I find myself opposing another one of TCO's ideas. Simply put, restricting access to a suite of templates (aside from that it's likely to be impossible to do from a technical standpoint) just to combat one bad practice is terrible overkill. If you want there to be a grace period before things are put up for deletion, start an RfC and get it as policy, then convince people to enforce said change in policy. I can tell you right now that the RfC is going to fail, but nonetheless that's what you're going to need to do. That, or you can approach the people doing the tagging one on one and calmly explain your position on tagging for deletion so soon after an article is created. That might have slightly more success, although you're still not going to fix the situation entirely. Sven Manguard Wha? 06:41, 4 March 2013 (UTC)

It's already policy that certain CSD tags should not be added to minutes-old pages. WhatamIdoing (talk) 19:09, 7 March 2013 (UTC)

Proposal

Let us discuss and create some mechanism which will force other neutral and uninterested editors into commenting fairly. We are not a democracy, are we? At least create a special discussion board (similar to afd) that will notify neutral editors more flagrantly. Don't get me wrong, I don't want it to be disruptive. But surely we can find some way to simply fetch more neutral comments to avoid traditional but unacceptable bias. Thank you all.

P.S. please don't make it an issue about me. I didn't come here to solve my own problems, I am here to solve the apathy and the system at large. Mr T^{(Talk?) (New thread?)} 08:13, 24 February 2013 (UTC)

• As long as there is controversy in the world, there will be controversy on Wikipedia. We have a variety of means, including RfC alerts and discussion listings, to attract neutral feedback. If one is not getting the responses one wants, one can either be bold and address the problem yourself or pursue dispute resolution. You're right, we're not a democracy, but we are a free encyclopedia. Editors can contribute in fields of interest to them, and there's no way people will be "forced" to offer feedback. dci | TALK 22:21, 24 February 2013 (UTC)

That must have come out in the wrong way. I didn't mean it to be literally "forcing" someone, more like persuading them to comment just like we are notified of some of the more consequential discussions through our watchlists every once in a while. That is something not everyone can avail. Is this helping to clear what I am proposing?

P.S. I have collapsed the details of the problem to save space, albeit I encourage everyone to read it. Mr T^{(Talk?) (New thread?)} 16:55, 26 February 2013 (UTC)

Comment There is a process in place for that now. Editors may sign up at the RfC noticeboard and be periodically dinged on random comment requests. It's just finding or encouraging more editors to sign up for this. GenQuest ^{"Talk to Me"} 22:22, 26 February 2013 (UTC)

Okay, I didn't know that but how to encourage adequate number of people to comment? Any ideas? Mr T^{(Talk?) (New thread?)} 18:01, 27 February 2013 (UTC)

How many times have you commented usefully at RFCs on topics that you don't care about? What can we do that would convince you to spend your limited and precious time doing this? WhatamIdoing (talk) 19:11, 7 March 2013 (UTC)

You know, you probably wouldn't have to ask so many times for donations if you kept your more passionate users like Editor-A in check. Just take a look at his user talk page to see how many other ordinary and well-intentioned users he's pissed off. Each of those is a potential donor, as was I.

But why would we donate to something that seems to be controlled by a very small group of people who seem to enjoy enforcing their views, even on subjects in which they have less expertise than us. While that small minority seems to be your most passionate user base, it's the majority they are pissing off who are your biggest potential donor base.

Editor-B who just removed this proposal is another great example of the kind of editor who is killing wikipedia's credibility for getting donations from the general public. I have nothing to gain by spending my time doing this. But I believe in wikipedia and that it could work if editors like this are kept in check. And I just don't want to use my real id and risk it getting "banned" by going against these overzealous "moderators".

Feel free to delete this suggestion again. Just remember it the next time you plaster the site requesting us for donations.

• Personally, I feel that encyclopedic quality should come before the $. If you feel that editors are making editor retention more difficult or have violated WP:NEWCOMER, I suggest you inform them of your concerns while logged in, and at their talk pages. This is preferable to sections at VPR which border on personal attacks. dci | TALK 12:45, 25 February 2013 (UTC)

Thank you Bazonka and DCI2026. I have cleaned up the language a bit and added a suggestion at the bottom of this edit.

Note that a lot of us newbies genuinely want to contribute to wikipedia, in content and cash. But then our content efforts are rudely thwarted by those who seem to know less than us in our subjects of expertise (I speak from an experience over several months and 2 different subjects). Such behavior compromises not only donations, but also the quality of content.

Now we newbies may not know the right procedure but if wikipedia already has processes to control such behavior, shouldn't these regular editors know about them and be following them? If they are following them, then maybe the current checks are not enough to prevent such behavior.

As a suggestion, may I recommend that outright deletions of contributions by others be discouraged? Deletion is very discouraging for a contributor who doesn't know the politically correct wikipedia procedure; as well as downright rude. If an editor has a problem with a contribution, let him correct it, or at least tell the contributor how to. [OP]

I luv Editor-B. He's the kinda guy who thinks that a four letter reference to 1950s fantasy fiction is more descriptive than a geo-locatable number. And we all know how important it is for a serious reference work to have identified authors.. like.. well some guy named in the language of Mordor. Honest.

I don't want to make this personal. The intention was to make wikipedia easier for the general public to contribute to. But Editor-B is actually a great example of the kind of editor I'm talking about. His user page actually says "Though I do have an image to uphold as a dick who only deletes and rarely creates". A culture where a regular is actually proud of his reputation for deletions without contributions is truly disturbing. [OP]

• Comment It is true that many, perhaps most, new editors find Wikipedia to be a hostile place. It is also true that we have been losing editors for years. Many of these problems are related to how users treat each other—and we should definately work on this issue. But it's usually not a good idea to name specific editors in a general conversation like this. If there are specific issues with a specific editor, it is best to let that editor know and try to work things out with them on their talk page. If that doesn't work, then follwing the advice at Wikipedia:Dispute resolution is the next best step. If we want to have a general conversation about the general problem, then specific names of individuals should be avoided. That way the conversation doesn't take a sour turn and, in the end, becomes much more productive. Now, having said all that, I can sympathize with your general concerns as I have run across these types of problems with many different people on the project. It is an issue that needs to be solved for the good of trhe community. So far, we have not been able to find a solution. Any suggestions you may have would certainly be welcome. 64.40.54.4 (talk) 16:09, 25 February 2013 (UTC)

I thought of this too before I read your comment and I agree. Getting personal would be counter productive. I've taken the liberty of replacing the specific names with generic ones (all of them in my posts except one instance). I hope that's OK. [OP]

Thank you. I appreciate the update. Personally, I would like to see the WMF do a study on a group of 1,000 new users asking them to report if/when they felt bitten to see if there is a common demoninator. That way we could see if certain policies (or whatever) could be the underlying cause. Then we could make the required changes. It's just a thought I had. Cheers. 64.40.54.4 (talk) 17:47, 25 February 2013 (UTC)

One needs to remember that Wikipedians are real people, and there are lots of types of people in the world: helpful ones and rude ones, thoughtful ones and hot-headed ones, meek ones and strong-charactered ones. Some are welcoming and understanding of new users, and others are impatient and dismissive. Of course new editors can feel intimidated or discouraged by the less welcoming Wikipedians, but the helpful ones are out there - we have a welcoming committee for precisely this purpose, for example.

In terms of whether a new user's contributions should be deleted or not really depends on what they are. Serious copyright or WP:BLP violations should be reverted (as should obvious vandalism of course), but in other cases, perhaps the added text just needs tweaking or moving - the new users can perhaps learn by seeing what is done to it. At the very least there should be a decent explanation in the edit summary that explains why the text was deleted or changed. New users are more likely to ask questions and learn if the other editor is polite and/or explanatory when they delete the inserted text, rather than if the summary just says "revert" or similar. Wikipedia-style jargon in edit summaries (e.g. "rvt copyvio"), whilst well-meant, may also be confusing to newbies.

This is a big issue, and there is no simple way to resolve it. It will be impossible to change the personalities of the editors at large. I honestly don't know how to address it, but please try not to let the actions of a few cloud your experience. Bazonka (talk) 21:23, 25 February 2013 (UTC)

It's encouraging to see some editors who actually understand the seriousness of the issue. We can't change the people but we can change policy, which in turn will change people. The current policy seems to be "guilty until proven innocent", or to shoot first and ask questions later. My suggestion is to strongly discourage deletion of any edit that has content of any value, however little. The focus should be cleanup and integration of edits rather than blind removals which harm both content quality and participation. If an editor does not have time to clean up an edit himself, let him tell the contributor how to. What we have now instead is a culture that prides itself in removal and exclusion.

Then there is the issue of hostility towards newbies - both in process and by people. Just look at the number of links a non-wikipedian SME would have to go through to make a contribution. Complex processes and jargon simply make it easier for the regular minority to control the system and harder for the majority and the real experts to contribute. Again, I believe that a policy change from deletions to integrations will help solve this.

Ignoring or belittling the problem won't make it go away. There are numerous other websites that are also discussing this very same issue and advising against donations to wikipedia for the same reason. Only time will tell which side will be proven right. [OP]

• Since when did the Village Pump become the Whinge Pump? Yes, I attempted to remove this section this morning, because it is the same nonsense that one sees crap up on Jimbo's talk page and elsewhere from time-to-time; a garden variety "someone removed my edits so I'm not gonna donate" bit. Always non-specific, always a generalised tirade against authority. We we eventually dig down to the actual details of the complaint, it invariably turns out to be someone who did not understand WP:NPOV, is mad that their favorite local bar band cannot have an article, and so on. If a user, new or otherwise, cannot understand what "rvt copyvio" means, then that is a person I would not welcome to the project in the first place. "Competence is required". Tarc (talk) 22:46, 25 February 2013 (UTC)

I wonder if you have actually read the Newbie section of CIR? Bazonka (talk) 18:42, 27 February 2013 (UTC)

• YAWN Same "Someone hurt me so I'm going to hurt wikipedia by not donating" that we see 2~3 times a week. You wouldn't expect to be able to jump directly into the NFL after watching a single game on TV, yet that's what a lot of the "Bit" editors try to do. When you're new in a community, you don't jump into the middle of a heated discussion, you observe from the sidelines to understand how things work. Hasteur (talk) 02:35, 26 February 2013 (UTC)

• • One thing is for certain. It is people like you, Tarc and Hasteur, who are bringing Wikipedia down. Newbies whine on the Village Pump because you are actually behaving like assholes towards them. (And I believe the word asshole is perfectly justified based on the content of the two entries above.)/81.170.148.21 (talk) 22:32, 26 February 2013 (UTC)

Also, newbie is misleading term. New to Wikipedia's complex rules perhaps, but some of us are experts in our own fields, sometimes with years of experience (12 in my case). That experience is what you lose out by having young and overzealous editors running around deleting whatever they don't agree with. All you'll get in such an environment is a giant magazine, not an encyclopedia of real value. [OP]

We're not the NFL. Professional level skill is not expected here, either initially or later. Nor are we a group of long-time associates who aren't going to let anyone else into their game unless they know the magic words. DGG ( talk ) 19:06, 26 February 2013 (UTC)

As you can see from the comment just above yours, that is just what seems to be expected by a lot of the existing editors - not knowledge of one's subject, but knowledge of wikipedia's rules. Those rules are used as the excuse to remove any contributions that these editors don't agree with. This subjective censorship by a limited few with more time on their hands is what is making wikipedia increasingly known as good for casual reading but unreliable on any serious subject - more magazine than encyclopedia. Not my words, just look for any discussion on the topic online. [OP]

OP, did you consider looking into the Teahouse? Or maybe Project Editor Retention? We would love to hear your views on these two projects, especially if you make an account. Unfortunately, these two are the closest structures that we have to guide/protect newcomers, and to lead them correctly. And as much as i would like measures to keep "Overzealous editors in check", I am certain that those very editors would ensure shelving of any such proposal immediately. So I am not going to place my bets on that one. TheOriginalSoni (talk) 12:38, 2 March 2013 (UTC)

I have, TheOriginalSoni, and I already have an account. As I said, I didn't use it here because I didn't want to risk getting banned by these editors. Though it's encouraging to see the discussion being taken seriously now, it's still strange that using one's own time to make a contribution of any real value to Wikipedia is such a long, thankless and painful process. One would easily assume that making a donation will be a similar experience. It shouldn't be that hard to have culture that is helpful and polite. I've modified the heading of this section to highlight my actual suggestion. [OP]

Making people be polite in a large, busy, anonymous virtual forum is an extremely difficult task that AFAIK has only been achieved in the long run with very heavy punishments for anyone who is even slightly off the mark.

I'm not sure that it has a significant effect on donations. Most occasional users aren't donors. WhatamIdoing (talk) 19:18, 7 March 2013 (UTC)

These things are always debatable but I know it did affect mine. It also seems to be a pretty common complaint and the ones who actually say it out loud are usually just the tip of the iceberg. Anyway, natural selection will eventually take its course. Either the issue is not significant and won't affect Wikipedia. Or it is and something better will take Wikipedia's place. Let's see what happens. In any case, Wikipedia seems to have more donations than it knows what to do with so this discussion is pretty pointless. [OP]

Currently, athletes and a few other types of biographies accept height as a parameter. I propose that height be added as an acceptable parameter to all biographical infoboxes. Here are the following reasons why:

1. It’s something people want to know, and not just about athletes
2. It’s not really trivial. There’s a whole article devoted to how important a person’s height is to success in a number of fields
3. Even if it was trivial, there are a lot of trivial things allowed as infobox parameters. Case in point: signature. How many curlicues are in a person’s signature has no effect on their success or failure in a particular field

pbp 15:47, 1 March 2013 (UTC)

• Oppose unless reliable sources specifically mention a person's height as significant, which is usually the case for athletes and almost never the case for anyone else. In that case it should go in the article before going in the infobox. Regarding your points:

1. You're asserting that with no backup. I could just as easily assert that nobody cares and nobody wants to know, and it would be equally baseless.
2. That would be an example of WP:Synth. Just because height can contribute to success, and a person is successful, does not mean we can imply or assume that their success was related to their height unless a reliable source makes that connection.
3. Signatures and height are both trivial and neither belongs in the infobox. I will happily sign onto any proposal to keep signatures out as well.

At the very least, I hope you agree that height should not even be brought up unless it can be sourced, not to some celebrity height list but a legitimate academic source. Internet-sourced height is very often estimated, and with very low precision. Designate (talk) 17:22, 1 March 2013 (UTC)

We might want to take a hard look at the Wikipedia pages on this list... --Guy Macon (talk) 20:08, 1 March 2013 (UTC)

I'm sure you could find a reliable source for hundreds of non-athletes with Wikipedia articles. And a few hundred articles is more than enough to justify the additional parameter. Heck, the heights of U.S. presidents alone gets you 10% there! I never said that it could be sourced for everybody or that the parameter needed to be used in every person's infobox. There are loads of parameters that aren't used in 70, 80, 90 percent of infoboxes, but still have the option to be used pbp 21:32, 1 March 2013 (UTC)

• Oppose I'd favor removing all of these things before adding another field, much less one as mind-numbingly trivial as height. Nothing attracts unsourced data as quickly as an infobox.—Kww(talk) 20:22, 1 March 2013 (UTC)

Please read point #2. How tall somebody is ISN'T "mind-numbingly trivial". People like George Washington and Abraham Lincoln had a leg up because they were tall; Washington was chosen as General of the Continental Army in part due to his commanding presence. You've also ignored point #1, the point that people are interested pbp 21:32, 1 March 2013 (UTC)

There are a few exceptions, but it's trivia for most of our biographies, and, when important, can be stated in the article where it can be explained exactly why it is important. Infoboxes are one of the worst features of Wikipedia. Their use should be discouraged, and I strongly oppose the addition of any more fields.—Kww(talk) 21:44, 1 March 2013 (UTC)

• Oppose - no need to add a field that will be just full of guess work all over the encyclopedia. Moxy (talk) 21:55, 1 March 2013 (UTC)

As I said above, there are hundreds of them that can be reliably sourced. As with anything else in a template, stuff that isn't can be removed. I'm not seeing the problem here; there are numerous other fields that are just as bad and already existent pbp 22:03, 1 March 2013 (UTC)

Feel free to use an infobox that does have height as a parameter, for those cases, like {{infobox person}}. Apteva (talk) 03:46, 2 March 2013 (UTC)

• Oppose Designate described the situation well. What next, favorite color? Name of pet? If a reliable source has written that Lincoln's height was significant the article should mention that (in the lead if it were really significant). But putting it in an infobox conveys the impression that this website is heading away from encyclopedia towards factoid collection. We do not need a new thing to argue pointlessly about: except for rare cases, it just does not matter. Johnuniq (talk) 22:08, 1 March 2013 (UTC)
• I do not see any need for it to be in all biography infoboxes. We do use it for {{Infobox pageant titleholder}}, {{Infobox basketball biography}}, {{Infobox football biography}}. It is not available in {{Infobox officeholder}}, and it is pretty hard to get reliable height information for politicians. Apteva (talk) 03:46, 2 March 2013 (UTC)
• Suggest an RfC. There seem to be a lot of editors who think that some of the existing fields should not be there, and some unknown number (we have only asked about height) who want more. I suggest that someone (perhaps Purplebackpack89?) post a WP:RFC to get a wider community input on what should and should not be in the generic BLP infobox. You can put me down as wanting a Dalek Supreme Yes/No field -- I don't know how many times I have read a BLP that fails to answer the question "Is he/she a Dalek Supreme?" After all, isn't whether someone is dedicated to exterminating all organic life more important than how tall they are? :) --Guy Macon (talk) 11:18, 2 March 2013 (UTC)
• 'Comment Normally an infobox has more fields than any one article uses, because we don't want to have a great number of custom-tailored ones, but rather a limited number that can be properly maintained. The general ones have all possible parameters; more specialized ones are built on the general ones and will have the appropriate parameters. Height can be important, and then the re is a general infobox available. But normally it is not, and we shouldn't be encouraging non- encyclopedic details in articles. It's relevant for athletes, and models, and some types of performers. It's rare important otherwise. DGG ( talk ) 03:03, 3 March 2013 (UTC)
• Comment My gut says to oppose this, largely based on my experience watching the population of birth date (as opposed to birth year), and the fair amount of horribly sourced junk that gets put into the field as a result, my favorite was the set of voice actors someone had sourced to a PDF stored in an upload directory of a fashion college. In general this information is not going to be significant to a brief summary of an individual, and including it infobox lends too much weight to it. (Athletes and models are sensible exceptions.) When well sourced it can always be included in-text. Ditto for blood type, astrological sign, weight, and so on. --j⚛e decker^talk 03:30, 3 March 2013 (UTC)
• Exterminate! I mean oppose. In most cases, this will be trivial. How tall was Charles Darwin? Charles Dickens? Plato? It doesn't matter. In those cases where it matters - as demonstrated by independent resources commenting that, for instance, "Napoleon's height affected his actions by..." or so-and-so was so influential partly because of a statuesque height - it can be added with appropriate explanatory discussion in the text. LadyofShalott 03:49, 3 March 2013 (UTC)
• Doesn't go far enough: Things like favourite colour and names of pets have already been mentioned above. But if we keep to the subject of bodily characteristics and measurements, there is no reason to limit them to length. Waist and chest circumference should be included, as should the length and circumference of upper and lower arms and legs, hat size and shoe size. These are all extremely important for properly understanding a subject. These measurements can then be extracted as machine-readable data (very important!) for historical purposes, for instance for analysing whether gymnasts or ballet dancers with a large waist circumference have generally been more successful than those with a smaller one, or the opposite. It can also make the job easier for tailors, hat- or shoemakers. In case one of these subjects would need a suit or a hat that is, or if someone (for whatever reason) would like to make a jacket fitting Lord Nelson, either before or after losing his arm (any relevant changes in measurements need to be clearly included in the box). And, oh! Optical data of the sort opticians use! We need that! Could be very useful in subjects like military history to know at what point a general would have been able to spot the enemy. And for writers on art history, it may be useful to know how clearly Monet could see his water lilies at different points in his career. And once all these measurements have been put in infoboxes, Wikipedia severely needs another large set of huge garish navigational boxes to make it easier for the reader to proceed from one article to any other article on a person with the same length, waist measurement or shoesize. I'm sure there is a way to add more succession boxes based on this data, even though I cannot think of one at the moment. All this work needs to be organized by Wikipedia:WikiProject Bodily measurements. The project members will add their tags to all the other project tags on the talk pages of articles and rate them according to the importance and quality scales of the project. --Hegvald (talk) 12:44, 4 March 2013 (UTC)
  • Thank you thank you thank you. If only I could be sure no one will enthusiastically embrace your proposal, I would thank you some more. Johnuniq (talk) 10:36, 5 March 2013 (UTC)

_{(Moved here from my talk page Guy Macon (talk) 08:59, 5 March 2013 (UTC))}

First off, remind me to add that "Dalek or not" quandary to Jon Pertwee's infobox. Anyway, should I start the "what fields should be in an infobox" RfC as: a) A subthread of the existing discussion, b) another PUMP thread, or c) somewhere else entirely pbp 14:49, 2 March 2013 (UTC)

I think the RfC should be at Template talk:Infobox and advertised on various other pages. I am not sure how familiar you are with RfCs, but if you need help, write up what you think it should look like in your sandbox and I will be happy to assist in tweaking it. --Guy Macon (talk) 00:26, 3 March 2013 (UTC)

I am going to make a survey about WP anti-vandal tool and WP, vandaliam. Shall I proceed?--Pratyya ^(Hello!) 05:14, 5 March 2013 (UTC)

Knock yourself out PG. Seems like an okay idea to me. I for one wouldn't mind giving you input. MIVP - (Can I Help?) (Maybe a bit of tea for thought?) 16:48, 7 March 2013 (UTC)

Talk to CVUA too so that they can join it/add input! --Tito Dutta (contact) 16:54, 7 March 2013 (UTC)

I've recently encountered a lot of new users who use HotCat to add empty or inappropriate categories to user or user talk pages. It becomes a nuisance when somebody keeps adding Category:Sorry all around. Can the gadget be turned off until users are autoconfirmed? This would deal with 90% of the problem. Acroterion (talk) 22:13, 5 March 2013 (UTC)

One problem is that autoconfirmed kicks in silently and very early; users don't get notified that they've been confirmed or told there's anything different, and it almost always happens before they've fully figured out how the interface works.

Switching hotcat on at this point will mean that we suddenly have a new part of the interface appearing with no explanation, which is potentially going to be even more confusing... Andrew Gray (talk) 23:24, 5 March 2013 (UTC)

How about someone make a bot to inform users that they have obtained the right? It could say something like this.

Thank you for your contributions to Wikipedia and your patience to edit, your account has now been promoted to autoconfirmed which gives users the ability to use tools which can be found in the Gadgets section of Your preferences. These tools should prove to be much more useful in your contributing.

Happy Contributing. (Bot name)

Something like that maybe? MIVP - (Can I Help?) (Maybe a bit of tea for thought?) 16:33, 7 March 2013 (UTC)

Yes, the whole concept of autoconfirmed alone is confusing to new users. I'm not sure why I'm seeing this spate of HotCat (ab)use right now - nothing's changed that I know of. Acroterion (talk) 01:40, 6 March 2013 (UTC)

...on the other hand, if we actually made autoconfirmed A Thing, with a bot-generated "hi, glad to see you've stuck around" message, it might be a good idea - "thanks for contributing to Wikipedia, we've now turned on [hotcat and edit SP pages], please ask here --- if you've any questions"... I can see this working. Andrew Gray (talk) 09:52, 6 March 2013 (UTC)

See also Wikipedia:village pump (proposals)/Archive 99#HotCat misunderstandings.—Emil J. 15:10, 6 March 2013 (UTC)

If I had never edited Wikipedia before I'd assume that the plus sign I see at the bottom of a talk page is a way to add a short comment or reply, since many other websites work that way. Yes I know it says "Categories" next to it but that isn't going to make the point clear to most people. I think Yunshui's ideas deserve another look. —Soap— 01:27, 7 March 2013 (UTC)

Yes, I think the the contextless + that's confusing people - they think it's an editing box. No new person's going to understand (or care) about categories. Acroterion (talk) 03:49, 7 March 2013 (UTC)

It seems I replicated Emil J's idea without even realising it o.o Just shows we have a bit of consensus for such a bot huh? heh heh. MIVP - (Can I Help?) (Maybe a bit of tea for thought?) 16:38, 7 March 2013 (UTC)

I don't like this idea, because of the changed interface confusion, although I'm sympathetic to the problem.

Maybe what we need is a bot that reverts non-autoconfirmed users when they've added a non-existent category, and leaves them an explanation, like XLinkBot (talk · contribs). WhatamIdoing (talk) 19:39, 7 March 2013 (UTC)

Recently I decided to get involved once again with the merge process, and the backlog of articles at Category:Articles to be merged. I've come across several examples where there are a bunch of articles related to a fictional work all nominated for merge; various anime/manga, several fantasy and science fiction books/films.

A reading of Wikipedia:Manual of Style/Writing about fiction gives a brief overview about how to write about fiction, but doesn't go into detail about how to structure content across several articles. What I mean is, I can see no guideline to help editors organize subarticles about a work of fiction. I consider an article class like countries, where we have established an acceptable hierarchy. Consider the subject France:

• France
  • Name of France
  • History of France
    • Prehistory of France
    • France in the Middle Ages
    • French Revolution
  • Geography of France
    • National parks of France
  • Administrative divisions of France
  • Politics of France
  • Blablabla, etc.

I don't know if this kind of hierarchy for Nations is set in stone, but clearly it has been accepted as a best practice and is widely used. What I would like to do is identify those best practices for fictional elements, keep a record of them and popularize their use. It would greatly consolidate the fragmentation we have in our coverage of fiction and fictional elements. --NickPenguin_(contribs) 23:37, 5 March 2013 (UTC)

You might consider surveying video games navboxes for how video game fictional elements are dealt with. In summary, it's usually one series article (if there are >=3 games usually), several games articles, a list of characters article, a handful of characters, occasionally a 'universe' article (these are usually plotfests), sometimes a list of media article (sometimes merged in the series article, sometimes split), as well as developers, publishers, and other miscellaneous information related. See e.g. Template:Warcraft universe and Template:World of Warcraft. In the case of the former template, several of those books are tagged for WP:N(BOOKS); I've been meaning personally to merge them, I just haven't had the will to do so. (See start of that list article at User:Izno/Sandbox/Warcraft books.)

That said, from my obersations, WP:VG takes better care of their space than a number of the anime, manga, film, and television projects do, with respect to WP:N at the least. Your mileage may vary.

Just to give you some ideas to work from. --Izno (talk) 02:34, 6 March 2013 (UTC)

The problem I find with fictional characters/fictional elements pages isn't so much the structure but how horrible the writing is. Sometimes jargon from the book or television series is used informally (I went through the character pages for The Bill recently and removed countless "coppers", "guv'nors" and other similar British police slang which was used freely as if it were appropriate terminology for encyclopedic writing) or without any suitable context for people who are unfamiliar with the fictional universe.

Plot summaries are often written with all the skill of a shopping list of events, without any real use of language to form a readable narrative. Instead of "John woke up, kissed his lover and then cooked him some eggs" we get "John woke up. Then John kissed his lover. Then John prepared some eggs to feed to his lover."

It'd be great if any guide to writing about fictional characters or fictional elements gave editors (who are often enthusiastic about the subject matter of TV or video games or anime or whatever) advice on how to write about those things in a more lively but encyclopaedic way. —Tom Morris (talk) 13:51, 6 March 2013 (UTC)

WP:WAF doesn't do it for you? --Izno (talk) 13:50, 7 March 2013 (UTC)

This kind of information is usually available in a {{WikiProject style advice}} page. WhatamIdoing (talk) 19:40, 7 March 2013 (UTC)

Dear all,

Wikimédia France launched an international research award aiming to reward the most influential research work on Wikimedia projects and free knowledge. After the initial submission of research papers by the community of researchers who study Wikimedia projects, a jury have selected five finalists among a thirty proposals. You can find summaries and full texts below :

• Studying cooperation and conflict between authors with history flow visualizations by Fernanda B. Viégas, Martin Wattenberg and Kushal Dave, published in 2004.
• DBpedia: A Nucleus for a Web of Open Data by Sören Auer, Christian Bizer, Georgi Kobilarov, Jens Lehmann, Richard Cyganiak and Zachary Ives, published in 2007.
• A Content-Driven Reputation System for the Wikipedia by Thomas Adler and Luca de Alfaro, published in 2007.
• Creating, destroying, and restoring value in Wikipedia by Reid Priedhorsky, Jilin Chen, Shyong K. Lam, Katherine Panciera, Loren Terveen and John Riedl, published in 2007.
• Can history be open source? Wikipedia and the future of the past by Roy Rosenzweig, published in 2006.

It's now up to you to choose the most influential. For that, please visit the voting page. Voting will close on Monday, March 11. The announcement of the winner is scheduled for the end of March.

If you have any question, please use the project talk page, thanks ! (do not hesitate to move this post to a more appropriate section)--CarolAnnO (talk) 11:24, 6 March 2013 (UTC)

Pretty uncontroversial stuff here. I propose that the assigning of IP block exemption is restricted to CheckUsers. It makes no sense whatsoever for administrators to hand out what is technically an administrative flag based on information that they inherently do not have access to and have no means of verifying. This would have little change in operations — the vast majority of IP block exemptions are granted by CheckUsers anyway — but just like how administrators are instructed not to lift a {{checkuserblock}} on their own terms per WP:CUBL, this would be a welcome and manifestly obvious clarification of policy. WilliamH (talk) 18:07, 4 March 2013 (UTC)

Nope. There a legit circumstances where an admin can grant it and they shouldn't be prevented from doing so.©Geni 18:10, 4 March 2013 (UTC)

Such as? --Rschen7754 18:12, 4 March 2013 (UTC)

(edit conflict) What are those legitimate circumstances? From my understanding of how IPBE should be being used, it has to be applied in conjunction with CU know-how if it's going to be used responsibly. An admin working alone has no way to know whether the user to whom they're giving the ability to evade blocks is someone who has a legitimate use for that right, or an illegitimate one, or none at all, so the best an admin working without CU input can do is close their eyes, click, and hope it doesn't turn out to be the wrong call. Is there some case I don't know about where IPBE should be given that way, flying blind without CU input? A fluffernutter is a sandwich! (talk) 18:16, 4 March 2013 (UTC)

Well for example, several years ago I was travelling and staying at a hotel in Denver. As it happened that particular hotel routed all of their traffic through a single IP address, and some current or recent guest had been vandalizing, so the IP address was blocked from editing Wikipedia. Obviously, this had nothing to do with me, so I made an inquiry, and had IP block exemption added to my account for a while to get around the fact that my hotel was blocked. While a checkuser might have been brought in, I don't think it is really necessary when users in good standing with a long history happen to get hit by blocks intended for simple vandals. Dragons flight (talk) 19:00, 4 March 2013 (UTC)

If a checkuser had been brought in, the chances of the block on the IP address being lifted or altered to anon-only would have been significantly increased, thus not just benefitting you, but also anyone else who was staying in the same hotel. Risker (talk) 19:05, 4 March 2013 (UTC)

Wikipedia talk:IP block exemption/log is really only proof that the vast majority of IP block exemptions logged on that page were granted by CheckUsers. :) If I tally the IPBE grants since 2011-04-09, over two thirds were given by users who have never been CUs. Amalthea 23:13, 4 March 2013 (UTC)

• Support though I'm not sure it will pass. There's too many administrators handing out IPBE like candy without knowing what they are doing (having the technical knowledge to do so) or whether said user really needs the exemption. Note that this will need to go to Bugzilla should it pass. --Rschen7754 18:12, 4 March 2013 (UTC)

It won't. I anticipate it being like unblocking CheckUser blocks: technically possible, but in principal, never done. This would be to allow admins to revoke IPBE if requested by the user holding it that they no longer need it. WilliamH (talk) 18:33, 4 March 2013 (UTC)

That is still possible through Bugzilla, I believe: you can allow a user to remove a right but not add it. --Rschen7754 18:47, 4 March 2013 (UTC)

That is correct, the ability to grant and the ability to remove a right as not linked in mediawiki. Snowolf ^{How can I help?} 21:06, 4 March 2013 (UTC)

Actually, it would probably result in a change in the configuration of administrator permissions. This would be fairly straightforward to accomplish, once consensus is reached. Risker (talk) 18:56, 4 March 2013 (UTC)

I too agree that this if approved would go on Bugzilla. It was my understanding that we already should be checking with checkusers in most cases. Snowolf ^{How can I help?} 21:06, 4 March 2013 (UTC)

• Support: Over the course of the last few years, we have seen IPBE granted in situations where there are active sockpuppetry investigations going on off-wiki, and when the reasons users have given for IPBE are highly questionable. Administrators granting IPBE generally do not keep track of the permissions they have granted so do not lift the IPBE in a timely manner; the current reviews are finding accounts granted IPBE where the block that affected the account was lifted long ago, and accounts that have not edited in over a year. As well, administrators are generally not providing sufficient information to editors to whom they grant IPBE, including the increased risk of being blocked and the fact that they are likely to be checkusered regularly as long as the IPBE is in place. But bottom line, administrators do not have access to the checkuser data that is usually necessary in determining whether or not granting IPBE is the appropriate action in addressing a user access request. Risker (talk) 18:56, 4 March 2013 (UTC)
• Ambivalent. I can't envision many circumstances where I would do this, but there are some rare ones. Can someone document that this has actually been a source of trouble? I'm seeing statements above that it has been, but nothing specific enough for me to decide whether there really is problematic granting of IPBE.—Kww(talk) 20:57, 4 March 2013 (UTC)

  I can think of at least three cases, just off the top of my head and one of which involved me back when I was a new admin, in which admins gave out IPBE and had to have their choice corrected by a CU. Admins tend to assume that since we can give IPBE, that means we're, you know, qualified to decide whether to give IPBE. Usually it turns out that we've done it wrong somehow - either we've granted it without adequate investigation (it can't just be "sure, user isn't visibly in trouble, looks fine" - that's the pit I fell into, for example), or we've granted it to someone who turns out to be using it to abuse, or we've granted it to someone whose situation would be better remedied by something other than a high-powered potential-block-evasion tool. As things currently stand, it's just far too easy for an admin to make an entirely-good-faith mistake and not realize that CU evidence is important for determining whether IPBE is a good option. That's leaving aside the other problem common to admins who give the bit out, which is as Risker says, a failure to tell people with IPBE that the right means they will be investigated more often than normal, and may be subject to wider-than-usual blocks. A fluffernutter is a sandwich! (talk) 21:07, 4 March 2013 (UTC)

• Support it's already best practice on the English Wikipedia to go bug a checkuser before granting IPBE and I have no issues formalizing this. I also have to say that indeed IPBE should be granted only after detailed explanations, and it seems best to defer it to those who are already expected to know about the technical side of things rather than expect an admin to handle it. Snowolf ^{How can I help?} 21:04, 4 March 2013 (UTC)
• Support Although this is a legitimate reason to leave the ability technically open to administrators. The original granting of IPBE by policy should be restricted to CU's. Crazynas ^t 06:05, 5 March 2013 (UTC)
• Oppose The underlying assumption of the CheckUser tool is that 1 IP addressdevice = 1 user. That has not been true for quite a while, due to Network Address Translation, Mobile computing, Proxy servers etc. I think that many, many, users edit from multiple devices in different locations. Granting IPBE is a statement of trust - that a particular user is not a sockmaster. That judgement call is better made by an admin who is familiar with the particular user account in question, rather than by a neutral CheckUser on the basis of outdated technical tools. --Surturz (talk) 10:22, 5 March 2013 (UTC)
  • .... what? That has never been the assumption of the CU tool. --Rschen7754 10:26, 5 March 2013 (UTC)
    • 'Internet device" then. The underlying issue is that one device likely has multiple users, one user likely has multiple devices, and device info in HTTP headers isn't even that reliable. Unless we implement social-media-website levels of privacy invasion, the CU tool will become less and less useful. --Surturz (talk) 12:16, 5 March 2013 (UTC)
      • You clearly do not understand how the checkuser tool works. No checkuser worth anything at all will ONLY use the IP address data in determining whether two accounts are related. The conclusion is made based on the exact circumstances of the IPs involved, the typical characteristics of the internet provider(s), the user agent(s) involved, the edits made, the timings of the edits, the typical characteristics of the sockpuppeteer (if known), and a host of other things that taken together paint a unique picture in each specific case (and the picture is not always a straightfoward one - indeed, it very, very rarely is). Let me be clear: If checkusers blocked accounts based only on IP information alone, at least 50% (likely more) of all user accounts on this site would be blocked. J.delanoy^gabs_adds 15:48, 5 March 2013 (UTC)
      • One of your statements concern me. You state that "That judgement call is better made by an admin who is familiar with the particular user account in question, rather than by a neutral CheckUser on the basis of outdated technical tools." The way I can interpret this is that let's get a person who may be involved rather than someone who is a neutral party. This is not how it works here. Actually, most of the IPBE flags I've seen has been given by neutral parties. So ask yourself then, who would be better at giving out the flag? A neutral admin or a neutral checkuser (who is most likely an admin as well) who has an extra set of tools to aid them in deciding whether or not IPBE is necessary? Furthermore, IPBE is treated as an administrative tool. Taken from the IPBE policy: This is a level of trust equal to that given to administrators. So why don't we have administrators have the technical ability to promote other users to administrators instead of restricting the ability to bureaucrats? Elockid ^(Talk) 21:30, 5 March 2013 (UTC)
        • That is not my argument at all. Let's be clear what this policy change is about: the CheckUser team is asking for more power. I've no doubt that this is done in good faith to assist in their mission of stamping out sockpuppetry, but the CheckUser team is very small compared to the number of administrators, so the net effect is that IPBE will be much harder to get. IPBE allows editors to contribute from more locations, so the follow-on effect will be to reduce the amount of contributions to WP. IPBE also helps users proactively remain anonymous and private by enabling them to use WP:TOR etc. (rather than relying on WP's functionaries to protect their privacy). WP's original strength was that it valued the contribution over the contributor - you could edit from anywhere without logging in. From a CU's perspective, doing that is sockpuppetry! In the end we are here to build an encyclopedia, not to assemble a group of trusted encyclopedia editors. In fact, "assembling a group of trusted encyclopedia editors" is complete anathema to Wikipedia, the encyclopedia that anyone can edit. If an editor has a sock account with IPBE and uses TOR so he can feel free to edit the Justin Bieber article without giving away that he's a fan, that's a good thing. --Surturz (talk) 01:04, 6 March 2013 (UTC)
          • Well, IPBE is not meant to be easy to get. From the IPBE policy page: The right is given exceptionally and only for good reasons. Furthermore, handing out IPBE for privacy reasons (non-related censorhips, etc) or to have the ability to edit through more locations are not valid or exceptional reasons to having to use IPBE. Elockid ^(Talk) 02:01, 6 March 2013 (UTC)
            • "Let's be clear what this policy change is about: the CheckUser team is asking for more power." I am almost lost for words at such a enormous sweeping assumption of bad faith. The reason for this policy adjustment is simple: the community has the right to expect that the decisions its administrators make rely on information that admins have access to. When admins hand out rollback, they are not prevented from checking the user's contributions; when admins hand out autopatrolled, they are not prevented from ensuring that the user complies with WP:BLP; IP block exemption should not be an exception to this principle. WilliamH (talk) 10:58, 6 March 2013 (UTC)
• Oppose as useless - What are you going to check? I want IPBE, so I ask a CheckUser to check my account whether I have socks .. no, I don't, so the IPBE gets granted. So, now I can sock, because I can edit through any Proxy I want. What is a CheckUser now exactly going to do to when granting an editor IPBE? Checking whether the editor was before using a proxy that needed IPBE .. wait, that is impossible because that editor would be blocked when he edits through that IP anyway. Whether he lives in an area that requires IPBE or is in a situation that requires IPBE? That is something that anyone can do (including WP:AGF that someone is living in China, Egypt, Saudi Arabia ..). Additionally, are we going to make this a global policy, because any user who is editing on 2 or more wikis will not ask IPBE on the local ones, but globally, which you can't even detect here locally.

  Additional point, 'I need IPBE because I am flying to China next week for <whatever>' - do I now need a CheckUser checking my current position etc. to find out whether I next week need it? --Dirk Beetstra ^{T C} 11:51, 5 March 2013 (UTC)

To echo Risker, CheckUsers would check the data that is usually necessary in determining whether or not granting IPBE is the appropriate action. As for your additional point, it's irrelevant — a request preemptive of circumstances would never be granted. WilliamH (talk) 14:18, 5 March 2013 (UTC)

'.. the data that is usually necessary in determining whether or not granting IPBE is the appropriate action' .. what exactly would you want to check. If the editor socked before, if the editor is editing regularly through those blocked proxies and needs it, whether they are in a geographical area that would make it reasonable for them to have necessity of them editing through a proxy, what?

A request preemptive of circumstances would never be granted. You say that we should not WP:AGF and assume that that editor genuinly wants to use it? --Dirk Beetstra ^{T C} 05:49, 6 March 2013 (UTC)

I said no such thing. IP block exemption is not granted to individuals before they need it. WilliamH (talk) 14:01, 6 March 2013 (UTC)

• Question, are CheckUsers now also going to check Administrators and others with advanced bits that automatically give IPBE before they are promoted to admin (or whatever)? --Dirk Beetstra ^{T C} 11:45, 5 March 2013 (UTC)

Since admins are granted IP block exemption purely by virtue of becoming an admin and completely regardlessly of whether they need it or not, this question is irrelevant. WilliamH (talk) 14:18, 5 March 2013 (UTC)

No, it is not. If a 'normal user' gets granted IPBE it needs to be checkusered, but for becoming an admin, which includes the IPBE it is not. The admins are trusted by the community, and normal editors are not? --Dirk Beetstra ^{T C} 05:49, 6 March 2013 (UTC)

Nope, that's obviously not what I'm saying and my previous comment already gives adequate explanation, but now at least the straw man of the original question has been spelled out. WilliamH (talk) 11:01, 6 March 2013 (UTC)

• When this discussion started, I actually checked my user rights to see if IPBE was separable from the admin package, since I don't need it. It's currently not removable from admins, but if it were I see no reason why it shouldn't then be on an as-needed basis for admins as well. A fluffernutter is a sandwich! (talk) 22:19, 5 March 2013 (UTC)

  I would not oppose separating it from the admins, though it is there for the reason that some do edit through general ranges (with changing IPs) and may run into blocks where they are obviously not the 'next account' of the editor, or the 'new account' of the editor, who got blocked before. --Dirk Beetstra ^{T C} 05:49, 6 March 2013 (UTC)

• Support. This would save on a whole lot admin errors/misunderstandings, and I've yet to see anyone present a legitimate situation where a non-CU can adequately determine whether IPBE is a good call. A fluffernutter is a sandwich! (talk) 22:19, 5 March 2013 (UTC)
• Oppose per reasons given by Dirk, but also regarding new users who simply have no other way to edit. CheckUser blocks should indeed be checked by CheckUsers to make a full determination, but with open proxies, they must be blocked. No ifs or buts. There may or may not be sockpuppetry going on, but given their open nature, a sockpuppeteer can easily switch onto or off of the IP at will. It is to override these blocks where CheckUser data would not be helpful. I shall illustrate with an example. A user in China wants to edit sensitive political topics, and so must use Tor. They need to prevent their true IP address from being connected to their account in any way. If they try to establish a reputation, get IPBE, and then edit sensitive topics, the government will already have his IP and know who the account belongs to. Let's say he makes a request to UTRS from his true IP. In that case our best bet is to create an account for him with IPBE per AGF and monitor it for abuse. At no point of this process is CheckUser useful. He doesn't have an existing account, so we can't run CheckUser on that. As for his existing IP, we just need to run WHOIS on it to make sure it is really from China. And as for monitoring the account, what's the worst that CheckUser could reveal? A bunch of Tor nodes? That's exactly what we'd expect. Now, on the other hand it could reveal a match with a static IP used by a sockpuppeteer. But if some sockpuppeteer is willing and able to go to such lengths, is he really dumb enough to edit on this account without a proxy, especially since he can? Ultimately, if the user turns out to be a sockpuppet, it will be based on behavioral evidence alone, and not IP addresses used. -- King of ♥ ♦ ♣ ♠ 00:41, 6 March 2013 (UTC)
  • THIS. My argument exactly, except in coherent and logical form :-) --Surturz (talk) 01:15, 6 March 2013 (UTC)
  • What has left you with the impression that those users are either (a) refused IPBE by checkusers if they already have an editorial reputation or (b) granted IPBE by anyone if they have no editorial reputation? Unfortunately, Chinese IPs are one of the biggest generators of spam accounts on Wikimedia projects, and anyone who's handing out IPBE to any China-based accounts without an editorial reputation is opening doors that really shouldn't be opened. Risker (talk) 01:27, 6 March 2013 (UTC)
    • An admin who is friends with the Chinese user in real life could hand IPBE to a new account. That's the point. --Surturz (talk) 01:41, 6 March 2013 (UTC)
    • Requests for IPBE from China are also rare enough (maybe one or two a month) that they are easily monitored. -- King of ♥ ♦ ♣ ♠ 07:51, 6 March 2013 (UTC)
• Oppose per Dragons flight. I was unable to edit a while back while travelling due to my IP. I only had a short amount of time available so I did not seek the flag; however, had the block been at my final destination, I would have desired to be unblocked as soon as possible. I see no reason why an admin should not be allowed to give me the flag immediately on review of my unblock request. Ryan Vesey 01:49, 6 March 2013 (UTC)
• Support IP Block Exemption isn't something we hand out very often. Certainly as an admin, I wouldn't grant it without asking a CU to check to make sure I'm not about to give the keys to the kingdom to a prolific sockfarmer. If a legitimate user wishes to be granted IPBE, they should have no reason to worry about a CU checking up on them. This seems an utterly reasonable and sensible thing to do. —Tom Morris (talk) 13:33, 6 March 2013 (UTC)
• Strong support The current system is too vulnerable to social engineering. Recently there was an example of someone who got IPBE because they might go to China some day. The more important thing we need is a centralized system to track why IPBE was given to each user - which blocked ranges should they use. (IPBE is not a license to edit over arbitrary proxies and ranges.) Having fewer people grant the IPBE bit will be important for keeping that documentation correct. I think we have adequate checkusers for rapid processing of valid requests. — Carl (CBM · talk) 14:59, 6 March 2013 (UTC)
• Support: I've seen too many instances where IPBE was given out like candy. I'm sure for the most part they were given at good faith but one time flings like getting caught in an autoblock is not something I would call an exceptional or compelling reason. Expanding further, blank reasons such as this or this or not leaving a reason on the IPBE logs page is not acceptable practice. Elockid ^(Talk) 18:52, 6 March 2013 (UTC)
• Oppose Checkusers already have enough to do, and are also subject to the same mistakes that an admin may make. It would be better to focus attention on the mistakes and have them and their makers corrected. Graeme Bartlett (talk) 20:59, 6 March 2013 (UTC)
• Support sounds logical. --Guerillero | My Talk 21:21, 6 March 2013 (UTC)
• Oppose - the fact that some admins have incorrectly assigned the exemption doesn't mean that the ability should be removed from all of them. Making it checkuser only introduces an extra layer of bureaucracy and makes it more difficult for a good-faith user to get the help they need. If someone is being given the exemption because they might go to China some day (to use the above example), then that's a training issue for the admin, not a reason to take it away from all admins. --B (talk) 21:41, 6 March 2013 (UTC)
• Question How much damage are admins causing to the project by handing out IPBE too freely? IPBE is the only check and balance non-admins have against problematic rangeblocks. I've shown a number of problematic rangeblocks in the #Restrict rangeblocks to CheckUsers section below. It would be helpful for the community in analyzing the extent of the problem if we could get some examples. Could somebody please list some diffs showing the damage admins are causing by handing out IPBE inapproriately? Thanks. 64.40.57.72 (talk) 03:04, 7 March 2013 (UTC)
• Oppose. Because admins are able to make rangeblocks, they should be able to make exceptions from those blocks. Ruslik_Zero 19:09, 7 March 2013 (UTC)
• Question Did anybody ask the CUs if they want their workload increased? WhatamIdoing (talk) 19:30, 7 March 2013 (UTC)
  • This proposal was floated on the functionaries mailing list (which includes all CUs) before it was made here. All the CUs (and non-CUs) who opined supported the idea. T. Canens (talk) 19:56, 7 March 2013 (UTC)
    • Can I respectfully suggest that in the future the functionaries mailing lists should refrain from discussing proposed policy changes? It's a violation of the "Stealth canvassing" provision of WP:CANVASS. --Surturz (talk) 23:23, 7 March 2013 (UTC)
      • Uhh...the proposal floated the list before it got here, and in that thread, someone said we should post it here. So naturally everyone can come here to comment, but not all have. We are allowed to have our own business happen and have a proposal come out of it. It's not called canvassing. -- DQ on the road (ʞlɐʇ) 23:39, 7 March 2013 (UTC)
      • The proposal was born out of organizing an IPBE cleanup effort and was then brought to the community quite quickly. I understand your concern and it should have been made clear at the start, both to prevent a few misunderstandings and to be transparent about the explicit pointer to this discussion at the "noticeboard" for the affected users. Sorry about that. Amalthea 23:42, 7 March 2013 (UTC)
      • Indeed, as Amalthea and DQ say, this proposal came from a "How can we fix the IPBE situation? Hm, what about proposing X to the community?" discussion, and we're here to see what people think about it. It was not a canvassing situation, but rather the reverse: an idea conceived on a mailing list, brought public for discussion. A fluffernutter is a sandwich! (talk) 23:51, 7 March 2013 (UTC)
        • It's a bad look: a proposal to increase the power of the CheckUsers is proposed as an "uncontroversial" change (when it clearly isn't, given the number of Oppose votes), and then it is revealed later that there were private discussions off-wiki among the beneficiaries of the proposal before it was made. The functionary lists are there to assist the functionaries enforce existing policy, not to facilitate bloc voting on new policy. As Amalthea says, the origin of the proposal should have been declared up front. --Surturz (talk) 01:01, 8 March 2013 (UTC)
• Support per Risker. There are occasional situations where it would make sense for an admin to be able to hand out adminship to others, yet we do not allow admins to do that. In the vast majority of situations, admins should not hand out IPBE without checking with a CU first; we might as well cut the middleman. T. Canens (talk) 19:56, 7 March 2013 (UTC)
• Support  Roger Davies ^talk 07:09, 8 March 2013 (UTC)

In such situation the editor does not get article creator's credit which they deserve. Therefore, I suggest to delete the redirect page first or do something here! Example this editor and this editor etc should get the credits! --Tito Dutta (contact) 01:47, 7 March 2013 (UTC)

Is there a point in collecting new page creation credits? I thought WP:NOT a social club would apply to collecting points/barnstars/whatever. WP:NOTSOCIAL would seem to illustrate what Wikipedia is for (the creation of knowledge compilations) and what it isn't for (the creation of social identities) -- 65.92.180.137 (talk) 01:52, 7 March 2013 (UTC)

It's about keeping record! --Tito Dutta (contact) 03:20, 7 March 2013 (UTC)

It's about collecting points. Several articles have been merged to be split out again at a slightly different title. If we extend your proposal, we end up having us search out all of those and get histmerges, to get the first mover attached to the current article name. (and remove the points from the most recent split-out creator, so that only the first creator has the points) Why would a split-out creator have an article creation point, instead of the first creator? If an article that covered several topics was split apart, why would you need to credit points to the split-out creator, instead of the people who actually worked on the article content before it was split? How is that any different from keeping the page creation points with the redirect creator? Credit should be given for useful content addition, not page creation -- 65.92.180.137 (talk) 03:53, 7 March 2013 (UTC)

Isn't it NewPageItis, a form of WP:Wikipediholicism (related to WP:Editcountitis and WP:Barnstaritis) ? -- 65.92.180.137 (talk) 04:05, 7 March 2013 (UTC)

If the authors who replaced the redirect want to say that they are responsible for creating the page, then I don't think anyone is going to care. However, I don't think we want to be the habit of deleting content just to help someone score points. In a case like your first example this is doubly true since there was meaningful content there before the redirect was created. Dragons flight (talk) 04:17, 7 March 2013 (UTC)

I think this is going a bit over the top. It's not as if there was something there before that I'm trying to claim credit for. It was a redirect which I turned into an article which is classed as new under DYK rules. The C of E God Save the Queen! (talk) 07:13, 7 March 2013 (UTC)

• The point is being misunderstood here! We have stopped WP:CUTPASTE. It's all about giving the "real" article creator the credits he deserves. The C and E did a brilliant work in the stadium's article, but, you can't find it in the list of pages he created. C and E, your article is being used just as an example. Both your article and DYK is fine! --Tito Dutta (contact) 09:27, 7 March 2013 (UTC)

If you think that tool is miscounting the "real" number, then the solution would be to patch that tool to include created-from-redirect articles. I don't think we need to start building a complex system of automatic deletion, with all the hassle and problematic side-effects, to fix these few cases. Andrew Gray (talk) 09:46, 7 March 2013 (UTC)

I'd agree with that. No need to delete redirect pages just to recreate them again. The C of E God Save the Queen! (talk) 12:42, 7 March 2013 (UTC)

If you delete the two letters "no" from near the end of the address in the output of the tool, don't you get the count you are looking for? Rmhermen (talk) 16:21, 8 March 2013 (UTC)

Wikipedia's policy to generally not duplicate wikilinks in the same article makes sense from a visual standpoint, but when you think of the way people tend to use Wikipedia articles, it makes less sense. People skip around for the information they need, far more than they read articles from beginning to end. Coming across an unlinked important term later in an article, one must search back for the link or hope the corresponding info is easy enough to find by searching Wikipedia manually.

I'd like to propose allowing duplicate wikilinks in articles, though perhaps still keeping them unique to each paragraph or section — while also providing wiki code to either keep the duplicate links uncolored, or imbue them with a more subtle color or marking than the default.

For example, an important term could be linked the first time it appears in each section, with only the first such link in the entire article actually being colored using default link coloring, and the rest being either uncolored, or more subtley colored, or otherwise marked, perhaps only upon hovering the mouse over them. Equazcion ^(talk) 03:01, 4 Mar 2013 (UTC)

It's a good idea, the trick is going to be in finding a method of pulling it off that won't start an angry mob. I, for example, detest anything involving mouse hovering, and I think that having links that are the same color as the base text is going to just be confusing, but am open to other ideas. That the popups tool exists and is widely used means that there's a strong likelyhood that other users won't have nearly the same issue with hover text as I do. I guess that the point that I'm trying to make is that even minor UI changes get people pissy, and there's no way to do this without it being a major change. Sven Manguard Wha? 06:33, 4 March 2013 (UTC)

I'd oppose the introduction of different levels of wikilinks as making Wikipedia even more confusing. If a term should be wikilinked, it should be wikilinked, even if it already had been wikilinked before in an earlier section. Also you say "Wikipedia's policy to generally not duplicate wikilinks in the same article <snip>". Which policy is that? -- Toshio Yamaguchi 08:04, 4 March 2013 (UTC)

I'd like to propose allowing duplicate wikilinks in articles, though perhaps still keeping them unique to each paragraph or section - my understanding is that this is a lot closer to the practice which actually exists than the strict wording of the MoS would suggest. A reasonable level of relinking - not as high as one per paragraph, but one per major section or per screenful of text - is usually seen as sensible. Andrew Gray (talk) 09:40, 4 March 2013 (UTC)

@Equazcion: Are you referring to WP:REPEATLINK? -- Toshio Yamaguchi 16:17, 4 March 2013 (UTC)

I understand Equazcion's concern. I would support adding links on first mention per second-level section, but not more, so articles don't get flooded with links. --NaBUru38 (talk) 14:53, 6 March 2013 (UTC)

I think this is a creative idea, but if I skip to the middle of the article, I'd rather have it be easy to spot the link. If the same link is provided a couple of times in an article, that doesn't usually bother me. WhatamIdoing (talk) 19:25, 7 March 2013 (UTC)

I think that important links should be allowed to be duplicated into the See Also section. And that each section be allowed to have a repeated link in the first instance. They should stay as blue links. The current guideline is just unhelpful to users of Wikipedia, instead being only useful to editors. -- 65.92.180.137 (talk) 04:03, 10 March 2013 (UTC)

There's no firm rule against repeating a link in See also. It's commonly not seen as necessary or desirable (think about how long Cancer#See also would be, if we listed every term that somebody thought was "important"), but it isn't absolutely prohibited. WhatamIdoing (talk) 04:27, 10 March 2013 (UTC)

I originally posted this on VP(t), but, I now realise it probably belonged here...

Working a bit on a wide table, I found out about the overflow property of CSS. And, I finally decided to test how "overflow:auto" would make the table look like in my smartphone (a Windows phone). To my surprise, it worked pretty fine, making otherwise inaccessible areas of the table, scrollable and readable (whereas at present, almost any table appears clipped in the mobile version on my phone). As even Microsoft has implemented support for such a feature, wouldn't it be a good idea to add (conditional) code on everything other than text so that it would appear scrollable in the mobile version if overflow is clipped? Or at least incorporate such a change in the wikitable template? The "auto" value means that the table will only become scrollable if it doesn't fit on the screen, thus not affecting at all users who access the mobile version through systems with screens wider than a phone's one.

Example to be viewed with cell phone:

• without overflow tag:

Signatory	Conclusion date	Institution	Majority needed			Abstentions	Deposited	References		Implementation law	Balanced budget amendment

• with overflow tag (can be touched and slided although no bar appears on my cell phone):

Signatory	Conclusion date	Institution	Majority needed			Abstentions	Deposited	References		Implementation law	Balanced budget amendment

Heracletus (talk) 15:53, 8 March 2013 (UTC)

I like this idea and think it would help with a nunber of pages I've come across. 64.40.54.70 (talk) 07:12, 10 March 2013 (UTC)

You have to be careful with overflow CSS per accessibility concerns. --Izno (talk) 14:23, 10 March 2013 (UTC)

Izno, those accessibility concerns are about the very example I make, i.e. people using browsers that do not support css, like most mobile browsers used not to. But, today, it's really hard to find an updated browser that does not support css or javascript. In either case, overflow:auto leaves the affected field unaffected(!) if it is not already cropped. If it is already cropped (because it does not fit in the screen), it only, then, adds a sliding bar.

To phrase it better,

• If the user has no css support nothing happens, apart from the overflow:auto field appearing as text.
• If the user has css support and the affected field (in this case a table) does not fit in the screen, then, that field (the table) can now be slided and seen fully, a feature which is not otherwise supported on most mobile browsers.
• If the user has css support and the affected field (the table) fits in the screen, nothing happens.

I think the improvement is clear. I modified the tables above to make much more evident what i mean. Using the overflow property set to auto makes wikipedia more accessible than it currently is, especially to mobile users, because their screens are small enough to make most tables appear cropped, even if those are not wide enough to appear cropped to other users. Heracletus (talk) 23:34, 12 March 2013 (UTC)

Sometimes there is a red link (no such an article, it opens an editor). Maybe it will be better to get a list of languages in which the missing article does exist? — Preceding unsigned comment added by IKhitron (talk • contribs) 10:38, 12 March 2013

That will be problematic because when there is not even a local article in English, how are we supposed to know how the subject is called in other languages? E.g. the interwiki links you find in many English articles have all been inserted manually either here at the English Wikipedia or most recently at the Wikidata project, but there is no standard database of all possible subjects in multiple languages. De728631 (talk) 14:18, 12 March 2013 (UTC)

There is already guidance on how to integrate interlanguage links and red links ]http://en.wikipedia.org/wiki/Help:Interlanguage_links#Inline_links here]. My preferred method is to create a redlink followed by a parenthetical reference to a foreign language wiki, ex: No link exists here in English (de). Andrew³²⁷ 19:59, 12 March 2013 (UTC)

It would be helpful if Wikilinks in articles could, on mouseover, provide a small pop-up, "tool tip"-style definition or succinct and incisive summary of the article or term that the link points to, perhaps limited in length to 200 or 300 characters. The content of the summary could be written in association with existing article text, perhaps in a separate section or text field called "Wikilink Summary Content", or whatever. This would be particularly helpful in technical articles or in articles about less familiar subjects, and would spare the reader being diverted by having to open and engage with entire other articles to find out what terms means, sometimes repeatedly in a technicality-rich passage, while trying to stay focussed on reading the original article.

Thus, a Wikilink to County Galway would offer pop-up text such as "A county on the west coast of Ireland"; a Wikilink to Albert Einstein would offer "A twentieth century physicist who developed the theory of relativity"; a link to flavonoid might offer "a class of plant metabolites that offer dietary benefits in humans"; a link to string theory could say "a theory in particle physics that attempts to reconcile quantum mechanics and general relativity"; a link to meteorite could say "a rock from outer space that has fallen to the surface of a planet".

I propose that such brief summaries be written separately from article leads, rather than simply "popping-up" the existing article lead itself, as the latter often contains a jumble of non-succinct and distracting etymology, eye-tangling pronunciation symbols, alternative similar terms, and other eye-bothering clutter.

Perhaps a new template at the beginning of an article might look like this: {{article-summary|text}}, where the text is what would pop-up on Wikilink mouseover elsewhere. — O'Dea (talk) 01:10, 13 March 2013 (UTC)

You could use {{tooltip}} (a.k.a: {{abbr}}) -- for example: County Galway — Albert Einstein — But this is probably not considered good practice - or is it?   ~E:74.60.29.141 (talk) 05:07, 13 March 2013 (UTC)

However, if I catch your drift, you would like to see an automated process, perhaps a hidden parameter with a one-line description at the top of each page, which would appear as a tool-tip (as above) whenever one hovers on a link to an article with such parameter specified. Right?    ~E:74.60.29.141 (talk) 05:41, 13 March 2013 (UTC)

While I like the idea, I'm guessing you might not know about the Navigation popups tool that can be enabled from the Preferences->Gadget menu. On hovering over a link, it pops up the lead and provides a nav menu with other important links – a really great timesaver. It doesn't generally render the pronunciation stuff, though this is probably an unintentional side-effect of it simply ignoring templates. Certainly, some changes could be made to it to look for an {{article-summary}} and render that if it exists, and/or filter out other undesirable stuff. —[AlanM1(talk)]— 05:40, 13 March 2013 (UTC)

My prayers have been answered. Wow, I had no idea about that Navigation popups tool. It's pretty much what I wanted, plus it even pulls out a photograph from the article to illustrate the pop-up. It's the story of my life – I have invented a number of useful devices in the past that could have made me some money, but I always find out that someone else thought of it before me. Thank you for the replies. — O'Dea (talk) 06:07, 13 March 2013 (UTC)