Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Patton123 (talk | contribs) at 20:20, 16 May 2010 (→‎Move the search box to the very top and make it much bigger please). 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 
New ideas and proposals are discussed here. Before submitting:

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]
Seconded; I'm sorry but that suggestion is plain ugly, very ugly. Furthermore, if an article is hardly ever read vandalism in it will hardly ever be seen as well, so that issue does not justify deletion.--Duplode (talk) 00:31, 11 May 2010 (UTC)[reply]
The fact that such a suggestion could be made goes against the very foundation of an Wikipedia. Thankfully, there are no "readership"/"page views" requirements as of yet.Smallman12q (talk) 11:28, 11 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 " " 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 · ( · ), ⋅ ( ⋅ ), or "music flat" (the very lightweight "♭", U+266D, or ♭). 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   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]
  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]

123__km/h - Yes, I'd like it! But there is need a switch-on tag for compatibility with older wiki-code, e.g. <nbsp chars="__"/> in the any place of the wiki-page? X-romix (talk) 11:58, 14 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)">/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]
Are middots ever entered directly, as a middot character (that is, not by the '&middot' entity)? That might take some rectification, but do we have any data on extensive that is? In general I suspect that middots usually are, and should be, indicated in the markup by the entity. So instances of '&middot;' in the markup are rendered as middots, while actual middots (in the markup), as well as '&nbsp;', are rendered as non-breaking spaces. (Or would sdots or some other character be a better choice?) - J. Johnson (JJ) (talk) 20:42, 8 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]
For sure, any change of how markup is rendered should not be taken lightly. But I beg to disagree on your other points. First, how serious is this specter of 'nowiki' wrappers? That really depends on how prevalent is the use of middot (or whatever character is selected), and if they were entered (see previous comment) as actual middots, or as '&middot;' entities. In the latter case, no problem. - J. Johnson (JJ) (talk) 20:58, 8 May 2010 (UTC)[reply]
As to the clarity/simplicity/complexity issue, would not middots (or sdots or flats) be a clearer, simpler representation of hard spaces than "&nbsp;"? To use a nonsensical example, compare "zippity&nbsp;do&nbsp;dah&nbsp;a&nbsp;minute" – quick! what's the text say? – (and think of how much fun I had typing that in!) with "zippity·do·dah·a·minute". Can there be any denying that the latter is clearer to read? I would say this is not a "minor readability detail", but a definite and desirable readability improvement.
Of course, that might all depend on the prior question of whether an editor bothers with non-breaking spaces in the first place. It is recommended as a matter of style (does that make it quasi-policy?) that non-breaking spaces should be used, and I would say that "articles which do not use nbsps" – perhaps because &nbsp; is so cumbersome and clutters the markup? – is a problem to be addressed.
The only complexity I see (perhaps I am not seeing something here?) is in the implementation, which is not visible to the editors. Aside from editors who are already entering actual middot (or sdot or flat?) characters (is there anyway of searching for such usage?} the only visible difference would be seeing middots in the markup – which is an increase in clarity. I suspect this specter of "complexity" arises from fear of being required to re-program one's keyboard. Which is not the case at all, because "&nbsp;" would still be available. - J. Johnson (JJ) (talk) 21:16, 9 May 2010 (UTC)[reply]
"Aside from editors who are already entering actual middot (or sdot or flat?) characters" - these are the ones I mentioned who will be forced to use <nowiki> markers or some similar trick with text that just worked fine beforehand. Breaking existing code just to add a convenience feature is generally not a good idea. The unnecessary complexity I mentioned refers not just to "under the hood" implementation (which may or may not be difficult, I don't really know) but also to fixing any breakage resulting from the change and, finally, to adding yet another special character (the wiki markup is complex enough as it is; and &nbsp; has the advantage of being no different from what one would do in actual HTML). Finally, after reading a bit more carefully the help pages about line breaks I found that there is already a good alternative to &nbsp;. Using it, your example would read as {{nowrap|zippity do dah a minute}} . A bit more verbose maybe, but as readable as you could possibly hope - you don't even need to know that a middot (or a flat, or a sdot) actually means a nbsp. --Duplode (talk) 02:32, 10 May 2010 (UTC)[reply]
Anyone using the &middot; entity would not be affected. Anyone entering actual middot chrs. into markup could use the entity. (And because of the similarity of middots and sdots, perhaps they should be entered as entities.) As to the prevalence of actual middot, sdot, and 'flat' characters, is there anyway of finding out?
The point of the example is that '·' is clearer, more readable than '&nbsp;'. (Or, for that matter, any "entity".) The advantage of {{nowrap}} is where mutiple instances an entity can be replaced, For single instances it is no clearer and no easier than "&nbsp;". - J. Johnson (JJ) (talk) 22:06, 10 May 2010 (UTC)[reply]
I analyzed the last database dump and there are 82405 pages with middot (·), 91 with sdot (⋅), 474 with music flat (♭), 3 with blank symbol (␢) and 7965 with literal non-breaking space (U+00A0, not &nbsp;, those should probably be cleaned up). Svick (talk) 01:34, 12 May 2010 (UTC)[reply]
Data! Good work. I say middot is eliminated from consideration. - J. Johnson (JJ) (talk) 23:43, 12 May 2010 (UTC)[reply]
And (forgot to mention this), the {{nowrap}} example glosses over the first proposal, which is to give hard spaces a non-blank representation, so they can be distinguished from ordinary spaces. - J. Johnson (JJ) (talk) 19:27, 11 May 2010 (UTC)[reply]
My problem with using a middot or some other non-keyboard character isn't that there's no benefit, just very little. It only benefits the people who have some easy way to type it. Using a double underscore or a double comma has much more benefit in the number of users who can easily use it, with no more potential problems (conflicts with existing uses). I just don't understand why a middot is better than something easily typeable without having to memorize or program some key combination. Mr.Z-man 19:42, 11 May 2010 (UTC)[reply]
Keep in mind that the first proposal is simply to make actual hard spaces visible (in the markup), with whatever glyph (e.g., middot) that might be suitable. The advantage here, to everyone that might edit an article, is that a clutter of obfuscating "&nbsp;" entities can be dispensed with, making the markup clearer.
As to being limited to "people who have some easy way to type it": not so! (And I do not understand why this continues to be an issue.) As I pointed out above, there are multiple ways of entering special characters; I would argue that everyone has an "easy way" to enter such characters. I am undecided whether the easiest is to cut-and-paste using the mouse (no typing whatsoever), or (for most editors) hit ctrl-shift-space.
Not that I am unsympathetic to double-underscores or double-commas, but I think there is a convincing case against them. (Would space-comma, or even underscore-comma, work better?) The argument for having the "specialness" reside in a special character, in contrast to a special use of a character combination, gets back to picking where one wants to handle any collisions of usage. Like, I doubt if anyone wants to enter an actual ",,". But what if you wanted a hard space after a comma (e.g.: ",,,")? Is that going to be a problem? I don't know. It seems like it would be simpler in concept and more elegant (and less likely to trip across unforeseen uses) to have all actual middot (or whatever) characters rendered as non-breaking spaces, and to use the entity form where that character is to be rendered. Is that too much work? Again, I don't know (we could use some data here!), but my long experience says to stick with elegance of concept. - J. Johnson (JJ) (talk) 23:14, 12 May 2010 (UTC)[reply]

Ah! Now I see Svick's contribution. (Good work!) Okay, I think middot is eliminated from consideration, and the character to consider is sdot. (And I will offer to personally convert all 91 instances (ah, pages?) of that to the &sdot; entity.) As to the 'blank' symbol ('␢') – well, it is to the point I was making above that I do not know how to "type in" that character, but cut-and-paste works just fine (␢␢␢␢␢!). But is there an HTML entity for entering it as itself? And: I still like music 'flat', but allow as how 474 pages is a bit much. - J. Johnson (JJ) (talk) 23:43, 12 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? Happymelon 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... ╟─TreasuryTagsenator─╢ 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 (utc) 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 (utc) 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 (utc) 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 (utc) 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. Happymelon 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. Happymelon 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? Happymelon 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 857 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. Happymelon 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. Happymelon 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]
  • I'm really not a fan of not having the ability to undo what I've done. If I blocked myself, I'd like to be able to unblock myself. There are very few things I can't undo, and I wouldn't want to add one more. Useight (talk) 15:38, 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]
I'm in favor of trying talks with individual projects, there could be problems with a global "call to arms". (Just thinking aloud now, I can think of a bunch of Wikiprojects that it would be amazing if they could collaborate with sister projects. Wikiproject Video Games or one of its sub-projects working on Wikinews, some of the descendent WikiProjects of WP:COMP working on Wikibooks, WP:MED helping on Wiktionary...) Maybe the Wikiprojects could develop local "branches" on sister projects, and everyone could work together. --Yair rand (talk) 21:21, 9 May 2010 (UTC)[reply]
Collaboration on content across projects is a good idea. Anything that can spread some of en.wikipedia's momentum to other projects is good. I'm less convinced about trying to collaborate on processes. When it comes to the behind the scenes stuff, even the smaller projects prefer to maintain their sovereignty. It could end up looking like a takeover - "We don't think your processes are running efficiently enough, so we're bringing in our own people to do it right." Mr.Z-man 15:52, 8 May 2010 (UTC)[reply]
"Collaboration on content across projects is a good idea. ... I'm less convinced about trying to collaborate on processes." I understand your point about not butting WP into other projects - but how do you distinguish between the two (content/process), and still have something that enhances collaboration, especially given the problem that en.wp has the most contributors? The best I can come up with is trying to create some equivalent "wikiproject" on the other project, and creating links between the two, maybe with some kind of regular communication. Would it be impossible to get a bot to help synchronise projects (not the entire wikiproject, probably, but a noticeboard subpage say)? That could help quite a bit. Rd232 talk 14:50, 9 May 2010 (UTC)[reply]
Its not that hard to separate them. If all you're doing is collaborating on content directly via projects, that's fine. But if you're trying to overhaul their deletion process or RFC process or even just flood them with wikipedia users to make them go faster or if you're going over there to set up some new bureaucracy, then it becomes a problem. Mr.Z-man 16:10, 11 May 2010 (UTC)[reply]
These concerns are legitimate, but I feel the usefulness of having a larger pool of contributors make it worthy to find ways to deal with any new convivence issues that might arise. Of course, the wikipedians "recruited" via Wikiprojects to work in, say, Wikibooks would make their collaborations as regular members of Wikibooks, and would have to follow Wikibooks policies and respect the community they are getting into. It would be no different to what should happen if, for instance, I convinced some friends at college to make an improvement drive on Wikibooks about some subject we're knowledgeable about - except that done in a potentially much larger scale. --Duplode (talk) 18:41, 11 May 2010 (UTC)[reply]
Sure, they would have to follow local policies, but there could also be enough of them in comparison to the number of regular Wikibooks users that they could get consensus to change the policies as well if they get in their way. What might be dealing with a convenience issue for us might look like a hostile takeover to people who have been on Wikibooks for months or years. I'm not saying we shouldn't collaborate with smaller projects, I'm just saying we need to be very careful not to make it look like we're seizing control from the regulars. Mr.Z-man 19:52, 11 May 2010 (UTC)[reply]
Precisely what I meant above by 'there could be problems with a global "call to arms"'. I think this would be best started off small-scale, with a few projects helping out off-Wikipedia, preferably divided over multiple sister projects. --Yair rand (talk) 21:18, 11 May 2010 (UTC)[reply]

Some sort of cross-wiki-WikiProject thing might be beneficial. There have been times on other projects where I've felt something was an issue, but there was no analog to a WikiProject I could go to and say "okay, I feel there's a problem in the domain of topic X, what do you all think?" For instance, I don't agree with the way the categories for roads/road sign photographs are set up on Commons. If this had happened on Wikipedia, I could consult with WP:USRD and work out a consensus, but it doesn't exist over there, so I couldn't go seek the input of people specifically knowledgeable about road photos. As a result, last time that I attempted to broach that topic, it ended up with two or three Commons categorizers shouting that I didn't understand Commons and me arguing that they didn't understand the reasons the photos had been taken in the first place, and thus their categorization scheme was silly. Very little got done. —Scott5114 [EXACT CHANGE ONLY] 06:15, 11 May 2010 (UTC)[reply]

You'll find that Wikibooks has a friendly small-town atmosphere, so don't worry about encountering the same situation. -- Adrignola (talk) 21:46, 11 May 2010 (UTC)[reply]
I think this is a very important proposal. Unfortunately, if we do this we will be fighting against the software because there are no cross-wiki watchlists. There is currently a strategy discussion here (you may have to log in there separately even if you have a global account), and on the talk page I have proposed adding cross-wiki collaboration as an explicit goal. Hans Adler 09:21, 11 May 2010 (UTC)[reply]
In the short term, a bot synchronising pages across projects could to some extent make up for not having cross-wiki watchlists, no? Rd232 talk 15:35, 11 May 2010 (UTC)[reply]

(Without breaking the flow of the current discussions: I just told people at Wikibooks about this thread. --Duplode (talk) 15:59, 11 May 2010 (UTC))[reply]

I think it's a really good idea. Cross-wiki watchlists would help, sure, but there's plenty of users who have coped without them across an admirable number of projects. I think that the most feasible way to do this would be, as suggested above, have individual wikiprojects run "outreaches" to other projects. This kind of thing is a start.
A way to get more traffic (both reading and editing) would be to include these projects in a separate section of the interwiki bar. Maybe not the way the languages are structured, but there nevertheless. It might even be as simple as one link to a page listing all the Wikimedia projects, or maybe more like this:

More about Foo
Books about Foo
Quotes by Foo
Current news related to Foo
Definition of Foo
Pictures of Foo
Opinions? {{Sonia|talk|simple}} 05:40, 12 May 2010 (UTC)[reply]

{{sisterlinks}} --Cybercobra (talk) 06:11, 12 May 2010 (UTC)[reply]
Oops. Yeah, like that, but defaulted into the left column for every article. {{Sonia|talk|simple}} 09:30, 12 May 2010 (UTC)[reply]
That would be nice if it could be part of every article. For what it is worth, I have made my attempt at to the math community here over at Wt:WPM. — Preceding unsigned comment added by Thenub314 (talkcontribs)
{{sisterlinks}} just isn't applicable on every article; fact of the matter is, enwiki's scope is far, far, far broader than any other projects', so cross-pollination (which I'm all for, as evidenced by my cross-wiki edits) isn't a simple "we need to get A talking to B". EVula // talk // // 16:48, 12 May 2010 (UTC)[reply]
How about adding some optional parameters to {{Talkheader}}, to generate notes at the bottom (just above the archive links, I suppose) that for contributions of type X1 (where X1 is, presumably, something that Wikipedia is not) consider Y1 (some specific thing on a sister project), for X2 consider Y2, etc.? It's technically simple to do, once we thrash out just what the wording ought to be; readily customizable for each article; and may actually catch the attention of more contributors than something left-column-ish or Wikiproject-ish. --Pi zero (talk) 18:56, 12 May 2010 (UTC)[reply]
re: to the comments above, I would probably lean towards Sonia's stance in that the key thing is getting potentially interested contributors involved (and thus Wikiprojects are important); and things like watchlists or how extra links to sister projects would be tailored to individual articles and subjects are mostly convenience issues. On the other hand, talkheader does looks like (another) great place to slip these links into. --Duplode (talk) 19:48, 12 May 2010 (UTC)[reply]
Anyone want to just go ahead and try to organize a cross-wiki collaboration effort on a Wikiproject? Seems like it's time for some actual action, hm? --Yair rand (talk) 03:08, 14 May 2010 (UTC)[reply]
I am attempting to at W:WPM, but there doesn't seem to be a lot of interest as of yet. But maybe I am going about it the wrong way... Thenub314 (talk) 11:47, 14 May 2010 (UTC)[reply]
That link goes to Words per minute, which I feel is not the intended destination. Can't find what is, to fix it. Rd232 talk 11:53, 14 May 2010 (UTC)[reply]
He meant to point us to Wikipedia_talk:WikiProject_Mathematics --Duplode (talk) 16:23, 14 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.—NMajdantalk 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]
Indeed they may contain jargon, but surely you can't disagree that even the most jargonistic of full titles conveys more information than a shortcut. The point about breaking section links is a more substantive issue. That would suggest taking the piped approach you mention - the bot leaving the shortcut for the link part, but providing the full title for the description part of the wikilink. Rd232 talk 17:30, 8 May 2010 (UTC)[reply]
While alphabet soup is a turnoff, full page names do not convey the pages' contents. I would be cautiously supportive of a bot that converted untargeted shortcuts to full name links without changing their original appearance. Flatscan (talk) 04:35, 10 May 2010 (UTC)[reply]
"without changing their original appearance" - doesn't that mean the shortcut wouldn't look any different? What do you mean? (And if you mean that, what's the purpose of that?) Rd232 talk 09:25, 10 May 2010 (UTC)[reply]
It would change the tooltip text only, making it available if the reader needs a quick hint. My opinion is that actively removing initialisms will make users less familiar and more confused if they come across unlinked/unconverted ones. Flatscan (talk) 04:09, 11 May 2010 (UTC)[reply]

I like the idea of an auto-tooltip when using WP: space a lot. It seems like the perfect solution. ♫ Melodia Chaconne ♫ (talk) 13:44, 11 May 2010 (UTC) [reply]

OK. Sort of like a mini-version of WP:POPUP which doesn't need installing, I suppose. Anyone have any idea how to do it? Rd232 talk 07:36, 12 May 2010 (UTC)[reply]
Bot possibility:
  1. Identify shortcut links, generally of the form [[WP:SHORTCUT]].
  2. Verify that it is an untargeted redirect.
  3. Replace with a direct link to the target, using a piped link to maintain its appearance.
A slightly smarter bot could parse signature timestamps and use historical revisions to find the target at the time of comment. Flatscan (talk) 04:20, 16 May 2010 (UTC)[reply]

Improve the WP tagline

The current Wikipedia tagline is "From Wikipedia, the free encyclopedia". 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]
  • Comment I can live with limiting the improvement to merely adding "that anyone can edit" to the tagline; this clarification is worth having. But I think the reaction against having the wikilinks is slightly ironic, given the nature of Wikipedia and how fundamental wikilinking is. I think people would get used to a wikilinked version fairly quickly. And it would give helpful introductory links to new visitors in a reasonably prominent place on every page; currently the "helpful links" version is only on the front page. Rd232 talk 17:22, 8 May 2010 (UTC)[reply]
  • Support per Rd232. Specifically, (1) The wikilinking is not unattractive. (2) Even if it is, you'll get used to it. (3) Even if you don't, it's too central to our Encyclopedia to omit. (4) I would, however, like to see a javascript mock-up that we could use for a few days to confirm all this. -Agradman (until the sky stops falling, A Concerned Chicken (talk)) 22:03, 9 May 2010 (UTC)[reply]
  • Note: per consensus I have added "that anyone can edit" to the tagline. People are not so sure about the links so I have left these off for now. — Martin (MSGJ · talk) 11:22, 11 May 2010 (UTC)[reply]
What's with the full stop?—Emil J. 11:41, 11 May 2010 (UTC)[reply]
I agree, the period makes it look odd --Cybercobra (talk) 11:50, 11 May 2010 (UTC)[reply]

I think this should be changed also in the British English version, for consistency's sake. Svick (talk) 16:31, 11 May 2010 (UTC)[reply]

done. Rd232 talk 18:09, 11 May 2010 (UTC)[reply]

I think this is a major change that should not have gone ahead so quickly - especially after a mere four support votes and four days of discussion. This issue was originally brought up by someone who wanted a tag to indicate that information on Wikipedia isn't reliable (that's the message this tag sends to me, too), and the first several responders to his query indicated that they thought such a tag is a bad idea. This issue should be given a much wider forum to be discussed in - maybe send one of those "check out this discussion" tags at the top of pages, so every single Wikipedia editor can see and give their opinion on this. In the meantime, I think this change should be reverted back until that kind of broad consensus is reached. Something that's been around for six years shouldn't be changed in a day. All Hallow's Wraith (talk) 21:39, 11 May 2010 (UTC)[reply]

I agree with All Hallow's Wraith; I was really hoping (per my support vote above) that we'd move slow -- starting by creating a javascript mockup. (does javascript do that? i dunno I'm a history major.) Agradman (until the sky stops falling, A Concerned Chicken (talk)) 21:47, 11 May 2010 (UTC)[reply]
I thought from your comment you wanted a mockup for the wikilinked version. Rd232 talk 07:29, 12 May 2010 (UTC)[reply]
  • Comment: I have received a request to revert this change from All Hallow's Wraith on my talk page. I am declining to do so for now, due to the level of support shown for this change here. — Martin (MSGJ · talk) 09:29, 12 May 2010 (UTC)[reply]
    • The "level of support"? There are just 4 support votes, one of whom has now stated that he agrees with what I said. A 2005 straw poll rejected this idea with 22 "don't change it"s outnumbering 18 who voted for it (and a few others who voted for different versions). That's the kind of scale something like this should be processed on. I don't think 4 votes should be able to change 3 million articles and 6 years of status quo, not to mention overrule a previous, and considerably broader, rejection of this very idea (and that should be true in general, not just in this particular case). All Hallow's Wraith (talk) 09:59, 12 May 2010 (UTC)[reply]
      • The straw poll is not exactly recent. And the amended version matches the well-established existing slogan on the Main Page (albeit sans wikilinks), so this choice of phrasing is certainly well established. Personally I wouldn't have changed it so quickly, but it is a highly visible change, so if there's very little blowback (bearing in mind people liking it aren't likely to bother saying anything), we might conclude it's OK. Rd232 talk 10:24, 12 May 2010 (UTC)[reply]
        • The straw poll is not recent, but it took place over several months and involved dozens and dozens of editors - while this has been a small discussion with only a handful of editors. Whether the tag matches the slogan on the main page isn't really relevant to my point - I'm not discussing whether I personally believe it should be changed or not from an idealogical point of view (for the record, I think it should not be changed), I'm discussing whether it should have been changed from the point of view of the process of how changes are made on Wikipedia - in this case, too quickly and without broad support, especially compared to six years of status quo and a significantly larger discussion that rejected this exact change. All Hallow's Wraith (talk) 10:37, 12 May 2010 (UTC)[reply]
          • The previous state of things could be characterized using the words bad, misleading, and dishonest. I'm glad the issue has been finally resolved. The same tag line is on the main page and there is a very good reason for it to be on all article pages too. Thanks for making this change towards a more honest and much less misleading Wikipedia. Seriously. I don't want to sound offensive, but if there is anyone who would like to censor the truth (that it's encyclopedia that anyone can edit), then he or she has some kind of hidden agenda and should perhaps refrain from participating in the Wikipedia project. Xnquist 18:14, 12 May 2010 (UTC)[reply]
  • This doesn't strike me as a change that's so difficult to imagine or with wide implications as to require mockups and extended discussion. With how much proposals tend to fall by the wayside if we wait too long to act on them, I'm sort of glad someone implemented this. It's not like it entails a radical new concept; it agrees with what's already said elsewhere, only it's more visible. Equazcion (talk) 18:19, 12 May 2010 (UTC)[reply]
I fully agree. Xnquist 18:23, 12 May 2010 (UTC)[reply]
  • Per request, I've reverted this change. Without commenting on the change itself, I fully agree that a wider audience is required before a change to the site wide tag line is made. Please make use of WP:CENT and the WP:RFC system. --auburnpilot talk 02:58, 13 May 2010 (UTC)[reply]
  • Also without commenting on the change itself (I still have not made my mind after reading the threads), the reversal until more extensive discussions are held makes perfects sense. By the way, I find the ad hominem a couple posts above ("if there is anyone who would like to censor the truth (that it's encyclopedia that anyone can edit), then he or she has some kind of hidden agenda and should perhaps refrain from participating in the Wikipedia project.") to be slightly bizarre. --Duplode (talk) 05:22, 13 May 2010 (UTC)[reply]

Reboot: RFC

The current Wikipedia tagline is "From Wikipedia, the free encyclopedia". 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). Currently this full slogan, with links, is only used on the Main Page. Putting wikilinks in the tagline may take some getting used to visually, but it's not really a big deal and 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. NB there is a rather old but substantial discussion at MediaWiki_talk:Tagline#.22that_anyone_can_edit.22. Rd232 talk 06:42, 13 May 2010 (UTC)[reply]

I assume you don't mean to include the period? Using logical quoting would remove the ambiguity in your statement. --Cybercobra (talk) 08:16, 13 May 2010 (UTC)[reply]
OK, amended. No, the period isn't intended to be part of the tagline. Rd232 talk 09:26, 13 May 2010 (UTC)[reply]
Do we really need a tagline there at all? We already have the logo in the top left, with the slogan beneath it. If we want to reduce clutter, this seems a good place to start.--Kotniski (talk) 09:31, 13 May 2010 (UTC)[reply]
Maybe. It was suggested in the VPD discussion to amend the slogan beneath the logo. Maybe removing the tagline would be a trade-off for that. Also, I know "anyone can edit" is well established, but doesn't "everyone can edit" sound slightly more positive? Rd232 talk 09:40, 13 May 2010 (UTC)[reply]
I agree with Kotniski. I'm not much of a fan of the tagline in general. It's not as cumbersome as the longer version, but it isn't great, either. I'd probably be in support of removing the whole thing, if that was brought up. As for expanding the tagline, Jimmy Wales did once say "The tagline is short and sweet and should stay that way", and that sounds about right. All Hallow's Wraith (talk) 10:08, 13 May 2010 (UTC)[reply]
It's short, but it's not sweet. And it's not a disclaimer, it's an invitation. Rd232 talk 14:23, 13 May 2010 (UTC)[reply]
  • Support "that anyone can edit". A lot of people I know, including Wikipedia readers, still don't know this. --SmokeyJoe (talk) 09:49, 13 May 2010 (UTC)[reply]
While there is a worthy motivation for the change (making visitors aware that they can edit - and not adding a disclaimer), I still find the longer version very unappealing. In any case, one thing that must not be done is modifying the tagline on the logo, which would have even uglier results and likely wouldn't be spotted by casual visitors anyway. Finally, an admittedly silly suggestion: if we think adding links to the tagline is ugly, would making the whole thing part of the link ("From Wikipedia, the free encyclopaedia" being a wikilink and "that anyone can edit" another) improve things? At least the colour would be uniform then. --Duplode (talk) 13:34, 13 May 2010 (UTC)[reply]
Possibly. Personally I think people are just really used to it, and vastly overestimate how objectively pretty the status quo is. I mean, just take a minute on a Random Article to really stare at that title/tagline. What's so great about it? Also, Wikilinks are so core to WP that it seems odd to object to a couple more. It's just what people are used to I think. Rd232 talk 14:21, 13 May 2010 (UTC)[reply]
  • Support changing the tagline, oppose changing the logo. Neutral on links in the tagline. Gigs (talk) 14:49, 13 May 2010 (UTC)[reply]

It couldn't be more obvious what that hidden agenda is. The more you pretend you don't know it, the more you discredit yourself. 94.113.158.92 (talk) 17:33, 13 May 2010 (UTC) Anyway, is this a joke? All it takes to revert a consensual change is one late request from a random unimportant member on a Talk page? Tell me this is a joke! 94.113.158.92 (talk) 17:33, 13 May 2010 (UTC)[reply]

I would like to remind to 94.113.158.92 that there is no deadline, and ask her/him to define what is an "unimportant member". --Duplode (talk) 18:14, 13 May 2010 (UTC)[reply]
  • I object to adding links (mostly per wp:overlink), but am neutral on the tagline change. -- Quiddity (talk) 17:48, 13 May 2010 (UTC)[reply]
  • oppose. Free is better. "that anyone can edit" on its own implies low quality unchecked neither of which is true. In practice we do not want some people editing things (vandals for example). --BozMo talk 18:16, 13 May 2010 (UTC)[reply]
    • What do you mean "on its own"? The proposal is for "From Wikipedia, the free encyclopedia that anyone can edit". And of course this is not an original slogan: it's been on the top of the Main Page for a long time. PS is "everyone can edit" better? Rd232 talk 18:21, 13 May 2010 (UTC)[reply]
      • He probably refers to the "alternative" disclaimer interpretation of the phrase. --Duplode (talk) 18:26, 13 May 2010 (UTC)[reply]
  • Suggestion What about different wordings? How do you feel about, for instance, "From Wikipedia, the open encyclopaedia" ? A bit vague, maybe, but suggests the spirit of the project better ("free" on its own can be easily taken simply as "gratis") while not looking like a disclaimer. --Duplode (talk) 18:26, 13 May 2010 (UTC)[reply]
  • Oppose: Wikipedia used to be the encyclopedia anyone can edit. That's less and less true every day. TotientDragooned (talk) 19:13, 13 May 2010 (UTC)[reply]
  • Hah Hah! Good comment. So true. What if we siphon off all the BLPs to a separate project? --SmokeyJoe (talk) 21:23, 13 May 2010 (UTC)[reply]
  • Oppose: To quote myself from the earlier discussion: "The tagline is fine staying the way it always has been without being dumbed down by this phoney addition. The word "free" is indeed ambiguous, and in that context that's the way it should be. The tag line does have a marketting quality, and that's just fine too. When you have an effective tagline don't spoil it with an anticlimactic qualifier. Others may call themselves "the free encyclopedia", but that's their concern, not ours. There is no need to tell people repeatedly on every page that they can edit. Let it come to them as a eureka moment; the lesson will be better learned that way. The proposed addition is lame and based on the premise that the user is an idiot." My view hasn't changed much since 2005. Wikipedia has built a reputation as "The Free Encyclopedia", and nothing useful is accomplished by tinkering with that. Tag lines are most effective when the are short and to the pithy point; excess verbosity detracts from that. Eclecticology (talk) 20:15, 13 May 2010 (UTC)[reply]
  • After careful consideration, oppose. Eclecticology has summed up the situation quite well. If anything, I would support a change to more vague wording (as in my suggestion above), and not to a more specific one. --Duplode (talk) 20:42, 13 May 2010 (UTC)[reply]
  • Oppose, the situation hasn't changed since 2005, when this was last discussed. Titoxd(?!? - cool stuff) 20:49, 13 May 2010 (UTC)[reply]
  • (weak) oppose. As the tagline currently appears on articles, adding "that anyone can edit" will make it unfit for purpose. The main page already says that it's a free encyclopedia that anyone can edit; there's no need to reiterate that on every article at a tagline location where all we really want to say is "from Wikipedia". "The free encyclopedia" serves to explain the character of Wikipedia, which may be useful; however adding "that anyone can edit" seems to go a bit too far into explaining the working mechanisms. --Deryck C. 22:23, 13 May 2010 (UTC)[reply]
  • Weak Oppose On further thought, it just makes the tagline too long/verbose. --Cybercobra (talk) 01:37, 14 May 2010 (UTC)[reply]
  • Oppose, as Titoxd said. — Ilyanep (Talk) 20:51, 14 May 2010 (UTC)[reply]
  • Oppose—I think that it would be needlessly verbose to add the "that anyone can edit" part. The tagline flows very nicely as is, and I don't see value in an addition. {{Nihiltres|talk|edits|}} 23:15, 14 May 2010 (UTC)[reply]
  • Oppose ISP editors can not edit to create, and any page that is protected or semi-protected is by definition not a page "that anyone can edit." In my book, adding the line that anyone can edit with such restrictions in place would be false advertising in a broad sense, and how does that make us look in the eyes of the public? Lets just keep it as it is. TomStar81 (Talk) 00:51, 15 May 2010 (UTC)[reply]
  • Oppose There are various aspects of Wikipedia that we might wish to promote, that it is editable is one of them, but is not - for most users - the main reason they are here. I love the collaborative nature of Wikipedia, and that is why I am an editor. But I came here initially mainly to look stuff up (after that, that's what an encylopedia is for) not to write stuff - and, funny enough, I still come here to look stuff up. Highlighting the editing aspect is too inward looking - it's what us editors think of Wikipedia, but we are - I think - only 1% of Wikipedia's users. 99% of users come here because it's a "Free Encyclopedia". SilkTork *YES! 19:58, 15 May 2010 (UTC)[reply]
    • I can accept a lot of the oppose rationales, but not entirely that one. We want more people to be more conscious of how WP works, and thereby be more likely to contribute. Raising the proportion of contributors from 1% to 2% of visitors would have a massive impact. Rd232 talk 20:44, 15 May 2010 (UTC)[reply]
  • Oppose; a short and sweet tagline works best and the current version projects precisely the image we want. Christopher Parham (talk) 02:42, 16 May 2010 (UTC)[reply]
  • Oppose, again. I still hold that being a free encyclopædia is more a defining principle of Wikipedia than its being editable. Moreover, we're talking about a tagline here, so KISS should surely apply. Only the most emblematic quality need be stated. To say more, especially as in the proposed addition (editable by anyone? never, by any means), is to mess with a successful formula. There are more important things to be concerned with.cj | talk 14:25, 16 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]
Agree with all although I think they should be expanded to cover all semi-protected articles, not just TFA, especially proposal no. 2 (the changing of View source to Edit this page). It would really help us earn more users. Narutolovehinata5 tccsdnew 04:12, 9 May 2010 (UTC)[reply]
I don't want to be a downer, but I think I said this before the last time this came up, and if not I'm saying this now just in case. I see little point pushing the TFA protection change angle at the moment. From Wikipedia:Village pump (miscellaneous)#Flagged Protection: update for May 6 & [2] it's apparent flagged protection isn't that far aware. I can't say you'd definitely convince the community to use flagged protection on TFA, but I do think it's pointless to spend time on this, when things could very well different in a few months with another obvious option particularly since a number of these changes may require enough work (the sandbox/poor mans flagged protection idea is an obvious one that seems a bit pointless) and that combined with the RFC and associated likely lengthy discussions to get any such substanial change to the way we treat TFA. Nil Einne (talk) 04:40, 12 May 2010 (UTC)[reply]
"I don't want to be a downer"... um, your various increasingly expansive posts wherever this idea is mentioned are starting to suggest otherwise. Rd232 talk 09:41, 13 May 2010 (UTC)[reply]

FYI, I pulled points 2 and 3 out of this discussion to pursue on their own merits (forgetting TFA issues). See MediaWiki_talk:Viewsource#Change_View_Source_to_Edit_This_Page and Talk:Main_Page#Adding_a_how-to-contribute_box. Rd232 talk 16:45, 12 May 2010 (UTC)[reply]

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

Update: see the discussion on Commons, where previously deleted images are being reviewed. SJ+

Original discussion

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

The proposal is still a draft; apologies have been made for deleting without discussion, and Commons is undeleting and discussing the ~70 images affected. SJ+ 13:33, 9 May 2010 (UTC)[reply]

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]
    That suggestion has been retracted. SJ+ 13:33, 9 May 2010 (UTC)[reply]
  • Support Rediculous to bow to pressure from Fox News against consensus. Falcon8765 (talk) 03:45, 10 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 (talkcontribs) 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 [3], 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 [4]. --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: [5]. 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: [6]. --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. I'll link to these, as others have also done: remove founder flag and petition. Maedin\talk 09:35, 8 May 2010 (UTC)[reply]
    • Do please review the delinker history. If any project feels that an image has encyclopedic value, I expect that would be a strong reason for Commons to keep it. SJ+ 08:21, 9 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]
  • Oppose - This just shifts the fight from Commons to here. --mav (Urgent FACs/FARs/PRs) 14:40, 8 May 2010 (UTC)[reply]
    Given Commons feeds all Wikipedia projects, the fight was brought here against our will. Resolute 15:01, 8 May 2010 (UTC)[reply]
    Rather than reuploading, simply mentioning on Commons that an image is needed here should be strong incentive for it to be restored. I feel that inclusion policies should be handled at the individual project level, not at Commons itself (which for various reasons should have the most inclusive policies of all Projects). SJ+ 08:21, 9 May 2010 (UTC)[reply]
  • Oppose. Go to Commons and support undeletion there for files that deserve it. Some of the undeletions that have already been performed show that Jimbo went overboard and deleted items that he shouldn't have, but the very fact that they have been restored shows that the Commons undeletion process works. Making local copies of files that are acceptable for Commons defeats the purpose of having Commons in the first place, and there is no magic that makes a file unencyclopedic pornography on Commons but a useful educational illustration on en-wiki. --RL0919 (talk) 15:08, 8 May 2010 (UTC)[reply]
  • Oppose I fully agree with Jimbo on this, and Wikipedia should not become another free porn server. If there are encyclopedic images needed for encyclopedic articles about sexual or other sensitive topics, I am sure there are ways to get them without violating any laws, and even if a few are missing, a brief textual description would suffice, as the goal is to inform, not to titillate. I trust Jimbo's judgment on what rules are needed for image content. Crum375 (talk) 15:09, 8 May 2010 (UTC)[reply]
    • File:Franz von Bayros 016.jpg is not porn except by the most prudish definitions, nor does it violate any laws (its not even a photograph). That didn't stop Jimbo from deleting it twice though. Mr.Z-man 15:44, 8 May 2010 (UTC)[reply]
      • Even Jimbo is not perfect, and this was likely caught up in a big sweep of a lot of other stuff. As you can see, he didn't delete it again. Crum375 (talk) 16:06, 8 May 2010 (UTC)[reply]
        • One thing Jimbo routinely shows is incredibly poor judgment. Holding him to perfection is not reasonable. Holding him to the same standard as every other admin is not an unfair request however, and given he is not capable of exercising good judgment in using the tools, he should limit his activities to getting board support on writing directives commanding admins with good judgment to do the work so that good images and works are not "caught up in a big sweep". Resolute 16:27, 8 May 2010 (UTC)[reply]
        • I must say that i'm rather appalled that this ever got deleted, though I suppose that's what happens when you hit delete all in a category, which should never be done. I don't even know why there's a tool for that. SilverserenC 17:41, 8 May 2010 (UTC)[reply]
          • It's like the big red "delete entire account" button that some systems offer you -- one click to oblivion. SJ+ 08:21, 9 May 2010 (UTC)[reply]
        • Not perfect is one thing. Doing something blatantly wrong twice though is pretty close to the opposite side of perfect. As noted below, he incorrectly deleted another historical work 3 times. Mr.Z-man 18:41, 8 May 2010 (UTC)[reply]
      • That's...strange. When I checked that record yesterday, Jimbo had deleted the file three...oh wait, never mind, this is a different file. He deleted the Sainte Therese picture three times and it was restored by a different admin each time. SilverserenC 17:41, 8 May 2010 (UTC)[reply]
    • None of them violated the relevant law, it's not the issue at all. Whatever happens on commons we should maintain the integrity of our articles; if we have decided by consensus that an image is appropriate for use in an article and it is deleted at commons without warning, then we should upload it locally and warn those responsible that it can hurt our trust in commons as media repository. Period. Cenarium (talk) 15:46, 8 May 2010 (UTC)[reply]
      • Did they all include the 2257 records? If not, wouldn't actual photos be illegal, if sexually explicit? Crum375 (talk) 16:12, 8 May 2010 (UTC)[reply]
        • That could apply only to photos, not drawings or paintings. I'm not pronouncing on that, it's not up to editors to discus legal matters outside the framework defined by the WMF. It's to them to determine that but for now as you can see in their statement on func-l, they didn't ask for projects to change their ways in this regard. What I mean is that the deletions were not based on any kind of legal considerations mandated by the wmf but on the intent by Jimbo to clean up commons from 'porn'. So that potential legal justification can't be used retroactively especially when it evidently doesn't apply to the vast majority and commons' and wp's editors already screened those extensively and they remain displayed in wp articles for a long time. I support that endeavor to cleanup commons from unused 'unworthy porn', for lack of better designation, but it should not adversely impact projects. Cenarium (talk) 19:17, 8 May 2010 (UTC)[reply]
  • Partial support. Artwork like File:Félicien_Rops_-_Sainte-Thérèse.png and File:Franz von Bayros 016.jpg probably doesn't require 2257 records. Pictures like File:Masturbating_hand.jpg, even if used for educational purpose, probably do require such records in the USA, where the servers are hosted. We should hear from Mike Godwin on this issue. It's sad that Mr. Wales has succumbed in such pathetic manner ([7] [8] [9]) to the pressure of Faux News. Read this for further details. Did I mention the Foundation is equally pathetic in their unconditional support for such actions. It's become nothing more than a PR machine of large corporation: almost completely disconnected from its "employees" (editors in this case). The head honcho does Soviet-style work visits and the party PR machine applauds. LOL. I see our ArbCom also supports this approach. I'd better watch out what I say here now, lest I find myself under wp:pedophilia style ban under the ever expanding written and unwritten wikirulz. Pcap ping 16:31, 8 May 2010 (UTC)[reply]
    • I'm not seeing any evidence that this supposed legal concern was anything more than a sudden assumption by people who don't actually have legal expertise. Not to mention that this sudden realization that we're hosting illegal pornography came after it's already been hosted for what is it, 5 years? The concern over 2257 records has been brought to Godwin repeatedly in that time, as is my understanding, and he's never mentioned that any action might be required, at least not publicly. Godwin's say-so should rightly have been the only justification for all these removals. I don't doubt that Jimbo might backpedal as a result of all the criticism and tell everyone that he didn't just make some rash decision on his own, and that he did consult Godwin first; but if that were true then he would've said so to begin with. Equazcion (talk) 16:49, 8 May 2010 (UTC)[reply]
      • There is no pressing legal concern. (Though it's about time images without clear model release forms and other paperwork started being rejected, just as we reject likely copyvios without a release.) SJ+ 08:21, 9 May 2010 (UTC)[reply]
Perhaps some more good faith needs to be given to Jimbo, one must assume that in his position he has access to information and knowledge not available to the rest of us. If the Foundation has not stepped up to say he was wrong, who are we to say "screw him". I personally dont think he has to explain himself, not when doing what he did, nor now. I would imagine that is why he's been quiet here, at village pump (policy), and his own talk page (amazing this discussion is occuring in at least three places....). He may simply feel that if other editors are going to basically say "screw what Jimbo says/does" that he should do the same about you who criticize him. I dont see the Foundation doing anything against him, and unless they do there's nothing anyone can actually do against him. Wikipedia IS Jimbo's reputation, he and it are linked in name long after he dies, he has a vested interest that none of the rest of us have. Please understand and try to see it from his point of view. Yes, he may have overreacted, I have this question for any of you who are criticizing Jimbo- would any of the rest of you really not do the same if you were personally being singled out in the media? If you answer that you wouldnt, then either your lying to me (and/or yourself) or if your being honest I sure wouldnt want you in charge because you'd do a worse job than Jimbo around here.Camelbinky (talk) 17:53, 8 May 2010 (UTC)[reply]
Please don't spread misinformation. There is no reason to believe that there is any perceived legal risk involved. --Gmaxwell (talk) 18:04, 8 May 2010 (UTC)[reply]
What? Where in my post did I say anything about legal risk? Others have been legitimately talking about the legal risk, this whole thing started because of being afraid of violating an actual US law. Gmaxwell, did you read anything in my post?! I dont understand anything about yours! This entire thread has to do with legal risk.Camelbinky (talk) 18:11, 8 May 2010 (UTC)[reply]
Of course there is a reason to believe it, although I agree that the reason is also speculative. — Carl (CBM · talk) 18:57, 8 May 2010 (UTC)[reply]
(edit conflict) You're not describing good faith, but blind faith. We assume good faith in all users up to a certain point, but Jimbo exceeded that point. To demand the assumption that no matter what he does, there was good reason for it, is to regard him as god or king, rather than his actual position. You can understand his motivations if you like; I do too. You can even feel bad for him if you like; I have before. But he still isn't allowed to escape the reality of the situation by doing inappropriate things, no matter how bad you feel for him. Equazcion (talk) 18:12, 8 May 2010 (UTC)[reply]
Good faith is not a synonym for good judgment and there is no way to sugar coat just how lacking Jimbo is in the latter. As to your question at the end - that is the price Jimbo pays for wanting to be the god-king of Wikimedia. If he wants to play at being the central figure of the project, then he's going to have to have the fortitude to withstand the criticisms that will come his way. If he can't, then he needs to step aside completely as his knee-jerk reactions are only harming the project. As it is, his antics have already led to the retirement of eight admins on Commons along with several other users - and that is a project already lacking experienced admins. Resolute 18:26, 8 May 2010 (UTC)[reply]

Please let us address this at Commons. Trying to distance ourselves from Commons, where there is overwhelming opposition to the change and/or the manner in which it was carried out (see Commons:Village pump#Support?), is not the solution. We must address the problem—namely, out-of-process deletion on Commons of content which depicts sex or nudity—at its root, rather than trying to isolate ourselves from the problem.

Pages on Commons at which relevant discussions are taking place include:

  1. Commons:Village pump;
  2. Commons talk:Sexual content;
  3. Commons:Deletion requests;
  4. Commons:Undeletion requests/Current requests; and
  5. User talk:Jimbo Wales

Please join the discussions there. -- Black Falcon (talk) 19:00, 8 May 2010 (UTC)[reply]

Don't forget: m:Requests for comment/Remove Founder flag. Pcap ping 20:49, 8 May 2010 (UTC)[reply]
  • Oppose there are webpages for that kind of content and is not here. Anyone that can read will understand what an ejaculation is without having to see some editor acomplishing his exhibitionists fantasies at the expense of the seriousness of this project. Im with Jimbo on this one. Andres rojas22 (talk) 22:28, 8 May 2010 (UTC)[reply]
  • Support and remove the founder flag. Tisane (talk) 03:51, 9 May 2010 (UTC)[reply]
  • Support Per Kusma, Maedin, Pohta ce-am pohtit, Tisane on this page, and the 291 editors here: m:Requests for comment/Remove Founder flag it is time for Mr. Jim Wales to step down for the good of the project. The extremely combative atmosphere Mr. Wales continues to foster and encourage is damaging the long term viability of Wikipedia. Can we make m:Requests for comment/Remove Founder flag a Wikipedia space page? Okip 15:17, 9 May 2010 (UTC)[reply]
  • Oppose - this is really a matter for Commons rather than here, but no, the images Jimbo deleted shouldn't be re-uploaded en masse. They should instead be considered on a case-by-case basis. Personally, I support Jimbo's actions in general, but I agree he went a bit too far. Robofish (talk) 22:30, 10 May 2010 (UTC)[reply]
  • I submit that the images remain while the videos be deleted. Useight (talk) 00:32, 11 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.

We'd need to list those in use on Wikipedia. Cenarium (talk) 15:46, 8 May 2010 (UTC)[reply]
Unfortunately, such a list would be quite difficult to generate, as CommonsDelinker has already removed links to images that were in use on the English Wikipedia. Dcoetzee 20:01, 8 May 2010 (UTC)[reply]
You can use the CommonsDelinker contribs to generate that list (at least until it got blocked, but that happened pretty late in the debacle). Someone's already working on that. Equazcion (talk) 20:15, 8 May 2010 (UTC)[reply]
See here. This was generated by filtering Delinker's last 1,000 contribs through the regex "/com:ps|scope|porn|cleanup/i". Generated by User:PleaseStand. Equazcion (talk) 22:34, 8 May 2010 (UTC)[reply]


Godwin & the Board

  • Wait - give the board a chance to sort itself out rather than make more work and more people unnecessarily upset. In the meantime, compile lists to your heart's content. Rklawton (talk) 23:01, 8 May 2010 (UTC)[reply]
    • The board has already made a statement with no special directive to divert from our normal operations. So images which we have found appropriate for use in articles can continue to be used unless they state otherwise in the future. And if we need to upload them locally then nothing prevents anyone from doing so. Hopefully commons is in the process of restoring the deleted images which were in use on local projects, and most have already been restored at this time. Cenarium (talk) 23:29, 8 May 2010 (UTC)[reply]
      • This is correct. There is no reason to divert from anyone's normal operations. In general, content policy and direction are decided by the Project communities, and would not come from the Board to begin with. (There should really be a cross-Project community-run body to consider content issues, but that's a topic for another thread.) SJ+ 07:58, 9 May 2010 (UTC)[reply]
    • Statement by WMF legal counsel Mike Godwin confirming that there is no urgent legal reason for commons to change the way it operates, and per extension for local projects. Cenarium (talk) 01:27, 9 May 2010 (UTC)[reply]
      • He made it clear it's his personal position and not that of the Foundation in another post: [10]. Pcap ping 05:04, 9 May 2010 (UTC)[reply]
        • Ok, but he gave his opinion on the purported legal issues and as recognized attorney it has infinitely more credit than user's speculations, or Jimbo's opinion for that matter. Cenarium (talk) 13:20, 9 May 2010 (UTC)[reply]

Jimbo saved the day!

  • [11] Good lord, I din't realize we were so close to loosing all those sponsors! "Wales himself marked hundreds of images for deletion, all of which involved graphic images of sex acts." Excellent reporting. Pcap ping 21:36, 8 May 2010 (UTC)[reply]
  • I can't tell if this is sarcasm or not. Either way, let me just say that we were not close to losing any sponsors at all. As can be seen by Yahoo!'s response in the article at the bottom, they totally see through Fox's BS, as i'm sure all the other sponsors do. They are not so stupid as to believe anything that Fox News says (and hopefully neither is anyone here). SilverserenC 22:05, 8 May 2010 (UTC)[reply]
The sad part is that that was Jimbo's plan: [12]. Pcap ping 04:48, 9 May 2010 (UTC)[reply]
I didn't know Fox News counted as "all media". I certainly hope that's not true or we're in more trouble than I thought. To the bomb shelter! SilverserenC 04:54, 9 May 2010 (UTC)[reply]
  • If fear of bad PR from a low-quality US news source influences content decisions on global projects like Wikimedia Commons, then I'm out of here for good. Note that the German Wikipedia recently had de:Vulva as main page FA with a detailed photograph; this was heavily opposed by Jimbo, who was laughed at and ignored by the community. It caused no bad press at all, just made Jimbo lose support. —Кузьма討論 09:25, 9 May 2010 (UTC)[reply]
For what's worth, they call the most recent Commons snafu "vulva reloaded" [13] Can you imagine our Signpost publishing something like this?! Pcap ping 16:55, 9 May 2010 (UTC)[reply]
And the German press was less impressed with Jimbo's latest initiative. [14]. To balance the Board's support for Jimbo, they even cited Flo saying: "Jimmy is behaving like a vandal and breaking with the very notion of placing the decision-making power in the hands of the community". They obviously don't understand NPOV: former board members are finitto in wikiland, they shouldn't be given any air time. What can you expect from vulva-loving Germans... Pcap ping 18:07, 9 May 2010 (UTC)[reply]
Do you know what really worries me about this whole affair? I fear that as part of the fallout from the crisis from now on we will have lots of people jumping on the bandwagon and screaming "we must implement content filtering now!", or even " 'Wikipedia is not censored' must be revoked!" because "Jimbo is with us!" - and that will obviously make any constructive discussion about policy very difficult.--Duplode (talk) 00:20, 11 May 2010 (UTC)[reply]
  • Oh, and Fox has a 3rd article, saying, of course, that porn still remains. [15] What did you expect? The BBC also covered it now [16]. Pcap ping 04:39, 11 May 2010 (UTC)[reply]
The BBC story you linked to is a 2008 article about the Virgin Killer incident.—Emil J. 17:47, 11 May 2010 (UTC)[reply]
See this one. – ukexpat (talk) 17:53, 11 May 2010 (UTC)[reply]
...*holds forehead* I long for the day when the news will actually be able to correctly tell the news. Or have accurate reporting, though that's probably a pipe dream. The Fox News article repeated itself three times, word for word. I guess they were trying to bang home the point or something, but it makes them seem like a stuttering child giving a speech in front of the class. I don't know how anyone can believe this crap. As for BBC, there's barely any new content in there. Almost all of it is a rehashing of old information and the information itself is woefully out of context. Though I guess it is folly to expect any better. SilverserenC 18:07, 11 May 2010 (UTC)[reply]


It really would help if editors with any interest got involved in the undeletion requests. In order for images to be restored there has to be a consensus in favor. Only admins tend to take part as only they can see the deleted images. Many liberal admins (and other users) left the project when this started and the pro-censorship lobby is weighing in using the "new policy" as justification, even though this has largely been dismantled after debate on the Commons. Peter Damian is joining in on the side of a pro-deletion "consensus" and is probably organizing more via the Wikipedia Review. I think Wikipedians are sitting back, waiting and expecting this all to be fixed but all that's needed for evil to triumph is for good men to do nothing. --Simon Speed (talk) 22:52, 11 May 2010 (UTC)[reply]

Fixing the Wikipedia logo's errors

Read my project page. I have been fixing the Wikipedia logo's errors with PhotoShop. Before voicing your opinion, please, please read the entire page, and if you know any other typographical mistakes in the logo, please tell me on its talk page. For this, not only will I need support, because some people call the mistakes "a metaphor to the encyclopedia itself", (who will probably oppose) but I will also need authority to help me get the image onto all of the heavily protected files.

Thanks,  Awesomeness  talk  15:58, 8 May 2010 (UTC)[reply]

Interesting undertaking. Just know that only top-quality work would likely be accepted as the new logo. I just hope you're not wasting your time. But if you have the skills for it, then great. My only suggestion is that it would be cool, and beneficial, if you posted an image of your progress periodically, so people can provide input along the way. Equazcion (talk) 16:03, 8 May 2010 (UTC)[reply]
Well, I can't tell the difference unless I zoom in to more than 300% and increase the contrast. I'd love to upload it, but I'm afraid the upload will be destroyed by a faulty fair-use rationale. Uploading images has always confused me. I could upload it to an image sharing website, but that would be illegal due to copyright infringement, most likely. Could you help me?  Awesomeness  talk  17:09, 8 May 2010 (UTC)[reply]
Image summaries confuse the hell out of me too. What I usually do is find a similar image and copy its rationale. For altered Wikipedia logos, this seems to work nicely: File:Wikipedia_Logo_addendum.png. Just edit the page and copy the summary; when uploading, don't choose any license from the menu, just paste this summary instead. Equazcion (talk) 17:31, 8 May 2010 (UTC)[reply]
How's this? (File:Wikipedia-logo-fixed.png) I don't think it's perfect; there is great room for improvement, but this is just a rough draft to show you what I'm doing. Tell me if you like it, or if I should scrap it. PS: I hope I did the image upload correctly...  Awesomeness  talk  19:06, 8 May 2010 (UTC)[reply]
It looks like the overall brightness is turned up in yours. The character you fixed looks pretty good though. You uploaded correctly, as far as I can tell; I just added a description. As for whether to to scrap this, you might want to wait and see about the new logos already being developed, apparently, as TheDJ points out below. This might all be for nothing... Equazcion (talk) 19:18, 8 May 2010 (UTC)[reply]
The brightness is turned up because my version of PhotoShop is messed up and it does that when you export it as a PNG. The PSD is fine, so if anyone wants that, I could give it to them. But he's right, it is for nothing:
"And, we’ll start roll-out of a refined version of the well-known Wikipedia globe logo, correcting small mistakes and representing new languages."
I feel so stupid for not finding that... This whole thing was such a waste of time. Oh well... =(  Awesomeness  talk  19:32, 8 May 2010 (UTC)[reply]
Nah, don't feel stupid. I didn't know about that either. With all the different venues here, and the roughly 10 different wikis where foundation stuff happens, it's impossible to always be up on everything. Be glad you found out after you only worked on one character in the globe :) Equazcion (talk) 19:39, 8 May 2010 (UTC)[reply]
I suppose. It was two, actually. The Japanese one was fairly easy, but the Hindi one was very difficult. Anyways, I'm just glad DJ found this before I started correcting other mistakes (apparently there were problems with other languages like Chinese, too) and really polished everything.  Awesomeness  talk  19:44, 8 May 2010 (UTC)[reply]
EDIT: Also, I just compared the images; it's not brighter, they just use an old thumbnail for the Wikipedia logo on the top left. (It has even more problems like a weird line over the backwards N and a quotation mark before the Omega) Compare it to File:Wikipedia-logo.png.  Awesomeness  talk  19:48, 8 May 2010 (UTC)[reply]
There are special legal rules for things like logos, and it's not unlikely that only the original artist who created this one has the legal right to fix it. Hans Adler 16:12, 8 May 2010 (UTC)[reply]
So there are some extra hoops for getting the new logo in place since anything he creates would be a derivative work, but derivative works can be allowed by the copyright holder, so it's not completely hopeless. VernoWhitney (talk) 16:23, 8 May 2010 (UTC)[reply]
It depends on the specific contract between the Wikimedia Foundation and the artist, which might well say that any changes to the logo must be done by the artist (and paid for). I remember reading about a serious obstacle like this in an earlier discussion, but I can't remember the details. Hans Adler 16:27, 8 May 2010 (UTC)[reply]
My understanding is that the logo is owned by the foundation now, so if they approve of the change it would be fine. I altered the logo once to fix some problems and improve quality, and got the site to use it without any real legal concerns. Granted those were smaller changes, but the only utterance of copyright issues was "the foundation needs to approve" (my changes were deemed to only be image quality corrections, so we didn't even end up asking them). Equazcion (talk) 16:28, 8 May 2010 (UTC)[reply]

New logos are already coming. They will launch May 16th (when vector is coming as well). —TheDJ (talkcontribs) 16:28, 8 May 2010 (UTC)[reply]

Details? Who's making them? Any links to discussion or samples? Equazcion (talk) 16:30, 8 May 2010 (UTC)[reply]
I had never heard of this either...  Awesomeness  talk  17:15, 8 May 2010 (UTC)[reply]
Sorry, I was looking up a source for this, when i once again got distracted by the whole Commons debate. You can read about it here. —TheDJ (talkcontribs) 19:09, 8 May 2010 (UTC)[reply]
No...  Awesomeness  talk  19:41, 8 May 2010 (UTC)[reply]
See also Wikipedia:Village pump (proposals)/Archive 60#The Unfinished Puzzle Globe and Wikipedia:Wikipedia Signpost/2010-03-29/News and notes which may or may not add further details. -- Quiddity (talk) 20:13, 8 May 2010 (UTC)[reply]

Logo launch underway. See commons:Wikipedia/2.0TheDJ (talkcontribs) 23:49, 12 May 2010 (UTC)[reply]

Ugh, it doesn't look right. I'm not sure precisely what's setting off my reaction, but I thoroughly dislike the logo examples given there. {{Nihiltres|talk|edits|}} 01:08, 13 May 2010 (UTC)[reply]
I was about to say something similar. What bothers me, I think, is that it's a lot smaller, and the choice of font is pretty bad. They wanted to go with a free font this time; I guess the choices weren't so great... Of course we could all just need time to get used to it. Hard to be objective when you've been looking at the same logo for 5 years. Equazcion (talk) 01:19, 13 May 2010 (UTC)[reply]
The SVG version isn't small, but it's got really low-quality shading (unfortunately), which gives it a sort of matte plastic effect that tends to conjure up a school assignment in a design course for me. Of course, this isn't just useless bitching - I'm not certain it's all that easy to get high-quality shading in a reasonably-sized SVG, so if reproducibility was an issue, the plastic feel might be intentional. Gavia immer (talk) 01:27, 13 May 2010 (UTC)[reply]
Looking at the SVG, you can really tell just how non-3D the indentations between puzzle pieces are. Those 3D ridges in the present logo are a big part of why it looks so good, I think. Equazcion (talk) 01:31, 13 May 2010 (UTC)[reply]
That's probably it—the lack of, or effective lack of, convincing ridging on the puzzle pieces. I've seen some reproductions of the Wikipedia logo that failed on the same point, and it always bugs me. It's not even that the ridging is done badly, but that it's not shaded right. If you look at the 1000px version, it quickly becomes evident that the ridging's there but has such poor contrast that it appears as a solid line at low resolutions. This really ought to be fixed, at very least for the low-resolution versions. I've done a bit of (amateur) icon work, and one of the first things you learn is that low-resolution versions of icons often need tweaks—or even outright distortions—to look right. :/ {{Nihiltres|talk|edits|}} 05:27, 13 May 2010 (UTC)[reply]
Main new logo discussion: WP:VPT#New logo. Please discuss there, to keep comments centralized.
Just fyi, other useful background links: User:DragonHawk/2010 logo, official blog post, and at the foundation-l mailing list the thread with title "Along with Vector, a new look for changes to the Wikipedia identity". HTH. -- Quiddity (talk) 19:34, 14 May 2010 (UTC)[reply]

Proposal to turn on revision deletion immediately (despite some lingering concerns)

I propose we ask the developers to note and prioritize the bug report filed by FT2, but to enable revision deletion (as requested) without further delay. Previous consensus for this from October 2009 is here.

FT2's concern
Having worked with RevisionDelete intensely (producing stats for its usage,
interface work, bug hunting, oversighter), my main concern is the effect of bug
21279. Log, revision and action links break all over the place in a
non-intuitive and non-easy-fixable manner, because revisions can move between
"normal" and "deleted" -- and the two use entirely different (incompatible)
schemas and link notation.

Revisions are identified via &oldid=.. on wiki, but via Special:Undelete +
timestamp (!) if deleted.

Revisiondeleted items are identified by revisionid and the parameter
"&revision" in the link on wiki, but "&archive" if deleted.

So a revision that is deleted or undeleted (as opposed to RevDelete visibility
changed) causes any and all links to the revision, to any diffs involving the
revision, and to any delete log entries concerning revDelete actions about the
revision, to break.

Worse: even given a (deleted or normal) revision, a (deleted or normal) diff or
a log entry reference, identifying the item concerned can be very difficult or
impossible, other than by undeleting all and hoping the link works again, then
re-deleting.

Having seen this close up, this one's a "breaker" for me: Admins need to be
able to use those logs as a tool to review others' actions. I couldn't advocate
giving RevDelete to a few thousand admins across multiple wikis, until this is
resolved and links relied on by admins for scrutiny, review and understanding,
won't fail without a clue following every delete/undelete action. 

Several possible fixes are discussed in bug 21279 and include a "revision is
deleted" bit (bug 21279 comment #2, Happy-melon, also allows withdrawal of
oversight in full), once-off schema change so that all revisions whether
deleted or not use the same revisionID to identify them plus a conversion table
for old timestamp links to revisionID so existing links still work (bug 18104),
or creation of a RevisionMove tool so that selective undelete can be withdrawn
(bug 21312).

I urge everyone to review the concern raised by FT2 (talk · contribs), as it is an important one - but I feel that the swift hiding of sensitive or dangerous material should be a priority. We could implement local policy with very restrictive use (only matters that would typically need to be handled via Special:Emailuser/Oversight, for example) until the concern about transparency of revision deletion is resolved. –xenotalk 00:57, 9 May 2010 (UTC)[reply]

Enlighten me: if this going to be available to all admins (and not just oversighters), and it's so buggy, what are the benefits? Pcap ping 03:56, 9 May 2010 (UTC)[reply]
The ability to quickly hide sensitive or dangerous information on pages with over 5000 edits, and on pages generally without having to resort to clunky selective deletion or email to oversight (at which point the same log-breaking concerns come into play anyway). –xenotalk 04:02, 9 May 2010 (UTC)[reply]
realistical the breaking of all links to a given revision is an unacceptable cost.©Geni 04:39, 9 May 2010 (UTC)[reply]
  • Nah This is unneccesary and will make it far too easy to hide 'the wrong version'. Let's not pretend that all (or even most) admins will use this responsibly. Jtrainor (talk) 10:51, 9 May 2010 (UTC)[reply]
If admins are permitted todo revision delete, will they also be able to see what was deleted, just as they now see ordinary deleted edits, or will viewing be limited to oversighters? If it's the first, I see no harm, because it does solve the problem of dealing with abuse in articles with long histories without making reviewing work impossible. If it is the second, this is too powerful to be trusted to the entire body of admins. Admins fairly frequently make deletes that need to be undeleted DGG ( talk ) 14:49, 9 May 2010 (UTC)[reply]
Yes, see [17]. ("As an administrator you can still view this diff if you wish to proceed.")xenotalk 16:22, 9 May 2010 (UTC)[reply]
To clarify, administrators can already see all of these (ie, "normal" deletions done with RervisionDelete where oversighters' "suppression" flag was not used). FT2 (Talk | email) 01:43, 12 May 2010 (UTC)[reply]
  • Support Many times have I seen a delay in oversighting material simply due to the fact that an oversighter was not around at the time (or none checked the mailing list). Revdelete would greatly speed things up, as I can always find admins around on IRC, for example. fetch·comms 03:24, 10 May 2010 (UTC)[reply]
  • Support, for removing random instances of defamation in individual edits and edit summaries. I would hope that each use of such a tool would permit instant scrutiny from other admins. bd2412 T 17:35, 11 May 2010 (UTC)[reply]
It doesn't at present, the software doesn't effectively allow it.
The debug issues identified by various users (self included and part cited above) include adding basic deletion log filtering and a fix for the breaking of links, which is not a trivial or minor issue but can break the wiki trail, and prevent tracing of which admin did what actions if it's ever in question. 'Church of emacs' has said he hopes to provide the RevisionMove function, which would resolve most of the problem and Aaron has hinted he may have an approach to this as well. So far these problems are not yet resolved. Oversighters, with just a couple of dozen people using RevisionDelete, found them a problem. If the same ability were extended openly to many hundreds of users, for more matters, and with less stringent use, the issues and possible abuse becomes more concerning because they cannot be checked easily right now.
If there a specific revision is an issue, then we already have a way to handle it that avoids all these problems. Admins have long been encouraged to selectively delete the revision, then pass the details to an Oversighter who will undelete and RevisionDelete as needed. The rapid privacy effect is the same, the only difference is the entire revision is deleted for a short while, not just the privacy-breaching field. It's a little slower than admin level revDelete, but the safest workaround. FT2 (Talk | email) 01:57, 12 May 2010 (UTC)[reply]
Could you give us some examples of such breakages? And as for your suggestion to continue using the clunky selective deletion, that isn't possible on pages with over 5000 revisions. –xenotalk 14:24, 13 May 2010 (UTC)[reply]

A Higher Quality Article Above Featured Articles

I propose that a higher quality article standard above featured articles be created. This should have much stricter standards and would be to featured articles what featured articles is to good articles. (I edited the proposal because of the responses)—Preceding unsigned comment added by Iankap99 (talkcontribs) 01:15, 9 May 2010 (UTC)[reply]

I project that 0 articles would ever qualify for it. --Cybercobra (talk) 01:18, 9 May 2010 (UTC)[reply]
Yep, none of our articles is ever "perfect" in the sense that nothing could ever be added or taken away without damaging it. Of course, that's really an argument in favor of this proposal, since it would be quite easy to administrate: every article that qualifies for this status has already been identified. Gavia immer (talk) 01:24, 9 May 2010 (UTC)[reply]
This is almost biblical... "perfect"? God is not a wikipedian :P Choyoołʼįįhí:Seb az86556 > haneʼ 01:26, 9 May 2010 (UTC)[reply]
"But "Featured Article" doesn't have any units. It's an arbitrary scale mapping..." ~ Amory (utc) 01:37, 9 May 2010 (UTC)[reply]
It would be easier simply to raise the featured standards a little more, whenever it is felt that the current ones may not be enough. MBelgrano (talk) 01:48, 9 May 2010 (UTC)[reply]
What would these "much stricter standards" be, and who would be the judge? Malleus Fatuorum 03:33, 9 May 2010 (UTC)[reply]
Maybe have good articles, great articles, and featured articles? Featured articles are already supposed to be "Wikipedia's best work." You can't exceed the best. Tisane (talk) 03:53, 9 May 2010 (UTC)[reply]
Yea, something like that, you should propose that --Iankap99 04:33, 9 May 2010 (UTC)

Call them Awesome Articles. Each would involve sound, video, and a network of subarticles. They would draw the reader in, captivate him, and eventually spit him back out, gasping for breath, an hour later. When finished, they would be reviewed by a team consisting of a genius middle schooler, a high school teacher, and a nobel prize-winner in the field. They would have glossy magazine-layout versions that are printed out, monograph-form, and distributed in the gift bags at NSF and UNESCO meetings. SJ+ 08:32, 9 May 2010 (UTC)[reply]

Well, why not have some higher standard like that to aim for? And different versions for different audiences, especially for more technical subjects, is far from ludicrous. Rd232 talk 10:22, 9 May 2010 (UTC)[reply]
I'd prefer the category Super Duper Articles. Seriously, I think that as Malleus Fatuorum says, FA are meant to be the best as it is - how do you get better? Raise the bar for FA, by all means, but I don't think a new "FA+" category of pages is needed. -- PhantomSteve/talk|contribs\ 10:26, 9 May 2010 (UTC)[reply]

I will support this only if we call them Holy Shit, This Is Friggin' Awesome-class articles.
All kidding aside, I fail to see what the point of this is. If FA isn't good enough, we can up the requirements. Voila, "problem" solved. EVula // talk // // 15:38, 9 May 2010 (UTC)[reply]

The criteria have already risen enough in the last few years, but there are many articles which were featured before that and probably wouldn't be promoted if they were on FAC today. What about systematically nominating articles featured (or last reviewed) the longest time ago for FAR? (Is there a list of FA sorted by the date when they were promoted or last reviewed?) ― ___A._di_M. (formerly Army1987) 16:16, 9 May 2010 (UTC)[reply]
Yea that's true, we should do that — Preceding unsigned comment added by Iankap99 (talkcontribs)
How about "Best article in the entire Wikipedia"? Or top 5, or top 10, or something? --Yair rand (talk) 17:05, 9 May 2010 (UTC)[reply]
The "stricter standards" I mention would be simply new or more strict requirements at the Manual of Style or content policies or guidelines, and they would be approved or rejected the regular way: a user suggest something, and if gets consensus it's added, if it doesn't, it's not. But in any case, it's not a systematic process (from here to a year in the future, we may develop much more requirements than in the last year, slow down, or even stop creating new ones), so a systematic review is not a good idea. It's better to review the status of featured articles when someone actually finds problems, than merely "just in case". Or perhaps make this periodics reviews at a wikiproject, and bring the concerns to the regular process when an article with problems is found. MBelgrano (talk) 18:31, 9 May 2010 (UTC)[reply]

Something like this could easily be achieved by having a list top 20 articles by quality or something like that, and advertising it in a prominent place. It would be updated each time a new article, better than the last one on the list, passes FAC. Unfortunately I am afraid some editors would take it a bit too seriously, try everything to get their article on the list, and cause a lot of disruption. I am not sure that the benefits outweigh this cost. Hans Adler 17:20, 11 May 2010 (UTC)[reply]

Personally, I think standards creep is more of a bad thing than a good thing. It means people spend more time improving articles that are already high quality just to meet some arbitrarily higher standard. If anything, I think our quality standards could use relaxing. Mr.Z-man 20:04, 11 May 2010 (UTC)[reply]

I wouldn't put it that way! The real issue is that so much more energy tends to go into articles of more narrow interest, whereas many "basic" articles don't get that kind of attention. That may be partly because it's harder to edit those articles, but mainly it's just what excites people. "Space Age Widgetmakers: The Cartoon (episode 587)" tends to get more interest than "Widgets"... ! Rd232 talk 21:31, 11 May 2010 (UTC)[reply]
I could care less where the effort goes, I'd just prefer it to be spread around a little more. Most people will stop doing work once there's no more incentive. Once an article is "featured", there's much less incentive to continue improving it. But just think how many fewer unsourced articles we might have if people spent their time adding 2 or 3 sources to those articles instead of adding 175 footnotes to Bacteria or 176 references to Wii. Or how much time is spent checking a few articles against obscure and trivial parts of the MoS that could be spent improving the prose in articles in need of a rewrite. Its like we prefer quantity over quality for everything except (perhaps ironically) quality. We'd rather have a few "extremely high" quality articles than more "very good" quality ones. Mr.Z-man 23:39, 11 May 2010 (UTC)[reply]
How can we make articles better than FA status? I can't think of how I'd add to most of them.--Patton123 (talk) 14:31, 16 May 2010 (UTC)[reply]

Editions of articles be verified for truth so that readers can look at a verified article

Some articles (including featured and good articles) have been vandalized, or created by authors that were misinformed when they were creating the article. I propose that there be a process for verifying a specific version of an article. This process would require the article to be verified for truth and that the verification process would require a number of users to all agree that this edition of the article is completely factual. This would create a set in stone copy of the article that is protected from vandalism.--Iankap99 03:48, 9 May 2010 (UTC)

I don't think that would work... a) how could you get everybody to agree? b) what's the difference to flagged revisions?... (moreover, I'm skeptical about "truth"...) Choyoołʼįįhí:Seb az86556 > haneʼ 04:42, 9 May 2010 (UTC)[reply]
a) How do we get people to agree for featured articles now? b) What do you mean?
If you look at the feature article talk page template and click the show button it will give you a link to the state of the ariticle when it was promoted.©Geni 04:45, 9 May 2010 (UTC)[reply]
But that link isn't on the article itself
Isn't he really asking for a way of asserting that an article meets a higher level of quality? (I don't know about this "verified for truth", as that is pretty sticky, but there could be verification of references, etc.) The Good Article process sort of does that, but more as special cases. And the process suggested ("require a number of users to all agree...") is pretty naive. But perhaps some variant of the Good Article process that in a narrower respect (verifiability, "truth", general sniff test, etc.) sets some kind of standard of quality. - J. Johnson (JJ) (talk) 19:45, 11 May 2010 (UTC)[reply]

Wikipedia is based in Verifiability, not truth. "Truth" is an absolute value, and things aren't always as clear and shiny as it sounds in theory. Some topics have no truths but instead opinions with varying levels of acceptance (such as everything related to good & evil), and sometimes truth itself is under dispute (such as with ovnis) MBelgrano (talk) 19:59, 11 May 2010 (UTC)[reply]

Science articles have levels of truth. Maybe editions can be verified as vandalism free.
Yes, the contents of the periodic table are "true", for example. The problem is that when "truth" is so clear, nobody cares about it. Who would dispute the number of electrons of oxygen? When "truth" is called for, it's because there is a dispute and someone expects a higher moral authoritative concept to settle it. MBelgrano (talk) 01:52, 12 May 2010 (UTC)[reply]
I've seen a lot of vandalism of solid truths, for instance birthdates and people's occupations, etc. ♫ Melodia Chaconne ♫ (talk) 02:06, 12 May 2010 (UTC)[reply]

Template to request attention of experienced users

I sometimes feel the need to call the attention of experienced or tech-savvy users to a specific page that might not get much traffic otherwise, and I think other users probably might as well. Currently there doesn't seem to be a better option than using {{editprotected}}, but that's wrong on at least two levels: 1) the template simply isn't meant for that (e.g. when a page is not protected but there's a technical problem), and 2) not only admins are experienced users that could help.

I proposed here {{admin attention}}, from the top of my head, admittedly, and MSGJ pointed out that is was probably a bad name, and suggested me to propose the idea here. So, what do you think? Do you agree that this could be useful? And do you have any ideas for better names? --Waldir talk 22:43, 9 May 2010 (UTC)[reply]

Already exists: {{Helpme}} and/or {{editsemiprotected}} --Cybercobra (talk) 23:01, 9 May 2010 (UTC)[reply]
There's also {{admin help}}, if you specifically need an admin. Equazcion (talk) 23:03, 9 May 2010 (UTC)[reply]
(edit conflict) If you really think that another template is needed, how about the name {{fixme}}? PleaseStand (talk) 23:09, 9 May 2010 (UTC)[reply]
Is there a template for attracting the attention of an experienced admin, as opposed to the first dickhead with too much time on his hands? Malleus Fatuorum 23:37, 9 May 2010 (UTC)[reply]
There's not going to be a way of requesting the attention of someone who doesn't have too much time on their hands, since everyone who edits Wikipedia has an excess of that, or else they wouldn't be here. As for avoiding dickheads, no, I don't believe there is any such template. Equazcion (talk) 23:40, 9 May 2010 (UTC)[reply]
Your response demonstrates very well your problem. There are many here who believe in the idea of free information, freely available to everyone. Admittedly, very few of them are administrators. Malleus Fatuorum 23:59, 9 May 2010 (UTC)[reply]
You must mean "the problem with Wikipedia," then, rather than my problem, as I'm not an administrator. Besides which, having an abundance of time on one's hands and caring about Wikipedia's purpose aren't necessarily mutually exclusive. Equazcion (talk) 00:11, 10 May 2010 (UTC)[reply]
Or you could go to their talk pages and ask them specifically. If they are "dickheads", that's your fault then. -- Ricky81682 (talk) 00:46, 10 May 2010 (UTC)[reply]
Asking specifically is not a bad way to go. About once a week, I get a talk page comment along the lines of "I saw your edits to X; can you help with a situation at Y?" —C.Fred (talk) 00:48, 10 May 2010 (UTC)[reply]

And the Wikipedia:Village pump (technical) is always open if you are lost or just cannot fine the help you need on such topics. —TheDJ (talkcontribs) 01:41, 10 May 2010 (UTC)[reply]

Actually, maybe not such a bad idea

Re-reading the OP, he's suggesting a template for use at any page, to call attention for [technical?] help in that specific place. The templates we described in response are meant to go on a user's talk page, and are meant to only be responded to by one individual. We have RFC tags to call more attention over, but for technical help that'd certainly be overkill. Something in-between might be a good idea. Equazcion (talk) 01:59, 10 May 2010 (UTC)[reply]

Exactly :) --Waldir talk 07:01, 10 May 2010 (UTC)[reply]
He actually said "experienced or tech-savvy", which suggests two templates. {{experienced attention}} and {{tech attention}} would do. In theory this could be a way to bring contributors to an article talk page without the complexity of an RFC (i.e. for lesser issues, or less well-defined). Currently we have specific noticeboards for specialised categories of "experienced attention", like WP:NPOVN (and VPT or helpdesk for tech stuff), so the question is whether this approach adds value to that, enough to justify the additional complexity. Perhaps Waldir could give some examples of where this approach would be better than those alternatives. Rd232 talk 09:21, 10 May 2010 (UTC)[reply]
I think any general coding issue would qualify. If someone's trying to get a table or infobox to display correctly and can't figure out what the problem is, or there are other rendering issues on a page. Maybe even non-technical problems where someone wants to know if a page satisfies policy, or get general advice on a content issue... I can't predict specific situations, but it seems like something that could be useful. I created Template:Attention requested for the time being (shortcut {{attreq}}), which adds pages to the category Category:Pages where attention has been requested. I'm not sure how to get them listed at IRC the way {{helpme}} does though. Feel free to revise it. Equazcion (talk) 09:31, 10 May 2010 (UTC)[reply]
For clarity, it would probably be better to put "tech" in the template/category names. Non-tech issues, I'm not convinced it's better to use this approach than to direct people to an appropriate noticeboard etc. And if it is, it should really be a separate template/category. Rd232 talk 09:41, 10 May 2010 (UTC)[reply]
The use cases were stated above by Equazcion. I have felt the need for something like this every now and then, especially when dealing with templates, which more often than not "feature intrincate syntax", to use their own wording. Also, I think approaching individual editors is ok if you already know one or more that could help, but you can never be sure in each specific issue, and besides you could be bothering someone who's busy, away, or simply uninterested in the subject. Not to mention newbies that might not have a clue on who could be a good person to contact. I also would support something like {{technical attention requested}} (shortcut {{tech-attreq}}?). Apart from the IRC warning, which would be really great (does anyone know how to do that?), I wonder what other ways we could use to advertise these templates. I was thinking that the pages they are added to could be placed in Category:Wikipedia requests related to help or one of its subcats; or maybe a new category could be created, what do you think? Also, a mention in the "see also" sections of {{editprotected}} and {{editsemiprotected}} could be potentially useful. --Waldir talk 20:50, 10 May 2010 (UTC)[reply]
I get that - if it's set up, that's all very sensible in terms of how to do it. The question is the fundamental Catch 22: if you know about this template, you probably know about VPT / helpdesk and quite possibly someone to ask as well. How do you get the knowledge of either this template or the alternatives to the people who really need it? That's the problem, for me. OK, there may still be advantages, eg if users feel reluctant to bother people at those central locations... but those will be much reduced if the info problem isn't addressed somehow. Rd232 talk 07:00, 11 May 2010 (UTC)[reply]
By that reasoning, we might as well delete {{editprotected}}... I think that having users contacting individual editors to solve a given problem is a less-than-ideal way to deal with issues. For example, a technical problem can be solved much faster by someone who's already encountered a similar instance, than by a reasonably tech-savvy user who might have to investigate a bit. Multiple opinions also might help reaching a potentially better solution than the first approach. --Waldir talk 07:26, 11 May 2010 (UTC)[reply]
Btw, posting in VPT is a good option, but I believe it might be better to have some issues dealt with in the talk pages of the pages they refer to rather than having a thread in VPT which inevitably will get moved into an immense archive. That said, a problem that might cover several pages would indeed be best served in the VPT, to centralize discussion. And now that you mentioned it, I think a good option to advertise these requests would be precisely a link in the VPT header, possibly with a count of items in the relevant category. --Waldir talk 07:32, 11 May 2010 (UTC)[reply]

I was just thinking... wouldn't it be cool if we could have Twinkle-style interaction for some of this? Like a box on {{talkheader}} (and/or elsewhere), for "attention", and you click it and get a popup to choose from different kinds of attention needed, enter a description, and the script does the rest (in terms of listing at NPOVN, or making an editprotected request, creating an RFC, etc). Long-term, Wikipedia really needs to try and move towards that sort of ease-of-use. Rd232 talk 09:40, 10 May 2010 (UTC)[reply]

That might be cool, if we could prevent it from being mis/over-used; and, if we could trigger javascript from within a template, which I don't think we can really do now (at least not without something being prepared by devs first). Equazcion (talk) 09:44, 10 May 2010 (UTC)[reply]
Well that's why I said "wouldn't it be cool" - I didn't think it was something possible right now. But I think (once Flagged Revs and RevDelete are handled) that could be a future milestone. Rd232 talk 16:35, 10 May 2010 (UTC)[reply]
You wouldn't need any changes to MediaWiki for that, just to the sitewide Javascript. Mr.Z-man 18:13, 11 May 2010 (UTC)[reply]
I don't think even that's needed, the withJS URL parameter could be used instead (it still requires editing page in the MediaWiki namespace). Svick (talk) 18:44, 11 May 2010 (UTC)[reply]
Well, in that case, how about it? What's stopping us from being lots more user friendly? Rd232 talk 19:02, 11 May 2010 (UTC)[reply]

Add note about using {{OTRS pending}} to {{db-f11}}

After being informed of this, I realized that neither {{db-f11}} nor {{di-no permission-notice}} mention adding {{OTRS pending}} onto the images to prevent their deletion. Is this for some other reason I am unaware about, or has nobody just noticed? If it's the latter, I strongly support adding a note about this to prevent images from being deleted prematurely, possibly because of some unknown issue in OTRS proceedings. fetch·comms 03:32, 10 May 2010 (UTC)[reply]

Setting an upper limit to the number of templates in given article

This discussion revealed a problematic nature of Wikipedia quality standards. Not that I've something against these, on the contrary. But it became evident that sometimes there is a technical problem to stick to them. Israel article is a featured article, meaning that it meet at least most of the quality standards of Wikipedia. However, that's what get it stuck. It appear that it take a lot of time to many editors to download it. This way, the article is practically less available for reading. Reducing the number of reference templates in it could reduce its ranking. That's a paradox which I'm sure Wikipedia is not in favor of. I suggest to set maximum allowable number of citation per statement, maximum number of templates or at least, reference templates and further ruling to avoid these cases. The article on Israel is not the only article suffering from this problem, I understood that USA article and G.W Bush article also suffering the same problem. Also, I suggest this ruling will be made with special consideration of FA articles (which are also prone the most prone to this kind of problems), such that their status wouldn't be affected without additional reason.--Gilisa (talk) 16:35, 10 May 2010 (UTC)[reply]

(copying my comment from the other discussion) Putting an arbitrary cap on the number of citations an article can have isn't really the best approach. For one, it will just mean that fewer sources are used or that less detail is given in sources in order to combine them. But the loading speed is also dependent on other factors like infoboxes, nav templates, and number of links, images, and categories. A better idea would be to reduce the overall size of slow-loading articles - The Israel article is more than 9,000 words and the PDF version not including the references, bibliography, or external links is 20 pages. Or, alternately, create less-complex versions of citation templates. I've proposed this several times but no one ever seems interested. Simpler versions would have only the commonly used fields in the templates and not use the overly-complex {{Citation}} or {{Citation/core}}. {{cite journal}}, for instance offers (at least) 39 parameter options, but the majority of uses probably use less than half of those. Mr.Z-man 17:11, 10 May 2010 (UTC)[reply]
I think Z-man's right. The citation templates are the most used. A good article can easily have over a hundred. We need to do a review of the main citation templates and see what percentage the various parameters are used and then determine a long term plan for those parameters. Or, a less popular suggestion might be to create a bot that finds a fully populated (and by fully populated, I do not mean one that uses every parameter but one that has all appropriate data for that source and hasn't been edited in awhile) and converts it to a regular, text citation. I use the citation templates because they are there and I have no desire to memorize how to format various citations.—NMajdantalk 17:28, 10 May 2010 (UTC)[reply]
I agree with you both, and I really liked the Bot idea of NMajdan. I think that the Bot should also consider the time it take the server to upload the article. How can we promote this idea further?--Gilisa (talk) 17:31, 10 May 2010 (UTC)[reply]
It appears that the speed also depends on the parameters used. I currently have 400 different very simple instances of the citation template (name, title, year) in my technical sandbox as a test. The time spent on these by the server is absolutely negligible. Therefore I think that what we need is probably not simpler versions of the templates but an analysis of them to find out which parameters cause the problem, so that we can avoid them or they can be fixed.
I think much of this discussion is premature. Let's find out all the facts before doing anything drastic. Hans Adler 17:38, 10 May 2010 (UTC)[reply]
There were some problems with my test. I am no longer sure that it depends on the parameters so dramatically. Hans Adler 19:48, 10 May 2010 (UTC)[reply]
Quite. Where's the evidence that the citation templates are the cause of some pages being slow to download? All the tests I've seen appear to indicate that they have very little impact indeed, fractions of a second at worst. Malleus Fatuorum 17:41, 10 May 2010 (UTC)[reply]
Take a look at the original discussion at WP:VPT (link at the very beginning of the topic). An editor took the content of Israel and put it in their user space. The page took 45 seconds to load. Then, they broke all citation templates and the page then took less than 10 seconds to load.—NMajdantalk 18:19, 10 May 2010 (UTC)[reply]
I did basically the same test as in the VPT thread. I made 2 copies of the Israel article in my userspace (minus categories and a couple templates that added categories). In one copy, I removed the {{reflist}} and the bibliography section (which consists entirely of citation templates). By removing the reflist, the references are still in the article text, but they never get run through the parser (I verified this by reading the code for the Cite extension). In 5 tests on each, with references took on average (43.631 ± 3.776) seconds, while the version without references took (7.701±0.712) seconds. Only once did the version with references take less than 40 seconds and the version without references never took more than 10 seconds. See also bug 22134. Mr.Z-man 18:50, 10 May 2010 (UTC)[reply]

I have experimented a bit more. This was complicated by the strange fact that as soon as I copied Barack Obama into my user space, poof!, the problem was gone. Or rather, it wasn't as easily measurable as I expected. When I saved the page I had to wait as long as expected, but the HTML comment of the page served indicated an unrealistically short time for generating it. When I reloaded the page it was again very fast. What I have to do to get the realistic times:

  • pick out a version other than the latest one from the page history and load that, or
  • append "?action=purge" to the URL.

Once I knew how to test, I tested the following:

With 900 citations I get a timeout and can't measure the time. With 1000 citations the same happens, and when I look at the page later the last templates are not properly handled. They are displayed as a link to the article citation. Hans Adler 19:48, 10 May 2010 (UTC)[reply]

For context, looking at some of the longest articles, 2009_flu_pandemic_timeline has 611 unique citations (only some of them are templated); so, I think very few articles run into a template run time problem in practice (and many of them probably have other stylistic problems, e.g. WP:SIZE violations. --Cybercobra (talk) 01:09, 14 May 2010 (UTC)[reply]
List of allied military operations of the Vietnam War has been under discussion. It uses no citation templates, one named reference used 1043 times and 581 single use references. I can open it only when logged out and it takes over a minute; logged in, it times out. Apparently being logged out causes a fresh version to be served, but I never did understand the details there. So— I don't think it is just the citation templates, but possibly the Cite parser. There are several open bugs that are related to the way that cite.php handles data; see Template:Bug and Template:Bug. ---— Gadget850 (Ed) talk 00:09, 14 May 2010 (UTC)[reply]
In that case, it probably has less to do with the references and more to do with the sheer size of the article. The wikitext size of Israel is "only" 168 kB, that list article is more than twice that, 438 kB. It is currently the largest article on the site. It results in a 1.4 MB HTML page. It also has links to over 2000 pages that need to be checked for existence. Those 2 bugs are about nesting refs, which isn't really relevant to performance. Mr.Z-man 15:26, 16 May 2010 (UTC)[reply]

Modify default BibTex ID in "Cite this page"

Currently Wikipedia's "Cite this page" feature gives you a very nice BibTeX template, however it always contains the default identifier: wiki:xxx. Arguably, every TeX user has his or her own preferences on which citation Id's to use, however in my humble opinion a default identifier of the format: wiki:en:Earth ( wiki:<language code>:<Article Name> ) could as easily be replaced by something entirely individual and would give users much nicer default. Masterfreek64 (talk) 19:29, 10 May 2010 (UTC)[reply]

OT: I just checked it on a random article, and the output appears incorrect. It gave title = "Leonhard Euler --- Wikipedia{,} The Free Encyclopedia", which means that in most styles the printed title would come out with lowercase "euler" and "wikipedia". The W in Wikipedia, as well as any words with capitals coming from the article title, have to be enclosed in curly brackets. On the other hand, the brackets around "," do not seem to do anything. There are other problems with the output (it does not handle diacritics, let alone more complicated Unicode characters), but this one shouldn't be that hard to fix. And do we really want to use a spaced em-dash in the title?—Emil J. 10:36, 11 May 2010 (UTC)[reply]

Possible Suggestion For Making Wikipedia Even Better

Wikipedia is a magnificent online-encyclopedia—the, not least, but most magnificent online-encyclopedia in the world. However, there exists a thing or two missing in order to make it more magnificent.


One thing which “might” make it an improvement would be to link ‘each link’ in a sentence “at the end” of a sentence. Quite often young users (even older people) have a tendency to go to another link “before they even finish the sentence” (and, thus, get off-track onto another article rather than the one they should be researching/reading) since they may not understand the vocabulary/terminology/word which is stated. I have found myself doing this. Instead, wouldn’t it be better to say at the end of a sentence [See: and then name the terminology, such as: Greek Classical Books; Classical Books; Greek Books; Greek; Classical; Books] while providing a link to those things. This also shows a disambiguation hierarchy which students can follow. It also brings the editor/writer a means by which to find mistakes. For instance, I may have said [Classical Books; Classical; Books] while then thinking to myself: “What type of Classical Books am I talking about? Greek? Roman? or what?” This also aids the creation of in-depth "lists" as well as "category" pages.


The disambiguation hierarchy would be:

Books
Classical Books
Greek Classical Books
Roman Classical Books


This is just a thought about what I think can make Wikipedia even better.--Rujacgeh (talk) 19:08, 10 May 2010 (UTC)[reply]

Personally, I would get (even more) distracted by links inside a bracketed block. For me the best way of reading Wikipedia is by opening any interesting wikilinks in a new browser tab and then usually reading them later on (although I often go overboard with that and end up with 50 open tabs which I never would manage to read anyway :-) )--Duplode (talk) 23:50, 10 May 2010 (UTC)[reply]
This MIGHT have been an interesting something to think about (but almost certainly not implament) if tab browsing didn't exist. But since all the major browsers have tabbed browsing, it's pointless to even think about. ♫ Melodia Chaconne ♫ (talk) 13:47, 11 May 2010 (UTC)[reply]

This question was also asked at Wikipedia talk:Reference desk#Just a Thought in Making Wikipedia Better. Buddy431 (talk) 21:15, 11 May 2010 (UTC)[reply]

Autolink bot

Hello,

I am currently brainstorming an idea for an automated linking bot:

Such a bot should take care of the following things: - see that any related and nontrivial articles are linked - not link any unrelated articles

In order to estimate triviality ( a.k.a. is an article "common knowledge" ) the bot would make a word frequency analysis of the English wikipedia, possibly matching similar sounding words with a SOUNDEX or similar algorithm in order to eradicate differences between British and English spelling. In order to establish whether two articles are related, the bot would look at a) how many categories do the articles share b) how big are those shared categories ( The category "living persons" is huge and therefore doesn't really imply relatedness, whereas the category "Fundamental Particles" is quite small therefore implying a lot of relatedness c) how close together are the articles, a.k.a. how many clicks do you need to get from one article to another d) how similar are the word frequency distributions in both articles, what "rare" words do the articles share e) possibly more

The bot has an offline snapshot of the Wikipedia for word analysis/relationship analysis etc. For every page in the Article namespace the bot does the following:

1.) Fetch page 2.) Eliminate all words that are not the name of a Wikipedia article 3.) Eliminate all words that superficially appear to be unrelated and are quite frequent ( set a threshold ) or on a list of unrelated subjects ( that shouldn't be auto-linked) and that ARE NOT IN A LINK IN THE CURRENT PAGE 4.) For each of the remaining words see if the current page and the article on the word are related. Words that appear in a link ( e.g. if there is one link already in the article) are automatically related. 5.a ) If not process next page 5.b ) If they are, search the first appearance of the word in every section, with longer section in every paragraph maybe , and place a link to the word's page on that word.

This ensures that wikipedia isn't spammed with links, but interesting articles still get their links.

I would implement and possibly run such a bot... Masterfreek64 (talk) 19:33, 10 May 2010 (UTC)[reply]

An interesting idea (I think the concept is to automatically add wikilinks to articles). Isn't there a strong possibility of overlinking? Is there any demonstrated need to add links automatically? Hmmm. WP:OVERLINK does not say what I thought it did (I agree with several editors I have noticed who have reverted dubious link additions with an edit summary pointing to WP:OVERLINK, but OVERLINK is actually very weak atm). Johnuniq (talk) 08:39, 11 May 2010 (UTC)[reply]
First, there was User:Nickj/Link Suggester and User:Nickj/Can We Link It, so the principle of suggesting links is well established, and if you can improve on existing algorithms, great. Two problems with the idea of automatically adding links though. One, it's going to be very hard to get a balance between overlinking and underlinking; it would require vast amounts of fine-tuning and in the process probably piss lots of people off. Two, linking from an article is both a relatively low priority task, and a rather easy one which is good for newbies to get started with. Far better to put the effort into the third suggestion I made in the section above at Wikipedia:Village_pump_(proposals)#Alternatives_to_TFA_unprotection, namely creating a mainpage box showing visitors/new editors what they can do, with wikilinking appropriately a basic and easy starter task. That said, orphaned articles are a problem, and if you could come up with a really good algorithm for suggesting inbound links, that would help. The suggestion should be left on the talk page like User:WildBot does though, not implemented automatically. Rd232 talk 15:48, 11 May 2010 (UTC)[reply]
I think one way to improve the suggestions is to exclude linking a single word, because of high FPs, unless the word is capitalized. Sole Soul (talk) 19:31, 11 May 2010 (UTC)[reply]
Maybe we could have the bot err extremely on the side of underlinking( approach the optimum from below) and possibly add a human voters system. The way this would work is that the bot would keep a special page where even anonymous users would be presented with a paragraph and individual words would be highlighted and they could decide if links are supposed to be added. If there were a random rotation, each link would be presented to a user once, the change put in according to this users decision according to WP:BOLD and later on one or two other random users would verify the decision independently.
A possibly even better way, which might be perfected with changes to mediawiki proper, would be to have links "on probation". The software would count every link clicked ( through referers, javascript, id parameter?) and determine if a link is used enough, possibly one could also add a button to disagree with certain links. Through the use of JavaScript, the voting logic could be kept seperate(why am I thinking of a fast, hash-table based FastCGI script here?, with a hidden iframe to send AJAX to that script whenever a user clicks a link, with a connection reset every so often for privacy). A page could either be marked on probation(count links) or as regular, and a page would be placed on probation for 1 week or 1 million views after the bot edited it. Obviously the bots editing rate would have to be limited to one re-visit per month or per 6 months unless drastic changes occured. Of course wikilinking is a task for new editors, but it is one of the tasks most likely to scare them away.Masterfreek64 (talk) 22:48, 11 May 2010 (UTC)[reply]
"one of the tasks most likely to scare them away" - why? compared to what other editing tasks? Rd232 talk 23:25, 11 May 2010 (UTC)[reply]
Is there some evidence that Wikipedia has a significant problem with underlinking? This really seems like an overcomplicated solution to a minor problem. Though if you want to work on an algorithm, nobody can really stop you (though running some script and recording something in a hashtable every time someone clicks a link is probably a non-starter, even a few minutes of collection would result in massive amounts of data). Mr.Z-man 03:00, 13 May 2010 (UTC)[reply]
Mr. Z-man, if he does no harm and can prove that the task is useful, I say more power to him! I am confused about how recording link-clicks in a hashtable got into this discussion. Tim1357 talk 20:52, 13 May 2010 (UTC)[reply]
That was part of his most recent idea. I'm not saying its harmful, but its a massive and difficult automated solution to a problem that's easy and simple to fix by hand. As Rd232 noted, there are similar problems that are much more important and difficult to fix by hand, such as orphaned articles. Mr.Z-man 14:48, 16 May 2010 (UTC)[reply]
Creating wikilinks is most certainly not a tedious task which should require automation to be feasibly executed. Furthermore, wikilink placement is an editorial decision which should be under the control of human users unless in absolutely exceptional circumstances. These two considerations are enough for the proposed bot to be taken as unnecessary and even potentially detrimental (in defence of the proposal, though, it should be pointed out that the technical challenge of implementing it effectively is quite interesting) --Duplode (talk) 04:42, 13 May 2010 (UTC)[reply]
The idea is good, but the bot shouldn't actually edit articles without human intervention. It could leave on the talk page a list of links which aren't there but should (or are there but shouldn't), though. A. di M. (talk) 13:08, 16 May 2010 (UTC)[reply]

New place for tag for politicans in the news

I am sure that most people who lives in my home country, the United Kingdom, will have heard tonight on news that Gordon Brown is going to resign as Labour leader. Can I please propose that there is therefore a tag at the head of such a figure, stating "This person is currently in the news, and information may change rapidly with news news stories"? I am aware that there is already a similar tag on the talk page of such articles, but what about having one on the actual article per se?

I am aware that Wikipedia is not quite Wikinews, but this is surely the encyclopaedia which covers current events more than any other encyclopaedia (including online ones), and as not all people would go to the talk page,why not have a tag about a person being in the news at the head of the article? ACEOREVIVED (talk) 20:49, 10 May 2010 (UTC)[reply]

Something like {{current person}}? Mr.Z-man 22:01, 10 May 2010 (UTC)[reply]

Thank you Mr Z-man - I had not seen that tag last night.It is exactly then type of thing I had in mind.I suppose that I am proposing it goes at the start of the article, not the talk page. ACEOREVIVED (talk) 21:28, 11 May 2010 (UTC)[reply]

There are hundreds of people "in the news", the template should be just for really heavy cases, like when Obama took office and all media in the world was talking about it, or when Michael Jackson died, or... well, I can't come up with really good examples near at hand, they are supposed to be few and limited after all. In any case, I doubt that Gordon's resignation would be such an omnipresent news MBelgrano (talk) 16:32, 11 May 2010 (UTC)[reply]
Examples like when the head of government changes in the United States…or the United Kingdom, as with Brown and David Cameron? I'd say it's as much a case for {{current person}} there as with Obama's election. —C.Fred (talk) 02:23, 12 May 2010 (UTC)[reply]

I've created a central area for discussion regarding subtle factual vandalism, a problem I've seen become worse and worse while our general vandalism fighting abilities get better and better. Right now the only purpose is to identify and discuss examples and patterns of subtle vandalism (think date change, statistics change, vital number and formula changes, etc.) and to identify the problem. The next step is to brainstorm ideas, and the ultimate goal is to develop tools to combat these problems.

I'd invite anyone with experience/interest in vandalism patrolling to add their specific expertise and experience to what is sure to be an important challenge as Wikipedia goes forward. Shadowjams (talk) 07:59, 11 May 2010 (UTC)[reply]

Automatically Updating Editcounts

Hey everyone! I have created a bot to make automatically updating editcounts, for use in userboxes and such. The bot is being discussed for approval. What do you guys think of the idea? All input in the discussion would be very welcome :). - EdoDodo talk 19:27, 12 May 2010 (UTC)[reply]

It would periodically go to all pages that request it, and update the counts posted? Equazcion (talk) 19:32, 12 May 2010 (UTC)[reply]
Yes, how often periodically is should still be decided but I personally think that once a week, or even less often, would be appropriate. This would not cause too much load on the server for something that I agree, is fairly low-priority. - EdoDodo talk 20:25, 12 May 2010 (UTC)[reply]
Um, I'm rarely against automation making things easier, but Editcountitis is a real thing, and this seems like a disease vector for that. Rd232 talk 19:37, 12 May 2010 (UTC)[reply]
I'm not really that concerned in that regard... the userboxes exist either way. I'm just not sure if cosmetic userpage updates are something worth the overhead of bot edits. Userboxes are probably the lowest-priority things to worry about around here. Equazcion (talk) 19:40, 12 May 2010 (UTC)[reply]
The userboxes may exist already, but when the editcount updates automatically, the count will take on a new significance (even if the boxes aren't used more widely as a result). As I said, encouraging editcountitis. The more I think about it, the more I think it's a surprisingly bad idea. (Surprising, because making things easier shouldn't ever be a bad idea...) Rd232 talk 20:13, 12 May 2010 (UTC)[reply]
(edit conflict) I agree with Rd232. (goes to check own edit count to see whether he qualifies as a Most Excellent Grognard now) ― ___A._di_M. (formerly Army1987) 19:42, 12 May 2010 (UTC)[reply]
(ec)I'm sure some would like this bot and it shouldn't bother people's watchlists (unless they have a bunch of user pages watched), but I tend to agree with the rest that this bot is unnecessary, though I'm not too concerned either way. But this is a good example to not declare in a request that edits non-controversial before asking about them. —Ost (talk) 19:55, 12 May 2010 (UTC)[reply]
  • It might be simpler and entail less overhead to simply make a user's total edit count into a magic word. This is already displayed in Preferences, so it couldn't be that hard to turn into a variable. I'm still not sure the devs would do it, because again it's a low-priority thing, and I'm not sure how much practical use it has. I don't think the bot has much chance at getting approved either. Sorry... Equazcion (talk) 19:47, 12 May 2010 (UTC)[reply]
I agree that this would be a far better solution, but unfortunately I doubt the developers would implement this, which is why I proposed this bot. - EdoDodo talk 20:25, 12 May 2010 (UTC)[reply]

Well I think this would be a very useful service for some (a lot of people are frequently updating their userboxes with new edit counts), and not cause too much load if ran at a fairly low frequency (weekly?), since I realize it is a low-priority task. I mean Wikipedia gets thousands of edits all the time, what is a couple of hundred of edits a week going to change if it makes things a bit better for some users? - EdoDodo talk 20:25, 12 May 2010 (UTC)[reply]

Sorry, I am unfamiliar with this. Will this bot go through the edits of the user? And if so how can one access this information?—Preceding unsigned comment added by Iankap99 (talkcontribs) 22:06, 12 May 2010 (UTC)[reply]
The bot wouldn't need to go through all the edits and count them, it just uses the MediaWiki API to get the edit count (basically it asks the server how many edits a user has and the server replies). - EdoDodo talk 05:29, 13 May 2010 (UTC)[reply]

MediaWiki extension that supports "Harvard" references

Example of Harvard references extension support

There is mw:Extension:HarvardReferences that supports simple refs like [Smith 2010] in text of article and anchors like [*Smith 2010] in bibliography section. Jimbo Wales on 5 November 2009 strongly supports [18] this proposal (in JavaScript version) "making refs easier to read and easier to use" in discussion about this proposal. This extension can be included to any MediaWiki site. By compatibility reasons, extension does not anything without tag <HarvardReferences>...</HarvardReferences> around bibliography section. Links may be shorter (replaced by *) or hidden by JavaScript selector in the bottom of the page (or optionally in the user settings). Working sample of this extension can be found here. X-romix (talk) 14:35, 13 May 2010 (UTC)[reply]

Taking a quick look, it seems a lot better then the mishmash of templates currently in use. It would certainly resolve current issues with duplicate ids that result in invalid HTML. ---— Gadget850 (Ed) talk 14:43, 13 May 2010 (UTC)[reply]
It's certainly a lot less horrible and useless than the Harvard refs currently infesting so much of Wikipedia. DuncanHill (talk) 21:15, 13 May 2010 (UTC)[reply]
The appearance of links can be configured and ever links can be switched off (hidden) in user settings. See selector in the bottom of sample page (bibliography section is shown anyway).


Traditional references from extension Cite.php can't be hidden, becouse it may be used for subnotes (text remarks) in article. But "harvard" links is simpler and more traditional for writing in wiki-code than refs and can be hidden for users who don't like view any source links when reading article. X-romix (talk) 01:52, 14 May 2010 (UTC)[reply]

In the meantime, please don't start documenting this as if it were available. I don't see a problem with starting a draft help page in your userspace or discussing it on the usual talk pages. ---— Gadget850 (Ed) talk 13:00, 14 May 2010 (UTC)[reply]

All documentation is on the MediaWiki server (it is not a Wikipeda server), links in "see also" sections is intended to inform readers about this alternative variant of references. X-romix (talk) 13:09, 14 May 2010 (UTC)[reply]
I believe the statement "Jimbo Wales on 5 November 2009 strongly supports this proposal (in JavaScript version)" misinterprets the views of Mr. Wales. I think he just supports improving references, not necessarily this specific proposal. Jc3s5h (talk) 13:38, 14 May 2010 (UTC)[reply]
Yes I'm correct it. X-romix (talk) 14:39, 14 May 2010 (UTC)[reply]
I think this is a great proposal, and certainly an improvement over the templates. My php is a little rusty, but how does the link work? Is it possible to write "[Smith & Jones 2010]", for a two-author reference? Does it distinguish between "[Smith & Jones 2010]" and "[Smith & Brown 2010]"? If you have two Smith 2010 references, can you distinguish them by "[Smith 2010a]" and "[Smith 2010b]"?COGDEN 21:47, 14 May 2010 (UTC)[reply]
Thank you, I'v made a sandbox in my site. [19] (anybody can edit there). There is not affect to [...] - sequences if in the page there is no anchor sequence [*...] with any sequence of chars ("]", ":" and "|" is a special chars). [Smith 2010:b] and [Smith 2010:a] points to anchor [*Smith 2010], but link [Smith 2010b] is not point to this anchor (":" delimits optional part of link where may be page numbers etc.). X-romix (talk) 13:04, 15 May 2010 (UTC)[reply]
These are very important questions. If this extension doesn't have all the features we need it will lead to us having one more way of formatting references, and none of the old ones being phased out. Not a good prospect at all. Is this extension currently active on a WMF wiki or a wiki that allows anonymous editing? I would love to test it in a sandbox. Hans Adler 22:25, 14 May 2010 (UTC)[reply]
Old pages is not affected becouse needed mandatory tag <HarvardReferences>...</HarvardReferences> around bibliography. If there is no this tag, extension does not anything. X-romix (talk) 13:04, 15 May 2010 (UTC)[reply]
I see some issues, so I am continuing this on the extension talk page. ---— Gadget850 (Ed) talk 22:51, 14 May 2010 (UTC)[reply]
Ok. X-romix (talk) 13:04, 15 May 2010 (UTC)[reply]

I have tried this extension in your sandbox and I like it very much. It's just as simple as such a thing should be in a wiki. One big advantage over our current Harvard citations system is that it works without tricks for publications without a year. I see the following obstacles to adoption on the English Wikipedia:

  • We already have two footnoting systems (standard and Harvard) and can't agree to standardise on one of them. We shouldn't have three systems for every new editor to learn. We may not be able (sociologically) to phase out one of the others.
  • We currently have trouble with Template:Citation and the other citation templates. Some pages are very slow to load because they use this template more than 100 times. I anticipate that your extension would also be used in connection with the citation templates. If we don't wait until the template problem is solved, both issues should probably be discussed together. The resulting discussion would probably be too complicated to be effective.
  • The current mechanism for switching between footnote displays needs to be replaced by something less obtrusive (i.e. nothing in the article itself). Hans Adler 18:07, 15 May 2010 (UTC)[reply]
I second Hans's first point. We really should have some more standardization of reference systems before we add a new one. The current system is a complete mess, and quite possibly the most complicated thing for editors to learn. Mr.Z-man 15:32, 16 May 2010 (UTC)[reply]
  • We actually have six referencing systems:
  1. Footnotes- inline using <ref>...</ref> tags linking to the full citation in a reference list; the citation my be defined inline or in the reference list
  2. Shortened footnotes- inline using <ref>...</ref> tags linking to the author, year, and page number in a notes section with the full citation in a bibliography list
  3. Parenthetical references (Harvard)- inline with the author, year, and page number in parentheses and the full citation in a bibliography list; can be done as plain text or using templates
  4. General references- citations in a reference list at the end of the article
  5. Embedded links- usually a URL inline; deprecated
  6. Reference templates— inline using {{ref}}/{{note}} or one of the other reference templates linking to the full citation in a reference list; deprecated for references but still used especially for notes
  • Hans is right about the sociological issues. Ref/note and their forks have been deprecated for references for years and were replaced by the Cite groups parameter for content notes, but there are still over 12,000 uses and forks keep being created. (I don't want to get off track with a long discussion on this issue here, so you can discuss at User:Gadget850/Reference templates.)
  • Citation templates and referencing systems/templates are two separate issues. Yes both can cause performance problems, separately or together. We have currently eight templates for Harvard referencing (with about 10,000 uses) that are very often used in conjunction with citation templates.
  • The issue with the dropdown box is under discussion at mw:Extension talk:HarvardReferences, and a solution has been proposed
  • The most egregious issue is that this is not styled as parenthetical referencing (Harvard) and this is under discussion on the extension talk.
  • I do like this system, but it needs some polishing and some work to make it usable.
---— Gadget850 (Ed) talk 17:20, 16 May 2010 (UTC)[reply]

A new LOOK for the Environment

To whom it may concern,

Recently I heard that dark backgrounds for one's screen saves more energy than Light backgrounds, this apparently is because using a white screen requires more energy. This is why there has been a custom search created known as Blackle (http://www.blackle.com/), where the screen is completely black. Now, I know that Wikipedia is a very well known source of information and many people around the world use it. So I was wondering If we could save energy together for our planet's sake and change the main color of Wikipedia to black. It may not be big but every bit counts..and we have come to a point where a change must be done. I thought that to save the environment, I might ask you to please make this change. I know maybe this might make the layout less pleasant But I find it important we do so!

Thank You and please do consider my comment. — Preceding unsigned comment added by 202.129.235.49 (talk)

No, this has been debated many times and the community has categorically decided against this course of action. It is possible for individual users to select that layout in Special:Preferences, but it will not be made the default. MBisanz talk 15:12, 13 May 2010 (UTC)[reply]
Using a black background only makes a significant difference on CRT monitors, on LCD displays, there's no difference [20]. Mr.Z-man 15:18, 13 May 2010 (UTC)[reply]
It's also usually hideously ugly. ♫ Melodia Chaconne ♫ (talk) 16:04, 13 May 2010 (UTC)[reply]
See our article on Blackle.com which links to references that give proper context to the claims. -- Quiddity (talk) 17:10, 13 May 2010 (UTC)[reply]
Exact duplicate threads: Wikipedia:Village_pump_(proposals)/Archive_52#Black_background_to_save_energy, Wikipedia:Village_pump_(proposals)/Archive_39#Public_Black_Background_version_of_Wikipedia. I think this might be WP:PEREN-worthy. --Cybercobra (talk) 21:14, 13 May 2010 (UTC)[reply]

Add a method of removing pages from your watchlist from Special:Watchlist

I always find it annoying to have to go into the article to unwatch it. It would be nice to have a small link to remove an article from your watchlist appear on Special:Watchlist. - ʄɭoʏɗiaɲ τ ¢ 15:51, 13 May 2010 (UTC)[reply]

What's wrong with the View and edit watchlist link below the Watchlist heading?—Emil J. 15:53, 13 May 2010 (UTC)[reply]
That it lists them alphabetically instead of by the last edit, and because it requires an extra click (quite clearly I'm a lazy bastard). - ʄɭoʏɗiaɲ τ ¢ 16:28, 13 May 2010 (UTC)[reply]
importScript('User:Alex Smotrov/wlunwatch.js');
^^^ Add to your special:Mypage/skin.js. –xenotalk 15:57, 13 May 2010 (UTC)[reply]
Done, it's perfect! Thank you very much :) - ʄɭoʏɗiaɲ τ ¢ 16:28, 13 May 2010 (UTC)[reply]
Maybe this could be a Gadget? It's pretty useful. Though it would be neater if it presented the "Unwatch" link as (diff | hist | x) rather than (diff | hist).. (x) Rd232 talk 16:43, 13 May 2010 (UTC)[reply]
It may be neater the way that you describe, but I suspect it's presented as such to prevent clumsy editors like me from unwatching pages when they go to click history. —Ost (talk) 17:41, 13 May 2010 (UTC)[reply]
Perhaps, but if you unwatch this way the page is struck through (not immediately removed from the watchlist, until you reload) and there's a '+' to click to rewatch, and effectively undo. So misclicking is not a big deal, unless it happens a lot. And with diff and hist next to each, it can't happen that often, I think. Rd232 talk 21:11, 13 May 2010 (UTC)[reply]

Proposal: Switch back to the old skin as default

This vanishing topic was moved to Wikipedia:Requests for comment/May 2010 skin change/VPR.

WMF paid for this?

This vanishing topic was moved to Wikipedia:Requests for comment/May 2010 skin change/VPR.

Font in "Compare Versions" screens

The new layout is nice, but is there any chance we could have the font on the "compare versions" screens (like here) put back to how it was, please? The new style is quite a bit harder to read and there's no obvious reason why it needed to change. 86.135.170.153 (talk) 01:57, 14 May 2010 (UTC).[reply]

Numbering sections not only in table of contents but also in the body of a wiki page

I think it's better to number every section/sub-section of any wiki page, whether it's an article page or a page like this, according to the table of contents shown at the start of the article. Of course, this is done automatically --Xeddy (talk) 11:43, 14 May 2010 (UTC)and hence we need some code for this. A reader may want to browse through the sections without going to the table of contents page, say in a long article. I think the average article is long so I think we desperately need this feature. I found this lack of feature annoying quite frequently. I think web pages are no different from other contents like printed docs or electronic docs, they should contain section/sub-section numbering in the body of the section. --Xeddy (talk) 11:39, 14 May 2010 (UTC)[reply]

I don't quite understand what the advantage would be... Choyoołʼįįhí:Seb az86556 > haneʼ 11:41, 14 May 2010 (UTC)[reply]

The advantage is ease of reading the article and of course strict content formality. Consider a 10 page article that has a table of contents, but then the body lacks the section numbers. What if you want to scan the TOCs and pick up three sections to browse through by remembering only their sections numbers. Remembering by their name would make you forget easily. This is also the issue of good design (accessibility) is it not. Certainly there would be no harm in being formal and this wouldn't put a blemish on the looks of wiki? --Xeddy (talk) 11:53, 14 May 2010 (UTC)[reply]

It may be difficult to implement: each time someone attemps to add or remove a section, should go on editing all the following ones to match the numbers again. Too much trouble for something that is just 1 button away: just press the "Home" button, or keep "Page up" pressed, and the table of contents is there. And the table itself would help to return to the original point. MBelgrano (talk) 12:06, 14 May 2010 (UTC)[reply]

Note that human editors are not to generate the section numbers themselves, neither to edit them. They are to be appended by the system automatically just like a TOC on a wiki page is generated automatically by the system through computer code. This is a simple case of computer programming and is not difficult at all. --Xeddy (talk) 12:23, 14 May 2010 (UTC)[reply]

This theory will break down as soon as some clueless editor refers to another section by its section number rather than using a link.—Emil J. 12:48, 14 May 2010 (UTC)[reply]
And let us not forget that numbers in front of section titles can be fairly confusing in some cases.—Emil J. 12:58, 14 May 2010 (UTC)[reply]

Special:Preferences → Appearance → Auto-number headings ---— Gadget850 (Ed) talk 12:54, 14 May 2010 (UTC)[reply]

Gadget beat me to it, the option already exists, and I've used it for some time. The only question would be whether it should become the default (I'd like it, but I predict it wouldn't gain consensus.) I have to catch myself, to make sure I don't tell some, "check out section 3 for the answer to your question." addendum (maybe I should have read to the end, e.g EmilJ comment, before posting :))--SPhilbrickT 13:28, 14 May 2010 (UTC)[reply]

Thanks Gadget850. What an excellent solution to leave the feature to those who want it. Now wiki is fantastic for me. --Xeddy (talk) 11:23, 15 May 2010 (UTC)[reply]

Adding dates to assessment templates

(I originally raised this at Wikipedia talk:WikiProject Council where it received no comment) I've been taking part in an assessment drive, and coming across a number of articles which range from stub in one project's assessment to B-class in another's. The most likely reason for this is that the article has been expanded considerably since assessed as a stub.

This gave rise to the idea of adding an assessment date parameter to each Wikiproject template, and having the assessment date displayed with the quality class. (It is currently possible for a user to discover the assessment date, but only by trawling back through the history of the talk page). In future, the date parameter could also be used by bots to compile lists of pages last assessed, say, 3 years ago, which could be a basis for reassessing. dramatic (talk) 19:45, 14 May 2010 (UTC)[reply]

I can see problems of the parameter not been completed or updated when the rating is changed. If this could be done, somehow, automatically when the page was saved then it would be useful to be able to see when each of the ratings was made. The idea of producing lists of article potentially in need of re-rating is also appealing. Keith D (talk) 20:25, 14 May 2010 (UTC)[reply]
A bot might work as well, though Keith's suggestion would be the ideal. I'm in general support for this otherwise. It might be wise to bring up this discussion on Template talk:WPBannerMeta. --Izno (talk) 05:31, 15 May 2010 (UTC)[reply]
WP 1.0 bot already maintains assessment logs for each WikiProject. If that data would be computer-readable, it would be easy to create a tool that e.g. lists assessments that weren't changed the longest time. I asked about it on the bot's talk page. Svick (talk) 16:16, 15 May 2010 (UTC)[reply]

Recent interface changes

Protection of Archives

I think we should have full protection of all archived areas to prevent vandalism and editing. Rin tin tin (talk) 16:27, 15 May 2010 (UTC)[reply]

Good idea. Only question is -- do the bots that take care of them have admin-status? Choyoołʼįįhí:Seb az86556 > haneʼ 16:41, 15 May 2010 (UTC)[reply]
  • Oppose—completely un-necessary. Apart from anything, there are occasions when it is necessary to edit an archive (for instance, to correct links to other archived sections; to remove copyrighted or libellous material etc.) – furthermore, until you just floated the idea, was there any evidence that vandalism of archives was majorly problematic? ╟─TreasuryTagconstablewick─╢ 16:49, 15 May 2010 (UTC)[reply]
  • Unnecessary, contrary to protection policy. Archives sometimes do need to be edited. –xenotalk 16:49, 15 May 2010 (UTC)[reply]
  • I see what you're saying. I probably should have thought about this idea. I'm expecting one of these on my userpage sometime soon. Rin tin tin (talk) 16:58, 15 May 2010 (UTC)[reply]
  • Nope. The idea has problems, but it wasn't a stupid idea.--SPhilbrickT 19:48, 15 May 2010 (UTC)[reply]
  • Another reason to edit: if a template is deleted and it is used on an archive page, then it may be useful to subst it. ---— Gadget850 (Ed) talk 20:16, 15 May 2010 (UTC)[reply]

Align all the edit tabs to the left

They are horrible on the right. Can they all be moved back to the left as on monobook? I refuse to even bother trying the new skin because of this simple lack of intuitive interface. I would like to use it, but I won't unless this is changed or unless we get an option to keep them all on the left. - ʄɭoʏɗiaɲ τ ¢ 20:06, 15 May 2010 (UTC)[reply]

They are on the right with monobook. Perhaps you enabled Special:Preferences → Gadgets → Moves edit links next to the section headers. See the documentation. ---— Gadget850 (Ed) talk 20:15, 15 May 2010 (UTC)[reply]
I'm referring to the Talk, edit, history, watch/unwatch, * (purge), and twinkle tabs. They're half on the left and half on the right on the new skin, and it looks like a retarded monkey came up with it (which by the way, the fact that this was paid for guarantees that none of the incumbent WMF board will be re-elected). - ʄɭoʏɗiaɲ τ ¢ 22:23, 15 May 2010 (UTC)[reply]
Me, I don't mind the new interface but I would like to move the edit tabs. Maybe a CSS how-to? Also I see no point to the "Read" tab. kcylsnavS {screech} 22:34, 15 May 2010 (UTC)[reply]
It'd be rather simple to make it an option in preferences. I doubt it's anything more than an align= piece of coding that determines the side they are aligned to. - ʄɭoʏɗiaɲ τ ¢ 22:41, 15 May 2010 (UTC)[reply]
It's slightly more complicated than that. This is the best I could come up with (without resorting to javascript hackery), if you don't mind the search box being in the middle:
#left-navigation {
  position:relative;
  top:2.5em;
  left:0;
  margin-left:10em;
}

#right-navigation {
  position:relative;
  top:2.5em;
  left:0;
  float:none;
  margin-top:0;
}

#ca-view {
  display:none;
}

#p-search {
  float:right;
}
-- Nx / talk 00:39, 16 May 2010 (UTC)[reply]
Edit: realized I was stupid, and replaced it with something better. Unfortunately it trips the code that puts view history into the menu because it thinks there's not enough space. -- Nx / talk 01:13, 16 May 2010 (UTC)[reply]
What's the difference between the Read tab and Project tab anyway? kcylsnavS {screech} 00:49, 16 May 2010 (UTC)[reply]
That's pretty good except the big space between talk and edit. I'd like to see this actually implemented instead of being a shortcut for me only. Either that or the community should vote which skin IT wants as the default. - ʄɭoʏɗiaɲ τ ¢ 00:55, 16 May 2010 (UTC)[reply]
That's pretty sweet now! I like it!
Now I've got to figure out how to break the drop down menus into separate tabs and I'm a happy editor. - ʄɭoʏɗiaɲ τ ¢ 01:19, 16 May 2010 (UTC)[reply]
You can use User:Amalthea/VectorMenuToTabs.js. Svick (talk) 12:25, 16 May 2010 (UTC)[reply]
Hallelujah! I am now ready to try vector (sounds too much like the cereal). Thank you everyone! - ʄɭoʏɗiaɲ τ ¢ 14:48, 16 May 2010 (UTC)[reply]

WikiProject Russian Federal Subjects

Wikipedia:WikiProject Russian federal subjects

I would like to revive this and spend the summer writing about various things related to them. I also have ideas for standardization that goes beyond what is there now. How do I officially revive this project? It's not very well covered by WikiProject Russia. InMooseWeTrust (talk) 12:12, 16 May 2010 (UTC)[reply]

Move the search box to the very top and make it much bigger please

File:SearchBoxTop.jpg
Maybe it could be put here?

It's in an absolutely terrible spot, and it's tiny. Either move it back to the left sidebar, or do what facebook, yahoo and other large sites do with theirs, move it to the top and make it really big. Something like this picture. It can't stay how it is, the suggestions won't show up, and it's in the last place I would look for a search box, and is tiny.--Patton123 (talk) 12:53, 16 May 2010 (UTC)[reply]

There is a gadget now (in Special:Preferences) to widen it a little. Making it take up the entire top of the screen would be rather distracting. Mr.Z-man 15:07, 16 May 2010 (UTC)[reply]
Distracting how? You mean different, not distracting. Every major website with a search bar that I have seen has had it at the top or left side. I proposed an idea like this earlier, I don't know where it has gone.--178.167.147.104 (talk) 16:12, 16 May 2010 (UTC)[reply]
How is this a good thing ? We want you to edit. You can search with Google already. —TheDJ (talkcontribs) 18:13, 16 May 2010 (UTC)[reply]
What are you suggesting? The most important thing to Wikipedia is a good search box, if we don't have that we don't have anything. How are people supposed to use the encyclopedia? Or are you trolling?--Patton123 (talk) 19:25, 16 May 2010 (UTC)[reply]
Every major website does not have a massive search bar that takes up at least 2/3 of the width of the page, as suggested in the image. The Facebook search bar is only about twice the size of our current one, as is the one on Twitter. The one on wordpress.com is even closer to the top right corner than ours, its just wider. The reason it appears that every major site has a giant search bar in the center is because most "major websites" are search engines. If you look at websites that have their own content (such as The NY Times, CNN, Britannica) the search bar is much less prominent. Mr.Z-man 19:53, 16 May 2010 (UTC)[reply]
So essentially you are disagreeing with my proposal because my image isn't very good? I'm just suggesting a search bar like the one at Yahoo. It's infinitely better than what we have now. Anything is infinitely better than what we have now. It's in literally the worse possible place it could be. It needs to be changed. (Also, the yahoo one is at least 4 times longer and 1.5 times higher than our search box no including the border, at least in 1440x900)--Patton123 (talk) 20:18, 16 May 2010 (UTC)[reply]
Gotta say, I'll get used to all the other changes, but the location of that search bar is abysmal. I have no idea how anyone thought that was good placement. Resolute 18:32, 16 May 2010 (UTC)[reply]

This has me pondering btw. Should we redo www.wikipedia.org to become like a search.wikipedia.org multilingual portal for readers ? —TheDJ (talkcontribs) 19:59, 16 May 2010 (UTC)[reply]

Uhh, isn't that what it is right now? --MZMcBride (talk) 20:03, 16 May 2010 (UTC)[reply]
Well I mean, a bit more like search.twitter.com. So indeed a bigger search box, more prominently positioned, multiple language results. I don't know. —TheDJ (talkcontribs) 20:14, 16 May 2010 (UTC)[reply]
The gadget Mr. Z-man mentioned doubles the size. I like it. Airplaneman 20:19, 16 May 2010 (UTC)[reply]

New editing interface is great. But it is in MonoBook too. Move back to MonoBook.

The new editing interface was one of the big "user friendly" changes added to Wikipedia. I think its great, but a question no one has been able to answer is why the switch to Vector? The new editing interface has been added to all skins not only Vector, so why the need to change the skin? The only identifiable difference is the "look" which was much better with MonoBook. Not only that, but it apparently was composed of less bytes too. I propose we move the default skin back to MonoBook until there are identifiable, significative and noteworthy changes. RaaGgio (talk) 17:54, 16 May 2010 (UTC)[reply]