Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Heyitsme22 (talk | contribs) at 22:06, 9 June 2011 (→User pages: new section). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

New ideas and proposals are discussed here. Before submitting:


Page mover

(moved to village pump to generate more consensus, please continue the discussion there.) This is a proposal for a new user right called the pagemover. Propose that this new user right would be able to move pages that have been move protected (move) and the ability to suppress redirects (suppressredirect). Those are pretty much the main idea I have but it was suggested that the movefile user right be include which is something i am not totally for. I would also like for move-subpages to be included which would give users with the pagemover user right to move pages with their associated subpages. As with any user right, there must be baseline requirements. What I propose is that the requirements for the pagemover right is that:

  • You must have some formal experience with moving pages.
  • You must have at least 500 edits.
  • At least 1 month experience

Let me just brief you of the benefits of having a pagemover. It would make the job of administrators a little easier by having someone else to userfy pages. It would also give users other than administrators the exclusive right of moving pages with their subpages. I myself am in opposition to the idea of pagemovers having the ability to move files as there are already two groups that can do that and their is no need for three. This could be done in a trial (Of Lord, the evil Trial word comes back) to see if it is a good idea or not. And with that I leave it to the community.mauchoeagle (c) 03:31, 21 May 2011 (UTC)[reply]

While I'm generally supportive, let me ask you the question that I foresee will ultimately shoot this proposal down. If someone can be trusted enough to be given this user right, why can't they be trusted to be an administrator?
— V = IR (Talk • Contribs) 03:52, 21 May 2011 (UTC)[reply]
Alot of respected users of the community were completely shot out of the water (eg My76Strat, Ancient Apparition and Chzz) and this sort of user right would touch the things that admins do without you actually becoming an admin. mauchoeagle (c) 16:02, 21 May 2011 (UTC)[reply]
  • Why is this needed? The number of move-protected pages that need to be moved on any given day is vanishingly small; there's not a huge backlog of such pages waiting around to be moved. Why does a special user right need to be granted where "ask an admin to do it" would work just as well? --Jayron32 04:17, 21 May 2011 (UTC)[reply]
As I mentioned above, another user right to performs such tasks could take a load off of administrators. And the proposal above is not only moving protected pages it also can move pages with there associated subpages and help with userfies. It always helps to have someone else to do a task, such as userfying, when you come accross pages that need to be userfied almost every day. In my experience with new page patrol, I see them alot. mauchoeagle (c) 15:55, 21 May 2011 (UTC)[reply]
There isn't much of a load to take off though. Most pagemoves that require an admin aren't moves of protected pages, they're moves over an existing page; completing these moves requires the ability to delete pages. Pages with subpages are typically established pages (subpages are most frequently used for discussion archives) and are rarely moved. Userfication is really the only one done on a regular basis, but is it that difficult to just move it yourself and put a speedy tag on the redirect? Mr.Z-man 16:59, 21 May 2011 (UTC)[reply]
  • Weak Support - Although I think that there is very little need for this I can see it could be useful. As one user who has basically lost interest in attempting a run through the gauntlet to become an administrator and who considers the process of choosing one completely and utterly broken (although good folks do become admins so no disrespect intended to them) I think this is a good step towards decoupling the various roles an admin does. In my experience most admins deal in specific things anyway and few use the whole suoite of tools so this would allow those interested in moving pages to do so. --Kumioko (talk) 13:03, 2 June 2011 (UTC)[reply]

Counter-proposal: Do not allow the right to move move-protected pages, only allow (suppressredirect), and up the requirements

This version would only allow suppressredirect, as moving protected pages seems like a bad idea. The requirements would be:

  • You must have a demonstrate history of constructive moves.
  • You must have at least 3 months of experience.
  • You cannot have a history of using moves to vandalize or content war pages.
  • You should have a communicable reason for wanting the right.

As one of the more prolific filemovers (currently knee deep in a list of 3000 files that all have to be renamed) this user right would allow me to do my job better, and would save the admins that I work with a great deal of time. If it's never been used in an article, there's no need to keep as a redirect a page named File:DSC01234.jpg or File:IMG02468.jpg when the image itself has been moved to something that's more descriptive. There are plenty of other people that work in plenty of other areas that could all benefit from this.

I do not, however, see any reason why allowing non-admins to move a move protected page around is a good idea. For the very tiny number of instances where it would be constructive, an admin is just a template posting or IRC chat away.

Thoughts? Sven Manguard Wha? 20:45, 27 May 2011 (UTC)[reply]

What are your thoughts on the move-subpages right? mauchoeagle (c) 20:56, 27 May 2011 (UTC)[reply]
I see all three components as having the potential for chaos should a vandal get a hold of the right, however from personal experience (someone moved my userpage to the mainspace once) I can tell you that an admin can fix straight up move vandalism in less than 30 seconds. I see no reason why it would take any longer to fix move vandalism if the subpages are also taken for a ride. The only component I specificly object to giving out as a right is the ability to move the move-protected pages. Especially when we get into template dependencies and trasnclusions, this could cause serious, widespread damage with a minimal amount of vandalism actions, and is much harder to clean up.
To some degree, the other issue is that I fully expect admins to grant rights to people that in no way deserve those rights, either in willful disregard for the guidelines, or because they don't care enough to even check the guidelines. I saw it with filemover. I'm not going to pretend that this isn't going to be given out like candy to both trustworthy people that will never use the right and untrustworthy people that just keep asking until they get lucky. Sven Manguard Wha? 22:21, 27 May 2011 (UTC)[reply]
  • Oppose. "suppress-redirect" is a mere convenience for admins, to save having to create a redirect page as part of a move and then delete it after when it's not needed. Particularly for admins doing a lot of a certain type of work, it saves quite a bit of time, and is a bit neater. I'm sceptical about the proliferation of user rights generally (given the misuse issues Sven mentions above), and this one just doesn't seem worth the hassle of managing, and the associated risks. Risks being, most notably, that abuses of suppress-redirect can make inappropriate page moves (or even page move vandalism) harder to catch. Users can just CSD the redirect. Moving subpages is needed less often, and probably carries less risk, but again it doesn't seem worth the trouble to separate it out, especially if it doesn't come with suppress-redirect. Rd232 talk 10:04, 28 May 2011 (UTC)[reply]
    Moving subpages carries less risk? That's a good one. Some rather nasty pagemove vandals have been known to use that option on things such as userpages with lots of subpages, and are thus able to vandalize upwards of twenty pages within a minute. Moving subpages is a right which is hardly used anyways, and has a massive potential for abuse. Ajraddatz (Talk) 14:59, 28 May 2011 (UTC)[reply]
    Fair enough. I did say probably... I was thinking it's no harder to undo than ordinary pagemove vandalism, and the subpages (especially of non-move-protected pages) aren't normally of particular prominence. Rd232 talk 15:12, 28 May 2011 (UTC)[reply]
    Much harder to revert, considering that most people don't recognize it as that type of vandalism, and revert each one separately - then users without the noratelimit right get stuck by a rate limit after two reverts. Ajraddatz (Talk) 03:45, 31 May 2011 (UTC)[reply]

One possibility which might be useful is to allow editors to suppress the creation of a redirect when moving a (userspace draft) page out of their own userspace into mainspace. That's probably harmless, is a common task, and prevents useless cross-namespace redirects. This would require a software change of some sort, but once done it wouldn't require any management. Rd232 talk 15:18, 28 May 2011 (UTC)[reply]

  • If this was going to be devolved from admins then it sounds like one of the least controversial accesses. move without creating a redirect, and move subpages, override title black list, and no rate limit on moves sounds like a reasonable package to grant as a right. However there must be some limit to the number of different rights before it just gets too confusing for people to understand. Graeme Bartlett (talk) 10:01, 31 May 2011 (UTC)[reply]
  • Support this would make files work so much better. --Guerillero | My Talk 21:45, 6 June 2011 (UTC)[reply]
  • Support I'm not normally one to support new userrights, but for those of you who don't do NPP you'd be shocked at the absolutely horrific page titles we come across sometimes. I've got hundreds of page moves in my log, and a good number of them are 1. names like BANURI VILLAGE (HIMACHAL PRADESH) from non-native speakers whose often horrendously mangled English isn't confined to the article body and/or 2. titles with missing or extra spaces. This would make it far more efficient; it wouldn't entirely do away with R3, as it seems many NPPers are not very experienced, and sometimes people create redirects that don't quite meet G3 but are clearly implausible anyways (Media shitstorm being created as a redirect to Media circus or Aught-six being redirected to 1906, for instance), but it would definitely help streamline NPP for those of us who know what they're doing. The Blade of the Northern Lights (話して下さい) 04:22, 7 June 2011 (UTC)[reply]
All rated articles by quality and importance
Quality Importance
Top High Mid Low ??? Total
FA 1,577 2,503 2,416 1,961 181 8,638
FL 181 688 768 701 101 2,439
A 370 681 788 584 91 2,514
GA 3,247 7,384 14,816 19,723 1,760 46,930
B 16,998 32,979 54,665 69,782 23,499 197,923
C 17,001 54,354 136,075 313,101 92,533 613,064
Start 18,538 92,538 417,290 1,632,818 414,054 2,575,238
Stub 4,277 31,460 277,973 2,808,856 762,954 3,885,520
List 4,889 17,232 54,106 195,640 69,507 341,374
Assessed 67,078 239,819 958,897 5,043,166 1,364,680 7,673,640
Unassessed 123 482 1,238 17,043 407,211 426,097
Total 67,201 240,301 960,135 5,060,209 1,771,891 8,099,737
About this table
The current assessment system.
This proposal would add a new row in the table, "FM" (Featured Media).
Alternatively, several new rows could be added, eg "FP" (Featured Pictures)
and "FSV" (Featured Sounds and Videos).
No change to the underlying assessment processes WP:FP etc is involved.

I would like to suggest creating a new class for featured media. This new class would be for Featured Sounds, pictures, videos (currently listed under featured sounds) and potentially topics. I believe that Wikipedia now has enough featured media that a category and class would be beneficial but since these content types have relatively few items individually I do not think we need separate categories for each. Currently some of these are tagged as File, however this would give us a better understanding of what media is currently featured.

I have already spoken to CBM who programs the bot that updates the assessment tables and he indicated that it could be done.

A few notes about the idea.

  1. Will help us identify the featured media so we can start identifying other media that could be promotable to featured status.
  2. Will allow projects to see if one of these is deleted, recommended for deletion or demotion, etc. via the Article alert bot
  3. Will help promote the use of our featured media
  4. There are currently about 364 featured sounds/videos.
  5. there are about 2747 featured pictures --Kumioko (talk) 02:13, 23 May 2011 (UTC)[reply]
I don't understand. What's a new "class" supposed to be? A new namespace? Cambalachero (talk) 02:25, 23 May 2011 (UTC)[reply]
Sorry I should have been more clear. A new class for article assessments. Currently we have A, B, C, GA, FA, FL, List, Start, Stub, File, Template, Category, and a couple of others. So basically we can identify a featured article and a featured list but not featured media (pictures, sounds, etc.) that only way to know its featured is to click on it. --Kumioko (talk) 02:32, 23 May 2011 (UTC)[reply]
  • Support, merging the current featured sounds, pictures, etc into a new large-scope class, similar to FA, is a excellent idea. —[d'oh] 03:23, 23 May 2011 (UTC)[reply]
  • Sounds good. I wonder though if we shouldn't plan ahead a bit and make Featured Pictures a separate class. Otherwise, in 5 years' time we might have to split the category. AFAIK categories with no content don't appear in the assessment summary box, so most of the time, with so few multimedia, this wouldn't mean an extra category, since most projects would only have Featured Pictures. Rd232 talk 04:15, 23 May 2011 (UTC)[reply]
I suppose thats true. There is a lot of content out there that could be featured the problem is we don't have a very active promotion system for non pictures. The videos and sounds never seemed to get going so thats why we only have a few. --Kumioko (talk) 13:27, 23 May 2011 (UTC)[reply]
Actually, featured sounds seem to be growing in number lately. --Another Believer (Talk) 03:54, 24 May 2011 (UTC)[reply]
Thats great, I admit I don't actively watch those pages but I suspect if we created a class that might help to increase visibility of this type of content. --Kumioko (talk) 16:03, 24 May 2011 (UTC)[reply]
Well, I'd rather have one Featured Media category than not be able to decide and end up not doing anything... Rd232 talk 17:11, 24 May 2011 (UTC)[reply]
Since the assessment classes are 'owned' by the WP:1.0 team, their input would be useful here. WhatamIdoing (talk) 20:48, 26 May 2011 (UTC)[reply]
It's rather easy to do, and I don't see how it could harm WikiProjects (aside from the up-front assessment work, but even that wouldn't be too hard). The main question I have is how we would handle images on Commons—if they get deleted there, we can't pick that up in the local deletion log. Titoxd(?!? - cool stuff) 21:09, 26 May 2011 (UTC)[reply]
There is User:CommonsNotificationBot. Rd232 talk 01:39, 27 May 2011 (UTC)[reply]
Thats a good point on Commons. I don't know what the best approach would be for associating commons files with a WikiProject myself. I had added the WikiProject US banner to several images that were commons images and other users came along and deleted the WikiProject banner so I stopped adding it to Commons related files. --Kumioko (talk) 01:11, 27 May 2011 (UTC)[reply]
The simplest would be to create the equivalent talkpage on Wikipedia and tag that. Rd232 talk 01:52, 27 May 2011 (UTC)[reply]
I misunderstood the proposal, therefore this answer is off topic. Sven Manguard Wha? 17:23, 27 May 2011 (UTC)[reply]
The following discussion has been closed. Please do not modify it.
  • Oppose FP/FS merge This would be a mess. Featured Sounds has clearly defined and high standards. Featured Sounds has poorly defined and admittedly iffy standards. Videos are accepted into Featured Sounds on the primarily on grounds of their audio quality, however often enough the video quality is sacrificed to improve the audio, leaving something acceptable for a Featured Sound but not so much for a Featured Media. The two areas, FP and FS, would not merge well together, I don't think. Sven Manguard Wha? 22:02, 26 May 2011 (UTC)[reply]
  • Strongest Possible Oppose for including FT as part of any of this! It's hard for me to comment on this component of the proposal without being rude or condescending. FT has nothing to do with media. If you want to merge off FT, which is something I don't see any reason for, merge it with a Featured Books process to create a "Featured Collections" entity. Do not, however, merge it with media. If merging FP and FS does go through, it should only be for the top items in the file namespace, period. Sven Manguard Wha? 22:02, 26 May 2011 (UTC)[reply]
I think the proposal is getting confused a little so let me clarify the intent a little. The purpose of this proposal is NOT to merge FP, FS or even FT's. What it does is add a "Class" for featured media to the WikiProject assessment tables. Currently we have Featured Article and Featured list but nothing for pictures, video, sounds or topics. All we can do is lump them under File. I would be ok with creating separate classes for each however I just don't think we have enough content built up in those yet to warrant seperate classes for each one. --Kumioko (talk) 01:11, 27 May 2011 (UTC)[reply]
Yep. I've added an assessment table - a picture's worth a thousand words. Rd232 talk 01:42, 27 May 2011 (UTC)[reply]
Thank you that did help to explain things. --Kumioko (talk) 13:17, 27 May 2011 (UTC)[reply]
Thats fine, that was always sort of a maybe anyway. --Kumioko (talk) 16:45, 27 May 2011 (UTC)[reply]

I updated several more files relating to adding the new class but Template:Cat class is protected and I cannot change it. I think this is whats causing it to not work properly. --Kumioko (talk) 02:42, 7 June 2011 (UTC) I think were gonna need to update Template:Class mask also. --Kumioko (talk) 02:56, 7 June 2011 (UTC)[reply]

That shouldn't be the problem. The banner template for WikiProject United States is not populating the Featured Media category for the project, so the bot is not picking it up. However, {{Cat class}} is a display template, which does not affect how the categories are populated, and {{Class mask}} was edited here already. Titoxd(?!? - cool stuff) 03:15, 7 June 2011 (UTC)[reply]

All I get is NA class if I put in fm or File class if I put in Featured Media. Is anything different supposed to appear? Is there an example of a successfully parsed fm class file? Since this is a featured class shouldn't it be standard for all projects? --Guerillero | My Talk 06:29, 7 June 2011 (UTC)[reply]

If you are using WPBannerMeta, you need to modify your WikiProject's banner in order to accept FM-Class as a valid option (see example). You can request assistance at Template talk:WPBannerMeta and one of the friendly people there may do it for you. As for FM being a standard class, I think so as well (or at least included in the extended assessment scale), so you can voice your opinion about that at WPBannerMeta talk too. Titoxd(?!? - cool stuff) 21:15, 7 June 2011 (UTC)[reply]
WikiProject US is working now. I'm not sure if someone else modified something to make it work or if the servers just needed to catch up but the bot is picking them up now. --Kumioko (talk) 23:15, 7 June 2011 (UTC)[reply]

Interesting concept. I like the idea of keeping track of project files although not sure how to automate this with Commons content. For Wikipedia:WikiProject Turtles, I actually just made a little manual montage of all the featured pictures on the topic (from WP or from Commons). So, I think it's something that I can see Projects wanting to track or liking to put up on their sites to intrigue visitors, motivate file work, etc. See here: Wikipedia:WikiProject Turtles/Turtles Featured Pictures.TCO (talk) 03:02, 8 June 2011 (UTC)[reply]

Media request page

Can we set up something similar to WP:BOTREQ, but for free media? I think a lot of times, users want to include an image (or other media) in an article, but may not have the necessary skills or software for that purpose. These users could request the creation of media for a specific article at that new desk. Someone with image editing software, audio editing software or video editing software could act on behalf of that request and create media. This media should then licensed under an appropriate license by the creator for uploading at Commons. I don't know if there were enough people willing to create such media or even if there were enough requests, but if there were, then that new desk would be a good place to centralize such requests.

Since our goal is to create a free encyclopedia, this would be beneficial for and in line with the overall mission of Wikipedia.

This could be run as a trial first inorder to evaluate, how the reception of this concept would be.

Just an idea from me. Toshio Yamaguchi (talk) 12:03, 27 May 2011 (UTC)[reply]

Are you aware of Wikipedia:Requested pictures? Yoenit (talk) 12:26, 27 May 2011 (UTC)[reply]
Thanks for the wikilink. However I think that's not exactly the answer to my request
  • WP:FFU is for those who whish to submit files, thus would be for those answering at the new page I am suggesting, not for those requesting there
  • WP:GL only deals with content that has already been uploaded
  • Wikipedia:Requested pictures is only a help page
  • {{reqphoto}} only categorizes requests
Therefore I think there is no page yet like the one I am proposing. And I think the page I propose would be useful, since it would follow the format used by WP:BOTREQ (which is more of a desk, like help desk or the reference desks). I welcome all critical comments on this proposal. Toshio Yamaguchi (talk) 12:55, 27 May 2011 (UTC)[reply]
Commons is the repository for free media, so shouldn't this idea be suggested there? We don't want free media on Wikipedia as someone has to manually move it to Commons so it can be used by the other projects. – ukexpat (talk) 16:58, 27 May 2011 (UTC)[reply]
"Wikipedia:Requested pictures is only a help page" - no, it isn't, look at all the subpage lists. It is just not commonly useful. Rmhermen (talk) 14:26, 28 May 2011 (UTC)[reply]
Commons already has similar pages: commons:Commons:Picture requests and commons:Commons:Audio and video requests. MKFI (talk) 11:35, 31 May 2011 (UTC)[reply]

OTRS Noticeboard

Wikimedia commons has a Noticeboard for OTRS members to answer questions asked by other users.(Commons:Commons:OTRS/Noticeboard) The advantage of this is that a user can get a quicker response to any questions regarding a ticket. I think it would be just as useful to have the same thing on Wikipedia. MorganKevinJ(talk) 16:13, 27 May 2011 (UTC)[reply]

  • Depends who you mean by that. I'm an OTRS volunteer, and I love it. :) I'm not an OTRS admin, but seeing as how there's a board on Commons already, I can't imagine why they'd have a problem with it. --Moonriddengirl (talk) 22:53, 28 May 2011 (UTC)[reply]
As an OTRS volunteer who handles a great many Commons and enwiki permissions tickets, my only concern is that I am commonly at Commons and watch the OTRS noticeboard there. I'd have to remember to come here and check for changes. I can also see confusion arising, where the mirroring of files gets OTRS questions asked here for files actually at Commons. If the OTRS volunteer who tagged such a file only participates at Commons, well, they're not going to be providing any information on it from their perspective. – Adrignola talk 14:48, 30 May 2011 (UTC)[reply]
I'd be perfectly fine with doing a soft redirect to your noticeboard; you guys are really on the ball over there. :D But if the board also covers other issues, that could be a problem. :/ --Moonriddengirl (talk) 00:41, 31 May 2011 (UTC)[reply]
  • I also think this would be fundamentally different - the main arrangements for deletion were It's targeted at non-editors and handles non-public data. Looking at the Commons board, it seems like it is targeted to editors, and I don't see any non-public data posted there. Avicennasis @ 18:12, 27 Iyar 5771 / 31 May 2011 (UTC)

Uw-3rr, ANEW, and WP:Don't template the regulars

I've noticed that the line "diff of 3rr warning" in each ANEW report encourages templating of experienced or semi-experienced editors. Thus I am proposing that a template for experienced users be made for the purposes of 3RR warnings.Jasper Deng (talk) 22:37, 27 May 2011 (UTC)[reply]

WP:DTTR is a mindbogglingly stupid page. Regulars should be templated; it's newbies who should be handled more carefully. I see absolutely no reason why experienced editors in an editwar--as in, people who should know better--should be treated nicer than people who may or may not know the rules. → ROUX ₪ 22:41, 27 May 2011 (UTC)[reply]
I dunno; you're assuming that the individual, personalized message left is kinder and more pleasant than the template. I have the impression that the opposite is frequently true, especially for people who are dealing with basic vandals on the WP:Recent changes patrol. There's a limit to how many times most of us can say craft friendly notices that amount to, "Please stop adding 'I LOVE CHEESEBURGERS!!!!' to articles" before we lose our tempers.
I think the point behind DTTR is that templating an experienced person is unnecessary, and likely to offend the recipient by failing to acknowledge his 'status' as a part of the community. Besides, someone like you and I doesn't need a link to the usual explanatory pages for the typical warnings; we're not going to wonder what "Knock off the edit warring already" or "Quit spamming your blog into articles" means. WhatamIdoing (talk) 23:27, 27 May 2011 (UTC)[reply]
Agree with ROUX: DO template the regulars. Choyoołʼįįhí:Seb az86556 > haneʼ 23:59, 27 May 2011 (UTC)[reply]
That's exactly the point though; there shouldn't be status like that. People who know better should be held to a higher standard; the inverse of this means we should be taking the time to not template newbies (blatant vandals excluded; they know exactly what they're doing and should be treated accordingly), whereas regular editors deserve to be told "I can't be bothered to write out something by hand for you, because you should know better already. → ROUX ₪ 00:06, 28 May 2011 (UTC)[reply]
I find DTTR valuable for this notion: "A personal message tends to work better in these situations. If you have a question, why not ask the experienced user your question? You may begin a dialogue that will prove much more effective than a template." With an experienced editor it's much, much more likely they've either made a mistake or that I'm missing the reason behind their actions. A question is more helpful in this case than a template. --NeilN talk to me 00:08, 28 May 2011 (UTC)[reply]
Agreed with Roux. I don't follow DTTR at all. Mind you, that's because I work in files and I have to inform people when their files are up for deletion. Still though, as I resize non-free files, I get non-free orphaned image templates regularly enough. Experianced editors should be expected to notice the template, take appropriate action, and dispose of the template when it is no longer needed. It's what I do, and I really don't get what all the whining about template messages is about. Sven Manguard Wha? 01:07, 28 May 2011 (UTC)[reply]
I do not follow it either and User:Roux made a good point, but people want me to follow it, like User:Orangemarlin that yelled at me after. ~~EBE123~~ talkContribs 13:25, 28 May 2011 (UTC)[reply]
@NeilN: Personal messages are fine too, but when you have to deliver dozens upon dozens of messages in a reasonable period of time, templates are efficient, civil, and for the most part unambiguous ways of doing that. Sven Manguard Wha? 01:12, 28 May 2011 (UTC)[reply]
While you do get complaints for doing so I find templating users 3rr warnings to be useful as it gives them all the dispute resolution information in one easy to see space.
Though as you do get complaints for using the template on regulars possibly a workable compromise would be to add another template with similar information, but without the warning symbol and stuff. -- Eraserhead1 <talk> 13:28, 28 May 2011 (UTC)[reply]
Could add a |regular=yes parameter to adapt the template message appropriately. At the end of the day "DTTR" is primarily about not insulting oldtimers by acting as if they're newbies, not about not using standard messages. Rd232 talk 13:49, 28 May 2011 (UTC)[reply]
Good idea. Then all we need to do is get it up and running in Twinkle, but that shouldn't be too hard. -- Eraserhead1 <talk> 17:26, 28 May 2011 (UTC)[reply]
It would require extensive editing of the uw warning templates, but, I feel it'll make the project run more efficiently. User:AzaToth, developer of Twinkle, has been notified.Jasper Deng (talk) 19:15, 28 May 2011 (UTC)[reply]
Frankly solving the problem for the 3rr template would solve 90% of the possible issues with templating the regulars. Usually the others aren't particularly useful with regulars anyway. -- Eraserhead1 <talk> 19:33, 28 May 2011 (UTC)[reply]
Well then maybe we shouldn't complicate all the templates, especially as it's probably best to start from scratch for regulars, rather than build from the newbie version. How about something in the direction of {{Uw-3rr-resolve}}? Rd232 talk 22:07, 28 May 2011 (UTC)[reply]
That'll be nice - except, we don't want to sound too nagging.Jasper Deng (talk) 03:22, 30 May 2011 (UTC)[reply]

You will not 'solve' DTTR by changing the wording of a template. The reason that you should not template regulars is that templates are designed for clear cases. For example, {{uw-ew}} is great - but only if edit warring is obvious. Regulars know the rules, and they are not going to be doing anything they believe violates the rules of the project. Templates say "You are violating rule X, stop." - some as bluntly, others more politely. Experienced users are extremely likely to have a reason they believe their action is justified. Applying a template in such a case is going to come across as very rude. Write a personal note. Obviously this problem wouldn't a apply for things like not including sources in images, in that case a template would be fine for any user. Prodego talk 05:20, 31 May 2011 (UTC)[reply]

How about something like {{Uw-3rr-resolve}}? Rd232 talk 09:54, 31 May 2011 (UTC)[reply]
I'm not going to write a personal note for edit warring that contains the appropriate dispute resolution links, which the user may not know. Even for clear edit warring you get shit for using the standard template. -- Eraserhead1 <talk> 06:37, 31 May 2011 (UTC)[reply]
Why not leave a personalized message asking that they cease edit warring, followed by the template, followed by a report to 3rr. If they are really a regular, and don't have a history of tendentious editing, why not AGF instead of rushing to meat the threshold to report them? Monty845 18:29, 31 May 2011 (UTC)[reply]
Personally I wouldn't bother giving them a message until the 3rd revert, at which point its a bit of a stretch to assume good faith - and giving them a link with all the resources is useful for them - we all get angry from time to time and over-revert. -- Eraserhead1 <talk> 20:35, 31 May 2011 (UTC)[reply]
There's a reason why TW does not provide uw-3rr1, uw-3rr2, uw-3rr3, and uw-3rr4.Jasper Deng (talk) 04:13, 1 June 2011 (UTC)[reply]
I never mind being templated if the template applies. I'd rather get a template than no notification at all. One reason why I like templates is that they're neutral, they help avoid the appearance of canvassing and could be less offensive than a personal note that might rub someone the wrong way. I try to follow DTTR when I can remember to, but not because I believe in it, but rather because "we're supposed to". I do often use a personal note when a template is available, but it's because I want to convey something in a way other than the template, or want my message to be more personable. But I do the same with newbies and regulars alike and don't discriminate. -- Atama頭 17:46, 6 June 2011 (UTC)[reply]
The way I see it, it all depends on which template. Obviously the "if you're new here and didn't know it" forms of templates are patronizing when used on an editor with a few hundred edits. On the other hand I think the emotionally-neutral tone and clear progression (you could be blocked, you will be blocked, do it again and you're getting blocked) are of great value in dispute resolution. HominidMachinae (talk) 20:09, 9 June 2011 (UTC)[reply]

Several changes to file naming

I have identified several issues with file naming on Wikipedia, and believe that it should be made a priority that they are fixed. They are:

  • Case sensitivity in image names: As it stands, three separate users could upload three separate images of three separate subjects called File:TestImage.jpg, File:TeStImAgE.jpg, and File:Testimage.jpg. There is no reason why file names should be case sensitive.
  • Multiple filetype extensions for the same filetype: As it stands, two separate users could upload two separate images of two separate subjects as File:TestImage.jpg and File:TestImage.jpeg. There is no reason for this.
  • Case sensitivity in filetype extensions: As it stands, and as I have seen at least twice recently, two separate images can be uploaded as File:TestImage.jpg and File:TestImage.JPG. This has the potential to cause even more problems that the above situations. There is no reason why filetype extensions should be case sensitive.

Why does this matter? This has and will continue to cause confusing situations. People upload multiple copies of the same image because they are looking for it and cannot find it under what is essentially an almost identical name. It is counter-intuitive for someone who has uploaded File:TestImage.jpg to, upon not finding the image, look for it at File:TestImage.JPG. Instead, time after time users, especially new users, assume that the upload didn't stick and they then re-upload the same image. They get a notice that the image is already there, which is confusing to them because they already looked and already couldn't find it. I've also seen cases where someone tries to put an image into an article, gets the case wrong somewhere, and then panics because the image dosen't show up.

I don't know if it's feasible, but if the community decides that it's worth doing and the coders determine that it's feasible, I'd like to remove case sensitivity in both image names and filetype extensions. I would also like for some sort of patch to be put in so that all iterations of a given filetype extension (JPG, jpg, Jpg, JPEG, jpeg, JpEg, etc.) function interchangeably.

Thoughts? Sven Manguard Wha? 08:24, 31 May 2011 (UTC)[reply]

Addendum: If implemented here, this would not affect files from Commons. Therefore at the conclusion of this discussion, if it is successful, I will either ask the developers if this could be implemented WMF wide or, if they want it, start an identical thread on Commons. I didn't think of that until now. Sorry Sven Manguard Wha? 19:05, 31 May 2011 (UTC)[reply]

Agree I agree with all of these points - especially number 2 which has potential to cause much confusion. Oddbodz (talk) 08:35, 31 May 2011 (UTC)[reply]

Totally agree. There is no reason why we must force article functionality onto files, and now that filemoving is enabled, it would be simple to fix project wide. ▫ JohnnyMrNinja 09:20, 31 May 2011 (UTC)[reply]
I would hope that a bot would be able to check for naming conflicts and then once those are taken care of backend code would be able to do the rest. I see that File:Example.jpg and Image:Example.jpg work interchanabally in the articlespace, so I was hoping, at least for the second of the three points here, that an identical situation (all forms of a filetype being capable of being used interchanabally) could be done up. Sven Manguard Wha? 18:54, 31 May 2011 (UTC)[reply]
  • Support 2,3. Case-sensitive and "synonym" extensions can only serve to confuse and have no real benefit. I am unsure if it will be feasible at this point to have case-insensitive file names. I'm sure there are plenty of cases where File:AIR.jpg and File:Air.jpg stand for some organisation AIR and the other for air component chart or something. The mess and workload it will create may overweight the actual benefits. But I'm educated guessing, someone working a lot with images/moving should comment. —  HELLKNOWZ  ▎TALK 09:41, 31 May 2011 (UTC)[reply]
    • If there are too many conflicts, one solution might be to make it so that current files are uneffected, while files in the future cannot be uploaded if an identical name exists in a different case configuration (similar to how users can no longer upload images with names like File:IMG0002.jpg, however the files already named like this are unchanged. I know that implementing it here would require a different solution, but the concept is the same.) Sven Manguard Wha? 18:59, 31 May 2011 (UTC)[reply]

FYI: I was told to post at BugZilla bug 4421 and have done so. Sven Manguard Wha? 05:39, 1 June 2011 (UTC)[reply]

  • Support fixes for all 3 cases specified. H3llkn0wz has a reasonable concern about AIR.jpg vs. Air.jpg but Sven's suggestion to grandfather in existing conflicts of that nature until they can be resolved eases my concern about that. Allowing separate images to be uploaded as (to make up an example) both Disney Logo.png and Disney logo.png is just asking for headaches and confusion. 28bytes (talk) 05:49, 1 June 2011 (UTC)[reply]
    As far as I know, we also have a similar block of uploading files that conflict with Commons, but existing conflicts remain until fixed. ▫ JohnnyMrNinja 06:07, 1 June 2011 (UTC)[reply]
    I intend on fixing the commons conflicts, just as soon as I'm done fixing the bad image names (there are 3000 of them, see user:Chzz/dsc0511 for a sample of what I'm dealing with now). If this is approved, and the number of conflicts is reasonably sized, I'll work on that before I get to the commons conflicts too. The great thing about filemover is that there are a half dozen people that are actively helping to clean out these massive backlogs, a task previously inaccessible to non-admins. I don't see the naming conflicts as being a long term headache, they can get cleaned up rather quickly if this goes through. Sven Manguard Wha? 23:45, 1 June 2011 (UTC)[reply]
  • Support to all 3 above. Case in point being file:Miranda Kerr.jpg vs file:Miranda Kerr.JPG. At present, it's just luck that we do not have file:Miranda Kerr.jpeg and file:Miranda Kerr.JPEG too ;-) Illogical! --Ohconfucius ¡digame! 08:00, 2 June 2011 (UTC)[reply]
  • Support 2&3, some files do need to have their names distinguished. —James (Talk • Contribs) • 10:08pm • 12:08, 2 June 2011 (UTC)[reply]
  • Support I have been the victim of similar mistakes, and it is frustrating how long it takes to sort it out, because I essentially assumed case wouldn't matter, so it never occurred to me to track that down.--SPhilbrickT 22:29, 2 June 2011 (UTC)[reply]
  • Comment - The above linked bug was first brought up in 2005. If you'd like to see it implemented, don't just show your support here, but login to bugzilla:4421 and vote there too. This will let the devs see how much support it has. ▫ JohnnyMrNinja 08:04, 3 June 2011 (UTC)[reply]
  • Support, I don't like to add images and have to look multiple times for the uppercased letters. mabdul 08:52, 4 June 2011 (UTC)[reply]
  • Support 2 and 3, because they are fairly logical; I'm not so sure about 1, given that there may be legitimate reasons to upload different files under different casings. —mc10 (t/c) 00:56, 7 June 2011 (UTC)[reply]
  • Support if this change is made on all projects, particularly Commons. We don't need different functions on different projects. Also, we need to discuss how the mass renaming would be handled; add a "1" at the end of the newer file name before extension maybe? Rehman 08:37, 9 June 2011 (UTC)[reply]

Good Article on Hold Template

Many articles are nominated as Good Articles and put on hold by reviewers. Reviewers leave a message on the talk page with a link to this list. However, many editors will not check the talk page and not know that the article is on hold. I wish to add this template to all articles which have been put on hold so that the message is on articles and talk pages.

The template is in my user space and is not yet in use. I wish to see if anyone would agree with this template beeing put into use. Oddbodz (talk) 08:46, 31 May 2011 (UTC)[reply]

What exactly does "on hold" mean here? I suggest that the words "on hold" should link to an explanation. -- John of Reading (talk) 08:51, 31 May 2011 (UTC)[reply]
I don't think this is a good idea. We don't want to clutter the article page with unnecessary stuff. There is not actually a problem, so a template drawing attention may not be needed. What you are trying to achieve is help from editors, but instead the 95% of readers will have their experience degraded. Graeme Bartlett (talk) 09:08, 31 May 2011 (UTC)[reply]
There really are not that many GANs on hold: Category:Good_article_nominees_currently_on_hold. WO:GAN#On_hold is placed while the nominator addresses the issues. Why do the readers (tag on article) need to be notified of this? Editors would only be notified (tag on talk) if they have the article watchlisted in the first place, but then they would have already known about the GAN. I think this is redundant to the category and the article tag is of interest to only a few editors. —  HELLKNOWZ  ▎TALK 09:34, 31 May 2011 (UTC)[reply]
I think editnotice would be more appropriate since it would not clutter up the article but it would still be seen by anyone trying to edit the article.MorganKevinJ(talk) 19:31, 31 May 2011 (UTC)[reply]
I support idea of an editnotice. Graeme Bartlett (talk) 23:39, 31 May 2011 (UTC)[reply]
  • Oppose, Nearly every article has at least one information box. It is good if there are some articles that don't have any! Normally the user only wants to read the article and doesn't know how to edit - and won't change if there is a new box informing the user. Normally the reader doesn't know what this information is about. mabdul 08:49, 4 June 2011 (UTC)[reply]

Suspend sysop rights after 1 Year of inactivity

The issue of Inactive Admins has reared it ugly head again after one admin account was hijacked by White supremacist editors. Arbcom made an emergency De-sysop of Spencer195 (talk · contribs · blocks · protections · deletions · page moves · rights · RfA) whose last edit was in 2005 to prevent possible damage to the community. Given Spencer195 off the Wikipedia for six years before being compromised there seems no assurance that dormant account are as safe as assumed.

Its been three years since the last major proposal on this was made. In that time Wikipedia prominence has grown and I think the Language on that proposal is right on with what needs to happen now.

Proposed language to be Added at Wikipedia:Administrators#Review and removal of adminship
  • Admin accounts which have been completely inactive for at least one calendar year (with no edits or administrative actions in that time) will be automatically desysopped. This is not to be considered binding, or a reflection on the user's use of, or rights to, the admin tools; if an inactive admin returns to Wikipedia, they may be resysopped by a bureaucrat without further discussion, providing they left Wikipedia in good standing and not in controversial circumstances, and that their identity is not in dispute. The admin will be contacted one month prior to the expiry of the one-year timeframe on their user talk page, and again a few days before the limit. If the account has a valid e-mail address, the user will also be contacted via that medium. The summary in the user rights log will make it clear that the desysopping is purely administrative."

This proposal allows a dignified desysopping and the ability to Re-Sysop if they choose to return to Wikipedia. The Resident Anthropologist (talk)•(contribs) 22:33, 31 May 2011 (UTC)[reply]

On the last line of the proposed clause, rather than "purely administrative" (which will introduce another potential ambiguity), perhaps "purely while account is inactive"? Ncmvocalist (talk) 13:15, 2 June 2011 (UTC)[reply]
I support this, but y'know... "good luck" Choyoołʼįįhí:Seb az86556 > haneʼ 22:43, 31 May 2011 (UTC)[reply]
I certainly wouldn't object if I disappeared for a year and came back to find that the tools had been removed - in fact, I'd expect it. I'd go further and say that an admin who comes back after over one year's absence needs to agree to read up on all the policy changes before the bureaucrat hands the mop back. Elen of the Roads (talk) 22:48, 31 May 2011 (UTC)[reply]
I Support this though I might like to push it to two years of inactivity but never the less i support the principles behind this and would not object to a one year time frame. Seddon talk|WikimediaUK 22:50, 31 May 2011 (UTC)[reply]
Support based on the security concerns of having high-privilage accounts which aren't being used. A year seems about right. -- Eraserhead1 <talk> 22:52, 31 May 2011 (UTC)[reply]

Support very reasonable proposal Murray Langton (talk) 09:29, 1 June 2011 (UTC)[reply]

I Support this. It make sense. But, there would have to be no strings attached; readminship would have to be automatic upon request, and any outstanding issues would have to then go through normal processes. Maybe 18-24 months is a better timeframe. Ocaasi c 23:05, 31 May 2011 (UTC)[reply]
  • Before we jump straight into judgement-vote mode, could we have a discussion about this? I understand similar systems are used on sister (language) projects, anyone know the details? Skomorokh 23:12, 31 May 2011 (UTC)[reply]
That would be helpful I feel. Sorry if I set folks off on the wrong track above - I was just intending to expound how I would react if it were me. Elen of the Roads (talk) 23:18, 31 May 2011 (UTC)[reply]

Question: what guarantees are there that the putative resysopping procedure would not be a point of security vulnerability, by having imposters come along and try to claim the account ("oh and the old email address is history, pls help")? Rd232 talk 23:20, 31 May 2011 (UTC)[reply]

I would say a Crat's judgement. The Crat's I know would be suspicious of such a request and probably discus it with other crats before doing it. Personally its better than simply having it to begin with. The Resident Anthropologist (talk)•(contribs) 23:23, 31 May 2011 (UTC)[reply]
I would think any admin coming back after 6 years of inactivity and asking for rights reinstated right away would be suspicious anyway. And at least at that point, they are being noticed. As it is, nobody is watching their (lack of) activity. ▫ JohnnyMrNinja 23:31, 31 May 2011 (UTC)[reply]
This would be better if another little group, of crat's trusted users because crats already have lots to do. But still, I support. Also, what happens if an account like his gets highjacked or hacked into before 1 year? ArbCom cannot come fast enough. ~~EBE123~~ talkContribs 20:35, 1 June 2011 (UTC)[reply]
  • It might be better to rename this proposal "Suspend sysop rights after 1 Year of inactivity" to make it clear this is a security/housekeeping measure that's not punitive. I wouldn't object to requiring, in the absence of a stronger method to verify identity, a month of normal editing prior to restoration on the grounds that an account hijacker is unlikely to bother. I agree there is no emergency, but it seems like a cheap preventative measure. While it's true that rogue admin actions can be reversed, the damage to Wikipedia's reputation is much harder to undue. --agr (talk) 23:26, 31 May 2011 (UTC)[reply]
  • Support old admins who left, went inactive, or retired in good standing of being entitled to the expectation of return of the bit on request at WP:BN with at least a brief discussion. --SmokeyJoe (talk) 23:43, 31 May 2011 (UTC)[reply]
  • Support It's a well thought out proposal and I can't think of any reason not to do it. True, an active admin is no less likely to be targeted for hijacking than an inactive admin, but let's limit the pool of targets anyways. Sven Manguard Wha? 00:35, 1 June 2011 (UTC)[reply]
  • One year seems kind of brief. A difficult year at work, a year abroad for school, a baby in the house, a deployment for our active military members—it's not hard to imagine a temporary circumstance that could result in a year's inactivity, especially for admins who are primarily active on other WMF projects. If we're going to do this (something I don't feel strongly about, but tend to think unnecessary), then I think the timer ought to be set rather longer than 12 months. Also, I think that the 'make sure they (say they) read all the policies' requirements are rather patronizing. We select admins because we trust their judgment, not because they can quote the (constantly changing) policies. In fact, I'm not sure that I've ever encountered a single editor who has actually read all of the policies before.
    BTW, in the category of 'how to make a decision', it might be appropriate to post notes on every potentially affected account's user talk page. Some of them might want to have an opportunity to comment, and the e-mail-based surveys WMF has done suggest that people who look "inactive" to us don't think of themselves as being inactive. WhatamIdoing (talk) 00:42, 1 June 2011 (UTC)[reply]
The reasoning doesn't stand up if they are active on other WM projects, especially if they have SUL. I don't think a WP admin who is busy at Commons should be considered inactive in this context. ▫ JohnnyMrNinja 00:49, 1 June 2011 (UTC)[reply]
The most common measurement of inactivity uses Special:Contributions, and therefore sees nothing more than whether the person made any edits to undeleted pages specifically on the English Wikipedia within the specified time. IMO such a measurement is inadequate for this purpose, but it's the most likely to be used. WhatamIdoing (talk) 01:34, 1 June 2011 (UTC)[reply]
In that case all they have to is to make a couple of edits somewhere when they get the warning. Is that so much to ask? Johnbod (talk) 02:45, 1 June 2011 (UTC)[reply]
Actually, policy states in pretty clear language that Wikipedia is not compulsory, so yes, I think it is a little unrealistic. --Tothwolf (talk) 04:26, 1 June 2011 (UTC)[reply]
Hardly "unrealistic". If you think it is "unreasonable" I'd have to disagree strongly. Johnbod (talk) 11:48, 1 June 2011 (UTC)[reply]
  • Support the proposal, it's common sense. Not sure if this is the case, but inactive admin accounts may give us the impression that we have more admins than we actually do. (I am not an admin) --Surturz (talk) 01:49, 1 June 2011 (UTC)[reply]
  • Oppose Per "security concerns" an invalid reason. Consider: how often are accounts compromised? Then: How many of those accounts are administrators? Then: How much damage could a rogue admin account cause before being shut down? Then: How many different ways can rogue admin accounts be quickly stopped? Versus: How much does leaving permissions on inactive accounts hurt? Seriously—when was the last time an old admin account was hacked? I recall Zoe/RickK, and Spencer195. It's not often at all. An active admin account can be "hacked" just as easily. The problem is not with leaving permissions on these accounts. It is with users picking weak passwords. You can't change that except at the individual user level. /ƒETCHCOMMS/ 02:20, 1 June 2011 (UTC)[reply]
So, because it's "only" happened twice so far, we should continue to memorialize the accounts of long-departed – and quite possibly deceased – editors by keeping all of their advanced rights on their account in perpetuity? On the off-chance they rise from the dead and decide to resume editing, is it really an onerous requirement that they stop by the bureaucrats' desk on the way back in and say "hey, before I start blocking people and deleting pages, has anything changed since 2004 that I should be aware of?" The idea that these accounts hold no interest whatsoever for people with malicious intent (because it's "only" happened twice so far that we know of) is naive, frankly. 28bytes (talk) 03:39, 1 June 2011 (UTC)[reply]
The problem is partly with inactive accounts, because the best person to detect hijacking is the person whose account it is. Removing the bit from such accounts has a variety of small benefits, including reduced security risk and better admin stats, and less risk of admins returning and not being up to speed (the act of having to ask for the bit back underlines that they have a need for seeing what changes they might have missed). If the benefit is small and the cost is very small, it's worth doing. Rd232 talk 16:45, 1 June 2011 (UTC)[reply]
  • Support - A lot can happen with the rules in WP in a year and if someone hasn't edited in a year then they might be missing out on major changes in policy. If they even come back at all which after a year is against the odds. --Kumioko (talk) 02:41, 1 June 2011 (UTC)[reply]
  • Support We'll have to do this some time, or our admin list will slowly become a phantom army. Johnbod (talk) 02:45, 1 June 2011 (UTC)[reply]
    And why is that a bad thing? Ajraddatz (Talk) 02:47, 1 June 2011 (UTC)[reply]
    • Er, because! Does that really need answering? If we have a list of admins, it's rather more useful if they actually are admins rather than ex-admins. Even if Rip van Admin does decide to return eventually, things change round here, & after a few years they may be seriously out of touch. If they can't be bothered to do a couple of edits when they get the warning, they should be de-activated. It isn't much about security as far as I'm concerned. Johnbod (talk) 02:56, 1 June 2011 (UTC)[reply]
  • Fetchcomms stole the words from my mouth. This change isn't needed - active admins are more likely to be compromised, and the problem is people using bad passwords, not keeping rights when they go inactive. Plus, while it happens once in a blue moon, this shouldn't be so much of a concern that we need to take this pointless action to "prevent" it. Ajraddatz (Talk) 02:47, 1 June 2011 (UTC)[reply]
  • It would be useful to know how many 1yr, 2yr, 3yr etc inactive admins there actually are. Ah yes, here at Wikipedia:List of administrators/Inactive. We already have more inactive than active admins (on the different "30 or more edits in the last 2 months" criterion), and there are 2 who have not edited at all since 2002. Opposers might like to produce arguments for keeping them live. There are 75 who have not edited since 2007 or earlier, and 246 who last edited before June 1 2010. Johnbod (talk) 03:02, 1 June 2011 (UTC)[reply]
    How about "why remove"? You are trying to fix a system which isn't broken. Ajraddatz (Talk) 03:16, 1 June 2011 (UTC)[reply]
What "system" applies to someone who hasn't edited in over 9 years, a time when WP was utterly different in so many ways? I believe the Pakistani phone directories only used to add new entries, never removing the old ones. That didn't work either. Most non-historical databases need housekeeping to remain useful, passports need renewing, and so on. Do you really want to keep people on the list "to infinity and beyond"? Johnbod (talk) 03:27, 1 June 2011 (UTC)[reply]
  • Support. In the real world, when you leave your job or a volunteer position, you turn in your keys to the building. It's absolutely bizarre that accounts that have not even logged in since 2004 (!) or earlier still maintain advanced rights. 28bytes (talk) 03:25, 1 June 2011 (UTC)[reply]
Agree absolutely, but to be picky, logging on, and edits on deleted articles, are not counted in the figures here - just recorded edits on live articles. Johnbod (talk) 03:30, 1 June 2011 (UTC)[reply]
There's two flaws with that analogy: one, Wikipedia is not the real world; and two, inactive does not mean a user has left. They're taking a break—maybe extended, but you don't know when they're returning, right? In the "real world", you would get to keep your keys if you were going on a vacation, and if something happened and you weren't able to return them, the boss isn't going to hunt you down to get them back. /ƒETCHCOMMS/ 03:40, 1 June 2011 (UTC)[reply]
If you mean a metal key on a chain, you're right, they're probably not going to send a bounty hunter after you to retrieve it. If you mean a plastic RFID badge that lets you into the building (which is much closer to the situation here): you'd better believe they'd deactivate that if you went on a short vacation and never came back. Any IT head that had a policy otherwise would justifiably be fired. 28bytes (talk) 03:53, 1 June 2011 (UTC)[reply]
One of the best points so far. -- Eraserhead1 <talk> 07:52, 1 June 2011 (UTC)[reply]
28bytes, your analogy is closer to a proposal to automatically change peoples' passwords after a year of inactivity. The RFID badge is like a password—the sysop tools are like a pair of scissors. Following your logic, it would make sense to automatically disable logins from user names that haven't edited/made a logged action in over a year, and then have some sort of system to restore the login when requested. Because a spambot running under a non-admin account is just as destructive as a rogue admin account (which is not very destructive in the end), and given that there are millions more non-admin accounts than admin accounts, it would make sense to think about those, first. /ƒETCHCOMMS/ 13:13, 1 June 2011 (UTC)[reply]
That's a bit of a red herring. Anyone can register an account instantly and start wreaking havoc with a spambot (or indeed, not register an account and wreak havoc with a spambot). Whatever incentive there might be compromise an inactive non-admin account (instead of just registering an account) is minuscule in comparison to compromising an admin account. 28bytes (talk) 14:24, 1 June 2011 (UTC)[reply]
Not necessarily. If someone's IP(s) is/are rangeblocked, then they would go for hacking others' accounts. Given that rangeblocks are often applied to stop frequent sockmasters, it's not unlikely that someone will try to take over another account rather than create one from scratch. There's also the "established" bit—anyone who would try to use the Clifford Adams (talk · contribs) account for deceptive purposes would be quickly found out, while someone who chooses a non-admin account would probably not be noticed that much. Being an admin makes the account stick out much more. And again: the amount of damage a compromised admin account could wreak before being stopped is very little. Or even a compromised crat account. If necessary, a dev could simply remove the ability for crats to change userrights until the whole thing was sorted out. So there's almost no chance that someone would succeed in creating an army of rogue admin or steward accounts. /ƒETCHCOMMS/ 18:54, 1 June 2011 (UTC)[reply]
Without getting too far into bean territory, I can think of plenty of ways a malicious person or group could cause a lot of damage with the sysop flag. That the damage could be stopped and the mess cleaned up is rather beside the point... why would we want to make it easier for people do so much damage in the first place? Not everyone who gains access to an admin account is going to be as stupid and obvious about it as our most recent (known) example. 28bytes (talk) 19:08, 1 June 2011 (UTC)[reply]

Suspend sysop rights after 1 year of inactivity - arbitrary break 1

  • I note also this failed proposal from 2004 to de-activate 5 admins who had already been inactive for over a year. The amazing thing is that none of them had over 1,000 edits in total. Yet they are still on the books, except for one who died in 2009 without editing again. Johnbod (talk) 03:46, 1 June 2011 (UTC)[reply]
  • Password security About the only "prevention" for the problem of poor passwords would be to enforce the use of strong passwords with something like cracklib which is based on Crack (software) from Alec Muffett. That said, I don't think a strong password requirement would be popular with users because in the larger scheme of things, few people actually use strong passwords.

    Other than that, speculation that inactive accounts with the admin bit are going to be compromised more often than accounts without the admin bit is unrealistic. The truth is, non-admin accounts are much more commonly compromised and are more commonly sought after by people wishing to use them as sockpuppets. Accounts with the admin bit are less of a target because they tend to be too high profile for such abuse. --Tothwolf (talk) 04:01, 1 June 2011 (UTC)[reply]

  • I'd be interested to see how many current admins had a year-long or more stretch of inactivity. Is this something that happens, people come back to active sysoping after a year of disinterest? ▫ JohnnyMrNinja 04:10, 1 June 2011 (UTC)[reply]
Also, is there any way for a bot or some other automated process to notify Bureaucrats of an admin that has not logged in to any WMF project in a year, or will we be forced to go by WP edits? ▫ JohnnyMrNinja 04:50, 1 June 2011 (UTC)[reply]
    • These are good questions. The "abroad at University" argument doesn't hold much weight to me, when every country in the world has internet access. The "busy at work" argument is reasonable, but for a whole year without a single edit or admin action on any Wikimedia project? This seems a little far fetched. -- Eraserhead1 <talk> 07:40, 1 June 2011 (UTC)[reply]
      • More like "no life at university" :). Although, I guess if a user was in China or something, editing would be much more difficult. JohnnyMrNinja, I don't think even CU can detect logins. Edits, we can track, but not when someone logs in. /ƒETCHCOMMS/ 13:16, 1 June 2011 (UTC)[reply]
  • Oppose. This would not reduce the already-small risk of compromised admin accounts or improve admin quality. On the first point, WP:PEREN#Demote inactive admins mentions that developers say an inactive account is less likely to be hacked than an active one (and, as Tothwolf mentions above, non-admin accounts get hacked even more often). On the second point, I'm not convinced that someone who could be trusted with the tools one, two, or even five years ago can't be trusted with them now. Yes, policy and consensus changes. However, two things have not changed: (1) our mission to create a neutral, verifiable free encyclopedia, and (2) the fundamental roles and responsibilities of admins. I'd like someone to point out an instance where an admin came back from a long break and proved themselves no longer worthy of the mop and bucket. A returning admin may have to get used to things like new blocking capabilities and minor changes in usual practice, but these are not such earth-shattering changes that they can no longer be trusted to use the tools properly. szyslak (t) 05:46, 1 June 2011 (UTC)[reply]
    What counts in security is the probability multiplied by the damage, the damage for hacking a non-admin account is trivial. -- Eraserhead1 <talk> 07:52, 1 June 2011 (UTC)[reply]
    I agree that an admin account in the wrong hands is a very bad thing. However, inactive admin accounts are no less secure than active ones, and appear to be even less likely to be compromised per above. What is needed is better password security per Tothwolf above, not removal of access based on a factor that doesn't even make the accounts less secure. (Even when an admin rampage does happen, the damage is temporary, reversible, and necessarily limited. Come to think of it, someone could do even more damage without an admin/crat account...) szyslak (t) 08:43, 1 June 2011 (UTC)[reply]
    How would you propose to increase the password security of inactive accounts? Only thing I can think of is emailing them a randomly generated password, but many of them don't have email enabled and for those that do there is no garantuee the mail account is not inactive as well. Yoenit (talk) 09:41, 1 June 2011 (UTC)[reply]
  • An account with the admin bit cannot really create any more damage than a a "regular" account. Most anything done with either account can be undone without too much difficulty.

    Where something becomes much harder to deal with is when someone has obtained non-admin accounts and uses them as sockpuppets to influence discussions, XfD, etc. Such actions are much more harmful to Wikipedia than the very occasional event of an account with the admin bit being compromised. Such sockpuppetry is yet something else we can link to the editor retention issue. [1] [2] As I mentioned above, "admin accounts" are not really suitable for this type of abuse because actions done by accounts with the admin bit draw more attention. (Those who are truly paranoid should be pushing for the locking of infrequently used accounts which have high edit counts ;P ...and yes, that is sarcasm.) --Tothwolf (talk) 15:29, 1 June 2011 (UTC)[reply]

  • Support But why wait a whole year? Bring it down to 3-6 months. Lugnuts (talk) 06:30, 1 June 2011 (UTC)[reply]
  • Question Are there are any cases where an administrator returned who would have been desysoped under the current proposal (so no edits at all for more than a year)? Yoenit (talk) 07:58, 1 June 2011 (UTC)[reply]
  • Support. All good reasons stated already. In addition I like it cause it can be confusing for people who don't know of any admins by name to find an active one. I see noobs leave messages for admins who haven't been active for a long time cause they don't know any better, then wait frustrated for a response. I would indeed cut down the time to 6 months, or at least add as a matter of policy that if you're inactive that long you may expect a warning to be placed on your user page by a third party, if you don't put one there yourself, that users shouldn't expect a reply or action from you until further notice. Desysopping is preferred though, as the bit is easier to track than user page content, the database would remove you from any admin lists etc. Equazcion (talk) 08:36, 1 Jun 2011 (UTC)
  • Support (I know it's not a vote, but I just want to be clear to anyone perusing) - I like 1 year but I think 2 might be less offensive to some (on the off chance they get really distracted), and I'd be more comfortable if there were a way to determine login activity vs WP editing activity. The arguments about active accounts being more vulnerable may well be valid, but those editors will notice, whereas inactive editors won't. Non-admin accounts may get hacked more often, but there are many-times more non-admins, and their passwords are probably easier on-the-whole. Someone specifically targeting an admin account knows something about what they are doing, and they may not make any waves once they have the account, maybe even having the name changed. Maybe they just log in to see admin-only pages and logs? Just because nobody is spreading racist propaganda doesn't mean their accounts weren't compromised. Also, if they have been logging in and not editing, they will notice the talk page message they will get, and hopefully respond. If they don't respond, for whatever reason, then it is highly unlikely they would even notice their privileges are gone, much less care. Another good is that our active admins are highlighted. Can anyone actually envision any admin who passed an RfA, then left for several years, and is upset that need to let someone know they are back before they start deleting and blocking again? They would see the politely-worded notice on their talk page and scream "This is what I get for serving my country!?!?!" and then go on a rampage through their hometown? What is the possible bad that can come from this proposal? I've had email websites deleted for less inactivity. People gone for that long probably would want to ease back into regular editing, let alone settling 3rr disputes, for the day or so it would take a Bureaucrat to reinstate them. ▫ JohnnyMrNinja 09:07, 1 June 2011 (UTC)[reply]
    • ...and, if they did turn out to be so unreasonable in their expectations upon returning after so long, they wouldn't make very good admins. Equazcion (talk) 09:16, 1 Jun 2011 (UTC)
  • Support Great idea. Will allow us to keep a better eye on the number of admins. --Doc James (talk · contribs · email) 09:36, 1 June 2011 (UTC)[reply]
  • A year's a long time on Wikipedia and things change. Guidelines are "clarified", which in some cases is an actual improvement. Policies alter. Custom and practice tends to drift. AN/I drama gets more pungent. Someone who hasn't edited for a year won't necessarily be ready to use sysop tools immediately; they'll have an out-of-date image of how we do things. It's reasonable that we ask a crat to satisfy themselves as to the returning user's identity and for a short period of regular editing that demonstrates the user's "up to speed" before access to sysop tools is restored.—S Marshall T/C 11:47, 1 June 2011 (UTC)[reply]
  • Comment For your information, there are at least four known cases of inactive admin accounts being compromised:

I have no doubt I will find more if I go through the history of Wikipedia:List of administrators/Inactive. None of them did serious damage after being compromised, but this is definitely a vulnerability. Yoenit (talk) 11:55, 1 June 2011 (UTC)[reply]

  • Support. I would only consider it normal that I would no longer automatically be a sysop after a year of inactivity. I wouldn't oppose a period of two weeks to a month of regular editing required before getting the rights back either, to decrease the chance of someone coming along and claiming to be me. While this suspension of rights may have few advantages, I believe they still outweigh the very small disadvantages. Fram (talk) 12:16, 1 June 2011 (UTC)[reply]
  • Oppose—requiring a minimum amount of edits in a given period of time will incentivize a minimum amount of edits in a given period of time. Admins not wishing to lose admin status will return to make a few edits each 6 months, for instance. Of course it could be argued that this is a good thing, as it will sort the dead from the living, generally speaking, with allowances for the merely incapacitated. I would suggest extending the period of inactivity to ten years to be sure we are really desysoping those who are unlikely to ever edit again in the capacity of administrators. Bus stop (talk) 12:42, 1 June 2011 (UTC)[reply]
  • Support. This has been standard policy at the other two projects I edit at, Wikibooks and Commons. The former uses a year and the latter six months. Both require notification of an inactive admin via email/talk page and allow for 30 days to respond. I see nothing wrong with reducing risk. While both inactive and active admins are targets, active admins will notice if they're locked out of their account or are performing bad actions. Inactive admins can be taken over without their original owner noticing. Additionally, having the list of admins actually reflect people that can assist is helpful to users and allows for use of tools like http://toolserver.org/~vvv/adminstats.php without errors due to too many admins. Adminship is "no big deal" as stated above, so there's really no need for consternation that it could be taken away if not used. Objections to the contrary make me wonder if it really is seen as a badge of honor. – Adrignola talk 13:02, 1 June 2011 (UTC)[reply]
    • Commons' policy is actually much harsher than this one and not exactly comparable. They only count admin actions, not edits. So it is more of a "if you aren't using the tools you don't need them even if you're editing". Killiondude (talk) 16:27, 1 June 2011 (UTC)[reply]
  • Support @@@@ — Preceding unsigned comment added by Nev1 (talk • contribs)
  • Conditional support. Conditions: i) email the admin in question a warning 1 month before desysopping (say, email at 12 months and desysop at 13, if still no activity) ii) after desysopping, 1 month of reasonable activity levels required after return, before resysopping on request at WP:BN. I'd also suggest that if at resysopping request time total activity levels over the previous 5 years are judged very low by bureaucrat consensus, there is bureaucrat discretion to require a reconfirmation RFA; but my support isn't conditional on that. Rd232 talk 13:12, 1 June 2011 (UTC)[reply]
  • Comment - introduction of process If this passes, I would support a special one-off process for the 250-odd admins that would now be caught. Say monthly warnings for 2 months, then 2 and 1 weeks before the final deadline. Would it also be easier to do the ongoing process say quarterly rather than continuously as anniversaries come up? Johnbod (talk) 13:35, 1 June 2011 (UTC)[reply]
  • Support as per Johnbod. But of course this is just talk, nothing will change, it hardly ever does here. Malleus Fatuorum 14:09, 1 June 2011 (UTC)[reply]
    Consensus seems very much in favour right now. But the "not broken, don't fix it" crowd hasn't come along in force yet to sink it again. AD 16:48, 1 June 2011 (UTC)[reply]
    • ^I'm inclined to agree. Stuff like this is fun to talk about and that's as far as I see it actually going, no matter how strong the support. Equazcion (talk) 14:44, 1 Jun 2011 (UTC)
  • Support. I'm of the mind that inertia is the only realistic reason for not implementing this change. If this was the current status quo, then changing to the current system would seem hard to defend: it could only reduce security, obfuscate the number of active admins, and I think few people would be arguing that the current system (in this hypothetical world) was unfair on those admins. I think a warning email would be a good idea. However, in order for this to go through, the process needs to be laid out so that the consensus to implement is clear (if it is). Grandiose (me, talk, contribs) 14:52, 1 June 2011 (UTC)[reply]
  • Strong support, long overdue. Wizardman Operation Big Bear 15:54, 1 June 2011 (UTC)[reply]
  • Oppose per Tothwolf and Fetchy. Killiondude (talk) 16:27, 1 June 2011 (UTC)[reply]
  • Support If someone wants to retain admin rights they just have to login and edit every year, not difficult. If someone has just disappeared, this sounds a good and long overdue move. Edgepedia (talk) 16:37, 1 June 2011 (UTC)[reply]
  • Support I'm actually amazed at how much support this is getting, usually this proposal is hijacked by the "not broken, don't fix it" crowd. Just wait till someone mentions it at RFA talk! AD 16:48, 1 June 2011 (UTC)[reply]
  • Support, with a smile to what Malleus and AD said. --Tryptofish (talk) 17:00, 1 June 2011 (UTC)[reply]
  • Support, obviously. There are potential advantages and no disadvantage. I can't see how anyone could seriously oppose this. – iridescent 17:01, 1 June 2011 (UTC)+[reply]
  • Support Why wait for another PR disaster to justify doing this? Creating an easy reinstatement procedure does no harm - shouldn't even cause hard feelings from the returning admin - and if doing so prevents one PR disaster, it's clearly worth it. Anyways, it just makes sense to keep the list of admins orderly. --JaGatalk 17:01, 1 June 2011 (UTC)[reply]
  • Support, common sense and long overdue. I'd actually make them go through RfA again rather than having them get their tools back via a crat, but that's a more minor issue.Volunteer Marek (talk) 17:22, 1 June 2011 (UTC)[reply]
Add on the hacking of active vs. inactive admin accounts; the obvious difference is that if an active admin account gets hacked, that person is likely to notice, inform the necessary parties, and the problem can quickly be nipped in the butt. But if an inactive admin account gets hacked it might take a long time before the activity (even if it's disruptive and damaging to the project) is noticed and hence there's much more of a possibility of a major snafu.Volunteer Marek (talk) 17:26, 1 June 2011 (UTC)[reply]
  • Support. Common sense. bd2412 T 17:52, 1 June 2011 (UTC)[reply]
  • Support (but for different reasons). Verifying account integrity is a basic function and shouldn't require consensus, just do what needs to be done. But why is there a presumption that administrators are appointed for life or that the proverbial mop is an entitlement that need not be returned to the bucket? Frankly, the presence of a contingent of former Wikipedians who may or may not return with administrative powers, unfamiliar with recent happenings, is kinda creepy. Any administrator who takes leave of the project ought to check back in when they return. I'm not saying they should have to re-up as a nominee, just tell everyone they're back and mean to be active again. - Wikidemon (talk) 10:07, 2 June 2011 (UTC)[reply]
  • Analysis and suggestion.
  1. Although disconcerting and very undesirable, hijacked admin accounts can't do much harm that isn't obvious and won't get a block in a reasonable time.
  2. The problem is to be sure that a long-term inactive account of an established user that resumes activity, is under the same control it was before. That's so whether or not the account was desysopped in between.
  3. Desysopping in the interim has a "feel-good" factor but doesn't actually achieve much. If reactivated user X asks for a resysop the issue is still "how do we know this is the correct account holder". But if they resumed editing after a long break as an admin the same question would be asked.
  4. The problem will get worse over time, as long standing users taking breaks or resuming editing after several years.
  5. The solution is to encourage admins to provide some way they can verify they are the correct owners of the account if needed, even if only to Arbcom or WMF. It must not rely on the email address which can be changed by the hijacker.
  6. A trivially simple example would be to ask all new admins to email Arbcom with a word, string, or textual sentence, which is harmless in itself and simply kept on the Arbcom records. If the account is hacked, the text will be known to the true account owner but probably not to a hijacker. Another way would be to provide a standard toolserver page for committed identity, making it very easy to use for verification.
  7. The policy could then be simply, "Users resuming activity as an admin after a break of more than a year, may be asked by any users to verify to Arbcom that they are the correct account holder. Administrators are advised to use one of the following methods in advance, to ensure they can do so if needed: <list>"
FT2 (Talk | email) 17:52, 1 June 2011 (UTC)[reply]
FT2, that's completely missing the point. The main issue isn't the Cool3-type hijacked or sold accounts; it's admins with knowledge of the policies of 2005, trying to enforce the policies of 2011. – iridescent 18:04, 1 June 2011 (UTC)[reply]
Can't be. Desysopping after a year's absence would not address that problem - if you stopped now and came back in a year nobody would claim you only knew the 2005 way of working (or equivalent). When would an admin be "out of date"? Consistent long term absence or low use for say 3 years or more could be a reason. So could 5+ years since their RFA. But a "one year inactivity = desysop" is not targeting "out of date knowledge". Also the header to this section makes clear it's about compromised accounts. FT2 (Talk | email) 18:11, 1 June 2011 (UTC)[reply]
Have a look at my support comment above: I suggested giving bureaucrats the discretion, at a resysopping request, to require reconfirmation RFA if activity is sufficiently low overly a sufficiently long time period. Plus, re your point 5, see my remark below about email address changes triggering a notification to the old address. Rd232 talk 18:14, 1 June 2011 (UTC)[reply]
I'd like a pint of whatever it is you're having FT2; the section title I see is "Suspend sysop rights after 1 Year of inactivity", nothing to do with compromised accounts. Malleus Fatuorum 18:23, 1 June 2011 (UTC)[reply]
Mine's a pint of spring water, then, Malleus :) Immediately after the section title: "The issue [is]... Inactive Admins... admin account was hijacked... emergency De-sysop [] to prevent possible damage... there seems no assurance that dormant account are as safe as assumed.... three years since the [] last major proposal on this was made..." FT2 (Talk | email) 18:47, 1 June 2011 (UTC)[reply]
"[...] it's admins with knowledge of the policies of 2005, trying to enforce the policies of 2011"... can you point to cases where this has previously been a problem? I'm not a fan of hypothetical scenarios being used to push for "solutions in search of problems". --Tothwolf (talk) 19:55, 1 June 2011 (UTC)[reply]
Off the top of my head, it has recently been an issue at ITN with old admins adding hooks to the main page without consensus and without adhering to ITN guidelines. I'm sure there are much more compelling cases (and I would hope others will provide them) than that out there, but I just thought I'd say that it is an issue. Jenks24 (talk) 06:39, 8 June 2011 (UTC)[reply]

Suspend sysop rights after 1 year of inactivity - arbitrary break 2

  • Support -- I don't see any particular downside to this. I agree that it should be almost-automatic to get the tools back, subject to bureaucrats' discretion. --SarekOfVulcan (talk) 18:25, 1 June 2011 (UTC)[reply]
  • Oppose. Per Tothwolf. This is also seems to be another solution in search of a problem. Ruslik_Zero 18:35, 1 June 2011 (UTC)[reply]
  • Question: "Desysopping" has naturally come to assume a pejorative connotation; is there some short euphemism, similar to, but better than, "suspension" or "mop-lifting", that anyone can think of? The administrator's done absolutely nothing wrong, any more than any other editor who takes a wikibreak; he or she hasn't attacked the Project, broken any rules, abused the rights of others or deserted Wikipedia. In fact some break from Wikipedia, even a long one if more important matters intervene, can be a healthy thing for those who get too deeply involved. —— Shakescene (talk) 18:50, 1 June 2011 (UTC)[reply]
  • Support, especially since "if an inactive admin returns to Wikipedia, they may be resysopped by a bureaucrat without further discussion." It's not quite like what Bus stop said above, that this policy "will incentivize a minimum amount of edits in a given period of time." Guoguo12 (Talk)  20:01, 1 June 2011 (UTC)[reply]
If the worst thing about the proposal is that it creates an incentive for sysops to return to Wikipedia at least once a year I don't think we have much to worry about. ▫ JohnnyMrNinja 20:14, 1 June 2011 (UTC)[reply]
  • I suggest that the crat sends an email to say that. With a link to reactivate the sysop bundle. ~~EBE123~~ talkContribs 20:54, 1 June 2011 (UTC)[reply]
  • Support, I think it will also be okay to push it to 2 years of inactivity. One question..In the spanish wiki, to be an admin you have to have an email acount, in here you don't need to?? (I said it because it said "It will also be contacted through mail if he has a valid one".--Lcsrns (Talk) 21:06, 1 June 2011 (UTC)[reply]
  • Support per my long-standing view that admin accounts may and have been compromised and gamed, as seen in the very recent User:Spencer195 fiasco. Moreover, there is a social aspect to it, as it seems that lately some admins who return after several years of relative dormancy are sorely inadequate in current guidelines, policy, and practices, which can and has frustrated the community quite a bit. I would also propose a "graduated" approach to asking for the bit back given the following conditions: those inactive over a year may ask a bureaucrat for the bit back with no problems, while those inactive for two or more years would need to go through another RFA to get it back. –MuZemike 21:40, 1 June 2011 (UTC)[reply]
  • Comment with regards to damage, with a normal account its been suggested that you can push an XfD in one direction or another. The issue with that is that actually lots of people get involved in those kinds of discussions, and so while you might be able to push a discussion from no-consensus to delete or from delete to no-consensus you aren't going to be able to do more than that - and you have to make different arguments with each different account, and use a different writing style, both of which are hard to do effectively.
  • You might be more able to influence a discussion on a single talk page with multiple accounts, but that is very small scale, and you risk getting caught if the user asks for any mediation of the dispute, and even there you have to keep your arguments different and your writing styles different - it would be really obvious if you left any tells due to the small numbers in the discussion. If hypothetically there were two people in this discussion who were actually the same person it would be pretty hard as you'd have to check every pair on the same "side", even if you knew one of them it would be pretty hard, whereas in a talk page discussion if two out of the three people on one side of the discussion started making the same tell then it would be obvious they were the same person.
  • With an admin account sure if you start being really unsubtle you're going to get caught, as the person has here, but actually its pretty clear that as an admin you get quite a bit of discretion - especially when you aren't interacting with a regular. Even more so if you were prepared to withdraw your disruptive admin decisions when they got to your talk page (or even when it got to ANI) its certainly my experience that the possibility exists that you could get away with quite a lot without anyone realising. -- Eraserhead1 <talk> 21:52, 1 June 2011 (UTC)[reply]
    • With any anonymous open-to-all internet group like we have at Wikipedia, it would be unreasonable to assume that none of our current accounts are compromised. Surely, at least some of our accounts are not the editors who originally started them, as accounts can be passed on or shared without the communities knowledge. If someone were smart and unscrupulous, they could make a business of starting and selling off admin accounts to PR firms and corporations. Study RfAs, become an admin, and then advise the buyer on how to remain unnoticed. I don't think it is likely, but it is certainly possible. ▫ JohnnyMrNinja 22:06, 1 June 2011 (UTC)[reply]
      • ...and why would people not do the same with non-admin accounts? Create a new account, vandal fight using automated tools such as a modified version of AWB disguised as twinkle (perhaps even creating the vandalism with throw-away socks), rack up several thousand edits or more and sell the account off to a similar buyer. This is done all the time with in-game currency and other non-tangible items of value, and you can't say that this hasn't or isn't occurring here. --Tothwolf (talk) 02:18, 2 June 2011 (UTC)[reply]
        • Sorry that wasn't clear, I meant that it's likely it happens across the board, and possibly with admin accounts. The anonymous nature of the site means that we will never know how many accounts are being run by someone other than the person who started the account. I meant this more as a comment on the comment before, and it doesn't actually have much bearing on the conversation at hand. If a regular account is compromised and starts making slightly different edits, but not making waves, it doesn't really matter in the long run. It's not worse than the 500 edits a day adding the word "poo" in amusing places. ▫ JohnnyMrNinja 03:06, 2 June 2011 (UTC)[reply]
          • Ah, ok, I guess I misunderstood you then. "The anonymous nature of the site means that we will never know how many accounts are being run by someone other than the person who started the account." That I do agree with. I guess the way I could sum up what I was saying above, is anytime you have something such as a user account which could have any sort of monetary value, you will also have people interested in the buying/selling/trading of such "goods". Even low-userid accounts on Slashdot have not been immune to this.

            "If a regular account is compromised and starts making slightly different edits, but not making waves, it doesn't really matter in the long run." Just to play devil's advocate for a moment, but would the same not be true for an admin account? ;P In the old days, admin functions were handled with a single shared account which lots of people had access to. Perhaps over time we've gone too far in other direction in restricting the admin bit too much and have in effect made the admin bit more "valuable" than it should be, both to those who might buy/sell/trade accounts and as a status symbol for those who have it but don't actually use the tools it provides access to? --Tothwolf (talk) 18:02, 4 June 2011 (UTC)[reply]

    • Clearly you aren't familiar with how such people operate then. If someone manages to gain access to an admin account, they are going to use the tools and that gets noticed. Abuse of non-admin accounts can go on for much longer periods of time and results in much more long term harm to Wikipedia and editor morale. --Tothwolf (talk) 02:16, 2 June 2011 (UTC)[reply]
  • Support the general principle. I'm not crazy about notifying the admin one month in advance. If their e-mail account had been compromised, sending an e-mail to them is an invitation for impostors. A Quest For Knowledge (talk) 22:03, 1 June 2011 (UTC)[reply]
  • Oppose, but not strongly so. My line of thinking is pretty much the same as fetchcomm's above. We haven't had any problem de-sysoping compromised accounts, and I think anyone that's managed to be an admin for any length of time would have the sense to look around to see what's changed. (at least I'd hope so). — Ched :  ?  01:18, 2 June 2011 (UTC)[reply]
  • Support. Don't think it'll be that big a win in terms of protection from compromise, but I don't perceive any tangible disadvantage; and while I'm a respecter of tradition, I don't think this one has anything but inertia behind it. Choess (talk) 03:39, 2 June 2011 (UTC)[reply]
  • Support—It's surprising this procedure doesn't exist already; important for the protection of the project and us as editors. Tony (talk) 03:48, 2 June 2011 (UTC)[reply]
  • Oppose, further discussion on both issues is necessary (account security, and the problem of inactive admins). This proposal in its current form doesn't solve either problem. --Chris 06:24, 2 June 2011 (UTC)[reply]
  • Support -- industry best practice to prevent identity theft should be regarded as an essential precaution for the protection of both readers and editors, and not a right for the duration of the account. --Ohconfucius ¡digame! 08:05, 2 June 2011 (UTC)[reply]
  • Support - Admin tools never expire? Why? Lightmouse (talk) 09:53, 2 June 2011 (UTC)[reply]
  • Support, deactivating inactive accounts is generally a good practice in terms of securing computer systems. In regard to the security issues, I would suggest that there is also a danger from a hacker who does not make their presence known, since since admins have access to places normal editors do not. I do not think we should assum that we can spot a bad actor by their bad actions. There's no emergency here, but if we notify inactive admins and create a low bar for an automatic bit flip, I see little down side. --Nuujinn (talk) 10:09, 2 June 2011 (UTC)[reply]
  • Oppose - We've only had 2 cases where former admins had their accounts hijacked, one being User:RickK and the other I forgot. But I remember seeing MULTIPLE Signpost articles about current admins having their accounts hijacked, there was one last year involving 5/6 IIRC. This proposal just adds unnecessary work for stewards and the threat lies purely with current admins. —James (Talk • Contribs) • 10:10pm • 12:10, 2 June 2011 (UTC)[reply]
    I don't know if there is a list somewhere, and these aren't easy to research, but User:RickK, User:Spencer195, User:Vancouverguy, User:Zoe (best quote ever). These are the ones that I saw before I got tired of cross-referencing. There don't appear to be a ton of admins that were banned for being compromised after a period of inactivity. These are the ones that made it obvious enough that they got banned instead of de-sysoped or going unnoticed. It's not like there is a noticeboard that admins post to when they come back from a 3 year furlough and now have different interests. ▫ JohnnyMrNinja 14:09, 2 June 2011 (UTC)[reply]
    "The threat lies purely with current admins" is an odd thing to say given that this proposal was sparked in part by a 6-year-inactive admin account being recently compromised. 28bytes (talk) 15:20, 2 June 2011 (UTC)[reply]
If there is a problem with current admins being hijacked, that suggests we should also improve security for them. That might include requiring secure login, committed identity and minimum password length. But that should be a separate proposal, and it doesn't argue against the current proposal.--agr (talk) 16:26, 2 June 2011 (UTC)[reply]
  • Support The fact that we continue to use the default of keeping permissions in place indefinitely just because there is no policy stating otherwise is foolish and contributes to the perception of admin as a rank, status, or award. I do not find any of the opposes to be convincing in any way as this proposal does no harm to the project, and may have the ability to protect it. Even if the occasion of a compromised account is rare, there is no good reason to leave the temptation out there as a juicy target for those who seek to do damage. Suspension of admin rights on inactive accounts is easily reversible, and should be subject to the discretion of Crats to ensure that returning admins are up to date on policy changes. This can be as simple as the word of the returning admin if a crat is satisfied with that. Jim Miller See me | Touch me 13:45, 2 June 2011 (UTC)[reply]
  • Support - this seems like a reasonable step to give some protection against hacked accounts and folks with out-of-date knowledge. Is it perfect? Of course not, but it would be a step better than leaving these accounts on the books, and the opposers have not convinced me of any actual harm in doing it. Slight positive with no negative yields a net positive for the project. LadyofShalott 14:16, 2 June 2011 (UTC)[reply]
  • Support I take the point that inactive accounts are no more likely to be compromised than active ones. However, active ones are doing good, while inactive ones are not - so there's no loss to suspending rights. Further, we will eventually get to the point where inactive accounts outweigh actives ones - so removing the inactive ones will significantly lower the total number of accounts, which can't but improve security. Note, I am supporting this only on the basis that it is a no-fuss easily reversed suspension. The gain is not sufficient to justify the bureaucracy involved in any process for retrieval of rights. Bureaucrats should by default restore on request (always allowing for an exercise of common sense in exceptional circumstances).--Scott Mac 17:11, 2 June 2011 (UTC)[reply]
  • Support I endorse the concept of not having dangling privileges out there for any holder of advanced privileges beyond a specific date of inactivity. We don't want people who successfully got autopatrolled to go on a extended holiday and come back writing new articles very questionable conformity to standards. Equally, If an admin is inactive for over a year and a half, I want them to do some editing first to demonstrate that they understand policies before we hand the keys to the janitorial supply closet back. Yes it means a fractional increase in the amount of work the Burecrats will do, but in the long run it reduces the possibility of actions not in confirmity with the community's consensus. Hasteur (talk) 20:46, 2 June 2011 (UTC)[reply]
  • Oppose - As written, this just creates a false sense of security (albeit for something that isn't really a significant security risk). As long as the desysopping can be undone by a simple post to WP:BN it's like taking away someone's keys and then hiding them under the doormat. The "identity is not in dispute" clause does little to mitigate this because unless they're acting strangely there would be no grounds for such a dispute. The only way this would work would be to reverse the clause and somehow require positive confirmation of identity and/or require all of them to do a reconfirmation RFA. Mr.Z-man 22:16, 2 June 2011 (UTC)[reply]
    • Forcing them to appear publicly and re-request the permissions brings them to light. People would be much more likely to notice suspicious behaviour then, whereas they wouldn't if they were just allowed to start using their admin powers again without having to get them back from a bureaucrat. -- Eraserhead1 <talk> 22:23, 2 June 2011 (UTC)[reply]
      • Spencer195 did nothing suspicious after returning and was still caught before causing any damage. Vancouverguy was blocked within 3 minutes of making an edit. RickK and Zoe turned themselves in. Looking for "suspicious behavior" is just as vague as "identity is not in dispute." What would be suspicious without also being obvious? I would presume that if someone is capable of hacking an inactive admin account, they're also capable of lying low for a few days. Mr.Z-man 22:56, 2 June 2011 (UTC)[reply]
    • "[...] it's like taking away someone's keys and then hiding them under the doormat." Except that the keys aren't even being hidden under the doormat, they are sticking out of the lock on the door. --Tothwolf (talk) 18:16, 4 June 2011 (UTC)[reply]
        • Because most people don't spend all their time following the logs, it would be possible to admin in a poor manner, or just use the powers to view deleted content etc.
        • And while the keys might be on display to extend your analogy they have to walk into the courthouse and publicly register with the court clerk that they want their keys back. -- Eraserhead1 <talk> 18:18, 4 June 2011 (UTC)[reply]
          • "Because most people don't spend all their time following the logs," Perhaps you don't, but others do spend a good deal of time removing changes and logs.
            "it would be possible to admin in a poor manner," Uhm, and this has already happened many times without accounts being compromised.
            "or just use the powers to view deleted content etc." ...and why would it ever matter if someone could view deleted content? We aren't talking about oversighted material here.
            "they have to walk into the courthouse and publicly register with the court clerk that they want their keys back." No, a court clerk would require some form of positive identification. In this case the person operating the account only has to make an anonymous post to a noticeboard with no further identification in order to have the admin bit restored. --Tothwolf (talk) 19:16, 4 June 2011 (UTC)[reply]
        • You keep banging on about password strength Tothwolf, but that's a very small part of the picture. Were I so inclined I could very easily get hold of the password for one of the long-abandoned admin accounts, without having to bother with a password-cracker. Malleus Fatuorum 18:22, 4 June 2011 (UTC)[reply]
          • Indeed it is a small part of the overall picture, but removing the admin bit itself fixes absolutely nothing. "Were I so inclined I could very easily get hold of the password for one of the long-abandoned admin accounts, without having to bother with a password-cracker." As could a good many "well established" editors, and that would not be limited to "long-abandoned" accounts either. That however, is an argument for RfA reform. Given that, why would anyone ever even need a password cracker? (I won't say much more on that per WP:BEANS.) --Tothwolf (talk) 19:22, 4 June 2011 (UTC)[reply]
            • I think I already said that there's no need of a password-cracker. as for RfA, well, that's just a hopeless basket-case. But one thing it fixes is the persistent illusion that wikipedia has 1800 administrators. Which it might do, but only if you believe in zombies. Malleus Fatuorum 19:31, 4 June 2011 (UTC)[reply]
              • "[...] as for RfA, well, that's just a hopeless basket-case." I previously thought the same thing about some other things here on Wikipedia, but those eventually began to change, so even if it is optimistic thinking at this point, I hope RfA does begin to improve. --Tothwolf (talk) 19:41, 4 June 2011 (UTC)[reply]

Suspend sysop rights after 1 year of inactivity - arbitrary break 3

  • Support Sounds like simple common sense. A year is an awfully long time, after all. Andrew Lenahan - Starblind 01:05, 3 June 2011 (UTC)[reply]
  • Support - I like RD232's caveats, and I think a good faith straightforward resysop for admins whose conduct has not been egregious before a long break is not bad either. I like the idea of getting a better idea of admin numbers. Casliber (talk · contribs) 01:52, 3 June 2011 (UTC)[reply]
  • Provided good-faith re-sysop process exists, this is quite reasonable -- Samir 03:38, 3 June 2011 (UTC)[reply]
  • Support - I agree this is just common sense. --Kumioko (talk) 03:53, 3 June 2011 (UTC)[reply]
  • Support - Once again, this is common sense. Swarm X 00:45, 4 June 2011 (UTC)[reply]
  • Support. Standard good security practice. Per Nuujinn above, the problem is not only with what admins can do, but with what they can see. An "inactive" account could be being used unethically and we wouldn't know.  —SMALLJIM  13:06, 4 June 2011 (UTC)[reply]
  • Oppose Per the reasons that lead to the rejection of Wikipedia:Inactive administrators and Wikipedia:Requests for adminship/desysop poll. Any proposal that removes permissions based on temporary inactivity will make it less likely that admins return to their former activity, even if the barrier is low. Per Wikipedia:PEREN#Demote inactive admins, inactive accounts are much less likely to be compromised than active accounts, so the security angle is not really a good reason to support this proposal. And as Mr.Z-man notes correctly above, a low barrier solution will be completely useless because a simple request to WP:BN is not suspicious at all if you don't act completely stupid. Someone could hijack an account, re-request the mop, wait a few weeks and then run amok. People would only be more alert the first few days after the request, not for weeks or months. And any higher barrier like a new RFA will just lead to those users never returning at all. Regards SoWhy 18:06, 4 June 2011 (UTC)[reply]
    • I don't think you can a complete break of a year "temporary". I think some evidence needs providing for inactive accounts being less likely to be compromised, they are probably much more likely to be compromised as the real account holder isn't around to figure out what has happened.
    • The point about a low barrier solution is that it forces the inactive user to step forward publicly and given its unlikely to happen they are an obvious user to keep an eye on, whereas without it they can run amok without publicising themselves, and most people don't spend their time checking through the logs to detect these things. -- Eraserhead1 <talk> 18:12, 4 June 2011 (UTC)[reply]
      • Why not? If I have to work in a part of the world for a year that has no internet, I do intend to come back after that period. "Temporary" just means "for a certain period of time", it does not mean "for a short time". So the burden of proof that those people really do not intend to come back falls on those who wish to desysop them. As for the likelihood, the devs have said so, so we could probably ask them. But I think there are several reasons to assume that this is true. As far as I know, often accounts are compromised by tricking an admin or by hijacking it using a manipulated script or website. Those methods only work when the admin is active. On the other hand, the only way to take over an inactive admin's account is by brute-forcing / guessing the password, hacking their mail account and requesting a new password or by exploiting a vulnerability in MediaWiki. All those methods work the same for active admins though, so there is no method that works better just because someone is inactive. If someone got into my account while I was away on vacation, it would be the same as if I had been inactive for three years. As for the other argument, I think there was plenty evidence provided above that compromised accounts will be spotted quickly anyway once they run amok, so there is no benefit in the "stepping-forward". Regards SoWhy 19:00, 4 June 2011 (UTC)[reply]
        • Firstly where in the world doesn't have internet access? And in the extremely unlikely case someone going somewhere where internet access is very limited - not that I can think of any - then they can request re-sysop on their return, or they can tell people before they leave that's what they are doing.
        • The fundamental difference with an active account is that the active user is around to complain about anyone taking over their account. -- Eraserhead1 <talk> 19:12, 4 June 2011 (UTC)[reply]
          • Quite. And the point that reactionaries like SoWhy are so reluctant to address is that if the present system is allowed to continue then one day there will be more wikipedia administrators than there are people alive on the Earth. It's already ridiculous to see claims that there are something like 1800 administrators; what there are are perhaps 1800 users who have passed RfA, some of whom are undoubtedly now dead and others who have lost interest. Malleus Fatuorum 19:18, 4 June 2011 (UTC)[reply]
          • Actually, taking a year or more off isn't that uncommon. Why? To start with, see Conscription and Peace Corps. --Tothwolf (talk) 19:32, 4 June 2011 (UTC)[reply]
    • "...a low barrier solution will be completely useless because a simple request to WP:BN is not suspicious at all if you don't act completely stupid. Someone could hijack an account, re-request the mop, wait a few weeks and then run amok." - that doesn't make it "completely useless", it makes it less than perfect. It's also why I specified condition (ii) in my Conditional Support: "after desysopping, 1 month of reasonable activity levels required after return, before resysopping on request at WP:BN." That requires slightly more commitment by a hijacker, and more chance of detection of something amiss before getting admin rights. It's also an approach which is particularly relevant when you think about the significance of access to Viewdelete rights (see discussion below). Rd232 talk 17:44, 5 June 2011 (UTC)[reply]
  • Support Someone not using the tools won't really miss them. -- WOSlinker (talk) 21:49, 4 June 2011 (UTC)[reply]
  • Support. Wikipedia needs editors who are ready, willing, and able. An absentee admin is of no use to the project.--Brianann MacAmhlaidh (talk) 06:20, 5 June 2011 (UTC)[reply]
  • Support I see no reason no reason to say no --Guerillero | My Talk 18:02, 5 June 2011 (UTC)[reply]
  • Obvious Support; the sysop bit is no big deal, it would be nice to get a better sense of our actual admin #'s and I don't see any issue with inactive editors beign de-sysopped. --Errant (chat!) 20:02, 5 June 2011 (UTC)[reply]
  • Support; it mitigates a real risk at minimal cost. Removing some rights from long-idle accounts is best practice in IT security - I would point out that the current proposal is considerably lighter (much longer period and much smaller change to user rights) than is the norm in the organisations I advise. bobrayner (talk) 23:59, 5 June 2011 (UTC)[reply]
On voluntary removal of admin rights. Good idea, but already covered.
The following discussion has been closed. Please do not modify it.
WP
Furlough

Based on the ideas here, and reading through the older discussions, I started work on Wikipedia:Furlough. The idea is that it is sort-of a wikibreak from admin rights. I know in the past that admins have stepped down due to real-life concerns, and this could be used in those instances as well. For now I redirected the talk page back to the above discussion. Please feel free to edit it. ▫ JohnnyMrNinja 04:21, 3 June 2011 (UTC)[reply]

Just to clarify, I am making an assumption here, that users supporting the above proposal for inactive admins would also support it for active admins on a voluntary basis. It is my feeling that the same logic applies in either scenario. If this is not the case, I don't wish to through a monkey wrench in at this point, and am willing to withdraw that portion of the proposal if asked. My thinking is that it will at the same time make the new procedure more useful and less threatening. ▫ JohnnyMrNinja 04:53, 3 June 2011 (UTC)[reply]
Pardon me if I am misreading your proposal, but you seem to be trying to establish a system not of involuntary desysop after prolonged absence as proposed above, but of admin-initiation voluntary suspension of rights. The thing is, the latter system is already in place – admins can voluntarily resign and go on a furlough anytime they want, with full expectation of rights being restored unless controversial. I am on such a furlough right now. So what would change under your proposal? Skomorokh 11:12, 3 June 2011 (UTC)[reply]
Indeed - administrators can already request removal of rights (at m:SRP) and restoration per the terms at WP:RESYSOP. –xenotalk 13:32, 4 June 2011 (UTC)[reply]
Oh, I hadn't seen that. Never mind, I'll delete it. ▫ JohnnyMrNinja 13:39, 4 June 2011 (UTC)[reply]
  • Oppose – This just seems like we aren't attacking the root of the issue—insecure passwords. Forcing all admins to make their passwords a certain strength, and resetting old admin passwords (along with sending emails to the confirmed emails) that aren't as secure, would be a better way to solve the actual issue, which is a security issue. Desysopping doesn't actually solve the issue, and active admins could also be targeted if they have insecure passwords. —mc10 (t/c) 01:01, 7 June 2011 (UTC)[reply]
    • That sort of thing can be done in addition (and I'd welcome more input at Wikipedia:Village pump (proposals)/Account security). But you seem to overlook the fact that many inactive admins may now not have valid email addresses specified (or if they do, may ignore requests to improve password strength, whilst sending out new passwords blindly is bad security practice and liable to piss people off to boot). Desysopping is a simple and effective solution for improving security in relation to people no longer participating in the project. Rd232 talk 02:09, 7 June 2011 (UTC)[reply]
  • Support per 28bytes and bobrayner. Shubinator (talk) 02:45, 8 June 2011 (UTC)[reply]
  • Support. I took a multi-year wikibreak once (before I was an admin), and if I took another I would hardly be astonished or upset if upon returning I found a message on my talk page telling me that my privileges had been suspended due to inactivity. Some other Wikimedia projects have activity requirements for admins, some harsher than what is proposed here. This is the sort of obvious security measure that should have been part of adminship from the very beginning. Should there be other security measures? Yes, and that is being discussed elsewhere. And yes, a savvy hacker might defeat this measure and others proposed as well. But that does not mean this idea isn't helpful; a single change does not need to solve every problem to be a good idea. --RL0919 (talk) 15:09, 8 June 2011 (UTC)[reply]
  • Support Not convinced of a substantial security risk but the real question is why this wasn't implemented before. 1 edit a year or the inconvienance of posting once annually on BN (which would seem to count as that one edit) isn't exactly much to ask. Bob House 884 (talk) 21:33, 8 June 2011 (UTC)[reply]
  • Oppose per the general 'solution in search of a problem' argument. I simply don't see what benefit this offers. The disruption which could occur from a compromised admin account is the same for an active one as for an inactive one. The probability of one being compromised depends on the security of their password, not on their level of activity. And the likelihood of a compromised account being spotted depends on how conspicuous their mischief is: deleting the Main Page is quite obvious but viewing deleted revisions is not. This proposal really makes no difference. ╟─TreasuryTag►assemblyman─╢ 09:08, 9 June 2011 (UTC)[reply]

Comment: I'm amazed people are still questioning the benefits of this (obviously people may have differing opinions on whether the benefits are worth the costs). Let's clarify the logic. The risk we're trying to mitigate is that to Wikipedia, i.e. the risk of any admin account being breached.

Define: A = number of active admin accounts, I = number of inactive admin accounts (definition of inactivity doesn't matter for the logic, but let's say no edits for 1 year, as per proposal) Define: S1 = insecurity of active accounts (0-1 variable: 0=perfect security, 1=complete insecurity), S2 insecurity of inactive accounts. Then

Risk of any admin account being breached = (A * S1) + (I * S2)

For there to be zero benefit from the proposal, either I needs to be zero (no inactive admin accounts), or S2 needs to be zero (i.e. inactive accounts have perfect security). Clearly neither is true, and therefore the proposal has security benefits, by reducing I to zero. Quod erat demonstrandum. Rd232 talk 09:46, 9 June 2011 (UTC)[reply]

I'm not sure that an equation is the best way to look at this. The only way this proposal could have benefit is if it decreases S2 – and I, along with several others by the look of it, don't see that it does. The other point is that initiating a major change must have not just some benefit beyond zero, but a significant benefit. And as I've pointed out just above, there is no greater risk of an inactive account actually being compromised than an active account; no greater potential for disruption; and no decreased possibility of it being spotted simply due to its inactive status. I agree that compromised admin accounts in general are a problem, but this proposal seems to only focus on one arbitrary part of that problem. ╟─TreasuryTag►without portfolio─╢ 10:00, 9 June 2011 (UTC)[reply]
"I'm not sure that an equation is the best way to look at this." - it is, it makes it clear and simple. I'm sorry you still don't get it. Rd232 talk 10:31, 9 June 2011 (UTC)[reply]
Or perhaps I (and the other opposers) do get it but simply disagree with you? ╟─TreasuryTag►tortfeasor─╢ 10:35, 9 June 2011 (UTC)[reply]
I'm not talking about all opposition, I'm talking about people denying that the proposal has any security benefit. The equation proves this is untrue. Rd232 talk 11:02, 9 June 2011 (UTC)[reply]
In short, I feel that the proposal is vaguely like the police saying, "In order to fight crime, we're going to randomly select ten ordinary houses and station officers outside them round the clock." Yes there is obviously a benefit above zero, because those ten houses will be safe from burglary, but they were no more likely to be burgled than any others to begin with. Concentrating security efforts on an arbitrary group of potential targets is a bad approach for all sorts of reasons. ╟─TreasuryTag►high seas─╢ 10:04, 9 June 2011 (UTC)[reply]
What part of deactivating unused accounts with high privileges is random? It's nothing like your analogy, it's more like deactivating keycards from employees who haven't been seen or heard from in a year. Rd232 talk 10:31, 9 June 2011 (UTC)[reply]
What part of deactivating unused accounts with high privileges is random? It's not random but arbitrary: a subtle distinction. Is there anything about an inactive account which makes it easier to compromise? Yes or no? ╟─TreasuryTag►tortfeasor─╢ 10:35, 9 June 2011 (UTC)[reply]
Your question demonstrates that you have not understood the equation. It is irrelevant whether S2 is greater than S1 (which it obviously is, the discussion at the security RFC indicates why), the only thing that matters is that the total security risk from inactive accounts is simply I*S2. That total risk can be reduced to zero by the proposal ("yes or no?"). PS how is targeting inactive accounts arbitrary? "Yes I don't work here any more but deactivating my keycard is arbitrary, what about the people who still do?" Rd232 talk 11:02, 9 June 2011 (UTC)[reply]
People no longer working for a specific employer traditionally go through a slightly more formalised process than people who simply don't use a particular online login for x months. ╟─TreasuryTag►Alþingi─╢ 11:04, 9 June 2011 (UTC)[reply]
So? You're nitpicking about the analogy, which is funny given the extraordinary weakness of your police officer analogy above. Bottom line: deactivating unused high-privilege logins is standard security practice. Rd232 talk 11:28, 9 June 2011 (UTC)[reply]
...given the extraordinary weakness of your police officer analogy above. Since you seem not to be behaving with the politeness and open-ness to others' points of view which I generally see from you, I'll withdraw from this line of discussion. ╟─TreasuryTag►constablewick─╢ 11:51, 9 June 2011 (UTC)[reply]

Viewdelete rights

Comment: Nuujinn above touched on a point that hasn't been brought into this discussion thus far, and should radically change the balance of costs and benefits when the implications are fully considered. Admins have Viewdelete rights (that is, the ability to access deleted material). It is long established as Foundation policy that only those who have gone through the relative rigours of RFA may access deleted material (for legal reasons, I think - perhaps someone could confirm). The assumption of all in this discussion thus far (including me) has been that the sole risk of hijacking of an admin account is damage. Introducing the role of Viewdelete rights casts this in a very, very different light. An attacker may silently view unknown amounts of deleted material, potentially putting it to all sorts of uses - without their presence being known. This aspect raises the stakes for all aspects of the security being debated, including the suspension of sysop rights, but also of other measures discussed in the section below. Rd232 talk 13:57, 2 June 2011 (UTC)[reply]

  • I considered that above, and there's really no way to deal with this. I could have my account compromised, and no edits/logged actions made. The "hacker" could simply use it to read deleted pages and no one would be the wiser. (I don't think CU can check to see the IPs where I log in only, without editing.) So desysopping doesn't necessarily solve this—as long as there is one admin account with a weak password, all deleted revisions are susceptible. One way of solving this is for MediaWiki to a) not allow weak/short passwords and b) send an email every time someone puts in the wrong password, say, 3+ times for an account. /ƒETCHCOMMS/ 23:01, 2 June 2011 (UTC)[reply]
    Would it not be possible, hypothetically, for viewing deleted revisions to be a logged action visible to Oversighters or Checkusers? ╟─TreasuryTag►Woolsack─╢ 23:04, 2 June 2011 (UTC)[reply]
    That would require logging the pages that individual users view. It could be done, but I don't know that everyone would be too fond of the idea. There would be very little standing between these volunteers and your browsing information. ▫ JohnnyMrNinja 00:40, 3 June 2011 (UTC)[reply]
    We shouldn't discount the possibility that a disaffected admin could have sold on his account details.  —SMALLJIM  14:16, 4 June 2011 (UTC)[reply]
    I already pointed that out above. --Tothwolf (talk) 18:20, 4 June 2011 (UTC)[reply]
    • Is the bundled viewdeleted bit even that big of a deal? Sensitive things should be oversighted, not revdeleted, otherwise why bother even having the oversight permission bit and all the extra steps required to hold it?

      Perhaps we should consider something along the lines of the system which Gmail has in place? It logs the IP addresses of those who login or attempt to login to an account and that history is maintained for a set amount of time. The access history is visible to the person who operates the account and IP addresses which are out of the ordinary for the history of the account are listed differently. This type of information could even be combined with an email notification to the email address linked to a particular Wikipedia account. --Tothwolf (talk) 18:33, 4 June 2011 (UTC)[reply]

      • Yes it's a big deal. "Sensitive things should be oversighted, not revdeleted, otherwise why bother even having the oversight permission bit" - sorry, that's just ignorance of the history. Oversight has been around a lot longer; RevisionDeletion opens up a similar, more accountable and transparent version of oversight to all admins, leaving the old oversight tool for only the most sensitive cases. In addition, oversight is a red herring for pages where the entire content is deleted (AFAIK oversight is rarely used in that instance). Bottom line, repeated proposals to unbundle viewdelete rights have always foundered on the Foundation's requirement that the rights be kept limited - because otherwise, if too many people can see it, the material is arguably not really deleted, with potential legal consequences. Rd232 talk 17:38, 5 June 2011 (UTC)[reply]
        • Hey Tothwolf, I thought the same thing before (see Wikipedia:Village pump (proposals)/Persistent proposals/Straw poll for view-deleted). I was so confident that I emailed the WMF's legal council who immediately torpedoed the whole thing and told us what a bad idea it was. It was going fairly well up to that point... ▫ JohnnyMrNinja 17:43, 5 June 2011 (UTC)[reply]
        • Sorry but I'm not buying it. Sensitive material should be oversighted and not simply revdeleted. Anything else (revdeleted vandalism, copyvios, deleted articles, etc) are not that sensitive and are not sufficient for justification for the proposal to remove the admin bit from inactive admins. Besides, as pointed out above, even if someone breached an account which had the admin bit removed, the person who breached the account could as easily just ask for the admin bit back and they could then see revdeleted material anyway. We have a separate election and special requirements for those that hold the oversight permission for a reason. --Tothwolf (talk) 05:17, 6 June 2011 (UTC)[reply]

Incidentally, the actual user right is called "deletedhistory" [6] - I misremembered it. Rd232 talk 18:17, 5 June 2011 (UTC)[reply]

I thought a brief summary of the issue might be helpful - cf WP:Viewdelete. Rd232 talk 18:33, 5 June 2011 (UTC)[reply]
FYI the bundle normally referred to as "viewdeleted" contains three separate rights: deletedhistory, browsearchive, and deletedtext. Only the last one allows you to actually view the deleted revisions. –xenotalk 15:27, 8 June 2011 (UTC)[reply]
Thanks. I've updated Wikipedia:Viewing deleted articles to match. Rd232 talk 17:15, 8 June 2011 (UTC)[reply]

Wikipedia:Village_pump_(proposals)/Account_security#Limit_viewdeleted_rights_for_admin_accounts. Rd232 talk 11:52, 9 June 2011 (UTC)[reply]

Admin account verification and admin know-how

There are two issues.

Long term inactive admin accounts are not really a problem based on whether or not to desysop. The problem is confirming that the account holder is legitimate after a long absence, and this is so whether or not the account retained the bit in between. Whether they remain a sysop while inactive, or didn;t keep the bit but request its restoration on reactivating, the question is still how to verify the user is the same person who should own the account. This also helps a lot on hijacked account cases too.

Proposal - that the following is added to policy:

Administrator accounts are to be used only by the individual to whom adminship was granted. In circumstances giving rise to concern, the account owner may be asked to verify that they are the legitimate owner of the account. This does not imply any personal identification, rather it implies knowing something that only the original owner would be likely to know. Administrators unable to verify their legitimacy to the community or Arbcom may be required by clear consensus or bureaucrat discussion to reconfirm their RFA.

Administrators are therefore advised to ensure that they have a means to verify their account ownership. Suggested methods include:

  • A word, string of characters, or other text known only to the user, submitted to Arbcom or a willing member of the Foundation to be held by them.
  • A committed identity string on their user page or (more secure) sent to Arbcom

With regard to out of date knowledge the issues are - how long does it take for admins to get out of date? Can active admins be out of date as well? Should all admins be required to demonstrate up to date know-how in some way, every 5 years?

FT2 (Talk | email) 18:39, 1 June 2011 (UTC)[reply]

In my opinion, I don't think we need a fancy way. The discussion above concluded that BN isn't going to be flooded with requests, they'll be quite rare (if at all). So, when one goes to the effort of posting there, you're going to be noticed. And checked. Quite apart from the actual message you leave, it wouldn't be difficult to keep these people "on the radar" for a while. On the second point, it sort of follows that because someone's checking, then they can be referred to an appropriate venue if their timeout is affecting the project, and their ability to use the mop.Grandiose (me, talk, contribs) 18:56, 1 June 2011 (UTC)[reply]
"You're going to be noticed. And checked." Checked how? This point is about making sure we can check, encouraging admins to take measures to ensure their account ownership is verifiable (which is a good thing anyway), and ensuring users are aware that if ownership can't be verified a reconfirmation RFA could be needed as the result of WP:BN discussion. FT2 (Talk | email) 19:30, 1 June 2011 (UTC)[reply]
Checked by observing behaviour. Anything else is, for this type of internet account, just a false sense of security. Rd232 talk 20:07, 1 June 2011 (UTC)[reply]
In observing behavoir the biggest hint will be the post to BN. Posting on BN is the least likely thing a person in control of an account would do, and with good reason. It flags them up for special treatment, people notice they're around again, the records will be checked at that instance, and there will be some sort of blurb about the fact they've come up to trip up on. It's also got a deterrent effect. Grandiose (me, talk, contribs) 21:35, 1 June 2011 (UTC)[reply]

We could simply require all admins to send a committed identity hash to arbcom (or even just have it on their userpage, but then people could guess the word and know for sure it was right before asking for the tools back). /ƒETCHCOMMS/ 19:05, 1 June 2011 (UTC)[reply]

If anything committed identities are weaker than passwords. Prodego talk 19:08, 1 June 2011 (UTC)[reply]
That seems like (a) hassle and (b) an extra point of security failure, both in terms of having a list that might be misused (and then falsely trusted, because it's "verified"), and in terms of admins losing the relevant data and not being able to get back. At the same time, the risk of admins losing that data raises the possibility of exceptions being made in practice even if theoretically excluded ("I lost my data"), and that possibility might be exploited by a hijacker. Rd232 talk 20:05, 1 June 2011 (UTC)[reply]

Unnecessary attempt to fix a problem that doesn't exist. When we have one restoration of rights to a bad user, then we can try to fix the problem. In the meantime, crats are picked for good judgement and if something looks dodgy they can ask questions. No crat can be compelled to do anything they think unwise.--Scott Mac 17:23, 2 June 2011 (UTC)[reply]

I have seen a lot of editors say that this is a problem looking for a solution. Well, that's partly true, that's the nature of preventative maintenance; to stop problems before they become problems. We shouldn't wait until a traffic accident to buy insurance, we shouldn't wait to build a crosswalk until someone gets hit by a car and we shouldn't wait to remove an unused and uneeded permission from an unused account. It has happened and eventually it will happen again, if it hasn't already and just hasn't been noticed. Aside from that it also removes them from associated things like AWB which if used by a rogue could do a lot of damage in a short time. It also removes the privilage so that if someone goes looking for a helpful admin they aren't distracted by one that's been gone since 2006. As was mentioned before if they have been gone for a year their probably not coming back and if they do they can just ask for it back. One last bit of reasoning to do this is that if they are gone for a year a lot of rules have changed and if they just jump back in the saddle one day they could unwittingly mess up something that changed months ago. --Kumioko (talk) 03:50, 3 June 2011 (UTC)[reply]
I think you are in the wrong section. I've supported suspending after a year. I'm questioning the need for form-filling additional checks before restoring.--Scott Mac 16:38, 4 June 2011 (UTC)[reply]

Touched field

FYI: the mw:User table stores the timestamp from the last time that a user has performed any action, including logging in. I mention this because there is some discussion here about knowing what the "real count of admins" is, along with all of the other stuff. It would be fairly easy to create an extension which would use this data in some useful manner (or even add to it). I'm fairly certain that there's already an extension or two that does something along the lines of what is being sought for, here. There's no need to recreate the wheel, here. :)
— V = IR (Talk • Contribs) 13:48, 4 June 2011 (UTC)[reply]

Consensus

This has been open over a week now, and with 59 supports and 14 opposes (that I could see) this is pretty much clear consensus to implement (I have voted here though, so am biased). Only 10 years too late! :-) Can someone uninvolve close? How are we going to do this? AD 18:34, 8 June 2011 (UTC)[reply]

IMO, as an RFC-style discussion, the usual period of 30 days should be allowed. –xenotalk 19:22, 8 June 2011 (UTC)[reply]
Yea, there's no rush. We should talk about implementation details first as well. Bureaucrats are going to be the ones taking on the workload here right? It'd be nice to see some "as a Bureaucrat I think it would be best to..." comments here, since we're apparently trying to tell them how to do their work here.
— V = IR (Talk • Contribs) 19:30, 8 June 2011 (UTC)[reply]
OK agree with leaving it open longer, but bureaucrats won't be having any workload at all - it'll be stewards doing the actual deadminning. If an inactive admin meets the criteria, any person should be able to request removal of rights on Meta. (And stewards aren't bothered about workload - loads of projects remove inactive admins). AD 21:17, 8 June 2011 (UTC)[reply]
If the proposal carries, I think a less chaotic method should be used than "just anyone post to m:SRP when an admin hits the 1-year inactive mark" - I would suggest a monthly or quarterly posting or a software-based method. And bureaucrats will presumably have a role in this if an inactive administrator re-activates and requests WP:RESYSOP. –xenotalk 12:39, 9 June 2011 (UTC)[reply]
Agreed. Also it shouldn't be done on meta anyway. Probably a regular bot sweep would be the simplest (it could probably do warning emails automatically, and maintain a list of those who still haven't edited a month after warning, and bureaucrats can respond to the list as and when). Rd232 talk 13:12, 9 June 2011 (UTC)[reply]
Well, even if bureaucrats were given the task of reviewing and verifying the lists, the actual removal requests would eventually have to make their way over to m:SRP - at present, Stewards are the only ones with the technical ability to remove the sysop userright (well, developers too, but they only act on userrights in exceedingly rare cases). –xenotalk 13:38, 9 June 2011 (UTC)[reply]
Oh, I'd forgotten that. Bloody silly if you ask me. Wasn't there an RFC about giving bureaucrats the technical ability to desysop, to be used solely at specific direction of the community? If this proposal is adopted, I think it should be revisited. Rd232 talk 17:43, 9 June 2011 (UTC)[reply]
I think the most recent discussion was Wikipedia:Requests for adminship/Bureaucrat Unchecking (see also /Poll). Not sure where it went from there (if anywhere). –xenotalk 17:52, 9 June 2011 (UTC)[reply]
If we're going to keep this open for several more weeks, maybe we should move it to a subpage? Rd232 talk 13:12, 9 June 2011 (UTC)[reply]
Not a bad idea. –xenotalk 13:38, 9 June 2011 (UTC)[reply]
  • And the strengths of the opposition? Not really any. Point is, deadminning inactive admins is going to help improve security, whether a little bit or a lot. The fact that it is a perennial proposal only means that it has been proposed a lot. This time, thankfully, so far consensus has changed in favour of implementing a deadminning process.
  • You can try and claim that it is in the best interests to keep inactive admins forever, long after they're dead etc, but the many points raised by supporters ultimately show this is a good idea. As I already mentioned, it's only an accident that a desysopping procedure wasn't put in place originally - because it wasn't anticipated Wikipedia would last this long. Now it's become necessary. AD 21:38, 9 June 2011 (UTC)[reply]
I could not disagree more. There is no reason to oppose this proposal just because it hasn't been done before. Every idea in WP:PEREN is open to new discussion because concensus can change. Automatically dismissing an idea just because it is on that list is a failure to WP:AGF on the part of new participants to the discussion - the community changes too. PEREN is not a graveyard of bad ideas, just a place to list things that have had multiple discussions and not been agreed to so far. To paraphrase another widely quoted and important policy, "WP:PEREN is not a suicide pact." We have no business dismissing an idea just because it has been dismissed before. Not a single oppose opinion has provided a legitimate reason that this proposal should not be implemented. It has been pointed out by many people that removal of permissions is a standard best practice in IT security. The only valid argument I have seen against this idea is that it may not improve security. There has been no proof provided for this, merely some vague idea that inactive accounts are less likely to be targets of abuse. Not one opposer has put forth a negative result of this proposal (although one editor has made a speculation that: a) a returning suspended admin may be offended by the mere idea of their suspension; and b) said prospective admin may be so offended that they would choose to no longer contribute at all). The proposal is minor, and puts a desperately needed policy in place where currently there is none at all. I will attempt to be just as blunt in this response - We have no policy that says adminship is permanent. That means it is not. This proposal would create a policy where there is currently a vacuum. There has not been a single good reason to oppose, and every oppose that amounts to "but that's the way we've always done it" should be completely disregarded by whoever closes this RfC. Jim Miller See me | Touch me 22:01, 9 June 2011 (UTC)[reply]


Increasing Wikipedia security

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.
This discussion is superseded by the new RFC at Wikipedia:Village pump (proposals)/Account security. If necessary please take any points made here across to the RFC. Rd232 talk 16:52, 5 June 2011 (UTC)[reply]

Renewed activity notification

The primary aim of the admin-suspension proposal above is to improve security (though there are clearly secondary considerations about admins staying in touch as well). Are there any additional measures we can take to improve security for all accounts? I have a suggestion (the recent email notification system suggests this should be feasible). We could automatically email editors who return after 3 months' inactivity with a brief "welcome back" email - and include in the email something in the direction of "if you didn't edit recently, your account might have been hijacked; in this case please login and check your contributions and if you have any concerns, change your password". This behaviour would be the default, but it would be controlled by a Preferences setting, to change the inactivity time period, or to turn it off completely. The advantage of this is that once implemented (in software; in theory it could be done by bot in the interim), it just works, without anybody needing to do anything. Thoughts? PS To be clear, I support the above proposal on de/re-sysopping; this would be additional, and based on the logic that the best person to detect account hijacking is the person whose account it is. Rd232 talk 15:04, 1 June 2011 (UTC)[reply]

Facebook sends an email when a user returns after being away for a period of a month or more saying "Welcome back!" This lets the editor know that their account is being used, not directly warning them, but it would warn them if their account was hijacked. Facebook also sends emails when the wrong password is entered, saying "We see that you are having trouble accessing your account." These would both be good ideas for WP. ▫ JohnnyMrNinja 19:23, 1 June 2011 (UTC)[reply]
Supplementary thought: if it doesn't already, removing or changing a verified email address ought to send a notification to the old address. Rd232 talk 15:08, 1 June 2011 (UTC)[reply]
Asking people to check their contribs seems like asking a lot. Most people who wind up getting that notification might not even know what a contribution is. It might be simpler (though less liberal) to follow a more standard security model such as requiring re-verification after a certain period of inactivity in order to log in again. Equazcion (talk) 15:25, 1 Jun 2011 (UTC)
? They'd get a link in the email to Special:Contributions. Should be clear enough. Rd232 talk 15:39, 1 June 2011 (UTC)[reply]
Not a bad idea, but it probably ought to be handled as a separate proposal and not a subsection of the sysop-flag suspension proposal. 28bytes (talk) 15:45, 1 June 2011 (UTC)[reply]
Alright, I've split it off. Rd232 talk 16:15, 1 June 2011 (UTC)[reply]
...and FT2 has reverted you. (Hopefully accidentally and not as an attempt to derail the main proposal now that's it's finally getting considerable support.) 28bytes (talk) 19:14, 1 June 2011 (UTC)[reply]
Can't see this - if I've reverted anyone else's edit please do fix it :) FT2 (Talk | email) 19:40, 1 June 2011 (UTC)[reply]
I've resplit the related but distinct proposals. Rd232 talk 20:00, 1 June 2011 (UTC)[reply]

If we want to improve security, is there a way we can require MediaWiki not to accept passwords shorter than, say seven characters, and they must include at least one numeral and alphabetical character, too? /ƒETCHCOMMS/ 19:09, 1 June 2011 (UTC)[reply]

Yes, libraries such as cracklib which I mentioned above can do this (and a php interface for MediaWiki would probably be trivial), but as I also said, doing this wouldn't be popular with users because as much as we'd like to deny it, many users really like to use weak passwords :) --Tothwolf (talk) 20:05, 1 June 2011 (UTC)[reply]
Given that many other websites have similar systems set in place, and anyone arguing against password security probably needs a serious reality check, I think getting consensus for it won't be extremely difficult. Then again ... even Sarah Palin's password reset thing was tricked (why would you ever use your dog's real name or whatever it was?). I'm just glad MediaWiki doesn't have security questions, like "What was your mother's maiden name?" /ƒETCHCOMMS/ 21:24, 1 June 2011 (UTC)[reply]
In response to that incident, Yahoo did at least improve their password recovery system. --Tothwolf (talk) 01:55, 2 June 2011 (UTC)[reply]
@Fetchcomms, so password1 meets those requirements. That's not a wildly secure password. -- Eraserhead1 <talk> 23:10, 1 June 2011 (UTC)[reply]
Now that's a red herring... A password such as "password1" would not be allowed by cracklib. --Tothwolf (talk) 01:52, 2 June 2011 (UTC)[reply]
Even if it isn't required, why not use cracklib (or something like it) to inform users of their password strength? It looks like the license is compatible with WM, we could install it and try it out. It could be set to offer a real-time password strength test, or a warning similar to the no-edit-summary warning. I think requiring all users to use strong passwords might have too many variables to get consensus easily, but testing out a warning system shouldn't have much opposition. If it integrates well, we could move from there. ▫ JohnnyMrNinja 08:51, 2 June 2011 (UTC)[reply]
There's not too much point in requiring complex passwords for all accounts so long as we allow users to log in via non-encrypted connections. My guess is the computational cost of requiring https for everyone would be high. We're working through some of these issues at work, fwiw. My suggestions would be:
-Admin accounts be required to use https and complex passwords
-Normal accounts have a length requirement and cracklib check. I have seen web systems that use a red-yellow-green bar that provides visual feedback on password strength. We can likely get significant improvements in passwords just by showing users a visual indicator of their password strength.
-Provide email notification of renewed activity after 90 days of inactivity for accounts with more than X edits (I'd say 1000), idea being that light editors may have long periods of inactivity on a regular basis.
FWIW, --Nuujinn (talk) 10:23, 2 June 2011 (UTC)[reply]
Good ideas. Incidentally I use HTTPS Everywhere addon for Firefox to force use of the secure WP servers. I don't know if the same can potentially be done in software or with a Gadget (for admins On by default), but at least encouraging admins to use HTTPS would help (in combination with a decent password). Rd232 talk 14:03, 2 June 2011 (UTC)[reply]
I agree with Rd232, these are all good ideas. Requiring admins to have stronger passwords than new users is especially smart. We don't want to annoy new users by forcing them to come up with complex passwords when they're first registering, but we don't want admins to rely on weak "new user passwords" either. 28bytes (talk) 15:26, 2 June 2011 (UTC)[reply]
Security issues could be noted at Wikipedia:New admin school, which is very easy; plus in theory, as a one off following this discussion, every admin could be notified by bot (talkpage at least, maybe email too) to check their password strength. But I'm wondering too if we couldn't have the software email everyone when they get to 1000 edits (say), as in "well done! thanks! BTW, how secure is your password, etc - maybe consider checking against strong/medium/weak indicator here..." (presuming we get one of those, as we should). Rd232 talk 16:27, 2 June 2011 (UTC)[reply]
I've moved subsection "Admin account verification and admin know-how" before this section, as it only deals with admins. Anyway, I support sending a ‘welcome back’ email to users who resume editing after 90 days of inactivity (but I'd add an option in the preferences to disable it), I support warning users about insecure passwords but oppose disallowing them from using such passwords if they still want to (except for admins and possibly reviewers, rollbackers etc.), and I'm neutral wrt requiring admins to use the secure server. ― A. di M.​plé​dréachtaí 16:38, 2 June 2011 (UTC)[reply]
See this Signpost article where a researcher from the University of Cambridge commented about several password security aspects of Wikipedia. Since then, two of his "low-hanging fruit" suggestions to improve security have been coded into MediaWiki (password complexity checker: rev:70520, encrypt password transmission: rev:75585), but are not activated yet on Wikimedia sites (as far as I am aware). On the upside, Ryan Lane and other Foundation staff are currently working on a major overhaul of HTTPS access to Wikimedia sites (earlier announcement, preliminary test at [7]), which should resolve various issues with the secure server.
Regards, HaeB (talk) 02:17, 3 June 2011 (UTC)[reply]
If we are going to make https: more common then the all the components of the page loaded must alsop be https: At the moment there are several javascripts and images loaded with http: even when you logon with the secure protocol. These are a weakness because they leak out the referrer and cookie information. I attempted to disable some, but there were to many parts and cannot easily disable some javascripts such as the geolocator, and ad banner stuff. Graeme Bartlett (talk) 05:38, 4 June 2011 (UTC)[reply]

How weak exactly peoples' passwords are

Well, Lulz Security today announced that they hacked into multiple unprotected Sony databases and accessed passwords/addresses/names/emails/etc. of one million users. They released a sample of those, so let's see how weak peoples' passwords are: [9], [10], [11]. For heavens' sake, the issue here is not old admin accounts. It is old admin accounts with weak passwords. Desysopping only "solves" half the issue. We must have MediaWiki require stronger passwords (i.e., a certain length, including both numerals and letters, cannot include the word "password" or something—some idiots are still using that in the above links, FFS). Does anyone else think that such a mechanism must be implemented? /ƒETCHCOMMS/ 23:08, 2 June 2011 (UTC)[reply]

hand up. Should be... but how? Will there be a post upon login that says "Your old password has been rejected, please pick a new one"? There are currently 14 million accounts... just saying. Choyoołʼįįhí:Seb az86556 > haneʼ 03:04, 3 June 2011 (UTC)[reply]
It can be rolled-out, starting with admins/user right groups, moved on to new accounts... Then, yeah, ask them to change their password. After the Sony hacks, I don't think people would be surprised. ▫ JohnnyMrNinja 03:14, 3 June 2011 (UTC)[reply]
You should read up on Wikipedia:User account security and bugzilla:16435. It's important to note that some developers have actively called for users to use weaker, easier to remember passwords, as the value of most Wikipedia accounts is next to nothing. --MZMcBride (talk) 16:09, 3 June 2011 (UTC)[reply]
I have to agree, if a user who only makes a small number of edits wants to set their password to something pretty basic does it really matter? Making them have a more secure password is likely to discourage them from editing. Enforcing a stricter password policy on people with rollback or admin rights seems reasonable.-- Eraserhead1 <talk> 09:04, 4 June 2011 (UTC)[reply]
I read a paper a couple of years ago about enforced strong passwords having the obvious effect of people being unable to remember them, so they write them down, often in the dumbest places, like on a Post-it note on the side of their monitor. OK, that's not a problem that will be exposed by dramas of the kind experienced by Sony above, nor a big issue for Wikipedia, but obviously still not ideal. HiLo48 (talk) 09:13, 4 June 2011 (UTC)[reply]
"the issue here is not old admin accounts. It is old admin accounts with weak passwords. Desysopping only "solves" half the issue." I would add that this issue applies to all accounts, regardless of which permission bits the account holds. As Mr.Z-man pointed out above, removing the admin bit actually fixes nothing and only promotes a false sense of "security". --Tothwolf (talk) 18:41, 4 June 2011 (UTC)[reply]
Forcing users who only wish to make a small number of edits to have strong passwords might well discourage them completely, certainly I would be discouraged if the password requirements were very strict, and as HiLo48 points out then people might well write them down or do other things like that. Forcing some level of password security on admins, or on those with rollback rights would probably be a good idea in supplement to this proposal. -- Eraserhead1 <talk> 11:03, 5 June 2011 (UTC)[reply]

New RfC

I've started a new RfC with the advice of Rd232 (talk · contribs) about account security on the English Wikipedia. Discussion is welcome about adding new security features to Wikipedia's registration process (and dealing with existing accounts). The RfC is located at Wikipedia:Village pump (proposals)/Account security. I urge everyone who has participated here to comment, because it seems that this is a potentially serious issue, and many users are in favor of reducing security risks per the above desysopping thread. /ƒETCHCOMMS/ 03:35, 3 June 2011 (UTC)[reply]

Quick question - does WP require email validation to start an account? If not, I would at least recommend requiring email validation for Admins (maybe for user rights). Even if email contact for other users is disabled, we could validate a method of contact, so that they are sure to get those warning emails. ▫ JohnnyMrNinja 05:06, 3 June 2011 (UTC)[reply]
It is optional but highly recommended. MER-C 09:22, 3 June 2011 (UTC)[reply]
Ok, thanks. I think that I'll mention it at the RfC. ▫ JohnnyMrNinja 09:26, 3 June 2011 (UTC)[reply]
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.

Tool for WebCite archiving

I request that a semi-automated tool be created that helps editors to quickly archive references with WebCite. Going through an article with lots of citations and archiving them all case by case per hand is really annoying and wastes time that could otherwise be spent on improving article content. This tool ideally should make it possible to archive all references at once, with only one click. Again, going through an article with hundreds of references and archiving them all on a case-by-case basis is extremely ineffective and time-consuming. And linkrot is a serious enough problem that justifies the creation of such a tool. And while WebCite might not be ideal to archive all kinds of content, it would still be better than having no such tool at all. Toshio Yamaguchi (talk) 11:40, 1 June 2011 (UTC)[reply]

Please see Wikipedia:Gadget/proposals MorganKevinJ(talk) 21:01, 1 June 2011 (UTC)[reply]
One of the Wikimedia Foundation's Google Summer of Code projects is about this, see [12], and also the links there. Regards, HaeB (talk) 02:01, 3 June 2011 (UTC)[reply]
Hey I'm the developer for the above GSOC project. I just wanted to say hi and get a feel for what kind of features the community would like to have for an external link archival extension in mediawiki. I notice from the currently stalled RFC on whether to implement wikiwix there appears to be significant disagreement over how external links should be modified in articles. The path I am thinking of going would modify links and add a link to take you to the cache for the page for every external link. I was wondering if the community would like the ability to limit this to say a specific category out of the box as consensus for implementation seems to be difficult to get. --Kevin Brown (talk) 21:38, 6 June 2011 (UTC)[reply]
What exactly do you mean by "Specific category"? Toshio Yamaguchi (talk) 00:20, 9 June 2011 (UTC)[reply]
Like where the feature is only enabled on a certain category that could be configured. For instance something like Category:Pages that use automated archival. --Kevin Brown (talk) 00:29, 9 June 2011 (UTC)[reply]
That sounds good to me, if there is consensus to do this. What about drafting an RfC? However I think we should try to reach consensus here first. So maybe you should outline here, what exactly you have in mind, probably as a subsesction of this section? Toshio Yamaguchi (talk) 00:45, 9 June 2011 (UTC)[reply]

Dispute resolution noticeboard

Have moved this over from the Idea lab to garner some consensus on giving this trial an idea. Part of this comes out of from comments and suggestions on the RFC on dispute resolution.

It seems to me that disputes on Wikipedia are all over the place, as in, they are not where they should be. We have people filing mediation cases for conduct issues, and vice versa. Some users don't seem to realise the best forum for getting their dispute resolved. Others just prefer to go to ANI directly. As a result disputes often get disjointed, and it becomes quite hard for mediators / "helpers" to keep track of, as well as ANI getting clogged up with disputes that sometimes either just don't belong there, or would be better suited at a proper dispute resolution forum. Perhaps, to try and counter this, we could create a new noticeboard, say Wikipedia:Dispute resolution noticeboard where we would have users being able to post their enquiry there and get some dispute resolution there on the spot by a mediator, or in disputes where it is evident the matter is detailed or one that does not have a simple resolution, could be referred to a proper forum, say an RFC, RFC/U or mediation. This noticeboard would exclude matters that should automatically go to arbitration, and standard stuff that should be at ANI, like block appeals etc. All other threads that are clearly dispute related that are posted at ANI could be closed, and sent to the disputes noticeboard instead. Additionally we could post a link on all present DR pages with a link to the noticeboard if the user is not 100% certain if that is the correct forum.

While I do see the potential for this noticeboard to get clogged up if not managed properly managed, I think that if correctly managed this idea could help reduce ANI getting clogged up with disputes that just don't belong there, and streamline the dispute resolution process in that we could point disputes in the right direction as opposed to being posted in 10 different places before finding the correct one. It could also help resolve low-level disputes, and nip them in the bud, so to speak.

To keep discussions on the page focused, we could have a similar format to SPI (with mediators or "clerks" to make sure discussions don't get out out of hand, stay civilized) but with users not having to post with funky templates. A simple comment about what the dispute is, who is involved, what has been happening, and then we can point them in the right direction, or get some basic DR underway. While I realise this is a new idea, I don't see any harm in giving it a trial go. ANI is far too clogged up nowadays with disputes that don't belong there, and disputes are often all over the place. Some forums for DR nowadays (WQA being a good example) work poorly and I think giving this idea a go might work. If it doesn't work, it doesn't work, but at least we will have given it a go. Steven Zhang The clock is ticking.... 23:37, 1 June 2011 (UTC)[reply]

That sounds like a bloody good idea. -- Eraserhead1 <talk> 23:39, 1 June 2011 (UTC)[reply]
Support. —[d'oh] 00:23, 2 June 2011 (UTC)[reply]
Support + improve WP:DR. A noticeboard is a good idea, but important to make sure it helps and doesn't just try to absorb every other issue. Specialist noticeboards and talk pages have their place too. In some cases it may need to point users to other venues. I made a start on restructuring WP:Dispute resolution a while ago to give much-needed better guidance, which might help too. (Link to draft - feedback welcome). FT2 (Talk | email) 01:23, 2 June 2011 (UTC)[reply]
The noticeboard is more designed to be a starting point for disputes to go to, as opposed to a replacement for the noticeboards that already exist. That said, some disputes are trivial and a quick discussion or some advice is all that's needed, which would prevent clogging up a noticeboard like ANI, and would also aid in resolving the dispute, as DRN would be watched by those that actually resolve disputes (or learning to) as opposed to ANI. It's a specialised noticeboard for a specialised problem. There are other times where new users just aren't aware of basic policies and need these explained, ie, they file a medcab case because a user keeps removing their unsourced info from an article. The main aims of this noticeboard are to a) Help keep track of disputes b) Act as a starting point for most disputes in the resolution process, ensuring they actually get directed to the best forum where they can be addressed properly and c) Aid in resolution of small disputes and trivial matters such as examples I listed above. It's designed to be a central point for the DR process, not a replacement for the existing processes. WQA has some severe issues, as most matters that get sent there end up with parties slinging mud at each other. Perhaps WQA could be marked historical with disputes starting at DRN and either finding quick resolution or referred to RFC/U. This way we can also keep discussions civilised and properly address disputes that have genuine issues, but nip in the bud "this user reverted my edit/I don't like them" type disputes that we too often see at WQA. Steven Zhang The clock is ticking.... 03:03, 2 June 2011 (UTC)[reply]
Support. This makes sense. DR is policy and next to RS, NPOV, and BLP is the most common and most disruptive part of Wikipedia. (While we're at it we should get rid of Content noticeboard and maybe merge this eventually with Wikiquette Noticeboard, which is a giant waste of finger-pointing time). The board would work to help navigate all aspects of disagreements and complex issues. It could be staffed by mediators and focus on compromise and building consensus. It would be an ideal complement to multi-factoral debates which don't fit neatly at any one board, but without necessitating an RfC. A good idea. User:Ocaasi c 03:46, 2 June 2011 (UTC)[reply]
Question. Does this proposal differ substantially from formal mediation? Maybe it just makes mediation more prominent as a dispute-resolution opportunity? —Tim Pierce (talk) 03:49, 2 June 2011 (UTC)[reply]
Yes. This noticeboard is not designed to replace any of the major dispute resolution processes (except perhaps WQA) but to complement the existing processes, clarify the disputes, resolve little ones that referring to a different process would be a waste of time or unnecessary, and point users in the right direction as to where the best place to sort out the dispute is, as currently, and often, disputes get sent to the wrong place. This noticeboard would aim to fix that. A noticeboard monitored by those who have experience in DR, getting little disputes resolved quickly, and referring others to the correct forum for resolution. Steven Zhang The clock is ticking.... 03:55, 2 June 2011 (UTC)[reply]

I have submitted a rough draft of the noticeboard. It is at Wikipedia:Dispute resolution noticeboard. I still haven't finished off the edit notice yet. Steven Zhang The clock is ticking.... 14:42, 2 June 2011 (UTC)[reply]

  • Support Although the existing noticeboards suffer from understaffing, I would still support this if traffic could be redirected from ANI. That will take merciless clerking, however, so I hope volunteers will be willing to step up to the plate. Skomorokh 15:47, 2 June 2011 (UTC)[reply]
Is there/could there be a technical way to move a thread to a different venue with only a click? (I'm thinking user-enabled, to help volunteers.) Grandiose (me, talk, contribs) 15:52, 2 June 2011 (UTC)[reply]
I don't know of any current thread-moving tool, but it would be both feasible (going on the way Twinkle expedites multiple edits to different pages in the deletion process with a single click) and to me welcome, if you can find someone to code and maintain it. Skomorokh 16:06, 2 June 2011 (UTC)[reply]
(Reply to Skomorokh) - I'm hoping that with this noticeboard admins will direct stuff that doesn't belong at ANI but does belong at the dispute noticeboard, to this noticeboard. It will be partly up to clerks to monitor ANI, partly up to admins to move threads there. There has to be a way in script to move pages from one page to another. I'll have a look into it. I know there's a script that does voting on AFD, I'll see if I can modify it to have it move sections. Or there might be a way a bot can move sections that are tagged with a certain template, say, {{move to DRN}}, to the disputes noticeboard. Will try to get some input on this. Steven Zhang The clock is ticking.... 23:54, 2 June 2011 (UTC)[reply]
  • Support Seems reasonable and worth a try. I'd love to have comments segregated into Involved and Uninvolved sections and have the clerk be able to enforce this. A Quest For Knowledge (talk) 15:59, 2 June 2011 (UTC)[reply]
  • Question Looking at the present state of WP:ANI, what proportion of the threads there would you envisage ought to start at the dispute resolution noticeboard in future? Most of the discussions revolve around inter-editor disputes – would this noticeboard swallow most of ANI? Skomorokh 16:13, 2 June 2011 (UTC)[reply]
    • If that meant that ANI did a better job of handling admin issues, which in my experience it handles very poorly, that would be a bonus. -- Eraserhead1 <talk> 17:56, 2 June 2011 (UTC)[reply]
    • Skomorokh, stuff that is still within the scope of ANI would stay at ANI. Stuff like sockpuppetry, block evasion, edit warring etc, stays at ANI. Other stuff is to the discretion of admins and clerks as to whether to move it over to DRN. It's not going to be 100% clear right off the bat. Our aim should be to encourage users with content and conduct disputes that does not fit within ANI's scope (stuff that would normally go to WQA, RFC, third opinion) to DRN to assist in the clarifying what the actual dispute is to make it easier to resolve, what the best forum for resolution is, or in limited circumstances providing resolution on the spot. Stuff is still going to get posted to ANI that probably belongs at DRN. It will take time to get familiar with what should be moved to DRN and what shouldn't, but like I said it's worth a go. We can learn as we go along. Steven Zhang The clock is ticking.... 23:54, 2 June 2011 (UTC)[reply]
  • Support. At least it's worth a try. Two suggestions: make it clear that other DR venues should not require attempting to resolve the issue here first (since it may only be a place where you get told where to go next), and make sure the format of the page does not lend itself unduly to just posting someone's name in a flaming manner (like using it to post the names of users one doesn't like; in other words, there should be some indication of a dispute, not just a name or list of names). --Tryptofish (talk) 18:57, 2 June 2011 (UTC)[reply]
    • In regards to your first point, no, if a dispute clearly belongs at mediation, a user does not have to go to DRN first. Other issues, sure. If the user feels that the DR avenue they have selected is best, they can use it. This comes with two caveats. One, if a user files a dispute on a page, and it does not belong there, they can be directed to DRN to find the best forum, and two, what the dispute about is should be clear. If, on the page they posted the dispute, it is not clear what the dispute is, they could also be directed to DRN. The main aims of this noticeboard are to a) Have the topic of disputes clearly clarified, to aid in resolution and b) Ensure that disputes are sent to the right forum. So, while using DRN will not be required before other DR forums, but it is recommended, especially if it is not clear who/what is in dispute, or where it should go to, in the case of mixed content-conduct issues.
    • In regards to your second point, with having clerks patrol the page, unlike WQA at present, the aim is to not have this sort of behaviour allowed. No longer will these sort of noticeboards be a place to flame users, rather, it will be the first location to bring up new disputes in regards to legitimate conduct issues, discussed in a civilised manner, as well as content issues, also in a civilised manner. Clerks will not be civility police, but bad conduct will not be tolerated. We've dealt too long with flaming at places like WQA and ANI, and it does not help resolve the issues. Time to make a change for the better. Steven Zhang The clock is ticking.... 23:54, 2 June 2011 (UTC)[reply]
  • Very cautious support The idea is pretty good, but it's also delicate. We have to balance helping new users with not creating a new layer of bureaucracy or adding an additional venue to forum-shop at. Also, clerking/mediating is reasonable, but good mediators are not every user, and making it excessively formal like ArbCom only makes dispute resolution take longer. /ƒETCHCOMMS/ 23:11, 2 June 2011 (UTC)[reply]
    • The noticeboard's main aims are to move disputes away from ANI where they don't belong, and disputes where the situation or scope is not clear, to this noticeboard, for clarification and direction to the best place for resolution. Forum shopping, not allowed, which would be enforced. I agree that bureaucracy is bad, and that allowing everyone to clerk would not be the best idea. Perhaps the user could demonstrate some experience with dispute resolution in order to clerk? We don't want to make the process to bureaucratic, but at the same time need to ensure the people directing users to other DR forums actually know what they are doing. Steven Zhang The clock is ticking.... 23:54, 2 June 2011 (UTC)[reply]
  • Support and highly encourage editors who make posts at the more specialized boards (NN, AN*, 3RR, BLPN, etc.) that are less experienced to come here first. Obviously if an established editor creates a thread at those other locations, they know what they are doing and don't need to come here to get their post at the other location. I can think of 30 or so threads in the past few weeks on ANI that should have been resolved elsewhere. Hasteur (talk) 20:31, 2 June 2011 (UTC)[reply]
    • Sure, experienced users don't have to post here first if they know exactly which forum to take the dispute to. This noticeboard is not designed to be an extra hoop people have to jump to, it is more designed as a mail sorter. Clarify what the dispute is and what needs to be resolved, and direct them to the best forum for resolution. With the two caveats I listed above. If a user files a dispute at a DR forum and it's the wrong place, they can be directed to discuss the dispute at DRN, two the dispute needs to be clarified in a way that is clear for helpers to aid in resolution. Otherwise it might have to be sent here. If an RFC/U is posted with the user stating "User Y keeps reverting my edits, I don't like it" etc, then sure, that needs to go to DRN. Steven Zhang The clock is ticking.... 23:54, 2 June 2011 (UTC)[reply]
  • Support Wikipedia:DISPUTE#Ask_for_help_at_a_relevant_noticeboard should be updated accordingly, the last line of Wikipedia:DISPUTE#For_urgent_situations, should also be emboldened in some way with a link to the new noticeboard. The Helpful One 00:01, 3 June 2011 (UTC)[reply]
    • The relevant DR pages will need to be updated if consensus for this idea goes ahead, but I want to wait until that first. We might need to also analyse where users who have the disputes find the forums they go to, and see if there's a way to direct them to the new noticeboard if they're unsure of the best forum. See my above comments. Steven Zhang The clock is ticking....
  • Support — but jokingly oppose as it'll reduce the overall drama level at WP:ANI and therefore hurt sales at my Torch and Pitchfork Emporium. --slakr\ talk / 00:07, 3 June 2011 (UTC)[reply]
  • Comment - Not dealing with this much, I don't have much of an opinion. I'd just like to point out that this is the second SUPPORTed noticeboard on this page right now, and we have a good-many noticeboards out there already. I just hope that the maintainers will do their best to advertise this board, and will have the guts to shoot it if the time comes. ▫ JohnnyMrNinja 00:34, 3 June 2011 (UTC)[reply]
  • Support - This is an awesome idea. There are numerous times when I find a content dispute that has been brought to a noticeboard (especially ANI) and I've directed people to WP:DR. Being able to direct someone to an actual board would be much better than just a policy page (especially since they've already reached out to one noticeboard, they'd be more inclined to try another). I might even try my hand at helping support such a board. -- Atama頭 16:48, 3 June 2011 (UTC)[reply]
  • Support proposal is reasonable and well-formulated. Would be useful and helpful to new & experienced WP users alike.--JayJasper (talk) 17:02, 3 June 2011 (UTC)[reply]
  • Support - useful board.Anthem 19:11, 3 June 2011 (UTC)[reply]
  • Support. A reasonable proposal that could help things, and seems unlikely to harm anything; worth trying, at least. 28bytes (talk) 20:32, 3 June 2011 (UTC)[reply]

Summarised proposal

It seems to me like there is a fair bit of consensus to giving this idea a go and seeing how it will work. So we are entirely clear on the functions of this noticeboard, I have compiled a summary of what the noticeboard would do, and what noticeboards it would replace, and a summary of how it would function. Comments on the summary are welcome.

  1. This noticeboard would primarily be used for users to post a brief summary of the dispute/issue, and can either get some on the spot resolution by a "clerk" (I use that term sparingly) or mediator in situations where it is either a small dispute, a trivial one, or one that resolving on the spot as opposed to referring to a proper forum would be a waste of time (see examples above). In disputes where it is evident the matter is detailed or one that does not have a simple resolution, could be referred to a proper forum, say an RFC, RFC/U or mediation. This noticeboard is not designed to replace all other DR noticeboards, except to absorb, as a trial, the sorts of comments that would go to WQA and Content noticeboard. This noticeboard would not be mandatory to use, as in, it would not be a "hoop" people have to go through to pursue other dispute resolution. This would come with two caveats. One, if a user files a dispute on a page, and it does not belong there, they can be directed to DRN to find the best forum, and two, what the dispute about is should be clear. If, on the page they posted the dispute, it is not clear what the dispute is, they could also be directed to DRN. The reasons for this are to a) Have the topic of disputes clearly clarified, to aid in resolution and b) Ensure that disputes are sent to the right forum to ensure resolution is actually possible.
  2. Update - A trial would be undertaken to implement the noticeboard in two stages. In stage one, discussions on WQA and the content noticeboards would still occur on those noticeboards, but a notice would be posted on the pages to suggest DRN as an alternate forum. This could be used to parallel the good and bad aspects of the new noticeboard, and compare with the good and bad aspects of existing noticeboards. This trial would last a month, and at the end of the month a discussion would take place outlining the results of the first trial. Stage two would involve the WQA and Content noticeboards closed, with posts directed to the Dispute resolution noticeboard. This aspect of the trial would also last a month, and the main purpose of this trial is to assess what would things be like if these boards were permanently closed. I've proposed this idea as a) Content noticeboard deals with largely the same issues and b) WQA at the moment has some severe issues, as most matters that get sent there end up with parties slinging mud at each other. While I realise that this is quite a major change, I feel that giving this idea a shot is worth a go. The new noticeboard would have little effect if users could go to WQA and still have shouting matches. Conduct disputes at DRN would aim to be civilized, with while this not being "policed", will be enforced. There is a difference between expressing one's opinion and calling someone an asshat. Resolution at DRN for these sorts of disputes would either find quick resolution, or being referred to RFC/U. This way we can also keep discussions civilised and properly address conduct that has genuine issues, but nip in the bud "this user reverted my edit/I don't like them" type disputes that we too often see at WQA. While WQA is a high traffic noticeboard, it also is deeply flawed, and something needs to be done to still address valid conduct issues, but prevent the cesspit that WQA has become, and I propose this noticeboard, which would be monitored by mediators and "clerks" (I hate that word) who have demonstrated some experience in DR to ensure discussions don't get out of hand, offer advice and point people in the right direction in terms of the best avenue for further dispute resolution. At the end of this trial, results would be compared to what we found in the first trial, and a discussion would take place outlining the results of both trials and the best course of action moving forward.
  3. Disputes that do not belong at ANI would be closed, and redirected to DRN. While severe and urgent conduct issues do belong at ANI, like as I posted above, a lot that ends up at ANI does not belong there. While it may take some time to get a hang of what belongs at ANI in terms of disputes and what does not, a main aim of the board to reduce clogging up ANI with disputes that do not belong there. Additionally, disputes posted at incorrect forums (for example only conduct issues being presented at a mediation case) could be sent to DRN for clarification as to what the dispute is, and how to resolve it.
  4. Traffic at Wikipedia:Editor_assistance/Requests that involves content and conduct disputes would also be directed to DRN. While a lower traffic noticeboard, this noticeboard is not really designed for dispute resolution, more so for assistance and questions about editing.

There are further details on the proposal further up the page, feel free to review that as well, as it has a bit more information as to the details of this proposal. The dispute resolution noticeboard is most designed to act as a mail sorter, resolve small issues on the spot, direct larger and more complex issues to the most appropriate forum for resolution, and ensure that discussions stay civilised and reasonable. Steven Zhang The clock is ticking.... 13:40, 4 June 2011 (UTC)[reply]

  • Support - what an excellent idea. Without getting to arbcom-formal, perhaps a simple structural thing like "Your complain needs to be 300 words or less, and must include diffs of alleged behaviour" or something (with help given to people, I guess; maybe 'should include'), would help things get more expeditiously disposed of. Either way, I think this is a great idea--and anythingt hat lances the boil that is WQA would be great. Admin involvement needed, of course; one of WQA's failings is that there's no teeth, just people yelling. → ROUX ₪ 08:46, 5 June 2011 (UTC)[reply]
    • That's a really good idea. I think being a little more lax on content disputes would be OK. The main issues with content disputes at present are either the scope and details of the content dispute being unclear, or the dispute being posted at the wrong forum, so this noticeboard aims to help resolve small issues but point larger ones to the proper forum for resolution. That said, discussions on the page should be short, regardless of content or conduct issues. Perhaps a word limit could work, especially for conduct disputes. In regards to "teeth", I do see the need for some enforcement of reasonable discussion, as opposed to the yelling and bickering that goes on at WQA. Perhaps the mediators/"clerks" that patrol the page can do what they need to do to keep discussions civilised, failing that notify users they need to keep things civil etc, and failing that close the discussion and refer that matter to an RFC/U or ANI? I'm really not sure on this part. Steven Zhang The clock is ticking.... 10:39, 5 June 2011 (UTC)[reply]
  • Support - As before. -- Atama頭 10:09, 5 June 2011 (UTC)[reply]
  • Support - I had come her thinking, "not another bloody noticeboard", but saw the note about interim folding in two noticeboards whose briefs overlap and am cheered up immensely. I approached this problem from a different way and this is much better. Is it too late to add Wikipedia:Third opinion to be marked (for the interim) historical? It is a fairly low traffic broad with a somewhat nebulous brief, whose roles I feel overlap with WQA and also RfC in some way? Casliber (talk · contribs) 10:36, 5 June 2011 (UTC)[reply]
    • Added to the list, I had been thinking about adding it and it is quite low traffic. Also added a clause about redirecting conduct and content disputes from Wikipedia:Editor_assistance/Requests to here, as while somewhat a low traffic noticeboard, the issue we have here is disputes spread out everywhere. While I agree consolidating everything together is a bad idea, the main purpose of this board is to fix small issues, direct others to the best forum for resolution. If managed well, I can't see this board turning into another ANI. Steven Zhang The clock is ticking.... 10:46, 5 June 2011 (UTC)[reply]
  • Support this seems like a good step forward for dispute resolution, hopefully it'll take some of the drama away from ANI. -- Eraserhead1 <talk> 10:56, 5 June 2011 (UTC)[reply]
  • Overall, I like this for the reasons I already stated above. I'm ambivalent, however, about going so far as trial-ing those other boards as historical. So long as the trial is clearly spelled out, in advance, as being brief, with a pre-defined end date, and leaves open the possibility of promptly re-opening the other boards, then I can Support, but I'd be very wary without that caveat. --Tryptofish (talk) 17:33, 5 June 2011 (UTC)[reply]
    • The noticeboards will have an initial trial of closure for say, two months, sufficient time to sort out any teething problems with the transition (One month might be insufficient) and yes, if the noticeboard turns out to be a total failure then we could re-open the old noticeboards. That's why there will be a trial, it's something that has never been done before so we need to see how it goes. I feel that if managed well this noticeboard could work quite well, but we have to give it a go and see first. Steven Zhang The clock is ticking.... 22:00, 5 June 2011 (UTC)[reply]
      • Reading the discussion since my last comment, I now have to Oppose closing the other boards during the trial. Certainly, two months is way too long. I still support the overall idea of the trial, but not that aspect of it. I've thought carefully about the argument that we need to prevent users from forum-shopping from one place to another, but that is not a valid reason to close the existing boards. In fact, if one really wants to test the hypothesis that this new board will be an improvement—and testing that hypothesis is exactly what the trial should aspire to accomplish—then the best way to do that is to leave all existing boards open. That way, we can actually collect data on whether the new board does or does not accomplish what it proposes with respect to cutting down on subsequent forum-shopping, as well as data about whether cases that originate at the new board get resolved more efficiently than do cases that start out somewhere else. Closing the other boards skews the trial to give an advantage to the proposal, and we shouldn't do that. Depending on the outcome of the trial, there could subsequently be a separate RfC about closing other venues. --Tryptofish (talk) 19:22, 6 June 2011 (UTC
        • We could perhaps do a trial of all noticeboards that exist at present just encourage traffic to be posted at DRN, and offer it as an alternative to the existing noticeboards, and see how it goes. After this trial we could assess the results, then do a second trial with the noticeboards closed and discussions directed to DRN. This way we can gether data on the successes of the noticeboard without skweing results. I've updated the proposal accorcingly. Steven Zhang The clock is ticking.... 01:33, 8 June 2011 (UTC)[reply]
          • Thanks, that update is a significant improvement. With the understanding that "phase two" of the trial will, of course, depend upon the results of "phase one", I am now comfortable Supporting the proposal in full. --Tryptofish (talk) 18:19, 8 June 2011 (UTC)[reply]

Oppose Why is this here instead of the already open RFC? I've already commented there and don't care enough to reiterate myself.

  • There's a fallacy here that the dispute issues WP has are due to lack of organization or can be fixed due to reorganization. Remember in the midst of WP-this and WP-that, there are but five pillars Read through this mess if you think organization, or admins instead of (mere) editors facilitating resolution is the issue.
  • The issue, vis-a-vis civility is lack of consensus. Without consensus, you can rearrange deck chairs all you want and it doesn't matter.
  • Clerk and procedures and all that are contrary to one of the pillars. The "cure" could easily be worse the problem.
  • Disputes occur because when a POV pushing editor uses suspect RS engages and edit wars, sometimes on BLP, with other editor(s) that they're insulting ... which dispute board does that go to? Gerardw (talk) 23:02, 5 June 2011 (UTC)[reply]
    • Hi Gerard. Thank you for your comments here. To respond to each of your points
      1. I realise that there is an already open RFC, and I left comments there as well. This proposal came out of an idea I got from reviewing the RFC, mainly, a lot of disputes end up at ANI, or a miscellany of other boards that they don't belong at, and as a result it is somewhat harder to a) Keep track of issues and b) Ensure they're actually posted at the right forum. There are the five pillars, but most people that have a dispute won't go and read the five pillars, or at times even read WP:DR. Most just go to ANI for content, WQA for conduct. Both forums turn into a shouting match. While I realise this would be a major change, I feel the major consensus at present is that there is an issue, and it needs to be addressed. This is my proposed resolution.
      2. Consensus will generally form from undertaking dispute resolution. Or it will not. Dispute resolution has to be tried first. But a major barrier to actually resolving disputes at times is incivility. It's quite hard to resolve the issues at hand if people are calling each other asshats. It works at MedCom, I feel it could work on this noticeboard.
      3. I'm not a big fan of the clerks idea either. That said, ArbCom has clerks, who also enforce good conduct on discussion pages, and it seems to largely work. I'm not suggesting that "clerks" of this noticeboard will hold any official role, their task would only be to ensure discussions stay reasonable and focused on the issues at hand, and help direct complex queries to a targeted DR forum, ie an RFC, RFC/U or mediation.
      4. That sort of issue would be posted to the noticeboard, a brief summary of the issues would be posted. It seems like that example you present is mainly a conduct issue, so an RFC/U would be the best avenue, and if edit warring was active, referred to 3RR. Once the conduct issues are resolved, the sources could be discussed on the article talk page. This noticeboard is not designed to resolve all disputes. It's designed to help discuss them to figure out exactly what is going on, resolve minor ones and recommend the best avenue to resolve larger, more complex ones. Steven Zhang The clock is ticking.... 23:37, 5 June 2011 (UTC)[reply]
  • Conditional support: i) not replacing any existing boards to begin with; if it works well enough that other boards become defunct, great, but don't force it. ii) minimal formality. No "clerks" or requirements of diffs, etc. The main objective should be to help newcomers figure out how to handle a dispute (probably boilerplate responses will evolve as the WP:helpdesk has) and point them in the right direction. It's fine if it evolves a little more formality in response to need, but starting with that is a bad idea. Keep It Simple. Rd232 talk 23:20, 5 June 2011 (UTC)[reply]
    • Part of the issue with not moving traffic from other noticeboards is that if a user is not satisfied with a response at one noticeboard, they can simply go back to the other noticeboards and post the same issues all over again. I'm not suggesting that suggestions on DRN should be final, but a user shouldn't be allowed to bring up a trivial conduct dispute matter, be told it's not an issue, and have them raise it again on WQA. My points stand in regards to the idea of clerks. They're designed to assist and keep discussions focused. In content disputes, sure, diffs maybe not required. For conduct, important to have diffs. Otherwise people could post anything they like on the noticeboard without substantiating evidence. The new board is designed to reduce these sorts of reports, as I've listed above, as opposed to increasing them. Helping out new users is important, but this needs to be balanced with the potential for the board to be used by anyone that has a beef with another editor. Steven Zhang The clock is ticking.... 00:16, 6 June 2011 (UTC)[reply]
  • Support Comment, Whilst the DRN is, at worst, a harmless idea and a best a brilliant one, closing WP:3O, even for a trial, is completely uncalled for and unneccessary. I don't believe there is, or has ever been, any consensus to scrap or even to substantially change it - 3O works, it's a great way of getting a dial-out consensus to a low visibility topic area and finding solutions to problems which couldn't really be aired without a fully fledged RFC. Volunteers there tend to be well informed and genuinely helpful (myself excluded of course) and the project operates with a remarkable level of efficiency (admittedly in part due to the low traffic). It would be a crying shame to shut it down for an unspecified trial period - if anything we should take this as an oppurtunity to redirect more traffic to 3O (or at least inform them of the discussion). I'm happy to support if we strike that off the proposal. Bob House 884 (talk) 23:37, 5 June 2011 (UTC)[reply]
Thanks. I do like the proposal - I'm sure we've all been in situations where we've had a dispute and just thought "where the heck do I post this?" and a board where you can just post any problem and have it sorted to the right noticeboard seems like a great idea. A possible problem may be keeping disputant from following the poster straight over to DRN and creating a shouting match before anyone can shift it - we can see if that materialises. One issue I'd be interested in seeing in the trial is the impact of having designated clerks deal with the 'cases' compared to just letting anybody do it. There are pros and cons for each but it's perhaps something that can be investigated. I am now happy to support the proposal. Regards, Bob House 884 (talk) 00:30, 6 June 2011 (UTC)[reply]
It wouldn't be formal, but users would need to demonstrate at least some knowledge or experience in the DR process in order to direct users to the proper forum. While this adds a layer of bureaucracy, it would also help ensure brand new users don't direct equally new users to mediation for a conduct dispute. I don't see major harm in letting anyone give advice and help, but actually closing a discussion (unless plainly unhelpful) and moving the dispute to different forum, would best be done by someone who is familiar with DR processes. Steven Zhang The clock is ticking.... 00:55, 6 June 2011 (UTC)[reply]
  • Strong support. A great idea, as I've mentioned before, centralized and staffed by mediators and policy generalists. No need to ditch 3O, but WQA and content noticeboard have seen their days come and go. Worth clarifying that DRN is not the place to blame everybody, but to lay out issues and see where discussion should focus. Ocaasi t | c 03:26, 6 June 2011 (UTC)[reply]
  • Support. Seems reasonable and worth a try. I still think that comments should be segregated into Involved and Uninvolved sections and have the clerk be able to enforce this. A Quest For Knowledge (talk) 18:52, 7 June 2011 (UTC)[reply]
  • Support. The mess WQA sometimes becomes has been accurately described and such a noticeboard would hopefully be better "staffed" and provide results instead of fueling further uncivil dispute. Guoguo12 (Talk)  19:46, 7 June 2011 (UTC)[reply]

appearance of scientific names in lead of species articles listed at their common names

I've created Wikipedia_talk:WikiProject_Biology#Consensus_how_scientific_names_are_displayed_in_the_lead_of_species_articles_listed_under_common_names to get an idea of whether we should streamline. Casliber (talk · contribs) 01:20, 3 June 2011 (UTC)[reply]

Default edit summaries

Per a consensus discussion here to implement default edit summaries in the form of dropdown boxes Rd232 and I have been working on a script to do this. The script now seems pretty complete and I would appreciate some more testers making use of it. :)

My question is; what is the next step? Can this be added directly to common.js? or is this better as a gadget (and enabled by default)? We have approval for the idea, I just need approval on the technical aspects. (FWIW I prefer the gadget option because this allows people to disable it). --Errant (chat!) 09:04, 3 June 2011 (UTC)[reply]

Hi. I loaded the script, but when I choose "Reply" - my edit summary is " - Replay", is there a need for the hyphen or space? The Helpful One 10:52, 3 June 2011 (UTC)[reply]
Nope, I can remove that. The script is adopted from another Wiki so has some holdovers from there. Just about any tweak is possible at this stage :) --Errant (chat!) 19:37, 3 June 2011 (UTC)[reply]

See also, User_talk:NuclearWarfare#Make prompting for a missing edit summary the default  Chzz  ►  09:22, 4 June 2011 (UTC)[reply]

You may want to look at some hacking in my monobook.js that makes a half-hearted stab at replacing the section summary E.G. /* Default edit summaries */ if you have started a new section. Rich Farmbrough, 18:57, 5 June 2011 (UTC).[reply]

I noticed Wikipedia:Please use fullurl and, even though I think it may be outdated (as is mentioned on the talk page), it shows how fullurl can make really simple, clean diff and search url code. What if WP were to provide a fullurl code between to article versions on a diff page, or at the top of a search page? Surely it is better than bare URLs? Below is an example from that page. ▫ JohnnyMrNinja 11:21, 3 June 2011 (UTC)[reply]

[{{fullurl:{{FULLPAGENAME}}|action=edit}}]
Links to edit this page: [13]
Cf. User:TFOWR/easyDiff2.js. Ucucha 12:01, 3 June 2011 (UTC)[reply]

I've noticed that an increasing number of sites have facebook twitter icons which when clicked on put on link on you relevant profile or create a tweet. Would is be useful for every WikiPedia page to have such a button? As an example have a look at Liverpool Echo when a user writes a comment the sytem can be set up to past that comment to Facebook and create a tweet with a link back to the article. Seems good PR as well as usefull.--Kitchen Knife (talk) 15:21, 3 June 2011 (UTC)[reply]

I thought about the same thing as well. Also, maybe let users log in using their Facebook account. Wikipedia has a shortage of female editors and women rule social networking so might be a great way to attract some new editors. A Quest For Knowledge (talk) 19:14, 3 June 2011 (UTC)[reply]
This has been suggested quite frequently recently, see e.g. this or this discussion and the links there. As a logged-in user, you can install User:TheDJ/Sharebox for yourself, but it appears that many users would find such icon blocks too intrusive to to be turned on by default. For Signpost stories, we added unobtrusive "Share this" dropdown menus a while ago (example - see top right).
Regards, HaeB (talk) 19:21, 3 June 2011 (UTC)[reply]

What would the purpose of echoing your edits onto Twitter and Facebook be, other than for canvassing purposes? The Mark of the Beast (talk) 20:41, 3 June 2011 (UTC)[reply]

You would not be echoing your edits, just articles you chose though might interest you friends.--Kitchen Knife (talk) 20:50, 3 June 2011 (UTC)[reply]

Sharebox is a script that reorders your toolbox. It adds new buttons that make it easier to mail, print or share an article on Facebook or another linksharing service. You must have an account to add Sharebox to the sidebar. See User:TheDJ/Sharebox for more information. ---— Gadget850 (Ed) talk 23:23, 3 June 2011 (UTC)[reply]

User:TheDJ/Sharebox sounds great but I cannot get it to work?--Kitchen Knife (talk) 10:55, 4 June 2011 (UTC)[reply]
What browser are you using? ---— Gadget850 (Ed) talk 19:26, 5 June 2011 (UTC)[reply]

Facebook integration already exists in MediaWiki, and is used on Wikia. Someone brought it up on Jimbo's talk page recently and he supports Facebook for Wikipedia. Just pointing it out. I don't think we should be a social site, I hate social sites, but linking to social sites will increase readership and editing. People wonder why we aren't getting new editors, maybe it's that Web 2.0 is old-school for most people now, and Wikipedia is hovering around Web .7 ▫ JohnnyMrNinja 20:57, 4 June 2011 (UTC)[reply]

What sort of editing Wikipedia will get from integrating Facebook needs to be considered before any action is taken. My guess is that since Facebook is for socialization and similar activities, and not for "scholarly" activities such as writing an encyclopedia, the majority of edits will be of no benefit at best. The worst case (and likely) scenario is that such links will attract Facebook trolls, fans, and POV pushers to Wikipedia. That's something the editors dealing with vandalism don't need. Rilak (talk) 02:12, 5 June 2011 (UTC)[reply]
Totally agree. The Mark of the Beast (talk) 03:21, 5 June 2011 (UTC)[reply]
Er... and using Wikipedia in schools... we'll get school-children editing their schools pages ... and abusing their friends and teachers... Oh no! It already happened! … It's not like Wikipedeans now are such a "neutral" bunch (see ANI, ARBCOm, block log, AIV etc), and it's not like there aren't many many links form FB to WP already. While I have great qualms about putting Fb and Twitter links on WP (and got soundly trouted for putting Google links on pages needing refs myself, although consensus later moved) I don't think that thinking of FBers as "the great unwashed" is either helpful, accurate or true to the spirit of the project. Rich Farmbrough, 19:08, 5 June 2011 (UTC).[reply]
Except that school kids are currently studying research techniques and materials relevant to different articles, so there's a potential gain (for us and them). The abuse is a problem for allowing anyone to edit (not suggesting we get rid of that), so there's not really a net loss there. FB does not teach anyone how to research stuff (as many pyramid schemes and trojans I have to point out to my friends, quite the opposite), so there is no potential gain. Ian.thomson (talk) 20:08, 8 June 2011 (UTC)[reply]

Note that Facebook mirrors Wikipedia. Rich Farmbrough, 19:08, 5 June 2011 (UTC).[reply]

As you say Facebook feeds Wikipedia as in Rose Heilbron what I and the people I'm connected with seems to do on face book is post links to articles, videos etc, lots of external content.--Kitchen Knife (talk) 19:27, 5 June 2011 (UTC)[reply]
  • Oppose for the same reasons as I opposed it the last two times. Also, Facebook is the antithesis of credibility, and in my opinion, the antithesis of intelligent discourse. Having the icons there would be damaging, I think, and the only reason I can think of people wanting it is that it saves them about a seventh of a second and that 'everyone else is doing it'. Seriously, if you want to link to a Wikipedia article, copy the URL, it's not at all hard. Sven Manguard Wha? 07:50, 6 June 2011 (UTC)[reply]
Given that most people use their real names on Facebook, I sincerely doubt that this would increase vandalism. If anything, using your real name is more likely to discourage it. A Quest For Knowledge (talk) 12:57, 7 June 2011 (UTC)[reply]
Only if they used their real names when editing on Wikipedia. But since Facebook and Wikipedia aren't linked, we'd only identify them with their IP address. Gary King (talk · scripts) 18:34, 7 June 2011 (UTC)[reply]
Well, one of the suggestions is to let users log in using their Facebook accounts. A lot of web sites are starting to do that. A Quest For Knowledge (talk) 18:43, 7 June 2011 (UTC)[reply]
How exactly would that work? I mean, in YouTube for example, I can log in with my Google-Mail account. In that case, both accounts are probably hosted on the same service (ie a Google server) (that's just my guess, it might be wrong). How exactly would that work in the case of Wikipedia and Facebook? Toshio Yamaguchi (talk) 18:52, 7 June 2011 (UTC)[reply]
How that would work essentially is that you log in to Facebook, they tell Wikipedia that you are logged in to your account and your name is "John Smith"; of course, they'd provide a unique ID so that you don't conflict with other "John Smith"s. Gary King (talk · scripts) 18:56, 7 June 2011 (UTC)[reply]
  • Undecided This might be a good for attracting new editors. However, I would like to see a better developed and more detailed proposal before deciding. I think this could also have a lot of negative issues. Toshio Yamaguchi (talk) 19:12, 7 June 2011 (UTC)[reply]
  • Opposed to any sort of non-optional, formal integration of the 'Like this!' box variety, for the following reasons (which I've kept quite abstract for the time being):
a) Credibility - connecting to facebook etc. in any overt way detracts credbility from us, especially in academic or professional circles - per Sven
b) Editor ingress - as has been observed, FB already mirrors wikipedia and links to our articles. That means that people are already able to jump from FB to our site, introducing a feature which allowed them to jump back doesnt seem paticularly beneficial in terms of keeping editors.
c) Expert retention - If I'm an expert on an obscure subject and create an article on something which is likely not of much interest to non-experts and come back a month later to see that it still has "0 likes" whilst another article on Will Mellor has thousands of likes, I probably won't bother making another.
d) Commercial reasons don't apply - Most sites, such as newspapers, blogs etc. have commercial motivations behind the FB links and 'tweet this' buttons - they want to draw in more views to earn more money - these reasons don't really apply to us.
e) Lack of techical knowledge needed - Come on, anybody who can edit wikipedia can also copy and paste a URL anyway, we don't need to build a toolbar into the interface to help them do that.
f) Independance - personally, I quite like the idea of having a major site which isn't linked into the 'evil empire' of the day.
They're my (possibly half-baked) thoughts anyway - I may try to expand if this becomes a serious proposal rather than a brainstorm. (Note that I'm completely unopposed to allowing people to choose to include something like this in an alternate skin/JS function/whatever). Regards, Bob House 884 (talk) 19:32, 8 June 2011 (UTC)[reply]
Nasa's web site[14] integrates with Facebook, Twitter, Digg and many other social networking sites. Can someone show me some evidence that this has caused NASA to lose credibility in academic or professional circles? A Quest For Knowledge (talk) 19:49, 8 June 2011 (UTC)[reply]
Bob: I don't think anyone's proposing that we add "Like this" buttons to Wikipedia. Instead, I see two proposals: 1) Let readers share articles they find interesting by sharing them on Facebook, Twitter, etc. 2) Let people log in using their Facebook accounts. A Quest For Knowledge (talk) 19:52, 8 June 2011 (UTC)[reply]
Regarding Nasa, that's a completely different situation. Nasa doesn't have to fight for credibility like we do (they have it and would have to work to lose it, we're gaining it and have to work to not lose what ground we're acquiring), nor do they allow anyone to edit their site. Ian.thomson (talk) 19:56, 8 June 2011 (UTC)[reply]
Can you explain exactly how letting readers share articles they find interesting with their friends will cause Wikipedia to lose credibility? I don't get it. A Quest For Knowledge (talk) 20:21, 8 June 2011 (UTC)[reply]
  • Comment - First, it is disheartening to see the elitist attitude of some of the comments here. It is unfair to assume that we are smarter than others, simply because they involve their friends in their lives, and we anonymously bicker about hyphen usage. Like I said above, I do hate social sites, but that doesn't mean I hate their users. I wanted to point out http://help.wikia.com/wiki/Help:Facebook_Connect as an example of how a MediaWiki site uses the Facebook API. Also, if anything were to happen with "like" buttons, or social bookmarking links, this could be handled through an integrated gadget, so only logged-in users who choose to have to see it. This should help us keep our "street cred". ▫ JohnnyMrNinja 20:35, 8 June 2011 (UTC)[reply]
  • I have to say I'm not a fan. --Guerillero | My Talk 21:04, 8 June 2011 (UTC)[reply]

Proposal for a "timeline" layout

First, apologies if this is wildly against policy/misformatted -- not a regular ;) I've noticed a lot of sections have a lot of one sentence paragraphs that go "On [date] thing X happened." one after another. I think adding a CSS style to support a timeline would be easy, and such articles could really benefit from the new formatting (I can't speak as to the wikimarkup side of things). Here's an example of this kind of page: Auction Rate Security#2008 auction failures — Preceding unsigned comment added by Felipeochoa0918 (talk • contribs)

  • Personally, I find "On date X, Y happened" entries to be nothing more than lazy writing. Unless a section is specifically intended to be a timeline, the proper solution is to turn these entries into proper paragraphs. Resolute 16:24, 5 June 2011 (UTC)[reply]

There was a discussion a while back about some kind of graphic network tool that would make nicer/easier Ahanentafeln (sp?), taxonomies, etc etc. Might be worth digging for that. Rich Farmbrough, 19:00, 5 June 2011 (UTC).[reply]

Some articles in quieter backwaters tend to build up a timeline peacemeal, because an editor will see some news on the subject in a source, and add a few words covering just that news, then a few months later another similar edit is made, over and over again - so the article gradually accumulates a chronological sequence of awkward bullet-points even when it's a subject which would be better off with a single, carefully-written paragraph. I'm wary of encouraging the development of such timelines when a better solution would often be to invest slightly more effort in writing a single block of prose. bobrayner (talk) 23:25, 5 June 2011 (UTC)[reply]

For the relevant essay, see WP:Proseline. —Mike Allen 01:39, 6 June 2011 (UTC)[reply]

Are you referring to something like this currently used on the Commandant of the Marine Corps article?:
James F. AmosJames T. ConwayMichael HageeJames L. JonesCharles C. KrulakCarl Epting Mundy, Jr.Alfred M. Gray, Jr.Paul X. KelleyRobert H. BarrowLouis H. Wilson Jr.Robert E. Cushman, Jr.Leonard F. Chapman Jr.Wallace M. GreeneDavid M. ShoupRandolph M. PateLemuel C. Shepherd Jr.Clifton B. CatesAlexander VandegriftThomas HolcombJohn H. Russell, Jr.Ben Hebard FullerWendell Cushing NevilleJohn A. LejeuneGeorge BarnettWilliam P. BiddleGeorge F. ElliottCharles HeywoodCharles Grymes McCawleyJacob ZeilinJohn Harris (USMC)Anthony GaleArchibald HendersonFranklin WhartonWilliam Ward Burrows ISamuel Nicholas


Its not the simpest thing to use I admit but it does work.--Kumioko (talk) 16:47, 6 June 2011 (UTC)[reply]

There's a very useful timeline, that unfortunately suffers from formatting problems (as well as using whole years rather than specific dates) at Timeline of Presidents of the United States. Before joining Wikipedia, I'd independently constructed something similar on MS Excel (to show how many former and future U.S. Presidents coincided with any president's term), but I haven't figured out if there's a good solution for this page. —— Shakescene (talk) 21:30, 6 June 2011 (UTC)[reply]

Page moves from userspace

Proposal: allow editors the option to suppress the creation of a redirect when moving a page out of userspace into mainspace (which would normally be a userspace draft-type page). That's probably harmless, is a common task, and prevents useless cross-namespace redirects. It's also a task which will likely become more common when the limitations on non-autoconfirmed users creating articles goes live, since many will be creating userspace drafts instead. Rd232 talk 02:20, 6 June 2011 (UTC)[reply]

  • I know nothing about the technicalities of this while still not allowing suppression of redirects with other page moves. If it is technically feasible though, I would support it. It seems quite silly for people to have to request deletion of a cross namespace redirect that they didn't want in the first place. LadyofShalott 03:38, 6 June 2011 (UTC)[reply]
    • It's a good idea, but it widens a loophole. Moving pages from userspace means that any editor can easily create an article and get around WP:NPP. Suppressing redirects would make it less likely that an admin is going to come across it. I don't know if that's a reason to vote it down, I'm just pointing it out. ▫ JohnnyMrNinja 04:38, 6 June 2011 (UTC)[reply]

Back to the question: if/when the NPP loophole for moves from userspace is fixed (Template:Bugzilla), do we want this to happen? Rd232 talk 10:26, 9 June 2011 (UTC)[reply]

More discreet banners

Hi, I would like to suggest that the banners that appear at the top of so many articles ("needs additional citations", "neutrality is disputed", etc. etc.) are made smaller (while still being noticeable). The ones we have now are better than a few years ago, but they are still big, blocky and ugly, and give the impression that most of Wikipedia is in a perpetually broken state. 86.181.172.159 (talk) 03:08, 6 June 2011 (UTC).[reply]

That's because most of Wikipedia is in a perpetually broken state. They are big and ugly for a reason; readers (the people these articles are written for) must be made aware when there are problems with articles, particularly when those problems have to do with reliability and sourcing. Their large ugliness is a feature, not a bug. → ROUX ₪ 03:29, 6 June 2011 (UTC)[reply]
Yea, god forbid we attribute one iota of intelligence to our readers. Gotta watch out for there best interests and well-being, don't you know? Can't have people reading things that we don't like, after all.
— V = IR (Talk • Contribs) 03:39, 6 June 2011 (UTC)[reply]
IN addition to this I would like to suggest that we calrify the rules of using some of these templates to say they are not needed on stubs. If an article is a stub there is almost no reason to put a Cleanup, expand, wikify or several others on the article. These are self evident by the class of the article. Some such as Ref needed, ref improve or the BLP tags would and should still be allowed though IMO. --Kumioko (talk) 16:42, 6 June 2011 (UTC)[reply]
You can already use {{multiple issues}} to merge these banners together. I agree that they should be smaller, at least for me as they are just a nuisance when I'm trying to read an article, so I shrink them with this script. Gary King (talk · scripts) 20:04, 6 June 2011 (UTC)[reply]
You know Gary thats an excellent point. Rather than trying to choose a one size fits all scenario why don't we see about adding that script as a preference Gadget that allows people to decide for themselves if they want the banners smaller. Some may and some may not and either way is fine but we should be allowing the users to decide how they want to see them. --Kumioko (talk) 20:15, 6 June 2011 (UTC)[reply]
Certainly at least the POV template should be big. -- Eraserhead1 <talk> 20:16, 6 June 2011 (UTC)[reply]
You'll probably like this banner I saw the other day: Voyager640 (talk) 08:16, 7 June 2011 (UTC)[reply]
I love that banner, and I'll be sure to use it on every page I read that doesn't meet Featured Article standards. Regarding my script that I mentioned above called Smaller Templates, all it does is it removes the icon from from these templates, then shrinks the text down to about 75%, and removes the "descriptive" text so only the bold text remains (and it unbolds it), so that you can still read and understand the template fine, but it takes up much less space. Gary King (talk · scripts) 18:33, 7 June 2011 (UTC)[reply]
I find that banner offensive. People who volunteer their time to this project do not have an obligation to fix every problem they see and often the problems that can be tagged by a person, cannot be fixed by that same person for many reasons. That's for "passive taggers" but more importantly, the people who do most of the "drive-by tagging" are the dedicated new pages and other patrollers, who do a critical, mostly thankless task, and to say that they could remediate the problems in the articles they tag rather than do the tagging is so unrealistic that there's little to say on the matter.--Fuhghettaboutit (talk) 23:59, 8 June 2011 (UTC)[reply]
Your criticism cuts both ways, though. People who create new articles are not obligated to create featured articles right out of the gate. Plastering our articles with all sorts of warnings in the readers faces makes all of us who contribute here look silly, at best. All other maintenance issues are dealt with on the talk page, and for good reason. Readers aren't stupid, and our behaving as though we can't trust them to realize that our content comes with caveats that have been well covered over the previous 10 years is rather insulting to them and to authors and editors. Nobody who is interested in actually improving articles is suggesting that maintenance categories, and the work at clearing the backlogs, should be stopped; the reason that this is a perennial point of discussion is that contributors don't want their contributions besmirched with warning tags, is all. You're asking for consideration, but failing to acknowledge how you're not giving consideration to others yourself.
— V = IR (Talk • Contribs) 00:35, 9 June 2011 (UTC)[reply]
Let's separate out the template above from what you're saying. Say I agreed with you on all fours. I would still find that template offensive for the same reasons I just gave. That template doesn't make your points, it just attacks with a massive brush the entire cadre of editors who tag any article with any maintenance template whatsoever. Putting that aside, I always find the idea that any reader would be insulted by seeing these templates silly, as if they were directed against them specifically; that's what insults people, not notices on articles they land on that on their face are directed at no person in particular. Meanwhile, you're demonstrably wrong that there aren't large numbers of people who actually aren't aware of the "caveats". We often see users at the help desk here, for example, and in other places all over the net, who have no idea and actually assume our articles consist of vetted content, written by a central authority of experts. But you're right that large numbers of people also do know the general caveats, and it's a far larger percentage than those who don't. But this is a side issue, because the caveats about our content are unspecific and do not make the targeted tags any less important or invalid. People hear that Wikipedia content can be added by anyone and that its unreliable and statements in that vein, but that does not translate to knowing specifics, like that some articles have cited sources and some do not; that articles with lots of inline citations are almost always much more reliable than the reverse of that coin; that if all the sources in an article are primary sources the article is probably POV, and on and on. Articles which are unreferenced, poorly referenced, non-neutral, etc. should not be relied on; people coming to these articles should be told in no uncertain terms—not on the talk page—but right up front, that the article has certain specific problems. Taking the general caveats to the specific to inform the public's reading is only one function. Another is to hope that action is actually taken by someone who cares about the subject; the templates are a guide for suggesting the action that is actually needed, and it won't act to inform but a few if hidden on the talk page. Neutral, balanced, comprehensive, well sourced articles containing no original research need no tags. Until they are well on the path to that stage, flagging problems they actually have is not "besmirching" them.--Fuhghettaboutit (talk) 04:50, 9 June 2011 (UTC)[reply]

I assume that none of these comments are directed at me in particular, but just in case, my last comment above was meant to be sarcastic (the first sentence). Gary King (talk · scripts) 19:55, 9 June 2011 (UTC)[reply]

Preceding Unsigned Comment

It just occurred to me that there isn't really any good reason to have the sinebot add a small-text template instead of just substing in the user's signature, which I'm sure is possible. Of course we would still encourage people to sign their comments, but the small-text message seems to serve no purpose other than singling out newbies and providing negative reinforcement to get people to sign their comments. It's really quite ridiculous, jarring to look at, a strain to the eyes, and WP:BITEingly disruptive. Does anybody know why this was done in the first place? ☻☻☻Sithman VIII !!☻☻☻ 09:31, 6 June 2011 (UTC)[reply]

No bot could (easily) substitute in your actual signature, but it could guess at your signature (by assuming the default). On the other hand, the bot sometimes gets it wrong. This, I think, is the justification for making it obvious that they didn't add that signature. Whether it needs to be quite so obvious, I'm not sure. - Jarry1250 [Weasel? Discuss.] 09:39, 6 June 2011 (UTC)[reply]
How is it bitingly disruptive to try to get someone to sign their comments? I think it's completely appropriate to make it obvious. The biggest danger to me is having a bot that impersonates an editor, by putting in a person's signature and not making it obvious that the person didn't add it themselves. I don't think we should ever have a bot that makes edits that appear to have come from another editor no matter what the reason. -- Atama頭 17:32, 6 June 2011 (UTC)[reply]
Bot sometimes mistakenly sign comments when people re-add comments by others (i.e. [15]), which is why it (quite properly) uses the "unsigned" template. –xenotalk 18:11, 6 June 2011 (UTC)[reply]

Formal proposal to put Featured Lists on the main page from 13 June:

A proposal (and poll) is currently in place on Talk:Main Page#Formal proposal to put Featured Lists on the main page from 13 June to have Today's featured list appear on the Main Page each Monday. The proposal will run until 23:59 UTC on Saturday, June 11. — Edokter (talk) — 11:33, 6 June 2011 (UTC)[reply]

Connecting Wikipedia to Spoken-Web

Hi all,I developed a new site to help and serve the blind or visually impaired community by making the web more accessible to them.

[1]http://www.spoken-web.com Using this site, a person who is blind or who has a visual impairment can hear the full range of any wikipedia article content, provided in a logical, clear, and understandable manner.

I thinking about better ways to connect between Wikipedia articles to spoken-web site. such as a link from any wiki page direct to the spoken version of the article

Benefits:

  1. Up-to-date - The spoken version is been generated on-the-fly, so it always be the most updated one
  2. Faster - The text-to-speech engine is on the client computer
  3. Economical - spoken versions for all 2.8 million articles would not take any space

--Eyalshalom (talk) 15:56, 6 June 2011 (UTC)[reply]

Disadvantages:

  1. For the meanwhile (money issues) the site availble only in english, and the technology requiered IE browsers and Windows Operation System
  2. Text to speech engines often sound quite... unnatural when they synthesize speech (but there is a solution for this too)

--Eyalshalom (talk) 15:57, 6 June 2011 (UTC)[reply]

About

[2]Spoken-Web is a web portal, managing a wide range of online data-intensive content like news updates, weather, travel and business articles for computer users who are blind or visually impaired. The site provides a simple, easy-to-use interface for navigating between the different sections and articles Using the keyboard to navigate, a person who is blind or who has a visual impairment can hear the full range of an article content provided in a logical, clear, and understandable manner.
Spoken-web is non-profit organization. --Eyalshalom (talk) 15:54, 6 June 2011 (UTC)[reply]


  • Spoken Web was founded at 2006 and had wiki ref since 2008.IBM started World Wide Telecom Web project at 2008 and they changed the wiki page (you can see it in the history of the page).

but this is not the point here--Eyalshalom (talk) 18:55, 6 June 2011 (UTC)[reply]

Show blocked users gadget

Russian Wikipedia has a Gadget to show blocked users, which I've been using for a while.

add

importScriptURI('http://ru.wikipedia.org/w/index.php?title=MediaWiki:Gadget-markblocked.js&action=raw&ctype=text/javascript');

to Special:Mypage/Skin.js.

Proposal: import the Gadget, and add it to Preferences as an actual Gadget. Rd232 talk 16:52, 6 June 2011 (UTC)[reply]

That would be really handy, I usually look at an editor's contributions to see if they're blocked. Seeing it right away would be great. -- Atama頭 17:33, 6 June 2011 (UTC)[reply]
How about using User:Gary King/userinfo.js instead (I forked the script from User:PleaseStand/userinfo.js; the original author has been busy and therefore unable to implement bug fixes, updates, etc.), which shows more than just blocked info, but also the user's groups, number of edits, last edited time, etc. The documentation is here. Gary King (talk · scripts) 19:09, 6 June 2011 (UTC)[reply]
That's good, but it only displays block status when on the user or user talk page. The Russian markblocked script puts a line through a username wherever it appears, if the user is blocked. Rd232 talk 19:23, 6 June 2011 (UTC)[reply]
Ah, didn't realize that. Y'know, a number of scripts with similar features can probably be combined so that we have fewer gadgets. Gary King (talk · scripts) 19:31, 6 June 2011 (UTC)[reply]
I'm sure that's the case, and that would probably be helpful both in general and in this case (though how the extra complexity of scripts vs fewer scripts would affect maintainability I'm not sure). On a related note, others may be interested in the conversation at MediaWiki_talk:Gadgets-definition#Gadget_tab_structure about restructuring the Gadget tab to be more user friendly. Rd232 talk 19:34, 6 June 2011 (UTC)[reply]
The scripts don't even have to interact with each other if we don't want them to. They can just be "packaged" together; it's somewhat similar to using importScript once for Twinkle rather than half a dozen times for each of its components (although in that case, each script is dependent on others). Gary King (talk · scripts) 20:00, 6 June 2011 (UTC)[reply]
For what its worth I am going to suggest to the AWB developers to line out blocked users as well if AWB is being used to add comments to talk pages. --Kumioko (talk) 20:28, 6 June 2011 (UTC)[reply]
"line out"? "strike out" or "line through" - pick one :P ... Yes, could be useful addition to AWB. Rd232 talk 21:31, 6 June 2011 (UTC)[reply]
I oppose that (the AWB thing) as strongly as possible. AWB has no way of sensing when a comment was added; are you seriously suggesting that because a user happens to have accidentally crossed the 3RR line and earned a 24 hour block, you want to strike through every comment that user has ever made? If I see anyone refactoring talk comments in this way, I'll have no hesitation at all in blocking for disruption. – iridescent 21:55, 7 June 2011 (UTC)[reply]
Irridescent I'm going to assume AGF that you did not just imply that if "the AWB thing" is put into effect by consensus of the Community that you will go around blocking individuals who do it? And as an administrator your "threat" can be seen as trying to intimidate, threaten, and unduly influence future discussion and implementation. Your personal views against this proposal are one thing, your threats of blocking individuals is a little overbearing. A clarification of your opinion and perhaps striking through your threats of blocking may be something you might want to consider as a good faith move right now.Camelbinky (talk) 22:23, 7 June 2011 (UTC)[reply]
I understood Kumioko to be talking about indicating to AWB users when an editor is blocked, by marking up the text shown to the AWB user (i.e. an equivalent of the JS script). Saving strike-through into Wikipedia is obviously undesirable. Rd232 talk 22:40, 7 June 2011 (UTC)[reply]
The script is listed at WP:JS, which links to User:NuclearWarfare/Mark-blocked script.js, which links to the Russian one. However I did find that calling up the Russian one did slow page loads down (I could see FF was waiting for ru.wikipedia), so I copied the whole thing to User:Ronhjones/strikeblocked.js and then called that from my monobook.js with an importScript('User:Ronhjones/strikeblocked.js'); - which has improved the page loads.  Ronhjones  (Talk) 22:29, 7 June 2011 (UTC)[reply]
Cool, thanks. Now how about making this a gadget - or perhaps bundling it with an existing gadget, as Gary King suggested above? Rd232 talk 10:24, 9 June 2011 (UTC)[reply]

Social Media

It's becoming increasingly clear to me that all Wikipedia articles and photos need a social media share functionality, probably just FB and Twitter, but maybe a "Share This" dropdown if we have to be fair. Thanks for reading and cheers. ~J — Preceding unsigned comment added by Jengod (talk • contribs) 19:46, 6 June 2011 (UTC)[reply]

I somewhat disagree. Seems like an easier way to attract vandalism. If people truly want to read something, they will search for it and Wikipedia is normally a top search result. The visits should be organic. Encyclopedic information is generally not something that you share in a social manner. Gary King (talk · scripts) 20:02, 6 June 2011 (UTC)[reply]
I am somewhat on the fence with this one myself. I admit that allowing this type of functionality might draw some attention to the articles I also believe that there would be some significant drawbacks, vandalism being one of them. I do think that it might be interesting to do a test of some to see (maybe pick a couple hundred). I think we need to ask ourselves though what the return on the investment is. What would be gained and lost by doing this and is it worth the investment of time and energy? The foundation has been beating the bushes looking for ways to attract more editors and this could be a way to do that. --Kumioko (talk) 20:23, 6 June 2011 (UTC)[reply]
Since most people use their real names on Facebook, I doubt very many would be vandalizing articles. A Quest For Knowledge (talk) 20:31, 6 June 2011 (UTC)[reply]
If "most" people use their real names, does this not mean that there are no mechanisms to ensure that people use their real names? Rilak (talk) 08:45, 7 June 2011 (UTC)[reply]
Using real names on Facebook and vandalizing articles here are two different things. You can discover a Wikipedia article through a friend on Facebook, then visit the article, then vandalize it. We would never know the user's Facebook name. On a somewhat related note, for about a year now, Facebook has been using Wikipedia's data to create information pages on every single subject. So for instance, in a person's profile if they listed "Cooking" as an interest, and you clicked on Cooking, you'd go to something like facebook.com/topics/cooking which would show the Wikipedia article for Cooking. I don't know how we could use that to draw editors here, but it's a thought. Gary King (talk · scripts) 18:29, 7 June 2011 (UTC)[reply]
I totally agree with the original poster. That's why I made Wikipedia:Sharebox in the first place. But to implement it everywhere, we need an open and free sharing system that supports multiple social share tools. We can't promote just one or two services, and above that, social sharing services are still very dependent on your country of origin/language in terms of popularity. That's quite a development effort. Not impossible, but will take considerable time none the less. —TheDJ (talk • contribs) 20:36, 6 June 2011 (UTC)[reply]
@AQFK: Especially not BLP articles, if you catch my meaning. =p Sir William Matthew Flinders Petrie | Say Shalom! 20:33, 6 June 2011 (UTC)[reply]
Apparently, the Wiki software already supports this feature. For example, scroll to the bottom of a WikiNews article.[16] There are links for Facebook, Twitter, LinkedIn, Digg, and several others. A Quest For Knowledge (talk) 20:39, 6 June 2011 (UTC)[reply]
That's just a template, found here. We can't use the same exact method to implement them here because we'd have to edit every single article and add the template to each one. Gary King (talk · scripts) 18:29, 7 June 2011 (UTC)[reply]
mw:Extension:PageNotice might obviate that, if it were installed. Rd232 talk 10:23, 9 June 2011 (UTC)[reply]

Offensive usernames of blocked sockpupets

Would it be a good idea to hide usernames which attack individuals or groups, or are generally disruptive or offensive ? In particular I wonder whether it might be appropriate to hide the name of this this sockpuppet, simply because if such content was in mainspace or userspace it would be deleted per our policy on attack pages. Would there be technical issues with giving such blocked user's pages generic titles such as "Blocked user" or "Blocked sockpuppet of user x"  ? Although I can't find a Wikipedia template which does it, there are some on other Wikia projects (see, for instance [17]). I am not suggesting that the usernames be changed, simply that they should be replaced by a template. It seems hypocritical that we would delete such content if it was placed anywhere else, yet we allow it to stay clearly visible due to it being part of the user's name. Anthem 19:57, 6 June 2011 (UTC)[reply]

If the title is a BLP violation or attacks someone I would agree and support this. I would say though that if it just contains a swear word or something that might just offend a few folks or is a general irritation then no. --Kumioko (talk) 20:25, 6 June 2011 (UTC)[reply]
I think if a username just contains a swearword, there's no obvious reason for hiding the name. There should be a case for hiding the username when there is a BLP violation/attack usernames (such as the one linked to), and what might be considered "hate speech" (ie. extremely misogynistic or racist usernames). --Anthem 20:53, 6 June 2011 (UTC)[reply]
Usernames can be revision deleted from page histories and even user creation logs etc, if necessary. Requests can be made via CAT:REVDEL. Rd232 talk 21:29, 6 June 2011 (UTC)[reply]
The issue is the presence of the offending username on the user's userpage. --Anthem 21:30, 6 June 2011 (UTC)[reply]
Well in extreme circumstances the user might possibly be renamed (WP:CHU). Note that such accounts will often be tagged with a template which NOINDEXes them (eg {{sockpuppet}}). Rd232 talk 21:52, 6 June 2011 (UTC)[reply]
Hmm, I was thinking it would be simpler to have a template an admin (as opposed to a bureaucrat) could apply. --Anthem 03:20, 7 June 2011 (UTC)[reply]
There could be a template requesting a rename (modelled on the WP:Edit request system), for bureaucrats to act on, but I'm not sure it's worth it. Rd232 talk 10:22, 9 June 2011 (UTC)[reply]

Welcome/how to edit template on talk pages

A discussion has been raised on the foundation-l mailing list about new users to highly trafficked pages regarding helping new users. The point brought up indirectly that I noticed is that we do not have a bot or AWB added a template assisting in talk pages and editing, welcoming IPs and new users on talk pages that offer assistance. Instead, we plaster pages with Projects and class and stub et.al templates. Would anyone care to modify the welcome template to talk pages and not just user talk pages, and can we just add the template at whim as we do other talk pages? Keegan (talk) 06:29, 7 June 2011 (UTC)[reply]

I hijacked {{hello world}} and adapted it a bit for this purpose. There is a generic {{talk page}} template that has existed for years as well. It's not very friendly, though. --MZMcBride (talk) 06:39, 7 June 2011 (UTC)[reply]
I think {{talk page}} is an excellent header for talkpages, containing a few helpful links but not being overwhelming. I don't understand why you would prefer the basic {{hello world}} template over it. You weren't thinking of adding an abomination such as {{Welcomeg}} were you? I would give my strongest possible oppose to that. Yoenit (talk) 08:36, 7 June 2011 (UTC)[reply]
The {{talk page}} template is dreadful at addressing the need here - that is, telling completely new users what a talk page is for. Even for those of us who know what it's for, it is yet-another-brown-box-to-ignore, and certainly doesn't stand out.
I note, BTW, that these proposed changes have been reverted without discussion. Charming.
James F. (talk) 09:09, 7 June 2011 (UTC)[reply]
Adding the standard welcome template is even worse, for it does not even mention talkpages. How is that supposed to help new users? I would be open to an alternative template on top of talkpages, but {{hello world}} is not it. Yoenit (talk)09:17, 7 June 2011 (UTC)[reply]
(addendum) Also, why are you whining about that revert? A reason is given in the edit summary and it is standard practice following the Wikipedia:BOLD, revert, discuss cycle. Yoenit (talk) 09:26, 7 June 2011 (UTC)[reply]

{{Talk header}} (for it is he - {{talk page}} is a redirect) has the header This is the talk page for discussing improvements to the Foo article. and the first item in the list of information is This is not a forum for general discussion of the article's subject.. That seems to cover the main requirements. As to eye-catching prominence: in a while we'll be able to add CSS specific to new users, so we could (if we wanted) make it all bigger and more eyecatching just for them. In the interim, we could, if we wanted, add a |big=yes parameter to the template to make it So Annoying You Can't Miss It. PS Looking at it through experienced-user eyes is probably not the best judgement of its visibility, since we're used to ignoring those brown boxes to look for the content. Rd232 talk 09:35, 7 June 2011 (UTC)[reply]

I also think that adding a template of some kind to talk pages should be done to inform out users and if we did it as a standard we could implement it on meta and let it be static without having to add it manually to pages as an edit. IMO we should not be waiting till something goes wrong to tell them not to bicker. Just my opinion. --Kumioko (talk) 23:27, 7 June 2011 (UTC)[reply]
I agree. The work could be put on the MediaWiki code of the talk page, similar to our warnings and whatnot when you click "edit" but instead be static on the talk page itself.Keegan (talk) 04:58, 8 June 2011 (UTC)[reply]
There is MediaWiki:Talkpageheader which I think would do the job, but it would be displayed on every single talk page. mw:Extension:PageNotice (referenced in Template:Bug, for per-namespace sitenotices) would provide more control, but isn't currently installed. Rd232 talk 10:14, 9 June 2011 (UTC)[reply]

Hi, I propose that a link to Special:Newpages is added to the interaction section of the sidebar. We currently have recent changes linked, and I think it would be useful to compliment it with pages too. AD 19:19, 7 June 2011 (UTC)[reply]

I've wanted that for months; I think it would help attract more users to start NPP, which until we get the changes implemented we still badly need. The Blade of the Northern Lights (話して下さい) 21:44, 7 June 2011 (UTC)[reply]
I wholeheartedly agree; when I used to do NPP, I installed a gadget that displayed new pages in the sidebar because typing it in the search bar every time was annoying. /ƒETCHCOMMS/ 03:28, 8 June 2011 (UTC)[reply]
Couldn't you just put it on your watchlist? Peter jackson (talk) 14:50, 8 June 2011 (UTC)[reply]
You can't watchlist any of the Special:SpecialPages, nor edit them for that matter. Yoenit (talk) 14:55, 8 June 2011 (UTC)[reply]
That hadn't occurred to me. My list includes a category & some pages in project space, so I sort of vaguely assumed you could have anything. Peter jackson (talk) 15:21, 9 June 2011 (UTC)[reply]
Good idea. I'm so used now to tying WP:NEW and hitting the first link on that page that I don't really need it, but I would have appreciated it a few years back.--Fuhghettaboutit (talk) 22:41, 8 June 2011 (UTC)[reply]
Sounds like a great idea, to me.
— V = IR (Talk • Contribs) 23:03, 8 June 2011 (UTC)[reply]
Yes, I think this would be useful. Killiondude (talk) 23:07, 8 June 2011 (UTC)[reply]
How many of the en.wp visitors are looking for special:NewPages ? I never visit it. Doubt my mom does either. The sidebar is precious space and it should be used for the most required or most useful links for ALL readers. I'm not really sure if NewPages qualifies for that. —TheDJ (talk • contribs) 16:47, 9 June 2011 (UTC)[reply]
As User:Fuhghettaboutit mentioned above, new page patrollers rely on it extensively. One more link in the Interaction section isn't going to swamp the sidebar, and it's not as though Special:Newpages is soe off the wall page.
— V = IR (Talk • Contribs) 16:55, 9 June 2011 (UTC)[reply]
I find the live feed in the sidebar perfectly adequate. See User:TheJosh/Scripts/NewPagePatrol.js. Kudpung กุดผึ้ง (talk) 17:07, 9 June 2011 (UTC)[reply]
@TheDJ: how many visitors, if any, are looking for Recentchanges, which has been there forever? AD 17:13, 9 June 2011 (UTC)[reply]
I have no reason to believe a reader would view RecentChanges over NewPages. They could both be presented. I think it would be intriguing to visitors to view new pages being created on Wikipedia. Just because they aren't looking for it now doesn't mean they won't click the link when presented with it. Killiondude (talk) 17:25, 9 June 2011 (UTC)[reply]
Recent changes is one thing, but let's not forget that the Wikipedia is read by even more people than those who edit and patrol it. The term New Pages is misleading: 80% of 'new pages' are the inapropriate ones that are going to be deleted - do we really want to draw the general readership's attention to them? Kudpung กุดผึ้ง (talk) 18:20, 9 June 2011 (UTC)[reply]
80%? Where'd you get that from? Recent changes is designed for editors, not readers, and contains things like vandalism that we are drawing attention to. New pages is an accurate name, it says exactly what it is. I still don't see any argument against including it when we have Recentchanges there. AD 18:51, 9 June 2011 (UTC)[reply]
You mean "change bad" is not a good argument here? Say it ain't so! ;)
— V = IR (Talk • Contribs) 20:09, 9 June 2011 (UTC)[reply]

Deprecate the term "autoconfirmed" in favour of something meaningful

I just came across the term "autoconfirmed user" (referring to WP:AUTOCONFIRM) and found myself looking at it through newbie eyes and thinking WTF? It's a technical term without any obvious meaning for a newcomer to get a handle on. I propose deprecating its use throughout Wikipedia in favour of "established user" or something which similarly gives a flavour of what the thing being described means. The deprecation would be painless in that old shortcuts etc would work, but terminology in help pages, templates aimed at newbies etc would be rapidly standardised in favour of the new term. Rd232 talk 20:34, 8 June 2011 (UTC)[reply]

I frankly don't think this is a good idea. "Autoconfirmed" is a very objective term, whereas there's no implication with "established user" that there are a set of criteria which need to be met. In any case, many autoconfirmed users aren't "established" at all, and the term is a subjective overload. --Anthem 21:47, 8 June 2011 (UTC)[reply]
I wouldn't exactly call a user of 4 days / 10 edits "established"... --KFP (contact | edits) 22:00, 8 June 2011 (UTC)[reply]
I tend to agree. "autoconfirmed" is certainly jargon, but it's so well established now that trying to change it seems like unneeded effort to me. Just for the heck of it though, "verified" would be a better choice then "established".
— V = IR (Talk • Contribs) 21:58, 8 June 2011 (UTC)[reply]
"well established" isn't much of an argument; no-one stopping oldtimers from using it, the issue is documentation. "Verified" is no good, that's actively misleading in suggesting some kind of verification (=checking) process. Rd232 talk 22:04, 8 June 2011 (UTC)[reply]
Well, that's where the objections to "established" are coming from as well. There's nothing about being autoconfirmed that makes a user "established". Maybe just dropping the "auto", so that the term is "confirmed", but again I don't really see the point of doing that now. I just think that this ship has sailed.
— V = IR (Talk • Contribs) 22:53, 8 June 2011 (UTC)[reply]
  • Autoconfirmed is one of those weird wiki terms, and I personally see no need to change it. We aren't the simple english wikipedia here, people. I'm 99% sure that any newbie (like myself when I was one) gets the idea that autoconfirmed is some sort of status that a user gets automatically after a bit. Besides, what are we going to rename it to, "user with 10 edits and four days experience"? Ajraddatz (Talk) 22:10, 8 June 2011 (UTC)[reply]
  • I would prefer the term "editor" instead of autoconfirmed. Many other wikis have editor as what autoconfirmed on enwiki is. —Croisés Majestic (sur nous mars) 22:16, 8 June 2011 (UTC)[reply]

Support heartily: Well, maybe I'm very different from other editors, but the whole gamut of Wikipedianese is something I've treated like reading a foreign language text or an alien slang: I just pass over many obscure terms because it would be impossible to read if I had to search for every definition; I just hope I pick up the vocabulary en passant and from context. That meant it was months, even years, before I fully grasped what dab, Prod, autoconfirmed, deprecate, RfA, XfD, RFC, ANI, CSD, FAC, CC-BY-SA, GFDL, etc., etc., meant. Surely there's a better term than "autoconfirmed": the question should rather be what's the best substitute: one that's clear, accurate and reasonably unambiguous. ¶ And, no, "autoconfirmed" doesn't necessarily mean what it says, any more than "Prod" or "Dab" do; to me (instead of being, presumably, a contraction of "automatically confirmed") it means "self-confirmed", which fits the minimum time and edits requirement in only in the vaguest and most indirect way —— Shakescene (talk) 06:47, 9 June 2011 (UTC)[reply]

Permanently protect closed AfD discussions

A closed AfD discussion carries the following message on top:

The following discussion is an archived debate of the proposed deletion of the article below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's talk page or in a deletion review). No further edits should be made to this page.

Wouldn't it be better if the closing admin simply redlocked the discussion? Toshio Yamaguchi (talk) 14:11, 9 June 2011 (UTC)[reply]

I don't see the need for that. Even if some people added opinions after closure, nobody noticed that, and then they tried to act as if there was a different consensus, the page history would reveal the trick Cambalachero (talk) 15:09, 9 June 2011 (UTC)[reply]
Sometimes archived discussions have to be changed for renamed editors or for moved articles, to change the links. Fram (talk) 15:14, 9 June 2011 (UTC)[reply]
Another posible case is when people cite a category during a discussion. Sometimes they mention [[Category:Foo]] rather than [[:Category:Foo]] (with : before "Category") The discussion is thus categorized there, and someone checking the categories would need to clean it from unwanted entries. Cambalachero (talk) 15:23, 9 June 2011 (UTC)[reply]

bAck to top

a bac to top button at the beginning and end of every section would be nice expecially for navigating long articles. thoughts? Heyitsme22 (talk) 15:18, 9 June 2011 (UTC)[reply]

The "Home" button works perfectly fine in this page. Cambalachero (talk) 15:25, 9 June 2011 (UTC)[reply]
I brought up something similar a while ago (see Wikipedia talk:Help desk/Archive 9#'Skip to top' button) and I would support such an addition. Toshio Yamaguchi (talk) 15:31, 9 June 2011 (UTC)[reply]
Easy to implement as a script so users who choose to have this feature can install it for themselves. Gary King (talk · scripts) 19:53, 9 June 2011 (UTC)[reply]


First of all, I am wondering whether the initiator of this speaks English as a first language, as I did notice there were several mistakes in the English - it should have been headed "Back to Top" (or maybe the person was just tired). Enough of that - I just wanted to point out that, using most, if not all, web browsers, you can go to two arrow keys at the head of the page, in the top left hand corner. Clicking on the arrow that points back will, I think, achieve what you want to do. ACEOREVIVED (talk) 20:21, 9 June 2011 (UTC)[reply]

Recommend we switch the default for the EMAIL option of talk page messages

Although I like the notification I have seen a lot of discussions about it not being wanted by some. It also seems to me that we might not need it for all the blocked accounts and such so I would like to offer a recommendation. I recommend we turn it off by default and let the users and editors choose wether they want it.

I decided to submit this because I heard this being discussed in public away from Wikipedia by someone who confessed to being blocked but could not turn the EMAIL notification off so they were getting "useless" messages every other day. --Kumioko (talk) 17:45, 9 June 2011 (UTC)[reply]

I agree these should have defaulted to off, but that ship has already sailed. Now, why is this person unable to turn the email notification off? It's at Special:Preferences. –xenotalk 17:47, 9 June 2011 (UTC)[reply]
Well the ship can always get new directions and change course but true on the second point. Would someone who has been banned or blocked (say for Vandalism or Sockpuppetry for example) be able to do that? --Kumioko (talk) 17:50, 9 June 2011 (UTC)[reply]
A blocked user can still change their account preferences. If they "scrambled" their password, they can recover their password if they are getting notification emails. --Tothwolf (talk) 17:55, 9 June 2011 (UTC)[reply]
Should be possibly even for blocked users, yes. And banned has no technical implications. - Jarry1250 [Weasel? Discuss.] 18:21, 9 June 2011 (UTC)[reply]
I agree with Xeno... I found the messages a little annoying and would have preferred an "opt-in" method, but now that it's already implemented and easy enough to opt-out of, it might be even more annoying to change it at this point. Those who wanted to opt-out (like me) have already changed our prefs, now we'd need the people who do like the notifications to change their prefs too. 28bytes (talk) 18:04, 9 June 2011 (UTC)[reply]
I agree with both the original position of opt-out, and the thought already outlined that the horse has already bolted. No point doing anything now. - Jarry1250 [Weasel? Discuss.] 18:21, 9 June 2011 (UTC)[reply]
Ok fair enough I just thought I would throw it out there. It makes sense what you all are saying. --Kumioko (talk) 19:07, 9 June 2011 (UTC)[reply]

Block log annotation

Following a recent Idea Lab discussion, there is now a means to annotate the "block a user" page (eg Special:Block/Rd232), by creating a page with a specific name in the relevant user's userspace. The idea is that this page would be fully protected and could be used by admins to provide clarifying links and notes for future reference. This could be particularly useful for warnings, edit restrictions, exonerations, and other things that might be relevant. Note: at present the code (at MediaWiki:Blockiptext) only displays the annotation page if it exists. This could be changed to provide a link to create the page, if the approach is thought desirable. PS If I'm correct in thinking admins can create pages protected by the MediaWiki:Titleblacklist, that could be used to fully protect this type of page, including against creation by non-admins. PPS Current downside would be not showing the annotation page on the user's block log (i.e. Special:Log), but that's less important, and possibly fixable with JavaScript, all else in software (cf Template:Bug). Rd232 talk 21:50, 9 June 2011 (UTC)[reply]

Perhaps a useful idea, but on Monobook it forces the sidebar at least one complete pagelength down (when I visit Special:Block/Rd232). Killiondude (talk) 21:59, 9 June 2011 (UTC)[reply]

User pages

Let me know if I'm missing something here as IM new herebut should all user pages be configured so no one can ed it it unless it is their user page? Would this work out? Heyitsme22 (talk) 22:06, 9 June 2011 (UTC)[reply]

  1. ^ [www.spoken-web.com www.spoken-web.com]. Retrieved 6 June 2011. {{cite web}}: Check |url= value (help); Missing or empty |title= (help)
  2. ^ http://www.spoken-web.com/index.cgi?p=about. Retrieved 6 June 2011. {{cite web}}: Missing or empty |title= (help)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=433458910"