Wikipedia:Village pump (proposals)/Archive 86

Source: Wikipedia, the free encyclopedia.

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)
  • Comment  We don't allow editors to revise old revisions, why do we allow software to revise revisions?  Unscintillating (talk) 18:47, 18 February 2012 (UTC)
  • Support  I think that this is possible and practical, by adding a time parameter to the picture-retrieving subroutine.  Unscintillating (talk) 18:47, 18 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)

  • Support - I like the idea; it will make the important notices clearer and more comprehensible. ItsZippy (talkcontributions) 21:02, 14 February 2012 (UTC)
  • Comment You're missing the reference to foundation:Terms of use that is required by Wikimedia (see meta:Licensing update/Implementation#Terms for edit screen). And I fail to see how either of the above gigantic boxes are more consolidated than what we have now. I'd oppose this, except that I hide the whole mess with my user CSS anyway so I wouldn't see it. Anomie 02:55, 15 February 2012 (UTC)
    • Actually, "both the CC-BY-SA 3.0 license and the GFDL" is linked to that. Wouldn't that be enough? ViperSnake151  Talk  13:37, 15 February 2012 (UTC)
      • Oh, it's an easter egg link. It seems to me that "CC-BY-SA 3.0" and "GFDL" should instead link to the texts of those licenses, and a link with the text "Terms of use" should link to the terms of use. Anomie 15:43, 16 February 2012 (UTC)
  • Support and add "not forum" point for talk pages. --lTopGunl (talk) 11:44, 15 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.

talk) —Preceding undated
comment added 05:17, 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".
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)
  • 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)
  • I proposed that in the past and it was rejected but I still support.--Fuhghettaboutit (talk) 14:09, 16 February 2012 (UTC)
  • Agree, partially: If there is one of two things we can try: a simple prompt to encourage edit summaries with emphasis on what an edit summary is; or, a simple indicator of an edit's length, such as we now have with the indication of words added/removed in the diff.--Djathinkimacowboy 14:53, 16 February 2012 (UTC)
  • Oppose per Fuhgettaboutit. - Purplewowies (talk) 21:26, 22 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: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
.
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 (talkcontribs)

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 ) 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)
  • Comment: Hi ACEOREVIVED, it goes without saying that talk is used to settle disputes, improve the article, etc. However, sometimes it goes... well, way beyond. Please check out talk:Gustave Whitehead... is that what you're trying to engender? Best, Markvs88 (talk) 15:24, 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)
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 (talkcontributions) 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)
  • Support - Marcus Qwertyus supports the removal of this redundancy.
    Qwertyus
    03:09, 10 March 2012 (UTC)

Request for comment: Adoption of new unblock appeals tool

Hello, all; an RFC has been opened at

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)

"My contributions" link for anonymous IP editors

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. --
(ʞ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)

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 (talkcontributions
    ) 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. Begoontalk 04:23, 21 February 2012 (UTC)
  • Support at Special:SpecialPages but oppose on every page. Most unregistered visitors are only readers and many would be confused by a link for edits made by "their" IP address. In most cases there will be no edits anyway, but checking this and only displaying the link if there are edits would probably be too expensive. PrimeHunter (talk) 04:33, 21 February 2012 (UTC)
    Logout and type Special:MyContributions into the search bar. IPs already have this page. I don't think it would be that difficult for the devs to work something out so that it only displays for IPs with actual edits. Alpha_Quadrant (talk) 04:39, 21 February 2012 (UTC)
    That's an interesting idea, to make the link visible only if the IP has edits. Another idea would be to have Special:Contributions default to have the username field pre-filled with the username or IP address as appropriate. 66.159.220.134 (talk) 23:06, 21 February 2012 (UTC)
    I doubt devs will add any "conditional" link because of caching issues, for the same reason mw:Manual:$wgShowIPinHeader is disabled here (I think you can see the result of that option here: http://wikitech.wikimedia.org/view/Main_Page in the right top corner). — AlexSm 02:40, 22 February 2012 (UTC)
  • Strong support. This is a simple matter of making an existing, useful feature more accessible to users who edit while logged out. Being able to review their own edits allows new users to reflect on their work, learn from their experiences, and grow as an editor. Even registered users usually have some edits they made before registration that they would like to review, but if they can't figure out how, they won't be able to learn from it. It shouldn't be interpreted as endorsing editing while logged out. Dcoetzee 20:34, 23 February 2012 (UTC)
  • Support. It seems pretty uncontroversial to make a link that's already available from the search bar a little more accessible. 28bytes (talk) 02:54, 24 February 2012 (UTC)
  • The easiest way to find your "My contributions" link is to get this warning. Sole Soul (talk) 05:57, 29 February 2012 (UTC)
  • Support per Alpha Quadrant
    Nobody Ent
    11:51, 1 March 2012 (UTC)
  • Just add to Special:SpecialPages, no need for any new UI features such as a tab, since the UI is cluttered enough already (or at most, "meh"). Adding to Special:SpecialPages seems to satisfy the original proposer who first asked for the feature. I've been editing from IP addresses for ages and have never had trouble using Special:MyContributions and I don't see any comments from anyone in this thread saying they have ever personally had such a problem. 67.117.145.9 (talk) 04:09, 4 March 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: should be made accessible ... more preferably alongside the "login/create account" option. --lTopGunl (talk) 13:14, 10 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.

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. --
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. --
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)
  • What about using PersonData from interwikis? We could just steal the values from other wikis. Josh Parris 11:43, 28 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
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)

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

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 ) 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
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)
  • Would be really nice if that could be installed and enabled by default for admins.Jasper Deng (talk) 00:24, 13 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 (talkcontribs)

Of course there's an API. It's available at <https://en.wikipedia.org/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,
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)

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. Begoontalk
    10:57, 8 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 (talkcontribs) 15:12, 14 March 2012‎

There's a card game in development - 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

, 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
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 (talkcontributions) 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 (talkcontributions) 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.
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.
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.wikipedia.org/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.wikipedia.org 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-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 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: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 {{

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.
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.wikipedia.org/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.wikipedia.org/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/

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 – )
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
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" (
(ʞ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.

Fatuorum
01:14, 10 March 2012 (UTC)

"edits" defined as "edit-count"? Choyoołʼįįhí:Seb az86556 > haneʼ 01:18, 10 March 2012 (UTC)
Yes.
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?
    csdnew
    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. 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. 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.
    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. 01:39, 10 March 2012 (UTC)
I can't.
Fatuorum
01:40, 10 March 2012 (UTC)
/yawn at silly timewasting. --OnoremDil 01:41, 10 March 2012 (UTC)
Anyway, my point is, it's not the quantity of Wiki-work, but the quality of it.
csdnew
01:46, 10 March 2012 (UTC)
  • Support, but the word "established" in the proposal is either superfluous, or needs defining. --
    talk
    ) 01:43, 10 March 2012 (UTC)
I think what he means is established, as in prolific users like 01:46, 10 March 2012 (UTC)
I did, yes.
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
talk
) 02:10, 10 March 2012 (UTC)
Try the number of FAs, GAs and DYKs a person has contributed to.
csdnew
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? 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?
    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
    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 (talkcont) 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 (talkcontributions) 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)
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.
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.
    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.
    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.
    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.
    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.
    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 (TCGE) 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 (TCGE) 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.
    Fatuorum
    03:49, 21 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.
    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.
    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)

  • That would pretty much put an end to successful RfBs, I'd think. 28bytes (talk) 16:41, 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)

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)TCM☯ 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

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)
(
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. Begoontalk
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. Begoontalk 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. Begoontalk 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)

  • For one thing, I think the best replacement for Vector would be something a lot more colorful. However, I don't know if the Wikimedia Foundation can afford the server resources necessary to serve up fancy CSS, etc.Jasper Deng (talk) 03:15, 21 March 2012 (UTC)
  • Not me. Perhaps you have four dimensions in your universe, but I don't in mine.
    Fatuorum
    03:41, 21 March 2012 (UTC)
  • Even though this is clearly a joke, I'm totally on board. Equazcion (talk) 03:46, 21 Mar 2012 (UTC)

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

  • 4D? If we're going to be making changes, I can't support anything less than 5D. 28bytes (talk) 03:51, 21 March 2012 (UTC)
  • Call me a luddite, but I am a 2D man. – Allen4names 07:13, 21 March 2012 (UTC)
  • Hmmm... Extra dimensions, with somewhat unsupported CSS? Sounds like a good idea to me......
    Is the original puzzle ball colorful enough? I can't imagine it would be too hard to add a couple extra dimensions to it, and more importantly, it has the advantage of having helpful mixed-Russian-Japanese redlinks. (By the way, it seems that the WMF actually does have plans to switch over to a new skin, called Athena, at some point.) --Yair rand (talk) 08:29, 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. Begoontalk 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
TALK
02:47, 22 March 2012 (UTC)
@138.162, 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)

Only show the V • T • E links in navboxes to editors

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)