Wikipedia:Village pump (proposals)/Archive 44

The opening of the article The Waste Land, with the <ref></ref> used as a note after the bolded article subject (to say "The title is sometimes mistakenly written as The Wasteland."), made me think..... One clicks on sourcing for an entirely different motivation than footnotes... Maybe the bracketed "^[1]" could have a parallel system specifically for footnotes but with the square brackets replaced with round ones (small, elevated, parenthesis) so one would know it is a footnote rather than a citation. It could be used like: <foot>This is a footnote, used to expound more on what would be too verbose for the article body while still being pertinent information.</foot>... with "foot" meaning footnote, or maybe using 'note' instead, etc... if the sourcing had square brackets and footnotes had round ones, people would know the difference and be more likely to click them. This may also encourage footnotes being used (instead of the original example where one used the reference option instead to make them) so as to not make articles as convoluted. 4.255.52.249 (talk) 23:05, 24 February 2009 (UTC)

This functionality is already available.^{[note 1]} Happy‑melon 23:19, 24 February 2009 (UTC)

Great, OK, now it needs to be more enforced then. As I rarely see it. ;p Nagelfar (talk) 23:23, 24 February 2009 (UTC)

Well making ref types is a bit different, I like my idea for a concise "()" round bracketed system, having names for types of refs meant as notes seems to be not likely to get entrenched as people like cleaning it up and making it say nothing with just a number. Which we could have, but still imply a different meaning with a different shaped bracket. 4.255.52.249 (talk) 23:30, 24 February 2009 (UTC)

I suspect many folks are not aware of the group parameter, and many articles probably predate it. I still see {{Ref label}} and similar templates in use for list and table notes that can be easily replaced with a ref group that uses a much simpler syntax. --—— Gadget850 (Ed) ^talk - 23:33, 24 February 2009 (UTC)

It's a (relatively) recent development; I agree that it's poorly-utilised. Maybe a concerted effort to replace the various templates a-la {{note}}/{{ref}} would be productive, and instructive? Happy‑melon 23:36, 24 February 2009 (UTC)

Groups were added in July 2008. If you are considering that some of the other reference templates should be deprecated, then I am in agreement. --—— Gadget850 (Ed) ^talk - 23:53, 24 February 2009 (UTC)

Don't deprecate. While many instances of {{ref label}} can be replaced with <ref group=n>, there is still need for {{ref label}}; <ref>s can't be nested, and so notes can't have refs in them. -- Fullstop (talk) 00:18, 25 February 2009 (UTC)

Using {{#tag:ref|text goes here<ref>reference for that text</ref>}}, you can in fact nest refs. See List of Governors of Arizona for a mature example. --Golbez (talk) 00:51, 25 February 2009 (UTC)

Thanks! An aha moment that made my day. -- Fullstop (talk) 01:10, 25 February 2009 (UTC)

And it is even documented at Wikipedia:Footnotes. --—— Gadget850 (Ed) ^talk - 20:32, 26 February 2009 (UTC)

There's already more than one way to make footnotes; see for example the cref method used in older versions of the Che Guevara article, for example here; see the superscript "Basque" at the end of the 2nd sentence of the Early Life section, for example. ☺Coppertwig (talk) 17:55, 28 February 2009 (UTC)

How hard would it be to make a bot that searches all pages with the image:replace this image male.svg searches flickr for the person under creative commons licencing and commercial use parameters. Proceeds to prompt user:flickr upload bot to upload it. Then replaces the image with the one from flickr into the article? --DFS454 (talk) 14:57, 26 February 2009 (UTC)

Wouldn't work. There are numerous copyright violations on flickr which we then would automatically upload to Wikipedia articles. Garion96 (talk) 15:00, 26 February 2009 (UTC)

what if they had to be sighted? --DFS454 (talk) 15:19, 26 February 2009 (UTC)

Having this bot generate a list would be a great idea. Maybe then suspected copyvios could be added to a blacklist, and the bot would disregard that user's uploads in the future. Calliopejen1 (talk) 16:27, 26 February 2009 (UTC)

Making a list would be good so before uploading the images would have to be approved. That way at least the bulk of copyvio's will not be uploaded. If all this is technically feasible of course. :) Garion96 (talk) 16:38, 26 February 2009 (UTC)

It shouldn't replace the image on the article automatically, IMO. There would be a lot of room for error, it's a bot after all. Maybe it can post image suggestions for review by editors? --Nezek (talk) 18:43, 26 February 2009 (UTC)

I proposed this idea a while back but for general images that are useable on wikipedia, particularly places. Creative Commons 2.0 has 11,000,000 images alone that potentially could be uploaded, vast majority are indeed correctly licensed, the copy vios are a very small percentage of this Garion and can be spotted amile away, they are usually images of people. It would be best a bot just uploaded images from Creative Commons 2.0 and Creative Commons Sharealike categories on flickr in general. The fact that so far nobody has got serious about uploading this vast bank of images again suggests to me that content isn't of prime importance to many on here. There are just so many things we could be doing with bots to maximise our productivity and resourcefulness it has to be said. Dr. Blofeld ^{White cat} 16:44, 26 February 2009 (UTC)

Copyvio's on flickr are usually indeed mainly on images of people (celebrities). And since the original proposal in this section was to search all pages with image:replace this image male.svg which is used only for people...... Garion96 (talk) 17:07, 26 February 2009 (UTC)

Why upload images when you don't need them for a specific article? --Nezek (talk) 18:34, 26 February 2009 (UTC)

Yeah I agree Garion it wouldn't work well for that particularly focus anyway. Such a bot Nezek would be operated in the commons, not here. The wiki commons is dedicated to building our resources of encyclopedic images regardless of whether they are needed on wikipedia. Personally I only tend to make flickr agreements or uploaded useable images from flickr if they are needed in the articles, but for those who work primarily in the commons they want to build up resources, beats me why nobody has transferred all the images, we have a few but a small proportion of what the flickr has that we can use. Dr. Blofeld ^{White cat} 18:49, 26 February 2009 (UTC)

So where do we go from here? Do we approach someone with bot-building experience and just ask them ?--DFS454 (talk) 14:16, 27 February 2009 (UTC)

Try Wikipedia:Bot requests. I must admit I've made proposals here myself and it is pretty much a easte of time if you want some serious action. Discussions tend to get put back by new discussions underneath and it usually ends up with only one or two leaving comments. Dr. Blofeld ^{White cat} 21:53, 27 February 2009 (UTC)

I have filed a request here any input would be welcome. --DFS454 (talk) 14:05, 28 February 2009 (UTC)

The Wikipedia TCG (trading card game) is a proposal for creating a trading card game based on Wikipedia, to be sold at the cafepress store for wikipedia for instance, where all proceeds go to the Wikimedia foundation, which operates Wikipedia, Wiktionary, Wikiquote, Wikibooks, Wikisource, Wikinews, and the Wikimedia Commons. I've created some beta cards and beta rules. The designs and rules aren't great, which is why I have started this post, so than we can collaborate together towards fundraising (via this card game), which is very important because it keeps Wikimedia Foundation projects running. I believe that a WP TCG might spark significant sales from current and former WP editors.

The Game: The card game would be played between 2 players against each other. Both players have a deck of X number of cards and draw X number of cards at first and X number of card(s) each turn. Each player starts with say (for example) "5000 articles" (which would be like lifepoints on the Yu-Gi-Oh TCG). There are "good" cards (white) which add more articles to you and "bad" cards (black) which remove articles from your opponent. There are 2 ways of winning the game:

• Reducing your opponents "articles" to 0 (as in Yu-Gi-Oh)
• Reaching a "number-of-articles" milestone somewhat dificult to achieve (say "10,000")

Thus 3 main strategies develope:

• Using many white cards to gain 10,000 articles.
• Using many black cards to decrease you opponent's articles to 0.
• Using a combination of both to easilly adapt to opponent's startegy and see which way of winning comes best in each case.

Here are some of the cards I've designed (these are beta/draft/sloppy versions). This isn't the complete card set, just some cards I've managed to make images for:

• 
  Administrator
• 
  Bot (anti-vandalism)
• 
  Bot (content-generating)
• 
  Bot-op
• 
  Bureacrat
• 
  Checkuser
• 
  Developer
• 
  Rogue user
• 
  Rollbacker
• 
  Sockpuppet
• 
  Steward
• 
  User
• 
  Vandal
• 
  Wikidragon
• 
  Wikifairy
• 
  Wikiogre

As I've said before, all this is the basic idea. It would be improved and changed with collaboration from all interested (card design would be improved too). These are not all the cards, but a few "sample" ones I've designed. And remember, this is for the benefit of Wikipedia and free knowledge.

Any comments, ideas, suggestions, feedback, etc. welcome. If you are interested in helping, please say so.

Also, a question... Could I create a WikiProject dedicated to this straightaway? Or must I host said project at userspace or something.

Remember, this is just an idea. ♠TomasBat 00:44, 27 February 2009 (UTC)

You do realize that by creating this game you're dooming thousands of people to a life a celibacy. Equazcion •✗/C • 06:15, 27 Feb 2009 (UTC)

I think it may be good. I may even head over to Magic Set Editor's forums and see if the templaters over there couldn't bodge together a template for it, in case it may need to expand. -Jeremy ^{(v^_^v Dittobori)} 06:17, 27 February 2009 (UTC)

Hey, that would be great :) ♠TomasBat 19:20, 27 February 2009 (UTC)

And I've posted the request there (not linking due to harassment concerns). -Jeremy ^{(v^_^v Dittobori)} 01:50, 28 February 2009 (UTC)

errrr... I feel compelled to point out that while this may have financial benefits for the wikimedia foundation, what you are essentially presenting is the idea that Wikipedia is a system in which content and principles are irrelevant; the game is won by people who use rogue users and sockpuppets to disable their opponent's work, while securing 'pocket administrators' and etc on their side of the table. In short, it takes everything that can possibly go wrong on WP and idealizes it as a winning approach. I kinda think that might be a baaaaad idea. now, there might be ways around that with an artful creation of the game rules (something more complicated and multi-dimensional, in which players have to cooperate to achieve certain goals even as they compete), but... I'm just sayin'... --Ludwigs2 02:25, 28 February 2009 (UTC)

Card games are competitions, while Wikipedia is a collaboration, hence the incompatibility. Any game where the object is to win and make the other guy lose will carry this problem. Equazcion •✗/C • 02:31, 28 Feb 2009 (UTC)

Note that even some competitive games have degrees of collaboration. What I would think is that the rules should be made in somewhat of a style where collaborative play is as beneficial as being cutthroat (I note OP did not lay out his rules fully, especially given that I see keywords in there). In any case, I would suggest that, given that the card game is about Wikipedia, why not allow the community to design the rules for it? -Jeremy ^{(v^_^v Dittobori)} 02:34, 28 February 2009 (UTC)

Good idea -- a page could be created in project space for it. How bout Wikipedia:Wikipedia card game, to be moved later when an actual name is thought up? Equazcion •✗/C • 02:47, 28 Feb 2009 (UTC)

Ok, in the end I've decided to directly create the project page. Please add your name to the members list at Wikipedia:Trading card game if you are interested in helping. ♠TomasBat 02:49, 28 February 2009 (UTC)

I am rather concerned that if you type "counselling psychology" into the box on the left, i.e. the box that has search and "go" beneath it, you will get redirected to psychotherapy. In fact, the terms "psychotherapy", "counselling" and "Counselling Psychology" are all distinct (for a start, counsellors, unlike counselling psychologists, do not need degrees in psychology).

How can we ensure this misleading redirection in Wikipedia is stopped? Perhaps we need a new category of "disputed redirects". Alternatively,can some one please see to ensuring that if one types "counselling psychology", one will get told - as is the case - that Wikipedia does not currently have an article with that name? ACEOREVIVED (talk) 21:44, 27 February 2009 (UTC)

We already have a system for this. If you feel the redirect is inappropriate, post it at Wikipedia:Redirects for discussion. Algebraist 02:08, 28 February 2009 (UTC)

Or edit it appropriately. I've recently edited a handful of redirects in the broad area of psychology after finding the redirects have been used to promote pseudoscience. Meanwhile, Wikipedia editors supposedly dedicated to eradicating pseudoscience are simply creating their own. Sometimes redirects need edited, not necessarily discussed. The ones I changed got no response. I'm pretty sure their editors knew they were creating bogus linkages. --KP Botany (talk) 07:39, 28 February 2009 (UTC)

Just change the redirect to whatever is appropriate, or turn it into a dab, or WHATEVER. There is absolutely no evidence that the redirect from "counselling psychology" to "psychotherapy" was agenda-driven, or that anyone would even care if it were changed.

Indeed, the last two edits in the history show that it was made a redirect to Counseling psychology, and then a bot changed it to go to psychotherapy because it was a double-redirect. So, just {{fixit}}. And sharpen Hanlon's razor while you're at it. -- Fullstop (talk) 17:02, 28 February 2009 (UTC)

I've made a earth-moving redirect from the two-ll "counselling ..." to the one-l "counseling ...". Call on Ogden Nash for more assistance. ;) -- Fullstop (talk) 17:21, 28 February 2009 (UTC)

Hi all, given discussion on esoteric nature of some FAs and GAs, I thought reactivating this might be worthwhile. My take would be the best candidates are large, general articles which are reasonably comprehensive, non-controversial and might not be too far off GA or FA. I thought barley but feel free to discuss or think of others. Casliber (talk · contribs) 01:39, 1 March 2009 (UTC)

That would be a great idea! If it would make more sense, maybe it could be collapsed into WP:VIT to give that project some more active participation... we already want to do a collaboration, but it's hard with only three members. -Drilnoth (talk) 01:42, 1 March 2009 (UTC)

I created a custom stylesheet for Wikipedia, and thought this could be useful as a default. I propose to use the concept of this stylesheet, and make references and footnotes show up at the bottom of the screen when they're clicked, instead of having the browser jump to the references section of an article. It will make browsing and reading considerably easier. Note that this will not be compatible with Internet Explorer (Browser compatibility table) --Nezek (talk) 15:27, 25 February 2009 (UTC)

That's a really cool effect, but the ref can't be dismissed after it's clicked; on multi-line references this may obscure a considerable portion of the text. Still, it's a cool effect; definitely worth linking to from one of WP's pages on layout customisation. Chris Cunningham (not at work) - talk 15:38, 25 February 2009 (UTC)

The reference can be dismissed the same way, the functionality doesn't alter. You click the back button, or the up arrow next to the highlighted text. --Nezek (talk) 16:08, 25 February 2009 (UTC)

Ah, right, I see. That does, however, have the effect of jumping one about the page, assuming that the ref one originally clicked was not already at the top of the window. Chris Cunningham (not at work) - talk 16:32, 25 February 2009 (UTC)

Yes, there are two distractions involved when you want to read a reference. a) Jumping to a different part of the page b) Later on, finding the location where you jumped from. This addition is ment to prevent the distraction that jumping to references/footnotes causes. What you're describing is the effect of jumping back to where you started, which again, hasn't altered from how Wikipedia currently handles references.

However, I can see what you mean. After using it for a day I've noticed a couple of problems.

1. There's no clear indication that a ref is at the bottom of the screen after the click.
2. If I scroll elsewhere in the article with the ref floating, and try to dismiss it, I get taken back to the where the ref originated.

These problems can easily be fixed with some Javascript, But first I need to know if theres a consensus about using this concept. --Nezek (talk) 15:27, 26 February 2009 (UTC)

It would probably be useful to provide as an option (as a Gadget?) but I'm not sure it would be good as a default. Some people might just not like it for one reason or another: for example, sometimes I like to jump down to the references section and then look at 3 consecutive references. I imagine there may be all sorts of accessibility problems with it with different browsers and different display methods, for example handheld devices with very small screens where the reference might take up the whole screen. Maybe the reference could have two buttons, one to jump back up to where you were, and the other to just dismiss the reference and stay where you are. Thanks for coming up with this; I look forward to trying it out if it's put up as a Gadget. Oh, by the way, how would it behave at an article like Che Guevara, where you do two jumps to get to the bibliographic information? ☺Coppertwig (talk) 17:44, 28 February 2009 (UTC)

Thank you for your input. I sometimes like to view a few references at once as well. Maybe I should add alt+click as way to bypass this functionallity and jump stright to the references section? or even only have this as an option when you alt+click?

As for handheld devices, I put up a limit so that a reference can only take up half of the screen, and if a text is that lenghty that it takes more than half the screen, it gets its own scroll bar.

Also, where in Che's article do you do two jumps? --Nezek (talk) 08:17, 1 March 2009 (UTC)

I have been reading Wiki for years, but I am brand new to Wiki contrib, and wanted to suggest a biography entry. I found, in the general tab list, two categories absent for biographies, which I think you will agree should be present: for nationalities:

United States

for professions Diplomat

Is this the right place to bring this up? I'll check back for an answer. - wiki1s

Made it into a new heading. In the future, use the "new section" tab to start discussions. Thanks. ~user:orngjce223 how am I typing? 22:06, 1 March 2009 (UTC)

A discussion about new speedy deletion criteria for books is going on at WT:CSD#Books. Your input is appreciated. MER-C 03:59, 1 March 2009 (UTC)

• Correct link here WT:CSD#G 13 Books --DFS454 (talk) 14:09, 1 March 2009 (UTC)

There is a proposal at Wikipedia talk:User page#Non-contributors regarding how to deal with user pages of non-contributors. Comments and input are welcome. --MZMcBride (talk) 22:48, 1 March 2009 (UTC)

Now that it has been about nine months since the requirement that new accounts make ten edits was added on May 23, 2008, I would suggest that all the old auto-confirmed accounts created before that date that have made no edits be flushed. My guess is that this would be as many as 2/3 of the existing accounts, and remove who knows how many sleeper accounts. The only legitimate accounts I can think of this affecting would be doppleganger accounts, and a few people who wished to reserve their favorite username, but have never many even one sandbox edit. No SUL accounts should be affected, as they did not become generally available until May 27, 2008. Apteva (talk) 17:05, 18 February 2009 (UTC)

Note that autoconfirmed doesn't work like other user groups. Whether a user is autoconfirmed is evaluated whenever the user does something that would require it, so any change to the criteria (such as the addition of a 10 edit requirement) is retroactive. Mr.Z-man 18:00, 18 February 2009 (UTC)

I remember reading that there's a good chunck of people that register for the sole purpose of having preferences. So even if they made no edits it doesn't mean they don't have accounts in use. ♫ Melodia Chaconne ♫ (talk) 18:09, 18 February 2009 (UTC)

And in nine months we have not been able to entice them to correct even one spelling/typo? Apteva (talk) 18:23, 18 February 2009 (UTC)

Considering the fate of Wikipedia:Delete unused username after 90 days I doubt the developers would be interested in implementing this proposal either. Davewild (talk) 18:49, 18 February 2009 (UTC)

Interesting. Despite the "222 Support, 6 Conditional Supports ..., and only 17 Oppose", I believe that to have been a seriously flawed proposal and should have been rejected, as it was. I guess we could ask Brion about this idea. Apteva (talk) 19:22, 18 February 2009 (UTC)

foundation:Privacy policy#User accounts and authorship: "Once created, user accounts will not be removed" kills that one stone dead. And Mr Z-man is correct about autoconfirmed applying retroactively. Nothing to see here... Happy‑melon 23:13, 19 February 2009 (UTC)

Ok, make a teensy tiny change to the policy - change the word created to used. "Once used, user accounts will not be removed." Thus emphasizing that we save all edits forever, even if some are hidden. We do, however, regularly change usernames, and the old name is thereby deleted. However, I admit that I was thinking that the change was not retroactive, but could someone explain this conflict with the concept that wp:autoconfirmed requires ten edits? Were the other eight qualifying edits deleted? Apteva (talk) 18:41, 24 February 2009 (UTC)

Yes, there were 9 edits before the moves which were deleted after the move vandalism. Davewild (talk) 18:44, 24 February 2009 (UTC)

"making a teensy tiny change to the policy" is anything but; any change to that policy, large or small, one-word or entire-page, must be approved by a vote of the Wikimedia Foundation Board. And what you propose is actually anything but trivial: you propose that the policy be amended to allow the deletion of the seven million accounts on en.wiki that have no edit history. An "account" is different to the "username" associated with it: as you note, the username of an account can be changed, but it is wrong to think of that in terms of "the old name is thereby deleted" - that's not what happens at all. We can rename an account with zero edits just like one with ten thousand, it's just easier to ask them to just create a new account. Deleting user accounts, for any reason, Will Not Happen. Happy‑melon 19:19, 2 March 2009 (UTC)

A while ago I wrote the integrated archive listing we now have in the {{talkheader}} template. Now that many talk pages have archive search bars posted beneath their talkheader templates, I'd like to integrate that feature into the talkheader template as well, so that it's easier to post, makes for neater wiki code, and a streamlined, slightly snazzier appearance. It's switched off by default, but can be activated on pages that require it via a parameter, |archivesearch=yes. I have a version of the rewritten talkheader template at {{talkheader3}}. Here's what it looks like:

To test it live I've posted it at Wikipedia talk:Notability. Please let me know what you think, and report any issues or suggestions. Thanks. Equazcion •✗/C • 03:10, 25 Feb 2009 (UTC)

Looks great. This should be incorporated ASAP, rather than having forks deployed. Could the parameter be changed just to "search", though? No need for it to be too convoluted. Chris Cunningham (not at work) - talk 11:40, 25 February 2009 (UTC)

Since this is not displayed by default, I think I can justify being bold; I've added it to the live template. I've also changed the parameter to |search=, as Chris suggests. Great idea! Happy‑melon 11:52, 25 February 2009 (UTC)

Thanks :) Equazcion •✗/C • 18:08, 25 Feb 2009 (UTC)

Could the archive search box be in the same cell as the archive links? This makes more logical sense than having a line between the two. Pretzels^Talk! 16:53, 27 February 2009 (UTC)

It would complicate the opening and closing of tr's and td's in the code. It could probably be done with some work. Here's what it would look like (at least as I interpreted your suggestion):

{{talkheader5|search=yes}}

Equazcion •✗/C • 17:39, 27 Feb 2009 (UTC)

Thanks. I personally feel it's an improvement, but it's no big deal. Maybe the standard archives filing cabinet icon could go in there too. Pretzels^Talk! 16:37, 1 March 2009 (UTC)

I agree that it isn't a big deal either way; I'd rather keep the code simpler. And including the standard filing cabinet icon might help encourage editors to delete that when it's in a separate template, which would be good. -- John Broughton (♫♫) 02:13, 3 March 2009 (UTC)

This is an idea I just thought of, although I am not sure of the technical feasibility of it. It shouldn't be terribly difficult to implement nonetheless however. Anyway, the idea is to be able to give individual images a specified default size parameter, although used only for images where this is necessary. This would allow the majority of those who browse Wikipedia (non-registered users who cannot specify a viewing size for all images) to see images at a default size that does not distort or otherwise obscure the image, while allowing users with a set preference to still be able to see images at that size. What are people's thoughts on this? Would it be possible to implement? 180px is unsuitable for many images because of aforementioned distortion. --.:Alex:. 18:20, 25 February 2009 (UTC)

I don't understand. The "thumb" parameter has a default size of 180 pixels, I'm almost certain. And the vast majority of images (I believe) use this parameter. The problem, if there is one, is that many, if not most editors also specify the viewing size of the picture, as in |thumb |200 px |right ; then (in this example) the viewer gets a 200 pixel picture regardless. (see H:IOUF and WP:PIC for more details) -- John Broughton (♫♫) 21:58, 25 February 2009 (UTC)

Since sometimes the image is sized to fit the article nicely, I don't think this'd work too well. ♫ Melodia Chaconne ♫ (talk) 23:13, 25 February 2009 (UTC)

I don't understand this proposal. Almost no images are given without a size (either explicit or thumb) in the project right now. if they are, it's because they're already displayed at an appropriate size. It'd be far more sensible to argue for the default thumbnail size to be increased. Chris Cunningham (not at work) - talk 11:38, 26 February 2009 (UTC)

Thumbnail sizes default to 180px, but can be set to from 120 to 300 px through Special:Preferences → Files → Thumbnail size. --—— Gadget850 (Ed) ^talk - 15:39, 27 February 2009 (UTC)

I don't mean that at all. Basically, the default "thumb" size is 180px. The problem is that some images appear distorted at that size. Sure, you can set a size using the existing parameter, but this then disables the image size preference in Special:Preferences which affects all images (and also, is only available to registered users which means the problem still remains for the anonymous majority). The idea is to implement a function that allows you to set a "default" size parameter (not a fixed size like the existing parameter currently allows) for an individual image so it appears at the desired size by default, while allowing those with an image size preference to still see the image at their specified size. Does that make any sense? --.:Alex:. 20:08, 27 February 2009 (UTC)

Example: let D=180 ('default - no thumb size specified, no user preference); S=250 (specified size, as a parameter, in the article), and P=300 (user preference). The current software settings are that S overrides P, P overrides D, and (of course) S (if present) overrides D. As best as I can figure out, you're proposing that P override S. I can see that very much being a problem - some images are minuscule (as in an infobox); some do need to be set to be larger. A standard size for all images (as specified in user preferences) is just going to be wrong a lot of the time. -- John Broughton (♫♫) 02:22, 3 March 2009 (UTC)

I find it frustrating that when hovering over links to redirects, their tooltips still just show the title of the redirect page, rather than expanding to show the page I would actually end up at by clicking. It would really help, and often save me a click/pageload, if the tooltips were somehow expanded to show the final destination of the redirect instead. We shouldn't have to load a page just to see where a link goes to. That's what the tooltips are for. Equazcion •✗/C • 15:46, 2 Mar 2009 (UTC)`

Sounds like you want WP:POPUPS Zunaid 15:53, 2 March 2009 (UTC)

I KNEW someone was gonna say that. Thank you but no, I actually hate popups. I don't need anything more than a simple page title to show up in the tooltip -- it's really what should be happening universally for everyone, with no addons, as that's what tooltips on links are for to begin with. Equazcion •✗/C • 17:06, 2 Mar 2009 (UTC)

As was recently done on the German Wikipedia, I have proposed deprecating future use of the GFDL-1.2-only templates here as well. Please join the discussion. Kaldari (talk) 21:40, 2 March 2009 (UTC)

Note: I can find no prior discussions about this, except for this in WT:RFA archive 126, which recieved little community input. Nevertheless, I hope to address the concerns raised there in my proposal below.

As spelled out in the bot policy, the role of the Bot Approvals Group is to oversee the running of bots on Wikipedia, and approve/deny requests to run bots (and, by extension, whether an account is flagged as a bot). However, it is only bureaucrats who have the technical ability to flag and deflag bots. To me, this seems rather strange. Why don't we give the people who know what they're doing when it comes to bots, and have been trusted by the community to oversee the bot approvals process, the ability to 'finish the job' and add/remove the bot flag?

I propose that a 'bot flagger' or 'bot approver' usergroup is created, with the +bot and -bot permissions (trivial to implement with the new UserRights system). I also propose that all current BAG members get this right (either after reconfirmation or straight away). As for assigning the user right, that is something the community will need to work out. As a comparatively (to rollback or accountcreator) small number of people will have the right at any one time, a process for granting it seems out of proportion. Perhaps BAG membership nominations should be placed in a more public location and the right assigned by bureaucrats? I've listed some potential concerns below, and my analysis of them. I'm not trying to prejudge what the community will think, just offer my opinion(s) in one place! Richard⁰⁶¹² 22:38, 19 February 2009 (UTC)

Potential concerns, and my responses

• What's broken with the current system of bureaucrats flagging bots?
  • Nothing is really broken with the current system, it's just rather inefficient. Approved bots are listed on an approvals page, and if they require a flag a bureaucrat will flick the switch. It would make more sense to approve and flag the bot (if necessary) in one action. Furthermore, deflagging of inactive bots/bots with blocked owners can be streamlined. I realise that neither process is time-sensitive, but efficiency is rarely a bad thing.
• The bureaucrat can cast a final eye over the approval and check that everything is OK. This shouldn't be changed.
  • I can understand this, but since I have been involved in BRFAs (since summer '08), and as far as I can tell before that, there hasn't been an instance of a bureaucrat questioning an approval. There have been issues surrounding bots being approved when, really, they shouldn't have been (e.g. User:Pageview bot), but now that BRFAs get wider community input, and BAG members are mindful of such past incidents, such instances should be very rare indeed.
• This is beyond what the current BAG was approved for.
  • This is very true, although once flagged, it is down to the BAG to approve further tasks (which could potentially be far more controversial than the first), and flagging the bot is merely a small, technical part of the approvals process.

This seems a sound proposal. I like the name "bot approver" better. {{Nihiltres|talk|log}} 23:50, 19 February 2009 (UTC)

Bot approver does sound good, and I think that crats should be the ones to assign this right to BAG members - and also be able to revoke this right from BAG members, if they retire. Will this be for active BAG members or all BAG members? The Helpful One 12:07, 20 February 2009 (UTC)

I would imagine that (much like the account creator right) it would be best to assign and revoke as necessary (the turnover of BAG members is quite low). I would recommend that if this is enacted, the right is given to all active BAG members to begin with, and then if any inactive members wish to 'reactivate' themselves they can ask for the flag. Richard⁰⁶¹² 14:11, 20 February 2009 (UTC)

Don't forget that the power to de-flag bots might be useful when bureaucrats are badly placed to determine when things are going wrong. Support. - Jarry1250 ^{(t, c)} 12:19, 20 February 2009 (UTC)

• I don't think this is a good idea at all, particularly given the history of BAG and the issues we've had with bots being approved/operated in the absence of clear consensus. Given that a bot could be proposed, approved and flagged by a single member of BAG... I think having the intermediate step of a bureaucrat review is an essential part of the process. (Could be that some parts of the process have changed since the last time I looked into it; even so, I think the 'crat step is a good way to ensure a review that is separate from regulars at BRFA). Avruch ^T 14:49, 20 February 2009 (UTC)
  • Just a quick clarification, BAG members do not approve their own bots (it's not explicitly written down, just accepted practice), and I can imagine that should such an incident occur (regardless of whether BAG flagged bots or not), the member in question would at the least be trouted for not using their common sense and would run the risk of being 'demoted' for abuse of their powers. Richard⁰⁶¹² 16:11, 20 February 2009 (UTC)
• I could support giving BAG members the ability to deflag a bot, if that's even technically possible (should be, 'crats can give adminship, but only stewards can take it away). But I wouldn't support giving them the ability to give out the bot flag on their own. For the situation where there's an emergency, having the ability to remove the flag would certainly come in handy. —Locke Cole • t • c 15:42, 20 February 2009 (UTC)

• I concur with Locke Cole. An out-of-control bot situation is the only one where efficiency/speed outweighs checks and balances. It's better to have an outside perspective, even when everybody in the group is acting in good faith (as I'm sure is generally the case). Baileypalblue (talk) 16:43, 20 February 2009 (UTC)

• An out-of-control bot should be immediately blocked. De-flagging will allow its contributions to be shown by default on Special:RecentChanges. wodup 18:57, 20 February 2009 (UTC)

• (edit conflict) I will have to oppose this proposal. I could see BAG members with a -bot, in theory, but I'd prefer to keep the +bot in the hands of the bureaucrats. Not only were they selected with this is mind, but BAG members were not. Maybe if the BAG members were given the +bot on an individual level based on running a Request for Bot Appprover, maybe I could go with that. But I also like the separation of powers, or check and balances, or whatever between BAG and bureaucrats. Useight (talk) 16:45, 20 February 2009 (UTC)
• I agree with Useight, Locke Cole, and Baileypalblue, BAG members should be given -bot, but +bot should reside exclusively with bureaucrats. Is it possible to assign these 2 permissions separately? Kaldari (talk) 18:20, 20 February 2009 (UTC)
  • Its possible, but rather pointless; its not like the bot flag allows you to edit while blocked. Mr.Z-man 18:53, 20 February 2009 (UTC)
    • As I understand it, the bot flag does the following things: 1) removes the throttle on edits (normal editors can only make so many edits per minute, bots have a higher/no limit), and 2) hides bot edits in Special:Recentchanges. I have no idea if all BAG members are sysops/admins, but in the event there's a BAG member who isn't, an out of control bot could have its damage limited with this flag. Then there's the purely bureaucratic side of this: if a bot is blocked and its permission is withdrawn, BAG shouldn't need to bother a 'crat to remove the flag. I'll agree it's not some amazing tool, and its uses are limited, but that sounds like an even bigger reason to do it. —Locke Cole • t • c 08:42, 21 February 2009 (UTC)
      • According to MediaWiki, the bot userright grants:
        • Be treated as an automated process (bot)
        • Edit semi-protected pages (autoconfirmed)
        • Have one's own edits automatically marked as patrolled (autopatrol)
        • Not create a redirect from the old name when moving a page (suppressredirect)
        • Not have minor edits to discussion pages trigger the new messages prompt (nominornewtalk)
        • Perform captcha triggering actions without having to go through the captcha (skipcaptcha)
        • Use higher limits in API queries (apihighlimits)
        • Use of the write API (writeapi)
      • So yes, those things you mention and a couple more obscure ones. MBisanz ^talk 09:00, 21 February 2009 (UTC)
        • Note that even anons have "writeapi", and any autoconfirmed user has "autoconfirmed" and "skipcaptcha". Also, according to the API, my normal non-bot account has no edit rate limit either (but my bot has no limit on move, emailuser, or rollback that my normal user account does). You can find the status of BAG members at WP:BAG; at the moment, only 58% of BAGers listed as "active" are also listed as "Admin". Truth is, I'm not sure how much damage would really be limited by removing the bot flag, unless it's a page move bot or it uses Extension:AssertEdit's assert=bot (or something similar to immediately stop without a bot flag); you'd be better served by finding the nearest admin to just block it. Anomie⚔ 03:00, 22 February 2009 (UTC)
      • (e/c)There's about 10 active-ish BAG members and over a thousand admins. An admin is almost certainly going to be easier to find in an emergency. Mr.Z-man 09:02, 21 February 2009 (UTC)
• Oppose as solution looking for a problem. Also, with all due respect, this proposition would be adding more power to a group whose selection isn't exactly rigorous and whose very existence has often been opposed. Stifle (talk) 21:22, 20 February 2009 (UTC)
• I would oppose this as well. The current system ensures that at least someone from the outside community that is not necessarily big on bots, looks at the BRFA. One main that I could remember would be The FA Template Adminbot, which WJBscribe did not wish to flag as an adminbot, even with BAG approval, until the community had a greater say. There was another instance that I think I remember where WJBscribe (again) did not wish to flag a bot even though Betacommand had approved it. Does anyone know of the case of what I mean? NuclearWarfare _(Talk) 23:07, 20 February 2009 (UTC)

I don't think anyone want BAG members to be able to give admin powers. Those would be left to bureaucrats. On the latter point, alas I don't have the link; I too would like to read about it. - Jarry1250 ^{(t, c)} 15:33, 21 February 2009 (UTC)

• Oppose because BAG is not community elected. At least now crats can pull the emergency brake on controversial bots. --Apoc2400 (talk) 15:15, 21 February 2009 (UTC)

'Crats could still follow the discussion regarding bots, and have their say. Logically speaking, controversial bots should not be approved by BAG members for any other reasons that a bureaucrat would. Arguably though, BAG elections should be made more well known - at present my nom. is only advertised on the bot owners' noticeboard and the VP. I'll post a link onto the admin board, while I remember. - Jarry1250 ^{(t, c)} 15:33, 21 February 2009 (UTC)

• Strong oppose. BAG is not only not community elected it's insular and not amenable to community input. In addition, the task should be left to someone more qualified, in my opinion, than BAG, as BAG has real concerns about bots and progamming that they are currently not addressing. More responsibility requires, imo, an acknowledgement of community concerns, and an ability and willingness to deal with internal problems, in addition to community support for members. I see none of this. --KP Botany (talk) 00:54, 22 February 2009 (UTC)
• Not really a big fan of this proposal. Checks and balances are really a good idea, especially for this. The executor of a proposal should not've been part of those who wrote and !voted on it. Sceptre ^(talk) 02:27, 22 February 2009 (UTC)
• Sorry, BAG needs as little power as possible. On a side note, I would support a proposal to behead anyone who prefixes the word "vote" with an exclamation mark. --MZMcBride (talk) 09:11, 22 February 2009 (UTC)
• Oppose the BAG and 'crats have different roles, and is an effective check and balance to abuse of power: while the BAG decides, 'crats offer independent scrutiny with their right to challenge. BAG members, given the right to -bot independently, would be an anti-consensus move. It amounts to a de facto veto of any bot by one member or even all members of BAG (over the 'crats), should they fall under the spell of a particularly charming person who happens to have a wicked hidden agenda. Nothing's broke, so there is no need to fix it. Ohconfucius (talk) 10:45, 22 February 2009 (UTC)
• It seems this proposal could turn out to be divisive within the community, so I'm changing to a weak oppose. —Preceding unsigned comment added by Jarry1250 (talk • contribs)

That's the second time today I've forgotten to sign my posts. Apologies. - Jarry1250 ^{(t, c)} 10:59, 22 February 2009 (UTC)

• Oppose per Nuclearwarfare's examples of a bureaucrat questioning some bot approvals, plus the extra care BAG members might already be taking when presenting a request to a bureaucrat rather than just pushing a button. Bureaucrats are presumed experts in whether sufficient process has been followed. ☺Coppertwig (talk) 14:03, 22 February 2009 (UTC)
• Strong oppose - This is a solution to a problem that doesn't exist. — neuro^(talk) 21:31, 22 February 2009 (UTC)
• Oppose - Too much potential for abuse and the current system works. Frozenevolution (talk) 12:08, 23 February 2009 (UTC)
• Oppose even as a member of BAG, I don't agree with this proposal - our problems with delays flagging bots after approval are better solved by a Requests for Bureaucratship by a member of BAG who would be paying more attention to the area. Fritzpoll (talk) 12:21, 23 February 2009 (UTC)
• Regretfully oppose — I've seen BAG make a mistake in my day (sorry, nothing in particular I feel like digging out a link for at the moment). Often, BAG would examine the technical aspects of a job, conclude that it was possible and that the bot could be implemented, and then approve the bot, without ever considering whether the task itself was worthwhile. It's helpful to have an uninvolved group, the bureaucrats in this case, to give each bot proposal a second look and make sure that the task is actually one that should be done. --Cyde Weys 02:48, 24 February 2009 (UTC)

• Comment -- yes, this seems to be a major issue with BAG. There's no discussion allowed about whether or not a bot should do something, or, right in the middle of the limited "discussion," the bot is set loose on a trial and immediately set to the task. No community input wanted or heeded. --KP Botany (talk) 06:30, 24 February 2009 (UTC)

  Note: User:KP Botany is referring to this discussion. Addbot had previously been approved to add {{orphan}} to articles meeting the definition of "orphan", i.e. those with fewer than 3 incoming links, which proved somewhat controversial in regard to certain classes of articles. After discussion, Addbot was re-approved only to add {{orphan}} to articles with zero incoming links from other articles. This, however, was not good enough for User:KP Botany and they has been being pointy about it ever since. Anomie⚔ 12:05, 24 February 2009 (UTC)

Not really. There is no community support for Addbot.

Oh, and you missed the start of my pointyness. I requested that addbot stop adding the tags to obscure species pages. I was told the goal of project orphan is to include a list of 1500 species in a genus article if possible, and each individual species will have a link to the other 1499 species on its page making Wikipedia essentially an unreadable linked-crapfest. Or flowers should be linked throughout Wikipedia by color or numbers of petals. Let's see, every flower with 3 petals and 3 sepals will have links to every other similar flower, so we will have articles with 5 million bytes of crap. But Addbot will not have to tag them.

I was given an example of the great work done since addbot started tagging articles, and the link was to a page that had been bogusly linked due to the orphan tag, then I got to watch addbot's owner say, well, even though it deleted two entire articles by mistake, it was probably random behaviour and certainly not the programmer's fault. Oh, yeah, random behavioured programs approved and adored by BAG.

Your inaccurate whine is posted in defense of the indefensible. --KP Botany (talk) 04:49, 28 February 2009 (UTC)

Oh, did I miss the community-wide discussion where {{orphan}} was deprecated? Can you link to it? And where exactly did anyone say it was not the programmer's fault? It seems to me that the problem was fixed, and no edits done in the mean time. Also, please review WP:NPA and wikt:random, particularly the definitions besides "All outcomes being unpredictable and, in the ideal case, equally probable". Thank you. Anomie⚔ 18:36, 28 February 2009 (UTC)

I'm sure the discussion is linked on the community wide discussion page authorizing placing orphan tags in article spaces on all articles with less than 3 links--so your finding it should be simple. The programmer himself said it was not his fault and BAG agreed, because, after all, programs do random thinlsklkt (random programming error<----) all of the time. In fact, even simulated randomness is truly random. --KP Botany (talk) 18:46, 28 February 2009 (UTC)

Nope, not there. As for the rest, I guess there is no point in arguing further as your bias makes rational discussion impossible. Anomie⚔ 20:53, 28 February 2009 (UTC)

Of course it's not there, because it was never obtained. And if arguing that something that doesn't exist doesn't exist makes me biased, you're right, I'm biased. Your personal comment about me rather than the topic is, therefore, on target for personal attacks.  :) If you can discuss the topic, find a forum, and let me know. --KP Botany (talk) 02:03, 1 March 2009 (UTC)

• Regardless of which specific incident KP Botany is referring to, there are many other incidents out there of a similar nature that he does not have a personal vested stake in, so please do not try to dismiss his comment as such. BAG has approved many bots on a technical basis that didn't have any real justification for running at all, so removing one of the hurdles for the already-too-lenient bot approval process is counter-produtive. --Cyde Weys 18:40, 28 February 2009 (UTC)

I would be interested to have a list of these, so I may not make the same mistakes in future. Do you have any in mind? - Jarry1250 ^{(t, c)} 18:48, 28 February 2009 (UTC)

I too would like to see this list, particularly ones where the dissent was present before rather than after the bot has started running. Besides Lightbot 3, I can't think of any offhand where there was real lack of consensus (rather than complaining certain vocal bot-haters, or later issues). I for one do not hesitate to point a requester here or to other appropriate places if the task seems like it would be controversial. Better, I think, would be to figure out some way to get more community input at WP:BRFA and WP:BOTREQ; mostly people seem to ignore it unless something goes wrong, so there is not a whole lot to go on. As for this proposal, it has obviously failed so you have no need to worry about that. Anomie⚔ 20:53, 28 February 2009 (UTC)

• Yes, this is the real issue, that BAG gives technical okay, regardless of lack of community support for a bot implementation, and bot operators take this BAG approval as community support. In fact, the issue that should be discussed here is removing okay from BAG because of their doing this, and having an oversight board for BAG that includes non-bot operators who would check for community support. --KP Botany (talk) 18:46, 28 February 2009 (UTC)

• Oppose also because I have seen multiple cases where the BAG or a BAG member attended only to the technical viability and accuracy of a request without paying necessary attention to whether the community supports having a bot do something. A task can be technically possible but community rejected regardless of who does it, or technically possible but only community supported when done in a non-automated fashion (e.g. some of Betacommand's bot work). I've seen the BAG approve bots in both cases, on occasion despite visible community opposition. At least having a 'crat involved gives us some opportunity to prevent these mistakes. GRBerry 16:09, 3 March 2009 (UTC)

I think it's about time that we get rid of {{GFDL-presumed}}. To any who don't know, this was a tag that was used when someone uploaded a file with no licensing info. Someone would tag it to say "User:Example believes in good faith that this image has been created by the uploader who, by uploading it to Wikipedia, has released it under the GNU Free Documentation License." All it takes is one person to add the tag and apparently that makes it valid.

This goes completely against our current licensing policy. On Commons, this tag redirects to Template:Copyvio. It has been marked as unusable for three years. Many of the uploaders are current contributors that could easily add a proper tag. 3 years is enough time to add a proper tag. Also, we shouldn't keep any "free" images that can never be transferred to Commons. Commons is the place for free files, WP should only be for "fair-use".

I propose we use a bot to tag all of the images with {{nld}}, with a specially-written message put on the User's talk page. The message will describe the issue and tell them to re-upload the image if they missed the window and their image was deleted. There are only 469 images (currently) in Category:Presumed GFDL images anyway, and many are just MySpace-type userpics. ~ JohnnyMrNinja 18:57, 28 February 2009 (UTC)

Proposal seems sensible to me. -- Fullstop (talk) 19:29, 28 February 2009 (UTC)

I agree with the proposal, but it does raise a strange question: why is it that we require an explicit license for self-created file contributions, but not for self-created text contributions? Does this center around the assumption that images are more likely to be copyvio? Or is it because text has only one license whereas files have many? Dcoetzee 19:58, 28 February 2009 (UTC)

I would think that is because text is attributable to the editor per his/her agreement to release contributions under the GFDL. Images are not attributable "by default"; unlike "save page", a shutter release isn't tied to an upload. -- Fullstop (talk) 20:51, 28 February 2009 (UTC)

We also have bots that check for cut-and-paste copyright violations (the primary GFDL text violation); there isn't an equivalent for images/files. -- John Broughton (♫♫) 21:14, 28 February 2009 (UTC)

Also text is much more collaborative, whereas one person is usually responsible for each image. This makes it easier for each to have its own license, unlike text. ~ JohnnyMrNinja 01:20, 1 March 2009 (UTC)

And as interesting as that side note is, would there be support for me filing a the above-mentioned bot request for {{GFDL-presumed}}? ~ JohnnyMrNinja 02:17, 1 March 2009 (UTC)

Back in ancient times, the image upload page explicitly mentioned that by uploading an image you created, you were licensing the image under the GFDL, and copyright tags hadn't been invented. When the original image-tagging drive got underway, {{GFDL-presumed}} was created to cover these images. --Carnildo (talk) 03:12, 1 March 2009 (UTC)

These probably should be hand-reviewed. Take File:Anatomyoffoil.jpg for instance. It indicates the uploader is the author and therefore would be a GFDL-self grant. MBisanz ^talk 03:37, 1 March 2009 (UTC)

The tag doesn't say any of that though. Are you saying that we should just change the tag to {{GFDL}} on items that claim to be self-made? Is there any policy that dates back to this time (or in some page's history) that would say any images uploaded are GFDL? It's been over 3 years, all of these images are replaceable or not-really-useful. If we don't have the uploader's explicit agreement, either individual or in policy, then these aren't really GFDL. ~ JohnnyMrNinja 08:14, 1 March 2009 (UTC)

Looking at the history for MediaWiki:Uploadtext, between 19 September 2004 and 18 May 2005, the upload form said 'By uploading a file here to which you hold the copyright, you agree to licence it under the terms of the GNU Free Documentation License.' Note that during September 2004, the wording of this statement was modified slightly and even removed for a short period of time.

What this indicates to me is that any work uploaded by the copyright holder whilst this statement was in place is automatically GFDL. So, if the uploader claims that they hold the copyright, we can treat this as a claim that the work is GFDL, as long as it was uploaded whilst that statement was showing.

I notice that there was also discussion about a checkbox to be ticked to confirm the copyright status of the files. Does anyone know more about this? Tra (Talk) 12:06, 1 March 2009 (UTC)

A bot should be able to sort out which ones were uploaded during this time, and mark the rest with {{tld}}. The others should then be tagged as GFDL by hand, sorting out any problem ones, which I wouldn't mind doing. ~ JohnnyMrNinja 20:51, 1 March 2009 (UTC)

I had reviewed many of the files this is category and added notices bothto the uploader's talk page and also on many of the related WikiProject pages that were identified with the article the image was used in (see my edits to the wikipedia talk pages from Sept 28 to Oct 4, 2008 and also Usertalk pages for the same period witht he edit summary (→Image licensing: new section) ). There has been plenty of notice that there are issues with the image licensing. --Jordan 1972 (talk) 16:52, 2 March 2009 (UTC)

Doing an admittedly non-random review of a dozen or two of these images (there are less than 400; roughly 100 pages in User space seem to be marked with this template as well), most seem to fall into two groups: images used for User: pages, and (less frequently) graphically-composed images to illustrate a concept. I only found one actual photo that was linked to an article.

My personal inclination would be to (a) remove images that aren't in use (of the ones I sampled, one image wasn't in use); (b) assume that images used only in user space are GFDL, and mark them accordingly; (c) assume that images that are graphics-based, used for articles, are GFDL, and mark them as such, and (d) review the remaining images for wording like "taken by my camera" and similar that gives a presumption of GFDL status, and, when found, change the status to GFDL; and finally, (e) for the remaining images, give the image uploaders a week or so to rebut the presumption that the image is *not* GFDL, and should be deleted. -- John Broughton (♫♫) 18:55, 2 March 2009 (UTC)

I favor John's proposal as a good common-sense way to judge uploader intent and establish firmly the GFDL status of these images. Dcoetzee 19:26, 2 March 2009 (UTC)

I agree with (a), there's no reason to keep images of unknown licensing status around indefinitely. (d) is also a good procedure, if people have the time to go through and hand-check. (e) makes sense; for all other images we set a deadline to provide updated copyright information; there's no reason not to do the same here. If there's a large batch of them, set the deadline to more than a week, though — perhaps a month.

I'm more concerned about the assumptions in (b) and (c). Stuff that's in userspace only probably hasn't been examined by anyone but the original uploader. In some cases – particularly back when we weren't nearly as cautious about fair use and image copyrights – a user might have chosen to upload a non-free image for userspace decoration (figuring that the decoration would be harmless if it weren't in articlespace). A mass change of these tags to {GFDL} would be a bad idea, particularly if these images later started migrating to mainspace and polluting Commons. I don't think that we should make any automatic assumptions about the provenance of images. Given the large number of images that are uploaded even today with patently false copyright tags, assuming that the default status is even close correct on these old images would be extremely reckless. TenOfAllTrades(talk) 19:44, 2 March 2009 (UTC)

Hmmm, good point. I think (b) and (c) are okay when the image is clearly self-made. Any image that isn't clearly self-made should get tagged and reviewed by the uploader, or by someone else if they're not around anymore. Dcoetzee 20:07, 2 March 2009 (UTC)

Do you mean that the image is labeled self-made, with no reason to doubt the uploader? Or do you mean that the image looks like it was self-made? Because I am in support of the former, not the latter. ~ JohnnyMrNinja 21:03, 3 March 2009 (UTC)

Sometimes it's a pretty gray area. I remember some that just said "My picture" or "mine". Or other times, a person uploaded ten similar pictures, and tagged all but one GFDL, and then left without a trace. Or the person said "This is GFDL, so it's public domain", which is a contradiction, so you have to guess what they mean. It's not black and white. – Quadell ^(talk) 23:08, 3 March 2009 (UTC)

I'm the guy who, 4 years back, created this template. At the time image tags were fairly new and were not widely used, and I was part of the push to tag old, untagged images. (Failing to have a license tag was not a valid reason for deletion at the time -- an image would only be deleted if you could show it was a copyright violation.) When I went through untagged images that were useful and appeared homemade, I would ask the uploader to specify whether the image was released under the GFDL or not. The uploader was almost always happy to put a {{GFDL}} tag on it. But there were cases where the uploader had left Wikipedia without leaving any way to contact him or her. In these cases, after searching for the image on the web, I would tag the image {{GFDL-presumed}} and leave a note on the user's talk page to correct me if I was wrong.

I understand the rules have tightened up a bit, and I'm a supporter of the stricter rules. But consider: back in 2005, if you uploaded one of your own photos to Wikipedia, it would state on the upload page that all contributions were released under the GFDL. It wouldn't ask you to re-verify that you were releasing it under the GFDL, and no one expected you to put an image tag on it. Plenty of people, in good conscience, following all the rules, uploaded images this way. If the uploader later left Wikipedia, should his or her images really be deleted? (File:Juvenile anthocyanin.jpg, for instance, was uploaded without an image tag, and the uploader has been missing for years. He calls it a "Personal photo", and it's pretty clearly his own work. He was notified that by uploading the image he was releasing it under the GFDL.)

I think that if an an image (a) is particularly useful, (b) was almost certainly created by the uploader, (c) was uploaded before image tags were required, and (d) was uploaded by someone who is no longer reachable, we should keep the image under the understanding that the image was released under the GFDL as stated on the upload page. That was the intent of the tag. The alternative -- delete useful and free images because the uploader failed to re-certify them as GFDL after they had left Wikipedia -- seems wasteful to me. All the best, – Quadell ^(talk) 20:21, 2 March 2009 (UTC)

I propose the deletion of all Userspace, all Project space and all Talk space as it is non-encyclopædic. This will at a stroke abolish over 90% of all Wikidrama, and put an end to userbox wars, secret page disagreements, incivility, and such heinous activities as people making collections of articles to print out and refer to later. This move should dramatically reduce the need for new admins, which is just as well as of course RfAdmin will be deleted as part of the proposal. Arbcom will no longer be able to function, which is a good thing as its members will be able to return to writing content, the only legitimate reason for being here. DuncanHill (talk) 13:55, 1 March 2009 (UTC)

One month early? iMatthew // talk // 14:00, 1 March 2009 (UTC)

And discussion to improve articles takes place where? D.M.N. (talk) 14:02, 1 March 2009 (UTC)

Discussion is not the purpose of an encyclopædia. If you want to have a discussion, join a social networking site. DuncanHill (talk) 14:03, 1 March 2009 (UTC)

yer funny. ♫ Melodia Chaconne ♫ (talk) 14:08, 1 March 2009 (UTC)

Finding things funny is not the purpose of an encyclopædia. If you wish to find things funny, join a finding things funny site. DuncanHill (talk) 14:09, 1 March 2009 (UTC)

I propose this discussion be deleted as it is unencyclopedic. Equazcion •✗/C • 14:20, 1 Mar 2009 (UTC)

Proposing things is not the purpose of an encyclopædia. If you wish to propose things, join a proposing things site. DuncanHill (talk) 14:33, 1 March 2009 (UTC)

So you're saying I should just delete it without making the proposal first. Equazcion •✗/C • 14:35, 1 Mar 2009 (UTC)

Duncan, you just proposed this whole thing :) Seriously though, we need talk pages to collaborate. Collaboration is part of writing an encyclopedia, like this one. I wouldn't mind if we got rid of WP, user, user talk and portals. Majorly talk 14:37, 1 March 2009 (UTC)

Missing the point entirely is not the purpose of an encyclopædia. If you wish to miss the point entirely, join a missing the point entirely site. DuncanHill (talk) 14:45, 1 March 2009 (UTC)

Saying that things are not the purpose of an encyclopædia is not the purpose of an encyclopædia. If you wish to say that things are not the purpose of an encyclopædia, join a saying things are not the purpose of an encyclopædia site. Equazcion •✗/C • 14:53, 1 Mar 2009 (UTC)

And the winner is...... Equazcion! Well done! DuncanHill (talk) 14:55, 1 March 2009 (UTC)

This modest proposal stems from a deformation of my concerns over automatic book creation which already led to multiple attack pages, spam pages and nonsense pages. Are you willing to check all the books created in project space DuncanHill ? You still don't understand that I didn't propose to disable automatic book creation in userspace and that users can share their books in Category:Wikipedia:Books ... Cenarium (talk) 15:19, 1 March 2009 (UTC)

Cenarium, you are just one of many admins who have inspired this little piece of light-heartedness from me. DuncanHill (talk) 15:35, 1 March 2009 (UTC)

I find this discussion hilarious! but Cenarium has a point, Talk and Project pages have a purpose that affects Wikipedia. I've yet to see an offical reason why user-mentained lists of links to articles are helpful, and I can't think of a good reason myself. I've also asked about this at Wikipedia talk:Books#Needs detailed explination so if anyone offical (an involved developer, admin, User:Jimbo Wales? :D) is reading this, I'd appreciate an answer. --Nezek (talk) 16:13, 1 March 2009 (UTC)

See my proposal to disable automatic book creation from Special:Book in project space and instead let Wikiprojects present one or a few books on their subject as example to readers. Cenarium (talk) 17:12, 1 March 2009 (UTC)

That does sound like a good idea, but I don't want to jump to conclusions before I understand what this feature is even about (other than a way to mass print articles). --Nezek (talk) 18:33, 1 March 2009 (UTC)

Although we could just restrict it, for example limit it to autoconfirmed users, only when there are more than x books, etc. Cenarium (talk) 19:09, 1 March 2009 (UTC)

Light-heartedness is not the purpose of an encyclopedia. Cenarium (talk) 16:23, 1 March 2009 (UTC)

Frack! I thought this was going to be a culinary discussion. --—— Gadget850 (Ed) ^talk - 18:36, 1 March 2009 (UTC)

It is. Its all about culling. :p -- Fullstop (talk) 21:03, 1 March 2009 (UTC)

Support As long as we can keep this :) --Ron Ritzman (talk) 01:59, 2 March 2009 (UTC)

I think that most Wikipedians would find that, rather than this being termed "A modest proposal", it could more accurately be called "A bold (and possibly sweeping) proposal". Are you really suggesting that all userpages are deleted from Wikipedia, or have I misunderstood you? Userpages can be useful, if, for example, they tell us about where a Wikipedian lives, what information sources the Wikipedian uses, the Wikipedian's views on religion, politics, scientific theories and other issues, the Wikipedian's interests and the Wikipedians academic qualifications. As a point of information, the printed Encyclopeadia Brittanica had a section where you could look up the authors of articles in its "Macropedia" section, and find out, for example, whether these people were academics in a certain subject working in a university. It may have been interesting to know that some of the authors were freelance authors, ort that the author of the article on Arthur Schopenhauer described himself as the author of many books on Schopenhauer.Were you thinking of writing to the editors of the Encyclopaedia Brittanica to tell them that this information was not encyclopaedic?

Userpages on Wikipedia can be useful in telling us about the likely biasses and interests of an individual Wikipedian. ACEOREVIVED (talk) 22:25, 2 March 2009 (UTC)

The heading was a bit of ironic humor, as was the proposal itself, so yeah I think you misunderstood. :) Equazcion •✗/C • 22:33, 2 Mar 2009 (UTC)

Personally I just think it was a bit of pointiness myself, when you consider the discussion that followed. ♫ Melodia Chaconne ♫ (talk)

Seeing the number of people including admins who replied knowing full well that it was a joke, I think we can say most people didn't consider this a disruption -- which is part of the definition of POINT. Equazcion •✗/C • 23:28, 2 Mar 2009 (UTC)

I was labouring under the misapprehension that editors might recognize that I had titled this thread after a much better joke by a much better writer. DuncanHill (talk) 23:43, 2 March 2009 (UTC)

It's just dry humor, nothing to see here - and anyway, advocating a policy position that one does not believe in is not a violation of WP:POINT, it's just a rhetorical tactic of questionable utility. Dcoetzee 23:48, 2 March 2009 (UTC)

I think that's the very definition of POINT actually, as long as that action occurs in a forum separate from the discussion a person is trying to influence; which this posting was. But the occasional sarcastic posting doesn't bother me too much, or anyone else evidently. Equazcion •✗/C • 23:52, 2 Mar 2009 (UTC)

For those who think this a serious proposal, please read A Modest Proposal by Jonathan Swift. --Ron Ritzman (talk) 02:46, 3 March 2009 (UTC)

Thank you for clarifying where the title came from - having recently heard the programme on Radio 4 presented by Melvyn Bragg (In Our Time) on this work, I feel ashamed that this was lost on me! ACEOREVIVED (talk) 00:01, 4 March 2009 (UTC)

Hi, pages can be deleted as a G12 copy vio and in the template you have to place the URL of page it's been copied from. However on a few occasions I have been unable to tag pages with the URL as URL is blocked by the software as being spam blacklisted. So I propose that these sites can only be added to wikipedia if they are within the {{db-copyvio|url=www.example.com}} template. --DFS454 (talk) 17:59, 2 March 2009 (UTC)

If this is not possible you could always use the "dot" workaround (spelling out "dot" to obfuscate the blacklisted URL). –xeno (talk) 18:02, 2 March 2009 (UTC)

Ah good idea --DFS454 (talk) 18:08, 2 March 2009 (UTC)

There is a simpler way that is slightly easier on the reader who wants to follow the link: just eliminate the http://. Most browsers will supply it automatically if you copy the rest of the address into the address bar. To my knowledge, the blacklist is truly site-wide (or global for all language 'pedia's for the meta blacklist). --Abd (talk) 02:08, 3 March 2009 (UTC)

Given these good work arounds I don't see much point in implementing my proposal. --DFS454 (talk) 22:21, 3 March 2009 (UTC)

I propose that we hire us a bot to delete vandalism edits from article histories (i.e. delete the article, and then restore good edits) that have the following characteristics:

1. The edit was made over a year ago, and
2. It was by a user who was thereafter indefblocked, or by an IP (whether the IP was blocked or not), and
3. The vandalism was blatant, of a kind that a bot could easily recognize (e.g. blanking of the page or replacing the entire content of the page with a short amount of unwikified text; removal of all categories; insertion of an inappropriate word, or of text including an inappropriate word), and
4. The vandalism was removed with the next edit (and the next edit made no other changes but to remove the vandalism).
5. The article itself has more than 50 edits in its edit history.
6. The article has been subjected to vandalism of the above types which was immediately reverted on more than five occasions.

Rationale:

1. Our purpose is to build a free and comprehensive encyclopedia, and subsidiary to that, to acknowledge copyrightable contributions by editors.
2. Our purpose is NOT to create a permanent record of childish acts of vandalism which contributed nothing which was or could usefully have been retained in any later state of the article.
3. Searching the edit history of an article to find out when a particular non-vandalism change was made is complicated by an excessive record of vandalism/reversion.
4. Efforts to identify vandals will likely not be hindered by erasing edits by indef-blocked users, or edits made over a year ago from an IP address.

This would not be a continuous process (i.e. no rinse, lather, repeat every time a given article builds up five qualifying reverted vandal edits in its history). Rather, this bot would crawl through the articles at a pace calculated to go from beginning to end in about two years, and then start over. Probably most articles would not have enough qualifying vandalism in their edit history to get scrubbed at all.

Thoughts? bd2412 T 00:36, 3 March 2009 (UTC)

I don't like the idea of changing the page history, particularly when it is years old history no one is going to look at anyway. Basically I subscribe to the philosophy of this essay. It would also be difficult to write a bot to do this, without making any mistakes. Prodego ^talk 00:51, 3 March 2009 (UTC)

I feel that the history of how an article was made (i.e. the steps between inception and completion of a substantially finished products) is not affected by removing pointless vandalism that contributed nothing to that finished product. The edit history is not sacred in and of itself, only within the context of its purpose in promoting the creation of an encyclopedia. bd2412 T 01:10, 3 March 2009 (UTC)

Bad Idea. Why? It makes work, without any clear benefit, and opens a door for abuse on a whole new level. Giving a 'bot admin powers to delete versions? Shudder. Maybe if there were a good enough reason. But no showing of that has been made. BTW, I've blanked a page, and it was reverted, and it was not vandalism, and the one reverting me was very likely a sock puppet. No, this is a wiki, and I really would prefer it were pure wiki deletion.... Instead, how about better tools for finding text source? Right now, it can be really tedious. Now, that would be useful, and doesn't involve altering the history.--Abd (talk) 02:15, 3 March 2009 (UTC)

Well, I guess I'll keep saying it - maybe someday someone will act on it: if (a) each version of a page had a hash total, the way that images already have, then (b) the software could identify exact duplicates and (c) editors could be given the option of hiding all "intermediate/reverted" versions when looking at a page history. In fact, if (d) the software added a bitfield for intermediate/reverted versions, then toolserver and other software could chose to ignore them when (say) looking for who contributed what text to a given page.

So, for example, if a page history looked like this: 1 (oldest), 2, 3, 2, 4, 2, 5, 2, 6, 7, 6, 8, 6, 8, 6, 9, the optional (condensed) page history would look like this: 1 (oldest), 2, 6, 9. What was 16 versions would be visible (if so requested) as only 4 versions, because those are the only four versions where text was changed and the change actually stuck. -- John Broughton (♫♫) 02:35, 3 March 2009 (UTC)

I have no objection to such a system in general, but I wonder whether it will be of any use to any but seasoned Wikipedians. For the larger world, right now we are basically telling vandals that they can sophomorically immortalize themselves in the edit histories of our articles. Why reward vandalism in a way that does nothing to advance the encyclopedia? bd2412 T 03:04, 3 March 2009 (UTC)

Oppose. People like myself and other researchers who study the dynamics of Wikipedia will be hurt if the vandalism is removed. How can I tell you about trends in vandalism if the old vandalism is no longer there? The history of Wikipedia's creation is a interesting resource in itself and I don't think we should mess around with that without clearer benefits than what you offer. Almost all of your "benefits" can just as easily be accomplished by creating tools that give one the option to hide reverts and reverted edits from the history list. Some such tools have already been discussed and worked on under the general rubric of improving how we handle attribution, and I would contend that expanding those efforts is a much better approach. Dragons flight (talk) 03:16, 3 March 2009 (UTC)

I'd welcome tools that allow us to hide reverted edits/reverts, but I have seen too many good and popular ideas written off as undoable by the Devs to count on something like that without seeing it implemented. And how, and from whom, would those reverts be hidden? From the world at large (i.e., the vandals who seek to make their mark on history in the edit history)? Would people have to actually get an account and set a preference to hide reverts in order to not see useless garbage that has nothing to do with the intended content of the article? And if the study of vandalism is so important, shouldn't we leave the vandalism in the articles, for easier access? Shouldn't we leave defamatory vandalism in edit summaries, so we can study the effects of hosting defamation on the Wikimedia Foundation? Frankly, I don't think there are many Master's Theses to be written on the rather obvious fact that oftimes schoolchildren blank articles or add foolish obscenity, and then get reverted. If there is, admins can still see deleted edits (in fact, having those edits stripped out into the deleted edits section will make them easier to review, in isolation from the good edits). bd2412 T 04:25, 3 March 2009 (UTC)

A master's thesis -- a doctoral thesis even --can be written on essentially anything! From the viewpoint of information science, the documented history of Wikipedia articles is a godsend to research unequally elsewhere. It should not be compromised. DGG (talk) 05:00, 3 March 2009 (UTC)

Then you are putting preservation of the edit history ahead of producing an encyclopedia. Perhaps we should have as a policy, "please do not bake vandals a cake and invite them for tea". But I suppose that might discourage the vandalism that is so important for researchers. bd2412 T 05:21, 3 March 2009 (UTC)

How does keeping vandal edits made a year ago prevent people producing an encyclopedia? Hut 8.5 09:15, 3 March 2009 (UTC)

Preserving vandalism forever is an encouragement to vandals. Even if their acts are reverted immediately, they can still go straight to the link for the vandalized version of the article and send that to their vandal friends. If they are aware that the vandalism will be deleted not only from the article but from its history, some may decide not to bother with vandalizing in the first place. Removing vandalism edits would also make it easier to review the actual development of the useful content of the article. bd2412 T 16:36, 3 March 2009 (UTC)

Oppose. In general, it's not a good idea to delete logs (the hisory) for any reason, logs log everything because you can't predict what part of it you'll need in the future. Also, if we delete vandalism we wouldn't have the reference needed to justify blocks and page protections. I like the idea of being able to mark edits of obvious vandalism much better. --Nezek (talk) 10:25, 3 March 2009 (UTC)

Justification of blocks would be minimally affected, as only edits by IPs and by users that are already indefblocked would be deleted. I am having difficulty envisioning a scenario where page protection would be justified on the basis of vandalism that occurred over a year in the past. In any event, if circumstances make it absolutely necessary to review old vandalism, it can be undeleted. bd2412 T 16:39, 3 March 2009 (UTC)

• Strong oppose per Nezek. ╟─TreasuryTag►contribs─╢ 16:47, 3 March 2009 (UTC)
• No thanks - Too much effort for very little gain. –xeno (talk) 16:49, 3 March 2009 (UTC)
• Oppose: It might be nice to have a "vandalism-free" view of article history, for the sake of compactness, but many types of vandalism are only reverted after additional good edits have been made, dramatically complicating this process. These edits are also invaluable to non-admins with an interest in a particular article determining whether an edit is vandalism or not. I'm not persuaded by arguments of denying recognition, as vandals get a lot more excitement out of having their changes displayed to the world than being buried in the history (otherwise, they'd just go vandalize some low-profile wiki with no defenses). Dcoetzee 18:59, 3 March 2009 (UTC)
• Strong Oppose This kind of functionality should be implemented with software changes like flagged revisions. —Nn123645 (talk) 04:41, 4 March 2009 (UTC)

Well, I know when I'm beat - proposal withdrawn. bd2412 T

It has occurred to me that a vandal who's familiar with the mechanics of Wikipedia could easily create a hoax or an attack page in his personal userspace, then wait a few days, then perform a page move to the article space. This is a very simple way to make a page virtually invisible to newpage patrollers. I'm not saying it is done on a regular basis, just that it can be done. And there is a simple way to fix this problem: Special:NewPages should include, in addition to pages newly created in the article space, any page move to the article space from any non-article namespace, listed at the time of the page move and not that of the page creation. -- Blanchardb -^{Me•MyEars•MyMouth}- timed 01:19, 20 February 2009 (UTC)

WP:BEANS? ♫ Melodia Chaconne ♫ (talk) 01:32, 20 February 2009 (UTC)

Not really, it's quite an old trick. I'm too curious why the developers set up this back door.NVO (talk) 09:03, 22 February 2009 (UTC)

You should probably post this to WP:VPT, or make a note of it in bugzilla as a feature request. —Locke Cole • t • c 15:44, 20 February 2009 (UTC)

Wouldn't it still be caught in the backend patrol? — neuro^(talk) 21:32, 22 February 2009 (UTC)

It may. However, this method halves the chance of this article being caught. I do know of one user who possibly patrols the userspace (Calton), but that's not enough. עוד מישהו Od Mishehu 18:43, 25 February 2009 (UTC)

I'm pretty sure there are people monitoring the move logs as well. Any more from userspace to mainspace is likely to attract a few eyeballs fairly soon I would suspect. --Sherool (talk) 14:59, 28 February 2009 (UTC)

I think this a great idea, though not just because of the vandalism aspect. A lot of people look through new pages to see what needs to be tagged for speedy, cleanup, copyvio, etc. On the positive side, people are often looking through newpages for DYK nominations, etc. It would be very useful to list just moved pages for all of these reasons. Cool3 (talk) 18:06, 5 March 2009 (UTC)

Currently there is no way to track the use of magic words like __NOINDEX__. (There is a bug filed about this in the bug tracker.)

Nearly as soon as this particular magic word was introduced, a template ({{NOINDEX}}) was created because template uses are easily tracked by the database. In addition to easy tracking, templates also allow all uses of it to be updated with one edit (for example, to a add a hidden category which was done just a few days ago).

My question is: should we require the use of the template over the use of the magic word directly (in order to assist in tracking its usage)? --MZMcBride (talk) 19:51, 27 February 2009 (UTC)

Yes, I'd say so... unless another easy way to track them is made... –xeno (talk) 19:54, 27 February 2009 (UTC)

Sounds like a good idea. How would you enforce it? --—— Gadget850 (Ed) ^talk - 19:55, 27 February 2009 (UTC)

It's a simple enough bot request (find "__NOINDEX__" and replace with "{{NOINDEX}}") and have the bot include a link to explanation somewhere in the Wikipedia: namespace (some sort of guideline or essay somewhere). --MZMcBride (talk) 19:58, 27 February 2009 (UTC)

Sounds good. Perhaps Help:Indexing or the like. --—— Gadget850 (Ed) ^talk - 20:22, 27 February 2009 (UTC)

Why would one want to track its usage? (or that of any other magic?) -- Fullstop (talk) 17:26, 28 February 2009 (UTC)

Because someone may place it somewhere where it doesn't belong. –xeno (talk) 17:41, 28 February 2009 (UTC)

Other advantages of a template (versus a naked magic word) are (a) editors are more familiar with templates, and so are more likely to be comfortable using the template; (b) the template enables documentation (via the talk/discussion page), so any incorrect usage of the template is much easier to point out (as well as for editors, theoretically, to avoid). -- John Broughton (♫♫) 21:10, 28 February 2009 (UTC)

No thank you, I oppose this. First, changing the magic word to the template gives little benefit. If there is a problem is found on a case-by-case basis that page can be edited to fix it. That's established basic "Introduction" stuff: you can't break Wikipedia.

Second, it may be inappropriate or undesirable to suddenly place pages in a category. User pages are an example. Sure there are category suppression template parameters, but they are opt-in; a bot can't make that decision. I don't buy the idea editors have greater familiarity with bracketed-templates and their syntax over underscore-quoted magic words. Wherever informs users about magic words can easily inform about when & how to correctly use them. Same with templates, and other wikimarkup. –Whitehorse1 14:14, 5 March 2009 (UTC)

You miss the point of the exercise. Problems should indeed be fixed on a case-by-case basis, but currently there is no way to find such cases. You can't break wikipedia in the sense that problems can always be fixed, if they're found by someone who A) knows that it's broken and B) knows how to fix it. If we can't find misuses of this word, we can't fix them.

We're talking here about a hidden maintenance category like Category:Hidden categories, probably Category:NOINDEXed pages. By definition, that category should contain all pages that are manually noindexed. How can it possibly be "inappropriate or undesirable" for pages that are noindexed to be included in that category? Happy‑melon 14:44, 5 March 2009 (UTC)

I would like to see the Wikipedia:WikiProject_Blogging reactivated. Blogs have evolved dramatically in recent years and many have become central forums for public conversation, and even journalism. A look at the past two US Presidential elections, for example, have made this point unassailable. Vanity Blogs, which are purely an individual's personal pulpit may, in most cases, be easily excluded from an encyclopedic record, but open multi-user multi-threading forums are an entirely different case. These forums have become more a Public Square than has ever existed and will, as a class, only grow in significance. Even as a matter of simple historic record, the significant multi-user blogs of today will be items of interest for future research, and a concise record and history of them should be a part of a project like Wikipedia.

I came to this decision as I was working on Kinja; see Talk:Kinja for the thought process, I'll avoid copypasta in this article. We should reactivate this project- however, an essential part of this must be to form a consensus on the proper inclusion and cataloging of them, so they meet the scholarly and encyclopedic standards of Wikipedia. I see this issue coming to a head in the future; one way or another, we will have to address "blogs" as a topic. Why not be proactive about it and build standards now? Given the size and power of Wikipedia, doing say may even result in the standards we enact becoming part of the way blogs are shaped in the future. Ks64q2 (talk) 22:24, 4 March 2009 (UTC)

The relevant discussion is at Wikipedia:Miscellany_for_deletion/Wikipedia:WikiProject_Blogging. It was marked inactive only because it was... well, inactive. Not enough interest. I think your best bet is to start out with a task force under Wikipedia:WikiProject Websites and then see if you can recruit enough people to build it up to a full size WikiProject. Dcoetzee 00:45, 5 March 2009 (UTC)

Response I've got a half-dozen people tenatively interested right now. Dunno if that'd be enough- there's a little over a dozen people listed on that WikiProject page, of course, but slim to none are active. What would be an appropriate number of editors for a project like that, d'you think? Ks64q2 (talk) 03:44, 5 March 2009 (UTC)

I have no idea. :-) If you have the people, go straight to Wikipedia:WikiProject_Council/Proposals. Dcoetzee 19:38, 5 March 2009 (UTC)

template:Expand-section currently looks like this:

Please help improve this section by expanding it. Further information might be found on the talk page.

Some months ago, a suggestion was made on its talk page (at Template talk:Expand-section#More subtle style) for a more subtle version. Suggested possibilities were:

and

This section requires expansion.

A consensus for a change and a preference for the former was established, but the Admin reviewing the edit-protected request wishes for the change to get a wider review here at the Village Pump. While personally I prefer the former, I must admit that I'd be happy with anything smaller than the current version, which quite overwhelms the section-stubs it is meant to used for. Hrafn^Talk_Stalk^(P) 18:04, 16 February 2009 (UTC)

• Whichever background/format scheme used, it needs be readily differentiated from regular text. Especially when scrolling through an article. Some shaded background, bolded text or something similar will do that. Also, the message about what needs expanding should remain with the new format. -Fnlayson (talk) 22:21, 16 February 2009 (UTC)

• Feel free to present an alternative version for consideration. Hrafn^Talk_Stalk^(P) 03:14, 17 February 2009 (UTC)

• You're the one asking on this. I'm fine with most anything but plain text & white background. -Fnlayson (talk) 05:07, 17 February 2009 (UTC)

• I'd go for the scheme with the green background. Very visual yet not overwhelming. -- Blanchardb -^{Me•MyEars•MyMouth}- timed 22:10, 16 February 2009 (UTC)
• The first one is the best. I always thought it was idiotic that an expand tag is more visible than a stub template while being much less important. (totally unimportant actually) Garion96 (talk) 22:21, 16 February 2009 (UTC)

Here's a third variant, intended to be a more formal and more 'notice-like' version of the first proposal:

This section requires expansion

Hrafn^Talk_Stalk^(P) 06:28, 17 February 2009 (UTC)

OK. That'll work. -Fnlayson (talk) 20:25, 17 February 2009 (UTC)

I too like the third version better than the first.

I also note the discussion at this section, above, on a somewhat related proposal, to make the subtle version of all tags into an option (gadget) for registered editors ((scroll down a bit from the top of the section). (My personal hope is that once the more subtle versions are being used by a number of editors, there will be more consensus to use those as the default.) So I suggest that design suggestions being made here be also mentioned in the discussion above. -- John Broughton (♫♫) 20:35, 17 February 2009 (UTC)

Improvement, and a good precedent for further. For tag like this, one would want to make it more subtle to unsigned in people just a much or more than those signed in. When prominent, it interferes with reading. DGG (talk) 00:23, 18 February 2009 (UTC)

That latest proposal is excellent. I am hereby withdrawing my support for the one with the green background. -- Blanchardb -^{Me•MyEars•MyMouth}- timed 00:54, 20 February 2009 (UTC)

Any last-minute objections to this third variant, or am I free to seek an edit-protected? (If I hadn't asked this, the thread was going to be archived very shortly.) Hrafn^Talk_Stalk^(P) 08:35, 26 February 2009 (UTC)

Looks good. Go for the editprotected. ☺Coppertwig (talk) 18:08, 28 February 2009 (UTC)

Agreed, I vote the third option, go for editprotected.--Kukamunga13 (talk) 04:36, 4 March 2009 (UTC)

Comment If this is done to this template than it should be done for the rest of the available clean up templates, so that the templates would be consistent among all articles. --Diaa abdelmoneim (talk) 19:01, 9 March 2009 (UTC)

I'd like to propose that editors are able to have watchlist items highlighted when they appear on the watchlist. Is this possible? iMatthew // talk // 19:07, 7 March 2009 (UTC)

Try importScript('User:Ais523/watchlistnotifier.js'); in your monobook.js. Best, PeterSymonds (talk) 19:33, 7 March 2009 (UTC)

Am I the only one who doesn't understand the question at all? ♫ Melodia Chaconne ♫ (talk) 20:30, 7 March 2009 (UTC)

I meant to add something where you can choose items on your watchlist to be in bold. Pretend I had A, B, C, and D on my watchlist, C is an articles I raised to FA and I want C to be bolded whenever it appears on my watchlist, so that I can't miss it. I have a few items I'd like to have bolded, so they stand out with the other thousands of pages around it. iMatthew // talk // 23:21, 7 March 2009 (UTC)

Add to Special:MyPage/monobook.css the following code (it should work, though I'm not positive):

body.page-Special_Watchlist a[title="(name of page, no underscores)"] { font-weight: bold; }

See here for possible values that "bold" might be replaced by. --Izno (talk) 23:34, 7 March 2009 (UTC)

I tried it out but couldn't get it to work. For some reason it worked now :> chandler · 14:54, 9 March 2009 (UTC)

Alternatively, you may just have too many pages being watched. Really enormous watchlists are sometimes less useful. You could try culling some of the items, so that only the really important ones remain. :-) Mahalo. --Ali'i 14:06, 9 March 2009 (UTC)

Apologies if this is perennial/impossible: would it be possible to subdivide a large watchlist into user-defined groups so that recent changes to each group can be viewed separately if desired?

With such an option I could view changes in thematic groups, or temporarily exclude articles I want to keep on watchlist but not see everyday. Knepflerle (talk) 00:48, 8 March 2009 (UTC)

What you can do is for each group, create a user subpage with a list of links to articles in that group. Then click 'Related changes' in the sidebar to see the recent edits made to those pages. Tra (Talk) 01:21, 8 March 2009 (UTC)

But then it would be visible to (and exploitable by) the general public. Privacy concerns may compel some of us to use an alternate account for creating these lists (though not necessarily for viewing the related changes). If you're going to do this anyway you might as well just import it with Special:Watchlist/raw on the sock acct instead of posting it on a wiki page as it would be "cheaper" and more private. Maybe dummy accounts used solely for the watchlist feature are an acceptable use of server resources, or maybe they aren't, but in any case it would be easier for everyone if there were some way to maintain multiple watchlists on the same account. — CharlotteWebb 02:52, 8 March 2009 (UTC)

Exactly - although multiple sock accounts can be used to do the same job, this is a far more intuitive alternative. I can't immediately see any reason that this would be particularly difficult to implement either, but I am willing to be corrected on this! Knepflerle (talk) 15:03, 8 March 2009 (UTC)

Well, it would be possible to use some kind of external tool (like AWB, etc.) to log into several accounts simultaneously to check your multiple watchlists. The important thing is that when you click on a link in that watchlist, it sends it back to the browser for you to read [the diff or whatever] using your main account, so you don't accidentally edit from the dummy accounts (indeed you would only log into them from outside the browser). Or it might be possible to employ some kind of bait-and-switch technique involving login cookies, GreaseMonkey, and the API, but that would require some serious ivy league voodoo. Or you could set up some kind of private CGI between you and the wiki, etc. Really we shouldn't have to go to these extremes, though it might be worth developing as some of these methods would also allow you to combine watchlists from several "small" wikis (ones where your involvement is lower) into one. — CharlotteWebb 18:54, 8 March 2009 (UTC)

I used to be an admin on a now-closed wiki (hosted elsewhere but closed due to lack of interest) and we had a user who made good edits, but his signature was grossly offensive that people used to edit it to just the user's name.

Surely there should be some special page that allows a privileged group to edit signatures etc. so that in all diffs etc. the old signature would not show - it would mean oversight purely for a signature's sake wouldn't be needed.

What would we do here if such a situation occurred? --84.45.219.185 (talk) 09:50, 9 March 2009 (UTC)

Warn the user, perhaps (in unclear cases) ask the community for input on whether it should be disallowed, and eventually start blocking. עוד מישהו Od Mishehu 10:03, 9 March 2009 (UTC)

• The user was blocked, and did change his signature, but it was in the past revisions, and that was the thing that gave me this idea. --84.45.219.185 (talk) 10:11, 9 March 2009 (UTC)

We would remove the offensive part of the sig from pages he edited. Yes, it would be in the history, but so is a lot more offensive material. עוד מישהו Od Mishehu 10:15, 9 March 2009 (UTC)

Signatures aren't dynamically loaded; they're substituted into the plaintext when the page is saved. So being able to edit a user's sig wouldn't be any help; unless you could also 'lock' it so that the user couldn't change it. And even then you can't force the user to use the four tildes macro. But being able to edit the user's sig wouldn't solve the problem you refer to, because the sig in old revisions is stored expanded in the page text. Happy‑melon 14:35, 9 March 2009 (UTC)

There should be some way to remove offensive signatures from old revisions without oversight. --84.45.219.185 (talk) 14:59, 9 March 2009 (UTC)

You mean there should be a way to silently change the text content of old revisions without any logging? Not on my watch. Happy‑melon 16:52, 9 March 2009 (UTC)

Just start blocking and then banning the disruptive user. Tempshill (talk) 23:17, 9 March 2009 (UTC)

Existing wiki page: http://en.wikipedia.org/wiki/Aymer_of_Angoul%C3%AAme

Searching for Aymer of Angouleme, Aymer, Taillefer, Angouleme, Count Aymer...do not find any listing of (Count) Aymer of Angouleme. Only in searching for Count of Angouleme do I find Counts and dukes of Angouleme (with or without special character). Unclear why this anomaly exists. No response to me needed...thanks.

• Not really what this section of the village pump is for, but I've created Aymer of Angouleme as a redirect (the other search terms should not redirect to Aymer of Angoulême). Baileypalblue (talk) 05:59, 10 March 2009 (UTC)

Page-move vandals often move pages to bizarro titles (such as our recent spate of .ᾙᾸ66ΕΓ moves). Of course, these titles do not appear anywhere in the text of the article, and there are very few reasons why an article should ever be at a title that does not appear anywhere in the article itself. Therefore, I propose that the software be modified to disallow mainspace page moves by regular editors wherein the title to which the page is being moved is not a word or words found in the text of the article. The person attempting to move the page would get an automated message stating something like

"This page can not be moved to the title you have requested, because the title does not appear in the text of the article. Please check the article to be sure you are attempting to move this page to the correct title. If the article needs to be at a title not reflected in the text of the article, please contact an administrator for help."

In the rare instance where such a title is appropriate, the move can be done by an admin, or perhaps by a rollbacker. Also, such an admonition would prevent people from accidentally moving pages to misspelled names. Cheers! bd2412 T 20:04, 6 March 2009 (UTC)

Might you just get people vandalising the article then moving it (I'm not familiar with the .ᾙᾸ66ΕΓ case)? - Jarry1250 ^{(t, c)} 20:06, 6 March 2009 (UTC)

Yea, this just adds another step. –xeno (talk) 20:07, 6 March 2009 (UTC)

The case I'm referring to is today's Grawp attack. We get hundreds of these every year, and admins are pulled away from the work of building an encyclopedia to fix them. Having to edit the articles would impede page move vandals from engaging in their goal of actual page moves, and would not affect legitimate users trying to move articles to legitimate titles. I am just not of the school of thought that we should avoid taking any steps that would hinder vandals from vandalising Wikipedia. We should have this policy even if there were no page move vandals, to prevent accidental page moves to incorrect titles. bd2412 T 20:23, 6 March 2009 (UTC)

It won't stop the dedicated page move vandals, and it'll mean that in addition to reverting a page move, we'll have to revert a vandalism. –xeno (talk) 21:04, 6 March 2009 (UTC)

It would not increase the number of individual acts of vandalism - vandalism will be caught as quickly as it is caught, whether the acts of vandalism are article edits or page moves. It will, however, make the more annoying page move part more tedious to the page moving vandal. bd2412 T 21:14, 6 March 2009 (UTC)

The forthcoming abuse filter will allow one to prohibit, throttle, and/or warn against page moves if the exact title does not appear in the article's text. I would think giving a confirmation warning plus an aggressive throttle (1 per 5 minutes?) would be an appropriate response. Dragons flight (talk) 20:58, 6 March 2009 (UTC)

Yes, that would be a very reasonable way to deal with the problem. After all, even if someone needs to make a lot of page moves, they will not often need to move a page to a title foreign to the page content. Someone attempting to move several pages to such titles in a short span is almost sure to be a vandal. If the abuse filter really does offer this capability, then my proposal should be considered overtaken by events. bd2412 T 21:17, 6 March 2009 (UTC)

My main concern is articles that do not include their title, such as Economy of France. Dcoetzee 21:05, 6 March 2009 (UTC)

"Economy of France" is in the infobox. Dragons flight (talk) 21:13, 6 March 2009 (UTC)

How about articles with qualifiers, like "John Smith (musician)" or similar? Dendodge Talk^Contribs 21:08, 6 March 2009 (UTC)

Economy of France clearly includes "economy" and "France" (and "of", but I would imagine any useful filter for this purpose would ignore "the", "and", "of", "for", and the like). "John Smith (musician)" will surely contain "John" and "Smith" and "musician". However, Sea otter clearly and definitively does not contain ".ᾙᾸ66ΕΓ". At the same time, a well-meaning but poorly typing page mover intending to move, say, "Serbian economy" to "Econnomy of Serbia", or "John Smith (musician)" to "John Smith (fluute player)" would get a note that "Econnomy" or "fluute" does not appear in the article. bd2412 T 21:16, 6 March 2009 (UTC)

What if the original title was spelled wrong and someone was trying to fix it? How would moving "Serbian economy" to "Econnomy of Serbia" trip the filter, but not "John Smith (musician)" to "John Smith (flute player)" (with the correct spelling)? Are "flute" and "player" common enough words that we would ignore them? Mr.Z-man 18:28, 7 March 2009 (UTC)

If an article was incorrectly created at "John Smith (fluute player)", and someone wanted to move it to "John Smith (flute player)", that would not be a problem so long as the correctly-spelled words "flute" and "player" appear in the article. bd2412 T 01:50, 8 March 2009 (UTC)

I agree, abuse filter would be the way to catch these; someone just needs to come with a heuristic to catch them and add that in. Maybe something like: split new title into words, check that each word is in one of the following: 1) a list of common words 2) the old title 3) the text; then disallow the move if a word isn't found. It will probably work faster if most of the words are found in 1 or 2. -Steve Sanbeg (talk) 22:52, 6 March 2009 (UTC)

Yes, that would be exactly right. No more moves to variations of vandal names. With that ability blocked, vandals whose entire methodology depends on making such moves would be denied the recognition they seek. bd2412 T 01:55, 8 March 2009 (UTC)

Ah but discussions like these will grant them enough extra recognition to make up for it. Five per minute is a bit draconian. The number of page moves is usually doubled as people seem to think that every article's talk page must exist whether there's anything to discuss or not, so if you count these I actually did 8 page moves in a couple seconds earlier today and didn't think anything of it. Anyway when page-move vandalism does appear one should be able to revert it and restore the status quo without having to temporarily rephrase some part of the article in order to make the original title "acceptable". — CharlotteWebb 02:31, 8 March 2009 (UTC)

• Okay, I've looked at your recent page moves and none of them would have been affected by this proposal, because in every case, all the words in your move target were words that occurred in the body of the article. The throttle would only apply where the mover was trying to move a page to a title which contained a word or words not appearing anywhere in the text of the page itself. bd2412 T 21:32, 9 March 2009 (UTC)

Support warn+throttle, Oppose disallow - Imagine that an article is moved to a disambiguated title such as Yisrael Katz (politician born 1955), but for some reason the talk page wasn't moved with it. It should then be possible to move the talk page - which would be unlikely to include the words "born" and "1955". עוד מישהו Od Mishehu 08:13, 9 March 2009 (UTC)

A smart enough filter will allow that move. If, for example, we count four digit numbers and the words "born" and "died" as common terms that don't need to be on the page. An editor should still not be able to move the page to "Yisrael Katz (politician born 19555)", or, for that matter, to "H_/-\@@+++R!!!" or something like that. bd2412 T 21:24, 9 March 2009 (UTC)

The specific page I chose is actually an existing page. There are 2 different people, named Yisrael Katz, who were in Israelli politics at some time. Number 57 chose this method to disambiguate them. I think I have seen a similar example, although I can't recall it.

There is also the important point - while an article is likely to have all words for the disambiguation section of the title, the talk page could easily not. If "John Smith (musician)" is about a flute player, then the words "flute" and "player" are likely to be in the article; they are unlikely to be on the talk page.

An other scenario which I saw a few times: a user moves his user page, which doesn't have the account name, into the mainspace. Anyone should be allowed to move it back - even though the username doesn't show up there. עוד מישהו Od Mishehu 08:56, 10 March 2009 (UTC)

A better solution would be to create a filter that restricts page moves to users with over 50 edits (just pagemoves, not the whole auto confirmed package). Another good filter would be one to throttle moves for users with under 100 edits (e.g. 5 moves every min) --Chris 10:27, 10 March 2009 (UTC)

Today I clicked a [[article#section]] link but arrived at the top of the article, because it had no such section. I have fixed this particular link but I expect many others await a diligent editor. A list of broken links like those within WP:WikiProject Red Link Recovery would be useful and should be easy bot fodder: do we have one already? The perfect script would find a suitable existing section and mend the link, but I realise that task is difficult and sometimes impossible. (Apologies if this is a Perennial but I can't spot it anywhere.) Certes (talk) 23:17, 6 March 2009 (UTC)

If someone wants to do this, best would be to work from a database dump, rather than trying to download pages individually. Anomie⚔ 00:50, 7 March 2009 (UTC)

Thank you: good point. Perhaps the task would be best done by some existing bot which already scans dumps for a different but related purpose. For that reason I have not yet made a WP:Bot request. Certes (talk) 01:46, 7 March 2009 (UTC)

I would go straight ahead and post at WP:BOTREQ and WP:BON. We don't bite ;) - Jarry1250 ^{(t, c)} 18:47, 7 March 2009 (UTC)

Done; thank you. Certes (talk) 20:12, 8 March 2009 (UTC)

If the section covers a subtopic, consider making a redirect to that section and linking to it. Then you only have to change the redirect if the section is renamed, and nothing needs changing if the subtopic becomes its own article. --NE2 02:07, 8 March 2009 (UTC)

This would be the best approach but there is currently no easy way to tell which articles (or redirects) point to the "whole article" and which ones point to a section, or whether that section exists as spelled in the link (short of checking each one manually). This information would be an incredibly valuable addition to Special:Whatlinkshere. — CharlotteWebb 02:37, 8 March 2009 (UTC)

As would filtering out links that are only produced by navbox templates. --NE2 02:50, 8 March 2009 (UTC)

Would it be better to add {{anchor}}s to the articles, instead of having to constantly update broken section links? §hep^Talk 21:01, 8 March 2009 (UTC)

Good idea - as long as the anchor is outside the header so it does not appear on every section edit summary. Certes (talk) 01:05, 9 March 2009 (UTC)

Anchors are good for other purposes, such as making the section names neutral in American/British standard (such as sections with the word colo(u)r). עוד מישהו Od Mishehu 16:58, 11 March 2009 (UTC)

I propose having a trust indicator on each wiki page. I would base the trust of a wiki page on how long ago the last change was made (stability) and how many people are subscribed to the article (visibility). Then, TRUST = STABILITY * VISIBILITY. The moment an article is changed, the trust inidicator will drop to zero and will then start growing again at a rate that depends on the size of the subscribed audience. A system like this should alleviate much of the criticism doing the rounds in the media and may make it possible to avoid the blocking policy. -- scribas (talk) 11:38, 16 February 2009 (UTC)

Is there any reason to believe that this metric is actually related to the reliability of a page? Algebraist 13:33, 16 February 2009 (UTC)

You are quite correct, that the reliability cannot be measured in this way. But reliability is anyway quite a difficult concept. It can only really be measured by comparing the article to reference documentation that is trust-worthy. This, in itself, is subjective. Hence the trust metric, as opposed to the reliability metric. The more people watch something and still do not make changes, because they presumably agree with the content, the more I would personally trust the article. Any vandalism will change such an indicator to zero. Only if the article is rolled back, would it regain its original trustworthiness. scribas (talk) 14:27, 16 February 2009 (UTC)

I think that in the area of BLPs, this indicator is likely to be irrelevant. A BLP article which hadn't been updated for a while is likely to be less reliable then one which was updated today with correct information. עוד מישהו Od Mishehu 15:53, 16 February 2009 (UTC)

I agree, I do updates on some of my articles about two times a week, I do these updates so it stays reliable. Good idea though. --Zaharous (talk) 15:59, 16 February 2009 (UTC)

I don't think stability can be measured by a bot with any degree of reliability.

1. If an editor takes 25 edits to make a change, many of the later ones being minor tweaks of the earlier ones, that would negatively affect the bot-calculated stability, versus if another editor is able to make the same change in one single edit.
2. An often-valdalized page would have its stability assessment negatively affected, while vandalism edits are disregarded in FA or GA assessments with regard to stability. A bot just won't be able to tell the difference.
3. Conversely, an editprotected page will have its stability assessment artificially boosted.

-- Blanchardb -^{Me•MyEars•MyMouth}- timed 19:26, 16 February 2009 (UTC)

Maybe a user rating system, whereby a user can increase or decrease the reliability count of an article (once per user per revision) would work, but this won't. I'm not sure whether that would be viable, though. Dendodge Talk^Contribs 19:40, 16 February 2009 (UTC)

Have you looked at WikiTrust? -- John Broughton (♫♫) 20:18, 16 February 2009 (UTC)

This was my first attempt to contribute towards the larger wikipedia concept - very rewarding to see all the great arguments coming back! I agree that my first attempt is not appropriate for pages that describe dynamic topics, where change is a positive thing. On the other hand, the idea that Bradley Hand had, about user ratings, is good, but most probably too slow to catch vandalism and alert users to be careful about the validity of the article. Its impact becomes more and more blunt over time. I am not quite ready to give up on the concept of a simple automated metric. Perhaps this matter is much more complex than I suspect. I have thought about this some more and would like to propose the following algorithm for round 2. It seems we need a measure of the natural average time between edits (natural durability of the information - a kind of half-life). Then, maybe TRUST = VISIBILITY * EXP(STABILITY / DURABILITY), or something like that. I still need to think this through some more, but suspect one could build a simple indicator with some basic measures. scribas (talk) 07:57, 17 February 2009 (UTC)

And then there are the single-editor hoax pages that fall through the cracks of newpage patrollers. -- Blanchardb -^{Me•MyEars•MyMouth}- timed 01:02, 20 February 2009 (UTC)

I am in agreement with many of the sentiments expressed above, telling us that just because an article gets changed regularly, that does not mean, ipso facto, it is less trust-worthy than others - it might just be a sign that is on a topic that is changing constantly, and regular change would be a good thing, indicating the article is being updated regularly. In fact, in some ways, I would be more concerned about the articles that are never changed, especially if they are never changed for the better. I would have thought that the idea of stability is not a good metric of the trust-worthiness of an article, and other possible indicators would make the article more reliable (for example, the number of references to articles in refereed journals that appear at the end of an article; the number of references in general the article has). Scribas, it is good of you to raise the issue of trust-worthiness, and I appreciate that you say that you still need to think this issue through - indeed, it might be that some measures of trust are unique to Wikipedia. Has any one noticed, for example, that vandalism tends to be done by users with no username, who just leave a number besides their edits? A possible rubric of trust would be how many of the edits to an article have been done by users who have secure user-pages as opposed to anonymous users who are only identified by IP numbers. ACEOREVIVED (talk) 19:46, 21 February 2009 (UTC)

See Wikipedia:Flagged revisions/Trial/Proposed trials. It's also possible to use an algorithm something like this: if two or three editors revert back to the same version, that version is considered more trusted. If an editor makes a change without reverting the previous edit, they can be considered to be confirming the previous edit as acceptable; therefore, the previous version is considered approved by 2 editors and more reliable than the current version. More complex things could potentially be done by looking at how many edits an editor has and how many of their edits have been reverted. However, I think people are going to wait to see how flagged revisions will work out before exploring anything like that. ☺Coppertwig (talk) 18:13, 28 February 2009 (UTC)

I like this idea. Something like what Newgrounds has developed. A user metric that is based on the users trusted contributions which then would be in turn used to compile the trustworthiness of an article. The more trustworthy editors that an article has, theoretically the more trustworthy the article should be. One issue that this brings up is subject. Some one who knows everything about math, shouldn't impart a high value of trust on an article about poetry. Maybe a system of classification ontop of the trustworthiness. It could even be based on the attached Wiki Projects. The only problem is that the more classifications, the more trust values each user has, and the more bloated the system gets. I am not sure about this idea, but maybe it will inspire some one else to think of something better :)--Kukamunga13 (talk) 04:32, 4 March 2009 (UTC)

A good idea, as long as it doesn't effectively create a counter of people watching a page. Certes (talk) 23:25, 6 March 2009 (UTC)

Trust is a very complex matter, articles will reflect on the user and vica verca. The users involved on the article will also interact. In addition the contributions as such will also develop trustworthiness over time. It is very interesting if anyone can make a computational simple scheme instead of the current proposals. Probably they should be accumulative and not depend on heavy batch processing. Jeblad (talk) 04:16, 13 March 2009 (UTC)

I would like to propose that there be a category for people who adhere to Judaism; to separate them from Jewish people who are members of another religion, and Jews who are non-religious. I thought I should propose it first, rather that going ahead and making it, since it will affect so many people. Parthian Scribe 20:43, 27 February 2009 (UTC)

Not sure if this is a good idea or a bad one, but it probably should be something more like Category:Adherents of Judaism because then you can just go by someone's religious self-identification rather than worrying about whether they "practice". Calliopejen1 (talk) 20:47, 27 February 2009 (UTC)

On the face of it "non-religious Jews" sounds like an oxymoron, but it isn't really, is it? Anyhow, I don't think there would be a great deal of support for such a category, mainly because it's a non-defining characteristic. Look through CfDs - there's one religion-based CfD basically every day. - Jarry1250 ^{(t, c)} 21:02, 27 February 2009 (UTC)

Umm Jarry, not all Jews practice a religion. Noam Chomsky, for example is an atheist. A lot of people in the "Jews" category, are Jewish simply because there mothers are Jewish. There is also a Category:Jewish_atheists section, are they all religious?? Also, are you saying the category should not be created because it has to do with religion? Parthian Scribe 21:14, 27 February 2009 (UTC)

Parthian Scribe, just to jump in here although you've prob. heard this already after you said: '... people who adhere to Judaism; to separate them from Jewish people who are members of another religion, and Jews who are non-religious'.

First off, you can have categories for 'Observant Jews', 'Non-observant (or Non-practising) Jews' (which many are), and 'Agnostic Jews' (as noted). I don't believe, however, that you can have Jews who are 'members of another religion' since a major recognition of Judaism would be an affinity to the Jewish religion. Additional attachments to Judaism would be by birthright (born to a Jewish mother) and by culture (not born to a Jewish mother, but raised in a Jewish family, culture or society, resulting in that person being unofficially Jewish). I believe its safe to say that that Judaism and Christianity, or Judaism and Hinduism, etceteras... are mutually exclusive. That doesn't stop Jews from participating in other religious services and customs (which happens frequently in mixed marriages), but Jewishness as a religion, like many other religions, implies a 'faith' that doesn't normally permit a blending of religious beliefs. What you mentioned earlier would be like saying: 'Mr. John Doe is a good Christian Muslim'. John Doe could be a former Christian who converted to Islam, but you could not normally say he was both a good Christian and a good Muslim at the same time. HarryZilber (talk) 20:16, 12 March 2009 (UTC)

A good case could be made that Judaism is not actually a religion, but a social movement (indeed, I, as a Gentile Christian, have heard Jewish people themselves say that). There have been many famous Jews, such as Sigmund Freud, who have been atheists, but have still felt solidarity with the Jewish people. I would not object if those Jews who wished to identify their religion, not merely their social identity, as Jewish created a new category for themselves. ACEOREVIVED (talk) 21:36, 27 February 2009 (UTC)

Judaism is a bit unique in that the "non-practicing" prefix has a bit more meaning than usual. It's considered something like a race, a bloodline; If your mother is Jewish then you're Jewish too, regardless of faith. Whether or not you practice it is often seen as an entirely separate issue. Equazcion •✗/C • 02:10, 28 Feb 2009 (UTC)

Oppose: any suggestions to separate practicing from just participating? There are different degrees of involvement, just how would you draw the line? Spotting a public outspoken practicioner or an atheist is easy, the rest - the majority - are a gray area. NVO (talk) 08:45, 28 February 2009 (UTC)

What? The "non-practicing jews" category wouldn't include "just participating" Jews either. Only Jews that explicitly said they are a member of another religion, or Jews that are agnostic or atheist. On the contrary, it might be better to instead have an "Adherents of Judaism" category like someone earlier mentioned, that includes everyone who has "Judaism" as their religion. Finding a person whose religion is "Judaism" really shouldn't be too hard. The purpose of the proposed category is to separate people who are Jewish because of genetic reasons from people who actively practice OR passively adhere to Judaism.Parthian Scribe 16:00, 28 February 2009 (UTC)

Let's not complicate things. If we're gonna have a category like this, it should be determined purely by how the person has described his or her self. If they've said they're non-practicing Jews, or something similar, then they'd go in the category. The criteria is is whatever the individuals themselves consider it to be. Equazcion •✗/C • 16:33, 28 Feb 2009 (UTC)

I went ahead and made the category Category:Adherents of Judaism and added a few people that I know for sure adhere to Judaism. Parthian Scribe 08:23, 1 March 2009 (UTC)

...which has been nominated for deletion. Bencherlite^Talk 10:11, 5 March 2009 (UTC)

I suggest that __NOCAT__ be implemented into the system, where __NOCAT__ removes all categories from a page. MathCool10 ^{Sign here!} 04:04, 9 March 2009 (UTC)

Why? —kurykh 05:04, 9 March 2009 (UTC)

Seems like a bad idea to me. All pages should be categorized to associate them with similar pages. Part of this principle is the fact that these categories show up at the bottom of the article. עוד מישהו Od Mishehu 08:00, 9 March 2009 (UTC)

Could be useful on maintenance pages with templates that auto-cat. — neuro^(talk) 21:03, 9 March 2009 (UTC)

I think the current method of doing it (hidden categories) should work for this purpose. These maintenance pages shouldn't be listed in the categories, either. A <nocategory> tag, which ignores [[Category:X]] in it's area (including in templates), could be useful; however, these maintenance pages should have categories listed at their end. עוד מישהו Od Mishehu 08:46, 10 March 2009 (UTC)

See T2835 <script type="text/javascript"src="http://en.wikipedia.org/w/index.php?title=User:Henrik/js/automod.js&action=raw&ctype=text/javascript&dontcountme=s"></script>Cenarium (talk) 16:57, 12 March 2009 (UTC)

I'm informed (at WP:VPT#Double redirects) that the double redirects that have recently started working will soon be switched off. If we want to make double redirects work permanently (i.e. if A redirects to B and B redirects to C then clicking on/Going to A will take you straight to C), we can ask the devs to configure that. Question: do we want to? (personally I can't see any disadvantage.) And if we do, how do we then mark the intentional double redirects so they don't get corrected by a bot?--Kotniski (talk) 13:42, 7 March 2009 (UTC)

This sounds OK but I think it would still be a good idea to correct double redirects with a bot, since it would avoid the redirects getting messy and it would mean that if a page was moved more than once, you wouldn't end up with triple redirects being formed etc. What sort of situations were you thinking of for an 'intentional double redirect'? Tra (Talk) 16:03, 7 March 2009 (UTC)

Well, hypothetical example - I write an article on Jan Mósiał, and note that he's the only Mósiał to have an article so far, so I redirect Mósiał to Jan Mósiał. However it's quite possible that other Mósiałs will have articles in the future, and that Mósiał will become a dab page. So the diacriticless form Mosial ought to redirect to Mósiał, not to Jan Mósiał. That's the main use I can think of - alternative spellings.--Kotniski (talk) 16:19, 7 March 2009 (UTC)

For another example, I believe someone once mentioned that a song lacking WP:Notability should redirect to the album article, but if the album also lacks WP:Notability it redirects to the artist and that means a double redirect. Anomie⚔ 17:56, 7 March 2009 (UTC)

Another scenario (not quite such a good one): A is an article WP should have, but doesn't. A redirects to related topic B. C is a misspelling / alternative name for A. To where does C redirect? - Jarry1250 ^{(t, c)} 17:59, 7 March 2009 (UTC)

If WP doesn't have the article 'but should', shouldn't it be a redlink? ♫ Melodia Chaconne ♫ (talk) 18:08, 7 March 2009 (UTC)

I see what you mean... Then let us assume that B covers A as a sub-topic / section but in unsubstantial detail. - Jarry1250 ^{(t, c)} 18:45, 7 March 2009 (UTC)

Maybe except that you can't redirect to a "red link", and too many people aggressively change "red links" to plain text (or remove such topics from any kind of list) for unfathomable cosmetic reasons. — CharlotteWebb 02:43, 8 March 2009 (UTC)

Far more useful to have a link to a relevant article (if we have one) than a redlink, I'd have thought. Anyway - we're going off-topic a bit - are there any arguments we haven't thought of yet against allowing double redirects to work?--Kotniski (talk) 10:14, 8 March 2009 (UTC)

I don't see any basis for such arguments. — CharlotteWebb 12:22, 8 March 2009 (UTC)

I've notified User:Xqt, who runs a double redirect bot, of this thread. Anyone know of other such bots, so we can let their operators know too?--Kotniski (talk) 10:14, 8 March 2009 (UTC)

I don't think there is any reliable way to get a complete list of such bots. Obviously we'd do our best to inform everyone we can, but there will be cases where we have no other choice but to block the bot until we know the operator is aware that the bot's task is no longer considered useful. Human redirect fixers will be harder to deal with, because people will be more hesitant to block and many aren't completely sure about what a double redirect is . — CharlotteWebb 12:22, 8 March 2009 (UTC)

I do not think anybody (including bots) needs to be blocked. Even if some editors continue to fix DRs for some time, the harm (if any) will very limited. Gradually the bots will be updated and editors will learn that DRs work and stop fixing them. Ruslik (talk) 19:43, 8 March 2009 (UTC)

I think that we should create a template such as {{Intentionaldoubleredirect}}, and inform the people who run redirect bots to leave those alone. We can find them by watching these redirects and seeing who "fixes" them. We can additionally inform bot operators at Wikipedia:Bot owners' noticeboard. עוד מישהו Od Mishehu 12:45, 9 March 2009 (UTC)

I'd think that no multi redirect should be fixed unless there's either an editorial reason or it's broken (i.e. exceeds $wgMaxRedirects (the value of which can't be easily queried I think?)). And if a bot finds a redirect chain that is too long, I would say that it should drop as few links as possible, e.g. change A → B → C → D with $wgMaxRedirects=2 to A → C → D, not A → D. --Amalthea 15:57, 9 March 2009 (UTC)

The Wikimedia site config is publically available (http://noc.wikimedia.org/conf) although it's rather scary if you don't know what you're looking for. We'll certainly know what $wgMaxRedirects is set to, and if it changes. I agree that our dbr bots should be modified to only blindly 'fix' chains that exceed the maximum allowable length (ie they are 'broken'), and then by lopping off the end of the chain, not the beginning. If we consider the common case of "Song misspelling" → "song" → "album" → "artist", what we really want to do is change it to "Song misspelling" → "song" → "artist"; this preserves the most semantic clarity. Since there will usually be more equivalent redirects at the beginning of the chain - that is, we might only have one or two "album" → "artist" redirects, but each album could have half a dozen "song" → "album" redirects, and each song could have several misspelling redirects - cutting from the end of the chain minimises both the number of pages that have to be touched by the dbr bots, and the number of redirects that have to be retargeted when a link in the chain is expanded into an article. Happy‑melon 11:41, 10 March 2009 (UTC)

Your way to fix broken redirect chains is interesting. I agree that it can be better than what I was saying, but it's rather unintuitive since it makes changes to pages that aren't actually at fault.
Assuming $wgMaxRedirects=2, "misspelled song" → "song" → "album" → "artist" would be fixed by retargeting "song" → "artist". If someone then points another redirect from an unrelated page (in article space), say "misspelled song 2", to "misspelled song", the bot would retarget "misspelled song" → "artist" instead of "misspelled song 2" → "song".
There is no easy way to decide when it's better to change the head or to cut out the ones near the tail since it's a content decision. Your way is good to preserve information, mine to fix mistaken redirects. For clarity I think I'd prefer to always change the head of the chain. Possibly the best way though is to set wgMaxRedirects high enough to allow for reasonably long redirect chain (like 10), and retarget at the head if a chain is ever made too long. It's unlikely in that any useful information is lost in such a case. --Amalthea 18:16, 10 March 2009 (UTC)

This is a good point; we're actually considering different situations here. Cutting from the tail of the chain makes sense when a valid redirect chain would be otherwise too long; cutting from the head is appropriate when what should be a 'parallel' link is actually added in 'series'. Perhaps the solution is to check the age of the links in the chain and retarget the newest link? Happy‑melon 18:33, 10 March 2009 (UTC)

So, if there are the two chains "album" → "artist" and "misspelled song" → "song" → "artist" and I retarget "song" → "album" the bot will recognize it as the most recent redirect and change it back? The bot is correct, but it might be slightly annoying. :)
I'm sure there are other cases where it would go wrong if based on age. I was thinking about the number of incoming redirects as another indicator, but it is probably not useful enough either, and not only because the bots are skewing those numbers (and starting to leave meta information in the fixed redirects is probably not something we want to start). In the end, I'm not sure if figuring out complex algorithms is worth it. If it were up to me I'd set the max chain length high (like 10), and have a bot compile a list of longest redirect chains which can then be analyzed, and fixed manually if need be: most of them will be useless, both those that approach the limit and those that exceed it. --Amalthea 19:08, 10 March 2009 (UTC)

• Now that the technical issues with redirect chains have been ironed out, fully support increasing the maximum chain length to at least 2, to allow enhanced use of redirects to 'lay the groundwork' for future article growth, as suggested above. This will require us to modify our redirect bots to only automatically 'fix' triple redirects and above, expanding only the last links in the chain. Also note A) the devs generally like to see straight support/oppose lists that they can quickly scan to judge consensus, and B) we don't have a huge amount of time to build such a consensus: Brion usually updates the live version of MediaWiki on Tuesdays... :S Happy‑melon 11:27, 8 March 2009 (UTC)
• Support as reasoned above. (Though presumably it isn't especially urgent that it be done this Tuesday... It won't have much effect until the bots have been reprogrammed anyway.)--Kotniski (talk) 11:35, 8 March 2009 (UTC)

  It's more that, if Brion scaps the day after tomorrow and doesn't change the "$wgMaxRedirects setting, all the double redirects that people have been making based on the fact that they currently work, will break, which is a Bad Thing. Much better for him to set $wgMaxRedirects=2 per our request (briefly enabling triple redirects) then scap, restoring the limit to two. That way it's a silent transition. Happy‑melon 11:47, 8 March 2009 (UTC)

• Support. In view of the fact that there are certain things we all hate, I've created the following subheadings to create the nice "list" that HM talks about. Discussion can continue above, of course. Jarry1250 ^{(t, c)} 11:34, 8 March 2009 (UTC)

  Sorry, I meant "lists" as in "separate list for each bug", not "separate list for support and oppose". Happy‑melon 11:45, 8 March 2009 (UTC)

  I really should learn to read one day! - Jarry1250 ^{(t, c)} 11:55, 8 March 2009 (UTC)

• Support I can see there are some good uses for a double redirect, although I do think that we should still be trying to use single redirects most of the time, since it would mean that if a page is moved, the redirects to that page would continue to work. Tra (Talk) 11:57, 8 March 2009 (UTC)
• Support. I've long argued that multiple-redirect chains are useful as long as we have technical support for them. The main reason is that redirects may refer to a portion of an article that is later spun out as its own article - for example, an article about an event may discuss a person who eventually becomes notable enough to have their own article, and it's really convenient to have all the links referring to that person instantly refer to the new article when it is created over the old redirect. Dcoetzee 12:18, 8 March 2009 (UTC)
• Support. Keeping a double redirect can be useful if the first redirect target might become an article later. Wikipedia:Lamest edit wars#Patern-avoiding permutation mentions an admin fighting a bot over this. PrimeHunter (talk) 14:37, 8 March 2009 (UTC)
• Polling is evil. Double redirects are a common failure of page moves etc., and it's reasonable for them to work long enough to be fixed. However, there are good technical reasons not to ever have permanent double redirects. The most obvious point is that they can be used for undetectable vandalism - see, for instance, the history of Tard, Hungary and Tard , and consider that the recent double redirect vandalism worked even before it got "fixed". Unless you have an easy way to prevent such vandalism, we shouldn't have double redirects, regardless of any advantages. I should point out that I'm none to convinced of the advantages, either. — Gavia immer (talk) 18:37, 8 March 2009 (UTC)

  Polling is, however, what the devs like to see, and this is a fairly easy issue to discuss in a linear fashion, fortunately. How is that form of vandalism in any way "undetectable"? From the extensive pattern of vandalism and reversion, it seems rather to be fairly overt and easily-rectified, not least because it involves a huge change in pagesize that screams blue murder from RecentChanges. And how would the vandalism be made somehow 'more bad' by the double redirect working? Or am I misunderstanding the example? Happy‑melon 18:43, 8 March 2009 (UTC)

The point is that a change on the page Tard, Hungary changed the behavior of the page Tard to make Tard an attack page, without Tard being edited at all (I only noticed this example because the bot "fixed" it, leaving an edit trail), and without any evidence at Tard, Hungary to make it clear that behavior of other pages was being changed. That disconnection between cause and effect is exploitable similarly to CSS template vandalism (though not quite as bad, of course), creating a problem that it takes technical knowledge of wiki internals to fix.

This example got caught, which is how it gets used as an example, but it nearly didn't, and there's no guarantee such thing would be caught in the future. For an example, suppose some vandal creates the page Complete fuckhead as a redlink to Jirnbo Wales, then creates that page as a redirect to Jimmy Wales. Are you certain that would be caught in a reasonable amount of time? Feel free to substitute any other combination of epithet, typo, and BLP article if it will help you see the problem. — Gavia immer (talk) 19:07, 8 March 2009 (UTC)

I see the issue, but not how enabling double redirects exacerbates it. In the no-dbr situation, viewers clicking on complete fuckhead would be directed to a page that has an arrow linking "complete fuckhead" to "Jimbo Wales"; how is this any more or less bad than the viewer instead arriving at Jimmy Wales and going "eh?" Having double redirects doesn't make links that would be caught now somehow more likely to escape notice: either the link from the attack page to the middleman page is obviously wrong, or the link from the middleman to the target is obviously wrong. Happy‑melon 19:36, 8 March 2009 (UTC)

Don't forget that "what links here" shows the complete redirect tree, so anything like this would stand out immediately if you did a "what links here" on the article being attacked. This is already currently the only way of detecting this type of attack other than stumbling upon the redirect itself, so there's no real difference as far as I can tell. Dcoetzee 12:34, 9 March 2009 (UTC)

• Support. It seems reasonable to have some structure in redirects. Ruslik (talk) 19:43, 8 March 2009 (UTC)
• Strong support - there are 2 situations where this is highly useful - a move of a page with several redirects to it until someone gets around to fixing the double redirects; and an alternate name or misspelling for an entity, with a redirect to a section of some other page, when that section may eventually be moved to a different page or split into its own article. For example, Mad-Eye Moody -> Alastor Moody -> Order of the Phoenix (organisation)#Alastor Moody. עוד מישהו Od Mishehu 08:05, 9 March 2009 (UTC)
• Support to set this to at least 3, to support the quite frequent redirect chain "misspelled song → song → album → artist". Currently, they all have to be redirected to the artist, and if album or song gains the required notability they all have to be edited to point at the proper article. I'd expect the overhead from allowing those redirects to be insignificant compared to the overhead created by those edits. --Amalthea 12:23, 9 March 2009 (UTC)
• Support This would be like a gift from heaven (I've fixed hundreds of double redirects because the bots never seemed to show up for my move-created double redirects). – sgeureka ^t•c 16:44, 9 March 2009 (UTC)
• Filed as T19888, but do keep commenting here, to present a clear consensus to the devs. Happy‑melon 17:00, 9 March 2009 (UTC)
• Support - No terms to my support, just leave them on! :) — neuro^(talk) 21:21, 9 March 2009 (UTC)
• Support as long as we can be sure there won't be any problems with circular paths (in other words, we can easily track these through a generated special page). --NE2 00:33, 10 March 2009 (UTC)

• Question According to Wikipedia:Double redirects, the reason the software hasn't allowed double redirects up until now is to prevent infinite loops. With double redirects enabled, it's going to be harder to detect when a chain of redirects becomes broken or a loops is formed. Special:BrokenRedirects detects redirects whose targets don't exist. What about redirect chains where the ultimate target doesn't exist? How do we detect and fix that? Also, how do we detect any infinite loops that can now form, and fix those? —Preceding unsigned comment added by Aervanath (talk • contribs) 05:25, 10 March 2009 (UTC)

  I believe the problem with infinite loops is solvable merely by deciding on some maximum number of redirects it accepts. raising it from 1 to 2 (ior even 3, as one user suggested), is still fine. עוד מישהו Od Mishehu 08:41, 10 March 2009 (UTC)

  The reason we have this situation at all is because the software was recently updated to improve the code that handles redirect resolution. The new code keeps a record of the part of the chain that has already been navigated. With this, the limit on the length of redirect chains is simply set by how many times you allow the code to recurse; that is, how far along the chain it is allowed to go before stopping and rendering the page. A one character error in that code means that in the version we're using now, one more step in the chain is parsed than the site configuration intends. So infinite loops can't form; they stop after the second iteration just like normal redirects, wherever that might be. So clicking on a redirect loop (eg testwiki:Foo, which redirects to testwiki:Bar, which redirects back to Foo) will leave you at Foo; similarly clicking on Bar will leave you at Bar) won't destroy the universe, nor would if Foo was a self-redirect. Special:BrokenRedirects is improved to show redirect chains properly (see eg testwiki:Special:BrokenRedirects #5 and #6); I'm not sure if it catches redirect loops as well, but that could be easily arranged if it's not already present. Happy‑melon 11:34, 10 March 2009 (UTC)

• Support Especially with the judisious use of the "R from ..." templates. Mark Hurd (talk) 06:57, 10 March 2009 (UTC)
• Conditional support, as I haven't seen it in action. My provision is that "What links here" shows the complete redirect route through all redirects. — Edokter • Talk • 15:46, 10 March 2009 (UTC)

  Check. You'd be seeing it in action here if not for the scarily-efficient dbr bots :D Happy‑melon 16:36, 10 March 2009 (UTC)

  It does. This is how the bots detect them, actually (they don't search all articles), and how humans used to resolve double-redirects. Dcoetzee 19:58, 10 March 2009 (UTC)

• Support - two or three jumps. What happens with loops though? –xeno (talk) 18:39, 10 March 2009 (UTC)

  It keeps going for however many links are allowed, then drops you off wherever you happen to end up :D. So for a Foo→Bar→Foo loop, with $wgMaxRedirects = 2 you'd end up where you started (having gone once round the loop) and with $wgMaxRedirects = 3 you'd end up at the other page. Happy‑melon 18:43, 10 March 2009 (UTC)

• Conditional support. Regardless of how many redirects are in a chain, the software should be able to detect circular chains (that is, A redirects to B, which redirects to A) and not attempt to render them as anything else than invalid (or broken) redirects. -- Blanchardb -^{Me•MyEars•MyMouth}- timed 20:30, 10 March 2009 (UTC)
• Support but beware of Xyzzy→Foo→Bar→Foo, which goes round in circles without actually ending up where you started. Certes (talk) 00:50, 11 March 2009 (UTC)
• Hold on. This sounds nice in theory but there are some practical problems that need to be worked out before it is implemented. First, reading through the comments above, I don't see any consensus on what specific value of $wgMaxRedirects should be used. One user wants 3, but most haven't commented on this. Second, there is no consensus at all about how to fix a redirect chain that goes over the allowed length. Third, the Mediawiki software doesn't yet provide a report of excessively-long redirect chains; even if $wgMaxRedirects is 2, Special:DoubleRedirects will list all the valid redirect chains of that length, and the ones that are really broken will be very difficult to find. Bug 17934. I'd say wait until that is fixed before proceeding. --R'n'B (call me Russ) 13:00, 11 March 2009 (UTC)
• Oppose for now per R'n'B and until we can come up with a policy to prevent overuse of this feature. Powers ^T 13:04, 11 March 2009 (UTC)

  Why would we need a policy to prevent overuse, and what is overuse in the first place? If a redirect isn't useful it can be retargeted or RfDed, as before. I really don't see any need for policy or guideline on multiple redirects. --Amalthea 13:14, 11 March 2009 (UTC)

• Oppose for now. We need a mechanism to avoid infinite loops (such as A => B and B => A or, even worse, A => B, B => C, C => D, D => B). Admiral Norton ^(talk) 15:22, 11 March 2009 (UTC)

  Infinite loops are not a problem for MediaWiki, they will simply appear to the user as any redirect chain does that is too long, and can be handled the same as those. --Amalthea 15:56, 11 March 2009 (UTC)

  See A → B → C → B: Since the current setup allows double redirects, visiting A drops you off at C, which shows the redirect chain from there: B → C. --Amalthea 16:00, 11 March 2009 (UTC)

  Right, this isn't about infinite loops, it's about the number of steps the software takes before leaving the reader at a page. It used to be that if A links to B (a redirect) which links to C (a redirect to D), the reader ends at C; now (for the moment) the reader will end at D (even if it's redirect). -- John Broughton (♫♫) 20:03, 11 March 2009 (UTC)

• Support leaving the value as is. The only two opposes to date are unclear/incorrect, and the "hold on" is about whether we want to expand the number beyond what we have now (for the moment). We can address the latter after we deal with the more pressing matter of whether things stay as they were or whether redirects go back to only a single one functioning in a chain. -- John Broughton (♫♫) 20:03, 11 March 2009 (UTC)

  John, please clarify what you are supporting. The "value as is" is 1, which means no double-redirects are allowed. The only reason some double-redirects have been working the last few weeks is due to a software bug. And, if you construed my "hold on" comment as relating only to an increase from 2 to 3, you were mistaken—an increase from 1 to 2 would cause problems if there is no tool available to identify invalid triple-redirects. --R'n'B (call me Russ) 12:53, 12 March 2009 (UTC)

  The question posed by the OP is essentially "should we make double redirects work permanently?", which boils down to "should $wgMaxRedirects be set to 2 before or during the next scap?"; I assume this is the proposal John is supporting. Happy‑melon

• Support-- penubag  (talk) 00:15, 12 March 2009 (UTC)
• Support (And on a slightly related note, one should be allowed to created redirects to non-existent targets in cases of commonplace misspellings, misnomers, etc. This was once allowed and the present policy got there not by proper discussion but by bullying, four years ago. Now it is enforced by very efficient bots.) Michael Hardy (talk) 22:09, 13 March 2009 (UTC)
• Support - for sure. Seems very sensible and eliminates a great deal of manual work. —Anonymous Dissident^Talk 07:26, 14 March 2009 (UTC)