# Wikipedia:Village pump (proposals)/Archive 44

## Sinebot screws up rollbacks

I don't have much of a solution, but I thought I'd start a brainstorm. Maybe the rollback function could be changed, just for Wikipedia, to include Sinebot's edit with the previous edit. No one's ever gonna need to rollback the Sinebot edit alone. Equazcion /C 18:51, 18 Feb 2009 (UTC)

What about when sinebot signs and its not supposed to? –xeno (talk) 18:54, 18 February 2009 (UTC)
Rollback is supposed to be for vandalism/nonsense only as far as I'm aware. If someone needs to undo a Sinebot edit alone they would just use "Undo". Equazcion /C 18:59, 18 Feb 2009 (UTC)
Nah, using rollback on a bot's erroneous edit is perfectly appropriate. An example of Sinebot signing when it isn't supposed to: optional RFA questions. WP:POPUPS can be used to rv past sinebot fairly easily. –xeno (talk) 19:04, 18 February 2009 (UTC)
Then maybe there's some other solution. My understanding is that many if not most people either use the mediawiki rollback function or twinkle's. Equazcion /C 19:21, 18 Feb 2009 (UTC)
How about an extra tab on Twinkle that says "ignore Sinebot" or something? --DFS454 (talk) 19:29, 18 February 2009 (UTC)
(de indent)Twinkle, as far as I know, already does ignore SineBot. It's not part of rollback proper, though, but in theory you could probably design a patch to allow a config directive to rollback over specific users to the next available one (e.g., bots that datestamp tags, sinebot, and probably others). Don't really know if it's needed, though, as not being able to use mw rollback in the overwhelming minority of instances is more just a minor annoyance than a serious feature requirement, and actually might help to better prevent rolling back to an also-vandalized revision, since it requires accessing the page history. --slakrtalk / 20:32, 18 February 2009 (UTC)
I personally think it's fine to have to exert slightly more effort to revert a talk page edit - they're not as important to revert quickly as article edits. Dcoetzee 20:42, 18 February 2009 (UTC)
It should be mentioned that the vast majority of rollbacks are done using anti-vandalism tools such as Huggle or Twinkle. Those will revert a SineBot edit that follows any edit marked as vandalism. Also, we should keep in mind that rollback is no big deal, really: it merely automates a task that even an anonymous user can do manually. -- Blanchardb -- timed 00:51, 20 February 2009 (UTC)

Hi all,

Thehelpfulbot now has a request, using pywikipedia's Python script nowcommons.py to delete local images that are also on Commons. You can have a look at the code if you wish, by seeing the pywikipedia library here.

If you wish to comment, please do so at Wikipedia:Bots/Requests for approval/Thehelpfulbot 6.

Thanks,

The Helpful One 20:46, 19 February 2009 (UTC)

Note: This task has now been withdrawn. The Helpful One 22:11, 19 February 2009 (UTC)

## Create page in userspace

A suggestion was made on the Help Desk talk page [1] that Wikipedia create a method for a link that asks new users what they want to name the page and then asks what text will go there, and then starts the page.Vchimpanzee · talk · contributions · 22:32, 18 February 2009 (UTC)

Something like the Wikipedia:Article wizard? Perhaps with the option to create the article in userspace? --—— Gadget850 (Ed) talk - 20:25, 20 February 2009 (UTC)

## Revisiting the "flagged revisions" question

I just wanted to revist the flagged revisions issue. How does this sound? Allow free editing of articles as at present,but lock the Quality Ratings pages, so only experts can rate articles. I appreciate there are both pros and cons, but I shall be interested to hear feedback from others before going on, ACEOREVIVED (talk) 20:18, 20 February 2009 (UTC)

No offense, but you don't seem to really understand what flagged revisions are; they're not a form of protection. See Wikipedia:Flagged_revisions#Community_proposals for some of the details. I oppose your proposal primarily on the grounds that identifying and verifying experts is infeasible. Dcoetzee 20:27, 20 February 2009 (UTC)

Thank you for your information, and for being very courteous - I find that, in all my years of working on Wikipedia, I constantly have new information to learn. Thank you - I shall know where to look for the "flagged revisions" debate now. ACEOREVIVED (talk) 22:16, 20 February 2009 (UTC)

## Blocking policy

I may not be doing this entirely correctly, but I propose that the terminology of the blocking policy be changed. Currently, the blocking policy states that blocks are not meant as punishment. However, as an elaboration upon that point, the blocking policy states that blocks are intended to deter future disruption.

I have a problem with this. Blocks are punitive, no matter what the policy says. Two things make it quite clear blocks are punitive. First, the policy says they are meant to deter. There are several rationales used by scholars to explain punishment, but I would submit that nearly every scholar educated in penological theory would agree that the two historical justifications for punishment (besides divine revelation) are retribution and deterrence. Like it or not, by conceding that blocks are meant to deter, the policy is contradicting its claim that blocks are not punishment. That’s my substantive problem with claiming blocks are not punishment. My second argument is procedural. The actual administration of blocks is done so in a punitive fashion. Repeat offenders are given longer blocks. More egregious offenders are given longer blocks. That’s a punitive system.

I suggest that the blocking policy be reworded to say that blocks are not for retribution, because they are certainly for deterrence. Those are the two classic justifications for punishment. Blocks deter; that means they punish. However, they aren’t necessarily retributive. This also has some other consequences. I also think that blocked users should be allowed to use “retribution” as a defense against their blocks. If the length of the block or the disposition of the blocking administrator indicate retribution, the block should be shortened or lifted. Hopefully, if applied correctly, this wouldn’t result in more blocks being lifted. Rather, it would result in more blocks being above controversy because removing any hint of retribution would increase transparency on Wikipedia. Chicken Wing (talk) 00:25, 20 January 2009 (UTC)

Unfortunately, you will never get people to admit that blocks are punitive, even though they frequently are. Same as how people insist that votes on adminship requests are not votes, and that there's no such thing as a cool down block, and so on -- Gurch (talk) 17:36, 20 January 2009 (UTC)
Most kind of blocks are punitive. And the fact they get extended is proof they are punishments. And almost every kind of block is a cool down block. Majorly talk 18:01, 20 January 2009 (UTC)
I know you know that, but try saying that when asked about it in an adminship request -- Gurch (talk) 19:07, 20 January 2009 (UTC)
I'm just trying to make Wikipedia more transparent. I don't think people should fail adminship requests because they stumbled on a trick question, especially when the "correct" answer has no basis in reality. Nor do I think Wikipedia should give its critics a foothold by dogmatically holding to patently incorrect policies. In my experiences editing Wikipedia, it would appear to me that the legitimate criticism of Wikipedia comes from people who are on the wrong end of policy text and policy implementation being at odds with each other. Besides, I don't see any serious harm that could come by changing the policy to say "retribution" instead of "punishment".
And, let me say thanks for the input to everyone who has commented on this. I appreciate it. Chicken Wing (talk) 20:54, 20 January 2009 (UTC)

I mostly agree with this change. Blocks serve essentially three distinct purposes: a preventative measure, to prevent the user from doing further damage, a deterrent measure, to discourage them from taking the same action again once their block is over, and a discouragement to others, who may avoid destructive behavior out of fear of blocking. The analogy with real-life justice systems is clear: we lock criminals in jail so that they cannot commit further crimes, so that they will be discouraged from committing them again after release, and to deter others from committing crimes. However, just as a criminal can get out of jail early if they've shown signs of effective rehabilitation, so may a blocked user; we are only concerned that they do not repeat their disruptive behavior, not that some arbitrary standard justice is meted out. It is in this sense that one can say that blocking isn't punitive (in addition to it not being about retaliation). Dcoetzee 22:57, 20 January 2009 (UTC)

Does someone want to link to the text in question? I agree with OP. This sounds like a simple case of poor use of english which should therefore be corrected - the word 'punishment' has been misused - if blocking is intended to deter future transgressions, then it is punitive, punishment, whatever, according to any half-decent dictionary. Even Punishment includes: "Possible reasons for punishment ... Deterrence / Prevention: to act as a measure of prevention to those who are contemplating criminal activity." Jaymax (talk) 22:17, 25 January 2009 (UTC)
This is the Wikipedia block policy. The first paragraph of the policy says in part, "Blocks are used to prevent damage or disruption to Wikipedia, not to punish users. Blocks sometimes are used as a deterrent, to discourage whatever behavior led to the block and encourage a productive editing environment." It may seem like I'm being trivial in trying to get this fixed, but I'm not. This contradictory policy has been repeatedly use to browbeat unsuspecting candidates for adminship. Chicken Wing (talk) 00:08, 26 January 2009 (UTC)
Further agree - the wording does not make any sense using a correct definition of 'punish'. Entirely valid reasons justifying the punishment (incapacitation, deterrence) notwithstanding. Also agree (best guess) the intent seems to be to say that blocks are not reprisal/retaliation against users for breaking rules Jaymax (talk) 00:37, 26 January 2009 (UTC)
This seems to be based on the premise that since people may use punishment as a means of deterrence or prevention, then deterrence or prevention is punishment. However, observing that "A is used for B" does not imply that "B is a form of A". Deterrence is owning a nuclear submarine fleet. Punishment is launching the missiles after being attacked. SHEFFIELDSTEELTALK 16:19, 27 January 2009 (UTC)
But we do launch the missiles. Threats of blocking only get so far. Mr.Z-man 17:47, 27 January 2009 (UTC)
I don't agree with the assessment by SheffieldSteel. To punish is "to subject to pain, loss, confinement, death, etc., as a penalty for some offense, transgression, or fault." A block subjects a user to the loss of editing privileges. A block subjects a user to the confinement of exercising speech in a manner other than through editing Wikipedia. A block is the penalty for an offense, violating a rule of Wikipedia in such a fashion as to warrant a block. A block is punishment. The goal of the block is deterrence, a legitimate goal of punishment. Your nuclear analogy falls apart because the equivalent analogy would be warning a contentious editor that you own the ability to block. Blocking is the actual use of a nuclear weapon. Through the correct use of your own reasoning, not only is a block a form of punishment, it's analogous to punishment of the nuclear variety. Frightening. Chicken Wing (talk) 20:51, 27 January 2009 (UTC)

I find this discussion interesting because I am currently reading The Roots of Evil ISBN 0313201986 which is a history of crime and punishment. The most salient point is that cruel punishments create cruelty in the people. When I was in high school it was explained to me that technologically we live in the space age, but sociologically we are still in the stone age. However, WP is hopefully on the cutting edge of wherever we are. Apteva (talk) 18:28, 31 January 2009 (UTC)

### Blocking policy break 1

Ok, then let's focus on our current topic. Is there any opposition to admitting blocking is punishment? Spotfixer (talk) 16:47, 8 February 2009 (UTC)

In response to your opposition below, equazcion, is there some other alternative phrasing that you would support? As it stands, the statement that blocks are not punitive is simply false. I understand your concern that admitting they're punitive might be seen as a license to use blocks to punish, though I'm not sure that any such license is needed at this point. However, perhaps there's some other way of saying it. Any ideas? Spotfixer (talk) 04:22, 9 February 2009 (UTC)
I don't think there is any wording that would impart the honesty you seek while also still offering the same level of discouragement. Frankly I think this proposal is really just a product of people who'd like retribution to correct the injustice of bad blocks and, in the end, make a point, call attention to the issue. I feel the same frustration, I admit, however I think this is not the right way to go about it, and won't help the situation.Equazcion /C 04:28, 9 Feb 2009 (UTC)
I think that the responses below are interesting in that they show the level of self-deception involved. Utterly refusing to admit that punishment is punishment turns out to be about as harmful as claiming voting isn't voting. Why is Wikipedia policy mired in obvious lies? Spotfixer (talk) 12:40, 10 February 2009 (UTC)
As I said (and others have said) in our votes, the distinction is in the interest of keeping admins aware of what they're supposed to be doing. The belief that they aren't doing what they're supposed to be doing some or most of the time is no reason to abandon all hope and finally just tell them to do it the wrong way. I don't see that doing much good for the community. Equazcion /C 15:16, 10 Feb 2009 (UTC)
• Support. For the record, I support my own proposal that Wikipedia's block policy concede that blocks are intended to punish. However, blocks are not meant to be retributive. Chicken Wing (talk) 03:57, 9 February 2009 (UTC)
• Oppose... after giving it some thought. I think the stress on blocks not being punitive is meant mainly as a reminder to admins, to not submit to the temptation of blocking someone cause they "did something wrong" and/or "deserve it", for example. Call them punishments and you give license to admins to use them in precisely that manner, and that would be bad. Present blocks may sometimes or often function that way anyway, but replace the statement against it with one that expressly condones it, and I think the problem would get much worse. Equazcion /C 04:07, 9 Feb 2009 (UTC)
Comment. That's why the policy would continue to say that blocks are not for "retribution". Punishment usually encompasses both deterrence and retribution (that is to say, either deterrence or retribution or both can be cited as an aim of punishment). Users blocked for retributive reasons would have a good case, and we would avoid the bizarre arguments on WP:RFA and other places about whether or not blocks are intended to be punishment. Chicken Wing (talk) 10:24, 9 February 2009 (UTC)
What's the difference between punishment and retribution? They both come after the fact and are both a form of balancing out a misdeed. The only difference is that with retribution we're admitting that the point is to make us feel better. Punishment, retribution, different ways of slicing the same turkey. Telling admins they're responsible for handing out "punishments, but not retribution", is a laughable statement to me. It's tantamount to saying "you're responsible for punishing people for doing bad things but you're not supposed to like it." Equazcion /C 16:36, 9 Feb 2009 (UTC)
Response. The distinction may seem laughable to you, but that just reflects an unfamiliarity with penological theories. This has been discussed above. The two classical goals of punishment are retribution and deterrence. Retribution is a possible goal of punishment, but punishment and retribution are not synonymous. As the discussion of penological theory becomes more complex, scholars also define incapacitation, denunciation, and rehabilitation. Some also accept restoration as an aim of punishment. Deterrence can be broken down into general and specific -- the conversation goes on. The academic field is well-established though, so calling the distinctions laughable probably isn't a good decision. Chicken Wing (talk) 22:25, 9 February 2009 (UTC)
Okay, then call it deterrence. If punishment is twofold, then let's just choose the fold that means what we want to say, and can only be taken one way. Why use an ambiguous term that could mean something we want to say, or could mean something we definitely do not want to say? PS. My "unfamiliarity with penological theories" is, I'll go out on a limb in guessing, not likely to be a rare occurrence in the general public. Pedantic objections to policy wording are not very useful. Policies need to be worded so that even people without degrees in "penology" will understand them. PPS. I read your explanation above, and my opposition is not based on a belief that your point is technically incorrect. On the contrary you may have a good point -- but only technically. And technical linguistic correctness is not the top priority. Equazcion /C 01:33, 10 Feb 2009 (UTC)
There's actually a utilitarian reason for changing the policy to call blocks punishment, and that reason is also discussed above. A lot of candidates to become administrators have been burned for calling blocks punishment. They were correct in practice, but not according to the paradoxical wording of the policy. Thus, Wikipedia's version of textualists crucify those would-be administrators for their mistake. The other utilitarian reason is that since blocks are, in fact, punishment, there is no sense in not calling them what they are. Chicken Wing (talk) 02:44, 10 February 2009 (UTC)
Well, the sense in it is something I've already described. As for candidates getting it for calling blocks punishments, I think that's more because it shows how they view blocks, rather than for a linguistic error. Equazcion /C 05:08, 10 Feb 2009 (UTC)
• It's not a punishment, it's a block. Doors closed not hands missing. It is the difference between punitive charges and exclusion. Read a book girls please. If (quote) technical linguistic correctness is not your purpose for altering a documents words without changing its effect, what are you talking about again? Differ between locked in and kicked out. Countries do not appoint their Offence Forces. Why? Because they intend to defend and be absolved of their actions. You block for a short period to see if that was enough to protect the site. If not, you block further until unlimately the site is safe. You try your damnest not to enter the psycology of Vandal A unless it is unclear wether he be a vandal or not. If you need to slap your kids they are either bored or overplayed with by a parent who is also bored and overplayed with and yet, take a kid outside for a walk or to kick a ball, it relaxes, it sleeps, aaahh, heaven awaits and I never even thought of it. Think of that when you punish or exclude the five year old and you wont be saying, "All parents slap their kids" to the fifteen year old. ~ R.T.G 11:46, 27 February 2009 (UTC)

### Blocking policy break 2

• Support. It seems clear that blocks are intended to be, and are in fact, punitive. Maybe they shouldn't be, but let's start by stating the truth. Spotfixer (talk) 04:22, 9 February 2009 (UTC)
• Oppose - Truth is in the eye of the beholder. So far people who have gotten blocked multiple times have spoken on this issue, and of course, since they feel they've been wronged, they're obviously going to have a certain POV in regards to the subject matter. But to the point, although they may feel wronged by certain admins, that doesn't automattically make all blocks punitive. Take for example getting blocked for personal attacks. In this case, the block is preventive, as the user in question has not shown that he will stop insulting other editors, an action which creates a poisonous editing atmosphere on the article talk page in question, and in turn, makes it difficult to edit without getting in some argument. Quite simply, it tests the patience of the editors who aren't making the personal attacks, rather then working constructively on the article in question. Wikipedia isn't about poking and prodding other until their limits are made apparent, it's about building an encyclopedia, and in order to do that, we need to prevent such things from happening.
Let's try blocks for POV editing. The user in question is incerting obvious POV, lets say, holocaust denial POV, into an article about the holocaust, writing that it doesn't exist, never happened, etc, and doing this all without a single source. Already, this breaks two policies: WP:V and WP:NPOV. While keeping with WP:AGF, others will warn this editor, and, gradually assume bad faith, as he just either removes the warnings without a response, and keeps doing what he was doing before, or the latter without removing or responding to the warnings. Either way, the editor in question shows that he will not stop editing against the current consensus at the article, and even stop to talk about his edits(let us also remember that truth is in the eye of the beholder). This editor, basically edit warring now, would be blocked to prevent further biased, unsourced statements from being inserted into the article. This block was put in place to prevent, such edits from happening again from this particular user, especially if this user was doing said edits on multiple articles which are in regards to his POV.
The same could be said for IP users, or schools, for that matter, inserting statements, which are unsourced, and heavily biased, regarding homosexuals on various articles regarding california's proposition 8. Need I really go on? I could continue for at least a few more paragraphs.— dαlus Contribs 23:30, 9 February 2009 (UTC)
The blocked editor in your first paragraph was blocked for "preventive" reasons. Prevention and deterrence are the same thing. Specific, reactionary deterrence is a form of punishment. A block is specific to the offender, and a reaction to the offense. It prevents, therefore, it deters. It's punishment.
I'm sure you could continue for several more paragraphs, but given that prevention is a form of punishment, as discussed above, it's still bad analysis. Oppose if you must, but nothing has been said here that changes the fact that blocks are for deterrence, and thus, punishment. What blocks are [i]not[/] supposed to be for is retribution.
PS: I'm also not going to accept that truth is in the eye of the beholder. That is only one of many philosophies concerning what truth is. It doesn't really serve our purposes here to create such a tangential argument. Chicken Wing (talk) 02:54, 10 February 2009 (UTC)
What you mean is, nothing I've said will change your point of view about what blocks are, but, to continue on to what I was originally saying, you are wrong in your above analysis of my argument.
The above argument, could be both viewed in two respects. It could be viewed that blocks can be used as a deterrence, as they are supposed to deter an editor for taking a specific course of action, say, in regards to personal attacks. But not the second reason, in regards to the POV pushing. Such as when an editor shows that he or she will not abide by our policies, and shall continue to push his or her point of view; blocks in this case are preventive, as it is preventing the said user from pushing their point of view. It isn't deterring them, as they are righteous in what they are doing.
Of course, it could then also be applied to the first argument, in that we are preventing the user who has been rude to others from further being rude to others. Blocks are in fact, preventive. The only deterrent that exists on wikipedia is our warnings, warning users that they will be blocked to prevent further damage to the editing atmosphere, and by the way, nine editors is hardly consensus on what blocks are or are not.
In fact, since this discussion is taking place about a policy here on wikipedia, and admins are going to be following this policy, I do believe that the Village Pump is completely the wrong place for this. I'm going to start a thread on ANI, referring to this thread.— dαlus Contribs 06:24, 10 February 2009 (UTC)

### Blocking policy break 3

• Oppose - I find the notion that blocks are not punishments but pragmatic methods to prevent disruptions to be useful. There are already to many cases then an admin could prevent a disruption by simply communicating with a user rather then by blocking but preferred to abuse the block button. There is no need to encourage this Alex Bakharev (talk) 06:53, 10 February 2009 (UTC)
• Oppose. No compelling arguments have been presented for this very serious change in the longstanding policy and tradition of Wikipedia. Ruslik (talk) 07:48, 10 February 2009 (UTC)
• Oppose - I think Equazcion hit the nail on the head: although the distinction between "preventitive" and "punitive" is highly artificial (and sometimes difficult to delineate precisely), the current policy serves to deter the use of blocks for retribution or to easily deal with a prickly editor. The requirement that a block be "preventitive" helps focus the admin's attention on what the future actions of the editor are likely to be, rather than on past bad acts. Futhermore, I'm entirely uncertain the "peneological theories" have any particular relevance in this circumstance. Ed Fitzgerald t / c 08:10, 10 February 2009 (UTC)
• Oppose per Ruslik. Ncmvocalist (talk) 09:32, 10 February 2009 (UTC)
• Oppose - The large majority of blocks I've seen have had one primary purpose, and that is to curb damage to wikipedia content. To compare being blocked to being sent to jail is absurd. You don't go to jail when you're blocked, you simply can't edit for awhile. There is no constitutional right to edit wikipedia, and the only "punishment" is possibly hurt feelings and being compelled to do something else with one's time for the length of the block. The purpose of wikipedia is to build a website that the general public can rely on as a source for information, not to stroke the egos of its contributors. Truly punitive blocks, made in anger or in conflict of interest, frequently get overturned. And the fact that block logs draw scrutiny is totally reasonable. Disruptive editors voluntarily make the choice of continuing to be disruptive, or of improving their behavior and putting distance between themselves and their block history. Baseball Bugs What's up, Doc? 10:14, 10 February 2009 (UTC)
• Oppose: I had something here to input, but I believe Baseball Bugs stole my words and phrases. seicer | talk | contribs 12:35, 10 February 2009 (UTC)
Response -
I realize this is probably going to fail at this point, but I thought I would address a few misconceptions that I'm seeing. I don't mind that the proposal will fail -- I've proposed other failed things in the past. I am concerned by the poor arguments though. They seem to show a misunderstanding of the proposal.
Baseball Bugs wrote, "To compare being blocked to being sent to jail is absurd." I find this comment to be unpersuasive for two reasons. The first is that I have not compared blocks to being in jail. The second is that the argument appears to assume that all punishment is equivalent to being jailed. In fact, many punishments exist in parenting, criminal justice, and dispute resolution that are not jail. A jail comparison would probably be most appropriate if we were discussing the penological goal of incapacitation, but that is not being discussed here.
Next, with respect to Alex Bakharev’s comment, I agree with the objective but not the interpretation of this proposal. I agree with the objective of not giving administrators’ more rope to make retaliatory blocks. However, this policy proposal, when changing the policy to say “punishment”, would also explain that blocks are not to be for retribution. I’ve read through some unblock requests. I’ve found the vast majority of them to be unfounded, but a few have actually appeared to have some legitimacy. In that instance, those blocked editors should have a policy guideline to be able to point to, as I have also found that the unblock template appears to not be taken seriously, even when it’s not being abused.
Lastly, Daedalus969 makes a clarification of the term “preventive”, which mistakenly reinforces the idea that blocks are punishment. The way you have defined “preventive” is basically identical to “incapacitation”. Incapacitation is “to deprive of the legal power to act in a specified way or ways.” A block deprives one of the power to act in a specified way, for example, POV pushing or engaging in personal attacks. Incapacitation is yet another goal of punishment, more evidence that blocks should be considered as such. Your analysis of deterrence also doesn’t consider that deterrence is both specific and general. Even if we don’t agree that blocks serve the purpose of specific deterrence, but I would think they certainly have the effect of general deterrence as well. Chicken Wing (talk) 16:04, 10 February 2009 (UTC)
PS. The Wikipedia article on punishment actually has a subsection entitled "deterrence / prevention". I deemed the irony as relevant. Chicken Wing (talk) 16:26, 10 February 2009 (UTC)
Reply - Maybe in some cases, blocks could be seen as punishment, but citing things in regards to today reason for putting people in jail, or punishing them, is not always case in regards to wikipedia. So, you think that all blocks are punitive, instead of preventive. Tell me then, how is it punishment to block a user who has shown they don't care, nor will they ever care, about wikipedia policy. The users who are usually blocked indefiniately, it is done so to prevent damage to WP. Tell me, how is it that blocking the user User:DavidYork71, and his over 500 sockpuppets, punishment? He obviously doesn't care that he's violating policy, and he will do whatever it takes to get his POV into an article. This isn't punishment to block him and his socks, it's prevention to stop damage to the encyclopedia before it begins.— dαlus Contribs 21:50, 10 February 2009 (UTC)
Response. The first sentence of that response is incoherent. The second sentence is wrong, and the rest of the paragraph is built upon the erroneous premise of the second sentence. Chicken Wing (talk) 01:06, 11 February 2009 (UTC)
Reply I was cut for time, guess I didn't notice my mistakes, either way, in this case, you're wrong: Blocks are not punishment, they are preventive, as they are preventing damage to the encyclopedia from users who have shown they don't care about violation policy here. The user DavidYork71 is a massively abusive user here on wikipedia. He was banned by the community for flagrant POV pushing even after warnings and multiple blocks. He has over 200 sockpuppets, and is rumored to have over 300 more. He of course uses these sockpuppets to continue on from where his other accounts left off, pushing his point of view. Do tell me, how is it, that by blocking, and banning this user and his sockpuppets, we are punishing him? He obviously could care less. My point is thus: People who are blocked are always going to view it as punishment, but that view doesn't make it so. Blocks are meant to prevent damage. They are to prevent the disruptive user from being disruptive. Punishing users is not the way it is, punishment usually implies that the user, in some sense, might realize what they've done is bad, after having a block. Well, this is more in relation to other sites, where users are expected to read the rules, and if any of those rules are broken, there are no warnings, just a flat ban. On wikipedia, as I've said several times now, the warnings are the part of the process that are meant to be the deterrance. If the deterrance fails to work, then a block is in order to prevent further disruptions from the user.— dαlus Contribs 02:16, 11 February 2009 (UTC)
Response. This is quite puzzling. Prevention is a part of deterrence. Prevention can be classified as deterrence or incapacitation, but either way, it's punishment. As I mentioned before, even Wikipedia's own article on punishment has a subsection called "deterrence / prevention". A block is an administrative reaction to undesired behavior intended to prevent the continuation of the behavior by the offender. Not only is that punishment, it's textbook. It's not even ambiguous. I am confident that if a hundred sociology, criminology, or law professors were asked to study the nature of blocks on Wikipedia, that more than ninety of them would conclude that they are punishment. The definition of punishment being used on Wikipedia is idiosyncratic to put it nicely, and wrong to put it more forwardly. Chicken Wing (talk) 02:36, 11 February 2009 (UTC)
Note/Reply - Please answer the question I stated above concerning the massively abusive user, DY71.— dαlus Contribs 03:15, 11 February 2009 (UTC)
Okay, that's just out of line asking if I'm evading on purpose. When you wrote an incoherent sentence, I didn't ask, "Are you pretending to be stupid on purpose?" When you wrongly said that I think all blocks are punitive instead of preventive, I didn't ask, "Are you lying on purpose?"
As for substantive matters, you've already answered your own question. The blocking of that user was to prevent further damage to Wikipedia. Prevention is a goal of punishment. As I previously stated, a block is an administrative reaction to undesired behavior intended to prevent the continuation of the behavior by the offender. David York behaved undesirably. David York was blocked. The block was to prevent his continuation of the undesired behavior. That's textbook incapacitation, deterrence, and prevention. It's punishment. All the things you have said only further the reality that blocks are punishment.
Everything you're saying (other than the specific denials that blocks are punishment) is basically the utilitarian view of punishment. I'll even put it like this. There is a WikiProject on law, and I think there is probably one on crime and maybe one on sociology, also. People can probably be found in one of those projects that actually has an education in these matters. Ask them about what I'm saying. Or do a Google search. Read about theories of punishment. Read about deterrence. This is the basic, low-level, first chapter of the book analysis on punishment. It's not even the hard stuff. Read the Wikipedia articles entitled punishment and incapacitation (penology). Even those articles, which aren't even very well written, back up what I'm saying. Chicken Wing (talk) 04:12, 11 February 2009 (UTC)
When you wrongly said that I think all blocks are punitive instead of preventive, I didn't ask, "Are you lying on purpose?" Lying? You obviously do think that all blocks are punitive instead of preventive. That's what you've been arguing this entire time. In regards to my edit summery, what then, were you avoiding my question? Yes, I see that you answered it, above, but you did not answer it before, especially when you made it apparent you were taking the time to read through my posts. Or is that a fallacy? To the case of DY71, the lead of punishment states that such a thing would be abhorant(this computer doesn't have spellcheck) to this user, an unfavorable end result. In the case of DY71, he obviously doesn't think much of blocks. He views them as a stone in his path that he can easily step over. Blocks are preventive in this case, not punitive.— dαlus Contribs 04:48, 11 February 2009 (UTC)
I'm done with this conversation. I don't think I can phrase a response to your latest reply in such a way that it wouldn't be construed as a personal attack, so I'm just done. The proposal is going to fail, so there is no reason to risk a policy violation by going on with this. Chicken Wing (talk) 06:25, 11 February 2009 (UTC)
What? You accused me of lying for stating fact. You believe, under what you have learned, that blocks are punitive instead of preventive. How am I lying? I believe otherwise, we obviously aren't going to change each other's point of view. Sure, the proposal is going to fail, but that is no reason to hint that you're going to make a policy violation. What, you can't form something that isn't a personal attack? At least take back your accusation of me lying, strike it through, because we both know what you will hold steadfast that you are right, that what you believe is true, but as I said above in my oppose, truth is in the eye of the beholder. My point is is that you can't argue something to be true, unless it is at least strictly logically, or mathematically true, eg, ${\displaystyle 1.{\bar {0}}+1.{\bar {0}}=2.{\bar {0}}}$, of course assuming that it is exactly, precisely, 1, versus cases where 1+1 could equal 3. But all that aside, I'm sure you should be able to come up with a response, in regards to at least DY71, and how we are punishing him, without being incivil, or personally attacking me. I've managed to do it, you should be able to too.— dαlus Contribs 07:43, 11 February 2009 (UTC)
I acknowledge that I have read this, but I still decline to substantively further the conversation. Chicken Wing (talk) 08:12, 11 February 2009 (UTC)
• Comment This discussion has spun somewhat off course (or so it reads to me) and appears to have some people fighting over Larger Issues - but what Chicken Wing was trying to get at is true - blocks are meant as deterrence, and deterrence is associated with punishment, and vice versa. The semantics are confusing, but the substance of Chicken Wing's point - that blocks should never be retributive, and that blocks are used in a way reminiscent of judicial punishment in MeatSpace, is true. Chicken wing, this proposal looks like its going to fail, but I encourage you to write an essay on the line between deterrence and retribution - sounds like you have something valuable to say.--Tznkai (talk) 16:12, 10 February 2009 (UTC)
• Agree - Tznkai's comment here makes a lot of sense. Trying to reword the policy to be less ambiguous on that point is going to be much more controversial than writing a clarifying essay explaining the point. Assuming the essay ends up generally agreed to, it can even be linked to from the policy without much issue. Gradualism this way wins... Georgewilliamherbert (talk) 00:12, 11 February 2009 (UTC)
• I have long believed that the claim that blocks are not punishment was no more than a fiction we liked to tell ourselves. They are punishment. But they are punishment for the sake of deterrence and prevention, not punishment for the sake of retribution, and that is a meaningful difference. They are meant to say that the triggering conduct is really and truly unacceptable. Unfortunately, focusing on deterrance also opens the door to telishment, which is a door that I believe we should keep firmly shut. The gradual approach Tznkai suggested makes sense for how to move the documented policy to the reality of what we are already doing. GRBerry 00:32, 11 February 2009 (UTC)
• Partially agree. In many cases blocking is clearly intended as punishment, though we rationalise it as preventing further disruption. It's sometimes very hard to specify the difference, because obviously someone who has been disruptive is somewhat likely to do so again. But most of the time we do not know that, and are motivated in good part by how obnoxious the behavior is. To quote from WP:3RR "Administrators tend to issue longer blocks for repeated or aggravated violations, and will consider other factors, such as civility when doing so. " That's punishment. More generally, people say "You've earned a block" That's punishment. Or, "this conduct deserves a block"--that's punishment. I d If we really meant preventing disruption, we'd block long before the 3rd RR, & the technicality of 24hrs wouldn't matter. (and similarly for other reasons.) Any look at AN/I will show blocks as retribution. I don't see how we can avoid that--humans, not being saints, behave that way, and we would do better to admit our motivations. DGG (talk) 02:52, 11 February 2009 (UTC)
• I agree with just about everything say, especially since you've taken the time to explain it and give examples. However, I would still like to see what you would say, in regards to preventing disruption, in regards to the DY71 socks.— dαlus Contribs 06:27, 11 February 2009 (UTC)

One of the purposes of punishment is deterrence of repeated offenders or other offenders. There are many true block as prevention--to interrupt an edit war. But the 3RR policy as applied is clearly blocking as punishment. If we really meant to prevent we'd do it a good deal earlier; doing it even though the immediate warring has stopped is always punishment, and that's what usually happens/. Ro quote from that policy "

• Commment we have a long history of not speaking the truth, and blocking policy is probably one of the last places people want to start. This is going nowhere. - Peregrine Fisher (talk) (contribs) 07:55, 11 February 2009 (UTC)
• Comment No matter what you think about blocks of users, take a look at the IPs and new accounts getting blocked nonstop at AIV—that's almost all preventative (since most of them are IPs and accounts that are actively vandalizing at the moment they are blocked). rʨanaɢ (formerly Politizer)talk/contribs 15:24, 11 February 2009 (UTC)
• Response. You've made the same mistake several other editors here have made. Prevention and punishment are not mutually exclusive. Prevention is a goal of punishment. Even if you go to the Wikiedpia article on punishment, you will see listed a subsection called "deterrence / prevention". Punishment can generally be for deterrence/prevention or retribution. What the policy should say is that blocks are a punishment meant to deter/prevent certain behavior, however, they are not a punishment meant for retribution. I think that would be the better wording of what you're saying, which is what I agree with. Most blocks are not for retribution, and no block administered correctly is for retribution. Basically, Wikipedia had adopted the utilitarian philosophy of punishment, but its users just don't understand the terminology. Chicken Wing (talk) 18:48, 11 February 2009 (UTC)
• Oppose The ultimate goal of blocking is prevention of further harm to the encyclopedia. How blocked people interpret justly applied blocks is their problem. This proposal will lead to the insinuation that blocking is because of punishment, which was not the goal. —kurykh 19:15, 11 February 2009 (UTC)

Oppose as per Baseball Bugs, who explains things clearly and concisely. Edward321 (talk) 17:09, 15 February 2009 (UTC)

• Counter proposal I believe the source of disagreement here is that, in the vernacular, "punishment" has an ambiguous meaning. Some people see it as more synonymous with "retribution", while others interpret it as either ethically neutral or closer to "suppressive action". Therefore, I propose to replace the word "punishment" (and "punish" and similar forms) with "retaliation", "retribution", and other synonyms. I sincerely believe that this was the intended meaning of the policy drafters. Those who opposed the original proposal should be satisfied with this, because it still affirms the purpose of blocking to be prevention and deterrence rather than retaliation. Those who supported the original proposal should also be satisfied because it eliminates the assertion that blocks are not punishment. Seems win-win to me. --Unconventional (talk) 02:54, 20 February 2009 (UTC)
• Counter proposal. I think this is essentially an issue of semantics. Just as WP:IAR does not explain its semantics in the policy itself (and any attempt to do so invites great argument), I think the appropriate course is to write an essay describing the precise semantics intended, giving an analogy with the real-world judicial system, giving examples of when and when not to block, and to drop a note on the talk page encouraging them to add a link to that essay. I'd call it something like Wikipedia:When to block or Wikipedia:The purpose of blocking. The only objections here are based around the idea that "making it easier to block people is bad," but that doesn't mean there isn't something that needs clarification here. Dcoetzee 19:57, 23 February 2009 (UTC)
• Oppose Arguements to construe the language of punishment v. exclusion to choose that which suits a purpose over that which suits a meaning: The punishment would have to be meted out on that which the punished owns. I have borderline appreciation for that ownership but stronger discontent for the admin to feel power over property they view as others. See Judge Dredd, the stories are great but if you knocked down four or five blocks leaving half a million homeless and replied, "I am the law", and your boss heard you... needless to say ~ R.T.G 12:10, 27 February 2009 (UTC)

## Perennial review of policies

Perhaps it would be a good idea to conduct an official review of at least the core content policies (i.e. NPOV, V, OR) every six months or so? To make sure that #1, everything is clear, as things can become garbled over time, and #2, that what is therein still reflects community consensus, with parts that didn't being changed or removed (possibly relocated to a guideline, information page, or essay.) I know some will say that this is what the policy talk pages are for, but there is the recurring question of how many editors it takes to form a policy consensus (or to override a historical consensus.) Such a review, however, could be widely advertised so as to attract anyone who cared. PSWG1920 (talk) 04:23, 11 February 2009 (UTC)

Uch, I don't like the sound of that, too bureaucratic. Any possible problems in policies can wait until someone encounters them and either changes them or complains, in my opinion. Equazcion /C 04:43, 11 Feb 2009 (UTC)
Again, that leaves the question of how many editors it takes to evoke a change. PSWG1920 (talk) 04:55, 11 February 2009 (UTC)
The thing is, if it's positive change, then it can be implemented at any time. But change for the sake of change is pointless and sometimes harmful. —kurykh 04:59, 11 February 2009 (UTC)
Who decides whether a change is positive? PSWG1920 (talk) 05:10, 11 February 2009 (UTC)
The community. Whether there is a policy review or not. —kurykh 06:05, 11 February 2009 (UTC)
(ec)I think that question would still rear its ugly head during the proposed reviews. Although the advertising aspect would be solved, I think that would also mean perennial headaches, because it would invite trivial policy complaints. I think it's better to deal with proposed policy changes as they come from editors. I could be wrong. Equazcion /C 05:01, 11 Feb 2009 (UTC)
I think in the context of an official review, if half of the respondents disagreed with a particular policy point, then it would clearly not have communal consensus and should be changed or removed. Whereas if those involved in a regular policy talk page discussion are split 50-50 on something, then the status quo will likely remain. PSWG1920 (talk) 05:10, 11 February 2009 (UTC)
There are already reviews of policies, they're just not "official" or scheduled. Anyone who thinks it's time to reevaluate a policy can invite the community to discuss it, such as the current RfC for the Notability guideline (here). These types of policy evaluations occur pretty often as it is, with no official scheduling, because editors take it upon themselves to do so -- and they often do reveal the community's consensus objection to certain long-standing aspects of policy. I just don't think scheduling them is necessary. It adds unnecessary bureaucracy. Equazcion /C 05:23, 11 Feb 2009 (UTC)
This proposal entails instruction creep. If anyone wants to make a comprehensive review of any given set of policies, they're free to waste spend their time reading through the applicable pages. Since changes will be made by consensus either way, there's little gained by a formal review system. {{Nihiltres|}} 05:19, 11 February 2009 (UTC)
And what constitutes "consensus" regarding policy changes? PSWG1920 (talk) 05:26, 11 February 2009 (UTC)
The age-old question of what constitutes consensus wouldn't be solved merely by scheduling policy reviews. It would just mean a lot more people would be involved in each debate, and probably also that there would be a lot more debates. Consensus would be determined the same way during those reviews as it is in any other situation. Equazcion /C 05:31, 11 Feb 2009 (UTC)
"It would just mean a lot more people would be involved in each debate". Exactly. Then it would be much more clear what had community consensus and what didn't. PSWG1920 (talk) 06:22, 11 February 2009 (UTC)
Yeah I had a feeling that was coming. My answer to that is, no, it really wouldn't. I'm not sure if you've ever been involved in one of those really massive debates, but larger does not equal easier consensus judgment. It's harder, if anything, and the final call gets disputed and argued about long after the decision gets made, cause of all the people that got pissed off. Equazcion /C 06:27, 11 Feb 2009 (UTC)
If in a truly community-wide discussion, consensus were not clear regarding a particular point of policy, that would be your answer right there—it should be removed or scaled down to something which had wide agreement (at least as far as NPOV, V, and OR are concerned.) Policies are supposed to reflect communal consensus. PSWG1920 (talk) 08:11, 11 February 2009 (UTC)
I do think it is really difficult to repeal policy that isn't being used, which is unfortunate - it's far easier to create new policy than destroy old policy. But I don't think periodic review would change that - what seems to be needed is a higher bar for a policy to satisfy in order for it to exist. Dcoetzee 03:03, 12 February 2009 (UTC)
The other options would be to demote NPOV, V, OR, and other "policies" which are not WP:3RR-exempt to guidelines (I touched on this at a different Village Pump but no one seemed interested) or to shift the burden for repealing policies. Currently the burden is squarely on one who wants to repeal a policy, and it really shouldn't be that way. If there is no consensus either way, that means the policy in question no longer has communal consensus, hence it should no longer be a policy. However, there is the nagging question of how you figure out what still has the broad consensus of the community. Editors who respond at a policy talk page may constitute a very biased sample. Hence my suggestion to schedule wholesale reviews. PSWG1920 (talk) 06:04, 12 February 2009 (UTC)
Every major challenge to of the major policies or guidelines typically take about half the Wikipedia time of dozens of editors for months. If the challenge to WP:N becomes a general discussion, this will be one. The WP:FICT proposal already had this effect. so has MOS Common names, and MOS Numbers. If we want to prevent experienced users from editing content at all, an effective way would be to review all the fundamental principles on a frequent basis. 03:18, 18 February 2009 (UTC)
Policy is constantly being reviewed and changed. I know from personal experience that policy can and is improved by the existing discussion and shifting of consensus. No need to formalize it. Chillum 03:21, 18 February 2009 (UTC)
Oh and PSWG1920 you should know NPOV, V, OR are at the center of what Wikipedia strives to be, it is not likely we would "demote" these policies. Chillum 03:22, 18 February 2009 (UTC)
Beauracracy, instruction creep, and unnessecary. If a user wants to hold an RFC for all policies, they gan go ahead and do that. If they want to do it anually, let em', no need for it to be official or anything.--Ipatrol (talk) 20:24, 22 February 2009 (UTC)

## Editnotice

--Pascal666 (talk) 06:25, 16 February 2009 (UTC)

Won't make anyone else read Perennial Proposals and will just lard up the top of the page some more. Tempshill (talk) 06:43, 16 February 2009 (UTC)
An Editnotice would not go at the top of this page, it would only be shown when someone hits edit, at which point it should be prominent enough to be noticed. There is already a link at the top of this page, but there is so much crap at the top of this page that it is consistently ignored. --Pascal666 (talk) 08:14, 16 February 2009 (UTC)
I support such an edit notice. עוד מישהו Od Mishehu 14:33, 16 February 2009 (UTC)
Endorse davidwr/(talk)/(contribs)/(e-mail) 15:58, 16 February 2009 (UTC)
Oppose. The current header (already cluttered) already has such a notice anyway. -- Blanchardb -- timed 20:10, 16 February 2009 (UTC)
What does the clutteredness of the header have to do with an editnotice? Algebraist 20:12, 16 February 2009 (UTC)
Oh, I thought it was on the page itself, not the edit window. Sorry, change to Support. -- Blanchardb -- timed 20:18, 16 February 2009 (UTC)
Support: Sure, why not? -- John Broughton (♫♫) 20:19, 16 February 2009 (UTC)
Support Maybe create new link for the editnotice, ie WP:VPR/Perennial that redirects to Wikipedia:Perennial proposals. So we can get a gauge of how many people use the link through the editnotice and if its useful to keep up. §hepTalk 07:17, 17 February 2009 (UTC)
Can you give an example of another redirect page that has been created solely for accounting purposes as you propose? --Pascal666 (talk) 09:09, 17 February 2009 (UTC)
If this is the first, so be it (see WP:BB). I think a better question is whether you have some reason to think that using a redirect this way is not a good idea, or if you can point to a discussion where the idea was proposed and rejected. -- John Broughton (♫♫) 14:16, 17 February 2009 (UTC)
Actually, they did it on the Main Page some time over the summer. (now we can use Grok to see if the editnotice is being used enough to keep up. §hepTalk 05:24, 19 February 2009 (UTC)
I created the editnotice. Ruslik (talk) 19:47, 17 February 2009 (UTC)
• The point of checking Perennial Proposals is to see what the common counter-arguments are, and only continue making the proposal if you have a new argument or approach. This message however makes it sound sort of like if something is in Perennial Proposals you aren't supposed to propose it again at all. I think the message should either be edited or removed altogether. Equazcion /C 18:51, 18 Feb 2009 (UTC)
• Well, I might suggest taking out the exclamation point, or better, replacing it with a question mark, but it does say "please review", nothing about "don't do it". It just falls into the category of there being no dumb questions, but that if it has been asked and answered twenty times before you might as well see how it was answered before, first. Apteva (talk) 19:55, 18 February 2009 (UTC)
• My gut reaction to this notice is "read the link and don't propose anything that appears there cause you'll just be annoying everyone". But that's just me. Of course it's easy to see the intended meaning when you know the intention beforehand. Otherwise I think this gives a bad implication. Furthermore I don't think it's such a terrible thing if dumb proposals appear on this page, and is certainly not a pressing problem that requires a solution. Equazcion /C 21:19, 18 Feb 2009 (UTC)
• That is why a question mark would work better than an exclamation mark. After all, it really is not intended to be a warning, just a suggestion. Apteva (talk) 03:17, 19 February 2009 (UTC)
• I believe the wording of the Editnotice is consistent with the wording about WP:PEREN at the top of this page. Since this page is not protected, you could start by rewording the header of this page and see if anyone objects. I must confess I have a tendency to overuse {{warning}}. Any changes to the Editnotice can be made at MediaWiki talk:Editnotice-4-Village pump (proposals) using {{editprotected}}. --Pascal666 10:43, 22 February 2009 (UTC)
• Oppose makes people stop reading editnotices. I already seldom do, because there is too much crap there. --Apoc2400 (talk) 15:20, 21 February 2009 (UTC)

## Flag protection, patrolled revisions and deferred revisions

The discussions on flagged revisions and trials have not been conclusive for now, but there does seem to be a support for some changes to improve our monitoring of blps and vandalism, provided they keep editing open. So I tried to evaluate the state of consensus and worked out three proposals for preliminary discussion, to see if we can go further for some of them, by starting a larger community discussion. The proposals are a variant of Flag protection, Patrolled revisions and Deferred revisions. Technically, flag protection and patrolled revisions are the most affordable, while deferred revisions would require substantial extension modifications. We could use a subpage of WP:CENT to host the discussions. Cenarium (talk) 03:12, 22 February 2009 (UTC)

## Template:Infobox Euroleague Player

Hi, I don't know if this is the correct place, if it's not, please tell me where can I ask for it. I would like to improve the Template:Infobox Euroleague Player by adding the chance to put the height in meters, and the weight in kg. I tried it, but I failed when I had to change the height and weight parameters to optional paramameters. I undid the changes in order to not affect all the articles which use this template, but you can check my attempt in the history page. Could somebody help me with it? Thank you. MinorKan (talk) 13:57, 21 February 2009 (UTC)

I'm told that the template gurus hang out at Wikipedia:Requested templates (it's for template modifications as well as new templates). -- John Broughton (♫♫) 22:10, 25 February 2009 (UTC)

## Transparent backgrounds in images

I browse the web with the browser set to white text on a black background. I find this easier on the eyes. However there is widespread use of images in Wikipedia (and elsewhere) which use transparent backgrounds or other similar devices and they can become unviewable if the image is mostly black on a transparent background as this now becomes black on a black background. The main wikipedia logo is an example, it is invisible on a black background. I've been meaning to post a message about this for some time, but a recent incident reminded me to pursue this. In the article Lloyds Banking Group I added an image a few weeks ago with a white background, and another user has just changed this to a transparent background which is unviewable on my browser. I reverted to an image with a white background.

I propose that all wikipedia images use the full colours that are intended and avoid the use of transparencies or any other devices that can be affected by browser settings, or Windows accessibility settings. Charvest (talk) 11:37, 22 February 2009 (UTC)

Without commenting on the merits of the proposal, I don't see this happening. It would be a huge amount of work to benefit a distinct minority of users. ╟─TreasuryTagcontribs─╢ 11:47, 22 February 2009 (UTC)
There may be client-side solutions to the problem. Something that springs to mind as a possibility is to use a custom master css file that sets the backgound of all images to white. Not ideal, but at least you'd be able to see the image. - Jarry1250 (t, c) 12:26, 22 February 2009 (UTC)
Thankyou for the comments and ideas. Note that this is more of a problem when viewing maps which use coloured backgrounds as indicators. e.g. the image at the top of Future enlargement of the European Union. The key to this map is invisible as it uses background colours as indicators rather than coloured images. Charvest (talk) 13:05, 22 February 2009 (UTC)
I don't believe that this can be considered a fault of Wikipedia. You have chosen to modify the appearance of web pages using style rules that override the default background colour for HTML elements. You then complain when the default colours are overridden? Do you want the cake or not? Happymelon 13:23, 22 February 2009 (UTC)
(edit conflict). I haven't modified the appearance of web pages, I have modified my browser settings. Web page authors should not assume they are in control of colour settings. Colours should not be used to indicate information. I didn't say it was anyone's fault, I'm simply pointing out what the situation is. I'm not making a complaint, I'm making a proposal. I believe web pages should separate content from presentation. That is the heart of HTML. The whole point of HTML is to allow the page to be viewable on any browser on any platform. Using transparent backgrounds is equivalent to removing information from images. Using background colours in the key to a map to indicate information is totally contrary to the ideals of HTML. Charvest (talk) 13:44, 22 February 2009 (UTC)
I see this has already been resolved, but I still feel I should comment; you have misinterpreted the concept of Separation of presentation and content. A white background around an image is a part of the presentation, white backgrounds are not a part of the content. Therefore, removing it from an image is the right way to go. Your browser should have incorporated additional functionality that restores the original CSS background color where needed. It's true that webpage author shouldn't assume they're in control of the page, but once you decide to take control, like by overriding the colors the author intended to use, it's your responsibility to make sure the page displays correctly. Having that kind of flexibility on webpages is what CSS and HTML are about. --Nezek (talk) 11:49, 25 February 2009 (UTC)
A custom style sheet seems the ideal for the image part. I rememeber I also once also took issue with how the colour keyo are presented but I can't remember what my problem was. I can't think of an easy solution to that (except maybe uploading 16.7 million 1 pixel PNGs and then just stretching them out for colour key use). Incidentally, do you do this by your web browser settings, or by editing the Wikipedia stylesheets. If you've overridden the stylesheets client-side, I don't think there's much can be done by us, save your proposal, which to be completely honest, I don't think has a chance of getting through - for the majority of users, transparent images are far more appealing than opaque ones. I'm going to revert the Lloyds Banking Group image for now since the general style is to use transparent where possible. You could try adding:
img {
background-color: #ffffff
}

into your stylesheet. I think that should add a white background to all transparent images (but I'm not 100% - can't remember for certain if "background-color" attribute works with images) - EstoyAquí(tce) 13:36, 22 February 2009 (UTC)
I just tested that code myself. It works on all article images. Some such as the Wikipedia logo in the top left corner don't because of how they're embedded into the page (I think there's probably a way to override that but I'd have to examine the HTML structure in more detail to know how). Just go to "my preferences" then the "Skin" tab. Then find the skin you're currently set to use and select "Custom CSS" and just paste the above code into that page and save it. Then you'll see all images with a transparent background as having white ones (after refreshing). - EstoyAquí(tce) 13:49, 22 February 2009 (UTC)
Ok, I've done that and refreshed, but nothing changes. The lloyds image is still invisible. Charvest (talk) 14:05, 22 February 2009 (UTC)
I've just realized why it's still invisible - because my browser settings put background colour as black and text as white - that's what my browser settings are - so that I can read web pages without eyestrain. My windows accesibility settings are also set to high contrast black and white so that all applications are white on black. Transparent backgrounds are simply not compatible with the idea of separating content and style. Thanks anyway. Charvest (talk) 14:15, 22 February 2009 (UTC)
If you still care, use:
img {
background-color: #ffffff !important
}

That should add the background to the logo and stuff, too.
Or you can enable a certain setting in your Wikipedia preferences which will set it to green on black and should fix the image problems. Dendodge TalkContribs 18:48, 22 February 2009 (UTC)
Well that was a rather sarcastic and unhelpful comment.
Take the image at the top of Demographics of Ukraine. The graph should have scales, but because of the transparent layer it just appears as a meaningless red line. Why does this image have a transparent layer anyway ? What is the point ? Transparent layers are just a gimmick which interfere with readability. Charvest (talk) 19:31, 22 February 2009 (UTC)

Charvest, it was not sarcastic. Go to Special:Preferences, click gadgets, and at the bottom of the User interface section, you will find the option referred to. Please don't jump to conclusions about other editors so quickly! ╟─TreasuryTagcontribs─╢ 20:10, 22 February 2009 (UTC)

Dendodge I offer you my sincerest apologies and many thanks. Treasury Tag, thankyou. Charvest (talk) 22:33, 22 February 2009 (UTC)

## Topical templates

I've just created (and tested) a new idea to allow cleanup templates to have a |topic= parameter which can be used to both A) display what topic the article is related to and, more importantly, B) Allow articles with cleanup issues to be categorized by their topic, rather than only by date or with all other articles related that have the same problem. The template can currently be located at User:Drilnoth/Sandbox 5, and another, more detailed description of my rationale for this proposal can be seen in this diff. I was wondering if I could get some community input on the idea and whether or not it should be used (or just implemented differently if it should be used). Before commenting here, please read the idea template's documentation for details on how it could work.

Thanks! -Drilnoth (talk) 00:09, 26 February 2009 (UTC)

## Wikipedia:Editor review

I'm not sure whether its correct to list this here, but due to a "great depression" of attention to WP:ER, there have been 3 proposals placed for discussion here.--TRUCO 02:15, 26 February 2009 (UTC)

## The True Furqan

Can you please start the article about The True Furqan.[2] Regards.--Abuk SABUK (talk) 21:37, 23 February 2009 (UTC)

Wrong place. You can create an article if registered. -Jeremy (v^_^v Dittobori) 21:41, 23 February 2009 (UTC)

I am not aware as to what "The True Furqan" is. It might be an idea if you think about which of the WikiProject groups (of which there are many) this would pertain to, and contact their members for guidance. Is this to do with literature, television or music? If so,that would help you to know who you should contact. ACEOREVIVED (talk) 21:51, 23 February 2009 (UTC)

• Its a printed book. On Sale on Amazon. Here is the internet site of the book.[3] Thank you. --Abuk SABUK (talk) 21:59, 23 February 2009 (UTC)
• I would like to start the article myself but English is not my first language and I am not very familiar with the codes on Wikipedia. Thank you.--Abuk SABUK (talk) 22:05, 23 February 2009 (UTC)
Please don't. It's self-published - [4]. [[User|Abuk SABUK}} did in fact write a stub saying what a wonderful book it was, it had a speedy tag and I deleted it. dougweller (talk) 22:30, 23 February 2009 (UTC)

Abu SABUK, you say that English is not your first language. Have you thought about contributing to the Wikipedia in Arabic? There are many different language editions of Wikipedia,and if you go to List of Wikipedias, you will be able to click on the hypertext link for the Arabic Wikipedia. Alternatively, you could go to Wikipedia: WikiProjects/ Council Directory to find other Wikipedians who might help. ACEOREVIVED (talk) 00:11, 25 February 2009 (UTC)

• I didn't write that stub. It clearly said editorial on the title. I copied the info from Amazon and I understand I shouldnt have. How can I write a book in English while it's not my mother language. Dougweller should be more positive towards new people here. That's a common problem in Wikipedia, old users own it too much and think they can be prejudiced or even insulting new, inexperienced or anonymous people here. That book is quite controversial and being given free in some Arabic countries to convert Muslim people. I still think it is important.--Abuk SABUK (talk) 18:56, 24 February 2009 (UTC)
This issue of not biting new users is widely recognized. Apteva (talk) 19:08, 24 February 2009 (UTC)
Sorry if I bit anyone, but he was the author of the article. I now know that it was a copy and paste job, which I didn't know at the time. I'm very happy to help Abuk Sabuk with the article as suggested on his talk page, although I may be limited by the language issue myself as I can't read Arabic (and I'll be around erratically for the next week and a half). It's been explained to him on his talk page the sort of sources he needs. dougweller (talk) 19:21, 24 February 2009 (UTC)

I wonder whether contacts with the WikiProject group for Islam might be called for here? Alternatively, you could do as Baileypalblue suggests (see above). ACEOREVIVED (talk) 22:31, 24 February 2009 (UTC)

Caution is warranted. This book is an Islamophobe's wet dream, written by a Bible thumper. It claims to be "The most plausible challenge to the Arabic Quran (Koran) in history!" (The title is merely a play on Furqan; the Arabic word means "Standard" and is a stock epithet of the Koran).
Self pub, and I don't remember having seen any reviews yet in the the usual journals about this new "True Standard", nor are there any RS refs per gbooks/gscholar either, so I recommend holding off per NN/advert until scholastic acknowledgment is forthcoming. We have enough drama as it is. Redirect to article on author if need be. At least he's notable. -- Fullstop (talk) 00:06, 25 February 2009 (UTC)

This topic may not be notable enough in the English-speaking world to warrant an article here, but it might be notable enough for the Arabic-language Wikipedia, especially if it's getting a lot of Arabic-language press. I don't read Arabic, but I think it's here: [[5]]. Someone correct me if I'm wrong. davidwr/(talk)/(contribs)/(e-mail) 16:39, 25 February 2009 (UTC)

Davidwr, you are quite right - I have checked the link you gave, and it is the one to the Arabic Wikipedia. Alternatively, if ongoes to Arabic Wikipedia, one should find the link. ACEOREVIVED (talk) 20:17, 25 February 2009 (UTC)

[6] And the worst reviews I have ever seen on Amazon. 215 people gave it one star. But don't use that as a reliable source. ~ JohnnyMrNinja 17:44, 25 February 2009 (UTC)

I did not know at the time of my earlier suggestion to contact the Wikiproject group for Islam that the book may be classified as Islamaphobic, so it would appear that they may not be the appropriate WikiProject group. However, I am sure that if one checked out existing WikiProject groups, one may find the appropriate one. Ignorance of the book prevents me from offering any more advice on this. ACEOREVIVED (talk) 20:49, 26 February 2009 (UTC)

• The English wikipedia is not limited to the english speaking world, ,and if something anywhere is notable by our enWP standards,it is notable here. The different language WPs have different standards for notability ,so one cannot assume notability here from it being judged notable in one of the other Wps, but the argument that it might be notable in the Arab-speaking world but not here is never acceptable. DGG (talk) 21:00, 26 February 2009 (UTC)

## Use the term "edit summary" rather than "comment" in oversighting

I like, very much, that oversight now results in an edit still being listed in a page history. (For what oversighted edits now look like, here are some examples.)

The text that would otherwise be visible on the history page is what was in the edit summary field. So a very minor request: can the standard wording be changed from "comment removed" to "edit summary removed", since there is no such thing as a "comment" field? -- John Broughton (♫♫) 17:10, 26 February 2009 (UTC)

I support this change as it makes common sense. --DFS454 (talk) 20:30, 26 February 2009 (UTC)

## Random article on category

It's nice to be able to be able to pick an article at random to find a fresh new topic; but I think it would also be useful if one could use a more specific criteria in finding a new article to edit. I propose that on every category page, a link is placed that selects an article at random from the category. I know that there are third party tools to accomplish this, but they are slow and not integrated directly into the category interface. I think that the feature would be especially useful in dealing with backlog categories, because it reaches some of the more obscure pages in a desired category that have been buried deep within. Spidern 17:27, 26 February 2009 (UTC)

I'm not sure that User:Proteins/followrandomlinkonpage.js is a "third party tool", nor that it is slow; it certainly is an option, as a user script. And if there were a lot of demand for this, it could be made into a gadget.
Also, if you check the "Random article" topic in the Editor's index, you'll find a bugzilla filling, and a link to a discussion about why the functionality you want, which is available in the MediaWiki software, has been disabled for performance reasons. -- John Broughton (♫♫) 22:06, 26 February 2009 (UTC)

## Enforcement of Speedy Deletion Template Removal via Bot

In a recent Bot Request it was requested by that a bot be created to enforce the rules on the removal of the speedy deletion template. I have since filed a BRFA in response to this request and was wondering what the general community consensus for such a bot would be, mainly should the bot re-add the speedy deletion template or just notify the person who placed the tag (providing ample options for New Page Patrolers to control and opt out of notices). —Nn123645 (talk) 06:08, 27 February 2009 (UTC)

## Other Wikis

More than once, I have found that many articles about the same topic are much shorter on other Wikis other than the English one, or simply non-existant. I imagine that this is because of the difficult task of keeping them all up-to-date and congruent. Therefore, for the time being, if an article is a stub or nonexistant in one or more wikis but not in an other, why not use translate.google.com or similar translation tool to create a temporary article in wikis of inferior size/lenght? In fact, this could even be done automatically with the Wikipedia software with some simple modifications. This would greatly increase the amount of material available on Wikipedia and therefore its popular support! You ought to try it. Thank you for your attention

18 Feb 2009

Signed: an anonymous but avid wikipedia user currently in high school.— Preceding unsigned comment added by 69.61.249.178 (talk) 17:34, 18 February 2009 (UTC)

Translation software tends to do a very poor job - when people who don't speak a language try to use one to create articles in that languages, it usually comes out as virtual gibberish. bd2412 T 18:00, 18 February 2009 (UTC)
That is what I was going to say. Thanks, but I would strongly discourage this. Language has so many nuances that machine translations end up being gibberish, and not the sort of professional content that we are looking for. Even the articles that do exist on other wikis are often copies of poorly written other language articles, that should not have been transcribed by rote. However, I would support adding a link to machine translations under the search box when an article is not found letting users know that it does exist in other wikis. When an article does exist in another language it should be listed in the list, although, it could be helpful for some people to know that machine translations are available (not that they are going to be very lucid, though). Apteva (talk) 18:17, 18 February 2009 (UTC)
Such a thing already exists via Babelfish, sort of. See Babelfish version of ES main page. davidwr/(talk)/(contribs)/(e-mail) 19:26, 18 February 2009 (UTC)
I (the writer of the original proposal) agree completely with this. However, something is better than nothing, right? Beseides, as I mentioned before, this would be only a TEMPORARY translation. Perhaps a warning could be posted at the top. Or at least to propagate the news (somehow, that's not my problem) that translate.google.com can translate entire web pages. There are a lot of people who would be very grateful to us, particularly in sub-developed countries. Trust me, it would help.
You will find, if you visit Pages Needing Translation, that machine translations of foreign-language articles are only suitable as far as telling us whether an article is worth the trouble of going through an actual human-made translation. Also, if you go to WP:ECHO, you will find a list of foreign-language articles in foreign wikis that have attained Featured Article status in their language of origin, but their English equivalent has not. -- Blanchardb -- timed 01:34, 19 February 2009 (UTC)
I assure you, something is not better than nothing when it comes to machine-translated articles. Rarely will a sentence above fourth-grade level be translated accurately. The reader may be able to guess the meaning, but it's not uncommon for a reasonable guess to be utterly wrong. That's disinformation, and it could even result in libel. Then again, a large fraction of sentences will be completely unintelligible, so of no value at all. I'm not being picky here, honest. The vocabulary and sentence structure of an encyclopedia article is way above what machines can reasonably translate with current techniques. Examples available on request. --Unconventional (talk) 05:56, 20 February 2009 (UTC)
Response: the text above was translated to Spanish and then back to English with translate.google.com and then back to English: "I assure you, is not something better than nothing when it comes to translating articles printed. Rarely is a sentence above the fourth grade level are translated accurately. The reader may be able to guess the meaning, but it is rare that a reasonable assumption that it is absolutely wrong. That is misinformation, and could even lead to defamation. Moreover, a large part of the sentence is completely unintelligible, and therefore of no value at all. I am not being picky here, honest. Vocabulary and sentence structure of an encyclopedia article is well above what can reasonably be translated machines current techniques. Examples available on request." How much of it is unintelligible? Did you understand it? Yes, you did. Why? because it works! If not, get any bilingual to read the translations and then see how much they understood. If it's above 80%, I say it's worth it. Or at least we could create a link to a different page where the "uninintelligible" translation is kept. Then, an editor could easily correct the mistakes. It would be easier than writing out the entire article, now, wouldn't it?
What? The first and third sentences have been mangled into meaning the opposite of what they should have. The 'machine' of 'machine-translated' has been lost, destroying the meaning entirely. The fifth sentence now refers to 'sentence' rather than 'sentences', and is baffling in the extreme. If I were Unconventional and that was posted on the internet as an accurate translation of my remarks, I would consider legal action. Algebraist 14:25, 20 February 2009 (UTC)
Alright, I agree. Oh well. What kind of a moron would I be if I refused to admit defeat? Thank you for showing me the error of my ways. Happy now? Good. However, you never know! The possibilty is always open...
Let me point out also that the double translation hid a couple of flaws. "Sentence" was translated to Spanish as pena, as in penal (the wrong sense of the word). "I'm not being picky here, honest" was translated as No estoy siendo puntilloso aquí, honesto - totally noncolloquial in Spanish, plus puntilloso means "picky" in the sense of "punctilious" (i.e. careful with details) and honesto is not an interjection in Spanish, so this sentence would probably be interpreted to mean "I am not being careful with details or honest, here". See what I mean about libel? --Unconventional (talk) 15:11, 27 February 2009 (UTC)
I forgot to include the penultimate sentence. In Spanish it reads El vocabulario y la estructura de la oración del artículo es una enciclopedia muy por encima de lo que razonablemente puede traducir las máquinas con las técnicas actuales. "The vocabulary and sentence structure of the article is an encyclopedia far above what can reasonably translate machines with current techniques." Mangled indeed, and typical of what I see all the time when fixing MT articles from Spanish to English. --Unconventional (talk) 15:29, 27 February 2009 (UTC)

## Image rollovers (change on hover)

I've been doing some work on wikibooks, and have come up with a template that allows highlighting of features of images "on hover" (i.e. when the mouse is placed over them). This requires an addition to the common.css file, which has kindly been done for me by an administrator on wikibooks.

There's still some work to do on the template, and probably on the css file (e.g. a different template that produces annotation arrows/text on hover). Nevertheless, perhaps this would be a useful addition to wikipedia? If so, I guess that there may be suggestions for improvement before transferring it to wikipedia, and I'd be interested to know what they are. The template, plus examples, is at http://en.wikibooks.org/wiki/Template:HoverImage for anyone interested.

-- HYanWong (talk) 13:14, 26 February 2009 (UTC)

It took me a while to realise how this worked, and, despite your saying so clearly, that two images are required. I think there needs to be consideration given to a template "This image is part of a pair for illustration purposes" to ensure that bizarre looking images are not tagged for deletion, both here and on Commons. I support the rolling of this out. Fiddle Faddle (talk) 13:54, 26 February 2009 (UTC)
There is one caveat. Clicking the image takes you to the "disfigured" one. Fiddle Faddle (talk) 13:56, 26 February 2009 (UTC)
Looking at the template code, it looks like a custom link can be specified for clicks. Though I'm guessing there's probably a way to change the code, there or in the CSS, to make it default to the original image. Equazcion /C 14:05, 26 Feb 2009 (UTC)
Another possibility is to advise that a link be provided from the image page for the "disfigured" image to the "original" image. In some cases (such as my usage on wikibooks), the "disfigured" image is just as reasonable a target as the original, see http://en.wikibooks.org/wiki/Statistical_Analysis:_an_Introduction_using_R/Chapter_2#Quantitative_variables . HYanWong (talk) 23:09, 26 February 2009 (UTC)
I agree about the image tagging. I guess it might also be good to be even more emphatic in the template documentation. In the book I'm writing I use it to display conventional statistical plots that become coloured in an unconventional manner on hover (to emphasise a point about how the plots are constructed). HYanWong (talk) 23:09, 26 February 2009 (UTC)
Seems to barf in IE6, so it needs work. EdokterTalk 14:56, 26 February 2009 (UTC)
Works in Opera but not IE7 --DFS454 (talk) 15:57, 26 February 2009 (UTC)
It requires a browser that supports :hover on tags other than <a>. I don't think IE 6 does. HYanWong (talk) 23:09, 26 February 2009 (UTC)
What's the likelihood that something would be added to our Javascript for it instead? Equazcion /C 00:06, 27 Feb 2009 (UTC)
Actually, IE6 doesn't support :hover for any other tag but <a>. --Nezek (talk) 06:53, 27 February 2009 (UTC)
It's a cute trick, but it breaks badly in non-CSS and text-only browsers. --Carnildo (talk) 05:02, 27 February 2009 (UTC)
Yes, I agree about non-CSS browsers. Ideally it should fail gracefully here (i.e. show both pictures). I guess this is somewhat like Template:Overlay. There is no reason why it should fail on css-enabled text-only browsers (if such things exist!): the captions can change as well as the images. HYanWong (talk) 10:32, 27 February 2009 (UTC)

## Database lag times reported in hours/minutes/seconds

Per WP:VPT#Watchlist, database lag times should be broken down into hours minutes and seconds. It would be easy to implement and much easier to interpret. The extreme 7-hour lag happening right now was the inspiration, and is probably an isolated incident, but lags of hundreds of seconds do occur often, so it this would be useful in general. Equazcion /C 03:51, 28 Feb 2009 (UTC)

Lol; I had to take out the calculator... If this is a simple fix, I would recommend it. Not that important though. -download | sign! 04:13, 28 February 2009 (UTC)
Well, we don't want to encourage this kind of thing.... -- Kendrick7talk 04:14, 28 February 2009 (UTC)

## "Reference" system used as "notes", maybe a parallel notational system needed?

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)

1. ^ example
This functionality is already available.[note 1] Happymelon 23:19, 24 February 2009 (UTC)
1. ^ View the wikitext to see what happened.

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

## A new image bot

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)

## Wikipedia TCG

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:

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)

Could also have these cards:

--DFS454 (talk) 09:41, 27 February 2009 (UTC)

lol, great idea. ~ R.T.G 12:26, 27 February 2009 (UTC)

I got more; I'd offer them but I have to get back to working on my MSE set for the Jargon File. -Jeremy (v^_^v Dittobori) 02:02, 28 February 2009 (UTC)

Where is the GFDL card? Thanks for outlining this here and releasing it under the GFDL! --—— Gadget850 (Ed) talk - 15:33, 27 February 2009 (UTC)

I'm glad with the new card ideas. The truth is that that I've thought myself of more cards but only made a few images up to now, but most of these new card ideas I haven't considered and would be great. TomasBat 19:20, 27 February 2009 (UTC)

This improves the encyclopedia... how? D.M.N. (talk) 20:06, 27 February 2009 (UTC)
Trading card game is finished = is proposed here (or somewhere else) = is sold at the Cafepress store for Wikipedia = proceeds go to the Wikimedia foundation, which operates Wikipedia, Wiktionary, Wikiquote, Wikibooks, Wikisource, Wikinews, and the Wikimedia Commons. Basically, if it sales, it would, somewhat indirectly, (but nevertheless) help improve the encyclopedia by helping to keep it running/helping the foundation in charge of it. TomasBat 20:28, 27 February 2009 (UTC)
Plus never underestimate the value of community building and social interaction among contributors. Dcoetzee 08:48, 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)

## Trial reactivation of Wikipedia:Article Collaboration and Improvement Drive

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)

## Floating references/footnotes

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)

## New categories

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)

## Speedy deletion of books

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)

## Non-contributors

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)

## Proposal: Flush all old autoconfirmed accounts

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... Happymelon 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[7] 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. Happymelon 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! Happymelon 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. PretzelsTalk! 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):

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. PretzelsTalk! 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)

## Default size for individual images

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)

## Deprecating the GFDL-1.2-only templates on the English Wikipedia

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)

## Proposal regarding giving Bot Approvals Group members the technical ability to grant and revoke the 'bot' flag

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! Richard0612 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|}} 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. Richard0612 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. Richard0612 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 Coletc 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 Coletc 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)
• 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 (talkcontribs)
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 [8] and also Usertalk pages for the same period witht he edit summary (→Image licensing: new section) [9]). 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)

## A modest proposal

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)

## Proposed exception rule for the mediawiki blacklist

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)

## Scrubbing old reverted vandalism from edit history.

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. ╟─TreasuryTagcontribs─╢ 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

## Pages moved from userspace to the mainspace should be included in Special:NewPages

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

## Require use of NOINDEX template instead of directly using magic word

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? Happymelon 14:44, 5 March 2009 (UTC)

## Reactivate Wikipedia:WikiProject_Blogging

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)

## More subtle style on Expand-section template

template:Expand-section currently looks like this:

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:

 This section requires expansion.

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

HrafnTalkStalk(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 -- 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.) HrafnTalkStalk(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)

## Categorised watchlist

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)

## Offensive signature question

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. Happymelon 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. Happymelon 16:52, 9 March 2009 (UTC)
Just start blocking and then banning the disruptive user. Tempshill (talk) 23:17, 9 March 2009 (UTC)

## Wiki page exists...Wiki search does not find

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.

## Disallow non-admin page moves to titles not reflected in the article

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 TalkContribs 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? §hepTalk 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)

## Trust indicator

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

## Category:Practicing Jews Proposal

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. BencherliteTalk 10:11, 5 March 2009 (UTC)

## __NOCAT__

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)

## Double redirects

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 [10]. — 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. Happymelon 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? Happymelon 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 Happymelon 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. Happymelon 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". Happymelon 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 [11] and Tard [12], 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. 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? Happymelon 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. 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. Happymelon 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 tc 16:44, 9 March 2009 (UTC)
• Filed as bug 17888, but do keep commenting here, to present a clear consensus to the devs. Happymelon 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 (talkcontribs) 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. Happymelon 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. EdokterTalk 15:46, 10 March 2009 (UTC)
Check. You'd be seeing it in action here if not for the scarily-efficient dbr bots :D Happymelon 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. Happymelon 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 -- 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 ABCB: Since the current setup allows double redirects, visiting A drops you off at C, which shows the redirect chain from there: BC. --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. Happymelon
• 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 DissidentTalk 07:26, 14 March 2009 (UTC)