Wikipedia:Village pump (proposals)/Archive 74

Source: Wikipedia, the free encyclopedia.

Welcome/how to edit template on talk pages

A discussion has been raised on the foundation-l mailing list about welcoming 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)

I hijacked {{
talk page}} template that has existed for years as well. It's not very friendly, though. --MZMcBride (talk
) 06:39, 7 June 2011 (UTC)
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)
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)
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)
(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)

{{

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)

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. --
talk
) 23:27, 7 June 2011 (UTC)
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)
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 T6469, for per-namespace sitenotices) would provide more control, but isn't currently installed. Rd232 talk 10:14, 9 June 2011 (UTC)

{{

Welcome! Ask questions, get answers." What more do we actually need on every single page? WhatamIdoing (talk
) 01:46, 10 June 2011 (UTC)

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)

Not really. Sometimes people leave bad categories on their userpage, or deleted files, redlinks, etc. In those cases someone might want to edit it for maintenance purposes. Someone could also create their userpage with vandalism/spam, and that would need to be tagged for deletion (or it could be reported somewhere, I guess). At any rate, if your userpage is being vandalized you can request that it be protected from editing for a while. Ajraddatz (Talk) 23:36, 9 June 2011 (UTC)
Some people also use them as sandboxes for writing articles, and they may invite others to help them, or need to move the page. It's not really
"yours". WhatamIdoing (talk
) 01:58, 10 June 2011 (UTC)

Proposal at
WikiProject Articles for Creation

Hello, there is currently a dicussion at

article wizard should be removed, relocated, or replaced. The discussion is located here. Thank you, Alpha Quadrant talk
23:08, 9 June 2011 (UTC)

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)

  • Strongly support. I've discussed the need of such a board with other users in the past, and I'm glad to see somebody's taken the initiative to propose it. :) It would be a much simpler matter for getting feedback on OTRS tickets. --Moonriddengirl (talk) 16:28, 27 May 2011 (UTC)
  • Strong Support - from me as well. We should also make sure it gets added to
    talk
    ) 16:51, 27 May 2011 (UTC)
  • Strong Support - This beats my current system of hopping onto the IRC, asking around in hopes that someone might have access, getting a person with OTRS access but who can't answer my question, being told to go to the OTRS channel, asking there, unsucessfully waiting for 30 minutes for the room to break its perpetual silence, and then finally PMing Keegan for the answer (Keegan only appears after I've tried all the other steps, I blame dark magic.)
    Wha?
    17:06, 27 May 2011 (UTC)
    • Comment Before this noticeboard goes up a decision needs to be made as to whether or not users can use that board to request OTRS access for themselves. That answer needs to be up in a divbox from the start. Personally, I am not in favor of allowing users to request OTRS access on this board, as it would clog an otherwise useful resource.
      Wha?
      17:17, 27 May 2011 (UTC)
      • A link can be added on the noticeboard to meta:OTRS/volunteering, where users should request access. MorganKevinJ(talk) 03:26, 28 May 2011 (UTC)
      • Given that OTRS is a "global" system and administered by the foundation, I don't think the enwiki community is in a position to determine where users can ask for access. Mr.Z-man 03:33, 28 May 2011 (UTC)
      • OTRS access most certainly should not be request-able here. As Z-man said, it's a global thing, and there is no need to take that to a local level. Ajraddatz (Talk) 03:50, 28 May 2011 (UTC)
        • Agreed. The volunteer OTRS admins have a system already in place, and decisions to change it should be made centrally. --Moonriddengirl (talk) 22:53, 28 May 2011 (UTC)
  • Support - a good idea, one of those that you think must already exist as it is a good idea. MilborneOne (talk) 17:21, 27 May 2011 (UTC)
  • Support. Much better organization this way. Ajraddatz (Talk) 20:52, 27 May 2011 (UTC)
  • Support, would be much more efficient than the current system, good idea.
    (talk)
    22:43, 27 May 2011 (UTC)
  • Support better. Also, started it in userspace here. ~~EBE123~~ talkContribs 13:19, 28 May 2011 (UTC)
  • Question: What does OTRS think of it? — Arthur Rubin (talk) 22:40, 28 May 2011 (UTC)
  • 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)
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)
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)
  • 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)
Note. The deletion discussion made clear that the main issue was the original draft wording, which was extremely wide and unrestricted compared to the actual uses and safeguards proponents had largely envisaged. I've reworded the board header to allow for these and it's now probably safe(ish). Eyeballs requested on the wording to ensure as far as possible, the wording has had careful scrutiny and that the most likely routes for serious issues have been accounted for in the directions. FT2 (Talk | email) 09:11, 10 June 2011 (UTC)

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)

The "Home" button works perfectly fine in this page. Cambalachero (talk) 15:25, 9 June 2011 (UTC)
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)
Easy to implement as a script so users who choose to have this feature can install it for themselves.
scripts
)
19:53, 9 June 2011 (UTC)


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)

It will if you've clicked in the table of contents to get where you are, but if you've scrolled down you'll have to scroll back up again. Peter jackson (talk) 10:13, 10 June 2011 (UTC)
  • Oppose There is a "Home" button on your keyboard for a reason. Yoenit (talk) 11:02, 10 June 2011 (UTC)
  • Comment Using the "Home" and "End" buttons on the keyboard works fine. However, then we should remove the "Skip to bottom" button for consistencies sake. Having one button but not the other one appears to be an incomplete implementation, that should either be completed or removed alltogether. Toshio Yamaguchi (talk) 11:13, 10 June 2011 (UTC)
    • There is no "skip to bottom" button. Some pages (like this one) implement it with a [[#footer|Skip to bottom]] link. This does not really have anything to do with the MediaWiki interface.
      talk
      ) 11:27, 10 June 2011 (UTC)
      • And the reason it's on village pump pages is because people typically want to see what the latest discussions are.
        scripts
        )
        17:27, 10 June 2011 (UTC)

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. --

talk
) 17:45, 9 June 2011 (UTC)

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)
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? --
talk
) 17:50, 9 June 2011 (UTC)
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)
Should be possibly even for blocked users, yes. And banned has no technical implications. - Jarry1250 [Weasel? Discuss.] 18:21, 9 June 2011 (UTC)
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)
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)
Ok fair enough I just thought I would throw it out there. It makes sense what you all are saying. --
talk
) 19:07, 9 June 2011 (UTC)

On a related point, some wikis have such email notification for watchlists, but WP doesn't seem to have that option. Peter jackson (talk) 10:15, 10 June 2011 (UTC)

Probably because that would be sending thousands upon thousands of mails a day :) I'd be getting about 500 emails a day at the moment :) --Errant (chat!) 13:10, 10 June 2011 (UTC)

Signatures

I added some text to

WP:SIGNATURE about discouraging confusing use of nicknames, only to discover that this is the default behaviour of the signature field in the preferences. This is controlled by MediaWiki:Signature, which does exactly the Nickname (if nickname is provided) which I thought was confusing and is/should be discouraged. This could be changed in MediaWiki:Signature, eg to become name/Nickname, and perhaps MediaWiki:Tog-fancysig tweaked to match. Rd232 talk
16:20, 11 June 2011 (UTC)

I...almost understand what you're saying here? Did you type too fast and miss about three sentences perhaps? Not being a bitch, you're usually one of the more clear Wikipedians around. → ROUX  16:28, 11 June 2011 (UTC)
I think this is about the "If unchecked, the contents of the box above will be treated as your nickname and link automatically to your user page" option, which would make it possible to simply enter another name to use with a high level of simplicity. Grandiose (me, talk, contribs) 16:30, 11 June 2011 (UTC)
I'm also slightly confused, but maybe because I've always had that "Treat the above as wiki markup" box checked. Frankly, we don't need that nickname feature—it's confusing (especially to a new user) and you can use wikicode to make a sig with a nickname, anyway. Although I definitely agree with the addition to
WP:SIGNATURE about nicknames being confusing if there's no mention of the actual username in the sig. /ƒETCHCOMMS/
18:39, 11 June 2011 (UTC)

OK, I guess I was pretty hasty, let's try and clarify:

  1. I made an addition to to clarify that poor use of nicknames in signatures (without including the actual username somehow) can easily be confusing. I think this is widely understood, but I have seen it done occasionally.
  2. However it turns out that this confusing practice is strongly encouraged by the user preferences setup. At the moment, if you enter a nickname without ticking the "raw signature" box, the result is that confusing practice.
  3. This can be fixed by editing MediaWiki:Signature. The current [[User:Example|Nickname]] would become [[User:Example|Example]]/Nickname in the event the user enters a nickname in preferences without checking the "raw signature" box.

Better? Rd232 talk 19:24, 11 June 2011 (UTC)

Hence we get periodic moments of hilarity like this (from my alternate account) and this (from an admin, no less). It took me a few tries to figure it out with this account, so if you look at my contribs around mid-July you can see the same thing happened a few times before I checked the box. Ticking the box as the default would probably make things easier. The Blade of the Northern Lights (話して下さい) 19:33, 11 June 2011 (UTC)

Essay elevation to Guideline proposal

You are invited to join the discussion at

pls
}})

Conflict of Interest Essay idea

You are invited to join the discussion at

pls
}})

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.

Lengthy discussion moved to Wikipedia:Village pump (proposals)/suspend sysop rights of inactive admins.

Brainstorm over increasing privileged account security

Seeing as a lot of this is revolving around a concern for admin account security, I'd like to briefly mention a few different ways/possibilities that could possibly be done while maintaining anonymity, privacy, and the like—at least within reason. Keep in mind that I'm not talking about bulletproof security, but simply a second factor of authentication that could be used to practically verify identity or secure logins as general (and possibly optional) practice.

  • Public key infrastructure — It might be a good idea to ask users with enhanced permission sets to use a free, basic PKI package (e.g.,
    GNUPG
    ) to generate and publish a strong (>=4096 bit) public key set to expire within a practical period of time so as to help negate long-term key attacks. Only problem is that keys can be lost in hard drive crashes or just by accident. Within reason, though, if someone is active and then loses their private key, one could probably judge by their behavior whether or not they're who they're claiming to be.
  • Token-based auth — Several technologies exist that would enable this.
    eTokens
    are fairly cheap, too, but do still require buying something.
  • Account security questions — Everyone's had to deal with these, but we could make something reasonable that would allow you to create your own questions (very important) and supply your own answers.

Using these methods, you wouldn't necessarily have to authenticate with them regularly (which might be a total pain), but it might be an idea to do something similar to what the toolserver does when it comes to account renewal: after a period of time (say in this case 1 year or after a stretch of inactivity), ask people with extended permissions to visit a site and "renew" their permissions using one of several methods of advanced identification that would be on file. That way, if someone loses their private key, they can answer their security questions instead; if they forget their account security questions, they could use their token or their private key instead; etc....

All of these would also help get around cases where someone forgets their password, someone maliciously changes it on them, or whatever other scenarios might arise.

Anyway, t'was just brainstormin'.

Cheers =) --slakrtalk / 22:22, 9 June 2011 (UTC)

That's really more Wikipedia:Village pump (proposals)/Account security territory. Perhaps you could move your thoughts there, as this thread is already quite long enough. Rd232 talk 00:05, 10 June 2011 (UTC)
Tokens work well, untill this happens (sorry, it was too tempting). --Chris 13:51, 13 June 2011 (UTC)

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

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 [1]). 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)

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. --
talk
) 20:25, 6 June 2011 (UTC)
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)
Usernames can be
CAT:REVDEL. Rd232 talk
21:29, 6 June 2011 (UTC)
The issue is the presence of the offending username on the user's userpage. --Anthem 21:30, 6 June 2011 (UTC)
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)
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)
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)
FYI Usernames can now be
dferg
21:23, 10 June 2011 (UTC)

Force IPs to use edit summaries

Whenever I look at a page's revision history, most IPs consistently fail to use edit summaries, this would help RCPs to determine how appropriate an edit is. For example, if the edit summary contains "BLARGHFSUDFSHKGS" that's indicative of the edit, statistically this is the case most of the time, other times the editor using such an edit summary is one who can't be arsed to insert a proper edit summary. Thoughts? —

Talk • Contribs
)9:38pm • 11:38, 12 June 2011 (UTC)

This is Perennial proposal territory, though I suppose a short-term test for IPs might be worth a try. I wonder though if the new Default Edit Summaries gadget couldn't be made available by default (via Commons.js) so that IPs can use it too. Rd232 talk 11:45, 12 June 2011 (UTC)
It would be great if a registered user could tick off IP edits as constructive in the history list so other users do not waste the time double-checking if they do not want to. --Squidonius (talk) 21:39, 12 June 2011 (UTC)
I thought we had a discussion recently over edit summaries, did that amount to something? I know some people supported a dropdown box of common edit summaries, but will that be implemented? /ƒETCHCOMMS/ 00:58, 13 June 2011 (UTC)
I think it would be a good idea. I've noticed a change in the edit summaries - there's now an automatic dropdown but I can't figure out whether they are standard suggestions or somehow stored .js versions of my own es. --Kudpung กุดผึ้ง (talk) 04:48, 13 June 2011 (UTC)
Well I certainly think ips should be strongly encouraged to put in summaries.
I like the other idea above too. I guess it would take a lot more work but the general idea of people signing that they like a particular edit sounds like it could lead to something useful. Not just cutting down checking but other things. Like the perennial problem of which edit to lock when there is dispute or finding a version suitable for publication on a schools CD.
Dmcq (talk
) 06:32, 13 June 2011 (UTC)
This idea is in Perennial proposal territory as stated above, and I could have sworn I participated in a discussion on this before. I believe requiring an edit summary may discourage anonymous users from trying out editing, and I'm not sure how helpful a edit summary would be anyways if they are forced just to type something in.AerobicFox (talk) 06:55, 13 June 2011 (UTC)


We did have a recent discussion on this, and it can be found here:

Extended content

I don't expect to get much support for this one. But I want to propose it anyway. I often see new accounts make big bold edits without leaving edit summaries, and I assume good faith of course, but I still don't know why they boldly removed that certain paragraph or sentence, or changed that date or statistic, or whatever. I don't know how many times I've had to leave an extended message on new users' talk pages explaining why they need to use edit summaries. Better to get them in the habit early, then once they get autoconfirmed they can have the option to turn it off. -- œ 09:29, 11 March 2011 (UTC)

I like it, can we set a trial to test this out? I think use of edit summaries would reduce the number of good faith edits reverted as vandalism. Yoenit (talk) 09:40, 11 March 2011 (UTC)
Agreed. I've often reverted silent deletions due to lack of an edit summary (they're indistinguishable from vandalism or POV-zealotry). Occasionally I've inferred "lack of references" as the reason and not reverted, but requiring an edit summary would significantly help in distinguishing nonconstructive deletions from good-faith ones. --Cybercobra (talk) 09:59, 11 March 2011 (UTC)
WP:PEREN#Automatically prompt for missing edit summary. (But I'm not sure I agree with the “[r]easons for previous rejection”: after all even most e-mail clients warn you if you're trying to sent a message with an empty subject line.) --A. di M.(talk
) 11:35, 11 March 2011 (UTC)
Do we have evidence that this is even a true perennial proposal? It seems to have been added back in 2006[3], but has it ever been the subject of discussions? Yoenit (talk) 12:07, 11 March 2011 (UTC)
What about turning on the prompt gadget by default? Kayau Voting IS evil 12:44, 11 March 2011 (UTC)
Right. The gadget is already there, but only registered users can turn it on in their preferences setting. If turned on, an attempted save of a summary-less edit does initially not succeed but instead displays a conspicuous warning banner: "Reminder: You have not provided an edit summary. If you click Save again, your edit will be saved without one." (See it atMediaWiki:Missingsummary.) Unregistered users and most new users don't get to see this, as it is turned off by default. Although enabling this by default is not exactly forcing unconfirmed users to use edit summaries, it most definitely will help encourage them to do so.  --Lambiam 14:02, 11 March 2011 (UTC)
Could we change the text to something like "Reminder: You have not provided an edit summary. Edit summaries help other users understand the intention of your edits. Please enter one before click Save again, or your edit will be saved without one."? I am afraid the default text is not really helpfull to a newbie and is more seen as annoying. Yoenit (talk) 14:27, 11 March 2011 (UTC)
I've put this proposal up at Wikipedia:MediaWiki messages#Proposed change for MediaWiki:Missingsummary. Please discuss it there.  --Lambiam 23:22, 11 March 2011 (UTC)
I'm definitely all for trying to get people to put in edit summaries and I haven't the foggiest why ips aren't prompted to do so. It should be like that by default.
Dmcq (talk
) 16:13, 11 March 2011 (UTC)

I really dislike this proposal. What are the new users supposed to do say they are for instance, just trying to get a piece of wiki code to work, or making minor edits. Forcing them to write a summary of everything they do seems like a hassle for new users.AerobicFox (talk) 17:27, 11 March 2011 (UTC)

I would weakly support a dismissible reminder for anons and new users (weakly because of AerobicFox's concerns), but I would oppose forcing users to provide one. Mr.Z-man17:38, 11 March 2011 (UTC)

I've had other users ask me how to leave an edit summary before, so I do suspect that many just can't see the bar right above the "save page" button. How about we just move the edit summary above the edit box, make it some obnoxious color, and render "Edit summary (Briefly describe the changes you have made)" as "Edit summary (Briefly describe the changes you have made)" and/or (along Mr. Z-man's suggestion) if they try to save a page without putting an edit summary, a prompt comes up saying "are you sure you don't want other editors to understand what you're doing?"Ian.thomson (talk) 17:50, 11 March 2011 (UTC)

If you use an obnoxious colour then the message could use the same colour so they can easily spot where the place to insert a summary.
Dmcq (talk
) 13:13, 15 March 2011 (UTC)

I would oppose compulsary edit summaries. The last thing we need is another hoop for new users to jump through before they can edit. Support a reminder, which would leave it firmly in their hands while still encouraging them to use the tool and educating them about its use. Interesting to note that of the eleven of us involved in this discussion, only four used edit summaries on the first edit, and none on all of the first ten ([4][5] [6] [7] [8] [9] [10] [11] [12] [13] [14]). Would it be right for us to force new users to do something that we failed to?Alzarian16 (talk) 13:27, 15 March 2011 (UTC)

Support the default reminder in article space for non auto-confirmed users. It's no great imposition and should reduce misunderstandings and possible summary reverts due to misjudging new editor's intentions, particularly if edit is not well formulated. It should also serve to highlight intentional disruption. RashersTierney (talk) 13:45, 15 March 2011 (UTC)

Oppose. As Alzarian helpfully pointed out this is not something we should hassle newbies about. I would be more tolerant of something along the lines of "congratulations on your 100th edit, may we now introduce you to the idea of the edit summary", but as for newbies I'm much more concerned about getting them to tell us their source. DE wiki has a referencing prompt and I would like that to be trialled here. ϢereSpielChequers 14:00, 15 March 2011 (UTC)

The last thing we need are more barriers, especially those requiring a degree of technical aptitude, to new editors contributing. Would not object to a dismissible prompt after 20 or so edits though along the lines of the comments by MuZemike and WSC above. Skomorokh 18:33, 15 March 2011 (UTC)

Much as I appreciate that this proposal was made with good intentions, I for one would quite strongly oppose it. Many newcomers to Wikipedia probably are just getting the hang of editing it, and are not even at the stage of thinking about edit summaries. My guess is that, every day, there are probably numerous edits which lack an edit summary which are perfectly good edits. This proposal does have shades of the perennial proposal (which seems unlikely to work - ever) of only allowing logged in registered users to edit Wikipedia. People who are new to Wikipedia are probably learning how to edit it before doing edit summaries - after all, one must crawl before one can walk. ACEOREVIVED (talk) 00:44, 23 March 2011 (UTC)

Well it seems to me the point is to help OTHERS recognize those good faith edits. The question of if newbies will be turned off by the summeries more than they are currently by their good faith edits being reverted (I've even seen plenty of seemingly good faith edits directly called vandalism...at least with an edit summery it's easy to tell if the reverter is in the wrong) ♫ Melodia Chaconne ♫ (talk) 02:15, 23 March 2011 (UTC)

Oppose mandatory edit summaries, support default reminders. ACEOREVIVED said it best - "one must crawl before one can walk". Let's not give newbies more hoops to jump through by forcing them to write an edit summary before their edits can go through, but rather let's encourage them to provide summaries with friendly reminders and a brief explanation of the benefits of providing summaries. Aside from discouraging participation from new users, another potential drawback to requiring edit summaries is that some - who don't care to be bothered with providing a summary but want to see their edit(s) materialize - may be tempted to write nonsensical gibberish or some kind of wisecrack in the summary space just to satisfy the "write something" requirement. And, of course, such summaries would unhelpful and counterproductive, as they would likely seen by patrollers as a sign of vandalism when this may not be the case at all. No, better to focus on ways to more effectively encourage edit summaries. The ideas proposed above by Yoenit and Ian.thomson are very good ones that should be given strong consideration.--JayJasper (talk) 03:51, 23 March 2011 (UTC)

JayJasper, thank you for your comment. Your comment about another difficulty here being that if we force people to write an edit summary, they might start writing nonsense is well taken - I had not thought about that, but it is an excellent point!ACEOREVIVED (talk) 19:32, 23 March 2011 (UTC)

I think that a prompt for, but not enforced edit summary, is a brilliant idea. I have a terrible history of not giving edit summaries, and have only recently discovered the pref where I could ask for a prompt! Since when, I've begun to get into the habit without having to be prompted. Pesky (talk) 05:07, 29 March 2011 (UTC)

This is actually at Wikipedia Village Pump Proposals Archive 70 at the time of typing. I think you can see why this should be considered a perennial proposal. As you can see, the discussion was in March at the time of typing. ACEOREVIVED (talk) 21:20, 14 June 2011 (UTC)

Why not wikilink to the archived proposal section instead of pasting in 12K of text? -- John of Reading (talk) 21:36, 14 June 2011 (UTC)

I oppose this idea, because if we want to identify vandalism, are we going to put a dropdown selection for vandalism to make changes patrolling easier? I don't think so, and the way it stands at the moment a blank edit summary is a good clue to check out the work. Though the idea to encourage more registered users to use or force use the edit summary has merit. It is already difficult enough for new people to edit here without making them think of an explanation of what they are doing. Graeme Bartlett (talk) 21:44, 14 June 2011 (UTC)

Random articles

Just for the hell of it, today I clicked on "random article" to see what would come up. I was quite disappointed to get not an article, but a disambiguation page. Is there some way of limiting random articles to just that - articles - by somehow disabling it from fetching any page that has a {{dab}} template on it? Grutness...wha? 11:44, 14 June 2011 (UTC)

This is possible using a script; see Wikipedia:Enhanced Random Article. -- John of Reading (talk) 12:08, 14 June 2011 (UTC)
Ah - thanks! Grutness...wha? 02:00, 15 June 2011 (UTC)

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)

Please see Wikipedia:Gadget/proposals MorganKevinJ(talk) 21:01, 1 June 2011 (UTC)
One of the Wikimedia Foundation's Google Summer of Code projects is about this, see [15], and also the links there. Regards, HaeB (talk) 02:01, 3 June 2011 (UTC)
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)
What exactly do you mean by "Specific category"? Toshio Yamaguchi (talk) 00:20, 9 June 2011 (UTC)
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)
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)
What I was thinking of doing was basically this:
  • On page save all the links from the article are retrieved from the parser
    • if have already been archived nothing is done


    • if they have not yet been archived they are added to a queue for a web bot to come by and archive them if they are not blacklisted
  • Sometime later a web bot comes by and attempts to retrieve the web page
    • if the archive is successful it is saved and displayed on request
    • if the web site is down the page is readded to the queue to be checked later, or if the page is still down after a certain number of attempts the the link is assumed to be dead and we stop trying
    • if the web site is up but the link can't be archived due to robots.txt, nocache, or noarchive tags automatically blacklist the site for a certain amount of time
    • if the web site is up but the page comes back as a 404 or a redirect assume it as a failed attempt, note it, and blacklist that link
  • Add a hook to the parser to display a link to access the cached version of the page for every external link on the wiki, or possibly configurable options, this will be done on parse so the link may link to stuff that has not yet been archived or where the archive was unsuccessful
That's basically it in a nutshell. The actual framework of getting done is really the easy part. The hard part is sanitizing everything to make sure this can be done without any security holes. Due to this it is unlikely that I will be storing java script or flash objects as they are difficult to sanitize. Images are mostly secure but you can have some security vulnerabilities there as well. As far as changing stuff and linking to stuff that may not exist I realize that some people in the community had a problem with this but this is far less intensive than trying to do queries to figure out what has/hasn't been archived yet. Not to mention that since pages are cached for a significant amount of time (as far as I'm aware it's a week here) it could be a long time before we check back to see if the archive actually exists. It's because of this that I think just linking to stuff that may not exist is the best option. --Kevin Brown (talk) 00:39, 10 June 2011 (UTC)
That sounds good. I think perhaps we should simply wait if some other people comment on this and if there is support for this. Nearly everything is better than the current situation: having no tool for archiving citations, so I generally support anything that brings us nearer to a working solution. Toshio Yamaguchi (talk) 01:00, 10 June 2011 (UTC)
This is something I will be working on regardless of if there is support to implement it on the English Wikipedia. I would however like to see this deployed here, so I would like to seek the communities input to see if there is are any features (within reason) they want out of the box in the software. I can't guarantee I will be able to fulfill every feature request, but if there is something that people really want I will try to get it implemented. Obviously getting working secure archival is my number one priority and everything else takes a back seat to that. --Kevin Brown (talk) 01:49, 10 June 2011 (UTC)
You might also want to take a look at a recent bot request I filed at
WP:BOTREQ#AntiLinkrotBot, where I listed some of the functionality I would expect from a WebCite bot. Toshio Yamaguchi (talk
) 10:00, 10 June 2011 (UTC)
At the current time this will probably be for all external links and not just what is in references. I would like to add something later to limit this to references but there are three problems with it:
  • it's not as easy to get as it is all external links, for instance the external links table contains no data to tell me if the link is a reference or not
  • The Cite extension is not part of media wiki core and thus requiring it would create an unnecessary dependency.
  • Some editors use parenthetical references in MLA or APA style by hand and not <ref> tags, thus those links would not get archived if you were only archiving stuff in ref tags.
As far as submitting stuff automatically to web cite that really wouldn't be that hard to do, but given webcite's current infrastructure I'm not sure that's practical, due to the fact that they require an email address and send emails to it for every archival request (this means tens of thousands of mostly useless emails). --Kevin Brown (talk) 11:58, 10 June 2011 (UTC)
Toward the end of last year I archived a big chunk of links (parsed out of a db dump) to WebCite, I never got beyond doing that, but the way I handled the emails was just to feed it it a googlemail address. And set up a filter to simply delete the "it worked" emails. --Errant (chat!) 13:05, 10 June 2011 (UTC)
Something like that could work but sounds like a "ur doin it wrong" kind of way to do things. It works, yes, but it's horribly inefficient, and on a large scale it makes no sense and may potentially lead to scalability problems. Really web cite needs to do stuff on their end to use API keys rather than an email address. --Kevin Brown (talk) 02:35, 11 June 2011 (UTC)
Please note that in some countries long time archival will make it necessary to get a permission from the sources in question if this shall be legal in those countries. There are (probably?) possible to make some kind of fall-back strategies that make this legal if the archived pages isn't available for general use somehow, that is a search engine will not index the page and you can't just construct a get-request to access the page. If the request emerge from the user, then I think the user will be responsible. If the request emerge from the software after an edit the I think WMF is responsible. In some jurisdictions the first one is the troublesome, in other the last one. Jeblad (talk) 12:30, 10 June 2011 (UTC)
As far as I'm aware the only jursidiction we have to worry about is the United States, since that is where the servers are hosted. That being said I am in the process of seeking a formal opinion from the Foundation's legal counsel, the copyright problems shouldn't be too bad as long as DMCA takedown requests are obeyed due to the safe harbor provision in the DMCA. --Kevin Brown (talk) 19:59, 10 June 2011 (UTC)
Its the uploader which publish and will be at risk, and if wmf act on behalf on some other party then they are at risk. Its similar to PirateBay and linking to copyrighted material on that site. In some jurisdictions that would be legal, in other its not. Jeblad (talk) 18:00, 14 June 2011 (UTC)
Given that Google and the Internet Archive are able to do caching I do think it's possible. However I'm not totally sure of the specifics of the legal stuff. You may be right, but I can tell you that the Foundation's lawyer is researching it and all legal issues will be looked at before full deployment. --Kevin Brown (talk) 22:34, 15 June 2011 (UTC)

I'd like to voice my support for moving this idea forward as dead links in citations are a major issue for Wikipedia. Any progress in this area would be greatly welcome. I should also mention that Gunther Eysenbach of WebCitation.org is wanting to work with Wikipedia to help get citations archived. He can whitelist Wikipedians so they can perform high-speed archiving. He may be willing to modify the email requirement for certain operations associated with Wikipedia. I'll ask for his input. - Hydroxonium (TCV) 00:38, 12 June 2011 (UTC)

See my last information [16]: We started yesterday caching the content of the English Wikipedia external links, so that, while waiting for the decision to be taken, all information sourcing work could be backed up.
Therefore, since yesterday, we're archiving all new links introduced in Wikipedia. For those introduced before yesterday, we'll try to archive them as well, and for those that return an error 404, we'll try to get them from webarchive.org. Cheers, Pmartin (talk) 01:43, 15 June 2011 (UTC)

Jumping To Histories

We should be able to type into the search box and jump to the history's page.

For example, we can type wp talk:table if we wanted to to go the table's talk page, but we can't do this for the talk page's history or the "article"'s history, so I am proposing this to be added.Curb Chain (talk) 07:05, 13 June 2011 (UTC)

Oppose. Readers should care about history pages, but they don't. Adding what will be UI clutter for 99% of our millions of visitors to save a click for the other 1% is unlikely to be worth it (and that's assuming this is realistically feasible from a technical POV.) Might be more useful if restricted to logged-in users only? Perhaps a gadget/user script would be a good idea. - Jarry1250 [Weasel? Discuss.] 11:26, 13 June 2011 (UTC)
Comment - the major piece that is missing in your proposal is "Why". You say we should be able to do it, but why should we be able to do it? I do not see any benefit to be able to go directly to the history of a page from the search box. GB fan (talk) 11:38, 13 June 2011 (UTC)
  • Strong support - This is a great idea for sourcing, it would make linking to an article's history intuitive and make it easier for sites reusing our content to comply with the license. The only simple way I can think of to do this is with a new namespace, and the problem there is that we'd end up with "Template talk history:", which is a mouth keyboard-full. We could make a pseudo-namespace only for articles, but that would mean that it wouldn't show up in the URL so it might be confusing, and its usefulness would be minimized. So, while I think this is an awesome idea, I can't think of a realistic way to implement it. If someone thinks of a way, great. ▫ JohnnyMrNinja 22:17, 14 June 2011 (UTC)
Comment: if technically possible, seems most sense as a script, or potentially a gadget. Hard to see the use of rolling it out to readers in the main, perhaps after use as a script or gadget this would be easier to assess. Grandiose (me, talk, contribs) 20:46, 15 June 2011 (UTC)

Request to re-activate WikiProject General Audience

I noticed that Wikipedia:Make technical articles understandable has been revised thoroughly (I was very impressed!) Many articles on mathematics are difficult for even well-educated readers to understand. There are a number of reasons why one might want to provide more background information in the leads of such articles, as well as add analogies (such as the airplane analogy in “limit of a function”):

  • A knowledge of mathematics is essential for one to understand science.
  • Many scientific topics are relevant to public policy debates, and full participation of the general public in public policy debates is desirable.
  • When members of the general public “google” something, Wikipedia is often the first “hit.”
  • The benefits of full public participation in public policy debates may increase as the knowledge level of the general public increases.
  • Many people feel aversion or fear towards mathematics, and the difficulty level of Wikipedia articles tends to reinforce this.
  • A good level of scientific knowledge is useful in solving many real-world problems.
  • Wikipedia seeks to be a high-quality general encyclopædia.

The purpose of relisting this proposal is not, however, to debate policy, but rather, to request users who are knowledgeable in science and math to volunteer to impart their knowledge to those of us who are less knowledgeable about their subjects of expertise (here are some specific examples of articles to look at).

As stated in the guideline, “the sun is of interest to more than just astronomers and diseases to more than just physicians.” I realize, of course, that many subjects by their very nature require a certain pre-existing level of knowledge, and I certainly do not think that existing content should be “dumbed-down,” but such principles as “Write one level down” are good rules of thumb.

69.251.180.224 (talk) 13:13, 13 June 2011 (UTC)


Relisted from archives[11][31][37][28]; please add new comments below this notice.
Thanks, 69.251.180.224 (talk) 13:13, 13 June 2011 (UTC)

Support, but we'd need people who can actually understand the articles... which at times can be difficult. Category:Wikipedia articles that are too technical has a backlog from 2007, which is not a good sign. Crisco 1492 (talk) 02:21, 14 June 2011 (UTC)
Comment. I think the idea of making Wikipedia articles more approachable to a general audience is widely agreed to be a good idea, and requires no justification, but in order to do it we need a more systematic way of going about it. A Wikiproject like this should list articles to target and endeavour to recruit people in each area. Dcoetzee 20:25, 14 June 2011 (UTC)
See
WP:REVIVE. You don't need permission to revive a dormant WikiProject. WhatamIdoing (talk
) 16:41, 15 June 2011 (UTC)

Moving pages and categories

I think it would be useful to have page moves automatically add the article page redirects to Category:Redirects from moves; the category is quite underpopulated since it has to be added manually at the moment. Would the software support that? Would the community? Crisco 1492 (talk) 09:36, 10 June 2011 (UTC)

Proposal change That the software automatically add Template:R from move when moving pages, except if the redirect is not created when moving. Crisco 1492 (talk) 23:14, 12 June 2011 (UTC)
The software wouldn't, though it could be done using some JS or an extension. I personally don't see much of a need, since all broken/double redirects appear on maintenance pages anyways. Besides, do you really want a category with thousands upon thousands of items in it? Ajraddatz (Talk) 13:56, 10 June 2011 (UTC)
The software could pretty easily do it as part of creating a redirect when moving a page. That, I think, is what Crisco was getting at, and it would be the most efficient method. Rd232 talk 14:46, 10 June 2011 (UTC)
Yes, it was. Thank you. Crisco 1492 (talk) 16:04, 10 June 2011 (UTC)
What is the point of the category? Or of the {{R from move}} template, which merely puts a page in that category, along with a brief message? The benefit of this escapes me. Rd232 talk 14:44, 10 June 2011 (UTC)4
I was going to say the same: I'd have no problem with a bot doing it, I just have no idea why one would want to. Grandiose (me, talk, contribs) 14:45, 10 June 2011 (UTC)
To quote:

"This is a tracking category. It builds and maintains a list of pages primarily for the sake of the list itself. Pages are added to tracking categories through templates."

and

"Administration categories, intended for use by editors or by automated tools, based on features of the current state of articles, or used to categorize non-article pages."

My interpretation is that it is just meant to exist and grow bigger, to index the pages and perhaps serve as an list of pages that have been moved. However, it may be also be useful for people who work at
Redirects for discussion and are looking for useless redirects. Crisco 1492 (talk
) 16:13, 10 June 2011 (UTC)
Yes, but, tracking categories should actually be useful as well. What purpose would a tracking category for pages that have been moved serve? Page moves and redirect pages are tracked by the software regardless, so how is a category not redundant?
— 
V = IR (Talk • Contribs) 16:18, 10 June 2011 (UTC)
That would be a question for
CFD, I think. I noted one, namely that people who regularly look for useless redirects could easily find them if all moves added the redirects to a category. For example, we have Can dogs see ghosts?, which I saw while looking through that category. Crisco 1492 (talk
) 16:34, 10 June 2011 (UTC)
How is this a question for CFD? What possible use is a category to them? You can find all redirects already, without any category.
— 
V = IR (Talk • Contribs) 16:50, 10 June 2011 (UTC)
This discussion is not; the usefulness of the category might be. Crisco 1492 (talk) 16:59, 10 June 2011 (UTC)
I aupport this for one reason; having the cat without this tempts people to add the cat to such redirects, which means one has to go through
WP:RM
to reverse the move. Often one shoud; but not always.
One alternative is to delete the cat. But that decision should also be taken at 04:57, 11 June 2011 (UTC)
If no-one can come up with an actual reason, in the next couple of days, why this category serves any purpose, then someone should CFD it. You've just given a good reason why it shouldn't exist. Rd232 talk 05:42, 11 June 2011 (UTC)
To quote Template:R from move: "Category:Redirects from moves, ... is used to track all moves that might result in the breakage of links, both internal and external, if a redirect is not installed properly." Seems somewhat reasonable. Crisco 1492 (talk) 23:17, 12 June 2011 (UTC)

Incidentally, the {{R from move}} template does serve a purpose, to help protect redirects from deletion which people may not see a use for (see template talk page). However it would serve that purpose better if the text in it actually appeared on the redirect page; for some reason, for me at least, it doesn't, and I can't see why. Rd232 talk 15:16, 12 June 2011 (UTC)

I think that's a technical limitation of the software. I've been cleaning up the classification backlog at WikiProject Indonesia and quite a few problems have been on pages that have been redirected without removing the WikiProject box; it doesn't display the box, but everything is still read by the software. Crisco 1492 (talk) 23:22, 12 June 2011 (UTC)
We might benefit from a WikiProject template bot that corrects the class to |class=Redirect on all such pages. It shouldn't be too hard to do; MZMcBride kindly generated a list like that for me a while ago. Bad class assessments could be a significant problem for the
WP:1.0 team. WhatamIdoing (talk
) 23:44, 12 June 2011 (UTC)
Agreed. Where would we make such a proposal? Here? In a new section, of course Crisco 1492 (talk) 23:58, 12 June 2011 (UTC)
WP:BOTREQ is the usual place to find bot owners who might write a script for you. I'd start with WikiProject Council; you'll be able to get a full list of requirements. WhatamIdoing (talk
) 16:39, 15 June 2011 (UTC)
Request made at
WP:COUNCIL but I will not be very active for the next few weeks so I wouldn't be able to participate. Crisco 1492 (talk
) 09:06, 16 June 2011 (UTC)
Actually, automatically adding that template when moving would be better. According to the documentation, it populates Category:Redirects from moves and would let editors know the purpose of the redirect. I think I will change my proposal. Crisco 1492 (talk) 23:14, 12 June 2011 (UTC)

Advice on blacklisted external links

Recently, I had to change an edit before it could be saved. I was told that my external link has been blacklisted. This was not a vulgar site - just one on possible links between Asperger syndrome and eating disorders. Do you think we should be given more advice on what websites have ben blacklisted, especially if they seem innocuous?15:59, 15 June 2011 (UTC)

Do you mean advice which pages are blacklisted or advice what to do if you if you want add a link to a blacklisted site? The first is bad idea per
wp:DENY and also not practical as the lists are massive (see for yourself m:Spam blacklist and MediaWiki:Spam-blacklist). If you meant the second, the requirements for delisting are very strict, so if you don't know where to find it already you are not gonna stand a chance at requesting a delisting either. Yoenit (talk
)

All I really meant there is perhaps we could have a few words at the top of articles on the type of external links which had been blacklisted. This was really stimulated when what, to me, seemed a very innocuous and quite academic external link seemed to get the blacklist tag. However, I appreciate your point that there is probably a very long list of blacklisted external links, so your point (if I understood your comment correctly) that listing blacklisted external links would not be practical is well taken. ACEOREVIVED (talk) 19:36, 15 June 2011 (UTC)

If you want more information on why a specific link is blacklisted, look it up on the MediaWiki talk:Spam-blacklist/log (local blacklist) or m:Spam blacklist/Log (global blacklist). 99% of the time there will have been problems with dedicated spammers, but it might be a special case or a false positive. Yoenit (talk) 07:58, 16 June 2011 (UTC)

Discussion at WP:MEASURE#A template for physical constants?

You are invited to join the discussion at

pls
}})

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)

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)
Note Anthem of joy has been indef blocked as a sockpuppet of Claritas [17]. --Tothwolf (talk) 04:21, 15 June 2011 (UTC)
I wouldn't exactly call a user of 4 days / 10 edits "established"... --KFP (contact | edits) 22:00, 8 June 2011 (UTC)
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)
"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)
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)
  • 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)
  • I would prefer the term "editor" instead of autoconfirmed. Many other wikis have editor as what autoconfirmed on enwiki is.
    Majestic (sur nous mars
    ) 22:16, 8 June 2011 (UTC)

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)

  • A solution looking for its problem. No need for change - a well 'established' Wikipedia term. Kudpung กุดผึ้ง (talk) 17:16, 9 June 2011 (UTC)
    • There's a difference between "well-established" [but only on the inside of Wikipedia] and comprehensible, especially to newcomers off the street who come across something that says a process is confined to Autoconfirmed Users. —— Shakescene (talk) 21:27, 9 June 2011 (UTC)
It reads intuitively to me, considering what it describes—a techie name for a techie threshold. The alternatives suggested do nothing to make the meaning comprehensible because the only way to do that is if the name states the threshold itself since there's not term for what this is in English, barring a description, and were not going to rename it "four days, ten edit barrier." Accordingly, no matter what the name, in order to learn what it is an unfamiliar user will still have to be told or visit the description page. If we change it, it will also conflict with the identical term used on many other projects; it is the same name used at Commons, at Wiktionary, at Wikinews, etc.--Fuhghettaboutit (talk) 22:33, 9 June 2011 (UTC)
Respectfully, I disagree that it's a "techie threshold" and therefore doesn't require explaining to non-techies. Autoconfirmed status represents a set of wiki privileges (uploading files, renaming pages, editing semiprotected pages) that new users regularly want. New users regularly come to #wikipedia-en-help asking why they can't do these things, and the answer -- "your account isn't autoconfirmed yet" -- doesn't really help them understand. If we were coming up with this feature for the first time right now, I would recommend "editor" for new accounts and "full editor" for autoconfirmed users.
talk
) 22:54, 9 June 2011 (UTC)
Sounds like a good idea. -- Eraserhead1 <talk> 23:37, 9 June 2011 (UTC)
@Tim Pierce But I don't see any clarity provided by the rename that you seem to think is provided by it. Let's make it concrete. New User: "I want to move X but I don't see any move button!" Helper: "well, you're an editor but not a full editor." New User: "what does being a 'full editor,' as opposed to an 'editor,' mean?" Helper: "it means you can't do certain things until you're account is four days old and has made ten edits." Do you see what I'm getting at? I'm not saying at all that because it's techie it "doesn't require explaining to non-techies". I'm saying that "your account isn't autoconfirmed yet" is exactly as opaque as "you aren't a full editor yet." Both require the same explanation (or a good link) in order for the person to know what the word/phrase means; no clarity is provided by the name change.--Fuhghettaboutit (talk) 23:40, 9 June 2011 (UTC)
Thanks for explaining your point a little more. Point taken: I agree that no matter what terms are used, they will require some explanation in order to understand exactly what that means. But I don't agree that the term itself is irrelevant. Users would still need an explanation to understand exactly what separates an "editor" from a "full editor", but the words' intrinsic meaning at least gives them a clue what kind of a difference it is. Changing this term would be a subtle change, but I think it would be an important one.
talk
) 02:03, 10 June 2011 (UTC)
Autoconfirmed gives clues: that it's some sort of access level, that it's a technical thing and that it's automatic. By contrast full/senior/established all could give the impression a person must earn a next level by being judged be fellow editors through some sort of process. I don't think that's a good impression to give. So, though no matter what the name it will need explanation, to the extent clues are provided by the title, I think the current is superior to the suggested.--Fuhghettaboutit (talk) 11:38, 10 June 2011 (UTC)
I agree with the last comment. I'm all in favour of eliminating wiki-jargon from our discourse, but in this case I don't think anything else we might think up would work any better.--Kotniski (talk) 11:42, 10 June 2011 (UTC)
Probationary? Provisional? ---— Gadget850 (Ed) talk 17:06, 10 June 2011 (UTC)
  • We don't have to change the word "autoconfirmed". We can just change all the relevant help-/project-space pages from "autoconfirmed user" to "user account that is at least four days old and has made ten or more edits". Longer, yes, but more clear. If someone comes into #wikipedia-en-help asking how to move a page, there's no point in saying "you need to be autoconfirmed/other term" and then explaining what that term means. I've found it just saves time to say, "your account needs to be at least four days old and have made ten edits, now tell me what page you want to re-title so I can do it for you". In this manner, we can eliminate the jargon for new users trying to find help, but still keep the technical name when dealing with discussions on, well, technical stuff. /ƒETCHCOMMS/ 18:32, 10 June 2011 (UTC)
    This is a great idea. More clear for new users without having to actually change the name ("full editor" just doesn't cut it—it even sounds like it's something you have to pay for to become). Well done. Guoguo12 (Talk)  18:50, 10 June 2011 (UTC)
    I agree, this is the best possible course of action that we could take (at least out of what has been mentioned thus far). Ajraddatz (Talk) 23:03, 10 June 2011 (UTC)
    That's the best solution so far, I think; and unlikely to be bettered by something that might actually reach consensus. Rd232 talk 05:45, 11 June 2011 (UTC)
    Yup, but I would still put "autoconfirmed" in parentheses after the long phrase, wikilinked to wherever the concept is best explained - that way people have a chance to learn the jargon (which is actually useful in discussions among experienced editors where everyone knows what's meant) without being baffled by it.--Kotniski (talk) 10:11, 11 June 2011 (UTC)
  • Oppose rename as every comprehensive term would need explanation. Every other option thus far has flaws. For example I think "established user" isn't the same as 4 days and 10 edits and if an unregistered user edits with the same IP over many years, than it may be possible, that he becomes more established then a registered user. 82.131.238.34 (talk) 17:39, 12 June 2011 (UTC)
  • Support. It's a crufty term...I have 10,000 edits and still don't know what it means (honest). TCO (talk) 23:23, 18 June 2011 (UTC)
  • Oppose, at least any term that would makes it explicitly look like brand new users and IPs are getting shafted from the get-go. Moreover, the above IP makes a good point about the one proposal. –MuZemike 09:29, 20 June 2011 (UTC)
  • Oppose. I always make a piped link to
    autoconfirmed to new users and so do many help pages. Those that don't, should. No term can convey the meaning accurately without actually saying "at least 4 days and 10 edits" (and that limit may change and doesn't apply to everybody). "autoconfirmed" gives clues to many people and it gives the right impression that it is a technical term so people can ask or look it up if it isn't linked. "Established" and other common words don't sound technical so many people will not realize it has a precisely defined meaning. "autoconfirmed" is also known by many from other wikis and written by the software in many places so we would need strong reasons to make up our own terminology. PrimeHunter (talk
    ) 22:35, 20 June 2011 (UTC)

Change TfD to use subpages

Currently it is really hard to follow a specific discussion at

WP:TFD. The page should be modified to use subpages like AfD does. This would make following a specific TfD a lot easier. Toshio Yamaguchi (talk
) 18:35, 20 June 2011 (UTC)

Nah... the activity at TFD ebbs and flows, it's not normally as active as it seems to have been this past week or so. Besides, you are aware that you can watch a single day's worth of nominations at a time, correct? You don't have to watch the whole TFD page.
— 
V = IR (Talk • Contribs) 18:47, 20 June 2011 (UTC)
It's really hard to scroll to one of perhaps four sections on a pretty short page and see if anybody has commented since you last looked? I admit that it is very distressing to be in such a scenario, but as Ω's law says, there really aren't enough TfDs – certainly not enough lengthy TfDs – to make such a change remotely worthwhile. ╟─TreasuryTagconsulate─╢ 18:50, 20 June 2011 (UTC)
Ok, it is not "really hard". It is just a bit inconvenient. However I agree Wikipedia has more serious issues to focus on than this. So regard this as resolved per
WP:DONTFIXIT. :) Toshio Yamaguchi (talk
) 18:57, 20 June 2011 (UTC)

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?

Wha?
08:24, 31 May 2011 (UTC)

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

Wha?
19:05, 31 May 2011 (UTC)

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)

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)
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.
Wha?
18:54, 31 May 2011 (UTC)
  • 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. —  
    TALK
    09:41, 31 May 2011 (UTC)
    • 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.)
      Wha?
      18:59, 31 May 2011 (UTC)
  • Support 2,3 per H3llkn0wz. I suspect retrospectively adding full filename case insensitivity is too much of a headache. [Addendum: Sven's suggestion on point 1 of making it apply only to new uploads would be fine.] Rd232 talk 09:52, 31 May 2011 (UTC)
  • Support - I have thought the same thing. --
    talk
    ) 11:14, 31 May 2011 (UTC)
  • If there is such a file on upload the user should at least get a prominent warning so that they can be aware of a preexisting file. Graeme Bartlett (talk) 23:38, 31 May 2011 (UTC)
  • Shouldn't this discussion be on meta or commons? Changing this just for the English Wikipedia would be mostly pointless and inconsistent. Mr.Z-man 00:11, 1 June 2011 (UTC)
    • Yeah, I thought of that just recently. Let's let it get some support here though, as developers rightly tend to like to see consensus before they change anything, so the more consensus we can show them, the more likely they will implement a solution.
      Wha?
      00:40, 1 June 2011 (UTC)

FYI: I was told to post at BugZilla bug 4421 and have done so.

Wha?
05:39, 1 June 2011 (UTC)

  • 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)
    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)
    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
    Wha?
    23:45, 1 June 2011 (UTC)
  • 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)
  • Support 2&3, some files do need to have their names distinguished. —
    Talk • Contribs
    )
    10:08pm
    12:08, 2 June 2011 (UTC)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • Oppose 2,3 - file name extensions are not gospel. MIME associations determine the type of file. Users may have good reasons to name their files the way they do. Jason Quinn (talk) 07:49, 16 June 2011 (UTC)
    • You lost me. Wikipedia treats Foo.JPG and Foo.jpg and Foo.jpeg the same, as all three are the same file type. Good reason for choosing one of those over the others or not, if those three Foo are three totally different things, and the only way to tell between them is file type extension, well that's just absurd.
      Wha?
      08:31, 16 June 2011 (UTC)
      • I see. I misunderstood the intention. I thought you meant using only one extension type exclusively. I retract my oppose. Jason Quinn (talk) 05:53, 17 June 2011 (UTC)
  • Support if all projects - Oppose if only this one - Points 1 & 3 are simply a matter of converting the name to lower or uppercase before checking if it already exists. Point 2 won't be much more work. Arlen22 (talk) 18:32, 22 June 2011 (UTC)

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)

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

No. Sometimes closers make technical mistakes in closing. Sometimes, a post-close comment,made under "no further comments" line, outside the coloured section, are appropriate. Sometimes, there is a subsequent XfD, or DRV, and it is very helpful for this to be noted, but for reviewers of the history down the tract, and for participants who keep the XfD page watchlisted for this very reason.

Is there a problem with edits to closed XfD pages? I think I have thousands of such pages watchlisted, and I check my watchlist regularly, and I don't see problems with edits to old pages. Instead, I think people can be trusted if you trust them. --SmokeyJoe (talk) 13:19, 12 June 2011 (UTC)

I don't think it's necessary. If there's a serious problem with closed AfDs being edited in problematic ways, and such edits are significantly more frequent than good edits to these pages (such as the types mentioned above by
Fram and Cambalachero), then it ay be necessary; however, I don't think these problems are, in fact, there. עוד מישהו Od Mishehu
07:36, 13 June 2011 (UTC)
Really, there should be a MediaWiki plugin for AfDs (and many of our other internal processes) so that their pages aren't just vanilla wikipages, but instead have a proper custom workflow. One of legion MediaWiki nice-to-haves. --Cybercobra (talk) 22:22, 19 June 2011 (UTC)


I would oppose redlocking of closed deletion discussions, simply because when it says "An article was cited for deletion" and then says the result was keep, it is quite interesting to go to discussion. Only my humble view - let me know if I have misunderstood anything here. ACEOREVIVED (talk) 20:08, 22 June 2011 (UTC)

Warn about special editing restrictions

I just recently inadvertently broke a one-revert restriction. The problem is that though the warning comes up at the top of an edit page it doesn't come up if one just presses the rollback button when looking at an edit diff. It is reasonable to put up the restriction on a page that shows buttons for reverting or else after pressing such buttons? Thanks.

Dmcq (talk
) 22:45, 18 June 2011 (UTC)

I'm not trying to be a jerk here or anything but... if you're under an editing restriction of any kind, what in the world are you doing using rollback? O_o
— 
V = IR (Talk • Contribs) 23:30, 18 June 2011 (UTC)
I think the general sanctions/ arb com rulings in the area are being referred to (climate change etc.). As is theres a warning on the talk page, a warning on the edit screen and a policy of not dishing out blocks without clear warnings first - it seems like probably enough to me. Regards, Bob House 884 (talk) 23:32, 18 June 2011 (UTC)
OK, I can understand that. However, I'd think that begs the question even more. If you're working on a page that is under restrictions of any kind, what in the world are you doing using rollback? And, I doubt that any admin or arbitrator will object to rolling back a series of blatant vandal edits, regardless of whether or not the page is under restrictions.
— V = IR (Talk • Contribs) 23:38, 18 June 2011 (UTC)
What should one use if a person sticks in something silly in an article? The talk page does not say 1rr and the link on the talk page does not point to anywhere that talks about 1rr. The warning does not appear if one uses rollback. What I'm talking about is a warning if one uses rollback. And in fact there doesn't seem to be a blanket 1rr restriction on such articles, it just was stuck on that particular article for some reason and not noted anywhere that I know of. Anyway does your question have anything to do with what I was proposing? Do you want to hide such things like land mines?
Dmcq (talk
) 11:34, 20 June 2011 (UTC)
They're not hidden though, a warning pops up on the edit screen and the talk page makes it clear that there are some sanctions on the article (and a rollbacker should probably know that any sanctions on the article warrants extreme caution with rollback). Even then you can't be blocked for violation of it without a warning - the warning itself isn't a sanction, it's there to make absolutely clear that you are aware of the 1RR. The result is that nobody can be blocked for a 1RR violation unless its shown that they knew, or should have known, about the sanctions. In this case, even though you skipped out the edit screens and talk page notes, you were obviously made aware of the special rules on the article and no administrative action has been taken. You might disagree but that seems pretty tight to me. Regards, Bob House 884 (talk) 14:33, 20 June 2011 (UTC)
How exactly should I have found out about it before doing the rollback?
Dmcq (talk
) 18:18, 20 June 2011 (UTC)
By looking first? I don't understand where the mix-up is, here. There may not be warnings plastered all over the article, but... I mean, you could take 10 seconds to look at the talk page. Why is everyone always in such a hurry to use rollback, undo, and similar things?
— 
V = IR (Talk • Contribs) 17:48, 22 June 2011 (UTC)
You don't necessarily need to look at the talk page to figure out whether blatant vandalism like "I LOVE CHEESEBURGERS!!!!!!!" should be reverted. If you're doing recent changes patrol work, your goal is to get vandalism removed now, not after several more readers have seen it—even if that means removing it before you carefully study whether there are unusual situations at the article. WhatamIdoing (talk) 22:00, 22 June 2011 (UTC)
Covered above, though. No?
— V = IR (Talk • Contribs) 22:57, 22 June 2011 (UTC)

(edit conflict)If it's blatant vandalism, I doubt anyone would object per 1RR. If it's not... you should be investigating the edit & the talk page, not automatically rolling back the edit. — The Hand That Feeds You:Bite 22:59, 22 June 2011 (UTC)

Tagged hotlinks in photos

http://en.wikipedia.org/wiki/Riviera_Maya it would be useful to be able to click elements of a map/diagram/photo to link to the entry for the tagged object (eg. the cities in the Riviera Maya map). Doc Martian (talk) 09:52, 22 June 2011 (UTC)

You can create an WP:image map, which has a similar effect. - Jarry1250 [Weasel? Discuss.] 15:56, 22 June 2011 (UTC)

RfC on minimum prep-time for main-page blurbs

Editors are welcome to discuss this proposal here. Tony (talk) 11:07, 22 June 2011 (UTC)

equations translated to english

I saw this idea on the village pump ideas lab at [[18]]. it would be really useful for me and at least one other person in trying to learn math from Wikipedia. Σ

I suppose you could have a user/browser plugin which explains the meaning of mathematical operators when selected, but a general translation of math to english? Sure 1+1=2 can be written as "one plus one equals two", but try doing the same with the Navier-Stokes equations in spherical coordinates. Your "translation" would become so long it would impossible to understand, which is probably why people invented math in the first place. Yoenit (talk) 07:41, 20 June 2011 (UTC)
You can use the alt attribute: <math alt="the divergence of B equals zero">\nabla \cdot \mathbf{B} = 0</math> gives . It is, in fact,
recommended, for screen readers and other browsers which don't support inline images. A. di M.plédréachtaí
20:38, 23 June 2011 (UTC)

Improve all performance information for cars with automated tools

I have noticed that most articles does not provide very confident information about performance, I even notice that there is no a defined writting style for this performance information.

I would like to propose a little fact information that should be included at performance section of all cars, or at least sports cars, I think that could provide useful information to a lot of car enthusiast people, in a single place you could find all that information

Performance facts:

  • Enviroment conditions: Temp: Xc, Humidity: Y%, Altitude: Z meters

Time to Speed (mph or km/h does not matter)

  • 0-30 mph
  • 0-60 mph
  • 0-100 mph
  • 0-200 kmh

Time to Distance (or distances in meters, does not matter)

  • 0-100 m
  • 0-1/8 mile
  • 0-1/4 mile
  • 0-1 km

Top Speed: W mph (or km/h)

It could be done very easy with car performance simulators like the one I am working on (www.nxgtrsim.com) or any other that could be used for Free, which I think gives very real results and it is the only option that is Free + Online + Advanced in whole internet, and could help to wikicars a lot.

Why do you consider these simulators to be
Fram (talk
) 09:28, 23 June 2011 (UTC)
I think this is one area standardisation is not necessary. We can cite what we think is appropriate. It's clearly possible to accurately (and usefully) describe the performance of cars is a useful way, and I don't think Wikipedia gains much from all articles being the same. Infoboxes, however, use of and data used, would be more feasible a standardisation. Grandiose (me, talk, contribs) 19:19, 23 June 2011 (UTC)
Something like that would make an excellent tool for an automotive review program/magazine-- which we could then potentially cite as a
WP:OR. Wabbott9 (talk
) 00:21, 24 June 2011 (UTC)

List of Wiki internal linking

Hello,

I oftentimes skim through artikels. Often i spot interesting Wiki Links (http://en.wikipedia.org/wiki/Wikipedia:Linking) but i dont open them, forget where they were or simply forget what artical i wanted to open. :) so i thought it would be nice, for many more reasons (also to keep track), to see an alphabetical list of all the links within that articel.

for example http://en.wikipedia.org/wiki/Computer now i want a list of all links, i.e. related articels

progammable machine memory data

and so on.

194.9.246.48 (talk) 13:18, 24 June 2011 (UTC)

If you are looking for all the articles that link to Computer that is here, Special:WhatLinksHere/Computer. You can find this list on the left side of the article in the toolbox under "What links here". If you are looking for an alphabetical list of all the articles that Computer links to, I don't think that is done anywhere. GB fan (talk) 13:31, 24 June 2011 (UTC)
Hello.
Thanks for your kind reply. Highly appreciated.
I was actually looking for the second, as this would give you like a mindmap/network of related topics/articels which would be awesome. Surely there must be a way to implement that.
I have to add though, that I am thankful for your tip with that "link to".
Have a good one.

194.9.246.48 (talk) 14:48, 24 June 2011 (UTC)

Though one could use
WP:AWB to see all the pages that Computer links to. Avicennasis
@ 11:21, 14 Av 5771 / 14 August 2011 (UTC)

RFC: implementing Manual of Style restructure

Editors may be interested in revisiting this RFC, now that there is discussion of its implementation:

Should all subsidiary pages of the Manual of Style be made subpages of WP:MOS?

It's big; and it promises huge improvements. Great if everyone can be involved. NoeticaTea? 00:58, 25 June 2011 (UTC)

Add link to new pages to sidebar

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)

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)
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)
Couldn't you just put it on your watchlist? Peter jackson (talk) 14:50, 8 June 2011 (UTC)
You can't watchlist any of the Special:SpecialPages, nor edit them for that matter. Yoenit (talk) 14:55, 8 June 2011 (UTC)
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)
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)
Sounds like a great idea, to me.
— 
V = IR (Talk • Contribs) 23:03, 8 June 2011 (UTC)
Yes, I think this would be useful. Killiondude (talk) 23:07, 8 June 2011 (UTC)
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 (talkcontribs) 16:47, 9 June 2011 (UTC)
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)
I find the live feed in the sidebar perfectly adequate. See User:TheJosh/Scripts/NewPagePatrol.js. Kudpung กุดผึ้ง (talk) 17:07, 9 June 2011 (UTC)
@TheDJ: how many visitors, if any, are looking for Recentchanges, which has been there forever? AD 17:13, 9 June 2011 (UTC)
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)
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)
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)
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)
Aiken, we've done some work on determining what happens to pages, and ~80% of the mainspace pages written by new editors end up deleted within ~6 months (most within a week). WhatamIdoing (talk) 01:52, 10 June 2011 (UTC)
Doesn't surprise me at all, but how good the pages are isn't relevant to whether or not it would make a useful link - which it undoubtedly would. AD 21:51, 10 June 2011 (UTC)
I made a .js script for that. It's in userspace. ~~EBE123~~ talkContribs 20:01, 14 June 2011 (UTC)
I still don't see why it can't be the default. AD 12:59, 18 June 2011 (UTC)

I would like a link New Pages to be added to the sidebar. I agree with this proposal.James500 (talk) 08:15, 23 June 2011 (UTC)

  • Oppose, there's probably already too much stuff in the sidebar for the casual reader. Recent changes is enough (and a standard link on most wikis), and has the new page link on top. For editors, it is easy to add New pages links to their userpages. —Kusma (t·c) 08:28, 23 June 2011 (UTC)
If your computer was as slow as mine is, you would realise why I don't consider the link to new pages on my user page to be of much practical use. James500 (talk) 06:13, 26 June 2011 (UTC)

Suggestion - How about allowing users to enable a link to Special:NewPages by using the gadgets section of Special:Preferences. James500 (talk) 06:25, 26 June 2011 (UTC)

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, or else in software (cf T31324). Rd232 talk 21:50, 9 June 2011 (UTC)

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)
That was a template issue (from {{
cot}}/cob); I've fixed it temporarily by removing the template. I wanted the transcluded annotation page hatted though so as not to push the log entries too far down the page. Perhaps someone more template-techy can fix it. Rd232 talk
22:21, 9 June 2011 (UTC)
I think this is a good idea. The block log (and all logs, for that matter) can't have links to specific versions of pages, spercific deleted pages, or log entries of specific users or pages. עוד מישהו Od Mishehu 18:39, 14 June 2011 (UTC)
Yes they can. Copy/paste works wonders. The problem was the character limit. Killiondude (talk) 18:45, 14 June 2011 (UTC)
Should non-admins be able to view the page? -- Eraserhead1 <talk> 19:09, 20 June 2011 (UTC)
...no.
— V = IR (Talk • Contribs) 22:01, 20 June 2011 (UTC)
Yes, for transparency. The aim is a clearer understanding of a user's block history; there's no reason to limit that understanding to admins. (In any case, AFAIK there's no current way to enforce admins-only viewing a page.)
talk
00:13, 26 June 2011 (UTC)
Um... it;s already inaccessable to non-admins. It's a page in the Special namespace, which requires sysop permissions to view or edit.
— V = IR (Talk • Contribs) 01:39, 26 June 2011 (UTC)
Well I guess it wasn't clear enough from the above, but the Special:Block bit is just loading a page from somewhere else, for convenience. That somewhere else is a page in the relevant user's userspace
talk
02:15, 26 June 2011 (UTC)

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)

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

We have a proposal for a pagemover group. It may be useful. ~~EBE123~~ talkContribs 19:59, 14 June 2011 (UTC)
I wasn't aware that new page moves from user to mainspace don't feed into NPP. I thinks it's absolutely essential they should, because if this loophole gets more widely known, it will be massively exploited. Not by the vandals, hoaxers, and attack pages, which are more spontaneous, but by the hard nosed SEO agents, corporate spammers, soccer fans, garage bands, and autobiographers promoting their first book or candidacy to the village council. Kudpung กุดผึ้ง (talk) 07:40, 19 June 2011 (UTC)

I question whether it is a useless cross-domain redirect. If the content existed in userspace, and now exists in mainspace, someone may have linked to the userspace version, so those links should redirect to mainspace. —Tom Morris (talk) 19:13, 27 June 2011 (UTC)

The only links that its important to maintain are those in the mainspace, and there are no mainspace articles linking to userspace articles, any links that are added are removed on a weekly basis (From Wikipedia:Database reports/Articles containing links to the user space)--Jac16888 Talk 19:19, 27 June 2011 (UTC)
You misunderstand. Links from outside Wikipedia to the user version. —Tom Morris (talk) 21:34, 27 June 2011 (UTC)

"All other namespace" tab in dropdowns

Currently, dropdown menus like the ones in "user contribution" pages allow you to search by individual namespace of by all namespaces overall. With many users, more than half of user contributions are in the article namespace. Is it possible to add an item in the dropdown menu allowing you to - at one go - search all contributions other than those in the article space? This sort of addition would also be useful in the similar dropdown menus in "new pages", "what links here", "related changes", etc. Grutness...wha? 02:13, 26 June 2011 (UTC)

I think this is a good idea; it's been around a while. The relevant bug is
talk
11:17, 26 June 2011 (UTC)

Category →'s at the bottom of articles

A major pet peeve of mine are laundry lists. Oh boy do I hate them! Why is it that so many articles are categorized inside categories to which they are also categorized? To look at what should be done, here is a good example: Category:Rivers. So how do we get people to not overcategorize? Imagine the following scheme at the bottom of each categorized page:


Categories:


Ideally, the shortest path between the top category Category:Contents and any category selected should be chosen.

And of course, in practice, only the first parent level should be shown. Example:


Categories: Rivers of EuropeRivers of Albania | Europe-related listsAlbania-related lists


In general, only one parent level need be shown.

This would prevent people from over-categorizing articles. This would also make for a much nicer and functional outline to be the pervasive norm.

Signed, a laundry list hater, siNkarma86—Expert Sectioneer of Wikipedia
86 = 19+9+14 + karma = 19+9+14 + talk
03:24, 27 June 2011 (UTC)

  • Comment This would be technically impractical: Graph traversal is generally a hard thing to do right and would require significant work from MediaWiki developers to implement and significant system resources. More detailed reasoning than "Oh boy do I hate them!" is needed to justify the technical and human resources needed to implement this. —Tom Morris (talk) 10:20, 27 June 2011 (UTC)
  • Comment: wouldn't it be more practical to come at the problem more directly? The issue is page or category A appearing in both category X as well as in category Y, the parent of X. (Sometimes this behaviour is desirable, but usually it isn't.) Perhaps
    talk
    10:59, 27 June 2011 (UTC)
    • As long as users were made very aware of the cases when that behaviour is desirable (such as the much-discussed and occasionally understood eponymous categories question).--Kotniski (talk) 11:14, 27 June 2011 (UTC)
      • Are they identified in some way that HotCat could feasibly do that?
        talk
        21:49, 28 June 2011 (UTC)

Removing edit conflict notice from the sandbox

I am not sure that there is the technology to do this, but here goes!! Tonight (June 28 2011) I had been trying out citation methods on Wikipedia: Sandbox, and got the message - "Some one else has been starting to edit this since you began, resulting in an edit conflict". My plea is for there to be a removal - if this is technologically possible - of the edit conflict tag from the sandbox, as surely, it is more than likely that there will be several people editing there simultaneously. ACEOREVIVED (talk) 19:18, 28 June 2011 (UTC)

In fact, I remember some one raised the question of edit conflicts some time ago earlier this year (2011) - did anything come of it? ACEOREVIVED (talk) 19:19, 28 June 2011 (UTC)

I don't know about that, by I do know that reasonably experienced users needn't be using the main WP sandbox. I've knocked up a userbox {{
talk
21:38, 28 June 2011 (UTC)


Thank you for that - giving people the right to use their own personal sandboxes on their own userpages seems a marvellous idea! ACEOREVIVED (talk) 23:08, 28 June 2011 (UTC)

Page mover


Install extension Pchart4mw - for charts drawing

Since we only have the <timeline> extension for simple (bar only) chart drawing, I propose to install the Pchart4mw extension to have the ability to create various types of real charts/graphs. Thank you for your support!--Kozuch (talk) 11:53, 19 June 2011 (UTC)

  • Support I would have it tested on one of the test wikis first, but this extension does seem to be a net positive for visuals in articles. Logan Talk Contributions 07:06, 20 June 2011 (UTC)
  • Support Sounds like a very useful feature, so long as it goes through a series of tests before widespread use (support, efficiency, output...). Grandiose (me, talk, contribs) 12:51, 22 June 2011 (UTC)
I have no idea how correct "extension installation" works here on EN Wikipedia, but I suppose community consensus is the very important part of the proccess. So yes, after we hopefully have consensus the technical part will begin (probably extensin code review, making sure it performs ok etc.?). If someone can supply info about correct steps in the process this would be welcome. I was also thinking of enabling it first on a smaller wiki (for instance Czech Wikipedia), but I did not ask for consensus there yet.--Kozuch (talk) 07:44, 23 June 2011 (UTC)
  • Strong Support This makes data editable as opposed to user externally-created charts. This will also bring some visual consistency. And finally this will make new chart making easy
    TALK
    14:58, 22 June 2011 (UTC)
  • How does this compare with the (many) options listed at
    WP:Graphs? WhatamIdoing (talk
    ) 22:07, 22 June 2011 (UTC)
I do not know "Template:Visualizer" or "Template:Pie chart" - one of the differences I see - these run on Toolserver (whose stability and availability is a big "?" sometimes). This would be a local extension which will perform much better I guess. --Kozuch (talk) 07:44, 23 June 2011 (UTC)
Pchart4mw has more chart types, it seems. They also look better (in my opinion) and are more customizable. InverseHypercube 00:57, 1 July 2011 (UTC)

Forgiveness day, 7 August

I was just thinking about a "forgiveness day", and it turns out there is one - 7 August [20]. So I propose that we adopt this on Wikipedia, to help spread peace and good will among editors and encourage them to try and put aside past conflicts. The idea is that we'd knock up a user template along the general lines of "I'm sorry for my contribution to our past conflicts, in honour of International Forgiveness Day I hope we can put these behind us and achieve better collaboration in future." (off the top of my head; much improvement possible; not forgetting to encourage the user to add a personalised addendum). {{

talk
23:35, 25 June 2011 (UTC)

That'd be great fun, if only human minds allowed someone to get rid of grudges on a whim. Since they don't, the result would be either (a) something completely meaningless or (b) something easier to game than a multiple-choice test. Ironholds (talk) 23:55, 25 June 2011 (UTC)
"if only human minds allowed someone to get rid of grudges on a whim..." - I think you need to reconsider what forgiveness means. In addition, a public commitment helps people sustain behaviours, so the public declaration is not meaningless, even if it doesn't work out in every case. I don't see where gaming comes into it.
talk
02:12, 26 June 2011 (UTC)
I agree with Ironholds to an extent. I no longer bear ill will to a number of people that I've had fights with, but there are some things that cannot be forgiven. I think that we could adapt it to a day of talking out differences and making commitments to settling disputes more amicably, but it won't, say, stop the NFCC war or anything of that caliber of conflict.
Wha?
05:30, 26 June 2011 (UTC)
"I think that we could adapt it to a day of talking out differences and making commitments to settling disputes more amicably..." - well that's the general idea. Forgiveness seems a good starting point for that, since it's often necessary, but if someone wants to suggest an alternative approach, I'm open to suggestions. At root, I just think an annual "let's put this shit behind us and try again to be really collaborative" day would be good.
talk
11:26, 26 June 2011 (UTC)

I just followed that link in the OP's post. It's amusing that the "Worldwide Forgiveness Alliance is a non-profit 501(c)3 tax-deductible organization." (My bolding.) Should I forgive them for not arranging deductions for 95% of the world's population? — Preceding unsigned comment added by HiLo48 (talkcontribs) 05:47, 26 June 2011 (UTC)

I forgive you for being a hater and for undermining a good idea only for the sake of hearing your own voice.
Wha?
06:19, 26 June 2011 (UTC)
A hater? Oh dear. I will forgive you for your paranoia. HiLo48 (talk) 06:22, 26 June 2011 (UTC)
It is neither amusing nor relevant, since the organization isn't involved in the proposal in any way. I came across the organization in searching for a "forgiveness day", an idea I had, and this came up and it makes sense to use an existing date that someone is already promoting (not least to avoid the need to pick a date from scratch). If there are any alternatives to 7 August already being promoted, let's hear them.
talk
11:26, 26 June 2011 (UTC)
It has the advantage of falling on my birthday. (Forgive me for pointing that out!) :-)--Jimbo Wales (talk) 01:33, 27 June 2011 (UTC)
Curses! People will assume it's a conspiracy! :)
talk
02:27, 27 June 2011 (UTC)


Shouldn't all days be foregiveness days? To forgive is one of the great Christian virtues, and it would be a shame if we confined this ideal to a mere one of the three hundred and sixty-five days in the year. ACEOREVIVED (talk) 18:21, 29 June 2011 (UTC)

We pagans, on the other hand.... --Nuujinn (talk) 19:27, 30 June 2011 (UTC)
If after trying to get through the behaviour of a person is still not satisfactory I think a measured amount of retribution is called for, it helps the world go round, without it you get jerks and freeloaders. After that one should check and see if things are now satisfactory. So what exactly is the point of having a particular date for forgiveness? Is it for people who don't know when to stop retribution or somehow otherwise to let them get on with their lives?
Dmcq (talk
) 21:06, 30 June 2011 (UTC)
I'm in favor of forgiveness; gimmicks, not so much. I'm afraid this will come across as a gimmick, however much that might not be the intent.
I'm not necessarily opposed. Who knows; it might do some good. But it will definitely also make some people roll their eyes. --Trovatore (talk) 00:34, 1 July 2011 (UTC)

Proposal to seperate template warnings for edit warring and breaking 3RR

A couple of weeks ago I made this suggestion at

U-Mos (talk
) 16:50, 27 June 2011 (UTC)

I agree that there's a need for a separate template, as the wording of Template:uw-3rr implies accusation of edit warring. Which, as you pointed out, is not always the case and should not be automatically assumed in all cases of multiple reverts within a 24-hr. time frame.--JayJasper (talk) 22:50, 30 June 2011 (UTC)

Boycott

I propose creating a list, possibly at

WP:G11ed, engages in linkspam, replaces neutral encyclopedic content with a press release, or hires anyone to do so on their behalf. 99.164.32.24 (talk
) 09:48, 29 June 2011 (UTC)

Any such list would probably result in companies spamming on behalf of their competitors. --Yair rand (talk) 09:52, 29 June 2011 (UTC)
Quite right. That's the true spirit of a proper security consultant.
Dmcq (talk
) 11:14, 29 June 2011 (UTC)
Actually, this sort of thing would be better implemented "off-wiki", so to speak. You could put together a list of companies that spam, share it with any interested partied, and do it unconnected with Wikipedia (say on a blog or some such thing where you have control over who posts). Just make sure you let the companies know why you're boycotting them. Wabbott9 Tell me about it.... 02:07, 30 June 2011 (UTC)
As Yair rand explained this would be exploited. It really would be, it isn't a joke. And it wouldn't even have been an unforseen consequence. I would not want to be associated with this sort of damage to innocent companies. We're better off just dealing with the problem straightforwardly as at present by blocking spammers.
Wouldn't this give legal problems? Even if we recognize, revert and block them, companies can easily deny relation with spammers, and then accuse wikipedia of plotting against them. It may be better to accept spammers as a "fact of life", that must be kept at bay but which can not be completely erased Cambalachero (talk) 14:27, 30 June 2011 (UTC)

Really short Wikipedia URLs

I think that Wikipedia should get their own article URL shortening service. There are 20 million articles in its >250 versions. So 6 alphanumeric characters should be enough to list them all (52^6 = 20 billion, or 70 million articles per language). How about an automatic system that changes en.wikipedia.org/wiki/History_of_the_universe into wkpshrt.org/5egF4w and pops up in each article page you visit to share easily? That can go for other Wikimedia projects as well. How do we make it? --NaBUru38 (talk) 22:52, 21 June 2011 (UTC)

  • Is there a good reason that Wikimedia/the MediaWiki software should implement this when there are good third party tools available to do it easily, though (TinyURL.com, bit.ly, etc...)?
    — V = IR (Talk • Contribs) 23:11, 21 June 2011 (UTC)
    • It is worth noting that some projects already have slightly shortened urls (http://enwp.org, there's one of the English Wikinews and probably others too). - Jarry1250 [Weasel? Discuss.] 14:10, 22 June 2011 (UTC)
      • Yep, enwp.org works for any WP page ( http://enwp.org/Barack_Obama for example). And the Wikinews one is enwn.net, which works differently (more like a bit.ly service). But I agree with the above. There are way too many third-party services out there. And we want to make Wikipedia less socialized. Anyone who wants to share a short link should already know how to. /ƒETCHCOMMS/ 16:10, 22 June 2011 (UTC)
        ...why do we "want to make Wikipedia less socialized."? Maybe that's what you'd like, which is fine, but I certainly don't want us to be more anti-social than we already are. :(
        — V = IR (Talk • Contribs) 17:44, 22 June 2011 (UTC)
I think we don't want to have to ask Big brother to do everything for us. Bus stop (talk) 17:55, 22 June 2011 (UTC)
... no one is, so I don't get your point. — The Hand That Feeds You:Bite 23:00, 22 June 2011 (UTC)
I think
bit.ly's approach makes more sense - links are only given when someone wants to link something. By contrast, your approach covers all articles, linked to or not, and only articles. So for example, as a test, bit.ly/lNbS69 now links to editing this particular section of this page. I wasn't asked to register. I don't know how long it will last, but it seems like a versatile solution. But I'm not sure making and archiving new custom links in this fashion would be within the mission of Wikipedia. True, Big Brother is probably listening in, but alas, the same is probably true of Wikipedia or any other site. Look at how many traceroutes run through Reston, Virginia, put it that way. Wnt (talk
) 05:18, 27 June 2011 (UTC)
Yeah. Silly National Wildlife Federation spying on us Nil Einne (talk) 12:35, 1 July 2011 (UTC)
Ok, I didn't know enwp.org. It's a cool feature. However, as you mention, it's run unofficially. An official shortening service would be much safer. Also, enwp.org doesn't truly shorten addresses. You wouldn't be abled to share List of submissions to the 83rd Academy Awards for Best Foreign Language Film on Twitter, for example. Fetchcomms, Wnt, this official service would help to spread the project easier. An unexperienced user could copy the shortened link from the article page and share it with others. Not everyone knows bit.ly, and lots of people wouldn't bother follow those steps whereas this option would be much more accessible. --NaBUru38 (talk) 23:58, 2 July 2011 (UTC)
In February, the Wikimedia Foundation welcomed the offer of the owner of enwp.org to give them the domain [21]. In May, it was said that the matter had been referred to Rob Halsell from the Foundation's tech department [22]. It was pointed out that some tech people might be a bit skeptical about it [23].
URL shorteners can present privacy issues as they can track who clicks on a shortened link. They often publish part of this tracking data. For example, bit.ly lists the number of clicks per country, and per referrer (add "+" to a bit.ly link). This could quite easily be exploited to find out a Wikipedia user's country. A shortener owned by the WMF would offer the benefit that such data would be governed by the WMF privacy policy.
Regards, HaeB (talk) 17:51, 3 July 2011 (UTC)

Template for Regiowikis

Hi all. Regiowikis are wikis focused on a geographical area. I propose to create a new template {{Regiowiki}} to link to these encyclopedias in the articles about cities. Example on the right for Tomsk. Just a link in "External links" section would be nice but this is a way to promote free knowledge creation.

By the way, I'm working on a list/map for all regiowikis in the world (

emijrp (talk
) 08:56, 30 June 2011 (UTC)

Hold your horses! I have several objections:
Hi. 1) OK, a new design is desired. 2) OK, only links to English writtens wikis. 3) I'm OK with this. 4) Come on! That is a side effect ; ) Regards.
emijrp (talk
) 10:38, 30 June 2011 (UTC)
I do not think this to be a good idea. A special template for a external link gives undue weight to the link over the others, and certainly the official web site of a region (if exists) should be more important than a wiki. Cambalachero (talk) 14:22, 30 June 2011 (UTC)
Since those links would almost never meet
WP:EL, and thus would almost never appear in articles, why would we want/need a special template? Qwyrxian (talk
) 10:43, 2 July 2011 (UTC)
You could use {{Facebook}} as a model for the correct style of such a link, but Qwyrxian is right: Why bother creating a template that has almost no legitimate uses? WhatamIdoing (talk) 14:21, 2 July 2011 (UTC)

Hide red talk page links for deletion discussions

I'm proposing that we add something to the common JS or CSS file that hides redlinked talk page tabs for deletion discussions. I've only ever seen one editor confused by this, but surely this tab is rarely if ever used. There should not be any meta-discussion about the discussions, all that needs to be said should be said on the page. If, by some wacky circumstance, a talk page must be created, then the tab will show as blue. Any editor that knows enough to know that the talk page must be created should also know how to type "talk" into the URL. To go to a discussion and find there is an empty discussion tab is a little counter-intuitive. This way there is no chance for even momentary confusion. ▫ JohnnyMrNinja 07:54, 2 July 2011 (UTC)

They're usually not used, but sometimes they are. It's sometimes helpful to move extended analysis of sources there, or lengthy tangential discussions. I've participated in a handful of AfDs where this happened. It's sort of analogous to the admin noticeboards: you "talk" on
WT:ANI. 28bytes (talk
) 08:09, 2 July 2011 (UTC)
Yes, this sometimes does happen, but the difference is that WP:AN never has a red talk page tab, whereas AfDs almost always do, by their nature. Once you create a Village Pump talk page, that tab is blue forever. Also, new users often need to go to AfD, as they are the ones most often creating pages that need to be deleted. And again, if the the tab is blue it should not be hidden. ▫ JohnnyMrNinja 08:46, 2 July 2011 (UTC)
This seems sensible. -- Eraserhead1 <talk> 09:09, 2 July 2011 (UTC)
I don't think that we want to require people to hand-code URLs. We shouldn't assume that every person with an interest in that page is a regular at the English Wikipedia, or that everyone finds it just as easy to type as to click (especially on a mobile device). Also, the redlink definitively indicates to the regulars that there isn't anything of interest on the talk page. WhatamIdoing (talk) 14:56, 2 July 2011 (UTC)
I'm not assuming that they are a regular, quite the opposite. I'm assuming that most people that go to an AfD don't know where to post. People who know enough about AfD to know that a separate discussion about the discussion is required, these people I'm assuming are regulars. There is no situation where someone who doesn't know how en works would also need to post on the talk page instead of the discussion. And yes, seeing a redlink is how people know it is a redlink, just as seeing any noun lets you know it is that noun. If only redlinks were hidden (again, not blue links), then seeing any talk page tab would be an indicator that there was a conversation there. It is unlikely this would cause a problem for anyone. Not seeing a talkpage tab will be just as reliable as seeing a red one, as it will be the same wiki software hiding it. ▫ JohnnyMrNinja 21:39, 2 July 2011 (UTC)
I'm not sure of the total numbers, but here is a list of all AfD talk pages. I said that I personally had only seen one editor confused by the talk page tab during a discussion; well, that list contains hundreds. I ask anyone interested in this proposal to take a random selection of these pages and see how many comments had to be made on the talk page, vs how many could or should have been on the AfD. The vast majority of comments on those talk pages are from people that think they will be part of the discussion. The vast majority of "meta" comments should be made in the discussion: SPA notices, relisting, deletion sorting, etc. People would not expect a meta comment on the talk page and it would likely go unnoticed. Comments taken out of the discussion are now simply hidden with a collapsible template, so (again) people can always easily see all parts of the conversation. ▫ JohnnyMrNinja 21:39, 2 July 2011 (UTC)
I have used the talk page a few times, such as WT:Articles for deletion/Thou Shalt Not.... I have also seen a few comments accidentally placed there. Flatscan (talk) 04:31, 4 July 2011 (UTC)

Link to Facebook

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)

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)
This has been suggested quite frequently recently, see e.g.
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)

What would the purpose of echoing your edits onto Twitter and Facebook be, other than for canvassing purposes?

talk
) 20:41, 3 June 2011 (UTC)

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)

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)

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

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)

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)
Totally agree.
talk
) 03:21, 5 June 2011 (UTC)
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).
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)

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

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)
  • 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.
    Wha?
    07:50, 6 June 2011 (UTC)
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)
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.
scripts
)
18:34, 7 June 2011 (UTC)
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)
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)
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.
scripts
)
18:56, 7 June 2011 (UTC)
  • 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)
  • 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)
  • Oppose Per Bob House. Also, in the manner of what I'm refering to: day b nuf spelin n shit 4 work weddout folk @fb writ dis we dot needat Ian.thomson (talk) 19:44, 8 June 2011 (UTC)
Nasa's web site[24] 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)
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)
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)
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)
  • 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)
  • I have to say I'm not a fan. --Guerillero | My Talk 21:04, 8 June 2011 (UTC)
  • Oppose How to manage it? Also, people would not go here just because they can use it because of a sn (social networking) account. ~~EBE123~~ talkContribs 20:07, 14 June 2011 (UTC)
  • Oppose we don't want Facebook tracking people on Wikipedia, so we need to keep it separate. However I am not opposed to linking to official or fan facebook pages in external links. Graeme Bartlett (talk) 05:26, 19 June 2011 (UTC)

I would oppose linking Wikipedia to Facebook for the following reason. Although there are probably many people (myself included) who like both Wikipedia and Facebook, and have both a userpage on Wikipedia and a profile on Facebook, we should remember that if one goes to WP: What Wikipedia is not and reads what is under Sub-heading 2.5, we have the clarification that Wikipedia is NOT a social networking website. We should not really confuse social networking websites with an online encyclopaedia - Facebook and Wikipedia both have their uses, but for different reasons. As or the suggestion above that this would be unlikely to attract vandals because people use their real names on Wikipedia, please remember that people use their real names on Citizendium but that this online encyclopaedia is still vastly inferior to Wikipedia. ACEOREVIVED (talk) 20:04, 22 June 2011 (UTC)

  • oppose Along with many other reasons listed above (and perhaps this is too) I would be worried that some of the ... ummm ... problems (Virus, phishing, scams, etc) could end up compromising something here. And accounts/names/passwords being compromised at WP almost always leads to some very undesirable results. Second, I'd wonder if it would increase the amount of "
     ? 
    02:50, 27 June 2011 (UTC)
  • Oppose - no for facebook ads - but it may be added as gadget Bulwersator (talk) 09:17, 4 July 2011 (UTC)

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 (talkcontribs) 19:46, 6 June 2011 (UTC)

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.
scripts
)
20:02, 6 June 2011 (UTC)
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. --
talk
) 20:23, 6 June 2011 (UTC)
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)
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)
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
scripts
) 18:29, 7 June 2011 (UTC)
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 (talkcontribs
) 20:36, 6 June 2011 (UTC)
@AQFK: Especially not BLP articles, if you catch my meaning. =p Sir William Matthew Flinders Petrie | Say Shalom! 20:33, 6 June 2011 (UTC)
Apparently, the Wiki software already supports this feature. For example, scroll to the bottom of a WikiNews article.[25] There are links for Facebook, Twitter, LinkedIn, Digg, and several others. A Quest For Knowledge (talk) 20:39, 6 June 2011 (UTC)
That's just a template, found
scripts
) 18:29, 7 June 2011 (UTC)
mw:Extension:PageNotice might obviate that, if it were installed. Rd232 talk 10:23, 9 June 2011 (UTC)
  • Oppose - Please see the post five posts up from this one, which deals with the exact same thing, for my reasoning.
    Wha?
    08:36, 16 June 2011 (UTC)
I've seen both of these, and many others. They never seem to get real consensus. Perhaps we have another
Persistant proposal to add to the list? Wabbott9 (talk
) 00:05, 23 June 2011 (UTC)

Everyone here is talking about what they want, or like. We should be considering what our users want; and what will encourage greater use of and participation in the 'pedia. And while that means doing research, anecdotally we can see that people do like, and use, such features. (For the record, my personal view is that such things belong in the browser, as bookmarklets or add-ons, rather than on the page. But I accept that that probably puts me in the minority). Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 10:20, 27 June 2011 (UTC)

+1 to both your meta point about needing to engage the users on this and you preference as to implementation via a plugin. Although I could also see having it as part of a skin, so user selectable as a reasonable option. Gonzo (talk) 10:32, 27 June 2011 (UTC)

First, I'm noting that I made this a subsection of the above Facebook thread, as they are both pretty-much about the same thing. Second, how about this: Why doesn't somebody whip-up a WP gadget with social bookmarking functionality, and we can use that as a gauge. We can easily track how many people use it. If it gets an overwhelming amount of support, we can look further into implementing actual MediaWiki extensions like mw:Extension:Facebook. If it is not popular, or causes problems, then we have our answer. I would recommend this gadget only function in mainspace and File: space. ▫ JohnnyMrNinja 11:12, 27 June 2011 (UTC)

  • comment Someone asked me to comment here from n:Wikinews:Water_cooler/technical#Facebook. I just wanted to mention there may be significant privacy considerations with integrating facebook. A click here to share on facebook button is ok (Since its passive, the user has to click in order to send info to facebook), but facebook like buttons, or logging in using facebook account, and pretty much all of mw:extension:Facebook allows facebook to gather information about our users essentially without their permission. (And is probably in violation of the privacy policy, although I don't think I've read the privacy policy so wouldn't be able to say for certain). Previous times this has been brought up on the mailing list its been shot down over privacy concerns recent example that's not quite the same because its about chapters. Bawolff (talk) 20:16, 29 June 2011 (UTC)
    • These issues are well known throughout the technical community and within the Foundation. Of course that doesn't mean that we can't do more than we do now, just that there are some specifics that we cannot do. —TheDJ (talkcontribs) 21:16, 29 June 2011 (UTC)

Teenage Editors

I feel that we need to have a Wikipedia page/essay which explains the policys to teenage editors. I know we already have Wikipedia:Guidance for younger editors but this is writen in a childish way wich could put teenage editors off. I would quite happly re-word that page if there was enough support. Oddbodz (talk) 21:28, 18 June 2011 (UTC)

I'm not sure what sort of person would be old enough to be insulted by the simple tone of the guidance for younger editors yet unable to understand the 'adult' tone of the policies themselves...? ╟─TreasuryTagmost serene─╢ 21:31, 18 June 2011 (UTC)
Some teenagers may feel that their maturity is being questioned. They may, however, not want to read the full adult version. It's just a sugestion. Oddbodz (talk) 21:38, 18 June 2011 (UTC)
Or they may not want to read them at all :P But I think it's perfectly reasonable to expect them to do so. ╟─TreasuryTagcondominium─╢ 21:39, 18 June 2011 (UTC)
Wikipedia is an "adult" place; I'm all for contributions from a diverse range of ages and demographics, but if you need to be spoonfed policies because you can't/don't want to take the time to decipher our professional-style guidelines... that's not a good thing. Juliancolton (talk) 21:46, 18 June 2011 (UTC)
The policies imo are generally readable enough by any 13+ year old. AD 21:32, 18 June 2011 (UTC)
Bah, don't listen to TT or Juliancolton. They're just trying to scare you off for some reason. You're just talking about an essay, so just click on: Wikipedia:Guidance for teenage editors and start writing. I'm sure that there are some people who will find your advice useful.
— V = IR (Talk • Contribs) 21:50, 18 June 2011 (UTC)
Hmm—I think you've inspired me to write an essay called, Wikipedia:Assume bad faith. Oh no, there's one already. Good. ╟─TreasuryTagsheriff─╢ 08:18, 19 June 2011 (UTC)
I have no need to assume anything. You provided the ammunition all on your own.
— V = IR (Talk • Contribs) 23:14, 21 June 2011 (UTC)
I think it's a good idea. I know when I first joined I wasn't keen on reading through all the policies. Having a page where they are written in a more approachable manner would be helpful. Muskeato 22:17, 18 June 2011 (UTC)
That sounds fine, but aiming it at teenagers is a bit silly really, and would be very difficult not to sound patronising. The "nutshell" box at the top of policy pages usually sums them up quite well. AD 13:06, 19 June 2011 (UTC)
This page looks like it sums up every policy briefly. AD 13:09, 19 June 2011 (UTC)
FWIW, most of our policies and guidelines could do with re-writing to improve the prose. Collaborative editing has many strengths, but clear prose is not one of them. I tend not to bother reading any of them unless absolutely necessary. If I had read them before starting to edit, I wouldn't have started editing. DuncanHill (talk) 13:53, 19 June 2011 (UTC)
If our current policies are written at such a level that someone with a (partial) high school education has trouble reading them, that's a problem that needs to be fixed. If the issue is that people just can't be bothered to read them, making a separate page probably won't help much. Mr.Z-man 15:08, 19 June 2011 (UTC)
Undergraduate level education actually. I'm someone who loves to read. The problem with the policies is that the prose is just so dull and flat. DuncanHill (talk) 10:21, 27 June 2011 (UTC)
But they're not supposed to be interesting, merely informative and comprehensible. They're not targetted at people who would read them for leisure purposes; rather, they're aimed at people who need to read them in order to edit Wikipedia effectively. To take a comparison, instructions for flat-pack furniture are usually pretty dry. These sorts of writings are designed for people who need to read them, not who want to read them. ╟─TreasuryTagsheriff─╢ 12:26, 27 June 2011 (UTC)
If something is not interesting, people tend to forget the details and sometimes just skim. If you make things interesting, even funny, people are likely to remember what is said and want to read them. Comparing to a furniture construction illustration is not very useful here as that is something simple and straightforward that doesn't require much thought. The many wikipedia guidelines that people are expected to adhere to are another thing as people are expected to follow many of them, and you can't have people follow guidelines that they have never read. Granted some are common sense, but others aren't. Sir William Matthew Flinders Petrie | Say Shalom! 12:36, 27 June 2011 (UTC)
I've got to agree. Most of the policies are pretty clear, clearer than many of our articles. Individual cases ought to be handled through discussion on their talk pages leading to consensus for clearer expressions in the policy pages themselves. If there's a problem, it's because often something isn't notable under our criteria, but seems notable to a new editor. Even that's not really a problem with our policies, more that the new editor just went with "notable" in a common use, rather than in the way we use it in policies. Wabbott9 (talk) 23:08, 21 June 2011 (UTC)
We're working on improving stuff! Only just begun - but please see the headway we're making at
Wittgenstein's ladder approach, in all likelihood. Pesky (talkstalk!
) 04:36, 23 June 2011 (UTC)
What we need to remember is that the Wikipedia is the encyclopedia anyone can edit. There is no software than can identify an editor's age, and the ) 06:15, 23 June 2011 (UTC)

Wikipedia policy should be pretty clear:

  1. Teenagers are human beings.
  2. Human beings that have not been banned are welcome to edit Wikipedia.
  3. Therefore teenagers who have not been banned are welcome to edit Wikipedia.

That is all. —Tom Morris (talk) 10:07, 27 June 2011 (UTC)

...and that is relevant how? ╟─TreasuryTagOdelsting─╢ 10:17, 27 June 2011 (UTC)
The point is that I'm not totally sure if we need to spend time reworking Wikipedia:Guidance for younger editors. I guess I just don't see the point, unless we can find good reasons, preferably from said younger users, why specific outreach is needed, and those younger users can work to ensure it isn't condescending. —Tom Morris (talk) 10:22, 27 June 2011 (UTC)
The only reworking the Wikipedia:Guidance for younger editors needs is to drop it into a more appealing HTML skin, such as those being developed at the WikiMedia outreach project. Stuff for youngsters is stuff for youngsters and won't be perceived by them as patronising, as any teacher knows. Anyone much over 14/15 should be able to grasp the essentials from our other instruction pages or understand how to ask for help, and to take advice when they are given it. Kudpung กุดผึ้ง (talk) 14:29, 4 July 2011 (UTC)
I do appreciate the intention behind Oddbodz' original suggestion, and I wouldn't go so far as supporting a blanket statement that "stuff for youngsters won't (ever) be perceived by them as patronising". However, because this essay is extremely important - that there are significant numbers of 9 and 10 year olds, and large numbers of 11 and 12 year olds, editing Wikipedia, should make that instantly clear - I've already been seeking feedback on the essay and how it is perceived by its target age group. Some of the feedback is on the essay's talk page, some elsewhere and some still to be added. The feedback is from a wide spectrum of ages (the youngest person to offer feedback was 10, the oldest was 15) and from a wide spectrum of types of editor (ranging between those who have spent many months contributing productively and have never had any difficulties, to those who are currently indefinitely blocked and likely to remain so for some time).
What came out of the feedback, as regards the subject of this thread, is that none of it suggested that the essay as currently written is condescending. The closest was that the oldest child editor who gave feedback regarded a lot of it as being "common sense" - which I take to mean that someone aged 15 would already have been taught extensively about internet safety in other venues - but that editor also said the essay had been very useful to them in giving information that they'd not found elsewhere, and even quoted part of it that they'd found useful in practice. One thing I also noted, which again will be familiar to educators, is that even the older teenagers who gave feedback, saw the essay as having authority just because it was there and it looked official; for example they were judging their own past behaviour on Wikipedia in terms of how well it met the "rules" that the essay laid down.
So there is no issue with the essay being regarded as condescending by its target audience. I also agree with some of the comments already made, that young editors who have moved beyond (or feel they have moved beyond) the type of advice offered in the essay, can read Wikipedia's other documentation instead; and that if our documentation is difficult to use for an intelligent teenager, then we should be improving our documentation, rather than creating multiple miniature versions of it for multiple different age groups. (Though it would amuse me to write a "Guidance for elderly editors" essay aimed at the parts of that age group that have
talk
) 18:28, 4 July 2011 (UTC)

The issue of whether it is condescending apart —or should include undergraduates —, I struggle to understand how on Earth would a guide for teenagers be of any use: new editors start slowly —and not meticulously study the policy book as if for an exam— and would not end up there too easily, when I was welcomed years back I received a welcoming post with two-dozen links to pages each with more text on them than an PhD thesis: I read none of them and learnt facts as I went along. If this guide is instead to be used to beat up teenagers with edits on the lines of "I deleted all your interesting and helpful work according to

Wikipedia:Advice for younger editors" I think it would be a bad idea. --Squidonius (talk
) 20:42, 4 July 2011 (UTC)

Well yes you're exactly right, I think I got welcomed by one of the more detailed menus of links, and never ever read any of them from that that menu. Even some of the simplified graphical ones have a couple of dozen links on them, in fact I might start using W-screen just because it is less link-heavy but still has some links to help. I usually leave a welcome template and then leave a separate, very brief, personalised message asking them to look at the Guidance essay.
How to encourage people to actually read it? Well, the separate brief message will attract them more than the big menu of links. Plus if you ask for feedback, this is about empowering; it introduces them to the idea that it's not just a big homework resource that sometimes they can edit if they can put up with angry people reverting them all the time, but it's a collaborative community where their opinions are being asked for as well. Does that draw them in? Well yes, sometimes it does.
How to get more people (including teenagers) to take the time to learn this sort of material at an early stage? Make it more immersive.
Your point about the risk of it becoming a quick way to criticise younger editors is a good one.
talk
) 21:23, 4 July 2011 (UTC)

After the failure of yet another way to try and get discussions which don't need admin attention away from

WP:ANI (namely the Wikipedia:Dispute resolution noticeboard), it's about time that we stop BSing about the function of ANI, which is basically a "community forum" in every sense. It has become clear that ANI is basically a forum in which the community goes to bring any and all issues for discussion, as it is easy to use. Calling it as its current name is overly confusing for many people and doesn't make any sense. Hence, I (more formally) propose that Wikipedia:Administrators' noticeboard/Incidents be renamed to Wikipedia:Community forum. –MuZemike
20:37, 3 July 2011 (UTC)

Comment: I think its a relatively good idea but for on, I don't see the point of moving it at all. To me,
ANI does look like a community forum but the reason that editors come there is to request action that only administrators could do. Not even to mention what a pain in the ass it would be for administrators to move all those archives (seeing that move-subpages doesn't apply). ceradon
21:08, 3 July 2011 (UTC)
Comment I think the dispute resolution noticeboard is working quite well. Disputes seem to be getting resolved there. I think you do actually need ANI to handle matters involving admins misbehaving, but given in my experience ANI fails to do that so maybe getting rid of it is OK. I'd still like to keep the dispute resolution noticeboard though. -- Eraserhead1 <talk> 21:18, 3 July 2011 (UTC)
Comment Part of the problem to why stuff is still going to ANI that doesn't belong there is a) There's no notice at the top of the page to indicate there's an alternative place to take the issues and b) Issues which don't belong at ANI are being discussed there anyway, because no one is doing anything about these threads. It would take some admin enforcement, namely, closing threads that don't belong at ANI and pointing them to other forums, such as DRN. Otherwise, nothing is going to change.
The clock is ticking....
21:51, 3 July 2011 (UTC)
I would say that rather than just closing the threads, that the admins should move the conversation to the appropriate forum, and notify the poster that they have done so. But otherwise, I agree with you. The only way the problem is going to be fixed is to a) provide an alternative and b) make sure that people use it. ~ Mesoderm (talk) 22:06, 3 July 2011 (UTC)
Oppose because the Village Pumps are the actual community forums. 'WP:Community forum' should redirect to WP:VP. ANI is supposed to be for incidents (not chat, questions, or discussion) that require attention specifically from admins (not everyone). Renaming is only going to make it harder for people to figure out the purpose of that page. WhatamIdoing (talk) 23:48, 3 July 2011 (UTC)
Oppose pretty much for the same reason as WhatamIdoing - we need more streamlining and organising of boards, and clarifying and delineating what their function. This goes in the opposite direction. Sorry. I'd support of merging some boards though. Casliber (talk · contribs) 00:06, 4 July 2011 (UTC)
Oppose also as per WhatamIdoing. We need to stress more clearly across the site that ANI is specifically for issues that require admin comment and intervention. The current name of the noticeboard is the most apt. We should be more bold about redirecting the plaintifs to a more appropriate noticeboard. Kudpung กุดผึ้ง (talk) 13:54, 4 July 2011 (UTC)

Limit the Wikilove feature to specific user groups

I'm sure that this should be disallowed for non-autoconfirmed users, and only in an opt-in basis for non-admins, since Wikipedia isn't a social networking site.Jasper Deng (talk) 22:02, 30 June 2011 (UTC)

Oh, lighten up... Next thing you know we can't even say 'hello' anymore. Edokter (talk) — 22:25, 30 June 2011 (UTC)
Actually I think Jasper's right, and it's only a matter of time before you see why.
Fatuorum
22:28, 30 June 2011 (UTC)
We may not a be social network, but we are a community. I don't believe in blocking features for beginning editors, especially those that promote collaboration. Edokter (talk) — 22:35, 30 June 2011 (UTC)
That's not what you'll be blocking Edoktor; have you looked at the "make your own" option?
Fatuorum
22:48, 30 June 2011 (UTC)
Yes, I suspect we'll come to rue that one.--SPhilbrickT 01:49, 1 July 2011 (UTC)
That was a seriously Californian off-the-wall crazy idea. I quite like it though, better than all the gooey "love" stuff.
Fatuorum
01:58, 1 July 2011 (UTC)
Obviously jealous of California MF? The 7th largest economy in the world. Almost all development and manufacturing of anything important in medical devices, telecommunications, social networking (though I might consider it a negative), Wikipedia (OK, another negative), automobile design, venture capital, computer devices, and gorgeous, intelligent women. In other words, without California, the US would be a backwards, Republican-run, anti-science, fascist religious state, pretty much laughed at by Californians. And we wouldn't let you have our excellent pot. OrangeMarlin Talk• Contributions 03:09, 1 July 2011 (UTC)
Why would anyone be jealous of California? A state that appears to have more lawyers per square mile than any other place on Earth?
Fatuorum
03:14, 1 July 2011 (UTC)
Actually, it's 12th on the list of US states for active attorneys per square mile, being preceded (in order) by New Jersey, Massachusetts, Connecticut, New York, Rhode Island, Maryland, Delaware, Illinois, Pennsylvania and Florida. Additionally, the District of Columbia and Puerto Rico both have far more attorneys per square mile than California. WhatamIdoing (talk) 14:51, 2 July 2011 (UTC)
The reason I opened this thread was because of some recent trolling incidents with things related to Wikilove (like this IP). Besides, many non-autoconfirmed users don't know the meanings of barnstars, etc. Therefore, I think it's reasonable if non-autoconfirmed users can opt in to Wikilove by applying for Confirmed status. It's too risky to allow IPs to opt in.
"...can we all get along?" Bus stop (talk) 04:17, 1 July 2011 (UTC)
I'd like to point out that Orangemarlin is wrong about, well just about everything to do with California. Not only is Wikipedia NOT from California, worse- it's from Florida; the state of NY has developed more medical devices (in particular the
Sematech the international consortium of computer chip companies is in Albany, New York; and of course Wall Street, Madison Ave, and the news headquarters of all major networks is in the City of New York (which is twice the population of California's largest city, while being in a smaller geographic boundary). Tech Valley in Upstate NY is in a better healthier economic condition than Silicon Valley. Oh, yea and California has a bigger budget problem than just about any other state. Let California go its own way.Camelbinky (talk
) 01:04, 6 July 2011 (UTC)

Opt out?

How about a way to opt out of receiving these unwanted advances? Apparently there's a way to opt out of the button to give these silly notices, but recipients has no such option.

talk
) 02:14, 1 July 2011 (UTC)

IMO the opt-out checkbox should block both sending and receiving -- it's highly unlikely that someone would opt out from sending but want to receive. For users who've disabled it, we could visibly disable the heart symbol to other users to make it clear what's going on.
I think it's inevitable that a small but vocal faction of users will dislike this feature, and this is a simple way to mitigate conflict about it.--
*
02:54, 1 July 2011 (UTC)
Well, if Wikipedia is anything like Facebook, then they will opt us in automatically, and make it impossible to figure out how to opt out!  :) OrangeMarlin Talk• Contributions 03:10, 1 July 2011 (UTC)
It is impossible to truly opt out. It is possible to make the button not appear to a user that has opted out; I can think of one fairly simple way that would work. But since anyone could manually type out any message they want I don't see a point in opting out of receiving the messages. Removing the button to send, on the other hand, could be useful and indeed I have done that for myself. Prodego talk 03:26, 1 July 2011 (UTC)
I think removing the button for opted-out users is good enough, since most of the Wikilove materials are hard to find for users who aren't familiar with what they are.Jasper Deng (talk) 04:09, 1 July 2011 (UTC)
It sounds like people also want an automated reply. I guess appropriate ones might be to
  • A rabbit icon 'I freeze like a rabbit when given wikilove'
  • A boiled rabbit icon 'I get obsessed when given wikilove, look out'
  • A rabbit pie 'We can share a meal and be friends'
I'm sure the Wikipedia software could look for a list of automated responses associated with a user and pick out the appropriate one for edits about to make to a users page so these could be shown in the preview. Hmm if they change their edit correspondingly then a different message might come out - one could almost work in a whole
Dmcq (talk
) 07:58, 1 July 2011 (UTC)

Proposals for closing projects/Closure of Old English Wikipedia

Per the new Meta:Closing projects policy, I have proposed Ang Wikipedia, the Old English Wikipedia, for deletion. My reasons are numerous, but the main issue is that information on a dead language makes sense, information in a dead language does not. Please voice any opinion at Meta:Proposals for closing projects/Closure of Old English Wikipedia. ▫ JohnnyMrNinja 06:10, 4 July 2011 (UTC)

why are you posting this here? Choyoołʼįįhí:Seb az86556 > haneʼ 09:29, 4 July 2011 (UTC)
Perhaps because both this project and that project's languages include the word "English" in them. Just a shot in the dark. Killiondude (talk) 06:37, 5 July 2011 (UTC)

So would you then wish to close down the Wikipedias in Latin, Sanskrit or Old Church Slavonic? I respect your view, but I disagree - I think it is of interest to keep these Wikipedias. ACEOREVIVED (talk) 14:30, 5 July 2011 (UTC)

"Wikipedia is not a junkyard", but to get to a different language you actually have to look for that language (i.e. it is not in the way), so there is no harm in keeping it and, contrary to what is said above, one it is actually useful in learning the language. Just because Mitsubishi, Toyota and other car companies have no qualms in butchering Latin (viz. plural of Prius), it does not mean dead languages are useless waste of a dozen megabytes out of terabytes. --Squidonius (talk) 18:54, 5 July 2011 (UTC)

Why do you not say "Anglo-Saxon Wikipedia" which is the name given to this Wikipedia at List of Wikipedias?ACEOREVIVED (talk) 19:54, 5 July 2011 (UTC)

For discussion about this proposal, follow the link above. Writing here will just ensure that nobody sees your comments. Jafeluv (talk) 20:12, 5 July 2011 (UTC)

Retitled from "Revisiting Wikipedia:Requests for adminship/Bureaucrat Unchecking"

Following the successful RFC at Wikipedia:Village pump (proposals)/suspend sysop rights of inactive admins, some editors (including myself) are wondering whether we should revisit the Wikipedia:Requests for adminship/Bureaucrat Unchecking proposal to give bureaucrats the technical ability to perform the removal of the tools for inactive admins as required by the aforementioned RFC. As such I wanted to ask here for input whether to start a new RFC on this proposal. Regards SoWhy 21:23, 4 July 2011 (UTC)

I for one would support this. Every other user right granting is reversible by the person who did it. In fact, everything admins/bureaucrats do is reversible and this is the only exception. It is only an accident that bureaucrats do not have this ability. AD 21:29, 4 July 2011 (UTC)
I have supported this proposal in the past and would support it again. Acalamari 21:31, 4 July 2011 (UTC)
Yes, of course crats should have this ability. → ROUX  21:35, 4 July 2011 (UTC)
Sounds good to me. -- Eraserhead1 <talk> 21:42, 4 July 2011 (UTC)
I supported this before, and still do. Since desysoppings are now going to start happening more frequently with the inactive admin removal process, it makes even more sense to have trusted local users do it instead of going to the stewards every time. We can assume bureaucrats to have knowledge about the policy and standard procedures, something of which many stewards may be unaware. Many Wikimedia projects have already added this right to the bureaucrat package: meta, simple.wikipedia, en.wikinews, hi.wikipedia, fi.wikipedia, etc. While bureaucrats weren't exactly selected for this task, I have no problem trusting them with an additional responsibility which is closely related with their current job. Jafeluv (talk) 23:38, 4 July 2011 (UTC)
  • Lest we get ahead of ourselves, rather than expressing support for the idea itself, perhaps we should discuss how an RfC would proceed. Past discussions have shown considerable support for the idea, but have foundered on claims that consensus was insufficiently strong, the question posed wasn't clear enough, and/or participation wasn't broad enough. Therefore, I would recommend the following specific steps: 1) Start a clear RfC on a distinct question. For example, "Should bureaucrats be given the technical ability to remove the admin bit?" No additional options (such as ability to remove the bureaucrat bit) or mention of other topics that have confounded past discussions (such as community de-adminship). 2) Advertise the RfC widely. Notices on the relevant Village Pump pages,
    Signpost. If possible, get a watchlist notice for it. 3) Hope for as clear a consensus as possible. --RL0919 (talk
    ) 23:56, 4 July 2011 (UTC)
I would support this if it is limited to, and only, to procedural desysopping as per the new '12-month' resolution, To succeed, The RfC proposal should be as short and concise as possible, and should not only state what it is for, but also state clearly what it is not for - otherwise there will be a pile on of 'views from User:X' and alternative suggestions, and requests for additional tool-removal circumstances. The RfC should be widely advertised. Kudpung กุดผึ้ง (talk) 01:12, 5 July 2011 (UTC)
What about self-requests and Arbitration Committee remedies, both of which go to m:SRP at present? –xenotalk 01:41, 5 July 2011 (UTC)
@Kudpung: I think that's exactly the problem RL0919 mentioned. Imho, the RFC should only be about the technical ability to do so. We can discuss specific cases, such as procedural desysopping or the cases xeno mentions once there is a consensus that crats should have the ability. Like with any other userright, the question whether a group should have it (like the delete-flag for admins) is separate from the question in which circumstances they may use it (e.g.
WP:DEL for the delete-flag). Regards SoWhy
07:33, 5 July 2011 (UTC)

Set up TWO RFCs. Seriously, it's the only way to stop the issue of policy polluting the discussion on the technical ability.

talk
09:44, 5 July 2011 (UTC)

True but I'm unsure as to how to have them open at the same time, since the second RFC requires the first to be successful to make any sense. And if we cannot have them open at the same time, how can we stop people from polluting the first RFC with discussions that should be held in the second one? One idea would be to ask one or more respected neutral editor(s), possibly from ArbCom, to moderate the RFC and remove all discussion that's outside the RFC's scope but I'm unsure whether all editors will accept such moderation... Regards SoWhy 10:34, 5 July 2011 (UTC)
We can perfectly well have the second open at the same time as the first, it's by far the simplest solution. All the second RFC needs to do is say at the top something like This RFC is about the policy which will be required if
talk
12:06, 5 July 2011 (UTC)
Indeed, recently parallel discussions were running simultaneously on adding the technical ability for CU/OS to function without administrative rights concurrent with the more general policy discussion on whether adminship should be a prerequisite for those roles. –xenotalk 12:23, 5 July 2011 (UTC)
Good points, I'm convinced. As such, I started two RFCs at:
As I am not experienced in creating RFCs, I would invite everyone here to help expanding those pages with proposals and structure, so we can start those RFCs soon. Regards SoWhy 13:43, 5 July 2011 (UTC)
I added some background and structural tweaking to the technical one. I think that will be the easier of the two since it is a pretty simple yes/no situation. The policy one may be a bit more complicated, since potentially people might have different opinions on bureaucrats acting in different cases (self-requests vs. ArbCom rulings vs. inactives). We may want different sections to discuss each to make consensus easier to determine in case it differs from one situation to another. --RL0919 (talk) 21:16, 5 July 2011 (UTC)
I created a separate section for each situation where a removal might be required, so that people can support one situation while opposing others. Then, when the RFC is closed, all situations with consensus in their favor can be added to the policy. Regards SoWhy 21:25, 5 July 2011 (UTC)