Jump to content

Wikipedia:Village pump (proposals)/Archive 86

Add links
From Wikipedia, the free encyclopedia
Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

History revisions should use historical file versions

Recently I've seen an editor denigrated at Wikipedia Review and on RfC/U for keeping an embarrassing image on his user page. The impact of the harassment has been substantial. But actually, the file was altered on Commons to make it much more 'embarrassing' than it had been. The result is that anyone could link to his contribution history and it comes up as a page that never existed. The 'remedy' applied appears to have been to delete all the past revisions containing the picture, but that makes it much harder for me to look at the past issues of relevance to the RfC/U, and is no good general answer.

So why don't we just fix this? Change the display of versions from the File History so that they use the historical version of the file from Wikipedia or Wikimedia Commons, so that the page displays the same way as it did?

(You could also do this with transcluded pages)

Wnt (talk) 15:07, 10 February 2012 (UTC)


But if the prior version was removed or altered for cause (like copyright or usage issues) then that would also be a "bad result." I would suggest that where an image is altered for any reason, that links in userspace be noted and an "original image unavailable" notice be returned. Wouldn't that accomplish as much as you wish? Collect (talk) 15:18, 10 February 2012 (UTC)
I don't see the point in that. If an individual revision was a copyright violation it was likely deleted; if not, including it in a historical version here is no different than displaying that historical version of the file page at Commons. Wnt (talk) 15:35, 10 February 2012 (UTC)
Comment: Most non-free files have had the old versions deleted per F5 Unused non-free media. Of course, user pages should not have non-free files, but you would have to have some mechanism to differentiate. ---— Gadget850 (Ed) talk 16:02, 10 February 2012 (UTC)
I'd be OK with having a deleted version end up as a redlink in the history version - though of course a bluelink would be a better outcome. Wnt (talk) 20:18, 10 February 2012 (UTC)
  • Support. Of course if the old file revision has been deleted we have to decide whether to show a red link, or the current revision. Old file revisions that are copyvios need to be deleted anyway - merely uploading over them is not sufficient - so that's not an argument against it. Note however that transcluded templates present exactly the same problem - do we want to use older revisions of those too? Dcoetzee 00:56, 25 February 2012 (UTC)
  • Comment you're going to have to deal with templates as well as files. I suspect the devs may so "no" on performance grounds. Josh Parris 05:32, 26 February 2012 (UTC)
Performance issues are not stable over the years, given changes in both software design and hardware design.  Nor, as a function of implementation tradeoffs, is it necessary that there must be performance delays.  I'm not one of the devs, I'm just saying that these are general principles.  Unscintillating (talk) 03:45, 28 February 2012 (UTC)

Again, consolidating those editnotices under the Editor

I remember making a proposal to this extent earlier at some point, and quite a few people agreed with my idea. Yet, nothing has happened, the only change made was one apparently forced by WMF legal. I still think that consolidating the messages down there into just one area would make a whole lot more sense. Maybe something like this:

For articles...

And for talk pages

How's this? ViperSnake151  Talk  20:26, 14 February 2012 (UTC)

'Comment: yeah, I looked and thought about the last proposal as well. But it got bogged down in the need for the legal team to have a look. Since none of them were around, it was rather pushed into the long grass. Also as I recall WikiEd or somesuch reorganises the lower sections. Speak to Geoff or someone and come back with approval, I think. Grandiose (me, talk, contribs) 14:23, 15 February 2012 (UTC)
Comment: Yes, please, speak to Geoff. The language of that wording is very specific ("by clicking the save page", implies affirmative consent, for instance). It's really really important that the WMF's Legal and Community Advocacy department be made aware of what language is decided upon here, prior to implementation. I know that Geoff will work with you, but there are some things that have to be, for legal reasons. Philippe Beaudette, Wikimedia Foundation (talk) 09:02, 21 February 2012 (UTC)
Hmm, you really do try to have your finger in every pie, don't you? --MZMcBride (talk) 14:18, 1 March 2012 (UTC)
That's rather what I get paid for.  :) Philippe Beaudette, Wikimedia Foundation (talk) 18:31, 1 March 2012 (UTC)
  • You should be looking at ways to reduce the amount of text, rather than simply trying to consolidate it. Nobody reads the warnings because they're too much text. --MZMcBride (talk) 14:18, 1 March 2012 (UTC)

Automatic edit summary

I have a proposal concerning the omission of edit summaries. If a user who edits an article leaves the edit summary blank, their changes (such as text inserted/removed to the article) will be shown, making it an automatic edit summary. However, if an edit summary is provided by the user, then that edit summary will be shown instead. The reason for this proposal is that there are far too many edits without edit summaries, leaving it inconvenient and time-consuming for other editors who want to view changes which have not been explained. Not only will this promote the use of edit summaries, but it can be used to view and stop vandalism to an article as the vandal's edits will be visible. Till I Go Home (talk) —Preceding undated comment added 05:17, 15 February 2012 (UTC).

  • Question: The edit filter (the way we would implement this) is dumb. How can you expect it to provide such a detailed edit summary? Or, are you talking about putting the diff into the edit summary (impossible)?Jasper Deng (talk) 05:20, 15 February 2012 (UTC)
Whatever is inserted or removed will be shown in the edit summary (e.g. if "abcde" is inserted in the article then the edit summary will say "abcde". Till I Go Home (talk) —Preceding undated comment added 05:25, 15 February 2012 (UTC).
We can't afford to do that, especially for page blanking, unless we greatly expand the edit summary field (which is not feasible).Jasper Deng (talk) 05:28, 15 February 2012 (UTC)
Perhaps if none is given, something descriptive could be added. For instance, "X characters added/deleted to Y sections" or something of that nature. ♫ Melodia Chaconne ♫ (talk) 05:51, 15 February 2012 (UTC)
Editsummary field has a limit, so we actually can add (as much allowed in that limit) the text that was added or removed with an indication of which ever on a blank editsummary. --lTopGunl (talk) 11:35, 15 February 2012 (UTC)
This makes a lot of sense to me. In fact, for small edits I routinely copy paste the text I added into the edit summary. My Wikipedia:Persondata-o-matic tool automatically produces detailed edit summaries describing exactly what was added, removed, or modified. For larger edits we'd just need a bit of technology to automatically summarize the edit in a useful manner (e.g. I could imagine an automatic program producing "Add paragraph to Cuisine section beginning `Fish are commonly eaten in Japan...'"). Dcoetzee 14:14, 15 February 2012 (UTC)
  • Oppose The issue really is that editors don't leave proper edit summaries. This proposal would hide the problem by putting automatic text in for the edit summary. At least seeing it blank is an opportunity to educate the user to proper Wiki etiquette. Plus, no computer system is going to be smart enough to explain why the edit was made. You can look at the diff if you want to see the edit itself. — The Hand That Feeds You:Bite 14:18, 15 February 2012 (UTC)
    • It seems like it would be easy to add some kind of marker to visually distinguish automatic edit summaries from manual ones, so that nothing is being "hidden." Moreover, intention can often be inferred easily from the content of the edit (for example, if it's "changed serius to serious" you can reasonably infer it was a spelling correction). If an editor omits an explanation or justification for a controversial edit, they're more likely to be reverted and have to explain it on the talk page, so the incentive to include one is still there. Dcoetzee 15:21, 15 February 2012 (UTC)
  • Comment: It seems unlikely that such a thing could be done accurately. I love the idea, I just think it is technologically unfeasible. How is the editing process itself supposed to detect then summarise edits not summarised by the editor? See my proposal below... I do actually think my proposal is a better idea because what has been originally stated here is a branch of the problem I have addressed below[1]. My idea in its basis is to try to strongly encourage edit summaries but also to make it clear what the edit summary IS and what it is NOT. Why make things easier for those who are already abusing the edit summary?--Djathinkimacowboy 13:04, 16 February 2012 (UTC)
Addendum to my comment: There is another problem revealed here: many editors do not fully comprehend how an edit summary should be written. I believe some of them don't even see the box when they edit, or simply don't know what to put. I myself as a raw newbie used to mark too many edits as 'minor' because I did not know the proper definition of a minor edit. See, we need to push editors to provide edit summaries, understand it well, not use it as a text-messaging service and be clear about why the summary means so much. Of course there are editors who simply want to make it hard for others to see what they've done and refuse to summarise anything.--Djathinkimacowboy 13:07, 16 February 2012 (UTC)
  • OpposeThis will automatically incorporate any attacks, copyvios or other bad edits ("poop fuck shit hahahahahah") into the edit summary. It's bad enough when they occur and aren't revdeleted, but now, instead of being hidden in a prior version and only likely to be discovered or viewed if a user specifically looks at prior versions, will now be evident just by looking at the edit history.--Fuhghettaboutit (talk) 13:40, 16 February 2012 (UTC)
  • If a lack of edit summaries is such a concern, and I'm not sure that it is, a much simpler and easier solution would be to have the "prompt for edit summary" option in prefs enabled by default --Jac16888 Talk 13:46, 16 February 2012 (UTC)
  • Support as opt-out: can be annoying for regular editors who don't want all their edits filled with the text they add to the articles and are used to adding manual edit summaries for their own edits. Should be enabled by default to allow the benefits discussed above. Edit summary has a limit so there won't be issues of huge amounts of text flooding. On a side note, this can not be taken as an alternative for manual edit summary, so this should be marked as an 'auto-edit summary' like a filter so that the issue is not hidden under the carpet. --lTopGunl (talk) 01:13, 26 February 2012 (UTC)
  • Comment would the automatic summary actually be helpful? This already happens on page creation, and its not necessarily clear what is going on from that... Aslbsl (talk) 20:48, 28 February 2012 (UTC)

Adding Modern Language Association format into Wikipedia?

People have believed that separating titles and URLs from each other in one format may presume link rot and bare URLs. Fortunately, that is precisely one of acceptable formats of MLA. Another format of MLA for websites omits URL because a URL is optional to add.

For example, from previous revision of Sam and Diane:

Shapiro, Ben. Primetime Propaganda: The True Hollywood Story of How the Left Took Over Your TV. New York: Broadside–HarperCollins, 2011. Google Books. Web. 04 Feb. 2012 <http://books.google.com/books?id=ymAWgveoxW8C>.

I have previously discussed this issue in WP:Village pump (miscellaneous)#Presumptions of link rots vs. MLA format. Per WP:CITEVAR, I want the MLA format to be accepted into essays, guides, and guidelines of citations, such as WP:Citing sources and WP:Bare URLs.

Sources for MLA usage:

Right now, Frasier Crane, Sam Malone, and Diane Chambers are tagged for link-rotting, in spite of using MLA. I wonder if MLA formats are acceptable.

To be honest, I don't like using cite templates anymore; too inconvenient to search and less readable. --George Ho (talk) 06:43, 25 February 2012 (UTC)

I am not sure what your asking - but the format used at Frasier Crane, Sam Malone, and Diane Chambers are what you see when you print a page. We dont realy have a need to do this for our readable version because the print version will make the ugly hard to read references automatically. Are you saying you like the url to be seen at all the time? We have templates to prevent this from happening because some Urls are simply to long and thus makes pages looks sloppy and unprofessional. A bare url does not help our readers and in fact I would say long urls impede readers ability to read references properly. We have tools to help you with this see Google book tool for an example More at Wikipedia:Citing sources#Citation templates and tools. "All that said" - there is no set way for referencing see Wikipedia:Verification methods. Moxy (talk) 07:06, 25 February 2012 (UTC)
This is more user friendly and professional looking
Ben Shapiro (31 May 2011). Primetime Propaganda: The True Hollywood Story of How the Left Took Over Your TV. HarperCollins. ISBN 978-0-06-193477-3.
Then this I think
Shapiro, Ben. Primetime Propaganda: The True Hollywood Story of How the Left Took Over Your TV. New York: Broadside–HarperCollins, 2011. Google Books. Web. 04 Feb. 2012 <http://books.google.com/books?id=ymAWgveoxW8C>. — Preceding unsigned comment added by Moxy (talk • contribs)

Wikipedia is the encyclopedia anyone can edit in any style, as long as you establish the style as the first editor or gain consensus to change it. Given that, you can use MLA with or without templates (which we don't have). You need to discuss style changes on the article talk page. MLA uses bare URLS in that manner because it is a style guide for print. I predict that exposing bare URLs won't be popular. ---— Gadget850 (Ed) talk 09:46, 25 February 2012 (UTC)

Which article talk page? Not specific article, such as "Frasier Crane", isn't it? --George Ho (talk) 20:12, 25 February 2012 (UTC)
MLA is already acceptable. In fact, WP:CITE says that editors may use any citation style, including styles they've just made up. See the second question at Wikipedia talk:Citing sources/FAQ. WhatamIdoing (talk) 03:18, 27 February 2012 (UTC)
Then why are formats tagged as "link rots" or something like that? MLA optionally includes URLs separately, but I use the MLA's URL format because I don't like templates as much as MLA. Is this of all MLA formats acceptable? --George Ho (talk) 03:33, 27 February 2012 (UTC)
Maybe because the user who tagged the pages didn't know any better? Maybe because he took a quick look and didn't realize that those are full bibliographic citations? People make mistakes all the time, and Wikipedia is so complicated that nobody can keep up with all the details. Have you considered asking him what he was thinking? WhatamIdoing (talk) 03:59, 27 February 2012 (UTC)
I'm not an administrator or experienced yet. I wonder if you can contact him about this issue. Sometimes, he dislikes bare URLs. --George Ho (talk) 04:02, 27 February 2012 (UTC)
I suspect that it was just an honest mistake of the sort that all of us make on occasion, but I've left a note for the user in case he wants to comment.
By the way, you might like to read the documentation at Template:Cleanup-link rot. As with all such templates, if one is added to an article when it shouldn't be, any editor can remove it. WhatamIdoing (talk) 04:08, 27 February 2012 (UTC)
Not only that user; also those at WP:DYK. See Template:Did you know nominations/Sam and Diane. --George Ho (talk) 04:20, 27 February 2012 (UTC)
I am happy they did. Seriously, compare [2] to [3]. You are free to use any referencing format you want, but other editors are also free to change it if they think it improves the article. Yoenit (talk) 09:50, 27 February 2012 (UTC)
Not exactly. Exactly like you can't convert from British to American spelling "if you think it improves the article", you can't unilaterally convert citation styles from the authors' choice to your preference. The rules are outlined at WP:CITEVAR. WhatamIdoing (talk) 16:30, 27 February 2012 (UTC)
That's not what CITEVAR says. Read it again. "Editors may choose any option they want", and it is "considered helpful" to seek consensus before changing the citation style. CITEVAR is not policy. It's possibly questionable as a guideline. The controling policy is WP:CONSENSUS. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 15:47, 2 March 2012 (UTC)
The last thing we need is yet another citation style. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 15:47, 2 March 2012 (UTC)

New WikiPedia Desktop and Mobile UI Designs

[Grande on MediaWiki] - This page contain the designs in Detail. — Preceding unsigned comment added by 106.67.27.98 (talk) 03:48, 2 March 2012 (UTC)

  • Sorry, but oppose for now per WP:NOTSOCIAL. Remove the "article notes" and "reviews" (first screenshot), since we're on the way to a visual editor. Even still, I don't know if the Wikimedia Foundation has the server resources to implement it.Jasper Deng (talk) 04:02, 2 March 2012 (UTC)
This is not WMF sponsored. These designs are done by a volunteer as suggestions; they are not currently anywhere in the plan. You may safely ignore this or delete this entire section.--Jorm (WMF) (talk) 04:16, 2 March 2012 (UTC)

Getting people to pay more attention to talk pages

This is only a suggestion, and arguably, it might have been better in Wikipedia:Village_pump_(idea_lab),but I guess that more people look at this page of Wikipedia. My proposal is as follows. It is sometimes said that people will get more out of Wikipedia if they did not merely read the article, but the talk pages (indeed, I am sure I once read a magazine which said that). Can we therefore have a template at the top of at least some articles, encouraging readers to read the talk pages of articles? ACEOREVIVED (talk) 20:35, 28 February 2012 (UTC)

Oppose. Talk pages are for discussing improvements to the article. If we did this then some talk pages would be considered quasi-articles by many readers – and by some editors who would start speculating in spreading their crap on talk pages when it's kept out of articles. All sorts of unverifiable nonsense and rude discussions are already on talk pages. If people want to learn more about the subject than the article and they aren't studying Wikipedia culture then they are better off searching elsewhere on the Internet. Talk pages are also treated less strictly than articles concerning legal issues like BLP violations and copyvios - especially when it's discussed whether something in the article is exactly that. We shouldn't give the impression that we want readers to read talk pages. They are for editors. PrimeHunter (talk) 00:02, 29 February 2012 (UTC)
I'm inclined to agree with PrimeHunter. I will note, however, that many of the article cleanup templates that flag content disputes or biased articles (e.g. {{POV}}) already link to a given article's talk page. While these template messages are principally aimed at editors, other readers are certainly able to discern the presence of a dispute and view any related discussion. TenOfAllTrades(talk) 00:26, 29 February 2012 (UTC)
  • Its just more clutter theres a tab at the top of the page already for the talk page, adding a template at the top is just going to detract from a persons ability to read the article Gnangarra 01:50, 29 February 2012 (UTC)
  • Oppose: Yes, readers should read more deeply. I meet people and brag about being a Wikipedia editor, one of millions, and tell them it's one of those iceberg things, 90% underwater. I advise them to use the tabs at the top of the page, and the "About Wikipedia" on the left edge, and the "Help" also on the left, all of which lead them to read the highly informative underwater parts. It's all there; just have to point, click and read though perhaps "Help" ought to be made more immediately helpful to readers and less focused on editors. Jim.henderson (talk) 19:31, 29 February 2012 (UTC)
Support - if we encourage users to actually go on talk pages, there would be a more social and collaborative aspect to the encyclopedia. By encouraging people to use the talk pages, we encourage new WikiProjects to actively improve a certain subject on Wikipedia, and improve the existing and mostly moribund ones. This will also aid in editor retention (our number 1 priority now), as it will allow a forum for discussion of articles. I understand that Wikipedia is not a forum or message board, but discussion on articles does contribute to their quality. Wer900 (talk) 03:36, 6 March 2012 (UTC)

Many thanks to all the people who responded to this proposal. The comments in response are well taken. I should also say that I was very impressed with how polite and civil people who responded to this discussion were, even if the general consensus appeared to be oppose the original proposal. It goes without saying that that is exactly the good manners that, one hopes, will characterise Wikipedia discussions. ACEOREVIVED (talk) 21:12, 29 February 2012 (UTC)

What I wouldn't mind seeing is a count on the 'Talk' tab of the number of recent discussion sections added or updated. (For example: '| Talk (2 updates) |'.) That way I can tell at a glance whether discussions are taking place. Regards, RJH (talk) 23:17, 29 February 2012 (UTC)
RJH's idea sounds interesting, but I would think like the above proposal, it doesn't totally jive with WP as an encyclopedia. All of the behind-the-scenes work should be accessible, but probably shouldn't be to prominent. Aslbsl (talk) 14:17, 1 March 2012 (UTC)

Make it possible to have several watchlists

It would be really helpful to be able to create several separate watchlists. I watch pages where my interest is the article itself but I also often watch pages where I only do wikignoming and only need to check whether someone else undoes those edits. It would be cool to be able to maintain separate watchlists for those two types of pages. Therefore I propose to give all editors the ability to maintain more than one watchlist. Toshio Yamaguchi (talk) 19:58, 1 March 2012 (UTC)

I had a similar idea, but I did not mention it outside my talk page (User talk:Wavelength/Archive 1#Watchlist folders).
—Wavelength (talk) 20:11, 1 March 2012 (UTC)
Try Special:RecentChangesLinked - it lists changes to any page linked to from a given page. You populate a page with the pages you want to watchlist, and tada you're done. Josh Parris 20:15, 1 March 2012 (UTC)
I am not sure this works for me. What I need would be the following watchlist categories:
  • Articles I am interested in
  • Village pumps and help desk
  • Specific policy pages
  • User talk pages
  • Pages where I perform NFCC enforcement
This is only a rough outline to get an idea of what I have in mind. Additional options for "fine tuning" your watchlist might be desirable. Toshio Yamaguchi (talk) 20:37, 1 March 2012 (UTC)
See Wikipedia:Help desk/Archives/2010 October 30#Multiple personal watchlists.
—Wavelength (talk) 21:02, 1 March 2012 (UTC)
Try User:UncleDouggie/smart watchlist.js. --Yair rand (talk) 22:13, 1 March 2012 (UTC)
This one is excellent, been using it since quite some time.. but it saves its settings to your browser, so you won't have the same settings on another computer. Some thing like this should be rolled out in general instead. There was also a consensus for recent watchlist changes... what ever happened to that? --lTopGunl (talk) 11:50, 4 March 2012 (UTC)

Categories for discussion nomination of Category:Eponymous categories

Category:Eponymous categories and all other cats beginning with "Category:Categories named after" , have been nominated for being turned into hidden categories. On the Categories for Discussion page there has been a debate about the appropriate venue for this discussion so I am linking it here to try and establish a censensus on venue. If you would like to participate in the discussion, you are invited to add your comments at these categories' entry on the Categories for discussion page. Thank you. RevelationDirect (talk) 04:48, 4 March 2012 (UTC)

Note there is a complementary request to rename such categories to "Category:Wikipedia categories named after...". SFB 17:29, 4 March 2012 (UTC)

Citation Style templates- centralizing talk pages

See Help talk:Citation Style 1#Centralized talk page.

A week ago, I made a proposal to centralize the talk pages of the Citation Style 1 templates, making an announcement on all 25 talk pages. The response has been minimal, which rather proves my point that these pages are underwatched. Since these templates are so well-used, I thought it best to open this to a broader audience. ---— Gadget850 (Ed) talk 14:02, 4 March 2012 (UTC)

Go be bold, imo. --Izno (talk) 14:17, 4 March 2012 (UTC)

Maintenance Category Reorganization

The maintenance categories on Wikipedia are poorly organized, and as a result, users are turned off by the massive walls of text which link to them. Category:Wikipedia maintenance categories sorted by month says it all. This is especially damaging to the base of new editors, which will be at best confused and will not be able to target their efforts on where the encyclopedia requires the most work, and at worst will be turned off by the large number of categories and simply become inactive or leave, feeling that there is no way they can help. For anyone, the place is visually unappealing in addition, and difficult to navigate. It is for this reason that I propose organizing the numerous categories into various categories superior to them but inferior to the category of all articles requiring maintenance, which shall give the general area of what must be done with these articles:

  • Cleanup and Grammar - this should deal with various aspects such as the prose of the pages, its grammar and spelling, the formatting of its contents, whether they use neologisms, etc.
  • Accuracy - this category should specifically deal with pages which have accuracy issues, or have some issue with regard to the style and placement of their references.
  • Comprehensiveness - self-explanatory. This category should deal with pages which have issues in the amount of content they have, if articles are stubs, and whether the article explains in depth and with many examples the topic that it covers. This section will also deal with whether lists comprehensively cover what they are supposed to and have basic properties of all of their subjects
  • Suitability for Inclusion - this includes articles that are cruft of any kind, non-encyclopedic, example farms, promotional, tl;dr self-shrines, libelous, etc.

In addition, within these categories, the dates they are sorted by should also be subcategorized by year, again so that new users are more invited to edit them and navigation is easier generally. I am not proposing the demolition of any existing category, merely that they be moved into the appropriate supercategory listed above so that the page is more elegant and easier to navigate for new users and old alike. Nothing else will change with regard to the categorical structure.

Also, in order to ensure that the backlog of bad articles is eliminated in the quickest fashion possible, a link should be placed to the maintenance categories sorted by month in a prominent place, perhaps on the left sidebar, or to the left of the "feedback about editing" link. This will ensure that a larger percentage of new and experienced editors alike notice the existence of a backlog, and that more resources will consequently be available to the related WikiProjects to help clear up this backlog, as opposed to merely a small dedicated group (though this group is not in any way harmful, just too small to clear up the backlog without serious firepower). That way, more editors will feel a purpose of being on Wikipedia, more new editors will be retained, and the community can grow back.

Wer900 (talk) 23:56, 5 March 2012 (UTC)

The new, redundant automatic edit summary on page moves should be reverted

Apparently as of about March 1, 2012, the automatic edit summary on page moves became the stunningly redundant "User name (without the user: prefix) moved page X to page Y". In an article's edit history what is thus seen is a person linked username, followed by their name again, listed as making the move. Here's a screenshot from the article history of a move I made last night to illustrate:

When looking at a person's contributions, or your own watchlist, a person's username is not linked and listed, but since you're looking at that person's contributions or your own watchlist, you know whose contributions you're looking at, so it's just as redundant to see this edit summary. I also imagine this now shortens the number of characters one can add to a page move summary in the Reason: field, which was already pretty short because of the automatic move text (a person with a long name might find any reason they add just gets swallowed when they save because of the character limit). I have no idea where this change was discussed at all, or what would need to be done to change it back but I'm sure responders will illuminate me.--Fuhghettaboutit (talk) 13:04, 6 March 2012 (UTC)

  • Thanks for providing this information. I have voted and apparently a developer has been "assigned" the bug (I assume that means the fix has been greenlighted and put in a queue for that person to take care of?)--Fuhghettaboutit (talk) 15:37, 7 March 2012 (UTC)
  • Support, I have voted there as well, and left some comments for the very defensive (and incorrect) developer. Let's hope they leave their rather entrenched position and actually listen to what we are suggesting, or that they at least provide some good examples of where this change is beneficial. Fram (talk) 09:52, 9 March 2012 (UTC)
  • Support the removal of this redundancy. ItsZippy (talk • contributions) 19:44, 9 March 2012 (UTC)
  • Support overly redundant, and there was no consensus for the change in the first place. While we are at it, the two periods around the page size should also be removed. For example
    00:00, March 9, 2012 Alpha Quadrant (talk · contribs) . . 2,000 bytes (+200) . . (Edit summary) would take up much less space as
    00:00, March 9, 2012 Alpha Quadrant (talk · contribs) 2,000 bytes (+200) (Edit summary). I have no idea why the devs added the extra periods, but I can't thing of any reason for having those four extra periods on either side of the page size count. It just takes up extra page space. Alpha_Quadrant (talk) 19:50, 9 March 2012 (UTC)
No, they add some much needed breathing room. We don't need to design for 640x480 anymore. - ʄɭoʏɗiaɲ τ ¢ 20:09, 9 March 2012 (UTC)

Request for comment: Adoption of new unblock appeals tool

Hello, all; an RFC has been opened at Wikipedia_talk:Guide_to_appealing_blocks#Adoption_of_new_unblock_appeals_tool to seek input regarding the implementation of the Unblock Ticket Request System as a replacement for the unblock-en-l@lists.wikimedia.org mailing list. Comments from all users, especially those who have experience in reviewing blocks, would be greatly appreciated. Hersfold non-admin(t/a/c) 21:13, 6 March 2012 (UTC)

Village pump official irc channel

Hello

can we create an official irc channel to discuss the proposals each other ?

I think it's useful. What do you think ? --Tegra3 (talk) 12:13, 7 March 2012 (UTC)

With the creation of any new IRC channel there is the danger it will remain underpopulated and die due to lack of interest. I think it's better to discuss proposals in existing channels like #wikipedia-en. Dcoetzee 22:21, 8 March 2012 (UTC)

General discussion of occupational categorization

Please Wikipedia talk:Categories for discussion#On the categorization of biographies by (perhaps) incidental occupation. Mangoe (talk) 19:56, 7 March 2012 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
The obvious consensus here is to add a contributions link for anon IP editors to the interface. Looking through the comments on the RfC, it would be reasonable to say that it should be logically named, and not say "My contributions" but something to indicate there could be more than one editor on that IP. -- DQ (ʞlɐʇ) 01:47, 20 April 2012 (UTC)
The Buzilla request was filed at bugzilla:36121. Cunard (talk) 19:23, 21 June 2012 (UTC)

There should be a "my contributions" link visible somewhere to anonymous IP editors, like there is for registered users. It should probably be called "contributions from this IP" or something similar, though, because the contributions may not be those of the current user of the address.

It has always bothered me that I have to jump through some hoops to see the contributions from this address, either by going to Special:Contributions and then having to figure out the IP address to type in, or to look at the history of an article I know I've edited, find one of my edits, and click on my address to see the contribution history. If there's an easier way, I don't know what it is. 66.159.220.134 (talk) 21:54, 15 February 2012 (UTC)

If you want to see your own contributions quickly, just use Special:MyContributions. Due to dynamic IP-addresses, I'm not sure how useful the link would be. --He to Hecuba (talk) 22:13, 15 February 2012 (UTC)
Thanks. In that case, I amend this suggestion to ask that Special:MyContributions appear on the list at Special:SpecialPages. Currently it doesn't.
Some IP addresses are static, and some dynamic ones persist with the same customer for months, depending on the ISP. Such is the case with me. It wouldn't be useful for AOL users, who get a different address on each HTTP request. 66.159.220.134 (talk) 22:41, 15 February 2012 (UTC)
For an easier way to see your contributions, simply click edit on any unprotected Wikipedia page, type four tildes (~~~~), which can be done automatically using the edit pane button, click on show preview, and then click your linked IP address.--Fuhghettaboutit (talk) 13:26, 16 February 2012 (UTC)
  • Strongest possible oppose: there is already a mechanism for watching one's contributions: create an account. The my contributions thing is guaranteed to be abused by bad-faith dynamic IP users, who would only add select contributions to their lists and then pretend that this is all they did. — Dmitrij D. Czarkoff (talk) 13:53, 16 February 2012 (UTC)
    • What would stop them from doing this right now, consider several easy workarounds are available? Why would they suddenly start doing so with this change? Yoenit (talk) 14:14, 16 February 2012 (UTC)
    • Thanks Czarkoff, I have rarely seen a more blatant example of disregarding WP:AGF. There is NO requirement to create an account on Wikipedia to participate here.

      Going to a page and typing four tildes to see my IP address, or hunting for one of my contributions in an article history, or looking up my own IP address to type it into Special:Contributions, are all unnecessary hoops to jump through.

      There is no valid reason I can see to make the anonymous IP experience deliberately more difficult. Anons don't get a watchlist, and that makes sense from a technical standpoint. However, an anon who wants to perform maintenance to some articles should have a way to see past articles of involvement. Special:MyContributions is the way to do that, but currently there is NO way for that link to be found. All I'm asking is that Special:MyContributions appear on the big list of other special pages at Special:SpecialPages, which is supposed to be a comprehensive list. 66.159.220.134 (talk) 15:06, 16 February 2012 (UTC)

      • Er, I'm not following. Yes, there's no requirement to EDIT Wikipedia, and there never will be. But people ARE "strongly encouraged" to get an account. I'm not opposed per se to making it easier for IPs to see their contributions, but to say that "There is no valid reason I can see to make the anonymous IP experience deliberately more difficult" is silly. There's a VERY valid reason -- the whole POINT of making an account is to make things easier, on everyone. You might have a static IP but for even so it's not your account. If you ever move, you'll change your IP and someone else will potentially use it. It's not "you" any more. Not to mention editing from elsewhere. So yes, if you want an easy way to find all your contribs, register an account. If you refuse, well there's other ways of keeping track what pages you edited -- your broswer's bookmarks for instance. ♫ Melodia Chaconne ♫ (talk) 16:51, 16 February 2012 (UTC)
      • Your reading of WP:AGF is plain wrong: nobody is supposed to assume the good faith of each and every human being. This policy is the editing policy, it is applicable on individual talk pages. Still, anonymous IP edits are not difficult at all, and there was a good way provided to facilitate tuning of the editors' experience: registering the account. You are not obliged to state your personal details if you don't want to, but re-inventing accounts just to save the ability to indicate your IP instead of random word just doesn't make sense at all. — Dmitrij D. Czarkoff (talk) 11:03, 19 February 2012 (UTC)

I have the Firefox search pulldown set to Wikipedia and generally just type "special:my" into it, so it auto-finds MyTalk and MyContributions, and that's how I usually get to my contributions page. Browsers also have a feature called "bookmarks", so overall I think the proposed new feature is of minor benefit as best. 67.117.145.9 (talk) 21:40, 18 February 2012 (UTC)

  • Oppopse: This would remove a big reason to create an account and could be as a tool for sockpuppetry: just hop to a new IP and there's all the articles edited by the last one. Best, Markvs88 (talk) 14:53, 19 February 2012 (UTC)
Yes, it is a reason to create an account, but it is technically possible to add an IP editor as well. With that said, the second part of your comment is plain wrong. IP editors already have a Special:Contributions page, it is just hard to find because it isn't in a prominent location. Sockpuppets already know the process, and they know how to get to IP contribution pages. Alpha_Quadrant (talk) 19:55, 19 February 2012 (UTC)
Well, some socks already know the process. I get where you're coming from, but I still feel there's no reason to make it easier. Best, Markvs88 (talk) 12:35, 20 February 2012 (UTC)
There aren't any serial sockpuppeteers that don't know how to get to a contributions page. This change will only make it easier for IP editors to find out what edits came from their IP. How on earth is that a bad thing. The page is already generated, it can't be abused, so what is the problem here? Alpha_Quadrant (talk) 15:39, 20 February 2012 (UTC)
  • Support it is quite sensible to have a tab for IPs to see their contributions. Although they don't have an account, they may want to check back on a page they previously edited. Before creating an account, I edited as an IP, and it was very annoying trying to check back on edits I previously made. There is no requirement whatsoever for users to create accounts. Providing a link to an IP's contributions page would be extremely beneficial for IP editors. Alpha_Quadrant (talk) 19:55, 19 February 2012 (UTC)
  • Support - None of the oppose rationales seem to make sense. Yes, it would be possible for an IP user to abuse this feature, but that is already possible. If a committed vandal or sock-puppeteer is going to abuse the fact that they can see their IP's contributions, they will do so regardless of whether there is an easy link for them to use. Preventing such a link will not deter those who actually want to abuse it. Despite what people have said, there is not requirement to create an account; users only encouraged to create an account insofar as some pages describe the benefits. Nowhere does it say that IP users ought to create an account, just that they can and that there are benefits to it. IPs are human too expresses most of my feelings nicely. ItsZippy (talk • contributions) 20:28, 19 February 2012 (UTC)
  • Oppose per Wikipedia:Role accounts. Where is the page showing the Foundation supports such a feature?.Switched to Conditional support below. Toshio Yamaguchi (talk) 09:22, 20 February 2012 (UTC)
This oppose doesn't make any sense. IP editors are not role accounts. Alpha_Quadrant (talk) 15:37, 20 February 2012 (UTC)
Strictly speaking they are not. Yet no editor owns a specific IP address and there is nothing prohibiting another user from making edits under the same IP (see WP:SHARE). Furthermore anyone wishing to have the benefit of having all their contributions shown in one place should simply register an account. I don't see the net benefit of this proposal. Toshio Yamaguchi (talk) 16:00, 20 February 2012 (UTC)
IP editors are already capable of editing. They already have a contributions page. This proposal is about making it easier for IP editors to actually find their contributions page. Presently, they have to figure out what their IP address is, visit Special:Contributions, and enter their IP. Either that, or they have to edit a page and use the contributions link on the history tab. There are many, many IP editors that are more active than some logged in users. For example, User:220.101.28.25, an IP editor has almost 12,000 edit. Account registration isn't required. It is an option open to allow IP editors extra tools (i.e. rollback, adminship, scripts, edit protected pages, etc.). What is the harm in adding a link to their contributions page in the top right corner near the login button. The page already exists, so how can a simple link be abused. All it will do is make it easier for IPs to find their contributions page. Alpha_Quadrant (talk) 16:10, 20 February 2012 (UTC)
You say "Account registration isn't required.", but neither is editing under an IP. It seems reasonable to me to require anyone wishing to have the benefits of an account to register an account. Toshio Yamaguchi (talk) 16:22, 20 February 2012 (UTC)
  • Conditional support under the caveat that it is called All contributions from this IP or something similar and with a note saying something like This is the contribution page listing the edits performed from this IP address. Please note that the edits might be attributable to several distinct individuals. Toshio Yamaguchi (talk) 21:42, 21 February 2012 (UTC)
  • Support per Alpha Quadrant. None of the opposes make sense to me, how can one abuse a Special:Contributions page? It's a page no one has control over and it already exists since it is dynamically generated; linking it would be useful for many unregistered contributors just like it is useful for registered contributors. CharlieEchoTango (contact) 09:30, 20 February 2012 (UTC)
  • Support I can't give a better rationale than CharlieEchoTango or Alpha Quadrant, so this support is per their comments. I too, fail to understand what "abuse" this virtual, dynamic list of contributions is likely to cause. There are many very productive IP editors to whom this would be a boon, and I can't see any reason to deny them what appears to be merely a convenience link to a page that already exists, unless there are technical issues. Begoon talk 04:23, 21 February 2012 (UTC)
  • Support I revert a lot of vandalism, and a lot of this is from unregistered IPs (and lets drop the "anon" part - IPs make more identity visible than disposable accounts). I would find it enormously useful to have this link, and having it would allow me one-click access to a page that I need to read, rather than the current hoopla through intermediate pages to find it. In fact I needed this so much that I wrote some JavaScript to provide it as a hack, just for myself (this is only a hack - I'm not going to release or maintain it). Andy Dingley (talk) 10:42, 7 March 2012 (UTC)
    • As an IP address contributor, I support this idea. Perhaps, on the side toolbox instead, "User contributions", rather than uptop and an obstruction to non-contributive IPs. 184.146.126.165 (talk) 01:42, 8 March 2012 (UTC)
  • Support. I often edit via IP when on public PCs and I must agree, this can be quite helpful by easing the way to keep track of what's done. At the same time, for those who have occasional cashe issues like myself; it would help to keep track of what edits have accidentally been saved as IP, when you get automatically signed off. All these are little issues, but would overall increase the editing experience. I don't suggest placing those links where the signed-in user's links are (that would confuse a lot of folks), but instead in one of those dropdowns, or a new one all together. Rehman 08:59, 8 March 2012 (UTC)
  • Support: I'm not what idea is better. If the tab idea is a non-starter, the placing of it on Special:SpecialPages (where it would be accessible to all users, not specifically us IPs.) would be useful. 72.137.97.65 (talk) 19:36, 12 March 2012 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Persondata backlog done by bot

Roaming around Wikipedia, I found Wikipedia's biggest backlog. Category:Persondata templates without short description parameter has 620,000 pages in need of a description parameter. Basically what this is, for those who are new to this category, is a few words that summarizes what a person did for a living for statistical purposes. Now, the few words, like "rock musician" for example, can be predicted through a number of ways. One example is by infobox. An article can only have one infobox, obviously. So, that infobox would describe the thing the person was most famous for. An idea that 1ForTheMoney developed in the idea lab was that a bot lists articles with infoboxes and missing short description. Then, the bot suggests a short description and all an editor has to do is to click an "okay" button which would trigger the bot to ammend the persondata. Other ideas thrown around at the idea lab were using stubs, titles, WikiProjects, and categories.
Vote below with Support or Oppose or suggest using something instead of infoboxes. Thank you, BCS (Talk) 02:45, 24 February 2012 (UTC)

I would suggest starting with the big win categories, Actors, Athletes, politicians and military persons. Depending on how detailed you want the description (can you say American politician or does it need to be Arizona governor) could depend on how easy or difficult the logic need be. Frankly I don't think it would be that hard to kock them out and it should be rather easy to write a script that could be done by a bot. --Kumioko (talk) 20:01, 24 February 2012 (UTC)
Both examples would be okay according WP:DATA. I like your idea. Would you like to volunteer to program the bot? Or will you leave soon? (I saw your userpage) BCS (Talk) 21:03, 24 February 2012 (UTC)
Sorry I'm not really interested in doing any bot work. There are plenty of other folks that can do that though if you take it to the Bot requests page someone may volunteer to do it. --Kumioko (talk) 00:14, 25 February 2012 (UTC)
Here is a small snip-it of AWB code that will add Footballer if the SHORT DESCRIPTION field is blank. This will probably be all you need if you are getting a list of articles based off of a category. I agree with Kumioko, that the big ones should be knocked out first and sportspeople is the #1 big one. I could run this as a bot or if somebody else wants to have some fun, go for it.Bgwhite (talk) 01:15, 25 February 2012 (UTC)
If you have the code ready, then by all means use it. Knock a big one out. WikiProject Football has 37,000 articles missing the short description. Infobox footballer could be a football player or manager if you use that, by the way. So, sometimes a manager who has never played football will have Infobox footballer. @Kumioko It's okay, I wasn't forcing you to make a bot. BCS (Talk) 04:15, 25 February 2012 (UTC)
I would do it by category and not infobox. I can do those that have both footballer and manager categories and then do just the individual categories. The same procedure can then be done for other sports. I think things would be more complicated for politicians, arts and the other groups. Bgwhite (talk) 05:41, 25 February 2012 (UTC)
Sounds good to me. BCS (Talk) 16:25, 25 February 2012 (UTC)
  • BCS refers to my idea of adding descriptions based on infoboxes/categories/project banners, and requesting human confirmation (using Madman's idea on the Toolserver or somewhere else) on the ones it doesn't like. Though I was just jotting ideas down at the time, it was made to address the problem of articles with no defining features, and those with multiple infoboxes. (In fact I remember participating in a similar thing with interlanguage links a few year ago, where editors compared articles in different languages and pressed a button to say if the articles were about the same subject or not. If enough people agreed a bot automatically added the links, and if they disagreed that pairing was taken off the database.) 1ForTheMoney (talk) 00:05, 25 February 2012 (UTC)
FYI. Rcsprinter (orate) (Contribs)
(Not Rcs) 20:50, 26 February 2012 (UTC)
German wiki is the only other wiki to use persondata. Persondata actually started there. How do you steal German language words to put in the short description parameter? Bgwhite (talk) 21:13, 29 February 2012 (UTC)
  • Two bot tasks have had BRFAs raised, and they look likely to fail due to unacceptable error rates. I now believe that crowdsourcing is the only viable solution, and encourage development in that area. Josh Parris 11:06, 29 February 2012 (UTC)
Yeah, they shot it down because any bot would produce an error, therefore a bot can't work on it. It sounded like they didn't even like "normal" people working on it because of the errors a normal human would produce. As the number of articles missing the description parameter has gone up every year since persondata was started, this categroy will never be empty. Bgwhite (talk) 21:13, 29 February 2012 (UTC)
That's a reasonable summation. A crowdsourced solution ought to address both problems, by waiting until enough humans agree on what the short description ought to be. I think someone pointed out earlier that the backlog was getting smaller, but I haven't sighted any data one way or the other. Josh Parris 02:27, 1 March 2012 (UTC)
I feel compelled to point out that a crowdsourced solution might seem like a good idea in theory but in reality Wikipedia is the modal of crowdsourcing and these entries have been empty for years (and apparently will be empty for years to come) so if you have a good idea then please present it. You are both very good programmers so I imagine you both have some really good ideas about how to solve this problem other than writing it off to crowdsourcing that you know won't work. 71.163.243.232 (talk) 04:41, 1 March 2012 (UTC)
@Josh: That would be me. I keep a record of the number of templates missing descriptions that I update once a week, though I admit it's more for my own purposes than anything else. And no, I don't think that bots are the best answer to this one - slightly ironically, persondata was made so that biographies could be made accessible to machines, and bots are in fact the cause of this backlog thanks to mass automated additions that should have been reined in before they started. At the moment, the best move is for more people to get involved with the backlog - tools such as Persondata-o-matic allow for semi-automatic additions but with human intervention. 1ForTheMoney (talk) 15:17, 1 March 2012 (UTC)

What about this? Could that be replicated? -- BCS (t · c · !) 19:06, 3 March 2012 (UTC)

I have done some work on this, and it is not that hard. However using cats as is being done now is not that great an idea. The reason is that the categories are as readily available as the short description parameter, so that not only is no information added, but the ease-of-use gain is negligible. Rich Farmbrough, 20:31, 12 March 2012 (UTC).

Special:EditCount

I've come up with a idea: Why not create a special page called Special:EditCount? I agree that luxo's, X!'s, tparis's ; etc are not bad, but when replication lag is high, problems occur. There is a sample here. It is used in Wikia, also run by MediaWiki, so it's technically possible. There is a consensus for creating this at TestWiki. Dipankan Meet me here! 14:44, 3 March 2012 (UTC)

  • That consensus is on another website. Historically, the consensus at en.wiki has been that too much attention to one's number of edits may lead to editcountitis, the symptoms of which make for a very unhappy editing environment. — Huntster (t @ c) 05:49, 4 March 2012 (UTC)
  • What would be the benefit of letting everyone see everyone else's edit counts so easily? This should stay in preferences where it is not being broadcast. ▫ JohnnyMrNinja 06:07, 4 March 2012 (UTC)
  • The example that you linked to uses the Editcount extension. I agree with Huntster, though, that in order to enable it here you would need to show a good reason and how it would be used to improve the encyclopedia, to overcome the concerns described. Incidentally, if you want to see Users' edit counts while browsing talk and contribution pages, Navigation Popups includes that functionality (using the API) when you hover a user name. Begoon talk 06:10, 4 March 2012 (UTC)
  • OK. I have developed my own script which adds a Edit Count link in your personal toolbar. That is of X!'s, but that will help. Dipankan Meet me here! 09:39, 4 March 2012 (UTC)
    I'm sure that may be useful for some people, thanks for sharing it. You can list scripts like that which you've created at WikiProject User scripts, to make them easier for other users to find. There are already a couple listed there which do something similar, like User tabs. As I mentioned, the API result from WP:NAVPOP is enough for me. Begoon talk 09:43, 4 March 2012 (UTC)
Thanks for giving the feedback. I will continue to develop simple tools using JavaScript when I get time...! Dipankan says.. ("Edit count do not matter") 05:13, 6 March 2012 (UTC)

People who have contributed to this discussion may be interested in the Wikipedia article Wikipedia: Editcountitis, although since I just saw a quote "Edit count (sic) do not matter" perhaps some of them will not! ACEOREVIVED (talk) 22:17, 8 March 2012 (UTC)

Comment I've always thought it doesn't make any sense why our edit count is under "my preferences" instead of "my contributions". Jason Quinn (talk) 04:15, 9 March 2012 (UTC)

It is under "my contributions". If you click on "My contributions", you can go to "Edit count" at the bottom of the screen. ACEOREVIVED (talk) 08:44, 9 March 2012 (UTC)

I was wondering if it is possible to have an EdiCount that has, as an additional argumen,t a minimum contribution size (eg. 1000 bytes) , either fixed or entered by the user. I know editcountitis is spread among some of the top contributors and that all contributions and contributors matter, however it is be good to recognize who the top contributors are. But, in my opinion, we shall not recognize ones that have thousand of contributions only adding lines between paragraphs, brackets in dates and adding unnecessary categories. Perhaps some filter (eg. contribution size) would help. Lgtrapp (talk) 18:31, 11 March 2012 (UTC)

Adding another disclaimer page about Accessibility

In Wikipedia talk:General disclaimer#For or not for dyslexic and blind people?, I requested an addition about dyslexic and blind people. However, the user suggested that adding a disclaimer about people with difficult accessibility is too good for WP:General disclaimer. There is already WP:WikiProject Accessibility, but it is not itself a disclaimer, I'm afraid. I don't know if WP:NOT addresses accessibility for handicapped people. Should there be another Disclaimer page about Accessibility for people with difficult diagnosis, such as deafness, blindness, dyslexia, and other diagnosis? --George Ho (talk) 02:01, 7 March 2012 (UTC)

I think you misunderstood what I was suggesting. I didn't mean another disclaimer page, because I don't think this is something to be "disclaimed" rather something along the lines of a page with advice on using Wikipedia for the differently-abled, much like Microsoft Windows has an accessibility section with things such as page zoom and speech etc--Jac16888 Talk 02:06, 7 March 2012 (UTC)
Shortcomings in the medium are not things to be disclaimed. Note how no other site has disclaimers for these. --Cybercobra (talk) 07:02, 7 March 2012 (UTC)
Sometimes government organizations have to put in some sort of disclaimer where they have not been able to cater properly for people with a disability because of requirements on them to deal with such problems. However the only requirement on Wikipedia is a moral one so no disclaimer is needed just an effort to deal with such problems. Dmcq (talk) 11:48, 7 March 2012 (UTC)
Can you elaborate a "moral one", please? --George Ho (talk) 12:15, 7 March 2012 (UTC)
As in the very first definition in athe first dictionary I googled 'of, pertaining to, or concerned with the principles or rules ofright conduct or the distinction between right and wrong;ethical: moral attitudes.' Dmcq (talk) 12:38, 7 March 2012 (UTC)
As a totally blind person (who happens to have Wikipedia:General disclaimer on their watchlist), I don't understand why a new disclaimer page is needed at all. It'd be very difficult to write a page about using Wikipedia for people with disabilities because users' needs vary enormously. The closest we have is Wikipedia:Using JAWS. Graham87 15:49, 7 March 2012 (UTC)
I think that such a statement is beyond the scope of a disclaimer.
Additionally, what Graham says about the variety of disabilities is important. The list of possible statements is nearly endless. In addition to "if you have trouble reading in general, you'll probably have trouble reading Wikipedia" (dyslexia), we could equally well say that if you have trouble clicking (mouse use is painful to some people with carpal tunnel syndrome), then our wiki links will likely be a problem for you; if you are blind, you won't be able to see the images; if you're Deaf, you won't be able to hear our audio files (including the spoken Wikipedia articles); if you have trouble typing, then you will find your ability to edit pages limited; and so forth. Basically, we'd be telling people what they already know and expect, and I'd expect many of them to be insulted by such a patronizing statement (because no matter how you phrase it, telling a person that their reading difficulties don't disappear merely because they are on Wikipedia is fundamentally patronizing).
Finally, telling people that Wikipedia may not work so well for them isn't really a method of solving any actual problems. If you want to make a difference for users with disabilities, then I'd suggest reading WP:ACCESS and figuring out what you personally could do to improve actual access to articles that interest you. WhatamIdoing (talk) 03:15, 13 March 2012 (UTC)
I think that most editors are unaware of the desirability of using language templates to mark up foreign language text embedded in English Wikipedia. LittleBen (talk) 13:49, 11 February 2013 (UTC)

Bot to notify admins of backlogs

We have 1500+ admins (several hundred of which are pretty active), yet we still incur large backlogs, especially at WP:RPP. Does this mean that we should have a bot to notify admins at AN (or, possibly, ANI) about backlogs?Jasper Deng (talk) 02:57, 12 March 2012 (UTC)

The script generally used to archive WP:RFPP will put up an admin backlog notice on that page when the queue reaches 10. An example of the notice may be seen in this version, just below the TOC. EdJohnston (talk) 03:19, 12 March 2012 (UTC)
Yeah, but admins do not see it unless they manually navigate to RPP.Jasper Deng (talk) 03:21, 12 March 2012 (UTC)
  • Many admins will have a dashboard that tells us of backlogs in areas where we are active. Posting on admin noticeboards about all backlogs is liable to be counterproductive, I'd suggest we reserve that for backlogs at AIV and the deletion of attack pages. With RFA broken the number of admins has fallen by more than a quarter since its peak, and will continues to decline, so we will either have to reform RFA or find other ways to do things that we need admins for. ϢereSpielChequers 13:20, 12 March 2012 (UTC)
    • That's what I'm thinking about, AIV, UAA, and RPP only, where backlogs really are backlogs. We don't have enough admins w/ a dashboard.Jasper Deng (talk) 17:41, 12 March 2012 (UTC)
      • Maybe we need some sort of specific alert that admins can opt in to that emails us about urgent backlogs that they particularly cover. ϢereSpielChequers 22:17, 12 March 2012 (UTC)
        • Yeah, but that would defeat the purpose of the idea, which is to canvass more admins to do AIV/RPP/UAA work; therefore, I believe an opt-out would be a better idea if you want it this way, but I'd find it more efficient to just post at AN or ANI since these are very heavily watched.Jasper Deng (talk) 22:22, 12 March 2012 (UTC)
  • With regards to speedy deletion, I recommend installing User:Ais523/catwatch.js and including any of the various cat:csd's you feel like, lets you have a regular steam of csd's on your watchlist, and is handy for other backlogs too like requests for unblock, or edit requests. If enough admins used this script those backlogs would be a lot lower. (Yes this is a blatant plug, but only cos it's so damn useful) --Jac16888 Talk 22:47, 12 March 2012 (UTC)

Exporting table data as CSV file

Just a small suggestion for added utility on pages containing table structured data.


The short version: Data contained in table format should have an option of exporting in various formats such as: CSV, XLS, XLSX, Tab Delimited, etc... This would allow for a quick way to manipulate and/or translate the data and the respective format of that data.

+++++++++++++++++++++++++++

The longer version/explanation and example use case: I'm a programmer working on a project that requires the storage of SMS/MMS gateways in order to formulate cell phone "email" addresses depending on the carrier the program is sending messages to.

I found the data I was looking for on this "List of SMS gateways" page on your site. The relevant data is contained in an ordered table on this page, but there is no way to export that data in a structured way. The print/export link in the margin of the website allows for PDF exports, but to extract data from a PDF file programatically requires a separate layer of case-specific coding that usually isn't worth the time invested.

My workaround was to use Microsoft Excel's Web Query feature in order to obtain this data in a structured way so that it can be easily manipulated and exported for various purposes.

In my specific case, the table data found on the list of SMS/MMS gateways page needed to be translated into a format compatible for importing into a database table. If the tables on Wikipedia had the option to export the data in various formats, I feel that many people would benefit from this utility.

+++++++++++++++++++++++++++

I imagine there might already be an API available for accessing & obtaining information from Wikipedia. If this is the case, my suggestion shouldn't be ignored completely, because using an API to obtain information requires special knowledge that I presume most visitors of this site do not possess. On the other hand, if my suggestion can be implemented, it would allow for a wider audience to participate in bulk data exports of table data.

Also, if by any small chance, there isn't an API established for Wikipedia yet, you should really look into developing one!

++++++++++++++++++++++++++++

Thanks for your time reading this... and thanks for providing an excellent means of providing and sharing knowledge to the general public. — Preceding unsigned comment added by CheeseConQueso (talk • contribs)

Of course there's an API. It's available at <http://en.wiki.x.io/w/api.php>. :-)
This is a very good feature request. I completely agree that having a little widget next to every table allowing easy export would be great. You should file a bug at Bugzilla. (Or I will shortly.) --MZMcBride (talk) 19:06, 10 March 2012 (UTC)
Why not just copy the table data and paste it into MS Excel or any other spreadsheet, then save it in whatever format you want? That's worked for the last decade... Franamax (talk) 19:34, 10 March 2012 (UTC)
"That's how we've always done it" isn't exactly a reason to ignore innovation, though. And this sounds like a nifty idea, though it won't see use among the average editor. Having that option could be very useful, though. — The Hand That Feeds You:Bite 18:31, 13 March 2012 (UTC)

Add a gadget to colour redirects green

I've currently got a css code that I use to turn links that are redirects green:

a.mw-redirect { color: #00aa00; }

I think this would be useful to a lot of editors as a gadget. I know there is a user preference to colour links to articles less than a certain size (in bytes), so this would be nice right underneath it. - ʄɭoʏɗiaɲ τ ¢ 19:08, 12 March 2012 (UTC)

I agree. What would even more useful would be to expand redirects into their destination article for their tooltips (not to hijack your proposal, but it seems related). Equazcion (talk) 19:20, 12 Mar 2012 (UTC)
This does seem to happen for me... periodically. Sometimes the tooltip will show the article I will arrive at, other times it will just show the title of the redirect. - ʄɭoʏɗiaɲ τ ¢ 22:18, 12 March 2012 (UTC)
Probably when the link text shows a shortcut but is actually pointing to the full page address. WP:V shows "WP:V", while WP:V shows "Wikipedia:Verifiability". Equazcion (talk) 23:28, 12 Mar 2012 (UTC)
If it's any interest, Wikipedia:Tools/Navigation popups (in preferences > gadgets) will show target articles for redirects, among other things. Shimgray | talk | 22:31, 13 March 2012 (UTC)
User:Anomie/linkclassifier is a very thorough script for colouring links. I find it very useful.-gadfium 21:00, 12 March 2012 (UTC)
I think that may also play a part in making the code I placed above work. - ʄɭoʏɗiaɲ τ ¢ 22:18, 12 March 2012 (UTC)
No, mw-redirect is added by MediaWiki itself (since T14968 was fixed by r30871 in early 2008). Anomie⚔ 00:05, 13 March 2012 (UTC)

Sounds good to me; my css has had green redirects for years and when I'm logged out I find the "regular" blue redirects quite annoying. 28bytes (talk) 23:00, 12 March 2012 (UTC)

Subtle notification of Article Talk page changes

As a user and editor, I would like to be able to easily distinguish whether an articles talk page has been changed since my last visit and or edit to it. Some of us have a lot on our watch list, and the chances of me missing an updated talk page is high. I don't think a big banner with flashing lights is necessary, but something subtle yet noticable, such as bolding the 'talk' button, or changing the font color could be useful. Mr.weedle (talk) 03:30, 11 March 2012 (UTC)

Just above the actual content of the watchlist is a dropbox that says "Namespace". If you select "Talk" from that and click the "Go" button, it will show you only the recent changes to talk pages. Slightly less convenient that having them highlighted amongst all the others, yes, but it should help a little. Keep in mind you'll have to switch back to "all" to get the non-Talk pages to show back up. —Scott5114↗ [EXACT CHANGE ONLY] 06:01, 11 March 2012 (UTC)
You mean like Facebook's little red square? That would be fine to me. Only problem is, there are too many pages to keep track of. --NaBUru38 (talk) 19:13, 13 March 2012 (UTC)
Sort of - Instead of the red notification icon, which is a bit in your face, and not very wikipedia; I think something subtle like a different text colour that is bold, just as a small reminder that something has changed since your last edit or visit Ideas? Mr.weedle (talk) 07:51, 14 March 2012 (UTC)

Keep drafts of edited pages

Having seen some support and encouragement at the idea lab (archive will eventually be either here or here), I'm ready to move the proposal here. Most of the rationale can be seen there. Having read the discussion, I think we could use mw:Extension:Drafts, but I think it's ultimately up to the developers to pick and/or implement a mechanism, especially since it's not clear to me how much testing that extension has had.

For people unwilling to go and read the idea lab post, here's the short version: New users may not understand the "This page is asking you if you want to leave" dialog and they may be just clicking through it. So we should save drafts of edits to prevent the work from being lost. --NYKevin @828, i.e. 18:52, 13 March 2012 (UTC)

I'd love that! Sometimes when I'm at the uni, I get kicked out of the computer room because there's lessons. When hat happens, I must rush to add the template "in progress" and save, or I lose the whole work. With that, I could leave the computer easily and resume the work somewhere else. Thanks! --NaBUru38 (talk) 19:15, 13 March 2012 (UTC)

This is another case where may other people may be little more responsive if you clarfied exactly what you mean by "the proposal". ACEOREVIVED (talk) 14:53, 14 March 2012 (UTC)

The second paragraph describes it, and I also linked to a post with more information. Basically, I want to save drafts of edits in progress when the user leaves the page, rather than just throwing up a dialog box saying "This page is asking you if you want to leave..." since I don't think the average user is likely to understand that dialog. --NYKevin @796, i.e. 18:06, 14 March 2012 (UTC)
I don't see a practical way of doing that. The dialog at least warns them their changes won't be saved, which is better than nothing. — The Hand That Feeds You:Bite 20:40, 14 March 2012 (UTC)
Um, I'm trying to get consensus in order to file a bug requesting that the developers figure something out. For example, they might test and/or install mw:Extension:Drafts. That seems perfectly practical to me. Honestly, I think issues of practicality are for the developers to decide, not us. --NYKevin @011, i.e. 23:15, 14 March 2012 (UTC)

Latest ep of a TV series

My proposal is that at the top of the page of a tv series, such as glee, or family, or house etc, it has one those those italicised sentences that says something like "for the latest episode of _____, which is currently in season _____, see _________." It will save a heck of a lot of time in finding the latest aired episode on a series instead of typing in the name of the series, then scrolling down to click on the latest season article, then scroll down and clock on the latest ep article.--Coin945 (talk) 09:05, 9 March 2012 (UTC)

Those italicised sentences are called Wikipedia:Hatnote but this isn't really what they are for. It would also require frequent updates and often be out of date. And many countries air foreign shows with a delay of weeks or months. I don't support going down this road but if we do then I think it should be a field in Template:Infobox television with both episode name and original air date. PrimeHunter (talk) 15:36, 9 March 2012 (UTC)
What's the view against going down this road? It seems like a logical, helpful thing to do from my perspective...--Coin945 (talk) 10:31, 10 March 2012 (UTC)
Opposing view would be something like... wikipedia is an encyclopedia? --lTopGunl (talk) 12:53, 10 March 2012 (UTC)
.....I've thought about this quite a lot and I've come to the conclusion that we can't actually use that as an excuse anymore. Wikipedia is not an "encyclopedia". It is a hub for all knowledge. When people want to know something, they will always to go Wikipedia - not to Wiktionary, or to Wikinews, or Wikicommons etc. Wikipedia is the be all and end all. That's the same reason why I oppose transwikiing. By all means have a wiktionary article as well, but keep the Wikipedia article as if its not on Wikipedia, it doesn't exist [at least that's the way many people see it]. And it naturally follows that I'm starting to think that just as Urban Dictionary is creating new memes and popular culture that even the media haven't picked up on, maybe it is our job to document them.... screw notability!!! [rant over :P] My point is that people go onto Wikipedia to have easy access to things they find interesting. Yes, the info they get can often be sub-quality, but I for one sure as hell love it when the Wikipedia article is a Simple-English style article that has all the basic facts in simple sentences/paragraphs instead of massive articles that i have to skim through to find what I'm looking for.... and I'm sure for others it's the same. In the same way, making life slightly easier for our readers will be of such great use to them. I don't see how fear of skewing from the "encyclopedic" format is a valid argument. All I am saying is that this might be a very useful little shortcut for people.--Coin945 (talk) 15:31, 10 March 2012 (UTC)
To put it simply: Just because people may use a resource for something doesn't mean that's what the resource is for. ♫ Melodia Chaconne ♫ (talk) 16:40, 10 March 2012 (UTC)
I don't think you'll get much traction for trying to revoke WP:N. I really don't want Wikipedia to become haven for all the fancruft that would allow, as well as minor bands, trivial locations, etc. Just because you can do a thing, it does not follow you should do it. — The Hand That Feeds You:Bite 18:46, 10 March 2012 (UTC)
I wouldn't like that hat, because the user can find that information in better places (like the infobox). Plus, with so many series around here, it would get outdated very easily. --NaBUru38 (talk) 19:11, 13 March 2012 (UTC)


Some thing rather similar to the proposal here happens with some television programmes. Just take a look at the article on University Challenge. It will not be hard to find a reference to "Series 41" (the 2012 series) and a link to the article on that there. Were you propososing that this should go for drama series as well as quiz series? I think it all depends how much attention Wikipedians feel an individual television series deserves in Wikipedia. ACEOREVIVED (talk) 19:49, 15 March 2012 (UTC)

Gentry

I think that the Gentry article needs a major Gallery cleanup. For each country there is a gallery with people that are examples of its gentry. The people from each gallery are completely randomly chosen and this leads to two things:

1)The article becomes ridiculous and

2)Some old computers cannot afford such a large amount of images.--188.4.233.216 (talk) 13:46, 11 March 2012 (UTC)

It is kind of odd, especially given the fact that every section has been split to subarticles. The galleries should either be moved to the subarticles or removed completely.
That said, this isn't the place to bring it up. Talk:Gentry would have been more appropriate. :) --Izno (talk) 16:51, 11 March 2012 (UTC)
No one looks at talk pages. Especially in this talk page there is a proposal that has not been answered sonce March 2010...--188.4.233.216 (talk) 19:02, 11 March 2012 (UTC)
If you're getting no responses at the article's talk page, try Rfc. Per Izno, this isn't the appropriate venue. Thanks. --JayJasper (talk) 19:11, 11 March 2012 (UTC)
You're right anyway - just clean it out. Johnbod (talk) 22:39, 15 March 2012 (UTC)

editing references

Moved from WP:VPP (Policy) because of letter "P" mistake. [4] -DePiep (talk) 10:48, 8 March 2012 (UTC)

I propose to add a link to every cite template, added to the reference content and so to be shown in the reference section. The link shows "[Edit]" on the page, and when opened it allows editing the reference (template), as entered on that page. Much like one can edit a Section now. -DePiep (talk) 10:12, 8 March 2012 (UTC)

[further explanation needed]. Can you explain what are the benefits of this change? Diego (talk) 10:32, 8 March 2012 (UTC)
It isolates, for editing, the single reference code input (template usage on the page) from other code. Especially since the code is in line, it is complex when editing the full page. -DePiep (talk) 10:42, 8 March 2012 (UTC)
{{Cite doi}} has that feature, but it only works because each reference is a subtemplate. ---— Gadget850 (Ed) talk 10:52, 8 March 2012 (UTC)
Spot on. We could limit it to cite templates, I have cast the net a bit wide. -DePiep (talk) 11:01, 8 March 2012 (UTC)
  • Have you tried ProveIt? You can activate it in your Preferences->Gadgets. It doesn't work exactly as you describe, but it's somewhat similar, I think, and worth a look if you've never tried it. Begoon talk 10:57, 8 March 2012 (UTC)
  • I just tried the demo. Very, very good. But hey, I do AWB once a month. I really need to learn HotCat, to use it once a month. Maybe I am a TWinkle-editor, once a month. You get my point? I am a serious editor, with many edits, but having to (learn to) use an App is not good. Just give me an [Edit] click, please. -DePiep (talk) 22:29, 9 March 2012 (UTC)
1) Wouldn't WP:Citing sources (or such) be a more appropriate place to discuss this?
2) The proposal is unclear as to where this edit link is to appear. You mention a "reference" section: does this mean specifically a section titled "References"? Or some other section? Or is the edit link to follow the citation (reference) wherever it is displayed? Or do you propose that these edit links be collected in some special section?
3) If the core problem is the difficulty of template coding being mixed in with article text (and I agree that is a problem), then there is a much easier solution: gather all the templates together in one section (e.g., "References") and link to them using Harv.
~ J. Johnson (JJ) (talk) 17:45, 8 March 2012 (UTC)
Not everyone like Harvard referencing. --Cybercobra (talk) 05:25, 9 March 2012 (UTC)
re JJ: 1) Indeed, "(or such)" is where I ended up. 2) As for where the [edit] is to appear: I think I described that in the first sentence. A more exact location can be decided later, and is not essential for the proposal. {{cite doi}} is a good example. 3) Reducing cite options to just harv is no way forward, and not "easier" (more simple it is, as in "choose any black color for your T-Ford"). I must say, you got the issue right when acknowledging it. -DePiep (talk) 16:57, 9 March 2012 (UTC) Struck my arrogance -DePiep (talk) 22:18, 9 March 2012 (UTC)
You have not explained why this venue is more appropriate than (say) Wikipedia talk:Citing sources. I think that exactly where this edit tab is to appear is a key part of the proposal, and not something that can be "decided later"; the lack of that detail suggests that the proposal has not been adequately worked out. (Could you provide us with a mockup?)
And I find it quite inexplicable how you find "Reducing cite options to just harv is no way forward". I certainly have not suggested "reducing cite options" – I suggested an available option that is likely more useful, and certainly easier, than what you are proposing. That many editors are prejudiced against it is unfortunate, as it does not suffer from the problem you apparently want to address. ~ J. Johnson (JJ) (talk) 00:33, 10 March 2012 (UTC)
JJ, how did I offend you? I am here on this page to drop an immature proposal. Maybe more than just my detailed world is involved (it is: another "[edit]" utton on a page!), but we are here to let it evoluate. -DePiep (talk) 00:03, 17 March 2012 (UTC)

wikipedia board game

a board game for wikipedia — Preceding unsigned comment added by Duocat (talk • contribs) 15:12, 14 March 2012‎

There's a card game in development - WP:TCG. Equazcion (talk) 15:15, 14 Mar 2012 (UTC)

Sounds an interesting idea, perhaps this ought to go on the Wikipedia: Main Page (rather than here) so that more people see it! ACEOREVIVED (talk) 12:00, 15 March 2012 (UTC)

Be serious. Why would we put some half-assed scheme to make a card game out of wikipedia on the main page. ffs. --Tagishsimon (talk) 13:43, 16 March 2012 (UTC)

Proposed guideline

An RfC has been posted concerning a proposed guideline tentatively by the name Wikipedia:Disruption on talk pages. Please comment. Brews ohare (talk) 18:31, 15 March 2012 (UTC)

This proposal has been moved from user space to Wikipedia talk:Avoiding talk-page disruption. Comments collected so far can be found there. Please comment. Brews ohare (talk) 18:04, 16 March 2012 (UTC)

Citation needed

When I read [citation needed], I can't tell whether the sentence it refers to was written a fortnight ago, and the tag added a week later, nor whether a citation is in the process of being sought . . . OR whether they're both aeons old.

I propose that it be changed to [citation needed (2nnn/nn/nn)] (not retrospectively, of course) so as to help readers know how much weight to give a statement which someone has implicitly challenged.

I've suggested a century-first format to obviate the American mm/dd/yy format versus the European dd/mm/yy format ambiguity.

I propose the date be inserted by software, not by the tag inserter.

Forgive me if it ISN'T called a tag! I'm not anything of a wikipedia editor, so I'm guessing.

There should be a bot that comes along and adds the date to the tag... perhaps it's down at the moment. 28bytes (talk) 17:58, 16 March 2012 (UTC)
I don't think that is what the poster is asking about, 28, since the bot-added date isn't visible on the article page.
I think the main reason that we don't have dates visible in "citation needed" tags is that it would take up more space and, actually, it wouldn't in practice be a very good guide to how seriously to take the tag. Sometimes the tag can be there a long time and it turns out that the info is true. Sometimes it may have only just been put there, but put there for a very good reason. I don't think there's any real rule about it.
I would say that the only way to check out whether tagged info is reliable is to research it yourself. Of course, you should also add what you find out to Wikipedia so that everyone can benefit. --FormerIP (talk) 19:47, 16 March 2012 (UTC)
But if you mouse over it, it shows the date.[citation needed] 28bytes (talk) 19:57, 16 March 2012 (UTC)
Yeah it does. But what I'm saying is if you think a five year old tag is necessarily more for a reader to worry about that a two month old tag, you're not correct. --FormerIP (talk) 20:00, 16 March 2012 (UTC)
Well, sure. I'm just telling him how to find the information he's looking for. How he uses it is up to him. :) 28bytes (talk) 20:59, 16 March 2012 (UTC)

UID interface to Wikipedia

This is a proposal to come up with a systematic means by which members of subsets of Wikipedia articles (chemicals, protiens, railway stations, etc etc) can be accessed by means of Universal IDs.

The subjects of many wikipedia article have unique IDs assigned to them. Chemicals are identified by their CAS registry number, for instance; protein sequences are identified by a range of UIDs such as UniProt; nucleotide sequences and their protein translations by GenBank ... UK railway stations by NaPTAN, etc. As you'd expect, UIDs are used to provide access to all sort of database repositories. Techniques include web service interfaces, APIs, etc. UIDs make information available on a systematic basis.

UID are already widely used on wikipedia, notably in infoboxes of articles. But right now, any info wikipedia has about a subject is (as far as I know) mostly inaccessible by the UID. Searching for the Ensembl UID for Rhodopsin, ENSG00000163914, brings a pretty useless result.

Equally, right now, any number of software products exist to search third party databases for information by UID. Other than by article name, wikipedia will tend not to feature as a source.

The proposal, then, is make such changes as are sensible to make wikipedia articles accessible by UID through the normal web interface. There are a number of ways this could be done; I come here for thoughts and direction both about the general idea and also the specific implementation. A low-tech example implementation is to create a redirect for each UID - e.g. Ensembl-ENSG00000163914 - and expect it to redirect to the article, Rhodopsin. A better approach would be to reuse the data already in infoboxes to seed the interface, so that we're not double entering data.

If it needs answering, the "why do this", "what use will be made of this" questions resolve to "because we can", "who knows", "until we do we'll not find out" and "if we don't, then we prevent these things from being realised". Those seem good enough reasons to me. Grateful for proposal and implementation detail feedback. thanks --Tagishsimon (talk) 21:25, 13 February 2012 (UTC)

I absolutely endorse this proposal - I'd be happy to be considered a co-proponent - which accords with moves to increase Wikipedia's metadata and machine readability; as well as interoperability with other websites and apps. Alternative formats (and there will be others) would be Ensembl:ENSG00000163914 or to set up a UID namespace, for example: UID/Ensembl/ENSG00000163914. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:39, 13 February 2012 (UTC)
Support redirect system. Redirects are cheap, and I can't see how the it would interfere. If other commenters have a negative outcome in mind, then I may need to re-evaluate. At the moment I can't see it. Not sure what "A better approach would be to reuse the data already in infoboxes to seed the interface, so that we're not double entering data." means. Automatically creating (or even maintaining) redirects based on infoboxes could be suitably trialled and implemented, I would think, if that's the sort of thing you meant. Grandiose (me, talk, contribs) 21:45, 13 February 2012 (UTC)
I'm not convinced that "who knows" is a sufficient reason to spend the time & resources of the WikiMedia on fixing a problem which does not yet exist, when they could be used to fix problems that we do know exist. If I've just not fully understood the proposal (which may well be the case), just let me know. ItsZippy (talk • contributions) 21:48, 13 February 2012 (UTC)
It's hard to say, ItsZippy. Who knows what's in your head? What I know is this: right now anyone who has an app which uses UIDs finds wikipedia inaccessible. If we re-use UIDs to enable access to article text, it becomes utterly trivial for any third party dealing in UIDs to access our content. --Tagishsimon (talk) 21:53, 13 February 2012 (UTC)
To be honest, I don't know a great deal about UIDs. If you think it's beneficial, then I won't be opposed. ItsZippy (talk • contributions) 22:15, 13 February 2012 (UTC)
Rather than onwiki namespaces, it might be possible to do something using a simple lookup database - toolserver.org/UID/Ensembl/ENSG00000163914 spits out the relevant article, with the option of adding /en or /de to the URL to select the desired language, etc. I do like the idea very much - I can see an obvious application involving LCSH headings resolving to specific Wikipedia articles, for one thing! Please let me know if you go ahead with this...
One other approach would be to increase our use of hidden infobox fields, and make sure they search properly. It's not much help to prominently display relatively technical identifiers in an article, but if we used something like persondata - a hidden metadata template - this would be a great use for it. Including this alongside the referrer database or redirect would also help ensure we don't get errors creeping in due to page moves (which is likely if we start using geographical or personal identifiers); we can have a script patrolling for mismatches and flagging them. Shimgray | talk | 22:40, 13 February 2012 (UTC)
Why would we put something on the toolserver, when Wikipedia itself can host it adequately? Also, I'm not in favour of hidden fields. We should be displaying UIDs in infoboxes; but that's a separate issue and should not be conflated with this one. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:09, 13 February 2012 (UTC)
I'm certainly not wedded to the idea of an off-wiki solution (and toolserver was just an arbitrary suggestion), but I think it's worth considering the benefits. The model I'm thinking of here is the very successful QRpedia, which does a similar trick of going through an intermediate layer before resolving a specific Wikipedia article, rather than leaping straight to an enwiki address.
Firstly, in the short term, it's simpler. We can set up a test database of these links elsewhere as a demo without approval, since it doesn't have to tie directly into the wiki; going straight for onwiki namespaces involves getting consensus before being able to do a practical demonstration, which risks becoming a vicious circle... (Transferring a proof-of-concept database to the wiki should be relatively simple, if the namespaces are later enabled - it'd be a matter of running a script to populate the redirects. The converse is true, as well, of course!)
Secondly, it has greater potential for future development. Using an intermediate layer makes it a lot easier to expand the functionality with things like:
  • adding alternate-language capacity via the same URL, without having to seperately query xx.wp and xy.wp and xz.wp to see if there are entries in the preferred languages. (I can imagine a case where a database would say "We need results in Polish, alternatively falling back to German or Russian, and if all else fails use English.")
  • more versatility in what we send back - some users might want microformat metadata, some might want full articles, some might want mobile ones, some might want us to spit out a copy of just the lead or the infobox image, etc.
...to take a couple of examples. Shimgray | talk | 12:47, 14 February 2012 (UTC)

This seems desirable, but probably needs a project page somewhere so ideas can be worked through. Is it wanted that a Google search for "ENSG00000163914" would include Wikipedia in its results? And/or a normal (article namespace) Wikipedia search? (Currently, a Wikipedia search finds nothing unless searching in the template namespace.) Roughly how many articles might end up with a UID? How would they be maintained? While a bot might happily create thousands of redirects, there should be some planning for how the results could be maintained. For example, there could be a master list somewhere, and a bot would make the redirects from that list, and would periodically report any changes to the redirects that disagree with what is in the list. Johnuniq (talk) 10:08, 14 February 2012 (UTC)

Yes; a project would be a good idea. Google searching would be one benefit, but the primary purpose would be so that other websites (online databases) and apps could programmatically create URLs like, say, http://en.wiki.x.io/wiki/UID/Ensembl/Foo, where "Foo" is a UID, and be redirected to the relevant article. Hopefully, this would also, eventually, be possible through the API, too. The use of categories would serve to provide lists of such articles. A bot could create the redirects, by scanning, for example, sub-templates of {{PBB}}; like {{PBB/6010}} for Rhodopsin. I like your ideas of a bot reporting suspicious changes. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:36, 14 February 2012 (UTC)
Tagishsimon, POTW, ... will you please stop having good ideas before I have them! .... :-) I'm currently talking to Library catalogue folks in Sheffield. I think we have an agenda! (ItsZippy - our resources are volunteers - the resource is infinite! We just need discussions about where the value and the enthusiasm best match. This might be one of them Victuallers (talk) 10:56, 14 February 2012 (UTC)

I have created WikiProject Unique Identifiers for discussion and coordination of all UID related matters. Please join! Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:49, 14 February 2012 (UTC)

A google search for ENSG00000163914 within the en.wiki.x.io domain gives {{PBB/6010}} and Rhodopsin as the top two hits. It is also worth noting that at least one external database can be search for ENSG00000163914 (see for example GeneCards) that leads to a link that points back the the Wikipedia Rhodopsin article. I don't see any harm in adding these types of redirects, but at the same time I do not see any particular advantages either, especially considering that search engines can rapidly locate the desired article. For the rhodopsin article alone, there would be an almost endless list of possible redirects starting the rhodopsin ensemble accession numbers for a half dozen additional species, the refseq RNA and protein IDs, UniProt IDs, etc. Boghog (talk) 20:50, 20 February 2012 (UTC)
The particular claimed advantage is that a third party database using UIDs can link to wikipedia articles at something like nil marginal cost. Given that we have UIDs in articles, leveraging them to create redirects is also pretty much nil marginal cost. There may be many redirects to a single article, agreed, but I don't see that as a problem. --Tagishsimon (talk) 21:03, 20 February 2012 (UTC)
You don't see any cost to adding millions of redirects? --MZMcBride (talk) 14:15, 1 March 2012 (UTC)
That's why bots were invented. When we have large numbers of articles with specific unique identifiers, a bot will not have difficulty figuring out the one that's applicable to each article. This is a simple enough task that I doubt we'll see false positives except for occasional vandalism and typos. Nyttend (talk) 14:35, 9 March 2012 (UTC)

I am still confused as to why we would want all this in the first place? Could someone explain the idea in simple language. (Don't assume people understand what you are talking about). Start with explaining what a "Unique Identifier" is and does. Then go on to explain why and how you think Wikipedia would benefit from having these "Unique identifiers". Thanks. Blueboar (talk) 15:05, 9 March 2012 (UTC)

THere are standard codes for train stations. THere are standard codes for Proteins. I run a web site or database dealing with train stations. And another dealing with proteins. I use these standard codes in my website. Right now, I cannot use these codes to link to wikipedia.
Wikipedia has standard codes for train stations in its train station articles. Wikipedia has standard codes for proteins in its protein articles.
If wikipedia uses the codes it already has, to crate redirects to the appropriate train station or protein page, then by making one simple change in my website code, I can link all of my train station entries to wikipedia: my users can navigate from my website record to the apropriate wikipedia record. Ditto proteins.
That's it in a nutshell. And yes, there are a number of train station and protein web services out there; and ditto the very many other database systems dealing in entities which have UIDs. Does that help? --Tagishsimon (talk) 15:16, 9 March 2012 (UTC)
So you want the Ensembl code for the protein Rhodopsin to redirect to that page, using a predictable format like Ensembl-ENSG00000163914. We should be able to set up something like that using a bot, based on infobox contents. WhatamIdoing (talk) 00:51, 13 March 2012 (UTC)
Support - a unique UID namespace would be the best way to go about this - redirects are going to be cluttered, as one would require an exact format in order to obtain the page. With a UID namespace, people will not have to follow the exact format and UIDs will actually be a useful part of Wikipedia. Wer900 (talk) 18:53, 18 March 2012 (UTC)

Allow to move to a website even if it is [www.<name>.com]

Hello. The current MediaWiki software can provide hyperlinks starting with http://. Many new users who want to contribute positively, and is trying to learn Wikimarkup fast rather than using the software for providing external links, write [www.google.com Google] instead of Google Many articles have this problem, having [www.<name>.com Name] in external link, rather than beginning with http website name.com . See a diff here, in my sandbox. I would like to ask for a communal input on this topic. Please be clear in what you try to tell. Thanking you, Dipankan says.. ("Be bold and edit!") 08:55, 16 March 2012 (UTC)

This sounds like a problem that a bot could fix. If the pattern you observe [www.something.tld text] appears the bot could isnert the http:// . If the text is missing it would be better to convert to a raw url without square brackets. Graeme Bartlett (talk) 11:29, 16 March 2012 (UTC)
I don't think the bot could handle so much. There may be more than 10,000+ pages with this issue. Dipankan says.. ("Be bold and edit!") 13:25, 16 March 2012 (UTC)
The MediaWiki software detects the URI scheme to create the link, and a lot of websites do not use www in the URL. ---— Gadget850 (Ed) talk 13:34, 16 March 2012 (UTC)
It could have a limited benefit, but overall I think the impact would be negative. People need to realize that a full URL includes the scheme. Some popular browsers are now omitting the scheme in the address bar by default (or in the case of Chrome, totally removing the option of ever showing the http:// scheme), but this is a mistake that we don't have to make. Editors need to have competence, and there is always the preview function; we don't need to encourage laziness in editing. Browsers are usually designed to be "friendly" in that they will try to figure out what you meant, but when writing an article we need to be specific with exactly what we're referring to. See also robustness principle. —danhash (talk) 14:04, 16 March 2012 (UTC)
A bot can easily handle 10000+ pages. The hard part is finding all the pages with this problem, which sounds like a job for WP:WPCHECK. Anomie⚔ 17:23, 16 March 2012 (UTC)
I concur with DanHash. Sloppy link coding like this is actually one of the easiest ways to find would-be reference citations that need to be verified and properly WP:CITEd; having a bot "fix" them would actually do harm to real WP:V/WP:RS cleanup interests, which are way, way more important than extlink formatting cleanup interests. This would effectively hide a symptom indicative of an untreated disease, as it were. PS: poorly coded links are also one of the easiest ways to find crap in articles that violates WP:SPAM and/or WP:EL, and "fixing" it would also harm WP:NPOV cleanup interests. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 19:12, 16 March 2012 (UTC)
I agree. In addition, I have sometimes seen stuff like "an example of a host name is www.example.com" which should not be changed to a link. Contributors should be encouraged to edit, and no one should revert changes merely because they are not properly formatted, so invalid links are not a big deal. As stated above, it would be best for an experienced editor to review the text and decide on the appropriate action (often external links are undue, or plain spam). Johnuniq (talk) 02:31, 18 March 2012 (UTC)

Image or caption dispute tag?

I have a question regarding proper inline tagging of an article when there is a dispute about the accuracy of an image. This is of particular interest in the field of astronomy where speculative illustrations of unresolved objects are more commonplace. Would it be better to use a tag like {{Disputed-inline}}, {{Dubious}} or {{Or}}, or should a new inline template be generated specifically for image concerns? For example: [Image disputed – Discuss]. Regards, RJH (talk) 19:24, 13 March 2012 (UTC)

This presumably is related to the discussion at WT:NOR about whether images can be banned from Commons for violation the English Wikipedia's "No original research" policy. WhatamIdoing (talk) 00:04, 14 March 2012 (UTC)
Only indirectly. Regards, RJH (talk) 23:07, 14 March 2012 (UTC)
It's a complicated problem. I'd suggest tagging the image (rather than the article), except that most of our images are at Commons, and the English Wikipedia can't really go tag the image files over at Commons for non-compliance with our standards. Additionally, the image could be perfectly fine, but misused in a particular article. For example, you seem to object to using artistic illustrations of exoplanets (someone might be confused into thinking it's a real photograph rather than some artist's vision of the planeet), but I'm sure that we could agree that such an image would be a perfectly fine illustration for an article about Illustration of exoplanets.
I don't really know what the best way to tag such a problem is. I think I'd skip the tag and just head for the talk page. WhatamIdoing (talk) 00:56, 20 March 2012 (UTC)

Cool news, HighBeam Research to donate free, 1-year accounts for Wikipedians

I have just finished a discussion with some generous folks at HighBeam Research--an online, pay-for-use search engine for newspapers, magazines, academic journals, newswires, trade magazines and encyclopedias. The site has access to over 80 million articles from 6,500 publications, most of which are not available for free elsewhere on the internet. Aside from a free 7-day trial (credit card required), access to HighBeam costs $30 per month or $200 per year for the first year and $300 for subsequent years.

But...as of yesterday, HighBeam has agreed to give free, full-access, 1-year accounts for numerous Wikipedia editors to use, at the discretion of the community. They do not expect there to be a problem with the number of these free accounts; however, the plan is for editors to have a minimum 1 year-old account with 1000 edits in order to qualify.

This is a proposal/announcement of the project not the signup process, which should begin in early April and will be widely publicized. Details about the project are available at WP:Highbeam. Comments and assistance setting up the project are welcome. Cheers! Ocaasi t | c 09:27, 14 March 2012 (UTC)

Very welcome news; kudos to you and to HighBeam. --Tagishsimon (talk) 14:56, 14 March 2012 (UTC)
Indeed this is welcome news. Ditto on the kudos. Thanks for sharing this.--JayJasper (talk) 20:02, 19 March 2012 (UTC)

Proposed Removal of Article tab in Archived Talk pages.

I'd like to see a method of having the Article Tab removed on Archived Talk pages such as Talk:Muhammad/Archive 18, in this case it does not make sense to actually have the equivalent article Muhammad/Archive 18. While it is not always true that a talk page with a slash shouldn't link to its equivalent article (like Talk:Face/Off), is there some way that there could be a flag set (which could go in the Template:Automatic archive navigator as well as other appropriate places). (In fact can anyone think of a reason that a talk page that exists should have a link to a "article page for it" that doesn't exist yet?) Note, this is a "like to see"...Naraht (talk) 15:05, 19 March 2012 (UTC)

Or the article tab could like back to the main article, for example on Talk:FL Studio/Archive 1, the article tab would link to FL Studio, not FL Studio/Archive 1. Either way, this would be a useful feature. —danhash (talk) 15:15, 19 March 2012 (UTC)
Also a very valid idea, either would be much better, IMO, than the current situation.Naraht (talk) 15:26, 19 March 2012 (UTC)
A good idea; the current appearance is rather weird and potentially misleading. dci | TALK 22:28, 19 March 2012 (UTC)
This was also discussed at Wikipedia:Village pump (technical)/Archive 97#Can we get talk archives to point to the main? PrimeHunter (talk) 01:04, 20 March 2012 (UTC)

Contribs tab

I was going to request this, but I eventually managed to script it myself. There used to be several scripts for this on Monobook, but since Vector I couldn't find a working one, and I figured people might want to know it exists now. User:Equazcion/ContribsTabVector. Equazcion (talk) 12:19, 13 Mar 2012 (UTC)

I'm sure Equazcion knows this but for people considering this script who might not, there's a "User contributions" item in the Toolbox menu on the left-hand sidebar when you are on a userpage. Jason Quinn (talk) 03:16, 21 March 2012 (UTC)
Yeah I do :) As evidenced by the three or so scripts that existed for this under Monobook though, many users like to have this in a tab. It feels like it should be one. Equazcion (talk) 03:23, 21 Mar 2012 (UTC)

Proposal: allow anchors to lead paragraphs.

Wikipedia is the natural home for glossary information required by other websites. Rather than building their own glossaries, web authors should be able to link directly to Wikipedia. However, it is often the case that the item of information important to the referencing site is not the article as a whole, but a particular section, paragraph or even sentence, table or figure within the article. This is the Wikipedia counterpart of footnotes in print documents that refer to particular page of another document. Wikipedia already provides a certain amount of fine-grained access with its table of contents, which when used provide a URI that an author can use to link directly to a section.

This ability to link directly to specific information is not true of the lead paragraph, which contains essential definition of the subject of the article, and is precisely the information that would make a Wikipedia article for glossary footnotes. That omission may be unimportant when an author uses an endnotes style of glossary references: a link can take a reader to a Wikipedia page, which he can read and then return from; but it makes using Wikipedia difficult for authors to use frames or other techniques to provide footnotes that can be read simultaneously with the page using the defined term.

For example, if I am writing a page that discusses Aristotle's concept of causality, I can use the URI "http://en.wiki.x.io/wiki/Causality#Aristotle" in a link, with a target of MyFootnoteFrame and the Wikipedia article on causality will open in that frame directly at that section. But if I use the URI "http://en.wiki.x.io/wiki/Causality" the article opens at the top of the page with (today) three inches of page space before the lead sentence. For the purpose of putting footnotes in a compact frame, that effect is quite undesirable.

I tried adding ' {{anchor|Topic}}' tags to the lead sentence, but they are being removed by disapproving editors. Izno merely called them "unstandard". Johnuniq had more to say: "Articles at Wikipedia should not have obfuscating wikitext added simply for the convenience of external websites. I have removed your edit from Uniform resource identifier because it does not assist the article and has the potential to confuse editors (why is it there? what is it for?)."

I respond to Johnuniq by saying that anchors are obfuscating only to those who do not understand the interrelationships among information. Moreover, just as national boundaries have become moot relative to the global economic flow of goods and services, the boundary between what is internal and what is external to Wikipedia is moot relative to the noetic flow of information. Wikipedia is the perfect place to record, debate and refine common knowledge. But the uses to be put to that information vary with every story told by every author in the noösphere. Anchors are the technical mechanism that enables that multiplicity of usage. Wikipedia encourages its authors to build articles out of fine-grained, documented, reusable information. They should also be encouraged to anchor that information so that other authors, both inside and outside Wikipedia, can make effective use of it.

Far from prohibiting anchors, Wikipedia should encourage and standardize them. What should be the standard practice, to enable authors to point directly to the lead sentence or to other fine-grained information? What should be the standard anchor/URN for a lead or other sentence so that it can be referenced by a URI (URL + # + anchor) to that sentence? Should a shortcut template be added so that users can obtain the URI? Should some other link be added so that a reader of a Wikipedia footnote can open the full page in a new window? What instructions should be placed in this MOS article to guide Wikipedia editors in entering lead paragraph anchors? Is it possible that such anchors (and shortcuts) could be generated automatically? These are important technical questions that need to be addressed.

But policy must be set first. Is Wikipedia going to play a significant role in the commerce of information by being a broker of information by allowing fine-grain access to its contents, or is it going to insist that the Wikipedia page is the smallest unit of information that it will provide ready access to, in which case users of information will have to turn elsewhere.

Since I am in the process of building a website that requires a good glossary that I can present in a footnotes frame, I would appreciate some guidance. Should I put my efforts in upgrading Wikipedia to serve this need, or should I write my own glossary that simply links to Wikipedia?

[This is a modified version of the suggestion I put in the Talk section of Wikipedia_talk:Manual_of_Style/Lead_section.]DrFree (talk) 22:23, 18 March 2012 (UTC)

The built in #top links to the pagename, for example Causality#top. #mw-content-text links to the start of the article body, for example Causality#mw-content-text. As in this example, it will often be a hatnote. PrimeHunter (talk) 23:26, 18 March 2012 (UTC)
There's also Causality#firstHeading, which links to the title of the page (below the site notice, if any). In general, if you look at the page source any tag with id="foo" may be linked to with #foo in modern browsers. Anomie⚔ 01:43, 19 March 2012 (UTC)
Thank you for the suggestions but none have the require functionality: Causality#top and Causality#firstHeading open the page at the title, a wasted inch above the lead paragraph. Causality#firstHeading opens the page at the redirect paragraph, closer but still half an inch lead paragraph. Sorry to be picky, but a web page can only allocate a narrow frame for footnotes.DrFree (talk) 22:33, 19 March 2012 (UTC)
The topic caught my attention, but – WP:TLDR. ~ J. Johnson (JJ) (talk)
I didn't read it all either, but this use of {{anchor}} is inappropriate. If you want this functionality go get it done at mw:. Alarbus (talk) 01:16, 19 March 2012 (UTC)
Going to mw: seems inappropriate, for what I am questioning are Wikipedia standards applied within the Wiki software.DrFree (talk) 22:33, 19 March 2012 (UTC)
It appears from [5] and the long post that DrFree wants an anchor when the "main text" starts after any hatnotes, message boxes, infoboxes, images and whatever. That would be difficult to determine for mw. A possible combined editor/mw solution would be that editors could place an anchor with a standardized name like "lead", and if mw detects there is no such anchor on a page then mw automatically makes it at #mw-content-text right below the pagename and tagline. I don't know how much such a feature would be used in practice. PrimeHunter (talk) 02:39, 19 March 2012 (UTC)
All I am really asking is for a more permissive attitude towards anchors. In general it is difficult to anticipate where in an article an author might want to point. The only special place that perhaps needs an automatic anchor is the lead paragraph, which the MOS requires to have both the topic title and a concise definition or explanation.DrFree (talk) 22:33, 19 March 2012 (UTC)
No. While you may want anchors in articles at certain places for your website, other people may want anchors at different places for their websites. How would that benefit the encyclopedia? Articles are not formatted for the convenience of external websites without very good reason (I am unaware of any such cases, although there are some attempts to put some metadata, for example WP:Persondata, in articles). Anchors are for linking one Wikipedia article to another. Johnuniq (talk) 10:06, 20 March 2012 (UTC)
Such a slippery slope is far-fetched, but the benefits to the encyclopedia are obvious: the ability to reference particular items of information, rather than whole pages or just the predefined sections, would make Wikipedia the natural collection of background information to be referenced by web sites doing the original research that Wikipedia eschews. It would become an integral part of the world wide web of information, not a mere, self-contained island. DrFree (talk) 15:46, 20 March 2012 (UTC)
If there is value here, then the anchor should be applied to every article, not just a select few. I checked, but don't see this listed, so file a software enhancement. ---— Gadget850 (Ed) talk 10:54, 20 March 2012 (UTC)
Separating the general question of allowing editors to insert anchors where they find them useful, from the question of anchoring the lead paragraph, it would appear that this is not a software enhancement, because it is based on an internal Wikipedia standard which assigns special status to a particular sentence: MOS: Lead paragraph: First_sentence, which is precisely where external glossary references would normally want to point. If the software could be made to recognize and anchor that internal Wikipedia standard, that would be great, but such an enhancement is unlikely in the near term. Hence my current request is merely to be able to anchors to first sentences without their being removed by over-zealous editors.DrFree (talk) 15:46, 20 March 2012 (UTC)
I agree that random creation of anchors by editors at arbitrary points is different than a sistematic anchoring of the lead paragraph, and that creating an automatic anchor for all the leads is a good thing. That said, this should be created by modifying the software so that all pages (or none) get this enhancement. Manually creating anchors for the particular pages you want to reference from an outside site is a terrible idea, it would require a massive clean up work when/if a better way to link to the lead is ever implemented. Your better option is to submit the feature request, maybe recruiting the help of Wikipedia talk:Semantic Wikipedia or some other interested wikiproject. Diego (talk) 16:18, 20 March 2012 (UTC)
So the situation appears to be: (1) The first sentence of an article is important enough to have very special standards applied to it by the Manual of Style. (2) Those very standards make it an attractive point of reference to other web sites, both within and without Wikipedia. (3) There is no syntactic marker which designates the first sentence. (4) Because there is no syntactic marker, there is no way for software to create an automatic anchor. (5) Software magicians might someday overcome this insuperable difficulty. Therefore (6) anchors to the first sentence won't be allowed because they might interfere with some future magic trick. It appears that the much heralded "democratization" of information that was to be the hallmark of Wikipedia has devolved into a politburo of self-appointed bureaucrats intent on vetoing proposals that they themselves don't directly benefit from. Shades of the Soviet Union! DrFree (talk) 19:05, 20 March 2012 (UTC)
Facepalm Facepalm
First, you're not helping your cause by being so insulting. This isn't something to be fixed here on en.wikipedia. Manually adding html anchors to specific pages is just bad form, and would lead to frustration & confusion when someone tries to link back to a page where they're not implemented. It would require a code-change to apply to all articles, which means you should file via the bug reports & feature requests system. — The Hand That Feeds You:Bite 20:07, 20 March 2012 (UTC)
If you want those anchors so badly, why don't you just download your own copy of Wikipedia and edit it to your heart's content? It is free content after all as long as you comply with the license (you're showing proper attribution and licensing, right?), and it occupies only about 8Gbs (much less if you trim all articles to just their lead, and a trivial weight for the few articles that you could tag by hand). Why request -no, demand- that the whole project accommodate to your needs, when you already have been given permission to do as you please - at your private space, without interfering with others? ("Soviet Union", indeed). Your proposal here looks like an over-engineered solution to a non-existent problem. Diego (talk) 21:50, 20 March 2012 (UTC)

Adding a NOINDEX tag to unpatrolled articles

Hey guys

After suggestions on the New Page Triage discussion page, we've opened a Request for Comment on adding the NOINDEX tag to unpatrolled articles - basically ensuring they can't be syndicated by google. If you've got an opinion or any comments, head on over there and post your two cents :). Okeyes (WMF) (talk) 13:07, 20 March 2012 (UTC)

Administrators should be restricted in what they can get away with

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
The community as has stated before expects "Administrators [...] to uphold the trust and confidence of the community" (See WP:ADMIN) with the extra tools. There is no indication in this thread that it has changed and the consensus of the community is to keep things the way they are. Though administrators may need to be more careful when issuing blocks (as noted by some of the users commenting) this does not mean the community has lost trust in all administrators to issue appropriate blocks for long term project users. -- DQ (ʞlɐʇ) 09:28, 25 April 2012 (UTC)

I propose that administrators ought not to be allowed to block established editors until they have themselves made at least 25 per cent of the edits that their victim has. Malleus Fatuorum 01:14, 10 March 2012 (UTC)

"edits" defined as "edit-count"? Choyoołʼįįhí:Seb az86556 > haneʼ 01:18, 10 March 2012 (UTC)
Yes. Malleus Fatuorum 01:30, 10 March 2012 (UTC)
Seems reasonable to me IMO. Rehman 01:27, 10 March 2012 (UTC)
  • Strong Oppose I'm not getting the point you are giving. But I don't think this is a good idea. For example, a sysop with only 5000 edits is free to block a user who has around 50000 edits who is revealed to be a sockpuppet of a banned user, as long as he/she has a very good understanding of Wikipedia policies. Also, wouldn't this be instruction creep, a solution in search of a problem? Narutolovehinata5 tccsdnew 01:29, 10 March 2012 (UTC)
Ahhh, I get your point now. Neutral because established users are trusted. However, occasional exceptions might apply in emergency cases. Still, this remains a solution in search of a problem. Narutolovehinata5 tccsdnew 02:36, 10 March 2012 (UTC)
Come to think of it, I don't think this will be a good idea. Experience is not by number, it is by quality. Also, there will times for emergency cases, like the Bot example I gave, that could go out of control. How can we block a bot with over a million edits? I think only a few people, if ever, will have the technical capability to do so. Narutolovehinata5 tccsdnew 04:52, 10 March 2012 (UTC)
  • You kind of elaborate on my point. Any so-called sockpuppet that makes 50,000 edits clearly isn't a problem. The problem is the wanky administrator that wades in without thinking. Malleus Fatuorum 01:35, 10 March 2012 (UTC)
I can think of several administrators with less than 10000 edits who have a good understanding of Wikipedia policy. Also, it's not about the quantity of edits a sysop does, but the quality of the work he does. I think there is an essay about that, but I can't remember. Narutolovehinata5 tccsdnew 01:39, 10 March 2012 (UTC)
I can't. Malleus Fatuorum 01:40, 10 March 2012 (UTC)
/yawn at silly timewasting. --Onorem♠Dil 01:41, 10 March 2012 (UTC)
Anyway, my point is, it's not the quantity of Wiki-work, but the quality of it. Narutolovehinata5 tccsdnew 01:46, 10 March 2012 (UTC)
I think what he means is established, as in prolific users like TenPoundHammer or WhisperToMe. Narutolovehinata5 tccsdnew 01:46, 10 March 2012 (UTC)
I did, yes. Malleus Fatuorum 01:54, 10 March 2012 (UTC)
It seems an unnecessary grey area - if an administrator can block someone and then justify their ignoring this rule by saying "in my opinion they were not established in the same way as prolific users like TenPoundHammer or WhisperToMe are", isn't that a huge loophole? Wouldn't it be better to leave out "established" entirely, just on the assumption that the number of operational admins with less than (say) 2500 edits is going to be near-zero? --Demiurge1000 (talk) 02:10, 10 March 2012 (UTC)
  • This seems like a basically good idea, I tend to think that only experienced admins should be blocking experienced users. One potential problem, there is one user with almost a million edits, but there are very few admins with 250,000 edits that could block him (not saying he needs blocking, this is purely hypothetical). Also, would this rule be waived if admins are blocking fellow admins? Mark Arsten (talk) 02:04, 10 March 2012 (UTC)
  • Support: Make sense—someone with four times the edit count of an admin (considering it's hard to become an admin with less that 5,000 edits) without already being indeffed or banned isn't likely here to be a nuisance. It would be respectful of that editor's large contribution to Wikipedia that someone with a likewise vestment in the project make the determination on a block. — Bility (talk) 02:05, 10 March 2012 (UTC)
  • Support: In general, Admins have too much power and long-term Editors have too little, this goes towards evening out the balance a bit, although ultimately I think the cure is to require Admins to re-run for Adminship periodically. Until then, we can expect Admins to continue to treat Editors with a lack of respect. StuRat (talk) 02:10, 10 March 2012 (UTC)
  • Oppose. If an established user gets blocked, they're free to appeal the block via an unblock request. That will get wider consideration of the block. If a block is to be reviewed, I'd rather it be on the merits of the block (editor's history, was the block preventative rather than punitive, is there an agenda with the block/is the blocking admin non-independent) rather than doing math on edit counts. Besides, edit count numbers can be deceiving due to deleted edits. —C.Fred (talk) 02:30, 10 March 2012 (UTC)
    No self-respecting editor would ever appeal a block. Malleus Fatuorum 02:34, 10 March 2012 (UTC)
    I actually agree there to some degree. I wrote WP:EHP a long time ago along those lines. Back then the appeal process needed work, don't have enough experience with it these days to say if things have changed. Equazcion (talk) 01:11, 14 Mar 2012 (UTC)
    Leaving aside, for the moment, the question of whether self-respect is necessary to edit Wikipedia; C.Fred, would you then also agree that (if this proposal were successful) if an administrator's block were procedurally overturned on the basis of this rule, without discussion, by another administrator, then that would be acceptable since the blocking administrator could appeal for the reinstatement of their block at WP:ANI or a similar venue? --Demiurge1000 (talk) 03:51, 10 March 2012 (UTC)
    I never suggested that self respect was necessary to edit Wikipedia, simply that noone with any would ever appeal a block. Malleus Fatuorum 04:23, 10 March 2012 (UTC)
    This is false. Many users have successfully appealed incorrect blocks, many of which were simple misunderstandings. Dcoetzee 05:02, 10 March 2012 (UTC)
    I think you missed the point. What I said was that no user would any self-respect would appeal a block, not that no editor would. Malleus Fatuorum 02:03, 12 March 2012 (UTC)
  • Question But what if prolific bots like ClueBot NG malfunction? There would be a shortage of admins to do the emergency block. Narutolovehinata5 tccsdnew 02:36, 10 March 2012 (UTC)
  • Comment. I'm surprised that Malleus Fatuorum hasn't shown up to address this proposal; He can usually be relied upon to argue stridently against the power of privileged, elite editors who are not governed by the same standards of conduct as the newer, less-experienced, or less-connected. TenOfAllTrades(talk) 02:54, 10 March 2012 (UTC)
    Perhaps you missed the fact that I initiated this proposal? Malleus Fatuorum 03:55, 10 March 2012 (UTC)
    Not at all. TenOfAllTrades(talk) 04:33, 10 March 2012 (UTC)
  • Oppose, "victim" is WP:BATTLEGROUND language. And that would make it pretty darned difficult to block, for example, Kumioko (talk · contribs)... --SarekOfVulcan (talk) 04:11, 10 March 2012 (UTC)
    it should be difficult to block, not the knee-jerk reaction. Malleus Fatuorum 04:31, 10 March 2012 (UTC)
    ...my point here being that to make yourself unblockable, all you would need to do would be to perform many automated edits, which would lead to gaming in the worst way. --SarekOfVulcan (talk) 19:12, 10 March 2012 (UTC)
    So you make it so that it has to be done at ANI or something and discussed rather than just leave it to one admin to do a "knee jerk reaction". I don't know whats worse in that statement Sarek. The inferance that Kumioko was just some vandal or that an editor that makes a lot of edits, automated or otherwise, is somehow reduced to the notion they are gaming the system. 71.163.243.232 (talk) 04:12, 11 March 2012 (UTC)
    I see what you did there. UltraExactZZ Said ~ Did 01:46, 12 March 2012 (UTC)
    You mean here? :-) --SarekOfVulcan (talk) 03:48, 13 March 2012 (UTC)
  • Oppose. Utterly silly. Makes it nearly impossible to block accounts with many edits (no matter how minor), even in the case of a grave offense like (say) uploading child pornography, and does nothing to protect established users from abuse, since sometimes the abusive admins happen to be the ones who also have a lot of edits. Moreover, it would provide an incentive for all users to make more edits at the expense of quality - enshrining editcountitis in policy in any manner is a terrible idea. The correct solution is to provide: 1. a good solution for appealing blocks; 2. desysoping of admins who abuse blocks consistently; 3. a policy which would allow (in certain situations) temporary reversal of a block for the purpose of having a consensus discussion regarding it in which the blocked user can participate. Dcoetzee 04:18, 10 March 2012 (UTC)
  • Oppose - edit count is not supposed to be a direct metric of user experience.Jasper Deng (talk) 04:24, 10 March 2012 (UTC)
    Can you suggest a better one? Malleus Fatuorum 04:34, 10 March 2012 (UTC)
Try the number of FAs, GAs and DYKs a person has contributed to. Narutolovehinata5 tccsdnew 04:54, 10 March 2012 (UTC)
Malleus still hasn't replied to my question. Assuming that this proposal is accepted, how can prolific bots be blocked if they malfunction? What do you think Floydian? Narutolovehinata5 tccsdnew 05:03, 10 March 2012 (UTC)
Fatuorum's proposal was likely not intended to target bots, so it's reasonable to assume they would be exempted from the eventual guideline. CharlieEchoTango (contact) 10:24, 10 March 2012 (UTC)
  • Question. This isn't a completely bad idea, as it would be a good way of preventing admin overreaching or abuse, but I think it would be extremely difficult to maintain as a guideline or policy. So, my question is this: what if an "established editor" repeatedly disrupts an article, a process, or blatantly and knowingly violates policy to the point where a block is necessary? And what if the admin who's the most available has less edits than the object of the block? dci | TALK 06:13, 10 March 2012 (UTC)
  • Oppose, the good judgement and/or (in)competence of administrators cannot be measured in the number of edits, and even if it could, it has little to do with the ethics of an administrator when it comes to blocking established editors. As for judgement, it can only be evaluated after the fact, through the proper procedure. Blanket restrictions are not the answer. CharlieEchoTango (contact) 10:19, 10 March 2012 (UTC)
  • Oppose - This would effectively mean that a few long term editors could do what ever they want without any chnace of repremand. Editors should expect to to treated equally.Nigel Ish (talk) 10:26, 10 March 2012 (UTC)
  • Oppose Both CharlieEchoTango and Nigel Ish have pointed out some obvious problems. And it's hardly appropriate for someone with as many edits as the proposer (who is currently 93rd) in the list at WP:MOSTEDITS to make a proposal that would leave only a handful of Admins available to block him). And as we know, any editor can suddenly develop problems that can only be stopped by blocking them. By the way, do we really have a system of edit counts that is 100% reliable? — Preceding unsigned comment added by Dougweller (talk • contribs) 11:38, 10 March 2012 (UTC)
  • Oppose reinforces vested contributors. Furthermore, does not account for minor contributions and AWB runs and page move warriors, so the metric is useless anyway. (For the record, I have 55,000+ edits and am an admin anyway, so there's only a small handful of editors that I could theoretically not block under this proposal; but ideologically, I disagree with it). --Rschen7754 11:54, 10 March 2012 (UTC)
  • There are not different levels of administrators. The RFA process is the time to worry about whether an editor has enough edits to be an admin. Once the editor becomes an admin, the issue of whether they have enough experience is settled. Moreover, the proposed system might give a way for some editors to avoid perfectly appropriate scrutiny. So I would oppose this sort of proposal. — Carl (CBM · talk) 11:58, 10 March 2012 (UTC)
  • Oppose. Edit count is not a valid measure. —  HELLKNOWZ  ▎TALK 11:59, 10 March 2012 (UTC)
  • Oppose. I think this is sound in principle, but flawed in application/proposal. So an established user blatantly edit warring couldn't be blocked by a new-ish admin if that admin is the only one who happens to have come across the warring? Perhaps a compromise solution is reachable; such as requiring a noticeboard block discussion (although I can see that any admin who would 'meet' any criteria could just take one look at the issue and block). If the issue is about admins with less than a certain number of edits then that needs to be dealt with separately. Instituting an arbitrary percentage cut-off is unnecessary. Strange Passerby (talk • cont) 12:05, 10 March 2012 (UTC)
  • Oppose - The motive behind this proposal seems to be Malleus' belief that administrators should abide by the same rules as everyone else and should not be given any special treatment just because of their position. I completely agree. I would also extent that to any editor. All editors should abide by the same rules as everyone else and should not be given any special treatment just because of their position - that is regardless of userrights, length of tenure or edit count. I agree that admins shouldn't be given privileged status; neither should anyone else, including those with a high edit count. ItsZippy (talk • contributions) 12:46, 10 March 2012 (UTC)
  • Support: per nominator's idea and Mark Arsten. The obvious exemptions would be intentional unambiguous, repeated vandalism, per consensus or bot accounts. On any other reasons when an experienced admin isn't available, community consensus should be sought. Some one with four times the experience of an admin would have a rather better judgement than him. --lTopGunl (talk) 13:06, 10 March 2012 (UTC)
  • Oppose: A solution looking for a problem. If a particular callow new admin is in the habit of thoughtlessly banning experienced editors, or if one or two of my fellow old-timers is a frequent victim, then it's a particular problem not calling for a new general rule. My habit of making fiddly little changes (picture layouts, geographical coordinates, etc) give me a larger edit count than many admins who tend to larger issues but that's not a reason for exempting me from their power, reasonably applied. And if unreasonably applied, sanctions exist which again have little do do with edit count. Jim.henderson (talk) 13:36, 10 March 2012 (UTC)

(edit conflict)

  • Oppose as completely unfeasible. Are we seriously going to make a situation where an admin goes, "oh, I only have 24% as many edits as this person, I can't block them for violating WP:NLT." Malleus, I get that you don't like the current admin culture, but this isn't helping. — The Hand That Feeds You:Bite 13:38, 10 March 2012 (UTC)
  • Comment Would not a reasonable move be to require all blocks of editors with over (say) 8,000 article and article talk page edits to be vetted by at least two admins at the start? For socks etc. I doubt this would be exceedingly onerous a requirement, but it might stop "quick finger blocks" which have a fair likelihood of being overturned later. Collect (talk) 14:05, 10 March 2012 (UTC)
  • Oppose Fails to take account of security issues. Sometimes accounts of long-established contributors get hacked and the person goes on a campaign of vandalism. It's perfectly reasonable to block those however many edits they've got. Also, some of our most long-standing admins have few edits, because way back when, it was a lot easier to pass RfA than it is now, when you basically need 10,000 edits minimum. —Tom Morris (talk) 14:38, 10 March 2012 (UTC)
  • Oppose: Tagging articles for wikiprojects can inflate edit counts quickly... one could just get around the idea by spending a little time doing that. Best, Markvs88 (talk) 14:52, 10 March 2012 (UTC)
Constant reversions of others edits also does that Mark with no real improvement to the project. Its obvious your referring to Kumioko but I should remind you that the majority of Kumioko's edits where not in adding WikiProject banners but in mainspace? 71.163.243.232 (talk) 13:06, 11 March 2012 (UTC)
Kumioko (your edit history gives you away, btw), this is no place for personal attacks. You've already gone after everyone else you feel has wronged you, and have now finally gotten around to posting again on my talk page. Please stop hiding behind an IP while sniping at me. My vote has nothing to do with you. Best, Markvs88 (talk) 13:43, 11 March 2012 (UTC)
I am not trying to hide. I closed out the Kumioko account, removed the password and scrambled it so its unrecoverable so any edits I make from this point will be by IP. Thanks to you and a few others User:Kumioko is dead and not coming back. 71.163.243.232 (talk) 14:00, 11 March 2012 (UTC)
"You keep saying those words. I do not think they mean what you think they mean...". (With apologies to Enigo Montoya). Best, Markvs88 (talk) 03:24, 12 March 2012 (UTC)
  • Oppose. Silly proposal. Obvious incentive for vandals to do millions of edits. Why are people wasting their tie on proposals like this? Dmcq (talk) 15:36, 10 March 2012 (UTC)
    As opposed to their cravat do you mean? Malleus Fatuorum 03:05, 11 March 2012 (UTC)
  • Oppose. If there's some statistic that objectively indicates a person's skill and judgment with some degree of accuracy, this might be a good idea. That statistic is certainly not edit count (and if such a thing were discovered, I think it would be a major scientific achievement). PS. This proposal looks pretty pointed to me. Equazcion (talk) 15:44, 10 Mar 2012 (UTC)
    I think you may wish to retract that accusation. Or at least you would if you had even a scrap of honesty. Malleus Fatuorum 03:09, 11 March 2012 (UTC)
I don't wish. This proposal had no shot, and whoever brought it is either stupid and inexperienced enough to think it did, or is just trying to stir the pot. And I know you're not stupid or inexperienced. Equazcion (talk) 13:31, 11 Mar 2012 (UTC)
It's quite clear that you on the other hand have done no thinking at all. Malleus Fatuorum 01:59, 12 March 2012 (UTC)
Good one. Equazcion (talk) 05:34, 12 Mar 2012 (UTC)
  • Oppose. Bad metric, even worse idea. ~ J. Johnson (JJ) (talk) 19:14, 10 March 2012 (UTC)
  • This is a case of "I know what you mean but..." The fact is that the dynamic of WP administration, especially admin on admin and established editor on established editor abuse is far more complex than that. Many admins start off all starry eyed and AGFy, and "Blocks aren't punitive" and "Leets make this work" and gradually become jaded. Similarly those with specialist knowledge or skills get tired of explaining the same thing to J. Random editor, especially if they have the social graces of a water buffalo in free-fall. But I do wonder if some kind of "hang on - are you really going to block this editor?" intervention would be a good idea sometimes. Especially with what Jon Vandenberg calls the "First mover advantage" (I.E. some action is drawn to the attention of n admins, where n is a large number - if any one blocks, the n-1 will be reluctant to wheel war). Rich Farmbrough, 02:03, 11 March 2012 (UTC).
  • Support - I also agree that too many administrators have too much power and too frequently don't use it correctly. They frequently take the easiest possible solution without reviewing the whole problem. In general I support eliminating the role of administrator and replace that role by granting the tasks in sets (like rollbacker, File mover, etc.). 71.163.243.232 (talk) 04:05, 11 March 2012 (UTC)
  • Oppose - "Support in theory" not practical to implement. Edit history of editors should be taken into account and explanations pursued before action is taken by an admin anyways.Moxy (talk) 04:52, 11 March 2012 (UTC)
  • Oppose - Edit count is no measure of edit quality, it is not even a fair measure of edit quantity. It is quite possible to do 10000 legitimate and uncontested edits with no noticeable quality improvement whatsoever, it is also possible to do only one edit, which nevertheless has significant and lasting value, and which could be quite large. Edit counts per se should be considered almost irrelevant, and not only for this application. If there was a way of measuring actual useful contribution, there might be some value in the proposal. Peter (Southwood) (talk): 08:08, 11 March 2012 (UTC)
  • Comment - I find it rather ironic and hypocritical that so many editors are saying that edit count is almost irrelevant and yet its required in order to submit an RFA (not written in the rules but try and get it without a large amount), get access to AWB (500 main space) and a whole variety of other things. If edit count was truly irrelevant then it wouldn't be required for those things. I also find it a little argumentative to say things like (if they just get millions of edits) well if they do then they probably should be an admin and there probably should be some pause before they are blocked. Lets not forget that even using tools like Twinkle and AWB it takes a very long time to hit a million edits. As far as I can tell no editor has even done yet after ten years. 71.163.243.232 (talk) 13:06, 11 March 2012 (UTC)
    • Lack of a decent edit count is a pretty good indicator that one doesn't have enough experience, sure. But that doesn't mean the converse should be true (that a high edit count means one does necessarily have any sort of qualification), which is the claim being made with this proposal. Equazcion (talk) 16:51, 11 Mar 2012 (UTC)
  • Comment. Any metric that involves edit count can be gamed in multiple ways. If the intent of the proposal is to give established users "mulligans" or "Get out of trouble free" cards, then that can be done in other ways. What the proposal says, essentially, is that established users get to breach policies at will, if there's the slightest veil of justification. So if I find an edit war, what do I do? Block the newer user and slap the established editor on the wrist? UltraExactZZ Said ~ Did 01:46, 12 March 2012 (UTC)
    That's not at all the intention, and I find it quite telling that your response to coming across an edit war is to issue blocks. Malleus Fatuorum 01:54, 12 March 2012 (UTC)
    Yes, clearly we don't block for edit warring. Ever. But the point stands - all other things being equal, the decision to block comes down to how many edits the editor has, yes? If you don't trust the administrator to exercise judgement, then get them desysop'ed. Bad judgement is bad judgement - and established users can screw up just as easily as new ones. Any policy that would exempt editors from compliance with policy due to any form of "tenure" is unwise, inequitable, and not in the best interests of the project. UltraExactZZ Said ~ Did 02:13, 12 March 2012 (UTC)
  • Strongest possible oppose. Wikipedia:No vested contributors (an essay, but should be policy, frankly). Robofish (talk) 01:59, 12 March 2012 (UTC)
    That's pretty much one of the daftest essays ever written. Malleus Fatuorum 02:08, 12 March 2012 (UTC)
    I'd never read that essay before, but I'm struck by "no editors are more equal than others". That's a nice and cosy ideal, but it just doesn't match the real world. Is a 10-year-old who doesn't even understand what an encyclopedia is as valuable to the project as a university professor? Is a Korean who can't speak a word of English as valuable as an experienced copy-editor? (I've nothing against either 10-year-olds or Koreans, they're just two actual examples I've come across recently). We should be encouraging the competent and discouraging the incompetent. -- Boing! said Zebedee (talk) 12:28, 15 March 2012 (UTC)
  • Oppose, per my comments above. UltraExactZZ Said ~ Did 02:13, 12 March 2012 (UTC)
  • Oppose - This proposal seems to suggest that: All Wikipedians are equal, but some Wikipedians are more equal than others... Um, no, per many well-explained examples/reasons above. As for edit counting, Peter (Southwood) (and others) said it well and clear enough. - jc37 02:33, 12 March 2012‎ (UTC)
  • Fascinating proposal. Of course, if it were implemented, I expect more than one admin would make 500,000 or so script-assisted minor edits to a userspace draft in short order so they could continue to block whomever they like. 28bytes (talk) 05:24, 12 March 2012 (UTC)
  • Oppose. Basically, I see this as a proposal from Malleus, who has been blocked 17 times so far, that 70% of the admin corps be disqualified from blocking him. WhatamIdoing (talk) 03:31, 13 March 2012 (UTC)
    You would do well to open your mind. Even ArbCom has recently admitted that an unspecifed number of those blocks were improper. Malleus Fatuorum 03:51, 13 March 2012 (UTC)
    It's a rather telling feature of the inequity here that bad blocks remain in the victim's block log, but there's no record in the blocking admin's log. Malleus Fatuorum 04:57, 13 March 2012 (UTC)
    It doesn't really matter if a few of them were improper. Most editors have a perfectly clean block log, and even if fully of half your blocks were truly improper, then you'd still be on the list of people who have a far longer block log than average. As a result, your proposal still smells like an editor who's been blocked a lot of times trying to cut down on the number of admins who could block him. If that's not your goal, of course, then feel free to propose that we do this and that you personally be subject to blocking by any admin regardless of edit count. WhatamIdoing (talk) 19:11, 13 March 2012 (UTC)
    I reckon preventing 70% of admins from blocking Malleus would be of significant benefit to the project. -- Boing! said Zebedee (talk) 12:17, 15 March 2012 (UTC)
    That it clearly doesn't matter to you WhatamIdoing however many of those blocks were improper I think speaks volumes for your lack of integrity. Malleus Fatuorum 02:36, 20 March 2012 (UTC)
  • Oppose. That's a most odd proposal. "Edit count" means precisely nothing. I propose that administrators ought not to be allowed to block content editors until they have themselves made at least 25 per cent of the content contribution that their victim has made (whatever that means). Anyway it is an abysmally stupid system we have here, making "admins" out of all sorts of odd people with no clue about adding value to an encyclopedia, and then allowing them to run roughshod over the people who do contribute. The whole mess has ceased to be a joke, and is now mired in unmovable muck. It's a waste of time trying to shift it. --Epipelagic (talk) 04:17, 13 March 2012 (UTC)
  • Oppose Since a minimum edit count at RfA has been rejected by the community a fair few times, is this not just a way of bringing up the same issue? As it happens, I do support a prerequisite for adminship, but after a certain point as a few people have said edit count means very little. I'm not going to say that there are no bolshy admins, but sorting out a community de-sysop should be the focus there. Taking myself as an example (as arrogant as that sounds), I have about 10,000 edits, but I've been around, know policies very well, know my limitations and have a level head on me. I have never blocked an established editor, but the idea that I should be able to block someone with 35,000 edits, but not someone with 45,000 seems like madness. WormTT · (talk) 08:56, 13 March 2012 (UTC)
  • Oppose - editcountitis. RJFJR (talk) 14:39, 13 March 2012 (UTC)
  • Support in principal even if its unlikely to be considered feasible. At least. In my experience I've seen some admins who have contributed frankly nothing to the project in terms of content blocking some of our great content contributors who've done 1000 times the amount of work that they have with a weak blocking rationale. And when I've seen it happen its usually when the veteran is in the middle of doing constructive work or plans on improving the content of wikipedia and the admin hampers them from doing so for the sake of playing cop and saying "I'm more powerful than you are". When that happens, it strikes me as out of place in the same way it would the Grade 7 pupil placing his 60 year science teacher in detention. I'm not saying that some blocks aren't justified but to me the rookies blocking the content contributing veterans illustrates one of the main problems with RFA. Although the problem is edit count as such is not really an effective measure of one's constructive contributions, articles created, however, or good articles would be.Oh and All Wikipedians are equal, but some Wikipedians are more equal than others. That's very true and if you can't admit that that's what goes on in the running of wikipedia... Unfortunately it is wiki lawyering for being "more equal than others" which qualifies, not content contribution. I also believe content contributors with years of experience should be given the authority to overide ips or newbies during moments of edit conflicts and trusted to do so. ♦ Dr. Blofeld 15:19, 13 March 2012 (UTC)
  • Oppose Under this proposal there are only 8 editors who I wouldn't be "qualified" to block, and a large proportion of admins wouldn't be qualified to block me. Yet a large proportion of my edits are minor and flagged as such. I don't dispute that blocking of experienced members of the community needs to be done with great sensitivity, but I'm not convinced that this is the right proposal to improve the quality of such admin decisions. Perhaps we should upbundle a few things from admins to crats, starting with civility blocks. ϢereSpielChequers 15:28, 13 March 2012 (UTC)
  • I can see the point behind the general idea, but this particular implementation would have all sorts of problems. Chief amongst them is the use of edit count as a metric. Should minor edits be valued equally to major ones? Is someone who takes ten edits to do what others manage in one, thereby massively increasing his/her edit count, a better contributor than those who use preview more conscienciously? What about assessing quality of edits? I just don't see raw edit count with no analysis as a secure enough basis to judge this on. Then there's the issue of strict cutoff points. The range of editors that a particular admin wouldn't be allowed to block would in some cases change frequently over fairly short time intervals, especially where two editors edit at different times of day. The most likely outcome would probably be that the class of power-hungry admins who I'm assuming this proposal is mostly targeted at would just make a lot of semi-automated edits to increase the number of editors they can block, which probably wouldn't be a good thing. Call this a weak oppose of this precise proposal. Alzarian16 (talk) 01:03, 14 March 2012 (UTC)

Oppose Not that I have any desire to do this (I'd probably leave it to someone else anyway) but where would that leave admins like me with less than 10,000 edits? If necessary and if I thought it was worth the headaches it would bring me for days afterwords I don't think I would be incapable of making a good block of someone with a high edit count. Ks0stm (T•C•G•E) 17:17, 14 March 2012 (UTC)

Upon reading my comment further I should probably clarify. My issue with this proposal isn't necessarily how I would fare as an admin under the proposal, more that edit count doesn't equate with the ability or lack thereof to make well-reasoned, policy based blocks, and that includes of established users. I for one would take much more time and would be much more hesitant to block a very established editor, not doing so without double and triple checking the facts, my rationale, and what effects it would likely have, and in some ways this means any block I were to make of a very established user might very well be one of the more thought out blocks I would make; this is pretty much because I would have such a low edit count compared to the more established user I would be blocking. All in all, in my opinion, edit count differences should not preclude admins from making well-reasoned, policy based blocks of any user, including established users. Ks0stm (T•C•G•E) 17:44, 14 March 2012 (UTC)
  • Possibly Illegal under current US law. There are some Wikipedia editors who are handicapped and can only edit with a mouthstick or a device that scrolls letters by to be selected with a mouth puff. These editors are physically incapable of making a large number of edits. Any policy that discriminates against editors based upon quantity of edits rather than quality of edits could be argued as being a violation of the Disabilities Act. --Guy Macon (talk) 12:18, 15 March 2012 (UTC)
    That's a pretty bizarre interpretation of US law, let's hope that you're not a lawyer. On the other hand, the US has so many more lawyers than any other country on Earth that I suppose they have to have something to argue about, to keep them busy. So long as someone else is paying, of course. Malleus Fatuorum 03:49, 21 March 2012 (UTC)
  • Oppose as privileging editors who make many small edits in series rather than using preview and making multiple edits (or, as I often do, creating whole articles ([6],[7],[8],[9],etc.)) in a single edit. The number of edits made says little about the quality of the contributions, only the quantity. (And at #309 on WP:MOSTEDITS, I'd still be able to block all but the top 15 editors so this !vote is not about concern for my own personal ability to block an experienced editor run amok.) - Dravecky (talk) 13:20, 15 March 2012 (UTC)
  • Oppose, "long-term editors" should never be granted special treatment of any type. Being a good editor is already far too much of a license for abuse, and that problem needs to be fixed, not made worse. If anything, longer-term editors should be held to a higher behavioral standard than others—they know the rules, so when they're breaking them, they're doing so intentionally. Seraphimblade Talk to me 17:56, 15 March 2012 (UTC)
  • Oppose. Sensible admins have almost no incentives to block useful editors, and non-sensible admins would have perverse incentives to boost their edit count artificially. The problem of non-sensible admins blocking non-sensible but useful editors inappropriately needs the solution "knock heads together", not anything in the way of silly metrics as is being suggested here. Charles Matthews (talk) 19:02, 15 March 2012 (UTC)
  • Oppose'. If anything, it should be easier to block problem users, and there are plenty of avenues to appeal a block and plenty of administrators willing to unblock. This would only further entrench long-term problem users. (For the record my comments don't refer to anyone in this discussion or under discussion here.) Gamaliel (talk) 21:39, 15 March 2012 (UTC)
  • Oppose A high edit edit count is not a meaningful basis for protecting an editor from a block by an admin with less than 1/4 as many edits. Some editors boost their edit count by a profusion of small edits: add a comma, remove it, add a phrase, move it somewhere else, move it back. Or they chit-chat endless on other editor's talk pages. Or they chime in on every ANI issue or AFD with off-topic or repetitious comments. Or they ask silly trollish questions or make make silly joke responses to questions at Ref Desk. Or they generate thousands of low-value stub article new articles by basically robotically copying from some public-domain book they found online. Someone who hits the "Save" button a lot is not always someone who should be above the law, or who should be blockable only by some admin of similar editing habits. Edison (talk) 04:39, 16 March 2012 (UTC)
  • Wikipedia:Don't feed the divas. Malleus, quit trolling. Fences&Windows 21:20, 19 March 2012 (UTC)
    Quit accusing me of trolling asshole. Malleus Fatuorum 21:29, 19 March 2012 (UTC)
    The lack of a comma in your sentence insinuates something else entirely. Killiondude (talk) 21:43, 19 March 2012 (UTC) 👍 Logan likes this.
    Only to an American. Malleus Fatuorum 00:41, 20 March 2012 (UTC)
    Reminds me of that Lynne Truss/Robert Sutton book, Eats Shoots and Assholes. 28bytes (talk) 02:49, 20 March 2012 (UTC)
I agree with what Edison says to an extent about the edit count not always being reflective of quality article and article work but I have experienced some situations where editors who have contributed practically nothing to the encyclopedia itself with tools who seem to relish blocking some of the heavy contributors who are not admins because they can do so. That is a problem and in certain situations, especially when it is a veteran editor with years of experience edit conflicting with a newbie, I believe the well established editor's perception on what or what is not appropriate for the article should be taken into consideration. I believe a lot of ANI reports would be avoided if veteran editors who are not necessarily admins at least have some element of trust in them to deal with content issues and stop what they believe is causing disruption to content.♦ Dr. Blofeld 21:39, 19 March 2012 (UTC)
  • Oppose- What a silly proposal. I'm no authoritarian, but this is just plain stupid. This would cause even more disruption because it would encourage troublesome editors to dig themselves in by making a whole bunch of rapid crap edits. Reyk YO! 06:08, 21 March 2012 (UTC)

Counter proposal

Established editors may not be blocked in non-emergency situations without prior discussion.

Ok, so we need to decide what an established editor is, but blocking an editor with more than a few thousand edits is something we should take more care over. If we put this mark at 10,000 edits, we're only talking about 5,000 editors, all of whom should know better. We can put in some safeguards if you like, 3RR, Sockpuppets etc. but I'm talking about the general case. WormTT · (talk) 08:56, 13 March 2012 (UTC)


Surely there must be other ways of restricting what administrators can do other than basing this on edit count? My fear is that such a proposal would encourage Wikipedia: Editcountitis. How about making it necessary for more than one editor to be called in for a discussion to decide whether an editor can be blocked? ACEOREVIVED (talk) 15:37, 13 March 2012 (UTC)

Bear in mind, that surely the main reason for blocking edits from users is that they have made a lot of rather stupid edits which would be counted as Wikipedia: Vandalism, which put up their edit count. As some said above, we should be basing decisions such as this on edit quality, not edit quantity. A lot of edits which are examples of Wikipedia: Vandalism would inflate some one's edit count. ACEOREVIVED (talk) 15:39, 13 March 2012 (UTC)

I doubt if we have many vandals who get near enough edits to get immunity under this proposal before they get blocked. Copyvio, plagiarism and running unauthorised bots on their main account, yes that all happens. But when did we last encounter an account committing vandalism after more than a thousand edits? ϢereSpielChequers 15:47, 13 March 2012 (UTC)
The only ways I've seen that happen is when someone wants to stop themselves ever coming back. Support Counter proposal. A vandal who makes a thousand, five thousand, ten-thousand edits before starting to vandalise happens basically never. They're much more likely to become a positive contributor on the way. Remember, we do have reformed vandals.--Gilderien Talk|Contribs 21:07, 13 March 2012 (UTC)
Support this matches well the spirit of consensus and seems free from problems of original proposal. Audriusa (talk) 15:13, 14 March 2012 (UTC)

Counter proposal II - upgrade block/unblock longstanding editors to crats

It is rare that longstanding editors get blocked or unblocked. Amongst our most active editors the two most common types of blocks are admins accidentally blocking themselves and admins accidentally blocking others. We could safely upbundle blocks and unblocks of logged in editors with more than 1,000 edits to our crats without causing them an excess workload, and it would certainly prevent some mistakes. This would mean that established editors could relax about RFA and not feel threatened by admins, at the same time it might reduce our problems at RFA. We do have a shortage of RFA candidates and are far too dependent on a very small number of very active admins, particularly at AIV and RFPP. Upbundling one of the most contentious parts of the admin toolkit makes sense to me, and should be quite easy for the devs to code. NB I'm assuming that this would work on a per account basis, so having half a dozen accounts with a couple of hundred edits each would not reach the 1,000 threshold. ϢereSpielChequers 16:01, 13 March 2012 (UTC)

  • And it's not that rare that longstanding editors get blocked or unblocked. All this talk about edit counts made me curious, so I took a look at my admin log. Turns out the last 14 accounts I blocked had edit counts of 158176, 318300, 260, 1, 3, 5, 5243, 6664, 19, 2, 3737, 191, 499 and 125630. 28bytes (talk) 16:43, 13 March 2012 (UTC)
I doubt if I've ever blocked someone with a thousand edits. Such blocks are probably not even a daily event, so I doubt that our current crats would be stretched by them. If they were then very few extra crats would be needed to cover the load. ϢereSpielChequers 16:53, 13 March 2012 (UTC)
If you'll excuse the sweeping generalization, any admin who's never blocked anyone with 1,000 edits probably tends to stay away from ANI drama. In my experience, plenty of established users do get blocked, but you wouldn't know it if you just patrol AIV etc. That's not a judgment -- I try to keep my distance from drama these days too. Equazcion (talk) 17:27, 13 Mar 2012 (UTC)
  • The issue at hand is not so much with the ability of admins to block established editors, as if they do so for no reason. The issue is with established editors who might edit in ways that deserve a block, relying on their knowledge that someone will step in to unblock them if they do get blocked. The title of the thread ("get away with") already seems to establish a sort of bias about the contents. In general, it is not the admins who are "getting away with" things when these circumstances arise. — Carl (CBM · talk) 17:21, 13 March 2012 (UTC)
    • On the other hand, if only crats were able to reverse blocks that were made by crats, then allowing only crats to perform these blocks might provide some net benefit. The main issue is not really with the blocking, it's with blocking followed immediately by unblocking. The difficulty, of course, is that crats tend to be quite conservative and might always think there is "no consensus". So I still have far to go to be convinced, I'm afraid. — Carl (CBM · talk) 17:43, 13 March 2012 (UTC)
      • That's a key part of the proposal. Yes there will be a little more caution in blocking people and maybe some vested contributors will get warnings instead of blocks. But when a vested contributor is blocked then I'd be surprised if it didn't stick until either the block expired or the blocked editor agreed to make the requested change in their editing behaviour. ϢereSpielChequers 18:43, 13 March 2012 (UTC)
  • Oppose per editcountitis. --SarekOfVulcan (talk) 19:00, 13 March 2012 (UTC)
  • Oppose. The underlying issue with restricting the block ability remains. Ironholds (talk) 21:48, 19 March 2012 (UTC)

Comment

All of these proposals really dance around the issue at hand: some editors feel that admins either have too much authority, or abuse said authority on a regular basis.

A single policy won't fix this. There's no overall measure that can assure an admin's competency, nor can we "protect" an editor from an improper block. Any hard rule will both make it more difficult for admins to block actual violators, and cause even more drama when an WP:IAR situation arises.

This is an issue of trust, and some editors will not trust admins in any capacity. Others want to give admins free reign. I think most of us fall in the middle. Regardless, this isn't something that can be fixed in a policy. However, maybe we can come to an agreement on what to do when it becomes clear someone was blocked improperly. (Reaching that conclusion is a whole 'nother ball game.) A desysop isn't necessarily the first thing that should be done, but at least some form of process to follow might help alleviate some of the concerns.

Note: I personally believe this is more something that needs to be done on a case-by-case basis, as it's an infrequent problem IMO. Given the timespan of this debate, though, it might be worthwhile to see if we can come up with a process of dealing with such issues. — The Hand That Feeds You:Bite 18:23, 13 March 2012 (UTC)

The ironic part of the proposal is that admins have essentially no authority when it comes to blocking established editors, because some other admin will always come along and unblock the established editor. So in fact even a well-deserved block of an established editor is hard to keep in effect, much less an ill-advised one. Admins don't "get away" with anything under the current system, although it could be argued that some established editors do. — Carl (CBM · talk) 19:05, 13 March 2012 (UTC)
I'm basically with CBM: These proposals are based on the idea that some editors are so incredibly valuable that they shouldn't be subject to the same rules as everyone else. They want a special set of rules for the power users (usually called "experienced editors" or some such phrase), and then the regular rules for all those unimportant plebians.
And beyond the (IMO) inappropriateness of this, the proposals are poorly thought out. For example, these proposals would have prevented Guerillero from blocking Betacommand at ArbCom's direction last month.
NB that I oppose this, even though it could theoretically benefit me. Malleus, who started this discussion, could only be blocked by 30% of the admin corps, but if his proposal was approved, only 12% of it could block me, and less than 1% could block Rich Farmbrough. WhatamIdoing (talk) 19:41, 13 March 2012 (UTC)
I agree with both of you, actually. The current proposals are really just duct-tape over the actual issue at hand, which is mistrust of Admins. And there's very little we can do to assuage that.
However, putting in an actual guideline for what process to follow when you disagree with an admin action might be beneficial. Right now, it basically involves running straight to AN/I or ArbCom, which just tends to exacerbate things. As you say, CBM, established editors already get a lot more leeway, because Admins recognize their contributions to the 'pedia. Right now, though, if someone thinks they got a raw deal, there's no real process in place for them to act on. WP:DR isn't quite the right one for that, but dumping it on AN/I doesn't seem productive in most cases. — The Hand That Feeds You:Bite 12:09, 14 March 2012 (UTC)

Isn't it about time to end this discussion here? Obviously as a proposal it isn't flying. As a complaint it has much interest, and I hope another venue can be found for discussing it. Jim.henderson (talk) 13:24, 15 March 2012 (UTC)

  • Oppose This is not necessary--if an admin exercises good judgement, then it should stay irrespective of edit count. If he doesn't, then it shouldn't. I don't understand why this needs to exist... —Justin (koavf)❤T☮C☺M☯ 19:55, 15 March 2012 (UTC)

Archive this?

I think this is one of those discussions that could go on forever if allowed, since it's so stupid that everyone who sees it feels they need to come comment on how stupid it is (I was admittedly one of them). There's clearly a consensus for rejection here and it's been up for nearly two weeks. Can we archive it? Equazcion(talk) 06:51, 21 Mar 2012 (UTC)

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

Allow watchlisting of Special:Contributions/[User] pages

Rd232 (talk · contribs) wrote at Wikipedia:Administrators' noticeboard/Requests for closure:

Added a note about the discussion (which despite some opposition, appears to have consensus) to Bugzilla:470, which has been open since... 2004. Worth observing that the recent discussion led to the creation of a toolserver prototype (see archived discussion), and of course the same functionality is possible via RSS, since every user's contributions list is spat out into its own Atom feed - see WP:Syndication. Rd232 talk 16:59, 12 May 2012 (UTC)

Cunard (talk) 06:24, 13 May 2012 (UTC)

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

Sub-proposals:


[edit=Quintucket (talk) 00:07, 27 January 2012 (UTC)]
I notice that every objection centers around the idea that it would make it easier to stalk users. So I'd like to point out two counter-points which have been brought up in the comments:

  1. It's easy to wikistalk a single user. What this proposal would do is allow the watchlisting of a lot of users, which isn't a tool wikistalkers need. They already have what they need, which
  2. There's no need to allow watchlisting of registered users. Logged-in vandals are generally dealt with in a timely manner; it's mostly the IP vandals who slip under the radar. [/edit]

I'm surprised this isn't on perennial proposals, but the upside is it means I get to suggest it without (I hope) looking like a total ignorant. I've noticed that the vast majority of anti-vandalism efforts are given either by Cluebot, or with an automated tool like Huggle or Twinkle, which apparently allow first-level warnings. This means that persistent vandals will get a lot of warnings, and often get "final" warnings followed a month later by more first-level automated warnings only. But the users with earlier final warnings in the last year or so I can at least report at AIV. Even more problematic are the users who rack up a large number of first, second, and occasionally third-level warnings, but never get to a final edit. (I generally give users who fit this criteria a third or fourth level warning in line with the total warnings they've accumulated in the past year. I'm not sure this is fully Kosher, but I feel it's completely warranted.)

So I try to check recent changes manually and find these persistent users, and watchlist any pages they've vandalized. This isn't exactly the best way to go about it, and I rarely catch new changes by these vandals, but I don't know if it's because they stop (unlikely in many cases), or because they move on to other pages. But if I could watchlist Special:Contributions pages directly, it would let me follow those persistent vandals without keeping them in a text file (which I've thought about, but I'm lazy, and I've already got quite a large non-vandal to-do list in another file).

While I know this would require software updates, I'm hoping that enough people would appreciate this feature that it can gain the consensus to suggest at Bugzilla. --Quintucket (talk) 10:50, 26 January 2012 (UTC)

WP:STALK. I don't think I can agree that this would be beneficial, however useful. --Izno (talk) 13:20, 26 January 2012 (UTC)
  • Oppose: While I acknowledge the advantage of watchlisting vandals but this will have much adverse affects on the constructive contributors who regularly get hounded or stalked. --lTopGunl (talk) 13:29, 26 January 2012 (UTC)
  • (edit conflict)Yes, with what Izno points out, and the substantial changes needed to software (I think) to "subscribe" to specific versions of what is a virtual "Special" page, I can't see this gaining much traction. There are so many "stalking" concerns it would be bound to open up, and truly, I share some of them. I think you're stuck with another way of doing this if you need to do it legitimately. Begoon talk 13:35, 26 January 2012 (UTC)
  • Oppose (reluctantly) Whilst I've often experienced the very same frustration as Quintucket, and have regularly (daily, even) thought how useful this feature would be, stalking vandals' edits shows a failure to assume good faith. We have to assume that they won't reoffend once warned - even if they almost invariably do. Yunshui 雲‍水
    • I don't think I follow the reasoning here. By this logic, we also shouldn't watchlist or protect any commonly vandalised articles, AGF they won't be vandalized again. That's really the exact reason why we would want to watchlist recurring vandals, for the very likely case they will again. —  HELLKNOWZ  ▎TALK 14:16, 26 January 2012 (UTC)
      • We can also remember something that Jimbo pointed out: "our social policies are not a suicide pact." I always try to assume good faith whenever there's any doubt, even with users who add anti-Semitic comments to articles (this is a real example, I tried to reach out to the user). But some vandalism is pretty damn obvious, like adding nonsense or spam. When you see a user who has a long history of vandalism, it's pretty clear that the vandalism will continue until the IP is reassigned or the user grow up.
On the other hand, if a user has a history of non-constructive edits, even if they seems to be in good faith, it runs up against competence is required. I've seen many users who persistently add biased or verifiably inaccurate information despite warnings to stop, and I assume that they genuinely believe they're improving the encyclopedia. When I see these users, I try to add text to whatever template I'm using (this is another reason I refuse to use scripts). These users in particular it makes sense to monitor, because they can become genuine Wikipedians. (I'm a minor case-in-point; my 2004-2005 contribs tended to reflect an anti-Boston bias that I've now outgrown.) Is it better to have Huggle users templating them until a non-script-using user gets fed up and reports them, resulting in a block, or users who can monitor them and attempt to talk to them? --Quintucket (talk) 17:02, 26 January 2012 (UTC)
  • Weak oppose. There are very many vandals from different IPs/usernames and some recurring individuals could use an oversight. But I don't think the ability to follow their edits arbitrarily outweighs the enabled misuse of the feature for WP:STALKing. I might consider this if users/IPs were "watchlist-tagged" by sysops. But this does sounds a little WP:SHEDy. —  HELLKNOWZ  ▎TALK 14:16, 26 January 2012 (UTC)
    • Support after reading other arguments. Stalking is probably not as big of a deal, and stalkers already stalk contributions, this will only make it marginally easier. On the other hand, this is very useful for rarely-editing users/IPs so every one doesn't need to be checked manually. Although I'd like for there to be a way to be excluded from this in cases of obvious stalking. Or some other kind of restriction. —  HELLKNOWZ  ▎TALK 17:44, 12 February 2012 (UTC)
  • We can implement this feature for IP contributions only to indeed avoid stalking. Then it will make sense for static IP with recurring vandalism issues.--Ymblanter (talk) 14:32, 26 January 2012 (UTC)
    • Really? I think you first need to establish that an IP editor is less entitled to protection from "stalking" than a registered (still possibly anonymous) username. Begoon talk 14:38, 26 January 2012 (UTC)
      Well, this is obviously an issue for discussion, but did not the community decide to have higher level of protection from IPs by for instance restricting them to be unable to create new articles? I am not sure the community would support the idea, but I do not think it should be outright rejected as being in contradiction to the five pillars.--Ymblanter (talk) 15:00, 26 January 2012 (UTC)
How about sysops being able to tag only the vandals who can then be watchlisted or monitored through RSS feeds? --lTopGunl (talk) 15:02, 26 January 2012 (UTC)
If they are vandals, why aren't they already blocked? --Jayron32 15:13, 26 January 2012 (UTC)
Because we are talking about recurring IPs. They may be blocked for 6 months, then return after two more months and start vandalizing articles until caught and re-blocked. This could facilitate catching them on time.--Ymblanter (talk) 15:35, 26 January 2012 (UTC)
Aren't we getting a bit close to being back in HELLKNOWZ's WP:SHED, by now, though? Begoon talk 16:36, 26 January 2012 (UTC)
RSS feeds are already available for everybody about everybody! I'm already stalking some person by this! mabdul 22:15, 21 March 2012 (UTC)
  • Without regard to the supposed moral hazard this presents, I'm not sure that this is technically feasible using the way that watchlists work. Actual "pages" in Wikipedia consist of text which is only changed when someone changes it; the text itself is stored in the database, which is why it can be watchlisted. "Special" pages do NOT consist of existing text, the "special" pages simply pull info from a database and the page is generated on the fly; there's nothing for one to "watchlist" because the things the watchlist looks for (changes to stored text) don't exist in "special" pages. I don't think this is implementable easily. I suppose it could be kludged by the devs, but it isn't something as easy as flipping a switch. --Jayron32 14:46, 26 January 2012 (UTC)
That's why I observed that it might be difficult. However page-protection already shows up in watchlists, and then there's the watchlist itself. It would seem to be a relatively simple matter of transcluding (not the right word, I know), any new user contributions to the Special:Watchlist page, as they would appear on the Special:Contributions page. --Quintucket (talk) 17:07, 26 January 2012 (UTC)
I support the principle here, and know of times myself it would have been useful, but also am worried about the potential for abuse in the form of stalking and hounding. Maybe it could say only work on newbies with >50/25 edits, or something along those lines. Could also be useful for adopters and mentorers to track their adoptee/mentoree easily. I'm not sure if this could be technically implemented though. Acather96 (talk) 16:44, 26 January 2012 (UTC)
  • In response to some of the comments I've seen above: I think I agree that if created, this should only apply to IPs. One thing I've noticed is that admins seem to apply a lower standard to blocking usernames than blocking IPs (usually on the pretext of WP:EDITWAR, whether the 3RR is violated or not), presumably on the principle that it could affect more people than just the vandal. And it seems to me that the vast majority of persistent registered vandals are spammers, who can be safely indef-blocked, while most IP vandals seem to have no such external agenda.
The other point I'd like to make is that I've seen a number of cases where problematic IP edits have gone unnoticed for months or even years, and I'm sure there's more we've all missed. All it takes is for a bot or user to revert vandalism by one IP but not the one that preceded it, or for a user to make another edit that hides the edit from most watchlists. (I doubt that the vast majority of recent changes get patrolled by a human user, even one using a script.) Usually these are blatantly POV statements or factual inaccuracies (often inserted in front of an already cited source), which while not technically vandalism, though these users will often have edit histories that contain genuine vandalism. Presumably if users who reverted the obvious vandalism were able these users, these seemingly valid edits would be subject to stricter scrutiny. --Quintucket (talk) 17:22, 26 January 2012 (UTC)
  • Comment: I am more than a little puzzled by the fears expressed here about people misusing the capability proposed. On the one hand, there is nothing to prevent anyone from looking at the contributions of a given Wikipedia user at any time so this will hardly be opening up some kind of Pandora's box. On the other hand, I recall that there is some javascript that can be added to a userpage to do exactly this (a search of common tools would probably find it, although I can't be bothered). (On a slightly different note, "stalking" is a serious form of personal harassment which is often criminal - looking at what someone edits on Wikipedia is not stalking by any reasonable definition and the overuse of the word does a disservice to victims of real-life stalking.) Delicious carbuncle (talk) 17:55, 26 January 2012 (UTC)
  • Support the idea, although its implementation might not be doable inside the current Special:Watchlist functionality. I don't find arguments about the dangers of stalking to be at all compelling. Stalkers already have a single page where they can see all of their target's contributions, so it's merely a matter of convenience. Stalkers are obsessive and they're already stalking without this tool, so this proposal would only change things for actual vandal fighters who don't watch vandals as closely as they might if it were easier to do so. — Bility (talk) 18:01, 26 January 2012 (UTC)
  • I have thought of this too, and here is a perfect example of an IP where this would be needed: User:173.168.93.7. This editor has put in guerilla vandalism across dozens of articles before getting noticed and having the vandalism removed. The editor was blocked 5 times, and as soon as the block is over, the exact same type of vandalism starts again. Now, if we had this tool, I would easily see when this person started editing again, and check to see if they were up the same same shenagins, and perhaps nip the issue in the bud before too many articles were disrupted. Currently, I'd literally have to mark a calender to check the IP once the block is lifted. Angryapathy (talk) 18:41, 26 January 2012 (UTC)
  • Comment I watchlist the user pages of some vandal IPs, and when I see Cluebot, et al., leave additional warnings I'll double check to see if they have committed enough vandalism to warrant a block.   Will Beback  talk  20:11, 26 January 2012 (UTC)
  • Oppose I can appreciate where the nominator is coming from, but suspect that this will create problems - particularly an increase in unconstructive wikistalking - more than it will bring benefit.--JayJasper (talk) 20:20, 26 January 2012 (UTC)
As another user noted above, stalking users is already possible through the Special:Contributions page. It's also possible to watch vandals the same way, of course. The difference is that fighting vandals effectively requires the monitoring of many pages, while stalking a user requires the monitoring of only one or two. Also, as noted, there's no reason to allow watchlisting of logged-in users. The actions of logged-in users already tend to be subject to stricter scrutiny, I think in part because they're easier to recognize than an IP number, and in part because blocking a user will only affect that user, whereas blocking a vandal may affect other users. --Quintucket (talk) 23:27, 26 January 2012 (UTC)
  • Support as a userright - Mentors may find it useful, but its potential for abuse requires it to be a restricted function. Jasper Deng (talk) 06:42, 28 January 2012 (UTC)
  • I actually made a userscript that did this years ago - it would take any user pages on your watchlist, then put those names into the wikipedia api, get out their recent contributions then display the results in a formatted list. Unfortunately the api then changed significantly and I haven't had the chance to rewrite the script accordingly. I understand the concerns that people could get stalked - I don't know how big a problem it is but surely the solution to that would be to either restrict access to contributions pages (which is never going to happen) or to just make people more aware that anything they post on here is public, and hence to avoid posting anything they later regret. Even if people here aren't keen on a feature like this, it's perfectly possible for third party websites to implement this sort of thing. Tra (Talk) 17:54, 28 January 2012 (UTC)
  • I like the idea, but am concerned that it might be abused for WP:HOUNDing. On the other hand, I've done it myself on occasion with nothing more complicated than a simple bookmark. WhatamIdoing (talk) 21:28, 28 January 2012 (UTC)
  • That's my workaround as well -- I make bunches of bookmarks of potential problem-user contribs (typically new user names that remind me of banned users, or historically troublesome IPs, things like that) and then periodically open them all in tabs. Easy to do, requires no software update. Antandrus (talk) 04:24, 29 January 2012 (UTC)
  • User contributions can be pseudo-watchlisted through RSS feeds - eg this. It's slightly clumsy (you have to use an RSS reader) but it does work (and it can scale as a long-term solution for mostly-inactive users). Shimgray | talk | 12:03, 29 January 2012 (UTC)
  • Support the idea although I don't think it will be implemented any time soon: devs discussed this since 2004 in mediazilla:470. In another project I'm currently using my userscript similar to Tra's above but utilizing browser localStorage. — AlexSm 22:34, 30 January 2012 (UTC)
  • Strong support – Enough with the "stalking" crap. Stalkers don't need extra tools to stalk—they are already stalking just fine. (By the way has anyone actually looked at WP:STALK recently?) This is a feature that I have wished for for a long time, and it would be extremely useful. Currently I have a list of a few users and IPs that I try and check up on every so often, but it's pretty difficult without a feature such as this. It seems more like something that would be on the toolserver at least initially, since the toolserver is where most hacked up tools like this go, but this would be a very useful feature to be integrated into MediaWiki. It also fits with the ideology here of openness and usability. I was just thinking of this recently and how it would be similar to the concept of Linux filesystems, where everything, including devices, act as a file and can be addressed as such (procfs, device files, etc.) The watchlist is not a "page" in and of itself; it's more of a "virtual page", so any action performed with/on it that treats it like a "regular" page will involve some type of abstraction layer. We already have crosswiki contributions tools (here is one) on the toolserver which compile contributions from multiple wikis into a single page. I'm a little surprised that watchlisting of contributions has not already been implemented, as it is simply one of the next logical steps in the ideology of how improvements to the usefulness and usability of Wikipedia/MediaWiki are made, and it also fits very well with the open source software mindset as a whole. The idea of having such a feature be limited to being used by or used on specific users is preposterous. Everyone's contributions are already public; it does not make an ounce of sense to make a feature with takes public information and makes it more useful in a way that anyone could do themselves manually or with a script and then make that feature a restricted or private feature. There is no reason to add extra complication to a feature just because it is new when every other similar feature is publicly available and unrestricted. —danhash (talk) 18:17, 31 January 2012 (UTC)
  • Support. The benefits of being able to watch for frequent vandals far outweigh any supposed danger of facilitating Wikistalking, and if we really want to prevent users from abusing this feature, why not give it only to autoconfirmed users in good standing? ZZArch talk to me 22:46, 31 January 2012 (UTC)
  • Oppose - It's not good to trace a user's edits. I think it will be approach more to Wikihounding than patroling. ●Mehran Debate● 09:45, 5 February 2012 (UTC)
    • The contributions feature has been and will be available. Your opposition is to the entire idea of tracking contributions, which the community and the software already support. Your comment is not about the proposed feature and is therefore not relevant. —danhash (talk) 15:37, 7 February 2012 (UTC)
  • Support for both IPs and registered users. It's not uncommon for warned users to "lay low" after receiving a warning, and return to vandalizing a few months later. There are several occasions on which I've failed to follow up on users after giving them a "I will block you if this behavior continues" warning because it's too much trouble. In the past I tried adding links to users' contributions to my user page for my own convenience - I'm not sure if making the list of watched users public encourages or discourages hounding, is this a good idea? If the devs aren't amenable to it, I might consider implementing a Toolserver tool for this, which would be quite simple and probably isn't against the privacy policy. Dcoetzee 22:10, 5 February 2012 (UTC)
  • Support I would use this for the students in the classes for which I am an online ambassador. Then I can provide more timely assistance when they actually edit. There already is somthing for this on the tool server, but it is pretty locked down so that it takes a while to get new stuff in. I don't mind if it is a userright or available to everyone, the information is there already, it makes it quicker to access. Graeme Bartlett (talk) 01:44, 6 February 2012 (UTC)
  • Support - it's already possible to follow a user's contributions, this proposal would only make it slightly easier to do so. I think the concerns about 'wikistalking' are outweighed by the potential benefits of keeping an eye on vandals and other problematic users. Robofish (talk) 17:29, 12 February 2012 (UTC)
  • Oppose It will nearly be flooding a user's watchlist if the user whose contributions are being looked upon edits too frequently. Dipankan In the woods? 15:44, 16 February 2012 (UTC)
  • Support' I'd certainly find this useful in fighting vandalism. We can deal with stalkers, that's not a good reason not to make this tool available, particularly if it is a userright that we can grant or withdraw rather than a default. Dougweller (talk) 09:57, 21 February 2012 (UTC)
  • Comment: Not that I think this tool would enable more stalking, but perhaps if its implementation were very transparent it would help assuage some of these concerns. If the users/IPs being watched were visible on one of the monitoring user's subpages, anyone could see who they're watching and stalking can be easily identified. Likewise the addition of a "Who is watching me" link in the toolbox would be helpful for quickly finding everyone who has you watchlisted. Since it hasn't been created yet we can make a wishlist for the development of the tool, right? — Bility (talk) 14:49, 21 February 2012 (UTC)
  • Support. I'm surprised nobody has pointed out that such a tool would likely improve collaboration? WikiProject members, for example, would probably like to know "what everyone else is up to", because it might be fun to join in and help out. Wikipedia is all about collaboration, right?! Mlm42 (talk) 22:08, 21 February 2012 (UTC)
  • Support The marginal increase in convenience to wiki-stalkers–nothing unless they are stalking multiple users–is worth the potential for fostering collaboration, as Mlm42 points out, and for adoptors and mentors monitoring the edits of their charges. I wish this sort of option had been easily available when I did more adopting. Danger High voltage! 01:44, 24 February 2012 (UTC)
    Ah, and I didn't even think of the wonders of being able to watchlist the contributions of corporate/institutional accounts that appear to be abandoned to make sure that they stay abandoned. That would be super for work at WP:UAA. Danger High voltage! 07:30, 24 February 2012 (UTC)
  • Support. This would come in very handy in several ways. One common scenario is a newly-created account that vandalizes a couple of articles, is warned, then stops... for a while. Being able to add their contributions to your watchlist and getting a heads up when and if they resume editing would be extremely helpful. Another case is for long-term IP blocks; it'd be nice to see, when the block expires, whether it served its purpose or another block is needed. The advantages of such a feature far outweigh any downsides, in my view. 28bytes (talk) 02:31, 24 February 2012 (UTC)
  • Support My initial concerns are minor compared to the good reasons given for support. Begoon talk 02:43, 24 February 2012 (UTC)
  • Support. I've often wished we had this. Would be really useful keeping an eye on persistent spammers, whose edits are often not spotted for long periods. I agree that it might be best as a userright that could be withdrawn if an editor is found guilty of hounding/stalking. Not necessary to be a userright, wouldn't be as useful for stalkers as standard Special:Contributions is already.  ⊃°HotCrocodile…… + 02:46, 24 February 2012 (UTC)
  • Support - I have wished for this feature and think it would significantly improve our ability to locate and control vandalism. Some ideas for addressing concerns of abuse, if we need that to achieve consensus, (my support is not contingent on any of these):
    • make it an assigned userright (per Jasper Deng),
    • automatically expire watches after N (30?) days,
    • restrict watching to a limited subset of accounts, e.g. accounts with recent level 4 warnings and recently expired blocks.
Jojalozzo 03:45, 24 February 2012 (UTC)
Any Wikipedian wishing to make such a list can easily do so. (Here is a link to Special:Contributions/Wavelength.)
—Wavelength (talk) 17:53, 24 February 2012 (UTC) and 19:53, 24 February 2012 (UTC)
  • Support. I think that this has become a very interesting discussion. My first reaction had been to oppose out of concerns about hounding, but I've been won over by how useful this could be, both for monitoring problem users and for collaborative projects. I like the ideas of making it a user-right assigned, on request, by administrators, and of having a "who watches here" link available, as two ways of combating misuse. --Tryptofish (talk) 20:32, 26 February 2012 (UTC)
  • Oppose Yes, I agree it would assist in tracking problem users. With that said, what about the editors in good standing. Why should they be subject to unnecessary stalking? The potential negativity of this greatly outweighs the potential benefits. Alpha_Quadrant (talk) 20:55, 26 February 2012 (UTC)
    • It's been my observation that stalky types tend to focus on a small handful of editors, often just one or two. They can easily do that now by bookmarking the contributions pages of their targets; are you concerned that these people will expand their stalking to more editors with this feature? 28bytes (talk) 00:34, 27 February 2012 (UTC)
      • I believe it could be possible such a feature would increase stalking problems. Right now, in order to stalk an editor, you have to look up their contributions page. Most editors don't constantly stalk another user's contributions. Additionally, you really can only stalk one person at a time. Even if you used multiple tabs, you wouldn't be able to look through several editor's contributions at once. Adding a feature to the watchlist, allowing someone to bulk watch editors, makes stalking extremely convenient. While it might be useful for watching vandals, it would be highly prone to abuse. Particularly during heated content disputes, making it more likely for a dispute to spill out into multiple articles. Alpha_Quadrant (talk) 00:58, 27 February 2012 (UTC)
        • It could be abused, I agree. I'd hate to lose a useful feature just because people might abuse it, though; there's a case on AN/I right now where action is being tabled because the editor has stopped editing (for now, at least). I would be really helpful to know (without having to remember to check their contribs manually every few days) when they're resumed editing so the issues with their editing can be addressed. 28bytes (talk) 01:26, 27 February 2012 (UTC)
          • I often track multiple users in multiple tabs, while doing other things totally unrelated to Wikipedia, without breaking a sweat. It is already not at all hard to "stalk" multiple people, and this feature would have many very useful legitimate uses. —danhash (talk) 20:58, 28 February 2012 (UTC)
  • Support per 28bytes. Eagles 24/7 (C) 04:43, 27 February 2012 (UTC)
  • Support as a useful tool to monitor for trouble; suggestions for restriction to IPs are misguided, as plenty of vandalism comes from user accounts, and spammers, COIs, SPAs use accounts too. An ability to only show all fresh edits would be very helpful. Extending this convenience to all editors will have a dramatic net good. Josh Parris 03:03, 28 February 2012 (UTC)
  • Support I already use externals tools to do this, not least to follow what people I collaborate with on certain projects are doing, so I can assist, and avoid duplication of effort; the proposal would make life much easier. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:36, 28 February 2012 (UTC)
  • Support; a tool like this could be quite useful. Personally, a lot of the areas I work in involve editors who aren't outright vandals or perfect editors, but somewhere in the grey area inbeweeen, and a tool like this would be helpful (though I already use a certain offsite tool, that's not a perfect solution). For instance, dealing with educational projects (lots of new student editors).
  • Support I really don't see the stalking concerns. I've seen a few vandals start editing dozens of pages as soon as they are off their block before being blocked again. If this tool was available, anybody who reported that user could immediately see when the edits start and check if they are indeed vandalism. At worst, it would prevent editors from having to check dozens of edits in this case. At best, it could prevent guerilla vandalism from staying on pages when no one notices it. Angryapathy (talk) 17:17, 8 March 2012 (UTC)
  • Support. Increases effective openness and accountability within WP. Vague concerns about "wiki-stalking" are unconvincing--editing here is not a private act, and any abuses should be handled after the fact, in the normal WP fashion. --Hobbes Goodyear (talk) 02:58, 10 March 2012 (UTC)
  • Support. Very useful for vandalism response and at the same time this tool would also allow to help new editors out. No violation of AGF here - at that point then we should stop Huggle highlighting contribs from warned users. Should not really limit to any user group, it would just create another status for no real reason: anybody can check other user's contributions already. --Mark91it's my world 13:30, 12 March 2012 (UTC)
  • Support but ONLY for IPs and redlinked accounts. (Easy way for a registered user to not have this work on them: edit their user page.) I also agree that this should be a userright handed out like rollback. (Wikihounding concerns don't seem enough to prevent this tool, but I think they are enough to prevent widespread access.) And further, admins should be given a userright to view who may be watching someone's contributions, for transparency. - jc37 23:15, 13 March 2012 (UTC)
  • Support, RSS is already available! mabdul 22:15, 21 March 2012 (UTC)

Proposal for Toolserver prototype

One way to try out this feature before asking the devs to do it, and get much earlier feedback on how useful it is and how to refine it, is to implement a Toolserver tool where you log in (with TUSC or a separate account) and add users to your user watchlist. For the sake of transparency these user watchlists would be public, and you would be able to easily check who is watching a particular user. Just like the normal article watchlist, edits would be shown in reverse order by date/time, and only the most recent edit by each user would be shown (with a link to their full contributions on-wiki). To make it easier to use, a custom Javascript tool could be built to add to user pages a link reading "add this user to my watchlist". I plan to do this and it shouldn't take very long, but would like to get feedback about the design and features. Dcoetzee 19:44, 24 February 2012 (UTC)

That would be great, although I see no need for watchlists to be public. Users could take offense thinking that they are being accused of vandalism or sockpuppetry. But really it's just not necessary. As has been stated, a tool such as this would not add any new information, simply make available information more usable. No use to make lists of watched users public for people to complain about and start asking to be removed from. —danhash (talk) 19:49, 24 February 2012 (UTC)
Well, a number of the supporters above noted it could also be used for collaboration, for Wikipedia in the classroom, for helping newbies, or even a mentor who they follow to learn from, so I think it would be erroneous for people to infer anything from being on someone's list. A notice to that effect could be included. However, such a feature would have actual uses beyond mere transparency (for example, checking whether someone is already watching a vandal, so you can avoid cluttering your own watchlist with them). Dcoetzee 20:04, 24 February 2012 (UTC)
  • This does seem like something best done off-wiki, at least for now. But if it ever does come on-wiki, it should be done "by permission only," sort of like "Friends" on social networking sites. Privileged users such as administrators would be able to bypass this provided it was logged. davidwr/(talk)/(contribs)/(e-mail) 21:01, 24 February 2012 (UTC)
    • There is no benefit of the extra complexity and overhead it would take to implement and support such a permission system. People who want to abuse Wikipedia will do so with or without this feature. Even if this tool was used for stalking/harassment it would likely just make it easier to find such users (their contributions could obviously also be watched). —danhash (talk) 20:53, 28 February 2012 (UTC)
  • Added note: I've been considering renaming this to "Followed users" and allow you to "Follow/unfollow" a user. The intention is to make it sound a bit less sinister (e.g. "we are watching you") and suggest a similarity with other websites where following just lets you check out what other people are up to (as in "following your progress"). I know this is a small detail but let me know if you disagree. Dcoetzee 00:50, 25 February 2012 (UTC)
Follow/Unfollow is a bit facebooky. Watch/unwatch is probably the most neutral. Another possibility would be stalk/unstalk, but that brings a negative connotation. "Track" might also work. Alpha_Quadrant (talk) 00:32, 9 March 2012 (UTC)
Well I already went ahead with followed users, but on reflection tracked is probably a bit better. I think current name is okay though. Dcoetzee 00:30, 11 March 2012 (UTC)

Shared watchlists and collaboration

Prototype tool now available

See http://toolserver.org/~dcoetzee/followedusers/. It requires a TUSC login, but provides a link to set one up if you don't already have one. Please try it out and let me know what you think! There is also now a Javascript extension at User:Dcoetzee/Followed_users.js you can add to place "Follow user/Unfollow user" in your toolbox and add "Followed users" to the upper-right. Please help spread the word about the tool so lots of people can try it out and help test it out! Dcoetzee 12:17, 25 February 2012 (UTC)

Any reason why the tool doesn't allow the following of IPs?  ⊃°HotCrocodile…… + 03:07, 26 February 2012 (UTC)
No, I just forgot to implement that. :-) I've updated it and it now allows following of IPs. Dcoetzee 03:14, 26 February 2012 (UTC)

Upon request only

To avoid abuse, access should only be granted upon a request that will have to be approved by an administrator.

  • Support as nom. PaoloNapolitano 20:20, 26 February 2012 (UTC)
  • Oppose. Ideas of the feature being abused are pure speculation at this point. If someone wants to harass a particular user by following their contributions, it's straightforward to do that today using Special:Contributions. Anyone could reproduce the tool in a couple hours using the public Mediawiki API, and they will if they're denied access to it (and give it to all their friends). The proposal would require a request and approval process that would involve considerable overhead. Any barrier to using it will result in less people using it, and it producing less benefit. I think a better strategy in the short-term is to simply ask me to ban users who are abusing the tool. Since the lists of followed users are public, you can tell if this is happening. Dcoetzee 02:16, 27 February 2012 (UTC)
  • Support Liam987 16:00, 27 February 2012 (UTC)
  • Strong oppose as nonsense. Not a single credible argument has been made demonstrating the need for this feature to be limited any more than Special:Contributions is limited (which it isn't). There is no way to keep anyone from making an external tool to do this either, since the entirety of this feature request is based on totally public information. So adding this as a MediaWiki feature and then limiting it will not have the intended effect anyway. Also, it would add completely unneeded complexity and overhead to make it a per-user permission and have a request process. It's simply a bad idea. —danhash (talk) 20:37, 28 February 2012 (UTC)
  • Support as I was earlier going to make the same point. Glad to see that there's a section. Aslbsl (talk) 20:42, 28 February 2012 (UTC)
  • Comment – People should give actual reasons why they think the added complexity of a user right is warranted. The number of votes is irrelevant; it's the quality of the arguments that matters. So far I have not seen a single good argument for making this a user right, and furthermore it doesn't much matter at this point since it is not currently an available feature of the software. Therefore, what would be helpful is a discussion based on reason and argument, not simply on the number of supporters. —danhash (talk) 17:46, 29 February 2012 (UTC)
  • Comment I believe people didn't flesh out their rationale here because it synthesizes discussions already made above, i.e. administrator approval is the remedy for avoiding abuse people mention above. Aslbsl (talk) 18:44, 29 February 2012 (UTC)
  • My point, though, is that nobody has given any real argument for the necessity of an admin approval process. Everyone just cries "potential for abuse", like that in itself is any kind of worthy argument at all. Look at rollback: there is an admin approval process for getting rollback, but Twinkle, which anybody can use, has a rollback feature as well. Any user losing his rollback priveleges can still rollback i.e. the approval process is more or less useless. Is regular rollback easier than Twinkle rollback? Slightly, yes. But there is no way to stop someone from using rollback or undo or opening a previous version of a page, clicking edit, then clicking save. The point being that there are numerous ways to do what is essentially rollback without going through the approval process, or even if one loses their approval. The same is true for this feature. It is already possible to do exactly what this tool just makes it a little easier to do. I have pointed this out more than once and as yet nobody has given any actual counter-argument, which gives even more credence to the viewpoint that the "potential for abuse" arguments given so far are not well founded. —danhash (talk) 15:19, 1 March 2012 (UTC)
  • I hear what you're saying. My response, though, would be to point out, that despite rollback being accessible in other forms to non-admins, there is still an idea that rollback itself should be an admin privilege. So to here, just because there are ways to accomplish the same task without privileges, doesn't automatically mean that limiting it to sysops is moot. It may be debatable whether any admin rights that are mirrored by other functions need be privileges only granted to some, but that's a different question. Aslbsl (talk) 12:16, 2 March 2012 (UTC)
  • Adminship, generally, is not a big deal anyway. I know that may be a contentious issue, but people wanting to weigh in on this particular discussion need to give actual reasons, not just "support" or "oppose". Votes of opposition mean nothing without actual arguments behind them; I don't know how many times that needs to be said. There are still, as far as I can tell, no good, actual reasons given so far for making this proposed feature limited by a user right. —danhash (talk) 22:21, 2 March 2012 (UTC)
  • Comment I strongly recommend trying out Dcoetzee's prototype tool. From my use of it, I conclude that a similar on-wiki tool would be a pretty poor tool for stalkers. Only showing editors' last edits cannot be as useful to stalkers as Special:Contributions already is as it shows all edits by their target. I have already found the prototype tool very useful (caught the first edit/vandalism from a vandal just released from a block. Reverted and reported to AIV, result is an extended block, probably saving lots of further warnings before reblocking.  ⊃°HotCrocodile…… + 04:03, 3 March 2012 (UTC)
  • Support as a right granted in a fashion similar to rollback. I would characterize rejection of this proposal as comparable to gun laws -- more detrimental to people who would use it legitimately than to those who would abuse it. Stalking is already very easy for those who want to do it, and is a silly reason to eschew the benefits this tool could have for vandal fighters. I used to use Tra's script tool a long time ago, back when it worked, and found it very useful for keeping an eye on known vandals who were smart enough to spread out their edits. Equazcion (talk) 14:30, 12 Mar 2012 (UTC)
Comment – But why does this feature need to be a user right? You have not given any argument for why you think abuse will be a problem more than with other features. —danhash (talk) 16:26, 19 March 2012 (UTC)
  • Support Whether we like it or not, this has potential problems written all over it. Better to start this way, at least for now. I remember the discussions about the implementation of rollback, and how there were those who said that that should not be a separate userright. I don't see much of a difference in argument here. - jc37 23:15, 13 March 2012 (UTC)
Comment – What potential problems does it have that are so serious as to necessitate the overhead and complexity of a user right? If you have an argument regarding the implementation of this feature, it should be listed here, even if similar arguments have been made before about rollback. I was not involved in the discussion about the implementation of non-admin rollback, but a big difference immediately comes to mind between this feature and rollback: the rollback feature adds a link that in one click instantly causes an action, an action which can sometimes be used in edit wars and disruption; this proposed feature is totally different in that it simply gives people information they already have access to in a more convenient way, and in a way that is quite likely to help deal with vandalism and disruption. —danhash (talk) 16:26, 19 March 2012 (UTC)

Solutions for controlling abuse

Because I realise many participants are concerned about the possibility of the followed users tool being abused, as demonstrated by the discussion above, I'd like to open a broader discussion on solutions to this problem. I've spoken to many people about this and collected a number of very different solutions with different advantages and disadvantages. I'd like to get additional suggestions and preferences. I believe a careful discussion of the issue, and gathering of evidence, should precede a straw poll (per meta:Polls are evil).

  • Proposal: An administrator must first approve any user before they can use the tool.
    • Advantages: Low potential for abuse.
    • Disadvantages: High overhead; barrier to use leading to less use; unclear evaluation criteria.
  • Proposal: Users who abuse the tool are banned from using it; any administrator can be given the ability to do so; misuse can be detected because followed user lists are public.
    • Advantages: Addresses a problem only where one exists.
    • Disadvantages: The damage may already be done before the abuse is discovered; users may stop following others to cover their tracks. (should log and publicise all follow/unfollow actions?)
  • Proposal: Permission-only system: non-administrators may only follow other users with their permission.
    • Advantages: Effectively prevents abuse in most cases.
    • Disadvantages: Prevents non-admins from using the tool in anti-vandal activities. Giving permission may confuse newbies in mentor relationships. Adds overhead and delays.
  • Proposal: Allow following of IPs only, or users with very few edits only.
    • Advantages: Would prevent abusive following of most long-term users.
    • Disadvantages: Prevents collaborative uses such as mentor/mentee, or following collaborators on Wikiprojects.
  • Proposal: Give only to users with rollback.
    • Advantages: Users with rollback already have some degree of community trust.
    • Disadvantages: Rollback is evaluated according to different criteria, and may not be given to users who don't participate in antivandal but want followed users for collaboration.
  • Proposal: Create a new user right for it, which is not given initially but then given by an admin.
    • Advantages: Low potential for abuse; can be given based on criteria specific to this tool; easy to add/remove on-wiki.
    • Disadvantages: Requires config changes to Wikipedia; high process overhead; barrier to use leading to low use; unclear evaluation criteria.
  • Proposal: A delay is built in where new edits are not made visible for some number of hours.
    • Advantages: Prevents "pouncing" on new edits made by established users.
    • Disadvantages: Prevents rapid response to vandal activity, or prompt replies to discussion.

Various combinations of these may also be appropriate. Thoughts? Dcoetzee 23:27, 2 March 2012 (UTC)

There is no good reason for any of these proposals. Not a single person has given a single good reason on this page for why this shouldn't be a fully available built-in feature if it is implemented. I can respond point-by-point to each one of these proposals, but this shouldn't really be necessary as nobody has given any reasonable, substantive argument for the limiting of this feature, and I have already responded so several of these proposals elsewhere in this discussion. I do not understand what people are afraid of. There are already so many processes in place for dealing with abuse. The "potential for abuse" arguments given so far are useless as they demonstrate no more potential for abuse than other long-accepted core features. There is no need for any of these proposals and not a single person has demonstrated otherwise. —danhash (talk) 14:49, 5 March 2012 (UTC)
I agree with that - in fact I'm not sure exactly what abuse people have in mind other than a vague uneasiness about "stalking". I'm hoping that this set of proposed solutions will at least provoke thought about exactly what the issue is so we can get a clearer explanation. I do believe certain measures - such as logging all follow/unfollow actions, and allowing any admin to block/unblock a user from using the tool - are perfectly reasonable. Dcoetzee 19:15, 5 March 2012 (UTC)
Every action on Wikipedia is already logged, and admins are already able to block/unblock users based on their actions. If a user is abusing Wikipedia (any part of Wikipedia) for harassment purposes, they are already able to be blocked. Why add more complexity? If a user cannot keep themselves from abusing this or any other tool or feature of Wikipedia for harassment or other policy-breaching purposes, they can be blocked. There is nothing wrong with any user following any other users' contributions. The problem comes in what that users' actions are; if a user harasses another user based on stalking their contributions (using this or any other tool), they can be blocked for harassment without any extra complexity of permissions needing to be added to this tool. Why not log every time a user checks a contributions page and give admins the ability to block users from viewing contributions pages? Contributions are public for a reason, and logs of viewed contributions pages are private for a reason. There is no need to add extra complexity simply because it may be easy from a technological perspective. —danhash (talk) 19:30, 5 March 2012 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page, such as the current discussion page. No further edits should be made to this discussion.

List of Internet phenomena

I noticed that several pages on the List of Internet phenomena do not have links to their own articles, while others do. Now don't get me wrong, I'm not the kind of guy who would request a Wikipedia article on every single tree, root, and blade of grass, (I'm not sure if I completely know the phrase) but these pages, in my opinion, (and I think that soon we will get the opinions of other fellow Wikipedians), should be redirects to their sections in List of Internet phenomena. Anyone support me?

--Walex03. Talking, working, friending. 00:47, 21 March 2012 (UTC)

You'd have to challenge each article one by one. If a discrete phenomena article meets notability then it is legitimate for the article to remain as is. There are many list pages that shell out into discrete articles. So no, no support from me for a blanket "should redirect to the list page". --Tagishsimon (talk) 00:55, 21 March 2012 (UTC)
(edit conflict) I support the addition of any article which meets our criteria for inclusion. If the articles not linked from the article you mentioned don't exist, and they meet our criteria, then I support their creation. If someone wants to create redirects for the items in the meantime, until the articles get created (if they do), and the redirects meet our criteria, then I support that too. Anyone who doesn't want to (or can't) create the articles themselves can, of course, use Wikipedia:Articles for Creation. I don't, however, really see what the "proposal" is here. All of these actions are standard, and possible already. Sorry if you meant something else, but if so, I'm afraid I don't understand. Begoon talk 01:00, 21 March 2012 (UTC)
Well, no, what you should be doing (or what the community should be doing), is analysing whether that article needs to be pruned. Some phenomena come and go, others remain. It's not for Wiki to record everything that gets posted on Reddit. Frankly, making geeks feel good about themselves is not how the project should continue. I'd be happy to cull almost everything in that article; we're not supposed to be a directory service, after all. doktorb wordsdeeds 02:37, 21 March 2012 (UTC)
That's also a very fair point. I was trying to avoid the details of the article and respond in general, because I don't think this is the right place to discuss a specific article, but, in the context, yes, we are not a directory of internet memes, and, while they should be subject to the same sourcing and notability requirements as any other content, there are additional considerations, obviously. There do seem to be a number of doubtful entries in that list - which are certainly not things that are "memes" as I understand the term, in the sense of their not being in any way pervasive. I'll offer one thought that may or may not be useful - when judging these items for inclusion, notability, verifiability etc. are not, in themselves enough. The criterion which are being used to define something to be a "meme" are obviously crucial, and maybe some entries have not been subjected rigorously enough to that "test" - merely being notable and verifiable isn't enough. That's a discussion for the Article talk page, though. Begoon talk 03:15, 21 March 2012 (UTC)

By the way, would a more appropriate place to discuss this one than here be at the the talk page of List of Internet phenomena? Incidentally, I wonder whether the phrase that the initiator of this proposal was seeking was "paraphernalia". ACEOREVIVED (talk) 09:08, 21 March 2012 (UTC)

Yes, sorry, I should have been more clear - I linked my post now. Begoon talk 09:25, 21 March 2012 (UTC)

Time for new logo and default skin change

Wikipedia is in danger of growing stale. We need to take it in a new direction. NUMBER ONE) I propose we redesign the Wikipeia globe logo. The new logo should be of at best questionable improvement upon the current logo but should be rendered in full 4D. A panel of international editors should be formed and each letter nominated for inclusion should undergo a thorough review process. It shall be possible to find no fewer than 10 mistakes in the final set of letters. The new logo shall be colorful because color monitors and printers have now been developed since the last logo was made. NUMBER TWO) The Vector skin has started to feel soooo 2009. I propose we create a new skin that feels more modern and relies even more heavily upon recently introduced CSS elements. Almost the entire browser market now properly supports the CSS used in Vector and interactive elements are almost acceptably fast. Clearly, we are lagging behind. It's time to push Wikipedia into the next decade. Been too long since change occurred. who's with me? Jason Quinn (talk) 03:10, 21 March 2012 (UTC)

--Cybercobra (talk) 03:45, 21 March 2012 (UTC)

@Yair rand. Thanks for the heads up on this. Didn't know. I'm in the middle of watching the video conference about it. I was quite annoyed to hear it said that the future of the desktop is dead. So many projects seem to be taking this literally. At some level this "prophesy" will be self-fulfilling if vendors and organizations simply stop developing for the desktop and cause users to leave. This "let's bet the farm on mobile" type thinking is dangerous. Look at KDE 4 and GNOME 3, those are both projects where it is obvious that mobile and tablet-orientated thinking caused them to derail. I worry that mobile fever has infected the WMF. That said, I'm kind of liking Harris' design. I'll be anxious to see more. A good user interface tends to transfer from one platform to another with only minor tweaking. Maybe Harris' design your design (!) whoever's design will work well on the desktop too. We'll see. Jason Quinn (talk) 18:28, 21 March 2012 (UTC)
Um, what? It's not my design... --Yair rand (talk) 00:43, 22 March 2012 (UTC)
Sorry. I noticed your Athena Prototype while watching the video. I hastily edited the message thinking I had made a faux pas under the false assumption thinking you had something to do with it. I quickly realized I was in error again but got distracted and forgot to come back and fix the remark. Probably the work of many people, I guess, but maybe Harris is main designer. Don't know. Sorry for the confusion. Jason Quinn (talk) 00:50, 22 March 2012 (UTC)
The logo I can agree on, everything else no. Logos and identity have moved on a lot, things are much more streamlined and minimalist. So if there's going to be another year-long vote/debate/argument about the logo, count me in doktorb wordsdeeds 18:49, 21 March 2012 (UTC)

Maintain a shortcut for User pages and User talk pages

Hi. I have been thinking of this for quite a few days. Why not maintain a shortcut for User and User talk pages? User talk pages should begin with UT:USERNAME, and user pages with UE:USERNAME. Dipankan says.. ("Be bold and edit!") 05:48, 21 March 2012 (UTC)

Why UE? — Isarra (talk) 06:51, 21 March 2012 (UTC)
See also Wikipedia:Perennial proposals#Create shortcut namespace aliases for various namespaces. —  HELLKNOWZ  ▎TALK 08:51, 21 March 2012 (UTC)
UT has been proposed and shot down before. Check the archives. I too wish we had UT. --Cybercobra (talk) 08:52, 21 March 2012 (UTC)
User pages should begin with UE as US:USERNAME makes me feel of a user coming from US and such. Dipankan says.. ("Be bold and edit!") 10:34, 21 March 2012 (UTC)

UT might be useful, I agree. UE only saves 2 characters, which is not worth the trouble, in my opinion - I'm still a bit confused about the 'E' too… However, as HELLKNOWZ points out, this is in the Wikipedia:Perennial proposals which means it's been proposed and discussed several times before. That doesn't mean you can't propose it again, but it does mean you should check what the previous objections were, and preferably include rebuttals for the common objections in the proposal, so that the same objections don't need to be debated again. Begoon talk 10:48, 21 March 2012 (UTC)

Create an option to allow people to suggest a change

I don't know if this is the right place to submit this but I think it would be beneficial to add some way for people to submit a suggestion to change something. There is already a process for people to submit an article but not an individual change and I think this could be very useful. — Preceding unsigned comment added by 138.162.8.58 (talk) 18:59, 21 March 2012 (UTC)

You could either do it on your own; or you could suggest a change at the talk page of the article! mabdul 21:04, 21 March 2012 (UTC)
This is the encyclopedia that anyone can edit, in most cases, by clicking the "edit" tab at the top of the article or section you want to change. In some cases, however, you will find yourself unable to edit an article, since it may have been protected. In this case, do what Mabdul suggested and request a change on the article talk page, which you should be able to edit with no problem. dci | TALK 02:47, 22 March 2012 (UTC)
@138.162, You can use {{Request edit}} to request a change to an article you don't want to edit. You can use {{Edit protected}} to request a change to a protected article. Both of these are used on the article's talk page. 64.40.61.74 (talk) 10:35, 22 March 2012 (UTC)
Also, you can use the Wikipedia:Article Feedback Tool which contains the functionality requested (currently in testing, so it's not yet available at all pages). Diego (talk) 10:46, 22 March 2012 (UTC)

User scripts cleanup project

The user scripts listing page at Wikipedia:WikiProject User scripts/Scripts is in dire need of cleanup. To facilitate this, I created a new draft listing at Wikipedia:WikiProject User scripts/Scripts cleanup. All are invited to list scripts known to be currently working and relevant. If/when the list seems reasonably complete, we can deprecate the old listing and move this one in (though keeping and linking to the old one as a more exhaustive list of all existing scripts). Please share any thoughts on this. Thanks. Equazcion (talk) 00:35, 25 Mar 2012 (UTC)

Wikipedia official skype account

Hello,

Can we create an official wikipedia skype account ?

Pro:

- audio conference

- discuss, interact

- wikiprojects coordination

- task force coordination --Tegra3 (talk) 05:36, 24 March 2012 (UTC)

Nope. Prodego talk 05:38, 24 March 2012 (UTC)

When we added the "V • T • E" links to the {{navbar}} template, we broke a cardinal rule of interface design: Only show interface elements to the people who need them. For the vast majority of Wikipedia readers, the mysterious "V • T • E" letters in the corner of every navbox are nothing more than confusing clutter. Not only that, but the links also display incorrectly on some browsers and versions of MediaWiki due to how they are implemented.[11][12] We don't display such editor-centric links on other templates, so I think we can live without them in navboxes as well. What I would like to do is remove the links from the {{navbar}} template and instead create a gadget that adds the "V • T • E" links to navboxes for the people that really want them. That way editors can still have the links, but we don't have to confuse our readers with them. Thoughts? Kaldari (talk) 21:21, 24 March 2012 (UTC)

Since everybody (whether or not they have an account, or they are logged on) is a potential editor, then everybody needs to see the VTE links - otherwise, how can people edit the template or talk pages?Nigel Ish (talk) 21:43, 24 March 2012 (UTC)
The same way they edit every other template and talk page. Kaldari (talk) 22:02, 24 March 2012 (UTC)
IPs do edit navboxes, so I think there is merit for those links. It certainly is easier to get to navboxes' markup this way. —  HELLKNOWZ  ▎TALK 21:45, 24 March 2012 (UTC)
Removing the links and adding a gadget to re-add them sounds like a solution in search of a problem. The links are helpful for inexperienced editors to find and edit the templates, and the clutter is minimal. Hiding them on the mobile version might be fine (but there may be some technical hurdles that need working out first). --CapitalR (talk) 21:53, 24 March 2012 (UTC)
Sure, if they happen to guess that "E" is a link to edit the template. So maybe half of people who want to edit the template would actually use the links, and the percentage of people who want to edit the template is maybe 0.001% of the people who read the article. So for half of 0.001% of our users, it is useful, for everyone else it's just mysterious clutter. Kaldari (talk) 22:02, 24 March 2012 (UTC)
Eh, by those stats, we could also get rid of section 'edit' links and especially interwiki links. I have no idea what most of the languages are by looking at them, so perhaps we should get rid of all interwikis and use a gadget to re-add them for those who want a particular language? And very few people actually use a particular section edit link compared to how many read the article, but they're still useful to have. More seriously though, I think the benefit of the VTE links outweighs the cost (access vs. 'clutter'), and it's not hard to find out what they do (click or mouse over). And when a user does click or mouse over one, they can see how easy it is to access and edit such pages. --CapitalR (talk) 22:25, 24 March 2012 (UTC)
This is just food for thought, but maybe hide them from IP editors, and let them display by default to registered users (no gadget required)? Navboxes are UI elements, rather than article content or discussion that should be considered as part of the "anyone can edit" principle applied elsewhere. Just throwing that out there, I'd be interested to hear why or why not, though I can predict some of the responses. Equazcion (talk) 22:01, 24 Mar 2012 (UTC)
(Coming here from Template talk:Navbar#Getting rid of the V T E links, which has the question We don't include edit links in other templates like infoboxes, so why do we have them in navboxes?): The main reason for having v-t-e links in navboxes is because navboxes are virtually always in a separate template, and they provide the means for accessing that template's talk page or for editing it. There are rarely v-t-e links in infoboxes because the infobox is almost always in the page itself, so you use the normal edit links for the page.
Regarding if they happen to guess that "E" is a link to edit the template - the {{navbar}} template generates tooltips "View this template", "Discuss this template" and "Edit this template" shown when you mouseover the links. --Redrose64 (talk) 22:36, 24 March 2012 (UTC)
It's precisely because they aren't contained in the current page that I'm thinking there's reason to consider this (not inviting navbox edits from "just anyone"). It's relatively easy to make a mistake, intentional disruption, or controversial change affecting lots of articles. And those changes won't be detected as easily, since generally they won't be showing up in watchlists for people who edit articles where they're transcluded. Relatively few people actually have navboxes watchlisted, and the rest would need to catch errors visually. Equazcion (talk) 22:46, 24 Mar 2012 (UTC)
What your proposing would have the same effect as semi-protecting the whole of template space, with the downside that experienced vandals can circumvent it easily by going to the template page directly. We already protect way too many templates because they are "high risk", I would definitely oppose something like this. Yoenit (talk) 15:08, 25 March 2012 (UTC)
This proposal relies on two flawed assumptions: That all non registered people are not interested in editing, and that all non registered people don't understand how the templates work. Both are obviously incorrect. There are many non-registered editors who make use of the ability to edit templates (eg: {{Colorado Avalanche roster}}). I see this proposal as a solution that lacks a problem. Resolute 15:41, 25 March 2012 (UTC)
I concur with Resolute, this is the encyclopedia that anybody can edit. We already discriminate against anonymous users enough, no need to take it further, especially given there's no pressing reason to do so. Snowolf How can I help? 19:16, 25 March 2012 (UTC)
I likewise oppose. I occasionally edit templates when logged out (when on public computers, and I don't have the time to log into my account for use on public computers), and removing these links would make it rather inconvenient. In reality, this proposal is backward: if we remove the links from anyone, it would be better to remove them for logged-in users, since they're more likely to know how to find the template page before editing it, while non-logged-in people are more likely to be unable to find the template and consequently be confused why they see a big box when the code is simply {{template}}. Nyttend (talk) 14:43, 26 March 2012 (UTC)
Retrieved from "http://en.wiki.x.io/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_86&oldid=1131476132"