Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Mobius Clock (talk | contribs) at 10:18, 8 May 2010 (→‎Re-upload Commons artwork that's been deleted by Jimbo Wales: support). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
New ideas and proposals are discussed here. Before submitting:

{{NowCommons}} deletion bot

Hey there wikipedia! I wrote a bot to find images on wikipedia that also exist on Wikimedia Commons that have the same name and Sha1 hash tag. I was hoping for some sort of community consensus to run an adminbot to delete these images off of en.wikipedia.org. This should help with the 12 images currently pending admin review. Please note the bot will only act if it determines the images are identical and have the same name. Thanks! Tim1357 (talk) 19:25, 17 April 2010 (UTC)[reply]

How would it determine that the transfer was done properly, including proper attribution? You also need to consider that {{c-uploaded}} and other protected images must not be deleted, and you need to be an admin to run an adminbot. PleaseStand (talk) 18:14, 18 April 2010 (UTC)[reply]
As having processed many of the deletions of recently bot tagged images, I have to advice against an adminbot. Mistakes are common and many of the transfers require significant additional verification of a human. I can only ask that more admins to help going trough all the CSD nominations. (over 10000 are left). —TheDJ (talk • contribs) 18:36, 18 April 2010 (UTC)[reply]
Bot could flag any hash mismatches at least, and maybe tag hash matches as checked. Could the bot assist with other verification time-saving? Rd232 talk 23:28, 18 April 2010 (UTC)[reply]
There are already 13000 images tagged by bots for being on commons or being transferred to commons. But you still have to double check for everything, since bot and usernominations are all mixed up, so you don't know what work has gone into the various nomination. —TheDJ (talk • contribs) 13:37, 22 April 2010 (UTC)[reply]
In which case, there's a possible improvement there, no? As part of the tagging, provide whatever info the bot came up with. Rd232 talk 15:45, 24 April 2010 (UTC)[reply]
Out of curiosity, is it possible to somehow get the SHA1 hash of a file on Wikipedia without downloading the whole file? If not, why would you compare hashes instead of just directly comparing the file contents? —Bkell (talk) 20:45, 20 April 2010 (UTC)[reply]
It is possible to retrieve the SHA1 hash of an image using Wikipedia's API. PleaseStand (talk) 22:30, 20 April 2010 (UTC)[reply]
  • Please, no adminbot for this. Just because {{NowCommons}} is on them, doesn't necessarily mean they should be deleted. Some transfers aren't correct and by deleting the file pages, it makes it harder to check it. Thus, admins should check them first and take care of problematic files. A bot is too stupid to deal with this. --The Evil IP address (talk) 22:53, 1 May 2010 (UTC)[reply]

Reducing Vandalism

I think an effort should be made to reduce the vandalism present in some areas of Wikipedia, especially articles about schools. These are regularly vandalised by students of other schools, and are harder to act on due to the "lenience" shown to shared IPs (including educational institutions). Hence, I am proposing that they be semi-protected so that IP users do not edit them. I would also like to raise a concern on the rising number of pages on Wikipedia that just don't belong. For example, there seems to be too many pages on unimportant people, such as relatively unknown actors/actresses in the porn industry (who have not achieved anything of notice) or relatively unknown films (especially foreign ones-those should be placed on their respective language Wikipedias). If steps are taken to solve these problems, I am sure that vandalism will not occur on such a regular basis. Deagle_AP (talk) 08:19, 23 April 2010 (UTC)[reply]

The Spring makes everything new :) See: Wikipedia:Village_pump_(miscellaneous)#Flagged_protection:_update_for_April_22, Flagged protection on English Wikipedia is coming soon now. I'm expecting to lower the vandalism volume :) --Chris.urs-o (talk) 08:35, 23 April 2010 (UTC)[reply]
That introduction would help, but I fear it may complicate the system. After all, creating a new "reviewer" usergroup takes time to put into place, doesn't it? Deagle_AP (talk) 08:40, 23 April 2010 (UTC)[reply]

Well, I do not know the details. German Wikipedia uses Flagged Revisions as default and it is quite happy with it. I think since 2008, but I can't find the citation. English Wikipedia wants some specials on the feature ó.O A vandal wants to publish on www his "Hello", "I was here", "'XXX' is gay" and so on. So, if it is not published, then it is not interesting anymore. And, if the volume goes down, it is easier to tackle. Some vandals are changing numbers, this is destroying Wikipedia, there is no choice anymore. Quote (Wikipedia:Flagged revisions#Release history): "On May 6, 2008, Flagged Revisions were enabled, first for a test, on the German Wikipedia." --Chris.urs-o (talk) 09:11, 23 April 2010 (UTC)[reply]

Re your point about putting "foreign" films on the relevant language wikipedias. Firstly EN Wikipedia is global - nowhere is foreign to us, and though I can see a temptation to only have articles about say chinese language films on the Chinese wikipedia, we need to remember that films get dubbed and subtitled and shown in many markets other than the ones for their language of filming, and the English language Wikipedia has taken on a global role because of the huge numbers of people who have English as a second language; Also many actors work across multiple languages, so someone reading up on a particular actor might well want to know about other work they have done even if its in a different language. ϢereSpielChequers 10:02, 23 April 2010 (UTC)[reply]
I agree, but with some less known films that have simply not gained sufficient recognition, I believe they should be removed, as Wikipedia-EN is an English encyclopedia, and those articles do not satisfy the requirements to be placed in a proper encyclopedia. Deagle_AP (talk) 10:37, 23 April 2010 (UTC)[reply]
The point is that if someone is notable for the Chinese encyclopedia, then they should be notable here using the same references. That the refs are in Chinese is irrelevant. And as far as reducing school vandalism, IMO they should be harder on blocking the school IPs that do cause trouble instead of preemptively semi-protecting an article that may not need it (though FRs would be great of course). ♫ Melodia Chaconne ♫ (talk) 14:11, 23 April 2010 (UTC)[reply]
Wikipedia-EN is an English-language encyclopedia, but it is not an English encyclopedia or an encyclopedia for the Anglosphere. If a film "simply [has] not gained sufficient recognition" to meet our notability standards, then that is a valid reason to delete the article about it—that deletion, however, must be completely independent of whether the film is an English-language film. -- Black Falcon (talk) 17:14, 23 April 2010 (UTC)[reply]
Good point there, Black Falcon. However, I think Wikipedia does need trimming-some articles are hardly ever read, and only serve as potential space for vandalism. Wikipedia at the moment seems to be leaning too far into the creation of unnecessary articles. Take the first example of the biographies of unknown actors (especially in the adult industry). These simply don't have any depth, and give restricted information on the person's life, achievements, etc. other than their date of birth, height and name. I believe these articles of major concern, because they simply don't meet the standards of an article for inclusion in an encyclopedia. Also, the schools' IPs cannot be simply blocked, because we seek to promote Wikipedia as an accessible source of information, and sometimes students can contribute constructively i.e. me (hence protecting popular target pages is better). Deagle_AP (talk) 12:00, 24 April 2010 (UTC)[reply]
Hi Deagle AP, Firstly there is no deadline, so by the nature of our process there will always be some articles that unfinished. However we do have deletion processes, and we delete hundreds of thousands of articles every year. I'm unclear from your comment whether your concern is that there are always some articles that merit deletion under our current processes but have yet to be prodded or tagged for deletion, or whether you think that Wikipedia:Deletion policy should be tightened with a view to accepting fewer articles. If the former please get stuck in and help us remove some of the spam and fancruft, if the latter I suggest you make a specific proposal at Wikipedia talk:Deletion policy or Wikipedia talk:Criteria for speedy deletion - but you might want to read the archives first as many proposals to either tighten or loosen the policy have been rejected in the past. ϢereSpielChequers 09:47, 30 April 2010 (UTC)[reply]
Yes, I was referring to the latter. However, since this is not a new issue and the need is not urgent, I suppose we'll wait until there really is a problem. Some current articles, however, do need prodding, but I believe there will be some opposition for some pages I have in mind. Nevertheless, we must watch what articles get created...11:18, 30 April 2010 (UTC)
Wow, did I just read this? "I think Wikipedia does need trimming-some articles are hardly ever read, and only serve as potential space for vandalism." A suggestion for mass deletion on the basis of readership on the grounds that an unread article is a potential hotbed for vandalism?!?! It's really time to get the Inclusionists organized and loaded for bear. This is perhaps the single most dangerous idea I've ever bumped into during my time at WP. Carrite (talk) 11:54, 5 May 2010 (UTC)[reply]

Mass rescale of FU images.

Hey there Wikipedia, I am here to ask for consensus to run my bot task to rescale fair use images that are blatantly defying NFCC 3.b, which states

Low- rather than high-resolution/fidelity/bit rate

should be used. From there, I used Wikipedia:Fair use/Definition of "low_resolution" as a hint to which sizes were acceptable, but the page is tagged as historical, and admittedly outdated. Is this page/policy still relevant to the going consensus?

The proposed bot task, right now, is to resize images where (height×width)≥600×600 into images that are the same proportion, only where height×width = 400×400. (trial example). And then tagg with {{reduced}} Tell me what you think! Tim1357 (talk) 12:03, 23 April 2010 (UTC)[reply]

Can bots do it? I thought that the only way to modify the images was to actually download them, open with an image editor, and upload the result as a new version of the file. MBelgrano (talk) 13:45, 23 April 2010 (UTC)[reply]
A bot could just use ImageMagick for batch rescaling, the same way that Mediawiki does it, though with different settings. — Gavia immer (talk) 17:34, 23 April 2010 (UTC)[reply]
If there is consensus to do this task by bot, can the bot ensure that both the height and width are at or exceed the minimum number that is chosen (e.g., if 400px is the minimum, then the trial example should be 400x534)? -- Black Falcon (talk) 17:21, 23 April 2010 (UTC)[reply]
One number that I've seen floated around is that images at 0.1MP (megapixels) or less tend to not cause problems, so maybe that's a better measure (to go along with BF's commment). That is, assuredly if 0.1MP is less an issue, 0.3MP or higher (about 550x550px square) will definitely be too high.
However, I strongly suggest you need to offer an opt-out keyword for some images, as through some template that users can add to a page, to assert the reasoning why they are above low resolution. Your bot can skip those images, but we can then use "what links here" of the template to find those images and review the rationales on a case-by-case basis for the larger size. Thus, if you are going to enact this bot, give people a 2 week period or more to place this tag on their images they need to keep at the higher resolution. --MASEM (t) 17:26, 23 April 2010 (UTC)[reply]
0.1MP (megapixels) has been aired in the past and never accepted as definitive. It is even less appropriate now that higher screen resolutions have seen the upping of the thumbnail default size. 550 x 550 pixels at the standard print resolution of 300 dpi would result in a printed image 1.8" square, so hardly something to cause any significant commercial jeopardy. An image which is reduced to a size that loses key detail will weaken a fair use claim for educational purposes, as it won't be educational if you can't see what's in it properly. Ty 17:45, 23 April 2010 (UTC)[reply]
First, again, 0.1MP would not be the limit for the bot, this is just a rough point where more NFC (let's avoid calling it "fair use" as that's not the standard on WP) would not be considered to be too big (though again, there are exceptional cases). Also, remember that most NFC is further scaled within articles due to being a thumb or other size.
Obviously, the question to ask is what is the initial material available in in terms of resolution. A 3000x3000 image reduced to 500x500 is likely low resolution, and the point you brought up - if fundamental details are lost in that - is still a consideration if that's too low. That's why I'm suggesting a tag to detail when this type of case exists, which effectively is a part of FUR to explain why that resolution was used. However, I will still contend that there is a lot of FUR (mostly of covers and screenshots from copyrighted works) where a resolution of ~0.1MP (which would allow for images of 320x240 for most 4:3 aspect ratios works) is sufficient to show what details are needed, particularly for live-action screenshots where fuzziness is ok. Obviously, when you get to less common types of FUR this is where the exceptions are needed. --MASEM (t) 18:00, 23 April 2010 (UTC)[reply]
Oppose. There is no accepted definition of low-res, and there shouldn't be, since some things (e.g. maps / charts / other things with fine detail or embedded text) have to be relatively larger to serve their encyclopedic purpose. There is no crisis of external fair use complaints, so I don't see the need to impose arbitrary limits. A human uploaded the image, and assuming it is tagged correctly then a human already wrote a fair use rationale. Proposals like this assume that an arbitrary limit is better than the existing human judgment about what size is appropriate, and I don't see a good case for that in general. Even though there are undoubtedly some images that should be shrunk, this should be dealt with by human judgment not machine logic. If one wants to create lists / categories / tags for unusually large fair use images, then I don't see a problem with that, but I'd say bulk resizing is not okay. Dragons flight (talk) 18:17, 23 April 2010 (UTC)[reply]
I couldn't agree more. I've also never been a particularly big fan of the (somewhat arbitrary) limit on Fair Use images; when we get an image straight from the copyright holder, I don't see why we should have to shrink it (versus stuff from scans, where the final size is determined by the person uploading it). EVula // talk // ☯ // 18:25, 23 April 2010 (UTC)[reply]
Remember, WP's bound by non-free content, not fair use; it is purposely more restrictive to try to maintain a free content encyclopedia. To that end, we use the best resolution that still serves the reason to allow for non-free use (that it is critical to understanding the article it is in) while minimize its size. Where that point is is an arbitrary thing for each image, certainly, but clearly something that is huge (well well above this 0.1MP consideration) needs to be really justified to be that large resolution. That doesn't make it wrong, just that we need clear evidence that it's needed; thus, as I've pointed out, we simply need to allow for image uploaded to tag images that are above this critical size as being necessary at that resolution. That rationale can be challeged, for sure, but the bot won't touch it. I'm also thinking that the bot should be smart enough to recongize specific license tags, and make certain changes based on that. With the more regular tags (screenshots, etc.) we can be certain they should be able a given size, compared with copyrighted promotional material. --MASEM (t) 18:57, 23 April 2010 (UTC)[reply]
The uploader could have already written an explanation of why a large size is necessary / appropriate, but only a human would be able to read it. And even if they didn't, the required size still might be obvious if text or details become illegible when shrunk. Since a bot can't evaluate such factors, it shouldn't try to resize images. Again, tagging large images might be okay, but you need human judgment to determine sizes. Dragons flight (talk) 19:13, 23 April 2010 (UTC)[reply]
Sure, that all is reasonable. But I also think that there is a point where if an image (and, if possible, an image of a certain license) is well above a given size, there's a potential problem. It could be a perfectly valid use, no question; at worse, we could simply have the bot note and log these, and then sent to human review to determine the appropriateness of each in question.
What may be useful to determine if such a bot is needed is to have a read-only bot simply parse through all NFC, and generate historgrams of image sizes, possibly broken down by license, and determine if there is really a large number of overly larger images to necessitate a bot for resizing or not. --MASEM (t) 19:36, 23 April 2010 (UTC)[reply]
Oppose, largely per Dragons flight. The term "low resolution", particularly as it applies to something like the fair use criteria, is highly subjective. Let us not forget that all images are not created equal; while one image may pass the criteria easily at an arbitrary resolution of, say, 300x300 pixels, another image of a different nature may still run afoul of policy. I could see some utility in a bot/script to create a list of images that go above an arbitrary resolution for review, but the decision on whether or not an image needs to actually be resized should be left to the discretion of human editors. Shereth 20:41, 23 April 2010 (UTC)[reply]
  • Oppose. Sorry, but the last thing we need is another copyright-police bot blundering around and messing things up. 86.136.26.144 (talk) 23:56, 23 April 2010 (UTC).[reply]
  • Oppose. As noted above, I have issues with the bot trying to make a call on whether an image is "too big." However, if there is some measure (0.33 MP, 600×600, etc.) that is an indicator of being too big, it would be reasonable for a bot to identify and tag those images for humans to evaluate. —C.Fred (talk) 00:03, 24 April 2010 (UTC)[reply]
    The main problem with this is that a human has to download the image, open it in an editor, rescale and re-upload, which is pretty slow and an annoying amount of work. A much better solution is for humans to tag images for resizing, then a bot can come along and do all the tedious hard work. Possibly this can be the same template as the one you describe, and a human just comes along and adds |checked=true or similar. OrangeDog (τ • ε) 11:30, 26 April 2010 (UTC)[reply]

Before we could even discuss a bot sensibly, we'd still need a list of images to look at. Tim, could you start by making a list of the images you are thinking of? The number and size of such images would be important factors in evaluating a bot job. — Carl (CBM · talk) 12:10, 26 April 2010 (UTC)[reply]

  • Oppose. Another drastic solution anxiously seeking a real-world problem. Catch the violations at the gate or challenge them individually when you run across them. No one-size-fits-all ex post facto destructive "fixing" via bots!!! Carrite (talk) 02:24, 4 May 2010 (UTC)[reply]

List of large non-free images

I put a list at User:CBM/Sandbox2 with images that are non-free and have either width or height over 1000px. It's slow but it does load. Browsing that, I see at least a few things right away:

Having a bot that would do the reduction upon demand would be nice. I could certainly write one, but maybe it's a project for someone who is still cutting their teeth. — Carl (CBM · talk) 12:58, 26 April 2010 (UTC)[reply]

The Woolworth image is an SVG. It doesn't have a pixel size. Ongoing consensus has been that SVG's are okay, so long as they don't contain more detail than is needed for the article, or for the size of a PNG that would be acceptable. The issue here is that we should be able to set per-image a preferred render size, or per-image a maximum render size, for the image pages for non-free SVGs. But that might need a software patch. Jheald (talk) 17:00, 26 April 2010 (UTC)[reply]
There were about 200 svgs on the list. I removed them, leaving the other ~6000. A different example of an excessively large logo is File:Logofinal print.jpg. — Carl (CBM · talk) 19:06, 26 April 2010 (UTC)[reply]

The real question here: is there a reasonable threshold size so that an image over that size needs to have a clear reason to avoid being reduced? — Carl (CBM · talk) 19:06, 26 April 2010 (UTC)[reply]

Why the obsession with reducing things after the fact? Graphic uploads are already, and I say this without a shadow of a doubt, the most hyper-analyzed, micro-managed aspect of Wikipedia. Images have run the gauntlet already, and now we're supposed to be all concerned because somebody has the technology to do this or that and is itching to use it?!?! LEAVE THINGS ALONE. DON'T FIX WHAT AIN'T BROKEN. A 1200 dpi 9 inch by 5 inch scan of a newspaper halftone photo is "low resolution" relative to the original photograph, even if the file size is as big as the moon. There is no one-size-fits-all magical threshold, particularly one that needs to be unilaterally and retroactively implemented by a bot. Carrite (talk) 15:35, 4 May 2010 (UTC)[reply]
I'm sorry, but a 1200dpi 9x5 image is obviously not "low resolution": it's 10,800 pixels wide. My current thought is to reduce the worst ones manually. If we did have a general rule, then a bot could be run. But even without a general rule, it's obvious that File:Sjl poster.jpg does not need to be 2,400 pixels wide. — Carl (CBM · talk) 16:12, 4 May 2010 (UTC)[reply]
A high resolution scan of a low resolution image would indeed be low resolution relative to the original image — that's my point. There is no magical file size at which point "low resolution" becomes "high resolution." There is no problem that needs fixing here, or rather, this is a matter where someone thinks they see a bug next to the house and wants to build an effective flamethrower to kill it because they like fire. No offense, but just because one has programing skills and the capacity to do something doesn't mean one should be making mass DESTRUCTIVE edits of already approved files... Carrite (talk) 12:04, 5 May 2010 (UTC)[reply]
What do you mean by "approved"? There is no approval process for files; problematic ones are just cleaned up as people find them. — Carl (CBM · talk) 15:30, 5 May 2010 (UTC)[reply]
One thing that you could do is ask Tim to modify his current bot to run so that it gets data from a template placed on image pages by users that want to rescale images. That would appease most users, those images that need rescaled get it done easily, and its reviewed by humans. βcommand 16:52, 4 May 2010 (UTC)[reply]
Which bot is that? — Carl (CBM · talk) 17:01, 4 May 2010 (UTC)[reply]

< Rather than agreeing on a standard size for a bot to reduce the size of non-free images, we could create a template where people need to specify {{large-non-free|bot=yes|widthnewpercent=60}} or something – manually specify that the width needs to be x% smaller? This would be better than nothing. Just a thought... ╟─TreasuryTag►duumvirate─╢ 15:33, 5 May 2010 (UTC)[reply]

Yes, I think that's the idea. To make a bot that does the resizing on demand, based on some sort of template. — Carl (CBM · talk) 15:42, 5 May 2010 (UTC)[reply]
I go back to my original suggestion, and emphasis it more: it is not that high resolution (a total pixel count greater than "some number") images are necessary bad, and in some cases are necessary to prevent degradation of the image. But, that said, one of the points that we ask in NFC rationales is to address if the image is low resolution - both with respect to the original image with respect to conveying the information. When I look at some of these "large" images, the "low resolution" rationale is a joke (the TV show one above says "yes" to the FUR template "low resolution?" question.) The thing is, I bet that 90% of our NFC content can be classified into a limited number of media types - things like covers and screenshots - which we can ensure what the original size is, and more importantly, what it shouldn't be.
I would like to see a three step process. In the Correction phase, wiki-wide announcements would inform uses that in x weeks (2?) a bot will run through and tag images that are outside certain size parameters (left to be determined for now), but that if you do have an image that needs to be that size, it can be tagged with a template that begs for more information about the high resolution aspect, and that if present the bot will ignore tagging. After this period, the second phase would let the bot tag images and inform their uploaders of the large size and that either they should reduce it themselves, add the high resolution template, or it will be reduced (by a human) in x weeks. After that, all images tagged by the bot that haven't been resized or tagged with the template will be resized by editors to what they feel is the right size. There would also be a period to review all images that use the high resolution template to verify that someone isn't BS'ing it, sending questionable uses to a non-free content review if the resizing issue can't be resolved. --MASEM (t) 15:41, 5 May 2010 (UTC)[reply]
Rather than doing everything at once, looking at specific categories might be productive. For example, just album covers, or just magazine covers. For example, this image File:Incontrolable.jpg actually says "No" in response to the low resolution question. — Carl (CBM · talk) 15:52, 5 May 2010 (UTC)[reply]
I'd still would start with one that uses a rather high level (say, more than 1 megapixels) to go through all images - which I suspect would only number in the 100s or less. A second round can focus on images from specific image categories like album covers which possible exceed, for example, 0.3 megapixels (eg greater than 500x500) for album covers. --MASEM (t) 16:26, 5 May 2010 (UTC)[reply]
According to a quick toolserver query, there are over 3000 non-free images over 1 megapixel. Of course not all of those need to be reduced. But there are 584 album covers, 363 logos, 279 book covers, 172 "publicity photographs", and 70 video game screenshots. Presumably most of those do not need to be a megapixel in size. — Carl (CBM · talk) 19:37, 5 May 2010 (UTC)[reply]
Certainly that ~1/3rd of the >1MP images are highly likely to be out of whack and we probably can fix those, but I think it's completely fair to check the other 2/3rds of those >1MP images and simply double check if they need to be that large. And we still have to consider things like album covers that exceed 0.3MP (again, this is not saying no album cover can be over 0.3MP, but that's the exceptional case). So I still think either a two-pass or a two-pronged approach (tackling both tasks at the same time) is doable once we set limits on what is reasonably expected for the more common image styles. --MASEM (t) 19:43, 5 May 2010 (UTC)[reply]

Ability to edit edit summary

I would like to propose a feature to allow, for a limited period (say five minutes), the user or IP address who created an edit summary to edit that summary. It's really annoying when one has some finger trouble and writes something nonsensical and then can do nothing about it (other than make a dummy edit with a "what I really meant to say was..." summary). 86.136.26.144 (talk) 00:01, 24 April 2010 (UTC).[reply]

It may work with smaller Wikis, but it won't work on Wikipedia - the rate of recent changes is at least 50 edits per minute at some points, leaving only one attempt to get your edit summary correct for those doing quick patrols. If you want to clarify your edit summary, use the Talk page instead. --Sigma 7 (talk) 00:09, 24 April 2010 (UTC)[reply]
I'm sorry, I don't understand. What does the rate of edits have to do with anything? And what do you mean by "leaving only one attempt to get your edit summary correct for those doing quick patrols"? 86.136.26.144 (talk) 01:01, 24 April 2010 (UTC).[reply]
It's not a bad idea, although we'd have to wait for someone to comment on it's technical feasibility. Prodego talk 01:16, 24 April 2010 (UTC)[reply]
I think I see where Sigma 7 is going: one of the restrictions on changing your edit summary should be that it's the most recent edit. One, that's probably more easily implemented than a five-minute limit, and two, it avoids a situation where a user changes an edit summary when there's been an intervening edit. —C.Fred (talk) 01:18, 24 April 2010 (UTC)[reply]
I see the appeal - but what about the risk? Vandals can play around with edit summaries... Rd232 talk 01:31, 24 April 2010 (UTC)[reply]
As I stated, I'm proposing that only the original editor can change the edit summary. The only loophole might be if it's extended to IP users. Someone with a dynamic IP wanting to cause trouble could keep reconnecting (thereby getting a new IP address each time) and keep looking for recent edits by someone who had previously had the same IP. If they were still within the five-minute window that I suggested then they could change someone else's edit summary. My feeling is that this is low risk, but not impossible. 86.136.26.144 (talk) 01:44, 24 April 2010 (UTC).[reply]
I hadn't even thought of that - just being able to edit your own edit summary could be troublesome enough. Hence previous discussions of this have always ended up "not going to happen". Rd232 talk 08:56, 24 April 2010 (UTC)[reply]
Why would editing one's own summary be troublesome? 86.142.110.239 (talk) 11:23, 24 April 2010 (UTC).[reply]
Just a thought, keeping in mind my opinion of this proposal in general below, the dynamic IP problem could be solved by restricting the 5-minute editing window only to the current session. Equazcion (talk) 19:36, 30 Apr 2010 (UTC)
See bugzilla:10105 (WONTFIX in 2007) and a 2008 discussion at Wikipedia:Village pump (proposals)/Archive 30#Being able to edit your edit summaries. PrimeHunter (talk) 01:47, 24 April 2010 (UTC)[reply]
Although that refers to the ability to edit other's edit summaries. Prodego talk 13:48, 25 April 2010 (UTC)[reply]

This is a perfectly valid and feasible request. The details of how it could work have already been worked out, please see bugzilla:13937 for details. The discussion had already moved on to implementation details and patches, but has been inactive for a while now. But maybe it will continue now? Essentially, this should work (1) if it is your own edit (2) and if it is the last edit (3) during a short time span. Cacycle (talk) 19:37, 25 April 2010 (UTC)[reply]

For information, another similar but distinct request is located at WP:Village pump (technical)#Claiming edits. PleaseStand (talk) 19:59, 25 April 2010 (UTC)[reply]

I'd appreciate having the ability to correct edit summaries. Every now and again I make a mistake there, and there's no way to correct it -- all one can do it make a dummy edit with "the previous edit summary should have been...." It's in a very small subset of things I can do on Wikipedia but can't undo. Useight (talk) 20:26, 25 April 2010 (UTC)[reply]

I oppose this feature. I see no point in putting in such a feature and I do not like people sticking in things which confer no great benefit, it is feature creep and only helps vandals. The past is the past. You can always put in a dummy edit to explain if you really feel you must. The only ones I can see worth editing are ones that are offensive or give out editors details or other reasons where the originator can't be expected to show much sense if they were given the facility. If you mess up an edit you do another edit, you can't change the old edit and that's the right way to do things. Dmcq (talk) 13:19, 26 April 2010 (UTC)[reply]
No, there is no way this could help vandals if implemented as discussed (own edit, last edit, during a short time). Cacycle (talk) 06:44, 27 April 2010 (UTC)[reply]

Editing your own summaries would be nice, but I can't imagine that the benefit of being able to would be worth the effort to enable it. It can remain one of those things we just get over not having. EVula // talk // ☯ // 19:16, 26 April 2010 (UTC)[reply]

Agree with EVula. Sometimes I wish I could fix an edit summary, (like when I accidentally type "rere" instead of "re") but it strikes me as more trouble than it's worth. –xenotalk 15:17, 28 April 2010 (UTC)[reply]
  • Strong support It would be very useful feature to correct spelling errors in an edit summary. However, I would support it being allowed only to Autoconfirmed users. Immunize (talk) 15:12, 28 April 2010 (UTC)[reply]
  • Strong oppose—would cause so much trouble, people changing the past. Should we leave edit-summaries when editing the edit-summary? Can we edit those? (And do spelling errors in edit-summaries really matter?!) ╟─TreasuryTag►person of reasonable firmness─╢ 15:17, 28 April 2010 (UTC)[reply]
  • Support own edit, last edit, during a short time, IPs excluded. --SarekOfVulcan (talk) 15:21, 28 April 2010 (UTC)[reply]

I feel it should be not only IP's excluded but also non-autoconfirmed users (users who have not made more than 10 edits and have been registered less than 4 days). Immunize (talk) 15:25, 28 April 2010 (UTC)[reply]

  • Support being able for autoconfirmed users to edit their own edit summary if it's the last edit of the page. A notice such as (edit summary edited at 19:48, 29 April 2010 (UTC)) should be displayed at the end. ― ___A._di_M. (formerly Army1987) 19:48, 29 April 2010 (UTC)[reply]
  • Comment It's not that I oppose this, I just see very little benefit to it's implementation.--Cube lurker (talk) 19:54, 29 April 2010 (UTC)[reply]
  • Weakish support - within 120 seconds, last edit, only (top) edits. Developers have far more pressing concerns. –xenotalk 19:56, 29 April 2010 (UTC)[reply]
  • Support - For a short period of time on your own edits this would be helpful. - EdoDodo talk 15:25, 30 April 2010 (UTC)[reply]
  • Comment This has come up a few times. The conclusion is generally that it's more trouble than it's worth, as has already been expressed above, and that I concur with. It wouldn't just be a significant technical effort, but there would be lots of logistics to work out. If you leave a particularly troublesome edit summary you can always use a null edit to display a correction. Equazcion (talk) 15:56, 30 Apr 2010 (UTC)
  • Oppose. This would only work if we then also had records of the edit summary history, which is extremely unlikely to happen. Otherwise editors would start putting the worst insults against other editors, threats of legal action or violence, etc., in their edit summaries when they know that their opponent is likely to see it, and undo it immediately afterwards. Or perhaps they wouldn't – but then others would swear that it happened anyway. Possibly even in good faith. I don't think anybody wants to sort out such disputes. Hans Adler 15:58, 30 April 2010 (UTC)[reply]
  • Is this really anything that a null edit and a "Oops, sorry, I meant diet COKE" wouldn't solve? ~ Amory (u • t • c) 17:29, 30 April 2010 (UTC)[reply]
  • Support. This is a good idea. In a related idea, I'd like to see a way for us to tag edits and collapse them out of the history to make it easier to see how a page has changed. I frequently want to filter out all the vandalism/revert, minor edits, and wikignome edits to see the substantive changes. I'd like like my watchlist to refer to the most recent substantive edit and ignore wikignome, minor, ect. edits. II | (t - c) 18:04, 30 April 2010 (UTC)[reply]
    Echo that. If I could mark specific edits "ignore" or "reviewed - don't need to see again", I'd wet myself. Rd232 talk 18:27, 30 April 2010 (UTC)[reply]
    From Special:Watchlist, you can click "Hide minor edits". That covers rollback edits, wikignomery, and, obviously, minor edits. EVula // talk // ☯ // 19:01, 30 April 2010 (UTC)[reply]
    Though I should point out that many vandals mark their edits as minor. Dmcq (talk) 19:08, 30 April 2010 (UTC)[reply]
    Yeah, the only may to make it really work is for each editor be able to tag other people's edits, with those tags completely private for them, i.e. solely affecting their own recent changes/history. Rd232 talk 19:21, 30 April 2010 (UTC)[reply]
People's tags could be made public, and I could assign 'trust' to certain people. So if someone I trusts tags an edit not initially marked minor as minor, I would automatically accept that it is minor, and filter it as such from the history or watchlist. I could also set my filter up so that if enough people mark an edit as minor (say 4), I accept that the tag is valid and can filter such edits from my history. The history should show when a series of edits has been collapsed, and should be easily expandable. II | (t - c) 00:15, 1 May 2010 (UTC)[reply]
I know, that would be lovely; but I seem to remember this has been brought up before (possibly by me), and it was said that it would be very very difficult to implement. Maybe it's worth spinning off from this edit summary discussion and revisiting... perhaps at WP:VPD. It might be high cost, but it would be very useful, especially for editing the high-traffic pages which are often relatively poor quality. Rd232 talk 08:23, 1 May 2010 (UTC)[reply]
  • Considering the fact that ImperfectlyInformed specifically wanted to hide vandalism from their watchlist as well, I fail to see how my suggestion doesn't address their needs. :) EVula // talk // ☯ // 20:42, 30 April 2010 (UTC)[reply]
If I hide minor edits, then if there is a substantive edit that happened on the same day as that minor edit, the substantive edit is not displayed for that day. So it doesn't work. Ideally when a person reverts a vandalism edit, their revert is minor and the vandalism edit would be tagged as vandalism, so I wouldn't have to see either edit on the watchlist, but rather the prior non-minor non-vandalism edit which occurred on that day (if applicable). The other problem is that enforcement of the minor tag under WP:MINOR is lax. If my above idea were implemented, I would want stricter enforcement. Many wikignomes don't mark their minor edits as minor, and under this idea we wouldn't have to pressure them, although they might get the point as people tag their minor edits. II | (t - c) 00:15, 1 May 2010 (UTC)[reply]
  • Oppose - it's annoying when it happens, but the implications of making that data editable are far more serious, and are sufficiently problematic to make it absolutely not worth considering. That edit summary is an inseparable part of what happened at that point in history. Use a null edit. PL290 (talk) 18:41, 30 April 2010 (UTC)[reply]
  • This would be a useful feature as long as the ability exists only for: (1) one's own edits; (2) the last edit to a page; and (3) edits made no more than about 5 minutes ago. Under these restrictions, I do not think that there would be significant negative consequences. On the question of whether this feature request is important enough for the developers to spend their time on it ... well, that's really up to them—if they decide that their time should be spent on other things, then they're probably right. -- Black Falcon (talk) 19:34, 30 April 2010 (UTC)[reply]
    The dynamic IP problem could be solved by enabling the feature only for registered users. If there is still concern about misuse, the feature could (on a trial basis) be restricted to autoconfirmed users only . -- Black Falcon (talk) 19:46, 30 April 2010 (UTC)[reply]
    As I said further up, the dynamic IP problem could also be solved by restricting the editing window to the current session only. So for instance, logging out, or logging in again from another location or browser, would not allow the user/IP to edit a summary posted in a previous login. I'm not really in favor of this anyway, for the reasons I stated already above. It's not just a matter of programmer time, but of adding logistical complications for all of us that just aren't worth it to basically save people some embarrassment. Null edits are enough, IMO. Equazcion (talk) 19:51, 30 Apr 2010 (UTC)
    Thanks, I'd not seen your most recent comment. I see your point about the added complications, but I don't think that they will be too significant (updating instructions on a few pages and occasional, minor confusion in those who are not aware of the feature and notice an edit summary change).
    Overall, my perception of the idea is that it involves a small improvement (i.e., a feature that is useful in some cases, even if the usefulness is minor) at a cost of a small amount of added logicistical complication and an unknown amount of programmer time. In light of this, I support the idea in principle, but will not be disappointed if it is not implemented. -- Black Falcon (talk) 20:04, 30 April 2010 (UTC)[reply]
    What I think would be really useful would be the ability to edit (or at least preview) deletion summaries. -- Black Falcon (talk) 20:08, 30 April 2010 (UTC)[reply]
    Might as well make that all log summaries, then. Block summaries, protection summaries, etc. Equazcion (talk) 20:11, 30 Apr 2010 (UTC)
    Good point. I started a thread at Wikipedia:Village pump (technical)#Previewing or editing log summaries. -- Black Falcon (talk) 20:35, 30 April 2010 (UTC)[reply]
  • Let's implement it as an optional feature in the software and once we see exactly how this will work, then decide. It might not be a bad thing, but we should probably keep a readily-accessible record somewhere of what the original edit comment was. If we do that, we might not even need to limit it to 5 minutes, or require it to only be the most recent edit. Tisane (talk) 20:40, 30 April 2010 (UTC)[reply]
  • Oppose - besides the huge amount of complexity for such a trivial feature as well as the possible abuse vectors, revisions should be considered immutable. If you want to change something in a revision, submit a new one. Mr.Z-man 21:17, 30 April 2010 (UTC)[reply]
While revisions should be immutable, I think in principle allowing a third-party to describe the edit which the editor failed to describe appropriately is a worthwhile idea. I can see the mess it would make on Wikipedia although I can also see as highly efficient in smaller and more tightly integrated wikis. II | (t - c) 00:15, 1 May 2010 (UTC)[reply]
  • Oppose. Too much lack of transparency for too little gain. "Show preview" also shows preview of edit-summary, so catching mistakes in edit-summaries is already no harder and is visible at the same time as you're catching mistakes in the edit itself. DMacks (talk) 20:05, 2 May 2010 (UTC)[reply]
  • Oppose - This will only serve to create unnecessary confusion among editors working on same page as well as page patrollers. Having incorrect edit summaries is considerably rare if you pay attention to what you are doing. There doesn't seem to be a pressing need, and things will become too complicated when edits overlap. Deagle_AP (talk) 11:13, 4 May 2010 (UTC)[reply]

Template:Portal

As I described here, I want to activate my bot to add the syntax {{Portal|Portalname}} in all the pages that is related to the related portal. In this manner more readers will visit portals. This would apply to multiple categories and portals.

  • Do you agree?
  • I have to write "Portalname" in lower case or upper case?
  • Except to have bot flag, write code, and reach consensus here, what I have to do?

--Aushulz (talk) 12:43, 27 April 2010 (UTC)[reply]

  • Tentatively agree, but automatically finding relevant pages might be problematic.
  • Currently the case matters, but this should be changed shortly.
  • You will need to follow the instructions at WP:BRFA to get your bot approved. — Martin (MSGJ · talk) 13:05, 27 April 2010 (UTC)[reply]
Disagree. Portals vary, the links to them are often crufty. Take a look a Louisiana Purchase is has a link to every US State portal that is part of the purchase (including, until recently, one that didn't exist), your proposal would add Portal:France to all the communes? Why? Unless you mean Portal:XXX gets added to article XXX? In which case, it is probably already done.
Also Portals are slip-sliding between The Project (i.e. being part of the encyclopedia) and Wikiprojects - look at Portal:Physics "Things you can do" "Fix a stub" etc. That makes the portal a selfref. Rich Farmbrough, 14:39, 1 May 2010 (UTC).[reply]

Proposals for non-breaking spaces

(Continuing the previous discussion on markup for non-breaking spaces, which was archived without coming to any result.)

A brief summary: I think we can generally agree that non-breaking spaces ("hard spaces") are useful and desirable, but there are some issues in implementation. Particularly, the "&nbsp;" is tedious, and makes the markup hard to read. The unresolved issue of the previous discussion regarded finding a better input representation (such as single or double underscores) for use in markup.

I submit a pair of proposals. First, that in the edit screen (markup) the non-breaking space – what is often called, and generally is, a "blank" – be given a non-blank representation; for this I recommend the glyphs for either the &middot; ( · ), &sdot; ( ⋅ ), or "music flat" (the very lightweight "♭", U+266D, or &#9837;). This would make the presence of non-breaking spaces (actual U+00A0 chrs.) visible in the markup, and prevent their unknowing deletion.

Second, I propose that whichever character is used to represent nbspaces also be taken as nbspaces in pasted-in copy. (In lieu of the previous proposal of underscores.) This presents two challenges. First, conflict with the intended usage of that character. For such usage I suggest either the standard convention of doubling the character, or just using the HTML entity. (Or entering the character directly form the "Insert" bar.) Second is the problem of inputting any non-keyboard character, either nbspaces themselves, or the visible character representing them. This is no problem for those of us that can program our compose keys. For the rest it could be accessible from the "Insert" bar on the edit menu. - J. Johnson (JJ) (talk) 21:12, 27 April 2010 (UTC)[reply]

This is even more complicated than just using &nbsp; or {{s|1}}. –xenotalk 21:20, 27 April 2010 (UTC)[reply]
Huh? Surely you don't mean that being able to see non-breaking spaces in the edit screen is complicated. As to having an alternative to typing in "& n b s p ;" – what's complicated about clicking on a symbol below the edit screen? - J. Johnson (JJ) (talk) 22:31, 27 April 2010 (UTC)[reply]
As a start, browsers without javascript don't have that ability. –xenotalk 22:32, 27 April 2010 (UTC)[reply]
&nbsp; is already in the edittools thing in the wiki markup section. Mr.Z-man 22:36, 27 April 2010 (UTC)[reply]
I support the idea of having some simple markup for non-breaking spaces, but the proposal to have a single Unicode character represent one, and two of that character represent a literal character, is never going to get support. I'm not sure why you reject using double underscores out of hand - if any simple markup is going to get support, that would be it. All other representations - including undistinguished blanks, the character entity, and the {{s}} template - are worse than that in some way. — Gavia immer (talk) 22:44, 27 April 2010 (UTC)[reply]
"␢" (note: this is NOT a musical note char) would make more sense for a character as it's specifically intended for showing visual whitespace, and it's rather uncommonly used in articles. There'd need to be some sort of escaping mechanism for the few literal intended instances of it though. --Cybercobra (talk) 06:01, 28 April 2010 (UTC)[reply]
Quite right, esp. as the slashed-b has a history for making "blanks" visible. But I didn't quite see how produce it. And what I really like about the flat symbol is that it is so light in appearance that visually it is almost a blank. - J. Johnson (JJ) (talk) 02:04, 30 April 2010 (UTC)[reply]
Wikipedia already has an escaping system: <nowiki>. We should continue to use that rather than introducing another notation.
The core issue is that '&nbsp;' is cumbersome to use, and obscures the markup. But for the secondary issue of distinguishing between the special and ordinary usage, any means of escaping should suffice. - J. Johnson (JJ) (talk) 02:04, 30 April 2010 (UTC)[reply]
I'm wary of any proposal under which one types a different thing than one sees in the edit box. I would rather we have something simple to type which doesn't conflict with anything in use. For example: A double comma. (This was originally proposed by User:Noetica, if I recall correctly.) I.e., one might write Mr.,,Smith or April,,1, 1990. Since double commas don't occur in normal prose, this would break very few articles (there may be some programming articles that are damaged by it). And it would make it much easier to write correctly spaced articles. Ozob (talk) 01:48, 29 April 2010 (UTC)[reply]
Double commas don't occur in normal prose, but does it matter how often they occur in URL's? Out of the first 10 long articles I searched, I found one URL with a double comma in List of foreign Ligue 1 players (go into edit mode and search for ",,"), 2 URL's with double commas in 2009 flu pandemic timeline, and 7 URL's with double commas in List of Jewish American entertainers. Art LaPella (talk) 04:29, 29 April 2010 (UTC)[reply]
The implementation could exclude URLs, <code> tags and <source> tags, as well as any place where the characters aren't actually displayed in the rendered title such as template parameter names. As for literal hard spaces, some browsers convert them to ordinary spaces when submitting the changes– for example I copied and pasted hard spaces between the following letters: a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a (this is Firefox 2.0.0.14). ― ___A._di_M. (formerly Army1987) 07:37, 29 April 2010 (UTC)[reply]
Same happens with Firefox 3.0.19. ― ___A._di_M. (formerly Army1987) 20:52, 29 April 2010 (UTC)[reply]

I personally find double-underscores and double-commas less than ideal, but acceptable. I think that something like middot or flat would be more elegant, their principal (?) drawback (??) being that they are not ordinary keyboard characters. (Which is what the "complications" of my proposal address.) - J. Johnson (JJ) (talk) 02:04, 30 April 2010 (UTC)[reply]

The problem with using non-keyboard characters is that it takes longer to go and click on something in the edittools thing (as well as the interruption from switching from keyboard to mouse) than it does to just type "&nbsp;". A small fraction of users might be able to program an easy keyboard shortcut, but everyone else will have to use the edittools bar or remember some obscure Windows alt code (or more likely, just continue to use the HTML entity). Mr.Z-man 02:47, 30 April 2010 (UTC)[reply]
In addition to the majority who just use the space bar, rather than try to learn something they can't pronounce. Art LaPella (talk) 03:35, 30 April 2010 (UTC)[reply]
It looks like we need to review the fundamental basis of this discussion, which is (as I touched on above in the summary of the earliar discussion) that non-breaking spaces are useful and desirable, as well as specified by the MOS (see WP:NBSP). So if you "just use the space bar", you get "just" a space, a regular space, which is suboptimal. While it is possible to enter "hard" spaces directly (by various means, including cut-and-paste), this is also suboptimal: they are not visible in the wiki mark-up, so an editor can't tell what is really there.
My proposals are 1) to make the non-breaking spaces visible (but only in the markup) by means of a special character, and 2) to provide a more convenient method of input. Please note: none of this would remove any &nbsp; functionality. If you prefer to type in "&nbsp;" every time, fine, you would still have that, but many of us feel that discourages many editors from using nbspaces.
I can't speak for Windows, but on my machine the "obscure ... alt code" for a hard space is "Alt-space-space" – and as long as I hold the Alt key down extra hard spaces come with each press of the space bar. I am at a loss to imagine anything more intuitive. As to "everyone else" having to use the toolbar, or type in some obscure HTML entity — the way things are now, that is what everybody has to do; there is no "else" option. And that is just what some of us would like to remedy. - J. Johnson (JJ) (talk) 21:33, 30 April 2010 (UTC)[reply]

Better solution, unicode the &nbsp;s, let automated systems convert between the two (as they probably do in 99% of all space -> nbsp cases now) and let people do the hard stuff. Rich Farmbrough, 14:45, 1 May 2010 (UTC).[reply]

Which (if I understand you correctly) is essentially what I am proposing. But "unicode" the non-breaking spaces not by their assigned value of U+00A0, which would be not visibly distinguishable (in the markup) from a regular space, but by some other code that has a visible glyph (such as middot, sdot, or flat). And also to have what ever code (character) is selected rendered as a non-breaking space in the wiki output. - J. Johnson (JJ) (talk) 19:10, 1 May 2010 (UTC)[reply]
You could do this in javascript, I think, change the non-breaking spaces to the desired character on load, and back again on save. Of course steeps would have to be taken to avoid changing the wrong characters back - either by using a really rare unicode character (flawed in principle, but probably workable) or some escaping mechanism- the simplest might be {{Sic}} - the over-head of that used on a merely very scare character such as ␢ is negligable. Rich Farmbrough, 19:43, 2 May 2010 (UTC).[reply]
Surely they should be visible (and typable) as something that we can type, like the double comma or double underscore suggestion. I don't see the point of doing it with non-keyboard characters of any description. While we're at it, can we suggest a double hyphen for an en dash, and triple for em dash?--Kotniski (talk) 19:52, 2 May 2010 (UTC)[reply]

I really like the idea to make double underscore not surrounded by spaces a new wikicode for &nbsp;. It is the only proposal in the spirit of the existing wikicode: It is easy to enter, it is non-obtrusive while editing, and it is intuitive and almost self-explaining when you see it: e.g. 123__km/h.

All other characters and options suggested so far cannot be entered by the majority of editors and are not intuitive. Non-breaking spaces (A0) should not be added directly as they are invisible and they will be converted to normal blanks anyway by some editors (including wikEd). Cacycle (talk) 06:23, 3 May 2010 (UTC)[reply]

I don't see any persuasive reason why it needs to be a double underscore. Plain _ (without any adjacent ordinary space) would be more intuitive. And as long as it can be escaped somehow (nowiki, if nothing else), it would seem to be an option. There was some discussion previously about titles involving _, but there aren't any that involve them in the page title, and plausible section titles will always have an adjacent ordinary space (eg "/nowiki (ctrl-click)">/nowiki (ctrl-click)">/nowiki (ctrl-click)">/nowiki (ctrl-click)">/nowiki (ctrl-click)">/nowiki (ctrl-click)">[[WP:bla#what about __NOINDEX__]]"; WP:UNDERSCORE#the underscore character is _). Rd232 talk 11:00, 3 May 2010 (UTC)[reply]
Single underscores are quite commonly used in identifiers, so employing them for nonbreaking spaces is going to be a PITA for computer science articles.—Emil J. 14:18, 3 May 2010 (UTC)[reply]
Examples? Would help clarify that. Rd232 talk 22:56, 3 May 2010 (UTC)[reply]
Examples of single underscores in computer articles? C++, Obfuscated code, Perl, Visual Basic for Applications, JAPH, SYLK, ASCII art, List of emoticons, OCaml, Standard ML, ... Art LaPella (talk) 23:53, 3 May 2010 (UTC)[reply]
See? Those examples aren't as bad as you would think. Anything in "code" tags should be excluded anyway, so a couple need adding, and maybe some example variables renaming to make life easier. Trickier are cases like "@_", which has the odd reference at sentence end so has a _ without an adjacent space. Still, a code tag can sort that out. Maybe a single _ is more of an option than you think? Rd232 talk 12:59, 4 May 2010 (UTC)[reply]
Double-underscores are also used for computer programming identifiers, so the doubling wouldn't work either. Also, I don't find it intuitive; I would naively think X__Y would insert a larger or more spaces between X and Y, when in fact a nbsp acts like a small space in that it sticks close to the letters on both sides of it and can't cause linebreaks. Either we end up using a Unicode character that's not easy to enter anyway, or we use some ASCII combination that's either not obvious or not much shorter than nbsp; in all cases, no real gain. I don't think this discussion is gonna go anywhere. --Cybercobra (talk) 15:18, 3 May 2010 (UTC)[reply]
Yes, anything with underscores would have to be interpreted as literal underscores inside <code> tags. That much goes without saying, but it's also easy to accomplish. — Gavia immer (talk) 15:58, 3 May 2010 (UTC)[reply]
Computer programming identifiers usually occur in program code which would be preformatted anyway (i.e. double underscore should not be interpreted in <pre> tags). Wikicode magic words and parser functions also contain double underscores and must be interpreted first.
As for the "no gain": We currently have a huge problem with cryptic, confusing, and too busy raw text, especially for the better and developed articles. Anything that removes clutter and increases readability would be a major gain. And the substitution of &nbsp; for __ does exactly that. A beginner would not have to guess much what it does in e.g. 123__km/h. Cacycle (talk) 19:00, 3 May 2010 (UTC)[reply]
@EmilJ: my proposal is to exclude URLS and the content of <code> and <source> tags. There aren't many other uses of underscore characters actually displayed in the rendered article text. ― ___A._di_M. (formerly Army1987) 16:09, 3 May 2010 (UTC)[reply]
I'd quite like the &nbsp;'s changed to unicode non-breaking space like people do with &minus; and things like that providing WikEd output them specially like it does all the various versions of hyphen minus ndash and mdash and gave an option for inserting them directly from a menu like it does the various types of hyphen lookalikes. Dmcq (talk) 15:52, 3 May 2010 (UTC)[reply]
The problem with just using literal non-breaking spaces is that there's no indication in the wikitext that they are supposed to be non-breaking spaces, and so in the normal course of editing they tend to "rot" back to normal spaces as editors just use the space bar. Moreover, there's no obvious indication that this rot has happened, either, so it will tend to get missed and have to be repeatedly redone. In fact, there's often a similar problem with dash-like characters, including the Unicode minus. — Gavia immer (talk) 15:58, 3 May 2010 (UTC)[reply]
The fact is that a "feature" of certain browsers automagically converts hard spaces to soft ones on saving the page, so the "rot" will happen immediately as soon as someone edits the page or section with such a browser, whether they "just use the space bar" or not. (See my post of 07:37, 29 April 2010, where I had copied and pasted hard spaces between the a's.) This is not an issue with dashes, which will stay dashes with all browsers I remember using. ― ___A._di_M. (formerly Army1987) 16:09, 3 May 2010 (UTC)[reply]
The automated rot (mishandling) is a sufficient reason for not using actual non-breaking ("hard") space characters, as well as their not being visible to an editor. These really are not an option. - J. Johnson (JJ) (talk) 21:02, 4 May 2010 (UTC)[reply]

Re "All other characters and options suggested so far cannot be entered by the majority of editors and are not intuitive." (Cacycle, above). Look, if this proposal were adopted (and let's say using middot, '·') NOTHING WOULD BE TAKEN AWAY, everyone would still be free to use the klutzy '&nbsp;' entity. The only difference would be where someone had used a middot instead of &nbsp;—they would see something like "110·miles" instead of "110&nbsp;miles". (For sure, some number of editors would then be asking what the dot is all about. Considering how many editors don't seem to know about the use of non-breaking spaces, I consider this a teaching opportunity.) For anyone that does not want any change, that could be the only change they see or have to endure. It would be like the ability to add an image to your signature: it's there, but I don't have to use it. And as long as I don't want to use it the means of doing so are quite irrelevant.

The question of how to enter an middot (or any other "non-keyboard" character) arises only when someone decides they want to use it. Let me suggest something pretty basic: type in "&nbsp;". That is (this is a sub-proposal) have it converted automatically. Sure, this is a bit more change, but it strikes a nice (and needed) balance between the invisibility of actual hard spaces and the in your face overvisibility of "&nbsp;". No other input methods needed, and that certainly is as "enterable" and intuitive as &nbsp;, because it is the current method of entering nbspaces. (That allows making hard spaces visible, which is my first proposal, but is just as klutzy as the current methods of entry, which leads to my second proposal.)

My second proposal is that whatever character (Unicode entity) is adopted to be the visible representation of hard spaces (here we assume middot) be accepted as markup input. Again, this TAKES NOTHING AWAY from anyone that does not want to use such functionality. And for those that do, there are multiple methods of entry. Let me list a few (variously applicable to on- and/or off-line editing):

  • Click on a menu icon. (If that is too difficult, then why are there multiple drop-down menus of clickable items?)
  • Cut-and-paste. (For the odd odd-character, this often works just fine.)
  • Search-and-replace. (Use underscores [or whatever] in your off-line copy, then convert to middot (or?) in one fell swoop.)
  • Use a virtual keyboard.
  • Editor macros. (For serious editors your editor is a tool. Learn to use it?)
  • Enter middot with Compose key. (Write the code down next to your password.)
  • Enter a hard space with "ctrl+shift+space" (or option+space on Macs), which (second sub-proposal) could be converted to middots in the edit screen.

Or just stick with &nbsp;.

That some users might not be able handle any of these input methods seems a poor reason for not making useful improvements in the handling of non-breaking spaces. - J. Johnson (JJ) (talk) 23:22, 4 May 2010 (UTC)[reply]

So then how would we enter middots? They're used in a large number of nav templates for example. I say just leave it as &nbsp; with no extra fancy stuff to confuse people trying to insert underscores/middots/flat signs/etc.. It requires no specialist keyboard or entry method, cannot be confused with anything else, and has been the way non-breaking spaces have been entered on the world wide web since it was invented. OrangeDog (τ • ε) 20:00, 7 May 2010 (UTC)[reply]
Conversion of regular characters to markup is not something to be taken lightly. It can be taken for granted that something, somewhere is going to break when such changes are done - the extreme example would be using underscore(s) for nbsp. Also, changes that force existing text to adopt <nowiki> wrappers would mean unwarranted trouble to articles which do not use nbsps and nullify much of the perceived benefits of clearer notation from nbsp. Finally, and in agreement with OrangeDog, making markup more complex for a relatively minor readability detail is not worth the trouble. Simplicity of implementation should have priority in this case, and so I oppose the proposal(s). --Duplode (talk) 06:26, 8 May 2010 (UTC)[reply]

CSD A10

I feel that this criterion for speedy deletion should be eliminated, and instead, all pages that would have fell under the criterion should be immediately converted to Redirects rather than deleted. Immunize (talk) 14:57, 28 April 2010 (UTC)[reply]

Why? The criterion specifically states that the title must not be a plausible title for a redirect. Mr.Z-man 16:02, 28 April 2010 (UTC)[reply]
  • For the articles that are eligible for criterion A10, if they were converted to redirects, they would then be eligible for speedy deletion under criterion R3. Having an article criterion makes it easier to just delete the title in one step, instead of having to make and tag a redirect. It's also a lot more transparent to delete the article instead of deleting the subsequent redirect. Accordingly, criterion A10 is useful and makes the whole cleanup process easier for all involved. —C.Fred (talk) 16:19, 28 April 2010 (UTC)[reply]
And any article that would otherwise fall under A10 can be (and should be) made into a keepable redirect by any editor. Although I do agree that much stuff is deleted which should be made into redirects, merged or kept, that is not the fault of A10. Adn loads more trash is thrown out than good stuff. Rich Farmbrough, 14:53, 1 May 2010 (UTC).[reply]
 References
The problem there is that A10 specifically states that it only applies to articles with titles that would not make a plasuable redirect. If the title was a keepable redirect A10 would not apply in the first place meaning that converting a valid A10 speedy in a redirect would be pointless because by this critera's very nature all of the newly created redirect would already be deleateable under R3. In short there is no reason to convert valid A10s into redircts since they will be deleted anyway.--76.66.191.208 (talk) 00:50, 2 May 2010 (UTC)[reply]
R3 does not apply to articles that have been converted into redirects. I don't see any problem here. A10 says where the title is not a plausible redirect delete - otherwise create a redirect. Simple, does what everyone wants, status quo. Rich Farmbrough, 19:51, 2 May 2010 (UTC).[reply]
Immunize, can you provide an example of an article deleted under A10 that shouldn't have been? Tisane (talk) 04:28, 3 May 2010 (UTC)[reply]

How to make Wikipedia more comfortable for users.

Hello! Much more users would think that wikipediais very comfortable if you could make a button in the top of the article, which turns off all links and tags<a href="...> </a> in the content. I think it is need, because when you're copying the text from article (with linking to wikipedia, of corse) you usually have to remove hyperlinks from words (but in MS Word it's quite inconvenient).

Best regards, Mr. Artem Ushakov, Qantas.

Use Paste Special... text only Lambanog (talk) 15:35, 29 April 2010 (UTC)[reply]
You can also paste it at the notepad, and then copy and move it elsewhere MBelgrano (talk) 15:49, 29 April 2010 (UTC)[reply]
Same thing into the address bar also works. --Cybercobra (talk) 16:30, 29 April 2010 (UTC)[reply]
More to the point, every page has on the lefthand side toolbox "print/export" options including "Printable version", which has wikilinks removed and URLs revealed. Try it. Rd232 talk 16:41, 29 April 2010 (UTC)[reply]
The "Printable version" does not remove wikilinks, although it changes the formatting to be less obtrusive. The text is still linked. —C.Fred (talk) 16:48, 29 April 2010 (UTC)[reply]
Oh. Oops. Well that leaves the "Keep text only" option when pasting into Word, besides other suggestions. Rd232 talk 20:31, 29 April 2010 (UTC)[reply]
Use Open Office. Not saying it solves the problem, just ... use Open Office. Rich Farmbrough, 19:52, 2 May 2010 (UTC).[reply]
There is also ?action=raw, but that is just the raw wikitext. Tim1357 talk 02:46, 3 May 2010 (UTC)[reply]

Automatic tagging of uploads without licensing specified

Is there a reason why the above hasn't been implemented at en-wp, but has at commons-wiki? When an upload's license has not been specified, the image is automatically tagged for lacking proper information (i.e., CSD F4). If not, why not? Blurpeace 23:48, 30 April 2010 (UTC)[reply]

Total support, makes new file patrolling a whole lot easier. • ɔ ʃ → 23:52, 30 April 2010 (UTC)[reply]
Pretty sure it is tagged for deletion if no licence is specified. Rich Farmbrough, 14:50, 1 May 2010 (UTC).[reply]
Not by default here, though. • ɔ ʃ → 01:34, 2 May 2010 (UTC)[reply]
I suppose it depends on "automatic" - I think tweaking the upload templates might be easy enough. Rich Farmbrough, 19:54, 2 May 2010 (UTC).[reply]
I'm not sure how it works on Commons (I assume either something in the upload form or some parser looking for copyright tags), but if a new file is uploaded without a copyright tag, what is the equivalent of {{db-f4}} shows up on the image page. This does not apply, I believe, for file pages whose tags are manually removed later, perhaps by a vandal. • ɔ ʃ → 20:53, 2 May 2010 (UTC)[reply]
I think a few different bots check new uploads for any templates other than {{own}} and {{Information}} (or any of its equivalents) and tags it as missing a license if there are no others. I've noticed that the bots don't get all of them, but they do get quite a lot. Killiondude (talk) 04:39, 3 May 2010 (UTC)[reply]

Disable admin self-unblocking?

From the next software update (see r64228), blocked admins will no longer be able to block or unblock other users, and the ability to unblock themselves will become a configurable setting, a permission which we can, if desired, remove from the admin group here on enwiki. That would mean that blocked admins are technically prevented from unblocking themselves. In light of recent drama at WP:ACN, and our general distaste for the practice of self-unblocking, is that desirable? Happy‑melon 19:54, 4 May 2010 (UTC)[reply]

Yes. For the all-too-frequent self-block, we have the magic {{unblock-stupid}} template. Hipocrite (talk) 19:55, 4 May 2010 (UTC)[reply]

Out of interest, does the revision allow for admins to unblock themselves having mistakenly self-blocked? Otherwise it could cause a lot of hassle... ╟─TreasuryTag►senator─╢ 19:57, 4 May 2010 (UTC)[reply]

(edit conflict) What of those who accidentally block themselves? It's happens more than you'd think. AGK 19:58, 4 May 2010 (UTC)[reply]
Indeed. Of the 11 self-unblocks this year, 8 were after mistakes. 1 was a test. Only 2 were admins lifting actual blocks of their own accounts. –xenotalk 20:00, 4 May 2010 (UTC)[reply]
As long as we're improving the blocking aspect of the software, why not just disable the ability to block one's own account? That seems like a superfluous ability anyway, and is only either done as a joke or by accident, as far as I know. Equazcion (talk) 20:07, 4 May 2010 (UTC)[reply]
No, sometimes an admin is the only one willing to step up and block themselves for doing something daft. –xenotalk 20:11, 4 May 2010 (UTC)[reply]
I think you're joking, but I'm oddly unsure :) Equazcion (talk) 20:12, 4 May 2010 (UTC)[reply]
=\ –xenotalk 20:18, 4 May 2010 (UTC)[reply]
Since blocks are supposed to preventative, blocking oneself seems rather paradoxical. If you have the forethought to block yourself then you apparently have already realized the inappropriateness of your behavior and resolved not to continue. So again the ability to self-block seems superfluous. Equazcion (talk) 20:25, 4 May 2010 (UTC)[reply]
Agreed. If one can't block oneself in the first place, then there's no need to be able to unblock oneself. --Cybercobra (talk) 20:59, 4 May 2010 (UTC)[reply]
Or a "screw it, burn the bridges" kind of thing - fullprotect/selfblock then m:SRP the bit. ~ Amory (u • t • c) 20:14, 4 May 2010 (UTC)[reply]
Yeah, but if those 8/9 were forced to get unblocked by another sysop, they'd only be slightly inconvenienced, and everyone else would get a proportionally larger laugh. ~ Amory (u • t • c) 20:17, 4 May 2010 (UTC)[reply]
Hell yes. Admins who block themselves can be unblocked by other admins. --Conti|✉ 20:04, 4 May 2010 (UTC)[reply]
I actually never even knew admins could self-unblock until I saw that little debacle, and was surprised. To be honest though, to me it's the same sort of ridiculousness as people in the same rights group being able to block each other (though I accept this isn't fixable without electing lots more bureaucrats or changing the hierarchy significantly). If this is to be implemented I'd like to see some sort of increased urgency in policy regarding the blocking of admins by other admins, ie. that doing it without good reason even once will get you de-opped (aside from accidental cases). Equazcion (talk) 20:02, 4 May 2010 (UTC)[reply]
Why should we treat admins like they're somehow better than other users? Admins can act just like every other user when they get blocked and follow the proper procedure. --Conti|✉ 20:07, 4 May 2010 (UTC)[reply]
(EC) So how many blocks with no good reason upon regular editors equal one block with no good reason on an admin?--Cube lurker (talk) 20:11, 4 May 2010 (UTC)[reply]
I'm not saying we should treat them any better. Ideally they should be treated the same, but that would mean they'd have another rights group above them to dole out their blocks. As it stands they can all block each other, which is already a strange way of doing things, and not on par with the average user. Equazcion (talk) 20:11, 4 May 2010 (UTC)[reply]
I don't see the need for that. There's lots of admins around, and when one blocks another there's still a thousand others (plus tens of thousands normal users, of course) to decide whether the block was okay or not. --Conti|✉ 20:19, 4 May 2010 (UTC)[reply]
I actually don't think it's the worst thing in the world for admins to have the ability to unblock themselves, but know they shouldn't. If they can't restrain themself in that situation, it's probably for the best that we learn about it.--Cube lurker (talk) 20:11, 4 May 2010 (UTC)[reply]
(EC)Excellent idea to stop blocked admins unblocking themselves. As for "accidental self-blocks" - hardly a sign of competence with the tools is it? Agree with Conti's response to Equazcion above too. DuncanHill (talk) 20:13, 4 May 2010 (UTC)[reply]
Everyone presses a wrong button or two here and there. Sometimes it's submit, sometimes it's delete the main page. Shit happens. ~ Amory (u • t • c) 20:17, 4 May 2010 (UTC)[reply]
Then I'm sure a kindly and understanding fellow admin will unblock promptly in such a case, perhaps with some simple helpful hints on how to avoid blocking oneself. DuncanHill (talk) 20:26, 4 May 2010 (UTC)[reply]
Without checking, I presume this is a right Bureaucrats inherit - would this change their ability as well? Is there any sense to letting the 'crats keep the ability? ~ Amory (u • t • c) 20:14, 4 May 2010 (UTC)[reply]
By default, it's not granted to the bureaucrat group; they would inherit it from the admin group if admins have it. We could explicitly grant it to them if desired. Happy‑melon 20:34, 4 May 2010 (UTC)[reply]
A concern of more substance. Without going too far into WP:BEANS are there concerns about the increased dammage that could be done with a single comprimised admin account?--Cube lurker (talk) 20:23, 4 May 2010 (UTC)[reply]
As in a rogue admin massing blocking other active admins? Yes, that is one potential problem - and I believe one of the reasons admins are able to unblock themselves. –xenotalk 20:25, 4 May 2010 (UTC)[reply]
How long does it take to block 1000+ admins? I find this a rather unrealistic concern, to be honest. --Conti|✉ 20:28, 4 May 2010 (UTC)[reply]
Probably not long with a script. A smart-cookie would start with the ones who were most recently active per contributions or log entries. But I agree that this is not even close to the most damaging thing that can be done with a rogue admin account, and all it would take is a steward to put an end to the madness. –xenotalk 20:34, 4 May 2010 (UTC)[reply]
And in the end a steward could come along and undo the whole damage anyways. Or we could create a blocking limit of 100 blocks per minute, or something. --Conti|✉ 20:37, 4 May 2010 (UTC)[reply]
Heh. Even in the worst case I can come up with the damage could be undone again somehow. Which leads me to another question.. can bureaucrats promote users to admins when they are blocked? :P --Conti|✉ 20:26, 4 May 2010 (UTC)[reply]
No; blocked users cannot access Special:UserRights. Happy‑melon 20:34, 4 May 2010 (UTC)[reply]
Wait, did you mean blocked crats promoting admins, or a crat promoting a blocked user to admin status? The Thing // Talk // Contribs 20:52, 4 May 2010 (UTC)[reply]
A blocked bcrat cannot use UserRights. Rights can of course be changed on a blocked account. ^demon[omg plz] 22:37, 4 May 2010 (UTC)[reply]
There are some actions that cannot easily be undone. The oversight feature makes possible a deletion spree that requires intervention of a sysadmin to undo. Further information withheld from public disclosure, but should be fairly obvious to the technical folks. PleaseStand (talk) 22:56, 4 May 2010 (UTC)[reply]
I was under the impression that Extension:Oversight was going to be disabled at some point, what with RevDelete becoming the conventional method for hiding revisions. AGK 00:28, 5 May 2010 (UTC)[reply]
What on earth has this got to do with the issue at hand? Happy‑melon 11:49, 5 May 2010 (UTC)[reply]

Oppose. I've seen cases of admins going bat shit crazy (or compromised account) and blocking a slew of other admins. Admins should be able to unblock themselves in such cases. If it's feared that a particular admin would unblock himself during a valid block then he can be temporarily desysoped during his block. --Ron Ritzman (talk) 00:52, 5 May 2010 (UTC)[reply]

  • So basically the way I see it either option (keep it as it is, or disallow self-unblocking) has bad possibilities, both uncommon. If we allow admins to unblock themselves technically, then we run the risk of them doing so when they shouldn't, fairly uncommon but obviously it happens. If we disallow it then we run the risk of a rouge account causing widespread damage, this is even more unlikely but much more damaging to the project. Which scenario is better? Higher risk of lesser disruption or lower risk of higher disruption--Jac16888Talk 01:26, 5 May 2010 (UTC)[reply]
  • Oppose. I'd rather have the risk of one rogue admin needing desyopping by a steward that the risk of one rogue admin running a script and blocking a slew of us in a matter of minutes. Useight (talk) 01:42, 5 May 2010 (UTC)[reply]
  • We trust admins to not go crazy with the tools; otherwise we wouldn't give them access to all sorts of special features. Self-unblocking is probably one of the least-misused abilities admins have, so in agreement with Useight that this isn't necessary. –Juliancolton | Talk 01:55, 5 May 2010 (UTC)[reply]
    • Oh come on guys. There's 1 (one) obscure, theoretical situation where self-unblocking would be useful and needed. There's more than one real situation (that actually happened before, more than once) where self-unblocking caused actual, needless drama. You can't tell me that you are genuinely worried over a rogue admin taking over Wikipedia. As has been said above, even if someone would try that one day, a Steward is all we'd need. Is it even possible to block every single admin within a minute, anyhow? --Conti|✉ 06:26, 5 May 2010 (UTC)[reply]

We could make it say, "You are about to block your own account. Are you sure you want to do this?" Tisane (talk) 08:23, 5 May 2010 (UTC)[reply]

I agree with others above, that if we remove the self-unblocking ability, we need to remove the ability to block yourself. Otherwise, the unblocking code needs to include a check to see who the blocker was:
IF blocked-by == current-user THEN
   unblock
ELSE
   give warning message: "You can only unblock yourself if someone else blocked you."
ENDIF
On the whole, I see no reason for an admin to need to block themselves: there are test IPs/accounts which you can test-block at WP:NAS. If you need a block to stop editing for a while, there's the WikiBreak Enforcer. Why else would someone want/need to self-block? If there is no way to self-block, there can be no accidental self-blocking - and then admins won't need the ability to unblock themselves. -- PhantomSteve/talk|contribs\ 08:35, 5 May 2010 (UTC)[reply]
WikiBreak Enforcer is useless for anyone who knows how to turn off Javascript (hello, Firefox+Noscript). Just saying. Rd232 talk 11:52, 5 May 2010 (UTC)[reply]
Oh, and as for the risk of a rogue admin blocking tons of other admins - has it ever happened before? If so, when? If not, I'd think the chances of it happening are remote, and even if all over admins apart from the rogue were blocked, a steward could quickly be contacted and an emergency de-sysop/mass unblock can be done -- PhantomSteve/talk|contribs\ 08:38, 5 May 2010 (UTC)[reply]
A rogue admin going on a blocking spree is not significantly more dangerous than a rogue admin going on a deleting spree; indeed by distracting them onto doing something entirely reversible, it might actually reduce the damage. Don't forget that there is already very little local admins can do to stop a well-planned admin rampage. But if unblockself is disabled, then the a rogue admin can be stopped if any of our 856 get to the block button before the rogue does, or when a steward gets here; whereas with unblockself, the rampage will definitely continue until steward help arrives. Happy‑melon 11:49, 5 May 2010 (UTC)[reply]
  • Oppose. Another solution in search for a problem. Admins do not unblock themselves every day, and when they do this without a very good reason, it may be a basis for an emergency desysoping. On other hand, the ability to block/unblock oneself may be useful for testing. Ruslik_Zero 16:33, 5 May 2010 (UTC)[reply]
    As has been pointed out above, this feature would actually dramatically reduce the harm a rogue admin could do. One block, and the problem would be solved. That seems like quite the solution to an actual problem to me. --Conti|✉ 16:43, 5 May 2010 (UTC)[reply]
    Just because the problem hasn't presented itself yet doesn't mean it's not a valid potential problem. There's no urgency felt until it actually happens, and then eveyone says "well why didn't someone just do ____ which could have prevented this whole mess". Well, now we've thought of it, so why not prevent it ahead of time? Equazcion (talk) 16:46, 5 May 2010 (UTC)[reply]
    While I really care very little for the outcome of the proposal -- it was simply something I noticed that tied in with software changes I'd already done -- I do intensely dislike the habit of presenting the "solution in search of a problem" response to issues where the problem very manifestly does exist. Admins occasionally unblock themselves in a way that creates drama. Drama is a problem; a problem which could be solved by preventing them from unblocking themselves. You can quite legitimately argue that the costs outweigh the benefits; indeed that's probably a convincing argument unless admins are also prevented from blocking themselves so easily. But to assert that the problem and benefits simply do not exist is totally disingenuous. Happy‑melon 16:50, 5 May 2010 (UTC)[reply]
  • If an administrator managed to block a great deal of active local administrators, the solution is simple. I think this is a good idea per Happy-Melon's post of a few hours ago. NW (Talk) 19:44, 5 May 2010 (UTC)[reply]
  • Comment Regarding limits on blocks per minute, the checkuser tool allows for multiple simultaneous blocks for socks. I'd like to make sure that is not removed. -- Avi (talk) 19:51, 5 May 2010 (UTC)[reply]
  • Looking at the discussion above, the justification for preventing admins from unblocking themselves seems strong to me and arguments against seem exceptionally feeble. If it helps those whose blocking activity is particularly erratic, it might be nice to prevent self-blocking. Thincat (talk) 21:05, 5 May 2010 (UTC)[reply]
  • Comment This + rouge admin + MediaWiki:Wikimedia-copyright (assume it's still not fixed, beans violation I assume again) hack can be an real disaster →AzaToth 21:04, 5 May 2010 (UTC)[reply]
    • How? Maybe I don't get the beans here, but if a rogue admin would do something now, there'd be nothing you could do. Block him, he'll simply unblock himself and go on. How could it be worse if he couldn't continue if an admin would block him? --Conti|✉ 21:13, 5 May 2010 (UTC)[reply]
At a pinch a single problem admin can be kept locked down with blocks every second or so until a steward is found. It's much harder to apply this tactic to the general admin community.©Geni 21:32, 5 May 2010 (UTC)[reply]
You prefer blocking a rogue admin every second over blocking him once? Er.. I don't get it. --Conti|✉ 21:36, 5 May 2010 (UTC)[reply]
Well, he'd go in and try to edit, see that he's blocked, and then have to spend time unblocking himself and refreshing and all that jazz... It's possible, considering stewards have to be extremely active and whatnot, and monitor the IRC channel. It'd only take like, a minute to get a steward.--Unionhawk Talk E-mail 01:56, 6 May 2010 (UTC)[reply]
Yeah, and if this were implemented he couldn't unblock himself in the first place, so there would be no need for a Steward in the first place. So, cleary, in this case that's the sane alternative, isn't it? --Conti|✉ 06:15, 6 May 2010 (UTC)[reply]
Except he couldn't be blocked in the first place since his first act was to neutralise every active admin. Under the current situation in a pinch it boils down to weight of numbers. Remove admin's ability to unblock themselves and it boils down to reaction times and skill with the first mover having a significant advantage.©Geni 18:09, 6 May 2010 (UTC)[reply]
Under the current situation it boils down to getting a Steward to desysop the admin. Under the new system it would boil down to getting a Steward to desysop the admin. In the former example, we need a Steward every single time. In the latter example we need a Steward only if the admin in question would manage to block every other admin before they act. Which is a thing that can easily be prevented by limiting the number of blocks that can be done in a minute. But I'm sure we're never gonna do that either because there's surely a handful of admins around who block more than 100 accounts a minute now and then, or something. --Conti|✉ 18:42, 6 May 2010 (UTC)[reply]
Not every single admin. Remeber at any given time only a fairly small percentage of admins are actualy active and able to react to such issues.©Geni 22:12, 6 May 2010 (UTC)[reply]
So? My point remains: You need a Steward either way. Right now, you'd need a Steward. With this, you'd need a Steward. If we're going into hypothetical worst cases, a rogue admin could have a script to automatically unblock himself, so the "Let's click the block button as often as possible to keep him occupied"-argument is a rather silly one when you also make the "Let's assume he'll block bloody everyone in a minute. "-argument. --Conti|✉ 07:32, 7 May 2010 (UTC)[reply]
  • Support - the code for this is already written. Its just a matter of flipping a switch. Even if the problem is minimal, the solution here is trivial. With regard to the rogue admin scenario, I think the ability to stop it with a single block outweighs the risk of someone being able to block every admin before anyone notices. Even then, the drama saved from non-rogue admins unblocking themselves far outweighs the both of the hypothetical rogue admin scenarios. Mr.Z-man 21:25, 5 May 2010 (UTC)[reply]
You don't need to block every admin straight away. Just the active ones and there are various tricks to further reduce the number and rate at which the admin community will be able to respond.©Geni 21:38, 5 May 2010 (UTC)[reply]
Let's see.. if an admin goes rogue now, we can't do anything at all (since he can just unblock himself) and have to run to a steward for help. If this would pass, we could deal with the problem ourselves unless that admin would manage to block every single admin before one of them would block him. Then we'd need a steward again. My apologies for the language, but, seriously, how the fuck is that a reason not to change anything? --Conti|✉ 21:45, 5 May 2010 (UTC)[reply]
It would be very easy, were an admin so inclined, to write a script which will block every admin account in a matter of minutes. Then what happens? I'm not saying its going to happen, just that its a possibility--Jac16888Talk 21:48, 5 May 2010 (UTC)[reply]
Then you go to meta and ask for a Steward, who'll desysop said admin. Think about it: what would you do if he would do that right now? Sure, you could unblock yourself.. and then what? He can unblock himself, too. So, in the end, you'd need a Steward to desysop the admin, again. Right now we need a Steward 100% of the time in case of rogue admins. With this implemented, we'd need a Steward only in one very specific instance. --Conti|✉ 21:54, 5 May 2010 (UTC)[reply]
What Conti said. In the worst case scenario, its no worse than it is now. And again, the rogue-admin-with-a-script thing is a hypothetical situation. Non-rogue admins unblocking themselves and causing drama has actually happened. Mr.Z-man 22:26, 5 May 2010 (UTC)[reply]
  • Support this proposal, and support making admins unable to block themselves as well while we're at it. Removing that capability removes the primary good reason why any admin ever needs to unblock him- or herself. Robofish (talk) 21:28, 5 May 2010 (UTC)[reply]
  • oppose removes a defence against certian attacks and removes a useful standard for defining when an admin has gone off the deep end.©Geni 21:32, 5 May 2010 (UTC)[reply]
  • weak oppose. The balance of the "rogue admin" arguments is unconvincing; any really effective rogueness probably needs steward intervention either way, and Wikipedia has survived 10 years with the status quo and won't collapse even if all admins are blocked for as much as a few hours while stewards are mysteriously AWOL. Which leaves the ability to self-unblock to go with the ability to self-block, which we really ought to trust admins with. And, per Geni, inappropriate self-unblocking may be a useful signal of something wrong. Defining it as purely drama may be incorrect. Rd232 talk 21:59, 5 May 2010 (UTC)[reply]
  • Oppose - what about a rogue admin (compromised account, probably) blocking bunches of OTHER admins? O.O Seriously though, if an admin needs blocking, then a steward should be called on the case to remove the bit and then block them. And, admins blocking themselves on accident is too funny to fix, honestly...--Unionhawk Talk E-mail 22:06, 5 May 2010 (UTC)[reply]
  • If admins block themselves by accident so often, how many other editors do they also block accidentally? Malleus Fatuorum 23:05, 5 May 2010 (UTC)[reply]
  • I've already opposed the idea of the software not allowing admins to unblock themselves but if it goes in anyway, why not also make it impossible for admins to block themselves? (or next April 1st say you have when you haven't and see if any admins fall for it :)--Ron Ritzman (talk) 01:26, 6 May 2010 (UTC)[reply]
    • Better still, why not make it impossible for admins to block anyone, if they can't even be trusted not to block themselves by accident? Surely this is some kind of a bizarre farce? If there's a problem with the UI then fix it. Malleus Fatuorum 01:35, 6 May 2010 (UTC)[reply]
  • Holy shit guys, I just had a really scary thought: If blocked admins can't unblock anybody, then in a hypothetical mass script-based blocking by a compromised admin account could feasibly take out every admin. That would be one hell of a mess for a Steward to clean up...--Unionhawk Talk E-mail 01:50, 6 May 2010 (UTC)[reply]
    • No, the steward would only have to unblock one admin. Every admin unblocked could then unblock other admins. And it could be undone as easily with a script as it could be done. I do find it strange though that people are more concerned with hypothetical situations rather than actual problems that have happened before (admins unblocking themselves and causing mass drama). Mr.Z-man 02:16, 6 May 2010 (UTC)[reply]
  • It would be the same amount of mess as if they all could unblock themselves, since only a small fraction will. But I don't think this is needed, admins know better than to unblock themselves. Prodego talk 02:12, 6 May 2010 (UTC)[reply]
    • Perhaps. What I find way beyond bizarre though is that blocked admins are still allowed to block other users, presumably including other admins. Malleus Fatuorum 02:21, 6 May 2010 (UTC)[reply]
      • They're not anymore. See the original comment that started this thread. Mr.Z-man 02:29, 6 May 2010 (UTC)[reply]
  • Comment What surprised me in the recent event was how much admins block themselves by mistake. I think something has to be done about it, like disabling the autofill (if possible) for the name of user blocked. Sole Soul (talk) 04:40, 6 May 2010 (UTC)[reply]
    There is no autofill (unless someone's browser is doing it), it's that people tend to have a lot of tabs open, including their talk/user page. Its easy to click the block link on the wrong page. I also sometimes click the block link on my own page, then fill in another username from there. Prodego talk 04:42, 6 May 2010 (UTC)[reply]
    At least, a confirmation message. After seeing this, I cannot rule out the possibility that number of new users were blocked indef by mistake without anyone knowing about it and without being unblocked. Sole Soul (talk) 05:07, 6 May 2010 (UTC)[reply]
    I blocked myself differently. I was showing a colleague what the admin interfaces looked like and I filled in the block user page with my own info, just in case a problem occurred. Lo and behold, when I went to grab my mouse, I inadvertently hit the enter key on the corner of my number pad. And I was blocked. Useight (talk) 22:28, 6 May 2010 (UTC)[reply]
  • Comment Perhaps the solution better solution would be to disable admin self-blocking. There's no reason to block one's own account. If a test is necessary one can either create a second account (though there may be an autoblock problem), or pick one of the million used-once accounts.   Will Beback  talk  23:12, 6 May 2010 (UTC)[reply]
    • That's not really a solution to anything. Admins blocking themselves by accident is embarrassing, but its not a real problem. The 2 problems here are the real problem of legitimately blocked admins unblocking themselves and causing drama and the hypothetical problem of a rogue admin running a script to block other admins and/or unblock himself. Mr.Z-man 23:36, 6 May 2010 (UTC)[reply]
      • Testing aside, is there ever a need to block one's own account?   Will Beback  talk  02:03, 7 May 2010 (UTC)[reply]
Some years ago a very prominent admin blocked themselves for 3RR. I remember this particular instance well because I was one of the aggrieved parties! It was an honourable thing to do and I said so at the time. It does not look to me contrary to the wording in Wikipedia:Blocking#Conflicts_of_interest. However, it did rather seem punitive rather than preventative. Thincat (talk) 09:42, 7 May 2010 (UTC)[reply]

Known future updates

Resolved

I just added details of a forthcoming event, to be held on on 16 July 2010, to David Lack#Honours. It would be good if I could add a template, say {{Update pending|2010-07-17}} and/ or category, say "Category: Articles requiring update on 17 July 2010"; so that interested editors could watch for updates due on the given date, and make the necessary tense or other changes. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:21, 5 May 2010 (UTC)[reply]

Template:Update after might be what you are looking for. Using the template will make an "update me"-box appear on an article on a given date. --Conti|✉ 11:38, 5 May 2010 (UTC)[reply]
Just the job; thank you. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:42, 5 May 2010 (UTC)[reply]

Commonly available chemicals

Would it be good to add brief descriptions of ways to make certain chemicals in the List of commonly available chemicals, such as is added to muriatic acid? --Chemicalinterest (talk) 17:12, 5 May 2010 (UTC)[reply]

I think there is a chemistry wikiproject, which might have a better audience for your question. Maurreen (talk) 17:17, 5 May 2010 (UTC)[reply]
If you have to make them, they are they really commonly available? As it is, that "article" is really more of a how-to guide, and not really suitable for an encyclopaedia. An issue that has been raised before, with nothing apparently done to address the problem. OrangeDog (τ • ε) 19:28, 5 May 2010 (UTC)[reply]

Finding archives of dead links

Hey there. I have written a bot (currently pending approval) that is designed to help fixd dead links on wikipedia. The bot works like this:

  1. Scans an article for dead links (that are used between <ref> tags)
  2. Comes back 5 days later to see if they are still dead.
  3. If yes, the bot looks for corresponding |accessdates. If none can be found, the bot uses wikiblame.
  4. The bot then looks in the internet archive for the closest copy to the access-date (within 6 months).
  5. The bot updates the |archiveurl and |archivedate parameters where available. Otherwise it uses the {{Wayback}} template.
  6. All links that are dead that did not get archived get tagged with {{Dead link}}.

I did an example edit, under my own account, to show what a bot's edit would look like. The bot, of course, obeys {{nobots}} and {{bots}}. I had seem some support for this type of task, but I wanted some reassurance that there was consensus. Any and all questions/suggestions are welcomed! Cheers Tim1357 talk 10:40, 6 May 2010 (UTC)[reply]

What about looking at WebCitation to see if an archive exists there as well?—NMajdan•talk 13:22, 6 May 2010 (UTC)[reply]
Good idea. In fact, their archives generally reflect the archived page better. I have emailed them to ask for permission to use my bot with their service. Tim1357 talk 01:49, 8 May 2010 (UTC)[reply]
I understand the logic for finding the closest internet archive copy, but why limit it to 6 months? VernoWhitney (talk) 22:12, 7 May 2010 (UTC)[reply]
There needs to be some limit to the age difference of the archives. This is because web pages change and archives need to reflect the content that was used in sourcing the article. Tim1357 talk 01:49, 8 May 2010 (UTC)[reply]

Trans-wiki collaboration

First of all this may be more of a global Wikimedia issue, but I feel having a discussion here first would be more interesting and useful. Also, this post is, in a way, a means of getting some frustration off my chest. (Hopefully I won't bore you too much in the process)

I have an Wikipedia account since 2004, and have been an utterly satisfied user of the encyclopaedia for a long while now. Occasionally I do some edits, mostly fixing patent mistakes and reverting vandalism I happen to come across, but I never became a prolific editor. A couple weeks ago, however, I began to study programming following a particularly well written Wikibook, and I felt totally at ease with the Wikibook model (probably just because my brain is best suited to tasks more modular and self-contained than building the incredibly complex web of cross-linking articles Wikipedia is. But I digress) and began doing some serious copyediting of the book right away. I felt that I finally found my home in the Wikimedia projects, and so decided to look around to learn more about how Wikibooks worked.

My worries began when, on reading the RfD page of Wikibooks, I took issue with a particular book on physics, and decided, after checking some policies and deciding it was reasonable to do so, make an RfD against that book. You can read all the gory details on the RfD entry itself if you wish, but the issue which really concerns me is totally independent on whether that RfD will be accepted or not by the community. The problem is that at several points during the process it looked very appropriate to ask other Wikibookians with some knowledge of physics for their opinions, as it is done in a RfC around here. Unfortunately, it appears impossible to locate a single regularly active editor of any of the better Wikibooks on physics, or find a place where asking for comments on the RfD would be useful. In fact, many of the RfD discussions at Wikibooks, particularly those on "specialist" subjects like physics, get no input other than from the proponent and the (currently 12) admins (and, occasionally, from the main contributor of the book to which the RfD refers to).

A pertinent question at this point would be what Wikipedia has to do with my complaints. The answer is very simple. Wikipedia has millions of registered users, an useful RfC system, some functional Wikiprojects and lots of public recognition. Wikibooks has none of these things. The point I'm trying to make is that Wikipedia could use some, even a little bit, of its leverage and brain power to support its sibling projects. Maybe something like having smallish (10-20 people) rotating boards of contributors in the main areas of knowledge (natural sciences, humanities, computing...) dedicated to providing comments in discussions and working at improving books at Wikibooks (the members of the boards could well be permanent, but for practical reasons I guess a rotating cast of volunteers would work better). It wouldn't cost much to Wikipedia, but would help the smaller projects a lot. The way things are now, I am afraid most of the existing Wikibooks are condemned to remaining eternally as stubs, and I feel the Wikipedia community could do something about that situation.

Note that I didn't post this either at Meta or at Wikibooks, as I feel it would be more productive starting this discussion at Wikipedia. Hoping to read your opinions, whatever they are. And thanks for putting up with my lamentations. --Duplode (talk) 23:03, 6 May 2010 (UTC)[reply]

I doubt boards would get off the ground. But the basic idea of cross-pollination has merit. Maurreen (talk) 01:03, 7 May 2010 (UTC)[reply]
Encouraging cross-pollination seems worthwhile. Two ideas: find suitable wikiprojects on specific topics to try and link with; and create a Wikipedia Noticeboard specifically for transwiki coordination/collaboration. (There may already be something on Meta but that gets so much less traffic.) There's also Wikipedia:WikiProject Transwiki, which might perhaps be expanded. Rd232 talk 01:54, 7 May 2010 (UTC)[reply]
I'd like to see some Wikiprojects making an effort at cross-wiki collaboration. Wikiprojects are built to organize groups of people interested in working on a particular topic, and it would be great if some Wikiprojects were to take some off-Wikipedia content and consider improvement of it to be part of their mission. Wikibooks needs groups with knowledge of a particular topic, Wikinews could use people organizing news relevant to a field, there could be groups knowledgeable about a specific subject adding words relevant to that subject to Wiktionary. --Yair rand (talk) 01:57, 7 May 2010 (UTC)[reply]
Good to see positive responses... engaging Wikiprojects in the cross-pollination makes a lot more sense than my suggested implementation, as it uses an already existing infrastructure. Speaking of infrastructure, it is worthy to note the unified Wikimedia accounts we now have will prove incredibly useful for making it easier for collaborators. By the way, if this idea gets enough support to take off, how do you think it should be kickstarted - that is, finding the first few Wikiprojects willing to try out the system? By a global "call to arms" to recruit interested projects, or by several "private" talks with individual projects to spread the idea? --Duplode (talk) 23:22, 7 May 2010 (UTC)[reply]

Clarifying WP: shortcuts and Wikipedia: page titles

Currently, the Wikipedia: namespace contains all manner of help, guidance, policy, guideline, essay, supplementary essay, wikiprojects and other miscellaneous pages. Mostly this is not a problem (though it is untidy and contributes to confusion for newcomers), but it is at least occasionally a problem for confusing all but the most experienced of Wikipedians when it comes to referring to policies, guidelines, and essays - particularly in cryptic shortcut form - in discussion. Two related proposals to improve this situation (more ideas welcome):

  1. Have a bot expand shortcuts on talkpages where wikilinked. So WP:NPOV becomes Wikipedia:Neutral point of view. Basically, decryptify shortcuts a bit.
  2. Create a "Policies and guidelines" pseudospace and PG: pseudospace for relevant shortcuts, and move policies and guidelines there; and/or an "Essay" pseudospace and E: pseudospace, and move essays there. Create a U: pseudospace for shortcuts for userspace generally, but of particular relevance here to create appropriate shortcuts for userspace essays. Basically, make it clearer from the links what the target is.

Note that point 2. in prior discussion at WP:VPD was felt to possibly be an attempt to demote essays or discourage reference to them; far from it. It is simply to avoid creating confusion, and a sense which too often seems to arise that new users feel cheated "I thought that was a policy you were raising". Clarify that it's an essay, that it's a convenient encapsulation of a user's view in a particular situation, and communication should be enhanced and discussion should just work better. Another issue raised has been (more or less) that it doesn't matter if shortcuts are confusing; it's users' fault for not following the shortcuts whenever they're mentioned. To this I would say (a) not very helpful, or friendly to newcomers, who have to try and remember all this new alphabet soup and cryptic abbreviation; (b) even more experienced Wikipedians can get confused, and think they know what shortcut X means, but they're wrong; expanding shortcuts is just being helpful all round. Rd232 talk 00:08, 7 May 2010 (UTC)[reply]

Previous discussion: WP:Village pump (development)#Move all essays to userspace (e.g. User:Essay/Coatrack) or separate namespace (e.g. Essay:Coatrack). Flatscan (talk) 04:18, 8 May 2010 (UTC)[reply]
I think that this is more a problem with how the users link. I think people should not link shortcuts at all, especially as sole reasoningsin !votes. Rather than "Oppose WP:NPOV", I believe one should say "Oppose The article lacks a neutral point of view, a Wikipedia policy" or something of the sort to more justify their reasoning. The link and its status should be secondary, IMO. I know this would make it "easier" because people don't want to do that, but I don't think it would help anything. VerballyInsane 03:46, 7 May 2010 (UTC)[reply]
Well it's not going to make anything worse is it? It may or may not change behaviour for the better in terms of using links (I think it might), but it should certainly help other users who are reading the links follow things better. Especially new users. Please don't judge a proposal for not solving a related problem it doesn't seek to address - that's so annoying. Rd232 talk 04:09, 7 May 2010 (UTC)[reply]
I apologise. I thought that was what it was trying to address. VerballyInsane 14:35, 7 May 2010 (UTC)[reply]
I think that the essay "WTF? OMG! TMD TLA. ARG!" sums up my thoughts on this. It is not directly related, but I do not think that adding these namespaces would help unconfuse readers. The essay " What does per mean? also has a bit of information on what I think. Whenever you link to a page, whether it is policy, guideline, or essay, it is up to the person to go to it. It is also your responsibility to mention how it affects the specific situation. And for that matter, even if it is a policy, people should still feel free to refute it (or ignore all rules) if they think that it does not apply in this case. Please feel free to disagree with me. And if I'm judging "a proposal for not solving a related problem it doesn't seek to address," then I obviously missed what problem it was seeking to address and it was not on purpose. VerballyInsane 17:08, 7 May 2010 (UTC)[reply]
"Whenever you link to a page, whether it is policy, guideline, or essay, it is up to the person to go to it." - you realise that by this logic, we should ban seatbelts, on the grounds that it's up to drivers to drive sensibly? Bottom line, this is supposed to help communication. In a perfect world, it wouldn't be necessary. In a perfect world, people would communicate clearly - and probably avoid using shortcuts at all, using the full page title instead, and certainly fully explain the relevance in the context. Well we can't automatically explain, but we can automatically clarify the links. Why is this not helpful, in an imperfect world? Rd232 talk 21:34, 7 May 2010 (UTC)[reply]
I'm really confused as to what problem(s) this is supposed to solve. Sometimes shortcuts are mentioned the way that they are because that's the easiest way to do so; in an AfD where the nominating statement specifically states that the article lacks a neutral point of view, it's perfectly reasonable for follow-up statements to simply cite WP:NPOV. Hell, I find it kinda funny that you say "prior discussion at WP:VPD was felt" without spelling out the development village pump (which is far more obscure than your given example of "NPOV").
As for separate namespaces for policies and guidelines and another for essays... ugh, please, no. There's no point in it, and it's needless fragmentation. The Wikipedia: and WP: namespaces/pseudo-namespaces are for project-level pages, which guidelines, policies, and essays all are. If someone is incorrectly citing a user essay as a policy, that's a behavior issue that needs to be addressed, not a technical one. EVula // talk // ☯ // 04:31, 7 May 2010 (UTC)[reply]
It's not "kinda funny" that I didn't spell out WP:VPD - it was deliberate!! It was an illustration of how a bot expanding links can be helpful! Now you know how newbies feel all the time! Also, you're missing the point - it's not "incorrectly citing" which is the issue; this is rare. It's citing in an ambiguous way. This is common, because people often say "see WP:whatever", rather than "my opinion on this subject is encapsulated in the essay WP:whatever". I don't see the "fragmentation" argument - we have different namespaces for different purposes, this is just applying the same principle for a pretty clearly explained reason. Finally, "there's no point in it" is just plain rude. You may disagree with the point, but the point has been made. It contributes to slightly reducing the newbie-offputting alphabet soup effect. This effect has been cited often enough as a big reason why people find it hard to get seriously involved. Rd232 talk 21:34, 7 May 2010 (UTC)[reply]
Might be kind of neat if the tooltip of linked redirects displayed the target page title. Hover over these two links to see what I'm talking about: WP:NPOV · WP:NPOV.

More generally, people should simply ensure that they always link when using an initial abbreviation / initialism. And, if possible, spell out the initial instance. --MZMcBride (talk) 04:55, 7 May 2010 (UTC)[reply]

That (tooltips showing redirects) is one of my favorite features of popups. VerballyInsane 14:35, 7 May 2010 (UTC)[reply]
What about something like this: NPOV or V (code: {{User:Nmajdan/Test3|NPOV}}). It provides a tooltip and a link. Granted, the hard part would be the initial population of all shortcuts into the template, but this would allow editors to hover over the link and see what page/policy it is linking to.—NMajdan•talk 15:17, 7 May 2010 (UTC)[reply]
WP:POPUPS already does this, and it does help. But we're talking about helping make things clearer for new users who haven't found that; unregistered users who can't; or passersby who find the whole thing ludicrously impenetrable and are put off ever trying to edit. Remember them? Remember that getting new editors to replace those leaving is not an optional extra, but essential to the long-term survival of Wikipedia? We should constantly be striving to be friendlier and more welcoming, and I think these suggestions would be help. Rd232 talk 21:34, 7 May 2010 (UTC)[reply]
I usually use direct page links in my comments, varying between full page names and piped links (which show the actual link on mouse-over) displaying the common shortcuts or in running text. I use shortcuts when they redirect to specific sections, which are easily renamed, breaking direct links. I tend to avoid linking when a term has been linked nearby, e.g. in a comment that I am responding to. I think that the shortcuts will be used regardless of any discouragement (short of outright deletion and creation protection), and linking them allows inexperienced users to educate themselves and gain familiarity. Full page names are more readable, but they often contain jargon and are not substantially less opaque. Flatscan (talk) 04:18, 8 May 2010 (UTC)[reply]

Improve the WP tagline

Suggestion emerging from WP:VPD discussion: improve the WP tagline. Change MediaWiki:Tagline so that it becomes "From Wikipedia, the free encyclopedia that anyone can edit." The aim is primarily to make the nature of Wikipedia a little clearer to visitors entering the site via specific articles (which is probably the usual way). NB there is a rather old but substantial discussion at MediaWiki_talk:Tagline#.22that_anyone_can_edit.22. Rd232 talk 00:39, 7 May 2010 (UTC)[reply]

I don't think putting links in that text is the best idea. --Cybercobra (talk) 00:43, 7 May 2010 (UTC)[reply]
Visually it's unappealing, but functionally it's unavoidable if you want to give visitors an easy way to clarify the meanings. I think it's worth it. We could potentially have CSS attached to enable people to kill the formatting via their own CSS page if they want. Rd232 talk 01:47, 7 May 2010 (UTC)[reply]
I'm with Cybercobra. It looks terrible. Come back with a version that doesn't look terrible, and that still looks like a tagline, and maybe it would make sense. — Gavia immer (talk) 01:57, 7 May 2010 (UTC)[reply]
Well that's just dropping the wikilinks, isn't it? Rd232 talk 04:05, 7 May 2010 (UTC)[reply]
Yes, I honestly didn't realize that "that anyone can edit" was missing from this. I do support adding that phrasing, just not the links. — Gavia immer (talk) 15:34, 7 May 2010 (UTC)[reply]
Love the addition of "that anyone can edit," but agree that there shouldn't be links. I completely understand the reasoning; however, it just wouldn't look like a tagline. VerballyInsane 03:53, 7 May 2010 (UTC)[reply]
I think we might get used to it... but anyway, adding "anyone can edit" is good even if we choose not to have links. Rd232 talk 04:05, 7 May 2010 (UTC)[reply]
Some of you don't like the link but exactly the same link is used within the tag line on the index page. I don't see any problem with that. Xnquist (talk) 08:43, 7 May 2010 (UTC)[reply]
But that display is a very, very different form factor from the tagline that appears on every single page except Main Page. I agree with adding the "that anyone can edit" bit, but don't want to see them wikilinked. EVula // talk // ☯ // 15:28, 7 May 2010 (UTC)[reply]
  • Strong support With or without a link, it is absolutely necessary to display the "that anyone can edit" phrase prominently on all article pages. For reasons, see this recent Village pump discussion [[1]]. Xnquist 14:19, 7 May 2010 (UTC)[reply]
  • Support it with or without the link. I don't really have a preference either way on the link, but I do think the added words would be beneficial. Equazcion (talk) 14:30, 7 May 2010 (UTC)[reply]
  • Support without the links. --Cybercobra (talk) 18:15, 7 May 2010 (UTC)[reply]

Alternatives to TFA unprotection

moved from Wikipedia_talk:Today's_featured_article, including first two responses There is a lengthy and inconclusive discussion about protecting Wikipedia:Today's_featured_article. The main reason given to keep TFA unprotected is to encourage visitors to experiment and get into editing. Yet it's agreed that we don't like having our best content mucked around with: we are, in a way, treating our best content as a sandbox. If we can come up with sufficiently good alternative ways to get visitors into editing, it would make sense to showcase our best content, and have a separate sandbox. So:

  1. Add a sort of "poor man's Flagged Revs" by having a sandboxed version of the TFA prominently linked from relevant places - most obviously, MediaWiki:Protectedpagetext can detect the current TFA and display a prominent custom message "you can't edit the live version right now, but you can edit a draft version of this page", when you click the Edit button and don't have permission to edit. Basically, create Wikipedia:TFAsandbox and at the beginning of each day, seed it with the day's TFA. Allow people to muck around at will, and provide a custom Sandbox editnotice which (a) actually helps first-timers and (b) points people to the Edit Request button now available on the Edit button of protected pages (only shown if you don't have the right to edit the page). This would work best in combination with 2.
  2. Change "view source" (which may sound techy and off-putting, and certainly isn't inviting) to "edit this page". "View source" is shown if you can't edit the page - so the status quo makes sense in a way. But you want to lead people into how easy it is to edit (just get an account, make a few edits, etc), give them some info and useful links - plus that tab now has an "edit request" button if you can't edit, so it makes less sense than it used to. Let's stop putting people off editing.
  3. Drawing on Wikipedia:Cleanup, create an additional "learn to edit" box below the Featured Picture box, with various categories of Editing Things To Do. Perhaps include current content RFCs too - people might spot a controversy of interest. Include some basic instructions on how to do stuff like copyediting, wikifying, and link to more detailed ones. Bottom line: the slogan is "the free encyclopedia that anyone can edit." Yet the front page gives no indication of the different ways you might be able to contribute.

All of these are worth doing regardless of the TFA protection issue - but if they are done, the cost/benefit of keeping it unprotected would be quite different. Rd232 talk 14:25, 5 May 2010 (UTC)[reply]

I agree with 100% of this. Simple, and if fully implemented, more inviting to potential new editors than an unprotected TFA. Well thought out, Rd232. --Floquenbeam (talk) 14:40, 5 May 2010 (UTC)\[reply]
I also agree. These are excellent suggestions. --Nasty Housecat (talk) 18:09, 5 May 2010 (UTC)[reply]
Definitely support the principle- anything that helps to keep the TFA clean is great! HJ Mitchell | Penny for your thoughts? 01:39, 7 May 2010 (UTC)[reply]
I like the idea - there must be a hidden flaw - it sounds too good to be true.--SPhilbrickT 01:40, 7 May 2010 (UTC)[reply]
Hellz to the yes! :D I especially like the last one. If this had happened in the past, I would have started editing years ago. It took a lot of work to find out how to help. (Well, not a lot, but who wants to look?) VerballyInsane 03:59, 7 May 2010 (UTC)[reply]
I don't like the idea of pushing TFA edits to some sandbox. One, a sandbox is going to be much less watched, meaning the chances of someone editing a vandalized version may be higher. And secondly, the chances of any good edits being incorporated into the main article will be much smaller. If we have to protect the TFA for some reason, it would be better than nothing, but as a reason for allowing the TFA to be protected, I don't like it. If it is done, we shouldn't call it a sandbox, as that's telling users that edits there don't really matter, making it a waste of time for new users and encouraging other users to just blindly revert to "reset" the sandbox. Mr.Z-man 04:08, 7 May 2010 (UTC)[reply]
"chances of editing a vandalised version" - so? It has a radically different purpose; and removing vandalism is a far more realistic start for editing than trying to improve a featured article, don't you think? Changes aren't likely to be incorporated in the article, it's true; but then it is the TFA - changes aren't likely to be positive - and an Edit Request button is available for serious suggestions. As long as the nature of the sandbox is clear, and the Edit Request button provided (besides the talk page), it's fine. Rd232 talk 05:28, 7 May 2010 (UTC)[reply]
We might as well just protect it and leave it at that. If someone's first experience trying to make a positive edit requires them to jump through a bunch of hoops and ask for an edit to be applied or edit some sandbox and hope that it doesn't just get ignored and blindly reverted, most just aren't going to bother. Most changes won't be positive, but that doesn't mean that 0% will be, otherwise we should just protect all FAs, if they're so close to perfect that new users don't stand a chance at improving them. Mr.Z-man 20:48, 7 May 2010 (UTC)[reply]
As stated before, the main justification for not semi-protecting TFA is to allow visitors a chance to experience editing. If that objective can be met reasonably well, then the attraction of using our best content as a sandbox declines markedly. By definition, improvements to TFAs are not reasonably to be expected from passersby - and I'd question to what extent meaningful improvements can survive the vandal-fighting required by the present approach. Alternatives exist for getting improvement suggestions heard; and if clicking the Edit Request button or going to the talk page is "jumping through hoops" we might as well all give up and go home. Rd232 talk 21:17, 7 May 2010 (UTC)[reply]
Eh, is it really that hard to just do a diff from the previous day after it's done being featured and then clean the article back up? It's not that bad a trade for getting to be featured. --Cybercobra (talk) 05:03, 7 May 2010 (UTC)[reply]
Yes, that's perfectly sensible. We can call it Today's Featured Vandalism Which Used To Be Our Best Content. (eg on 5 May, TFA had about 70% of its content missing for half an hour). See extensive complaints about this sort of thing, leading to proposal of semi-protection of TFA, which the above is an alternative to: Wikipedia_talk:Today's_featured_article#RfC: Time to dispense with WP:NOPRO?. Rd232 talk 05:28, 7 May 2010 (UTC)[reply]

Should GA and A-class articles have the corresponding symbol on the article page?

See discussion at Wikipedia talk:WikiProject Good articles#Should GA and A-class articles be recognisable through a symbol on the article page? –xenotalk 13:56, 7 May 2010 (UTC)[reply]

Re-upload Commons artwork that's been deleted by Jimbo Wales

As posted by User:TheDJ: "Per comments of Jimbo on Commons, there is now a new interpretation of the existing polices regarding sexual content. Basically all images that might potentially require 2257 record keeping and that do not serve a current educational purpose are to be deleted instantly. Undeletion of these images can be discussed on a case by case basis. The effects of this new policy can already be witnessed by the removal of images in our articles by CommonsDelinker. —TheDJ (talk • contribs) 12:29, 6 May 2010 (UTC)"

Several Wikimedia Foundation members, and Commons and Wikipedia editors are in opposition to certain aspects of this policy. Of primary concern for the moment is Jimbo's unilateral removal of artwork from Commons, which wouldn't even fall under the 2257 act, which requires that "producers of sexually explicit material obtain proof of age for every model they shoot, and retain those records" (according to Wikipedia's article on the act). The rationale for these removals is that they are out of the scope of the project.

As was proposed informally at the VPP discussion, and I'm now proposing here, the removed artworks could theoretically be re-uploaded to Wikipedia for use in our articles. If broad consensus for this were to be demonstrated here, it would make for a stronger justification for re-uploading the material, and hopefully make it more difficult to reverse. Equazcion (talk) 20:07, 7 May 2010 (UTC)[reply]

  • Oppose in general, support on case-by case basis I oppose this idea. EnWiki's role is not to store information for potential use, especially pornography. On a case-by-case basis, if there exists an image, already validly used in an article which was removed from the commons, that is one thing. But turning EnWiki into a porn repository because the Commons is being cleaned up is not appropriate. -- Avi (talk) 20:19, 7 May 2010 (UTC)[reply]
    That's the intention, I believe. The proposal is not to re-upload the 255 penises that existed on Commons, but to re-upload valuable images that were being used in articles here. Jimbo isn't just deleting useless pics. He is deleting works of art and illustrations that were used in place of base porn images. Resolute 20:23, 7 May 2010 (UTC)[reply]
    Correct. That was my intention. I'm not proposing a mass-re-uploading of all deleted images; only those that were in valid use at Wikipedia articles. Equazcion (talk) 20:30, 7 May 2010 (UTC)[reply]
Almost all of the images, it seems, that were deleted were already in use in articles and a number of them were sketches or art that does not fall under the cited law. SilverserenC 20:26, 7 May 2010 (UTC)[reply]
Thank you for clarifying. I agree that there are some images whose deletion may have been a bit hasty, but there is so much garbage on the Commons that the last thing we need is to turn EnWiki into PornoWiki. -- Avi (talk) 22:45, 7 May 2010 (UTC)[reply]
Then Jimbo should have put up the ones that were clearly pornographic for deletion, but he didn't. Instead, he deleted entire categories of images, regardless of the educational and artistic images that could have been in the categories, of which there was a lot. SilverserenC 22:50, 7 May 2010 (UTC)[reply]
  • Support. For local upload of all deleted images that were in use in our articles, plus lesser support for those historical images and illustrations that do not fall under 2257. If necessary, implement a {{di-orphaned fair use}}-style system for those that do. OrangeDog (τ • ε) 20:22, 7 May 2010 (UTC)[reply]
  • Support If we follow Jimbo's suggestion of "destroy now, fix later" we are going to see many valuable and useful images fall through the cracks and be lost permanently. Moving useful and used images to en in the short term will not only allow us to maintain the quality of this encyclopedia, but will also present an outlet for Commons to restore some of the damage done by this bit of moral panic. We are seeing what images are being removed right now. Finding them later when their removal by the commons delinker bot has been buried under edit logs will be a much tougher task. Resolute 20:23, 7 May 2010 (UTC)[reply]
  • Support This law does not apply to artwork and I think the pictures that this started with (the "child pornography" that Sanger told the FBI about) don't fit under the law either, as a majority of them were artwork from a historical piece. This whole situation is just ridiculous. SilverserenC 20:26, 7 May 2010 (UTC)[reply]
  • Support but wait. As I suggested on Commons, I think patience is the best weapon here. We should take some time - maybe a few months - to let both Jimbo and the media calm down and divert their attention to other matters before we directly challenge his authority with a move like this. Jimbo does not hesitate to desysop admins who wheel war with him. The repealing of CSD T1, originally ordained by Jimbo, shows that his decrees can be reversed given community support and time. There is no deadline. Dcoetzee 20:31, 7 May 2010 (UTC)[reply]
Except this is a proposal, so it is not wheel-warring, it is consensus. He cannot desysop anyone for that. SilverserenC 20:34, 7 May 2010 (UTC)[reply]
To the contrary, he has and will block people who take action against him, regardless of consensus. That's what it means to be a dictator. I just don't think a frontal assault can win in this battle, he's too powerful. He has a dreadfully short attention span and we should use that against him. Dcoetzee 21:52, 7 May 2010 (UTC)[reply]
Wheel warring requires the use of admin tools, which are not needed to upload images. More to the point, Jimbo's authority needs to be directly challenged on this. His shortsighted actions are causing damage to the encyclopedia, and it is the responsibility of the community to react. Frankly, if this was anyone else, he would have been desysopped and blocked for this. Nobody would stand for it if you or I did this, there is no reason why we should stand for Jimbo doing it. It is the responsibility of this community to protect the integrity of the project. Resolute 20:43, 7 May 2010 (UTC)[reply]
  • Support Jimbo crossed the line on this one. EVula // talk // ☯ // 21:55, 7 May 2010 (UTC)[reply]
  • Support Because it's absolutely to remove perfectly valid pictures from articles. Ones that aren't in use, fine. But...yeah what they said above. ♫ Melodia Chaconne ♫ (talk) 22:09, 7 May 2010 (UTC)[reply]
  • Support Per others regarding Jimbo, and because he could have consulted. And should have. By supporting, I merely support the reversion of what was done by an editor acting against consensus and who will not engage on talk page.--Wehwalt (talk) 22:12, 7 May 2010 (UTC)[reply]
  • Strong Support. Unless Jimbo intends on taking down the servers, Wiki is no longer his hamster in a cage to play god with as he pleases. The copyright terms of the content and photos make this pretty clear: nobody is important, and everybody is equal. You are no different, and not an exception Mr. Wales. 7 years ago perhaps, but not today. - ʄɭoʏɗiaɲ τ ¢ 22:17, 7 May 2010 (UTC)[reply]
  • Blatant stupidity. Good quality educational images are not intended to be covered by the new rule at Commons, if there is a good quality educational image that's been deleted then it can be restored on Commons. The number of good quality educational images required per subject is small and the number of subjects requiring such images is also small. This should not be a problem to fix on a case by case basis. Wholesale re-uploading of material deleted as out of scope by Jimbo is a measure of such jaw-dropping stupidity that I am at a loss to work out how to explain to you just how stupid it is, if you don't immediately understand without it being explained. The way forward is to identify the images which are unambiguously of good educational quality and request undeletion, which will I am sure be honoured as several such requests already have. I am sure you have all seen people edit warring to have the photo of their dick on the article penis, that is not something we want to get into. Remember, our mission is to inform, not to prove to the world just how not censored we are - that would be juvenile in the extreme. Guy (Help!) 22:38, 7 May 2010 (UTC)[reply]
    This proposal is to do exactly that: re-upload the educational images that we were using, that have now been unilaterally deleted and automatically removed from articles due to Jimbo's actions. OrangeDog (τ • ε) 22:46, 7 May 2010 (UTC)[reply]
    We also want the educational ones. The thing is, a considerable amount of what was deleted was either educational or artistic. Artistic mainly. SilverserenC 22:49, 7 May 2010 (UTC)[reply]
  • So ask Jimbo for undeletion on commons. For genuinely good images this will not be an issue. My experience fo Jimbo is that he is a reasonable man who is always prepared to listen to a reasonable request, but that he has little patience with people who butt heads against him. He does not often don the "god-king" hat and when he does it's because he has really strong feelings on something, usually because of some overall impact on the project itself. Try talking to him. Guy (Help!) 09:48, 8 May 2010 (UTC)[reply]
  • Support: At least for some of the files, particularly for some of the drawings. I fully support deleting some of the grade F, shitty "porn" on Commons, but some of these deletions were completely off-the-mark. --MZMcBride (talk) 22:40, 7 May 2010 (UTC)[reply]
  • Support for encyclopedic content. I generally think Jimbo has this one right with regards to intention, but I think he's gotten things badly wrong in the implementation of his intentions. If we agree that an image is useful to English Wikipedia, I think we ought to keep it - meaning in practice that we must keep them here, and not on Commons, for now. I do not support dumping random unencyclopedic garbage here to "oppose censorship" or "archive Commons material" - we don't need even one badly-framed cameraphone shot of a penis here, let alone all the ones getting scrubbed from Commons presently. To Guy, above: I agree that the announced policy says that it isn't intended to remove educational images, but in practice, it is happening; the fact that images in use here have been deleted is proof enough of that. — Gavia immer (talk) 22:42, 7 May 2010 (UTC)[reply]
  • Support per MZMcBride. —TheDJ (talk • contribs) 22:49, 7 May 2010 (UTC)[reply]
  • Support I support it being undeleted, reuploading is unnecessary. — raeky (talk | edits) 23:04, 7 May 2010 (UTC)[reply]
    Alas, Jimbo was wheelwarring over some of his deletions earlier today, and we can't force Commons to undelete. All we can do on EN is bring the useful content here until sanity reigns there. Resolute 23:10, 7 May 2010 (UTC)[reply]
    The English Wikipedia is Jimbo's home project and the one he cares about most - I believe he'll delete them here too if we upload them today, and then we'll be right back where we started. I can only see two paths going forward: wait until he moves on and doesn't care anymore to reverse his actions; or appeal to the Board to hold a hearing regarding abuse of Jimbo's special privileges. Dcoetzee 23:16, 7 May 2010 (UTC)[reply]
If the images are reuploaded today on this Wiki, it'll be because of community consensus that is established here. If he goes and reverts those changes here, then he would be directly going against community consensus. Not even Arbcom could protect him then. I say let this proposal run for another few hours, to truly gauge consensus (even though it seems rather clear from what i'm seeing right now) and then implement whatever consensus is to do. SilverserenC 23:20, 7 May 2010 (UTC)[reply]
You think he cares about community consensus? This action is CLEAR he doesn't care about that. They got bad press, their funding was jeopardized, they stepped in and deleted anything remotely controversial to "make a stand". If you think the deletion of these images was JUST a unilateral decision of Jimbo, you're definitely mistaken. The only course here is to work with the processes and accept a higher level of censorship with images that could be considered "obcene" under the miller test and move on. The undeletion of works of art that FAIL the miller test will of course need done. But some images will never come back. Uploading them here is just going to get your account banned most likely. Thats why I support the undeletion of images that fail the miller test, and move on, afterall if it passes the miller test it shouldn't be here anyway since it has no encyclopedic value. — raeky (talk | edits) 23:27, 7 May 2010 (UTC)[reply]
As has been stated though, a large amount of the deleted images will fail to pass the third portion of the Miller Test and, thus, would not be labeled obscene. And I never said I was advocating the re-uploading of all of the images. I just stated I object to the complete deletion of image categories, without even considering the value of what they contained. SilverserenC 23:31, 7 May 2010 (UTC)[reply]
I completely agree, wholesale bulk deletion in reaction to bad press is NOT the proper action to take. — raeky (talk | edits) 23:34, 7 May 2010 (UTC)[reply]
I wonder if the press will catch onto the negative reaction Jimbo's abuse has received here and in Commons? We've gone from being the project anyone can edit to the project anyone can edit so long as they conform to the wishes of a dictator. Resolute 05:57, 8 May 2010 (UTC)[reply]
  • Support uploading relevant images locally. I look forward to the day when Jimbo is no longer permitted to use this and other projects like his personal playpen. Not only is it foolish to blindly delete content without thought and consideration, it is detrimental to every Wikimedia project that makes use of images hosted on Commons. At this point, the least we can do is repair the damage caused to this project. --auburnpilot talk 23:51, 7 May 2010 (UTC)[reply]
  • Support - We should have gotten rid of the crappy homemade porn long ago, but deleting historical images and artwork is absolutely wrong. Mr.Z-man 00:08, 8 May 2010 (UTC)[reply]
  • Support Jimbo's authority to impose policy unilaterally has long since lapsed; particularly policy this unnecessarily draconian. --Cybercobra (talk) 00:17, 8 May 2010 (UTC)[reply]
  • Support. We're about ready for WP:SNOW here. And give Wales and those acting at his behest a trout. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 00:23, 8 May 2010 (UTC)[reply]
  • Oppose. This makes no sense. Basically two things can happen: Either what we upload here would also be considered acceptable for undeleting on Commons. Then it should be undeleted on Commons so that all Wikipedias can use it. Or it wouldn't, so that we would fall in Jimbo's back by keeping lots of stuff here that he has made clear shouldn't be kept. That would of course lead to a similar deletion order here, probably with similar effects (loss of admins). Maybe Jimbo doesn't mind losing the kind of admins who would leave the project for such a silly reason. I know that I wouldn't. Hans Adler 00:33, 8 May 2010 (UTC)[reply]
  • Comment- I can understand the rationale behind uploading those few images that have legitimate uses, because it seems Jimbo did have the idea of "kill them all and let God sort them out" (ironic because normally he's God and we're not, he reversed the roles on us ;)) and he seemed to have the idea that yes, some ok photos would be deleted with the bad and we can return them on a case-by-case basis. But it should be to Commons, I dont think Jimbo would oppose reuploading those that have justification. BUT any "supports" listed here where basically the reason for supporting is "I hate that Jimbo unilaterally did this, blah blah, he had no right, blah blah" should not be considered at all. If you support this because you want to spite Jimbo and reverse him just for the sake of "teaching him a lesson" that we're in control and he's not... then go some place else.Camelbinky (talk) 00:58, 8 May 2010 (UTC)[reply]
A great number of the commenters here seem to agree with me that this was a good idea that turned into a bad action; I don't see much in the way of "support because fuck Jimbo!!!1!1!!11" here. — Gavia immer (talk) 01:03, 8 May 2010 (UTC)[reply]
Although some people are angry, there's good reason for that, IMO, and that anger can serve a purpose. In a practical sense, this unilateral action shows something about Jimbo's current mentality regarding his ownership of the project, and one that we don't want to see demonstrated again. Gaining broad consensus that the action warrants immediate reversal could be an important step towards assuring that something similar doesn't happen in the future. The unilateral "shoot em all..." logic here was not warranted. Jimbo may have said that things can be restored on a case-by-case basis, but the idea with this proposal, I think, is to systematically get everything restored that was carelessly removed from legitimate use in our articles (side note, maybe we can get this list from the CommonsDelinker contribs). Equazcion (talk) 01:40, 8 May 2010 (UTC)[reply]
Thats the thing- "his current mentality regarding his ownership", yes he literally owned Wikipedia and any "powers" he has lost have been of his own free will. Who are we to say "this thing you created you have no power over, we have the power". Kinda arrogant and rude of us... and sets a bad precendent for anyone else who wants to create anything on the internet that others can use and work on... I know if I were to create a whateverpedia I have learned from Jimbo's problems here that I would make it clear that I am the final arbiter and would never give that up. I think the biggest mistake Jimbo ever made in his life was ever making any statements that he was voluntarily giving up any type of power or right to do anything. That was/is his downfall. And frankly I think he doesnt get the credit for being as good to all of us as he has, think of the alternatives. We all know LOTS of editors around here that if they were given even half his power we'd hate it more than we hate any abuse by Jimbo. I'd say 99% of Wikipedians could NEVER be trusted with a quarter of the rights Jimbo has had/still has.Camelbinky (talk) 01:54, 8 May 2010 (UTC)[reply]
We didn't say it. He did. If he had said it belonged to him and that he retained his right to unilaterally shape it as he saw fit, and retained that position within the Foundation, we wouldn't be telling him otherwise; and that would at least be in honest consistency with his recent actions, and perhaps some people wouldn't even mind. But I have a feeling many editors would never have even joined had that been the case. The fact that we believe this place to be community-run, with no dictator, is a big reason many of us joined. Maybe you're right in that Jimbo should seek to regain control of the Foundation and then re-declare that Wikipedia is his to mold (many of us would probably leave if he did), but barring that, he's obligated to keep in his place and not act like he runs everything, because the fact is he doesn't. Whether stepping aside was a smart move on his part or not, he still made it, and claims continually to abide by it. Equazcion (talk) 02:21, 8 May 2010 (UTC)[reply]

Could someone make a list of 5 historical artworks that have been deleted and which were used somewhere other than an article about sexuality? Such a list would be compelling, and it would help people like me see if there is actually much of an issue here. — Carl (CBM · talk) 01:29, 8 May 2010 (UTC)[reply]

Actually, the number of images deleted is not very large [2], and it looks like all the ones that are works of art have been restored to commons already. — Carl (CBM · talk) 01:58, 8 May 2010 (UTC)[reply]
Sort of. That's only deletions by Jimmy. There have been a number of similar deletions by other administrators in the past few days. --MZMcBride (talk) 02:26, 8 May 2010 (UTC)[reply]
This thread is specifically about the ones bu Wales. But I also had looked at the CommonsDelinker contribs, and it looked like the vast majority there were for sexuality articles, at least the ones since May 2. — Carl (CBM · talk) 02:58, 8 May 2010 (UTC)[reply]
  • Support Commons needed a 'purge' of all those 'porn' images which are not used in any project (to which extent, I'm not pronouncing as that doesn't matter much to us), but it was badly handled (by Jimbo, the admins who made the deletions,etc), and images in use on local projects should definitely not have been deleted. Local projects depend on Commons, so Commons should be consistent in their inclusion - and deletion - policy, or make sure local projects are not impacted by changes (by notifying in advance, etc). Otherwise it means Commons is not reliable (which I've found to be the case for high risk images, fwiw), and in that case they failed. So we should take the appropriate steps to make sure our articles are not any more impacted by this situation, by locally uploading deleted images used in articles as suggested, immediately and not waiting for Commons to fix. Cenarium (talk) 03:31, 8 May 2010 (UTC)[reply]

It's worth mentioning that commons doesn't appear to support the way this was handled either: Commons:Commons:Village_pump#Support.3F, so I think I can say on behalf of commons "We're sorry for the mess". --Gmaxwell (talk) 04:04, 8 May 2010 (UTC)[reply]

Does anyone know if the other language Wikipedias have been discussing this situation also? SilverserenC 04:06, 8 May 2010 (UTC)[reply]
I am aware of [3]. --Gmaxwell (talk) 04:12, 8 May 2010 (UTC)[reply]
Should I run that through a translation machine then? :P SilverserenC 04:37, 8 May 2010 (UTC)[reply]
There are now quite a few collected on commons: [4]. The response, as far as I can tell, seems pretty similar to the EnWP response— plus a few jabs at americans for being untrustworthy. ;) --Gmaxwell (talk) 05:00, 8 May 2010 (UTC)[reply]
  • Support local uploading of all images that are used here and endangered by censorship on Commons. Of course, people who delete encyclopedic content against consensus should be desysopped, even if they happen to be Jimbo. See also m:Requests for comment/Remove Founder flag. —Кузьма討論 06:18, 8 May 2010 (UTC)[reply]
  • Support Wikipedia is not censored, and wouldn't images that were already being used in Wikipedia articles count as "for an educational purpose" by the very fact that they're used in Wikipedia articles? Also, I'm not usually around the policy pages much, so can someone explain to me why Mr. Wales has all these special powers? I thought this was a project built on consensus (with the narrow exception of obviously illegal things that could get the Foundation in trouble). --TorriTorri(Talk to me!) 06:25, 8 May 2010 (UTC)[reply]
  • Wait. People should not locally upload any content deleted on Commons before the Foundation policy or statement that Jimbo Wales has referred to as forthcoming is published. Even after that, I find it difficult to imagine the circumstances under which it would be helpful to locally upload an image that has deleted as inappropriate from Commons, as per Hans Adler above. Any questionable deletions should be discussed on Commons, not here, or we'll just needlessly multiply the drama.  Sandstein  06:48, 8 May 2010 (UTC)[reply]
No, we'd be settling the drama per consensus. And it appears that the consensus is the same across all of the Wikipedias and Commons. SilverserenC 07:10, 8 May 2010 (UTC)[reply]
It's worth mentioning that commons decision making is much slower than EnWP. You can't really say that there is a consensus there yet. It's also the case that uploading locally won't "solve" the problem for the hundreds of other projects which have lost access to these images, though I'm sure everyone at commons would understand enwp's taking care of its own content as an imperative while commons gets its act together. It would be helpful for more enwp regulars to come over to commons and express your views on how this event has impacted your project from the perspective of a "commons customer". Your positions are every bit as important as those of the regular commons community— as you'll have to cope with the ultimate results of this as much as the commons users will. --Gmaxwell (talk) 07:27, 8 May 2010 (UTC)[reply]
The board statement has already been issued: [5]. --Gmaxwell (talk) 07:19, 8 May 2010 (UTC)[reply]
Yeah, I read that earlier...it really doesn't say much. I think we were expecting a more sweeping change from the way Jimbo made it sound, but...it's not. What we're doing in this discussion is exactly what it says to do, saying that the educational images should be reuploaded. And also expressing that their method of deletion was, we believe, not the right way to go. SilverserenC 07:23, 8 May 2010 (UTC)[reply]
We're not bound to follow the same inclusion policies as commons, in fact we do not as we accept more types of copyright and licenses than commons. The foundation made a statement here which confirms that it is up to local projects to make their own inclusion policies within the general framework noted there and which were already existing. Commons need to be cleaned up of all those 'porn' images not used anywhere but images used on projects should not be deleted without alerting and it is entirely within our remit to locally upload images which we have already found to be appropriate for use in an article but which have been summarily deleted from commons without regard to local projects. Cenarium (talk) 07:25, 8 May 2010 (UTC)[reply]
I don't disagree— although the same arguments would also apply on commons and I hope the community here will go make them there as well. --Gmaxwell (talk) 07:27, 8 May 2010 (UTC)[reply]
  • Oppose Any images which could be liegitimately uploaded and kept here should be on Commons, rather than fighting for their inclusion here the communities not just enwiki and commons but pan wiki (this is affecting every wikipedia) should be working for their reinstatement at Commons.KTo288 (talk) 09:03, 8 May 2010 (UTC)[reply]
  • Support: one thousand times over. Unbelievable that these heavy-handed and out-of-process deletions happened at all. We should salvage whatever we can that has encyclopaedic value. Also, I'll link to this, as someone above also did: [6] Maedin\talk 09:35, 8 May 2010 (UTC)[reply]
  • Support - many of the deleted images are/were notable works of art (and therefore 2257 is irrelevant). Jimbo was way out of line here, he shouldn't no-one should be doing large-scale unilateral deletions, especially with such poor reasoning. - Mobius Clock 10:18, 8 May 2010 (UTC)[reply]

Examples of deleted works

For reference purposes, I'm listing some works here that were either deleted on Commons under the "Jimbo rule" and later restored by consensus, or are deleted under the Jimbo rule and not yet restored but under consideration for being restored, with links to external mirrors. A gallery is below. Taken from commons:Commons:Undeletion_requests/Current_requests.

Temporary shut down of Commons

I have proposed here: commons:Commons:Village_pump#Temporary_shutdown_of_activity to temporarily shut down edit activity at Commons, because the wheel warring is damaging that community and the communities that depend on Wikimedia Commons. —TheDJ (talk • contribs) 23:51, 7 May 2010 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=360876219"