Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

New ideas and proposals are discussed here. Before submitting:

• Check to see whether your proposal is already described at Perennial proposals.
• Consider developing your proposal on Wikipedia:Village pump (idea lab).
• Proposed software changes that have gained consensus should be filed at Bugzilla.
• Proposed policy changes belong at Wikipedia:Village pump (policy).
• Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.

« Archives, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211

Bot to reduce duplicate references

I have made a request to allow a bot to reduce duplicate references in articles, and I'm posting here to see if there is any opposition to the idea, or any requests to modify the way the bot would work. The bot request is here. In short, the bot will comb through this list of articles and search for duplicate references in each article. If it finds duplicate references, it will combine them using named references. In other words, if the bot finds multiple instances of this in the same article:

<ref>foobar.com</ref>

it will replace the first instance with:

<ref name=duplicateref1>foobar.com</ref>

and it will replace all subsequent instances with:

<ref name=duplicateref1 />

Please note that this bot will only affect references that are exact matches. If there is even one character that is different in two refs, it will leave them alone (unless the difference is only whitespace characters). I've made a table below to summarize the different cases that the bot will encounter, and whether or not it will take action on each case:

First ref	Second ref	Bot Action?	Comments
<ref>http://www.google.com</ref>	<ref>http://www.google.com</ref>	Yes	Exact duplication
<ref>http://www.google.com</ref>	<ref>http://www.google.com/stuff</ref>	No	Same site, different page. Not an exact match, so the bot will not touch it.
<ref>{{cite book|title=Foo|author=Bar}}</ref>	<ref>{{cite book|title=Foo|author=Bar}}</ref>	Yes	Exact duplication
<ref>{{cite book|title=Foo|author=Bar}}</ref>	<ref>{{cite book|author=Bar|title=Foo}}</ref>	No	This is technically an exact duplication, but arguments are out of order so the bot will be cautious and leave it alone.
<ref>{{cite book|title=Foo|author=Bar}}</ref>	<ref>{{cite book|title=Foo|author=Bar|page=47}}</ref>	No	Same source, but one references a page number. Not an exact match, so the bot will not touch it.
<ref>[http://www.disney.com Mickey Mouse]</ref>	<ref>[http://www.disney.com Mickey   Mouse ]</ref>	Yes	Only difference is white space, the bot will filter this out.
<ref>{{cite book |title=Foo |author=Bar }}</ref>	<ref>{{cite book|title=Foo|author=Bar}}</ref>	Yes	Only difference is newlines, the bot will filter this out.

Hopefully the table above demonstrates that the bot will only be fixing duplicate references which were created either by mistake or created by editors who don't know about named references, and it will not touch any references that were purposely not grouped together. There are currently over 5,000 articles that have duplicate references. Let me know if you see any potential problems with this proposal. Thanks. —SW— ^spout 16:55, 15 March 2011 (UTC)

• Sounds good to me, I don't know what we didn't already have this. I'm no programmer, though. Ian.thomson (talk) 17:09, 15 March 2011 (UTC)
• As described here, it sounds great in principle. Would want careful testing before implementation though. Skomorokh 18:30, 15 March 2011 (UTC)
• Support Nifty! Sounds potentially really helpful, with the appropriate care in rollout of course. I'd almost suggest that worrying about the cite template argument order is too conservative, but I'm guessing that if anything it's easier to code (and easier to code correctly) the current way, and it probably wouldn't pick up that many more duplicate refs. I wouldn't mind a version I could run on my own, either. --joe decker^{talk to me} 18:38, 15 March 2011 (UTC)

Reflinks will do this manually. ---— Gadget850 (Ed) ^talk 18:42, 15 March 2011 (UTC)

Awesome, I make a lot of use of RefTools but haven't played with Reflinks at all. Thanks! --joe decker^{talk to me} 18:46, 15 March 2011 (UTC)

The main Reflinks has a bookmarklet that you can drag to your browser bookmark bar. Clicking on it will open the current page in Reflinks. ---— Gadget850 (Ed) ^talk 04:20, 16 March 2011 (UTC)

You're right, it's much easier to program the bot if it doesn't have to worry about identical template arguments that are out of order. And, I agree that it would probably only find very few (if any) additional duplicate references if it was programmed to look for that case. Not worth the effort, and not worth the risk of introducing bugs due to increased algorithm complexity. —SW— ^{spill the beans} 20:57, 15 March 2011 (UTC)

• Applauds* your good engineering sense.  :) (And thanks to other folks for pointing me at Reflinks, which I'm also using now to good effect in a couple places.) --joe decker^{talk to me} 19:04, 16 March 2011 (UTC)

• I'm surprised this doesn't exist already. I guess existing instances I've seen are using reflinks and possibly AWB? Rd232 ^talk 00:43, 16 March 2011 (UTC)

I was also surprised that this doesn't exist. I think the fact that there are currently over 5,000 articles that have duplicate references is proof that either no such bot exists, or that it's not doing a very good job. —SW— ^soliloquize 15:45, 16 March 2011 (UTC)

• Oppose. Whether we should have named references or not (and correspondingly, whether we should have multiple footnotes at a single point) are matters of editorial judgment; an article repeating one reference exactly is not a problem. Septentrionalis PMAnderson 17:18, 16 March 2011 (UTC)

As Pmanderson says, using named references is optional. Bots should not add "named" references to articles where human editors have avoided using them; see WP:CITEVAR. — Carl (CBM · talk) 17:21, 16 March 2011 (UTC)

To be clear, the bot is specifically designed to not add named references to articles where human editors have avoided using them. It is specifically designed to find articles where duplicate references have been inadvertently introduced. Can you describe a situation where it is necessary to have multiple references in a single article which are 100% identical? —SW— ^chatter 17:38, 16 March 2011 (UTC)

• I don't see the objection. This does not seem to be the kind of variation in style that WP:CITEVAR is concerned with. It is the difference between:

John agreed,^[23] and the flight was uneventful.^[24] But on arrival in Chicago, the police was waiting for the duo.^[25] Martin had snitched on them.^[26]

---

References

23. ^ John Doe (1999). My Crook Years: an Autobiography. Hothouse Press.

24. ^ "An uneventful flight". The Chicago Flyer. 2009.

25. ^ John Doe (1999). My Crook Years: an Autobiography. Hothouse Press.

26. ^ John Doe (1999). My Crook Years: an Autobiography. Hothouse Press.

and

John agreed,^[23] and the flight was uneventful.^[24] But on arrival in Chicago, the police was waiting for the duo.^[23]. Martin had snitched on them.^[23]

---

References

23. ^ ^{a b c} John Doe (1999). My Crook Years: an Autobiography. Hothouse Press.

24. ^ "An uneventful flight". The Chicago Flyer. 2009.

What is the value of having repeated identical entries in the References section?  --Lambiam 17:58, 16 March 2011 (UTC)

Exactly, there is no value to having repeated identical references, and WP:CITEVAR is not a relevant guideline with respect to this topic. If sentence #1 cites reference #1, and sentence #2 cites reference #2, but reference #1 and reference #2 are 100% identical, then there is no difference for both sentences #1 and #2 to cite reference #1. The only difference is that it is more efficient, saves space, improves readability, and generally makes logical sense. —SW— ^chat 18:54, 16 March 2011 (UTC)

It sounds like you are arguing that using named references is required by WP:CITE, but it isn't. Articles are not required to use named references even if they have "100% duplicate" citations, which is why a bot can't just go through changing the duplicates to named references. — Carl (CBM · talk) 19:01, 16 March 2011 (UTC)

Bots are not limited to perform only tasks that are explicitly "required" by some guideline or policy. The reason that grouping identical references is not required is because Wikipedia is not a bureaucracy, and not every common sense rule has to be spelled out. There is no logical reason why having duplicative, identical references is preferable to grouping them. Unless you can provide some kind of example situation (preferably with respect to an actual, real, existing article) where grouping 100% identical references will result in an actual problem, or an example situation where duplicative references are actually preferred, then the basis for your opposition is unfounded. —SW— ^communicate 20:12, 16 March 2011 (UTC)

Our guiding principle is that, in optional matters, the established citation style in each article should be preserved, and new references should be added that match it. The style should not be converted from one optional style to another based solely on personal preference. This includes, among other things, the choice whether to use named references in an article. Neither using them nor not using them is objectively better; it's just a matter of preference. — Carl (CBM · talk) 20:32, 16 March 2011 (UTC)

The issue of named references is a red herring. It's not like the bot is going around naming every reference it can find. The primary purpose of the bot is to group identical references, and it just so happens that it accomplishes this by naming them. Having identical references is not a personal preference, nor is it a style preference. It is illogical and inefficient. Again, you have not presented any logical reason why identical references would be preferred in any real situation, or why grouping identical references would be problematic in any real situation. We're looking for logical reasons to not perform this task, not reasons based on an emotional response to automated edits. —SW— ^confabulate 20:48, 16 March 2011 (UTC)

The choice of style is always a little illogical. But since there's no lack of vertical space in articles here, there's also no need to be efficient with it. There is a long history of disagreements over citation styles where everyone feels their preference is the only logical choice; but in reality the choices are all more or less equivalent. That's why we have a presumption to keep the original style. — Carl (CBM · talk) 21:13, 16 March 2011 (UTC)

I agree with most of what you're saying. The only thing I disagree with is that this particular issue is a style issue. The use of duplicate references is, in my opinion, a mistake on the part of the editor, not a conscious stylistic choice. If this were a style issue, then there would be at least two valid ways of dealing with identical references. You would be able to say "In situation A, it's better to do it this way, and in situation B, it's better to do it a different way." That is a style issue. In this case, there is only one valid way to deal with identical references, and that is to group them. If you disagree with that statement, then please provide an example of a real-life situation where not grouping identical references is clearly preferable to grouping them. We don't force editors to group references because it is not technically possible. However, it is beyond clear that it is considered preferable to group them, as evidenced by the fact that no one can provide an example case where it is not preferable. —SW— ^speak 23:41, 16 March 2011 (UTC)

Some find sequential references are simpler to follow in a text, and some style guides support that. In the Wiki implementation, if you have three refs reused a dozen times each, then grouping with named refs makes some sense, but grouping a handful of refs that are repeated once or twice each impedes sequential referencing for no substantial benefit. So there are some situations where is is preferable not to group refs. However, if you say it is "beyond clear that is it considered preferable to group them", what is the huge over-riding benefit that trumps any other consideration? Gimmetoo (talk) 20:42, 17 March 2011 (UTC)

• Comment Don't most people use ibid when referring to the same thing? I like the lettering thing. Sir William Matthew Flinders Petrie Say Shalom! 18:06, 16 March 2011 (UTC)

See WP:IBID, which specifically instructs us to not use ibid. —SW— ^express 18:28, 16 March 2011 (UTC)

Without referring to Snottywong's reference, I can say from experience that using ibid is a bad thing in a wiki because it is completely at the mercy of the exact order of text on the page, which is fluid for articles here. --User:Ceyockey (talk to me) 13:47, 17 April 2011 (UTC)

• Sounds like a very sensible bot proposal. As said above, there is no value to having repeated identical references, and no style variant that I know of calls for repeated identical references.  Sandstein  20:27, 16 March 2011 (UTC)

Many style guides for endnotes say they should be numbered consecutively [1], which means that the same number cannot be used in two different places for the same reference. Do you know of any style guide for endnotes that allows the same endnote number to be repeated after larger numbers have been used? The same question applies for footnotes, but I doubt any guide allows using a footnote number for a footnote that appears on a previous page. — Carl (CBM · talk) 20:40, 16 March 2011 (UTC)

You can't be serious. Random external style guides don't trump the MOS. If sequential footnotes were required, then the mechanism for grouping footnotes wouldn't have been made available to us. Can you tell us the real reason that you are so vehemently opposed to this proposal that you would go to such lengths to discredit it? —SW— ^comment 20:52, 16 March 2011 (UTC)

There's nothing in the MOS that requires named references – that's my point. You're arguing as if they were required somehow. OTOH Sandstein said he had never heard of a style guide that would require repeating a reference, so I pointed out that some do, by requiring endnotes to be sequentially ordered. — Carl (CBM · talk) 21:13, 16 March 2011 (UTC)

Ok, let me clarify my position as much as possible, as it seems you're not understanding the point. It's true that the MOS doesn't require identical references to be grouped. On the other hand, the MOS doesn't prohibit identical reference from being grouped either. In fact, the Mediawiki interface specifically provides a mechanism to group identical references, suggesting that this is a desired feature. Furthermore, bots have never been restricted from performing tasks that weren't "required" by some guideline or policy, so your argument that it is not required by MOS is irrelevant. Also, while the MOS does pull some of its style guidelines from other organizations' style guidelines, that doesn't mean that we are bound to any style guideline you can find on google, so that argument is also irrelevant. Besides, I think Sandstein was saying that he's not aware of any Wikipedia style variant, not that he was not aware of any style variant that has ever existed in the history of mankind. Here is my main point, which you or no one else has yet responded to satisfactorily: Under what circumstances would it be beneficial/desired/valuable to adopt a personal preference or style preference whereby duplicate references are not grouped? When would it ever be better to leave identical references ungrouped? Until I get a satisfactory answer to those questions, then I can't help but to feel that you are arguing for the sake of arguing. —SW— ^communicate 22:40, 16 March 2011 (UTC)

I'm just pointing out that we have a longstanding principle not to do this sort of thing. WP:CITE allows article to use named refs, or not to use named refs, and the established style should be respected. — Carl (CBM · talk) 23:54, 16 March 2011 (UTC)

• I regularly coalesce identical refs, like here, and have not yet once run into an adverse reaction. My impression is that, apart from the cases that were introduced before we had ref naming, many editors don't know about the possibility or do not understand how to use it (and copy–paste is easy), while in other cases duplicate refs are inadvertently introduced by editors unaware of the fact that there is already an identical reference elsewhere. I've never had the impression such duplication was a conscious preference.  --Lambiam 22:26, 16 March 2011 (UTC)
• I could've sworn some of the cleanup bots already do this. I have yet to come across a single article where references are duplicated on purpose and named references are avoided on purpose, so some of the above arguments seem rather silly to me, to be honest. --Conti|✉ 22:41, 16 March 2011 (UTC)
• To combine a couple threads above, I'll respond here. If an editor writes an article in which he or she consciously chooses to keep the footnote numbers consecutive, by not using named references, that is certainly stylistic choice - what else is it? We have a longstanding practice of respecting such choices unless there is a consensus that something has to be done some other way. That's expressed both in WP:CITEVAR and WP:STABILITY in the MOS: when two different styles are both acceptable, the first style to be chosen should be left, not changed solely for the benefit of using a different optional style. This principle is motivated by the perennial difficulty of getting any agreement on these things; arguments that one style is better than another tend to be Qixotic. In the case at hand, the benefit of named references is marginal, because there is no space limitation on the references section of an article. On the other hand, the idea that footnotes should be numbered consecutively is quite common in real style guides and is certainly compatible with the MOS. — Carl (CBM · talk) 23:51, 16 March 2011 (UTC)

To my knowledge, keeping footnote numbers consecutive has never been important on Wikipedia, nor has it ever been spelled out as a priority, a requirement, or even a suggestion in the MOS (again, to my knowledge). —SW— ^chat 00:27, 17 March 2011 (UTC)

It doesn't matter whether I, or you, find it important. If the style in an article is established that way, in the absence of any requirement that named references have to be used, we need to respect the preferences of other editors. Everyone has their own taste and their own preferences, which may not make sense to others. We recognize that in our policies by saying not to change from one optional style to another. — Carl (CBM · talk) 00:36, 17 March 2011 (UTC)

Now you're assuming that editors are making conscious choices to preserve the consecutive numbering of citations. What evidence do you have that at least some of the duplicative references are a result of conscious style choices by editors, as opposed to inadvertent coincidences or blatant mistakes? —SW— ^express 00:55, 17 March 2011 (UTC)

Carl, do you have any examples of articles where editors specifically choose to use duplicated references? Because I'm getting the impression you're talking about a hypothetical problem here that doesn't actually exist anywhere on Wikipedia. --Conti|✉ 07:51, 17 March 2011 (UTC)

I thought this whole discussion began with a list of articles where there were duplicated references; aren't those examples? If we assume good faith, that means assuming that editors edited articles intentionally, and formatted the references the way they wanted to. It's not as if named references have ever been required, so not using them is not a mistake in any way; if an editor didn't use them, that's the prerogative of that editor, and perfectly acceptable according to the MOS and WP:CITE. — Carl (CBM · talk) 11:54, 17 March 2011 (UTC)

That's a rather odd way of defining "assuming good faith". Is it suddenly "assuming bad faith" when I assume that people might not even know of named references, and therefore don't use them? Or that the large majority of editors simply wouldn't care one way or the other? No one here talks about named references being required. It just simply makes sense to use them, and apart from "there might be somewhere someone that might not want to use them for no specific reason", there's no reason not to use them. --Conti|✉ 12:37, 17 March 2011 (UTC)

The existence of articles with duplicate references is not proof that they were created that way intentionally. AGF has nothing to do with determining whether someone did something as a conscious stylistic choice, or if they did it unintentionally or as a mistake. If I misspell a word in an article, I would hope that you wouldn't "AGF that I meant to do it" and not fix it. —SW— ^babble 14:19, 17 March 2011 (UTC)

A good example of that is this edit, which introduced duplicate refs in an inferior style (just the bare urls) in an article that at that moment had strictly coalesced refs, largely in standard style and at least giving the source titles. I see no reason not to assume good faith, but it is quite far-fetched to suggest that this referential duplication is the result of an intentional choice reflecting the editor's stylistic preference.  --Lambiam 22:15, 17 March 2011 (UTC)

Articles are not required to use duplicate citations and humans can change them to named references, which is why a bot can just go through changing the duplicates to named references. There also is no need to be inefficient with vertical space merely because there's no lack of vertical space in articles. If an editor disagrees with the change, they can just undo it. Change in an article always invites a potential for disagreement. However, until there is a disagreement or at least an objective/explicit preference for a particular style, there is no basis to preserve one style over another, particularly for stub and start articles. Consensus preference for removing duplicate references is set by Wikipedia:Featured article criteria - criteria to which all articles should aspire. -- Uzma Gamal (talk) 15:43, 17 March 2011 (UTC)

Here's the sort of thing I see a ton of, and that definitely colors my opinion on the matter towards automated assistance. Of course, this article is problematic for other reasons, but I think from a variety of indications that it's a good bet that the editor here is actually unaware of the our ability to consolidate refs. Maybe I just spend a lot of time in the shallow end of the article pool, but this is really what comes to mind for me during this discussion. --joe decker^{talk to me} 01:48, 19 March 2011 (UTC)

• Support A no-brainer, I think. Now if we can only reduce the "single word supported by 25 cites syndrome". Any bot available to find the worst offenders? Collect (talk) 14:24, 17 March 2011 (UTC)

I just saw one of those articles, but now forget where it is. Good idea for another bot - list of articles having more than three adjacent references sorted by max number of adjacent references. -- Uzma Gamal (talk) 16:03, 17 March 2011 (UTC)

There may already be a toolserver script out there that does this. —SW— ^prattle 16:31, 17 March 2011 (UTC)

• Support trial tests - In general, it is a good idea. As for an issue, not very often, I'll use duplicate references when I want to use two different URL links to two different pages in the same book posted at Google. If the bot were to remove one of my two URLs, that would be a mistake. I think the bot will have to have a lot of exceptions to its decision to remove duplicate references. I suggest finding the most clear cut case for removing duplicate references - the one where just about everyone will agree that it would be beneficial to remove the duplicate references -- and use that to implement the bot v1. Let everyone chew on that for a while then slowly add a second duplicate reference removal condition. I suggest starting with dublicate {{cite web}} references since newbies are more likely to cite to web pages and to not know about naming a citation. Also, perhaps you can limit the bot to operating on articles rated below a B class. Carl's point above about preferred styles likely is more true for B and higher class articles. -- Uzma Gamal (talk) 15:27, 17 March 2011 (UTC)

I would hope that no GA's or FA's would have duplicate references. That would almost certainly be something that gets addressed in GA/FA review. And, for the moment, the plan is to run the bot once, not let it run continually. If the backlog bloats up again in the future, I might run it again, but it would probably be several months down the line. —SW— ^yak 01:20, 18 March 2011 (UTC)

See the table at the top of this thread. If two references have slightly different URL's, the bot will not group them. It will only act on references that are 100% identical. —SW— ^prattle 16:31, 17 March 2011 (UTC)

OK, what about limit the bot to operating on articles rated below a B class. The bot won't be hitting uf FA or GA articles, right? Also, the bot should not return to any article it has worked on since (i) if the bot reference change is kept, then there is no reason to return and (ii) if the bot reference change is undone, then a human decided what they wanted and the bot should not re-undo that. -- Uzma Gamal (talk) 00:31, 18 March 2011 (UTC)

• Like CBM argues, articles have been written with all refs in sequence, consciously avoiding reused named refs. A bot really shouldn't change that. But, there is a fairly natural way to handle this - only automate work on articles that already have some minimum number of reused named references (say 5), and definitely avoid any article which does not have any reused named references already. That should avoid the bot working on any article written without reusing named refs. Gimmetoo (talk) 20:42, 17 March 2011 (UTC)

I'm not aware of any conscious movement to support the sequential numbering of references in articles. Is this just a feeling that you have, or do you have any evidence to support the fact that there is a conscious effort to keep references sequential, or any evidence of articles where the major editors of an article expressly agree that sequential references are important on that article for some particular reason? Also, the limitations you've proposed above would make the bot almost completely non-functional. The vast majority of articles with duplicate references don't already use named references, because if they did then they wouldn't have duplicate references. This is because duplicate references are not intentionally created, they are created either by mistake or by editors who are not aware that there is a mechanism available to group them. Take a look at the reference sections of these example articles and tell me you don't see a problem (the bold ones are especially terrible):

• 1984 Tampa Bay Buccaneers season
• 1985 Tampa Bay Buccaneers season
• 2011 Asian Winter Games opening ceremony
• 2011 Clube de Regatas do Flamengo season
• 2011 in hip hop music
• Abram Fitkin
• Amanda Knox: Murder on Trial in Italy
• Antonia Handler Chayes
• Arian controversy
• Australian Road Rules

And considering I only searched until the end of the A's, it's all but guaranteed that there are even worse examples out there. Only one of these articles would pass your criteria of already having 5 named references (Arian controversy). I don't see any evidence of a conscious effort here though. Take Australian Road Rules as an example. It's hard to argue that an editor consciously did that to keep references sequential, since the same reference is repeated a dozen times in a row with no other references in between. So, if they had grouped the references, it would not have broken the sequential numbering. You can also see from these examples that grouping references makes it much easier to determine how heavily an article relies on a particular source. If there are 400 references in an article, and one reference is repeated 50 times throughout the article, it would be difficult to determine that this is a reference on which the article relies heavily. If it was grouped, however, you'd be able to see it immediately. There is no benefit to sequential numbering, and that is why there is no reason to strive to keep reference numbers sequential. —SW— ^communicate 21:36, 17 March 2011 (UTC)

It's not a "feeling". If an article has 20 refs, two of which are used twice and all the others used once, I don't perceive any significant benefit from introducing little 'a' and 'b' marks on the two, and doing so would break sequence, which I perceive as a loss. Sequential refs are easier to follow for verification and in accord with some style guides. If you don't agree those are benefits, that's fine, but saying "there is no benefit" is not exactly correct. Your proposed bot would be useful for articles which have a lot of named, repeated references, but get sources re-added regularly by editors who are not aware of what sources are already cited. Gimmetoo (talk) 22:34, 17 March 2011 (UTC)

How do sequential refs make it easier to follow for verification? All you're doing is matching numbers. Actually, in most cases all you're doing is clicking the link and looking for the highlighted reference, so the sequential nature of the number makes no difference. Even if you were going through an entire article top to bottom to verify references, it would still be beneficial to have grouped references. That way, if reference #7 is used 5 times in one section, and you've already read through reference #7, then you can just skip over it. With sequential references, you would waste all kinds of time looking through the references just to find out that references 14, 19, 27, 53, and 66 are all the exact same source that you've already read. I can say that "there is no benefit to grouped references" because no one has produced one as of yet. So far, the reasons you have described include: "I don't perceive any significant benefit", "[it] would break sequence, which I perceive as a loss", "sequential refs are easier to follow for verification" (with no other reason to support why it is easier), and "[it is] in accord with some style guides" (style guides which have nothing to do with Wikipedia, and which do not include the MOS). None of these are valid reasons, in my opinion, and I believe I have refuted them all. You also mention that you believe that the bot would be useful only for articles which already have a lot of named, repeated references. What about the vast number of articles that have been recently created, which have been primarily edited by one editor, where that editor is not aware of named references? This case makes up the majority of the 5,750 articles that currently have duplicate references. Also, keep in mind that we are currently talking about 5,750 articles, which represents 0.16% of articles on the english WP. The fact that this problem affects such a relatively small number of articles implies that #1, duplicate references are not desired since 99.84% of articles already don't have duplicate references, and #2, that we probably shouldn't be making such a big deal over it. —SW— ^chat 23:05, 17 March 2011 (UTC)

• • • • None of these are valid reasons, in my opinion, and I believe I have refuted them all. Then you don't know what you are talking about. Absolutely and unconditionally oppose. Septentrionalis PMAnderson 02:26, 18 March 2011 (UTC)

Apparently we need a bot to refactor duplicate !votes, too. --joe decker^{talk to me} 18:02, 18 March 2011 (UTC)

See also Help:Footnotes#Multiple_citations_of_the_same_reference_or_footnote, which does not mention that this is optional or subject to stylistic interpretation in any way. Your "absolute oppose" is duly noted, but without a logical reason for your oppose, it carries little weight. —SW— ^express 03:51, 18 March 2011 (UTC)

Nor does it say named references are required. I have provided a case where it is not preferable to use repeated named references. You appear to disagree, and apparently think that "it is beyond clear that it is considered preferable to group them". Fine. Can you convince me that reusing named references in the case I describe is absolutely and completely beneficial so as to override any other consideration from any other editor? Gimmetoo (talk) 04:45, 18 March 2011 (UTC)

Just to throw out something, would an exclusion tag of some sort be sufficient? E.g., what if the 'bot did it's work, but left (in edit summary) a "if this isn't what's intended, revert and add {{leave my refs alone}} or some such. How much would that reduce your concern? I happen to think even in the case you cite that it's beneficial (although only a tiny bit so), as I doubt most readers look at the refs and any duplication is, for those readers, wasted ink, but I hear and respect that your view differs. --joe decker^{talk to me} 01:24, 19 March 2011 (UTC)

Note that Pmanderson was just blocked for 1 week for an unrelated incident, and therefore probably won't be able to respond. —SW— ^speak 04:15, 18 March 2011 (UTC)

I wish I could convince you, but in order to do that I would have to understand why you think that having sequentially numbered references has any benefit whatsoever. The guidelines don't specifically say that named refs are required or optional, but I think this is only a bureaucratic distinction and it's clear that they are highly preferred at the very least. See Wikipedia:Footnotes#Reference_name_.28naming_a_ref_tag_so_it_can_be_used_more_than_once.29, Wikipedia:Citing_sources#Footnotes, and Help:Footnotes#Multiple_citations_of_the_same_reference_or_footnote. They don't specifically say "It is required that you do this", but they all generally say "Here's how to use identical references." —SW— ^chatter 18:21, 18 March 2011 (UTC)

• Strong support, if only because I always group my references because I think it makes sense. However, having worked as a major contributor to pages (eg.Brontë, Malvern, and a few others) that have hundreds of footnotes, it makes even more sense. There is also the aspect from my experience at AfD of having to sift through refs on articles that 'claim' to be well referenced, that to a more casual reader, a long list that includes the same duplicated ref makes it look as if the article is well referenced, giving a false impression of notability. Kudpung (talk) 07:52, 18 March 2011 (UTC)
• Support It's much easier to see how well sourced an article is (and how much improvement it could use) when duplicates references are unified. Having fixed this a number of times by hand, I support having a bot to help out with this task. Sailsbystars (talk) 17:43, 18 March 2011 (UTC)
• Strong support - There is no reason, in the long term, to not use named references when the exact same citation is repeated multiple times. Named references help to remove excess code from the text and reduce clutter in the "References" section, thereby making it easier to edit the article and check references. -- Black Falcon ^(talk) 22:00, 28 March 2011 (UTC)
• Strong support - it seems such an obviously good idea. I'd imagine that the vast majority of instances that would be picked up would not be the result of a deliberate style choice on the part of the author(s). And when it comes to seeing how heavily something is relying on just one source, at a glance, it's so much easier when references are grouped. Pesky (talk) 05:20, 29 March 2011 (UTC)

Strong oppose. Please don't force the abomination of "named references" in articles where they have been intentionally avoided. And please don't pretend that it is "clean up" to do so. --Hegvald (talk) 05:43, 5 April 2011 (UTC)

Stats

I ran an analysis on the first 500 articles from the toolserver list, and found the following statistics:

• 672 distinct references were duplicated at least once.
• A total of 1,820 duplications were detected.
• The maximum number of times a reference was duplicated was 24.
• The average number of times each duplicated reference was duplicated was 2.7.
• 197 of the 500 articles (39%) already had at least one named reference.
  • Out of the 197 articles with named references, the average number of named references per article is 27.1.
  • Out of the 197 articles with named references, the maximum number of named references in an article is 466.
  • 156 articles had 5 or more named references.

—SW— ^soliloquize 16:25, 18 March 2011 (UTC)

Alternate proposals

While I still have trouble believing that there is actually opposition to this common sense proposal, there obviously is enough of a vocal minority to hold up the bot proposal (I count 11 supporters and 3 opposers above). Some tweaks to the proposal have been proposed above, so I thought I'd organize them in a new section so they can be discussed separately. Would any of the ideas below change the minds of the opposers?

1. Restrict the bot to working on articles that already use named references. (According to the stats above, this is about 40% of articles with duplicate references.)
2. Make the bot exclusion-compliant. That is, the bot will look for a template or comment in the article's wikitext which will signal to the bot that the article is purposely using duplicate references, and that the bot should leave that article alone. A link to an instruction page can be included in the bot's edit summary for easy access. After all, if someone didn't like the changes the bot made, it would only take them seconds to revert.
3. Prohibit the bot from working on articles that are GA class or above. I doubt there are very many GA/FA articles with duplicate references, so this probably won't make much of a difference.

—SW— ^gab 15:36, 19 March 2011 (UTC)

It would seem easiest to me to enact a 1RR requirement for the bot. This could be followed up with a report to see exactly which articles the bot was reverted on, if any. --Izno (talk) 23:07, 19 March 2011 (UTC)

I think that's a good idea. It would be easy to scan all of the articles that the bot edited about a week later and see if anyone reverted the edits. If so, that article would be placed on a blacklist so the bot doesn't edit it again. Also, the bot could be programmed to skip over articles which have {{bots|deny=Citation bot}} and {{bots|deny=Snotbot}}. I think this is more than enough to ensure the bot is acting responsibly, not annoying people, and not forcing any particular kind of citation style on anyone. Any thoughts from the opposers? —SW— ^prattle 02:08, 20 March 2011 (UTC)

I would not think the usage of T:Bots necessary if the bot is restricted via 1rr and blacklisting certain articles from the bot-side. But that's just me. --Izno (talk) 02:17, 20 March 2011 (UTC)

I've been intending to come here and offer my Support for the last 24 hours, so here it is. The "1RR requirement" satisfies just about every criticism, in my opinion (Bots should all be required to wait at least a few hours before revisiting pages regardless, in my opinion. Especially bots which deal with Recent Changes. That Sort of think simply avoids a bunch of "teh dramaz", I think.) Besides, if you can gain approval for this, it ought to make it easier for me to get some similar tasks approved. ;)
— V = IR (Talk • Contribs) 21:47, 20 March 2011 (UTC)

I wouldn't expect to be making edits related to this task more frequently than once per week, more likely once per month. There shouldn't be any danger of the bot edit warring, especially if it checks whether it's been reverted on an article. —SW— ^speak 04:52, 21 March 2011 (UTC)

Just as a more general comment, it's not even edit warring that is a real concern though. There's just a sense, among some, that is something along the lines of "OK, now I have to battle against this machine trying to change my contribution!" If the person makes a contribution, then some bot comes and changes it, and the person changes things back, if that's the end of the chain then all is well. It's when the bot comes back again (because the page is on Recent Changes) that the real trouble can begin. That's when people start feeling embattled, so they go running off to block the bot and start screaming for blood at ANI, etc...
— V = IR (Talk • Contribs) 15:56, 21 March 2011 (UTC)

Understood. Firstly, the bot will not be monitoring Recent Changes, it will only be looking at the toolserver list to decide which articles to examine. As discussed above, the bot will monitor all of the articles it changed in the last pass for reversions, and any confirmed reversions will put the article on a blacklist that the bot will no longer touch. —SW— ^yak 16:21, 21 March 2011 (UTC)

• Support - I think the vast majority cases of duplicate references are issues of editor didn't know how to group them or just didn't care - not that the editor consciously chose not to group for some stylistic reason. Nevertheless, adding a 1RR rule and templated exclusion option should cover all needed exceptions. (I don't think it makes sense to exclude GA and FA articles automatically; rather, I just don't think there will be much that the bot could do on those articles.) LadyofShalott 14:18, 21 March 2011 (UTC)
• The solution to getting a bot to do "controversial" edits shouldn't be to make editors add exclusion templates. It's a bad precedent, as it encourages this sort of workaround for future bot proposals. Generally, the standard approach has been to either restrict the bot task to avoid nearly all false positives, or (if the number of articles involved is "small") an editor makes the edits with script assistance. Gimmetoo (talk) 01:40, 26 March 2011 (UTC)
• Support 1RR which will take care of all the likely objections. The most frequent cases are that authors do not know, or don't want to bother (For an article with 10 refs of which 2 are dups, one might just copy & paste rather than think about it), or where an article starts off small with no duplicated refs and gets added to, and some of them duplicate without being noticed. I can't imagine why anyone would prefer not to. unless they were really accustomed to writing in the older style where one did number consenutively, and for the second time something was cited, say" Johns, A. B,. Ibid if immediately preceding or Jones, A. B. op.cit if not immediately preceding. (I have in fact seen this here, and its usually a clear sign of copypaste). I'd think that if anyone really wanted to write that way, they would not be using the ref formatting in the first place, but would hand code them. I can understand the objections as coming from the dear that other things in refefrences might get centrally formatted, but I don't think it's really a slippery slope here, and this particular change is obvious enough. DGG ( talk ) 05:30, 27 March 2011 (UTC)
• Support - you don't need to perma blacklist that site, just maybe a short period of time. Probably could add an automated edit note to notify of anything you believe is an error.陣内_Jinnai 23:24, 28 March 2011 (UTC)
• Support – This will take care of the objections. —mc10 (t/c) 02:17, 5 April 2011 (UTC)
• Strong Support - Making a bot that automatically cleans up references is a great idea. It should decrease the backlog significantly. Alpha Quadrant ^talk 03:26, 5 April 2011 (UTC)
• Strong oppose. Please don't force the abomination of "named references" in articles where they have been intentionally avoided. And please don't pretend that it is "clean up" to do so. --Hegvald (talk) 05:43, 5 April 2011 (UTC)

The proposal is to "Restrict the bot to working on articles that already use named references." This means it will not be adding grouped references to articles that do not have them already. Personally I think that the bot should fix all duplicate references, because otherwise they have to be fixed manually, or with RefLinks. As I frequently clean up references, it would be nice to have a bot that does the tedious work of fixing ungrouped references. @SW, will it be possible to run the bot on a single article, like citation bot does? Alpha Quadrant ^talk 14:14, 5 April 2011 (UTC)

My comment ended up under the wrong subsection. --Hegvald (talk) 19:42, 5 April 2011 (UTC)

• Support I would love a bot that did this. Would personally want the name of the ref group to be the Author last name and the date of publication. --Doc James (talk · contribs · email) 13:08, 6 April 2011 (UTC)
• Support Common sense, streamlines referencing, 1RR takes care of rare issues. --Cybercobra (talk) 23:38, 8 April 2011 (UTC)
• Support alternate proposals, 1RR/template/type exclusions sound entirely sensible and are my preference. --joe decker^{talk to me} 04:59, 11 April 2011 (UTC)

• General comment—I think that the # of articles containing duplicate references, 5,000, is small enough to tolerate without an automated fix. I would come down on the side of not bot-manipulating references in this manner in general. We have a quite difficult time getting people to add references, and if a bot makes a mistake in that area (potential, not a certainty - I trust bots in general), then that will be substantially offputting to those who are a) casual editors and b) been diligent enough to add references. In other words, I think the risk-benefit ratio is too high at the present time. --User:Ceyockey (talk to me) 13:44, 17 April 2011 (UTC)
• Support No-brainer. It'd tidy up pages, I too am perplexed at the ridiculous oppose !votes, ugliness of named refs? What the fuck? Seriously? —James ^{(Talk • Contribs)} • 9:57pm • 11:57, 18 April 2011 (UTC)

Make prompting for a missing edit summary the default

Currently, users are only prompted to provide an edit summary when they click Save page with a missing summary if they have turned on the option "Prompt me when entering a blank edit summary" in their Edit preferences. The default is to give no warning.

In the course of an earlier discussion on a proposal to force new users to provide an edit summary, Kayau made a simpler and less drastic proposal to turn this around, by making giving the missing-summary reminder the default. Only registered users would then be able to turn the option off. The text of the reminder has now been adapted to allow for this change, making it more explanatory (and also more friendly in tone).

I hereby reiterate the proposal embedded in the earlier discussion: let us make prompting for a missing edit summary the default.  --Lambiam 08:50, 20 March 2011 (UTC)

• I think that this is a good idea. It would quickly introduce new Wikipedians to our culture of explaining edits (after which they could easily turn off the warning in their preferences), and potentially cut down on rapid vandalism edits without summaries by mandating an extra step in submitting an edit.--Danaman5 (talk) 09:21, 20 March 2011 (UTC)
• Strong support - I have always personally felt that es should be mandatory for everyone for all pages except perhaps their own user pages - so I agree wholeheartedly with the proposal to make an es prompt as the default. --Kudpung (talk) 09:32, 20 March 2011 (UTC)
• Strong support - edit summaries need to be the norm, especially for newusers. Mark^Dask 11:40, 20 March 2011 (UTC)
• Support, simple and hopefully effective. Thryduulf (talk) 12:49, 20 March 2011 (UTC)
• Neutral. A tiny step towards mandatory registration, ie. a net-good for us that also goes against some fundamental guiding principal about keeping things just as simple for new/unregistered users. Can't really bring myself to support or oppose. Equazcion ^(talk) 12:59, 20 Mar 2011 (UTC)
• Support... for edits to articles. --Anthonyhcole (talk) 13:06, 20 March 2011 (UTC)
• Support Don't know why this wasn't done years ago. And if somebody could fix it so I still get a reminder when I edit a section and don't put in a comment I'd be very grateful. Dmcq (talk) 13:45, 20 March 2011 (UTC)
• Support, about time... Rehman 14:13, 20 March 2011 (UTC)
• Support I am supporting this ~~Awsome EBE123 ^talk_Contribs 16:13, 20 March 2011 (UTC)
• Oppose - I originally supported this proposal, but on further reflection, I can't really support anything that makes editing more difficult. We're trying to justify this by making it sound like it has some huge benefit to newbies, but we all know the real reason it to make it easier for us to determine whether a new user is a vandal. One thing I should point out – if a vandal uses an edit summary, then we won't get the automatic "blanked page" or "replaced page with" summaries. Mr.Z-man 16:58, 20 March 2011 (UTC)

  While this is objectively true, if you look at a slightly larger picture I'd say that this will make it easier for newbies to make edits which are not reverted in a discouraging fashion. You can still very easily tell the difference between an edit for which the edit summary is an inconvenience (probably unconstructive) and one for which the edit summary is an "oh, I need to do that? Let's see..." (more likely to be constructive). We can very easily replicate the blanked/replaced autosummaries with tags from the EditFilter, if we don't already, which would actually be a productive step anyway as it would then be independent of whether the vandal is intelligent enough to add a summary. Happy‑melon 17:09, 20 March 2011 (UTC)

  It still sounds like the reason is "We're too rude and impatient. So instead of changing our 'revert first and ask questions never' approach, we're just going to make newbies do more work to make them prove they're not vandals." This makes things easier for experienced users by making things harder for new users. Editing is already confusing enough, let's not make it worse. Mr.Z-man 18:00, 20 March 2011 (UTC)

  I said something along these lines above already so I of course kinda mostly agree sorta -- You can always wax Machiavellian and twist a benefit to you into a benefit for them; There's always a way to do that. Wanted to add that I just tested the "reminder" feature myself and I see that the entire editing window reloads with the small one-line message on top. It's extraordinarily easy to miss, and if I hadn't been looking for it I probably would've just tried re-submitting the edit a few times thinking there was some sort of glitch. I think this'll generate a lot of new confusion. (I'd suggest a javascript popup message instead, but only if such a feature is absolutely needed). Equazcion ^(talk) 18:52, 20 Mar 2011 (UTC)

  Not all users may have popups enabled – I for one have them blocked in my browser preferences. Personally I wouldn't mind a much more attention-drawing delivery of this reminder (see the orange version in the middle of the discussion at Wikipedia:MediaWiki messages#Proposed change for MediaWiki:Missingsummary), but it was objected to: it was said to "shove this notice down people's optic nerves". If you reread the earlier discussion, you will see, by the way, that the "Machiavellian twist" has more than incidental support as an expected benefit – not for "us" or "them", but for the Wikipedia project.  --Lambiam 22:16, 20 March 2011 (UTC)

  Ordinary popup windows are different from javascript dialogs, and the latter is what I meant. While many people have ordinary popups blocked since it's a default for many browsers and security software, the people most likely to miss edit summaries are also least likely to have explicitly blocked javascript dialogs. As far as risk to the optic nerve, I think the message if implemented should be treated as important enough to warrant the forced attention so as to reduce frustration with tryign to figure out what went wrong with the initial edit. The current feature was created for the purpose of allowing users to voluntarily request a reminder, so they know to look for it; whereas this proposal is to present new users with a warning, a very different scenario that should implement a more noticeable message. Equazcion ^(talk) 22:28, 20 Mar 2011 (UTC)

  • Shouldn't page blankings be tagged regardless of the edit summary though? (Aren't they?) Rd232 ^talk 08:49, 21 March 2011 (UTC)
• Support. I also agree with Dmcq's "if somebody could fix it so I still get a reminder when I edit a section and don't put in a comment I'd be very grateful." --Philcha (talk) 18:12, 20 March 2011 (UTC)
• Support. Insignificantly more difficult, noticably less BITE in the end. If I'm a newbie and you'd like me to do something a particular way, don't wait and yell at me later, don't delete my article (even in a borderline case), help me do it right the first time. (As an aside? Do you want to make newbie's lives better? Put in *more* automation before accepting an edit, not less to give immediate feedback on edits rather than simply biting them a week, a month, or in the case of one of our backlogs seven and one-half years later because they've failed to read a couple dozen policies. The friendly path is not to have standards, it is to help newbies understand those standards with immediate, clear, constructive, supportive feedback.) --joe decker^{talk to me} 18:40, 20 March 2011 (UTC)

  For a new user, it's really not that simple. "Edit summaries" are a very Wikipedia-specific thing. To compare it to other sites, when you update your status on Facebook or comment on a blog post, you don't have to include a second comment explaining that your first comment was a comment. I've seen new users take our current instructions a little too seriously and write an entire sentence to summarize a single spelling correction. It probably took them five times longer to write the summary than it did to make the edit. We provide very little guidance except for the typical overly-complex "help" page at Help:Edit summary, which is more than 1,500 words. Mr.Z-man 23:10, 20 March 2011 (UTC)

  Wikipedia is not a social networking site so the comparison with Facebook is adrift. There may be social interaction here but its purpose is to build an encyclopedia. Everything we can do to ensure in the nicest and easyest way possible that people understand that goal, is a positive step forward - and that includes making edit summaries by default. I have never seen summaries of the kind Z-Man describes, but I have been infuriated by the thousands of blank ones. Pop ups works - (sometimes) depending on the speed of your connection. Kudpung (talk) 06:39, 21 March 2011 (UTC)

  The type of site is mostly irrelevant. What does being an encyclopedia have anything to do with edit summaries? All that matters is that its a site that the user contributes to. Unless they've contributed to another wiki running MediaWiki, they will likely have never heard of an "edit summary" before. And unless they've contributed to the English Wikipedia, they likely will have never seen such obsession over it. At least you're willing to admit that the main reason for this is to help experienced users first and foremost, not new users. Mr.Z-man 12:43, 21 March 2011 (UTC)

  For an example of overly long summaries by newbies, see [2]. I've seen more extreme, but this is the most recent. Mr.Z-man.sock (talk) 14:44, 21 March 2011 (UTC)

  Z-man, I don't doubt the existence of long edit summaries, and I'm sympathetic to not liking the way things are right now. But the place where someone doesn't enter an edit summary is precisely the moment to teach the user the one bit of information we'd like them to learn here. What I think would best address both our concerns would be for the the prompt screen to have a little more explanation, perhaps a couple of examples, and a lot less of anything else. Get rid of the article edit window on this page, it's not technically necessary (the data can be hidden). Get rid of the summary of the 50 transcluded templates (Transcluded? what's that? Template? What's that?) at the bottom of the page. Just tell them what we want, clearly, and given them a single box to enter that information in. That is constructive, supportive, and friendly.

  As far as the edit summary utility, in the course of processing PRODs and BLPPRODs I always check article history to sniff at it's history. Sometimes I find the article was entirely salvageable at some previous point in its history. It's simply not plausible to think that admins stare at the full text of every single edit before hitting delete, fewer edit summaries imply to me that I'm going to salvage fewer articles. I believe we lose a small number of otherwise salvageable articles this way, disproportionately those authored by new users, and I consider the BITE of unnecessarily deleted articles to be very high. --joe decker^{talk to me} 17:56, 21 March 2011 (UTC)

• Oppose per Mr.Z-man. Ruslik_Zero 19:54, 20 March 2011 (UTC)
• Support Unexplained changes are one of the banes of RCP, and this would encourage by education in advance, rather than chastisement afterward -- Boing! said Zebedee (talk) 20:04, 20 March 2011 (UTC)
  • The problem with RCP is that Hugglers are blindly reverting without bothering to ask the user why the change was made. Obviously, this would be easier with edit summaries, but if a new user has no clue what that is or doesn't notice the edit summary input box at first, there won't be an edit at all. /ƒETCHCOMMS/ 00:38, 21 March 2011 (UTC)
• Oppose per Mr.Z-man and because there are two cases here:
  • New users—why complicate things for them? I see new users who do use edit summaries and those who do not. What if they don't even see the little box for edit summaries (it sorta blends in ...)? They won't have any idea what the heck they need to do.
  • Experienced users—if someone doesn't want to use an edit summary, what the hell. You can't reason with some people. Ask them nicely, then forget about it. We should only change this option to default if policy mandates edit summaries, which it currently does not.

/ƒETCHCOMMS/ 22:42, 20 March 2011 (UTC)

• Oppose per Fetchcomms's view directly above. He is 100% correct; I really have nothing more to add. Guoguo12--Talk--  02:19, 21 March 2011 (UTC)
• Oppose Edit summaries are - frankly - not always useful. Let them be reserved for the occasions on which an edit really deserves a thorough explanation. What I might support is the addition of some kind of drop down box of "common edit summaries" like "spelling/grammar correction", "copyediting", "adding/removing content", etc. Dcoetzee 06:24, 21 March 2011 (UTC)

  Strange how opinions differ - I have always found edit summaries to be one of the features I look at most often. Perhaps editors who don't do NPP, RCP, vandal fighting, or checking for sockpuppetry, don't realise the huge advantage of just being able to scan quickly down a whole list of diffs on a log or history to see things that stick in they eye. Using popups is a pain, they stick on the page or are just too slow to use most of the time. Kudpung (talk) 06:52, 21 March 2011 (UTC)

• Oppose Waste of time. Having it switched on implies that all new edits by new users are trusted based on their edit summary. Only needs a smart vandal to add things such as "added reference", etc, to mask an unconstructive edit. Or worst still, just filling in the edit summary with a fullstop or other token character. Lugnuts (talk) 08:38, 21 March 2011 (UTC)
  • So, what on earth is stopping vandals from using edit summaries to hide their vandalism now? And why would it be a problem if they used a token edit summary? The goal behind this is not vandalism prevention, but reducing the number of good faith edits reverted. Yoenit (talk) 08:50, 21 March 2011 (UTC)
• Oppose as a gradual creep that makes editing more irksome without providing tangible benefits to the encyclopedia. This proposal is for the benefit of editors only - and it is of limited benefit. I sometimes find edit summaries useful when tracking down when or who added something to an article, however we have WikiBlame and WikiTrust for that, so they can be used instead. The other use is to prevent inappropriate edits with the notion that by making editing more difficult it will put people off editing. Yes. However, it will put off good editors as well as bad. Edit summaries are useful, but they are not essential. If I want to know what somebody has added to an article I use the "prev" button- that is far more accurate and reliable. I have sometimes found edit summaries to be misleading - (both unintentionally and intentionally) - and nobody makes (or should) a decision on reverting or leaving an edit stand purely on the edit summary. That a vandal says - "adding a reliable source" - should not be a reason for not looking at what the person has just added. SilkTork *^YES! 10:17, 21 March 2011 (UTC)

  I don't understand the sentiment behind "for the benefit of editors only". Isn't anyone who edits a Wikipedia article an editor? The proposal is meant to be for the benefit of Wikipedia. You may expect that the net effect will actually not be beneficial to our project, but please don't frame this in such a strange way.  --Lambiam 15:03, 21 March 2011 (UTC)

I see that my comment wasn't clear. Yes, anyone who edits a Wikipedia article is an editor. However, such people make up a small fraction of Wikipedia users. There are around 300,000 regular editors compared to 12 million daily readers. This is a proposal that isn't aimed to improve the reading experience, but is looking to make editing a little easier, therefore it is not a priority or high value proposal. Added to which, the value to the everyday editor is questionable - it would make editing more irksome for many, and its value in reducing inappropriate edits would be limited and possibly negative. In short, it's a low value, irksome and potentially negative proposal. SilkTork *^YES! 08:51, 22 March 2011 (UTC)

• Oppose per many of the concerns listed. I would add that, in minor edits such as fixing words, wikilinking, categorizing, adding or removing templates as needed, adding an edit summary may be more complicated than the edit itself. Usually, I only use edit summaries for actions that may seem questionable on first sight. Besides, there is another problem with edit summaries: users may use them to "discuss" between themselves, when they should do so at the talk page, so a mandatory use of edit summaries may increase the number of edit wars. MBelgrano (talk) 11:51, 21 March 2011 (UTC)
• Oppose Per Z-Man & Creep. ManishEarth^{Talk • Stalk} 13:30, 21 March 2011 (UTC)
• Support. The edit summary prompt needs to be a little bit better, in that it needs to have the edit summary box in the user's field of view when the enter-a-summary prompt is displayed, or something. Other than that, I understand the opposition, I just think that overall it's likely a net benefit. Herostratus (talk) 06:22, 22 March 2011 (UTC)
• Strong support—every edit on Wikipedia, whether making a minor typo correction or massively restructuring an article, should have an associated edit summary to allow other users to understand your intent in making the change. Too often on Recent Changes patrol I saw IPs or new users removing sourced sentences or sections—is this an attempt to remove something biased, something irrelevant, or just vandalism? Without a thorough understanding of the article and its sources it is often impossible to tell. Activating the blank edit summary warning for everyone with an opt-out for registered users would increase our ability to understand the intent of people's changes; users who really didn't want to provide an edit summary could just click submit again or leave an edit summary such as "x", but that alone might communicate to Recent Changes patrollers that their edits might be in less-than-good-faith. I personally use the tool and have found it very helpful in warning me when I have accidentally forgotten to provide an edit summary; I wonder how many IP and new users either just forget to provide a summary for their edits or don't realize that the edit summary function even exists? –Grondemar 12:32, 22 March 2011 (UTC)
  • You write, "Too often on Recent Changes patrol I saw IPs or new users removing sourced sentences or sections—is this an attempt to remove something biased, something irrelevant, or just vandalism? Without a thorough understanding of the article and its sources it is often impossible to tell." Well, the easiest way, and the best way, is obviously to ask. This is an excellent example of how we can promote communication with new users/IPs instead of blindly reverting, or staring confusedly at, an edit. /ƒETCHCOMMS/ 21:43, 22 March 2011 (UTC)
    • You can ask; my experience oftentimes has been that the IP never responds to the message on their talk page, and never repeats the edit. Does that mean their previous edit was vandalism, or did the person simply move on to a new dynamic IP, or perhaps they didn't understand the "You have new messages" orange bar and were frightened away from Wikipedia forever? Asking isn't reliable, and besides, it should be the obligation of any editor to provide at least some basic reason for their edit, rather than expect that later editors will chase them down to ask what they meant. This is especially true when looking at historic edits; even an active editor would likely be hard-pressed to remember why they made a particular edit after a year or two if they left no edit summary. Asking simply isn't reliable; prompting for justification upfront is. –Grondemar 03:58, 24 March 2011 (UTC)
• Comment - as proposer (sort of) I probably shouldn't put a 'support' in bold hence the 'comment. First, I think the 'blanked the page' point is adequately EditFilter. Secondly, I don't think we're 'robbing the newbies to help the experienced' by doing this - edit summaries are generally believed to be necessary for mainspace edits, especially major ones. However, the warning message at the present state, even after the change, may not be sufficiently newbie-friendly. For instance, where on earth is the edit summary field? How do I stop this bleeding thing from bugging me every time I leave out the edit summary field for minor edits? Also, the gadget could be disabled for minor and userspace edits. Kayau Voting IS evil 15:33, 22 March 2011 (UTC)
  • As for the edit filter, sure, we can do that, except the EF is essentially a limited resource. We can only have a set number of filters (sort of), why should we use them to do something that the MediaWiki software already does? We're already maxing it out on ~1% of edits. Anonymous users cannot mark edits as minor, so that change wouldn't help them. Mr.Z-man 22:17, 22 March 2011 (UTC)
    • I don't think it's right to discourage the use of edit summaries to trigger the automatic edit summaries. Maybe some people will not make the test edit they wanted to make if they realise that they're dealing with serious stuff here (since they're to give an edit summary). Plus, some vandals may put in edit summaries like 'I added some nonsense to/deleted(pseudo-deleted, for blanking) this page! Mwahahaha! I'm so evil!' That makes it even more obvious that it's vandalism. Only a through a trial run can my point be proven (in)valid though. Kayau Voting IS evil 14:59, 25 March 2011 (UTC)
      • Where did I say anything about discouraging the use of edit summaries? Not shoving our collective obsession over edit summaries in new users' faces when they're just learning how to edit is not the same thing as discouraging them from using them. It used to be we only expected high edit summary usage for admin candidates, and even then just for major edits. Now we want users to have 100% edit summary usage from their first edit? Mr.Z-man 21:18, 29 March 2011 (UTC)
• Support. Makes very good sense, and is, very simply, helpful. I don't agree with the objections that have been raised, since it is simply asking, in a helpful way, users to do things in a manner that is good for the project overall. Someone who feels strongly that they don't want to use an edit summary could still do so, and they would hardly be put upon to have been given the reminder. --Tryptofish (talk) 17:15, 22 March 2011 (UTC)
• Support, but in article pages only. Talk page entries and other pages shouldn't require an edit summary. StuRat (talk) 17:24, 22 March 2011 (UTC)
• Support - A sensible approach to encouraging more edit summaries which are helpful when patrolling recent changes, watchlists, and the like. Like Tryptofish, I also differ with those who feel that this would "complicate things" for new users. No one is being "forced" to do anything or made to jump through hoops should they choose not to provide an edit summary. They are merely being given a friendly reminder. Per StuRat, I also support the idea of applying the policy to article pages only.--JayJasper (talk) 17:42, 22 March 2011 (UTC)
• Support - After reviewing the many good arguments made through the course of this discussion, the benefits of such a system seem to far outweigh potential negative results. And personally, I always mean to include a summary but sometimes move too fast hitting the "Save" button, so an unobtrusive mechanism to help me in those cases would be appreciated  :) Doc Tropics 18:00, 22 March 2011 (UTC)
  • As an established user, this proposal would not directly affect you. The mechanism already exists for you to enable in your preferences. Mr.Z-man 22:17, 22 March 2011 (UTC)
• Strong oppose Not because I don't like edit summaries, but because this will discourage editing. You'd be surprised at the number of casual editors who won't bother to repeat an edit if it doesn't go through the first time. This is why vandalism filters cut down significantly on vandalism, even if a determined vandal can just ignore the warning. This might be equally effective at discouraging non-vandalistic edits. 169.231.53.195 (talk) 02:59, 24 March 2011 (UTC)
  • moved from wrong section Rd232 ^talk 15:30, 24 March 2011 (UTC)
• Oppose until I see evidence that there's a problem. Juliancolton (talk) 12:43, 24 March 2011 (UTC)
  • moved from wrong section Rd232 ^talk 15:30, 24 March 2011 (UTC)
• Strong support making the default preference to prompt for missing edit-summaries. This has many clear benefits (the main one being that it encourages people to include an edit-summary but does not force this in the [few] cases where it would be inappropriate or unnecessary) and no obvious downside, provided the prompt was clearly worded and there was an ability to alter this default situation via Special:Preferences for people who frequently need to save edits without a summary for a specific reason. And there aren't many of those. ╟─TreasuryTag►Chancellor of the Duchy of Lancaster─╢ 05:46, 24 March 2011 (UTC)
• Weak support if the reminder does not require the page to be reloaded (i.e. using Javascript) or a dialog to be dismissed; otherwise, weak oppose. Rd232 ^talk 15:45, 24 March 2011 (UTC)
• Weak oppose to making the default preference to prompt for missing edit-summaries. If someone doesn't want to write an edit summary the will just turn it down, or write meaningless edit summaries. For example if I used for this edits edit summary: "x", then it would be meaningless. Armbrust ^{WrestleMania XXVII} _{Undertaker 19–0} 22:30, 25 March 2011 (UTC)
• Support I'm fed up with seeing users not using the summaries. Near enough every person who edits on Tennis articles do not use an edit summery, so its really hard to see wheather something is a vandal act or not. Although I do see the point of the put a random word in to by pass it as being a problem KnowIG (talk) 22:42, 25 March 2011 (UTC)
• Support; failing that, revert the reminder text to the old version: the new one is too patronising if it only shows up to people who deliberately enabled it and hence presumably already know what edit summaries are good for. --A. di M. (talk) 12:04, 26 March 2011 (UTC)
• Conditional Support I've thought that this should be made the default for a long time now. That being said, the "You have not provided an edit summary..." notice is not very noticable at all, and I can see unfamiliar users missing this and getting frustrated when their edits don't go through. Therefore, I think that we should make the reminder much more prominent and noticable, before we entertain the idea of enabling it for everyone. It might also be worth investigating a redesign of the gadget, as someone has suggested below. A pop-up of some sort would be much better than reloading the entire page. --Dorsal Axe 16:39, 30 March 2011 (UTC)
• Support. Revision history is hard to sift through, and this will make that task easier, esp. for newcomers.  – OhioStandard (talk) 02:16, 1 April 2011 (UTC)
• Oppose Although I agree that edit summaries make it far easier to see what the editor was trying to achieve, I'm opposing per Z-man and Fetchcomms points. Noom _talk ^contribs 21:32, 1 April 2011 (UTC)
• Oppose. Sends away users who are doing small edits. Also per Z-man. Stickee (talk) 02:28, 2 April 2011 (UTC)

Oppose per Z-man. Not needed, one still needs to check edits regardless of summarizes. --Doc James (talk · contribs · email) 23:18, 3 April 2011 (UTC)

• Oppose from ceyockey — A part of me says "YES! do this", but that is the part which set the default on my configuration to prompt for edit summaries. I agree with those who argue that edit summaries are a hurdle which will turn away novice editors. Instead, I would suggest that some "good reasons for including edit summaries" be articulated for people who become relatively regular editors to encounter and adopt ... if they find those reasons good for them. Lead by example and expedience rather than by policy. --09:18, 4 April 2011 (UTC)
• P.S. from ceyockey — Using both Firefox and Chrome, I gain great benefit from previous entries in edit summaries being available for selection. In regard to 'minor' edits mentioned above, it is (almost) trivial to type "typo" or "copyedit"; more complicated edit summaries like "added x-ref to es.wikipedia", for instance, are easy to add when the autocomplete features of firefox or chrome are available. --09:24, 4 April 2011 (UTC)
• Support, it surely won't save the world, but surely the time of an editor every now and then. Believe me, it's really not that difficult to write a short summary, I mean, there's no problem using abbrevations and the like... --The Evil IP address (talk) 18:45, 4 April 2011 (UTC)
• Support for edits made in article space, per my comment at the previous proposal. RashersTierney (talk) 13:49, 6 April 2011 (UTC)
• Oppose – Mr.Z-man sums it up very well; essentially, it defeats the purpose of AES, which is fairly useful most of the time, and helps with removing vandalism. —mc10 (t/c) 23:33, 7 April 2011 (UTC)
• Strong Oppose Having this nagging feature will frustrate new users and turn them off from the English Wikipedia just because they are not entering edit summaries. We want to encourage new editors, not nag them. Logan _Talk ^{Contributions} 20:26, 9 April 2011 (UTC)
• Strong support - absolutely. It's not too much to ask, for a little short comment on each edit - I really don't think it would discourage anyone - and, they could just click again and ignore it. The potential benefit is huge. New users would get the idea of good practices from day 1, and they'd not get a warning about failing to use edit summaries. It's not nagging; people are perfectly accustomed to having to fill in similar boxes when saving a page on other websites. And we are not insisting on it. This should be the default; absolutely.  Chzz  ►  21:14, 9 April 2011 (UTC)
• Strong support - this will make anons and new users more likely to use edit summaries - which will make the good edits less likely to be reverted, make it easier for Edit filter false positive reports to be handled better, etc,. עוד מישהו Od Mishehu 06:46, 11 April 2011 (UTC)
• Weak oppose Originally I intended to "click link" ... "!vote support", but in reading the existing persuasions, I tend to agree with Mr. Z-man. To be honest, the only time these edit summery things seem to generate any impact whatsoever to the project is when (1)Someone vandalizes, (2) Someone gets uncivil or delves into a personal attack, or (3) We look for something to complain about at RfA. They (edit summaries) can be a nice touch, but hardly something that really adds much to the project that everyday people read. — Ched :  ?  01:57, 13 April 2011 (UTC)

Trial?

May I propose we figure out a way to trial this for a bit? Perhaps enable it for 50% of new accounts created for a few days and then compare % of edits reverted, average number of edits and number of editors still active. That way we would actually have statistics to back up this idea, rather than just assumptions. I am honestly unsure whether this is a good idea, but it definitely has enough support to warrant further investigation. Yoenit (talk) 08:50, 21 March 2011 (UTC)

Either that or simply turn it on for a month and see the impact it has on the inclusion of edit summaries and the number of IP and new edits. I sincerely doubt that this is going to have any significant negative impact. –Grondemar 12:32, 22 March 2011 (UTC)

There seems to be enough to support to begin duscussing a trial, but wouldn't a 30 day trial on all accounts be more useful? There's no question this can help experienced editors as much as newcomers. Doc Tropics 18:00, 22 March 2011 (UTC)

• Strong support for a trial. But, per comments in the next two threads, the "prompt" that we trial should not be the present one (which involves reloading the entire page) but a small box saying "Please enter a brief description of your edit in the field below or select a description from the drop-down menu." And a "skip edit description" button. --Anthonyhcole (talk) 09:59, 24 March 2011 (UTC)
• Support More edit summaries = Less bitey-ness. --Cybercobra (talk) 04:40, 27 March 2011 (UTC)
• Modify. Prompt for an edit summary, but not every time. Either do this conditional on missed summaries in an editor's first [50 edits], perhaps until auto-confirmed even, and then stop it. Or, at point x, only prompt for blank summaries [25%] of the time, decreasing as the number of edits/time editing increases. Ocaasi ^c 21:24, 31 March 2011 (UTC)
• Strong Oppose Often an unnecessary hassle. We really shouldn't be going out of our way to make editing less convenient. Abyssal (talk) 03:33, 1 April 2011 (UTC)
• Support: anyone wanting to edit an encyclopedia should be willing to spare a few keystrokes to explain what they are doing. It will help us to support new editors, and help them to understand what has been done to their work by later editors. (In fact I'd happily see edit summaries made compulsory!). PamD (talk) 18:53, 2 April 2011 (UTC)
• Oppose - I am seeing a lot of opposition to this, moving forward with a trial without consensus would be unethical. Sven Manguard Wha? 18:21, 3 April 2011 (UTC)
• Oppose per Sven; no real consensus for a trial. We should work toward a redesigned system as discussed elsewhere (popup prompt, selection box, etc.) first. /ƒETCHCOMMS/ 23:52, 3 April 2011 (UTC)
• Support a trial. But not just a "flip the switch and see what happens" trial. I think we should be very particular about it, and redesign the gadget to suit the trial better. It should only affect mainspace edits, and we should consider only doing this to users who do not leave edit summaries often. Both excellent points/ideas raised above. --Dorsal Axe 16:07, 5 April 2011 (UTC)
• Oppose the benefit is so small, the risk big... Do not support a trial.--Doc James (talk · contribs · email) 13:42, 6 April 2011 (UTC)
• Is there actually any reason to believe that any trial will actually turn out to be a trial? "Trial" doesn't really mean much since PC... --Yair rand (talk) 21:34, 6 April 2011 (UTC)
• Oppose – Absolutely not, if it isn't supported above, a trial shouldn't start. —mc10 (t/c) 23:35, 7 April 2011 (UTC)
• Strong Oppose See above. Logan _Talk ^{Contributions} 20:26, 9 April 2011 (UTC)
• Strong support - sure - if the proposal doesn't succeed - why not? Why can't we just give it a try, see what happens? As long as the trial is for an absolutely, set-in-stone, fixed time - at the end of which, regardless, it'd be turned off. And then we could discuss it again, evaluate the results - before working up a fresh proposal.  Chzz  ►  21:14, 9 April 2011 (UTC)
• Support - I like the trial idea- I'm not sure yet if I am on board with the proposal, I would like to see if it makes a difference first. Or see if new users find it to much of a hassle and take off.Nightenbelle (talk) 19:16, 10 April 2011 (UTC)
• Oppose And oppose a trial as a means to "convince" the opposition. We don't need another trial with a pinky swear end date. Trials should be reserved for ideas that have general community consensus but a lack of clarity on the implementation details. I don't see a benefit from requiring edit summaries and I'm frustrated by the continual insinuation that wikipedia needs to deal with its shrinking editor base by adding to editing friction. Protonk (talk) 17:04, 12 April 2011 (UTC)
• Oppose While trials may appear good on paper, and in theory, in practice they seem to generate more heat than light. — Ched :  ?  01:57, 13 April 2011 (UTC)
• Strong oppose A lot Wikipedia's best contributors often don't use edit summaries, User:Tony1 comes to mind. Edit summaries help, but sometimes it's hard to properly summarise an edit. —James ^{(Talk • Contribs)} • 10:01pm • 12:01, 18 April 2011 (UTC)

Addendum: nudging

Moved to separate section, under #Dropdown of common summaries. Rd232 ^talk 15:40, 24 March 2011 (UTC)

Addendum: update notification scheme

Moved to separate section, under #Reminder design. Rd232 ^talk 15:40, 24 March 2011 (UTC)

Improving edit summary use

Note: these sections were originally part of the "prompting for edit summaries by default" discussion above, but the inclusion there was starting to cause confusion. Rd232 ^talk 15:40, 24 March 2011 (UTC)

Dropdown of common summaries

What about providing a dropdown with a range of common edit summaries below the edit summary box? This would help new users figure out what they're supposed to do, and would also help make edit summaries less cryptic for people reading them. (If it's as quick to add a standard "Grammar correction" as to type "gr", surely that's more accessible for newcomers.) [In case it's not clear, this suggestion involves no compulsion to use the dropdown, merely to make one available for use.] Rd232 ^talk 08:49, 21 March 2011 (UTC)

• Support. Encouraging editors to make edit summaries is a good thing for the encyclopedia, helping editors make edit summaries is even better Murray Langton (talk) 09:46, 21 March 2011 (UTC)
• Support. I Suport the 'dropdown with a range of common edit summaries' idea from above. IPs would be compelled to use them, but newbies and registered users should be let off with a few misses on bussy pages (like those on the resent Egyptian rebelion). Wipsenade (talk) 10:00, 21 March 2011 (UTC)
• Support. This is a good alternative to the above proposal given the concern about making it harder for newcomers to edit.--Danaman5 (talk) 11:35, 21 March 2011 (UTC)
• I would support this. Perhaps we should also consider giving a little more emphasis to the edit summary (bold text, larger text, colors, etc.) area as well. As Fetchcomms noted, it can be missed in all the other text around the edit box. Mr.Z-man.sock (talk) 14:50, 21 March 2011 (UTC)
• Support as well, if made obvious what it's for, so new users understand what to pick if they want to (maybe start with a default of "what did you change? (pick below or type it in)" sort of thing). This isn't going to get around the "vandals using false edit summaries" and "no automatic edit summaries" problem but it seems like a reasonable compromise—especially if it's on by default but users can still turn it off in their preferences. /ƒETCHCOMMS/ 15:01, 21 March 2011 (UTC)
• Support whether or not we decide to prompt, etc. This suggestion is quite elegant, really, this has the value of both making it easier to enter a lot of edit summaries, and teaching by example. --joe decker^{talk to me} 18:03, 21 March 2011 (UTC)
• Support. I still support the default-to-mandatory-summary proposal above with or without this, but this would be a good idea if the default-to-mandatory-summary proposal is accepted. (If the default-to-mandatory-summary proposal is not accepted, this dropdown-box suggestion becomes less useful or important and perhaps not worth the effort, since the only people who ever see it would be users who have specifically turned on mandatory-summary.)
  • "the only people who ever see it would be users who have specifically turned on mandatory-summary" - no, the dropdown would be shown to all, regardless of whether a summary is mandatory. (Possibly with the option to hide it in preferences, if people want, but certainly shown by default.) Rd232 ^talk 10:15, 22 March 2011 (UTC)
• Comment - I've seen a similar mechanism used in some wikia wikis, where you can choose the type of edit summary you're using. I'm not sure how it exactly it works and whether newbies in EBTHK use edit summaries more often, though. Kayau Voting IS evil 15:36, 22 March 2011 (UTC)
• Support whether or not we do the above. It would even be helpful to experienced users. --Tryptofish (talk) 17:15, 22 March 2011 (UTC)
• Support - per rationale of proposer and others expressing support. Helpful to new and experienced users alike. Should be implemented regardless of the outcome of the "prompt" disussion above.--JayJasper (talk) 17:50, 22 March 2011 (UTC)
• Support - on its own merits, either in addition to, or independent of, the above proposal. This seems a good ides either way. Doc Tropics 18:00, 22 March 2011 (UTC)
• Against (but with an alternative that I would support) - I'm an experienced editor who almost never logs in. I supply edit summaries almost all the time. A "dropdown" sounds like a list of choices I'd be forced to select from, and I want to have the option of customizing the summary. What I would support is an expansion of WP:Automatic edit summaries by generating a default edit summary based on an analysis that is similar to what Special:Tags does. If I don't replace the default, it becomes the summary; if I don't supply an edit summary, the default becomes the summary. 67.100.125.139 (talk) 02:11, 23 March 2011 (UTC)
  • Well I guess I wasn't clear enough: I envisaged a dropdown below the edit summary box, where selecting it would enter the text into the edit summary box. You could therefore ignore the dropdown for the many cases where a standard summary isn't appropriate, or possibly use a standard one and then customise it. Rd232 ^talk 12:27, 23 March 2011 (UTC)
• Support the dropdown menu but the dropdown options must be very carefully thought through. --Anthonyhcole (talk) 10:14, 24 March 2011 (UTC)
• Comment. I want to see how it will look like before I support/oppose. Ruslik_Zero 15:05, 24 March 2011 (UTC)
• Mild oppose In reviewing my lengthy watchlist (>4000 articles), I find the lack of an edit summary a good clue that an edit should be checked. I don't have time to review every edit, so this is a useful filter. Vandals almost never provide an edit summary so why prompt them to do so?--agr (talk) 15:46, 24 March 2011 (UTC)
  • Well I could be wrong, but I suspect it's a pretty small minority of vandals who would be nudged by the existence of a dropdown to use a false edit summary, but aren't sophisticated enough to do it without that. Certainly understanding the significance of a missing edit summary is rather more advanced than most vandals get. (BTW You're not mixing this up with the "prompting" proposal above are you?) Rd232 ^talk 18:37, 24 March 2011 (UTC)
• Comment—This would only work for me if the list was short and concise. I don't want to have to chase down the reason in a long menu with verbose entries because it would be faster to just type in a brief message.—RJH (talk)
  • Well the list would be populated from an editable MediaWiki page, so we could do whatever we want; the list does need to be easily navigated or it won't be much used. And I've idly wondered if it would be possible to use keyboard shortcuts somehow. Rd232 ^talk 18:28, 24 March 2011 (UTC)
• Support An added benefit is that we can run bots to make, for example, statistics regarding edit summaries, so will have a better understanding of the editing process. Suddenly the information in the summaries gain more structure. Randomblue (talk) 06:41, 25 March 2011 (UTC)
• Support This is a boon for every editor and it may establish a de facto standard for writing edit summary. I still have no idea whether we should use sentence, infinitive or participle for edit summary.--Netheril96 (talk) 17:19, 25 March 2011 (UTC)
• Oppose—this simply overcomplicates matters. What is a 'common summary'? There's an infinite variety. And this would open the floodgates to misleading summaries, by accident or by design ("Oh, sorry, I meant to click rm but ended up choosing added refs...") ╟─TreasuryTag►Captain-Regent─╢ 07:29, 26 March 2011 (UTC)
  • "What is a 'common summary'?" - anything Wikipedians have evolved abbreviations for in edit summaries. "There's an infinite variety." - yes, but the dropdown is supposed to provide common edit summaries. As to accidental clicking: the dropdown should add its text into the edit summary box, so that merely clicking the wrong thing in the dropdown doesn't submit the wrongly chosen edit summary (i.e. you have the chance to amend it). Rd232 ^talk 10:55, 26 March 2011 (UTC)
• Oppose per WP:PEREN#Automatically_prompt_for_missing_edit_summary. Choosing a (perhaps randomly selected) edit summary would suppress critical WP:Automatic edit summaries. Also: Why would I need this? Firefox, at least, has this functionality built in. Every edit summary I've used is automatically available to me; all I need to do is to start typing. You will, for example, find that the edit summary "One list of multiple items, rather than multiple single-item lists, per WP:ACCESS#Lists" appears repeatedly throughout my contributions. I assure you that I'm not typing that out every time. WhatamIdoing (talk) 17:18, 26 March 2011 (UTC)
  • What are the chances of a blanking test edit having a 'fixed typo' summary? ;-) Not too big IMO. This is just to tell good faith newbies about it, not make it more convenient for experienced editors. Kayau Voting IS evil 17:23, 26 March 2011 (UTC)
  • Whilst that's useful for experienced and high-volume editors, (a) that's not the main target market here (b) it doesn't work very well for section editing, since the section name is part of the edit summary field and so the browser doesn't recognise it unless it happens to be a common section name and you've previously used the edit summary you're going for in a section of that name. Rd232 ^talk 04:52, 27 March 2011 (UTC)
  • Re the Automatic Edit Summaries - AFAIK that currently watches for blank edit summaries on submission of the page; in principle it could check for Common Summaries too, and override it or add the "blanked the page" etc. Also I've wondered in the past if it shouldn't just label all summaries, like that at least for the key "blanked page" and "replaced all content" ones. I also wonder if some interaction with the edit filter tag system is out of the question, so the Auto Summary software could record a "blanked page" tag. Rd232 ^talk 05:05, 27 March 2011 (UTC)
• One demerit of this proposal is that one may no longer be able to hit tab to get straight to the summary field. Kayau Voting IS evil 17:23, 26 March 2011 (UTC)
  • Well that's something to watch out for, but the tab order it depends on how the 'tabindex' property works out in the HTML. I'd imagine the dropdown below the edit summary field (so tabindex higher and tab goes to edit summary field first), but tabindex can also be set manually in HTML (not quite sure how this would be done in MediaWiki, but where there's a will...). Rd232 ^talk 04:58, 27 March 2011 (UTC)
• Comment (I do apologise if I've missed it posted by someone else). In some wikis, like Russian, right below the summary field there's a row of buttons like wikification, spelling, using which one can easily describe the changes. Shouldn't it be better than a dropdown menu (where, as I conjure up, only one option can be chosen)? --Microcell (talk) 17:33, 26 March 2011 (UTC)
  • Ah, I see, that's nice that something quite similar is already in action. I have to say though that whilst it might be easier to sell that button approach (eg you're not the first person to think the dropdown would restrict you to one option - but it need not, it would work just like the buttons in terms of adding text into the edit summary field), I think the dropdown could work better in terms of making it clear to newcomers what's going on, because you can have a description of the dropdown within it, rather than needing to take up space next to the buttons. (The Russian WP foregoes a description.) In addition, the button approach encourages short single words, whereas I'm envisaging at least some of the common summaries being slightly longer, more helpful phrases. Rd232 ^talk 04:52, 27 March 2011 (UTC)
    • Yeah, I see your point. The idea is to make the design handier in terms of the number of pressed buttons - in this instance, the aforenamed row is at an advantage to the detriment of detailed explanations (or the menu mustn't drop down - then it's all right, but too much place is taken up). So, maybe it's better to invent something like a button row with full descriptions emerging as a mouse cursor is placed over the respective option? --Microcell (talk) 12:05, 27 March 2011 (UTC)
• Support - this would work similar to the deletion screen (non-admins can see a screenshot of that here) - if you leave it at "Other reasons", it inputs nothing into the final result. עוד מישהו Od Mishehu 08:18, 28 March 2011 (UTC)
• Support for a very limited range only. This would help to address the problem of too many blank edit summaries. However, I agree with TT that there are too many variants to attempt to cover every common scenario. Using a very small range - say just "rvv", "spelling fix", "link fix", "grammar" and "added references" to start with - would give the most benefit for the least risk. Alzarian16 (talk) 09:19, 28 March 2011 (UTC)
• Support -with the first 'option' being blank; this wouldn't make it any harder for people who want to use the standard options, would make it a lot easier for people who like to customise all the time, and would make 'no summaries' stand out from the crowd. Pesky (talk) 05:39, 29 March 2011 (UTC)
• Support, but how about checkboxes instead of a dropdown list? I'd like to be able to tick several boxes for things like "fixed spelling", "fixed grammar", "revert vandalism" etc. These checkboxes could append or pre-pend the abbreviations (e.g. "sp", "gr", "rvv") to the edit summary you would additionally/optionally type in. Zunaid 17:11, 30 March 2011 (UTC)
• Support: if it makes it quick and easy for experienced editors to add less cryptic edit summaries, (and if said editors take advantage of this!) this will help new editors and make WP more welcoming to them. Checkbox idea is appealing, too, for multi-job edits. PamD (talk) 18:49, 2 April 2011 (UTC)
• Support – Definitely, this is a very nice way to select common edit summaries without having to abbreviate something as rvv or the like. —mc10 (t/c) 23:36, 7 April 2011 (UTC)
• Support (with a bit of a shrug) — Ched :  ?  02:54, 13 April 2011 (UTC)
• Support Yes, it gives new editors an idea of what edit summaries are and saves time for experienced editors. Though I suppose we need to determine how many and what options the list should include. Zlqq2144 (talk) 23:42, 17 April 2011 (UTC)
• Conditional Support So long as it doesn't override the auto edit summaries. —James ^{(Talk • Contribs)} • 10:11pm • 12:11, 18 April 2011 (UTC)

Reminder design

I think the missing edit summary warning would get a lot more use if it was designed better. I used to use it but it slowed me down too much, so I disabled it. Here's what I don't like about it: If you forget to enter an edit summary, the entire edit page still gets submitted, and then the entire edit page gets reloaded with the warning, and then you enter your edit summary and submit again. If you're on a slow connection and/or editing a large page and/or WP servers are slow that day, the last thing you need is to wait for the entire edit page to load again just to display a warning. Why couldn't we change it so that a dialog alert box pops up and says "You haven't entered an edit summary. Are you sure you want to continue?" with an OK and Cancel button. Or, even better, a dialog alert box with a similar message, with a field where you can type in an edit summary, hit OK, and be on your way. I think we could get a lot more support for prompting for the missing edit summary by default if the prompt itself was less intrusive and annoying. —SW— ^gab 15:39, 21 March 2011 (UTC)

I don't know about more support, but it would be worthwhile objective in itself. Can we Javascriptise it? Rd232 ^talk 16:50, 21 March 2011 (UTC)

This is kinda where my brain was heading too. While I'm not sure that popups will work across all browsers/platforms, I'd think it would be possible to load a new page that only displayed the question, instructions, etc., and an edit box, and carried along any other form data we need to pass on (in particular, the article edit) as hidden data. This would take a lot less time to load, but would eliminate a huge amount of the distractions, which I think is one of the bigger sources of cognitive load affecting usability here. --joe decker^{talk to me} 18:10, 21 March 2011 (UTC)

I think it's important to find a solution which doesn't involve loading a new page. Just about any Javascript-enabled browser would be able to display a simple alert box. If you're using a browser which doesn't support JS, then you're losing a lot of functionality on Wikipedia. I'll see if I can find some time to try creating something in js. —SW— ^squeal 18:58, 21 March 2011 (UTC)

This also would be fine, in my opinion. Either the drop-down list (suggested in the subsection above) or this idea, where the edit summary box is directly in the user's field of view, are fine and probably more or less equally good. Either one is much preferable to the current system where you have to go hunt for the edit summary box, and which we must upgrade if we are going to turn on default-edit-summary-prompting. Herostratus (talk) 06:39, 22 March 2011 (UTC)

"Either one"? I think we should have both, regardless of what happens with default-prompting. Rd232 ^talk 10:17, 22 March 2011 (UTC)

• I took a look at the situation, and I believe it would require a MediaWiki update in order to allow a javascript to do this. The edit form's HTML needs to have an "onsubmit" parameter to call a javascript function when the user clicks Submit. That javascript function would pop up the alert box if there was no edit summary, and then proceed from there. Currently, there isn't a way (that I know of) to make this happen without some level of developer support. —SW— ^communicate 22:10, 23 March 2011 (UTC)
  • Well that's doable, nonetheless; it's not really hard. I would say though it should not involve an alert or dialog or anything like that. For instance, it could be some red warning text which appears below the edit summary if you click "save page" with no edit summary text (ignoring preloaded /* */ section part, if present), unless the warning's already visible, in which case it saves. Rd232 ^talk 15:54, 24 March 2011 (UTC)
    • I'm pretty certain it already exists. See Wikipedia:WikiProject User scripts/Scripts/Force edit summary. Reaper Eternal (talk) 20:13, 25 March 2011 (UTC)

Comments

Is it possible to also add edit summaries to new sections ? Just because you can enter a title doesn't mean that you don't want to enter a larger summary. (applies to pages where there is a new section button/tab) 65.93.12.101 (talk) 06:36, 25 March 2011 (UTC)

You can't add a fuller edit summary if you use the add section button, but you can edit the full page and add a new section at the bottom of the page with a full edit summary. GB fan (talk) 20:41, 25 March 2011 (UTC)

Let me clarify: Is it possible to ADD FUNCTIONALITY to allow edit summaries when you create new sections ? (also, editing the entire page cause problems with very large pages, and edit conflicts in general, since every edit will now conflict with you.) 65.93.12.101 (talk) 02:13, 26 March 2011 (UTC)

The software currently doesn't allow it - but you can request it, see Wikipedia:Bug reports and feature requests for how and where. עוד מישהו Od Mishehu 08:21, 28 March 2011 (UTC)

Wikipedia:Votes for Highlight

I want this page to be official.

I have the VFH page suggested code (With 1 example nomination!)

VFH Draft

VFH overview

All nominations

Feature queue

Recently featured

Recently failed

Archive

Rules

Welcome to the Wikipedia Votes for Highlight page. To nominate an article, type the name into the box below and follow the directions.

• Vote for an article you find excellent.
• Previous featured articles can be found in the VFH archive.
• Voters: be constructive with criticism. Writers: Be open to criticism.
• Articles from all namespaces (including Main, Wikipedia, Category, Book, etc.) are eligible for VFH.
• If a nomination disappears from this page, it is likely to be found in either the recently featured or recently failed nomination lists.
• If your article doesn't get featured, don't despair. It may be eligible to be a Good Article so long as it meets certain criteria.

VFH contents

• Nominate
• All nominated articles
• See also

Nominate

Self-nomination regulation: self-nominated articles (i.e. you write an article and then decide to nominate it yourself) must receive at least one critique via Peer Review before nomination. Articles nominated by people other than the author can still be nominated at any time and require no review.

VFH is not a discussion page. If you'd like constructive criticism for your article, please submit it to Wikipedia:Peer Review.

All nominated articles

Wikipedia:Votes for Highlight

Score: 1 vote for highlight

Support. A totally awesome Wikipedia page James1011R (talk, contribs, log, boxes) 17:12, 1 April 2011 (UTC)

Talk About Proposal

NOTE: This is a serious proposal, not a April Fools Joke

I would like to use the new VFH soon. James1011R (talk, contribs, log, boxes) 17:12, 1 April 2011 (UTC)

What is this? a proposal to replace wp:Featured Article Candidates? or is it supposed to run parallel to our current grading scheme? Yoenit (talk) 17:31, 1 April 2011 (UTC)

It is supposed to run parallel to that James1011R (talk, contribs, log, boxes) 17:32, 1 April 2011 (UTC)

What would be criteria for a "highlighted page"? Yoenit (talk) 17:36, 1 April 2011 (UTC)

Currently the same as for a featured or good article (It also gets marked as such) but that could change. James1011R (talk, contribs, log, boxes) 17:39, 1 April 2011 (UTC)

If they use the same criteria, why would need an additional process? Is something wrong with FAC/GAN? What are the advantages of this proposal? Yoenit (talk) 17:44, 1 April 2011 (UTC)

The Advantages of WP:VFH over WP:FAC and WP:GAN

1: No more submitting articles to WP:FAC and then finding out it's only a good article and then being forced to submit it to WP:GAN!
2: Support for all namespaces (WP:FAC and WP:GAN only support the main namespace)
3: Awesome header
4: No more confusion with the two pages!
5: Score meter that is required to be updated for each vote. (i.e. +1 for Support, -1 for Oppose)
6: Archives
7: Much better name
8: An overview. WP:FAC and WP:GAN do not have one.
9: Ergonomic look
10: You can brag about WP:VFH successful nominations, unlike WP:FAC and WP:GAN
James1011R (talk, contribs, log, boxes) 18:05, 1 April 2011 (UTC)

So is this basically a "Like" feature, i.e., someone can "Like" a page on Facebook? WhatamIdoing (talk) 18:45, 1 April 2011 (UTC)

(edit conflict) "Awesome header" does not convince me this is a serious proposal. Your other advantages are just as bad. The only one worth commenting on is number 2: Images, Lists, Sounds, Portals, Topics can already be featured, and featured content in the other namespaces (talk, wikipedia, cat, user) makes no sense. I also get the feeling you are suggesting a form of popularity contest, which is a very bad idea. Yoenit (talk) 18:51, 1 April 2011 (UTC)

• Oppose FAC and GAN work fine, the last thing we need is a third/fourth (if you count A-class) review process. --Jayron32 19:02, 1 April 2011 (UTC)
  • Comment I thought there was no A-Class nomination thing. Well, WP:VFH does A-Class too!
    • There are currently about 800 A-class articles. It is the top of the scale for the assessment system controlled by the WP:1.0 team. Consequently, it is awarded by WikiProjects, not by outside processes (FA, GA, FL, etc.). Most WikiProjects do not bother with it; MILHIST does the most, and you can see theirs at Category:A-Class military history articles. WhatamIdoing (talk) 19:33, 1 April 2011 (UTC)
• Support This is a human-usable version and is also a very powerful tool as a template is required to be put on the article (It's part of VFH process!) automatically categorizing the page under VFH nominees James1011R (talk, contribs, log, boxes) 02:15, 2 April 2011 (UTC)
• Strong Oppose To be blunt, it's a useless and arbitrary system, which from my perspective, exists only to allow people to inflate their own egos. I see plenty of potential for antagonistic behavior and chaos, and no potential for this to be a constructive addition to Wikipedia. Sven Manguard Wha? 20:14, 2 April 2011 (UTC)
  • Comment Score is a poor indicator to if the article will pass VFH. The actual FA/GA/A-Class guidelines and the discussion have more weight. --unsigned comment by James1011R
    • I don't care what metrics you use, what I object to is that you're seeking to create what is ultimately a poorly defined process with an unclear scope and no benefit to the project. FA/A/GA/FP/FT/FL/FS/FPortal all recognize or 'highlight' the best content. They have much, much better defined metrics and a clearer sense of purpose. I see this as becoming another "Valued Pictures" type process, i.e. where second rate content is given a near useless stamp of approval by a group of editors that favor idealism over experience, practicality, or quality. And that's the best case scenario. The more likely scenario is that it'd get hijacked by an egotistical and insular group of people interested only in scratching their own and each others' backs. Sven Manguard Wha? 20:49, 2 April 2011 (UTC)
      • Important There are rules for VFH, just they haven't been developed yet. It is possible to vote to delete nominations made in bad faith, to increase someone's ego, or made as jokes. VFH is an extremely powerful tool and should only be used on truly excellent articles (i.e. ones that exceed the Featured article criteria [Ones that meet the criteria are WP:FAC content]). James1011R (talk, contribs, log, boxes) 21:04, 2 April 2011 (UTC)
        • Do you understand why I believe that your unsupported assertions that something "should" be this way represent wishful thinking? Do you understand the difference between "should" and "will"?
          Let me tell you about the dancing bears problem:[3] Imagine that you run a business, and you tell all of your users, "You may get e-mail promising you a video of dancing bears. DO NOT click on the link. DO NOT watch the video. It's a computer virus and will destroy your computer." Do you know what happens if the users receive this e-mail? Nearly all of them click the link. Nearly all of them care more about the possibility of fifteen seconds' fun than about protecting their computer. You told them they should absolutely not click on this link, but the users do not do what they should. The users do what they can. If you're in charge of the IT infrastructure, your only effective protection is to design a computer system that makes it impossible, or at least extremely difficult, for the users to click on the dangerous link.
          You have designed a process that as designed has people doing nothing more than voting for articles, with the implied promise that if enough people vote for the article, they'll be rewarded with a main page link. You can keep saying "Only vote for articles that are really excellent" until you're blue in the face, but you have designed a system that cannot stop someone from voting for an obviously lousy article as a joke, or because it's about the person's favorite musician, or any number of other stupid reasons -- or, indeed, because the person has absolutely no clue what is considered an excellent article -- and that rewards them for voting for these articles. Maybe they "should" vote only for really excellent articles, but they will vote for whatever they like. This is a Bad Idea. No matter what it "should" do, it will reward subject-matter popularity rather than excellence. WhatamIdoing (talk) 21:31, 2 April 2011 (UTC)
• Comment I think VFH will appeal to different users than FAC or GAN. It could work out the way it should. And this page has been nominated for VFH. James1011R (talk, contribs, log, boxes) 23:03, 2 April 2011 (UTC)
  • (edit conflict) Very well put WhatamIdoing. I suppose one other thing that needs mentioning is that this goes against the grain of what a good encyclopedia is. A good encyclopedia is a comprehensive, high quality reference work. Those are the three core traits: It covers all or almost all things notable, it is of a sufficient quality as to be useful (this also means it's factual and neutral), and it it is composed of freestanding units of information (articles) that can be accessed individually. No where in that definition does popularity, political correctness and acceptability, degree of mainstream versus esoteric, or comparative value come into play. The featured assessments all follow this definition. If you look at them, they check for quality, neutrality, reliability, and their ability to stand alone. They strive to use objective, rather than subjective, means of assessment. Your system relies on subjective assessment, the "I want this" factor. Well there is a heck of a lot of things I want and a heck of a lot of things I don't want, but that does not factor into my assessments of featured content. I personally hate Christmas carols (worked service sector, heard them for four months straight, it got nauseating,) but that wasn't grounds for me to oppose them when some appeared as Featured Sounds candidates. Wikipedia cannot accept subjective rating systems, it would make rating worthless, and it would destroy the credibility of the project. Sorry, I know this seems like I'm going on a rampage here. I have nothing against you personally, I am just making these comments because I believe it's what's best for the project. Sven Manguard Wha? 23:13, 2 April 2011 (UTC)
    • One more thing: For the future, it's not a good submit an idea until it's fleshed out. You're asking us to approve something that we know at most a third of the details of. Things can be changed once the idea is submitted (as requested by the community) but going in with a proposal that isn't finished makes people nervous about supporting it. Sven Manguard Wha? 23:16, 2 April 2011 (UTC)
      • I would have stated the rules, but I believe that would get me blocked for taking a proposal too far. The Feature queue, Recent features, and Recently failed are of no purpose until VFH is actually being used. The awards need a great image designer to create. I have the overview, nominations, archive, and VFH nomination template (why isn't it here yet?) done. James1011R (talk, contribs, log, boxes) 23:28, 2 April 2011 (UTC)
• The suggested interface/header looks atrocious. The thought process behind it doesn't seem any better. Killiondude (talk) 03:05, 3 April 2011 (UTC)
• The listed benefits are, frankly, nonsense. How can non-articles meet the same criteria as FAs or GAs which are inherently designed for articles? A score meter sounds like a terrible idea. An ergonomic look? The comments put forth by the proposer seem to be contradictory. In the initial proposal he states "VFH is not a discussion page", but in response to a comment by Sven states "guidelines and the discussion have more weight" - which is it? Is there no discussion, or does the discussion have more weight than the votes? Mr.Z-man 17:47, 3 April 2011 (UTC)
  • Reply "VFH is not a discussion page" means don't submit your articles there to get discussion on them. Use Peer Review instead for that. If the discussion is bad (e.g. the article is POV) but the score is good the VFH will most likely fail (This will most likely be listed in rules). It is the good article version of AfD. If someone submits a Bad Article to VFH it would fail and the VFH be deleted even if the score was like "100 miles" (VFH is not a popularity contest!). Scores like "-50 Articles in Wikipedia" will fail even if the article is excellent according to the featured article guidelines, it just isn't reviewed good by Wikipedians. James1011R (talk, contribs, log, boxes) 22:05, 3 April 2011 (UTC)
• This sounds inferior to / duplicative of FAC+GAN, with no significant countervailing benefits. --Cybercobra (talk) 21:15, 3 April 2011 (UTC)
  • It is not intended to outshine FAC+GAN, just to be an alternate way to give excellent articles it's recognition. James1011R (talk, contribs, log, boxes) 22:05, 3 April 2011 (UTC)

I think we can close this discussion as {{rejected}}. James currently has four (4) undeleted mainspace edits. Perhaps when he is more experienced, he'll understand the unanimous objections more clearly. WhatamIdoing (talk) 01:48, 4 April 2011 (UTC)

• Note Is this because I am a no-editor? If not the supporters aren't here yet. James1011R (talk, contribs, log, boxes) 02:11, 4 April 2011 (UTC)

• Oppose. The scope and purpose are not clearly defined; it appears to be redundant to existing processes. I do not see how benefits of an additional parallel layer to GA/A/FA will outweigh the problems with additional bureaucracy. Our FACs and GANs work "well" enough, so I am yet to understand how this proposal improves the existing system? —  HELLKNOWZ  ▎TALK 10:39, 4 April 2011 (UTC)
  • Comment The purpose is to highlight excellent articles (will be added to summary if this goes through). This may allow a quicker way of highlighting excellent articles if it's used enough. (Support and Oppose are clearly defined). Can I use FAC and GAN as VFH if this fails? James1011R (talk, contribs, log, boxes) 02:06, 7 April 2011 (UTC)

• Oppose if this was an april's fool joke, give it a rest, that was a week ago. But if it's really serious, let me point the flaws. First, it is redundant, we already have systems to promote good or featured articles. The best way to avoid (1) is to nominate for GA first, and then for featured (if there are no concerns, you may try higher, but if the article still needs improvement, GAN is better to realize it or decline if the work is too large). (2) it says that it would support all namespaces, but which would be the "talk page featured criteria"? (3) An awesome header is not a reason to use a new system, we can always improve the headers of FAC or GAN if needed. (4) See "1" (5) Nominations are based or arguments, not votes, and it's for the best that it is that way. The facebook-styled "I like it"/"I don't like it" would not be productive here, as we promote or demote articles, not the subjects of articles. (6) and (8): already used at the other projects. (7) and (9): see "3" Cambalachero (talk) 21:17, 11 April 2011 (UTC)

• Oppose - per WhatamIdoing and Sven. Kudpung กุดผึ้ง (talk) 05:41, 15 April 2011 (UTC)

Proposal to convert CSD A7 and A9 to a PROD

• With the ongoing dearth of new users, and
• With the frequent criticism leveled at New Page Patrollers as a cause,

I'd like to propose:

the removal of speedy deletion criteria A7 and A9 and their replacement with an irremovable 10-day prod, with the admin mandated to review the state of the article, and with the prod automatically adding NOINDEX to the article.

Reasons follow:

• A lack of asserted notability is not as bad as vandalism, copyright violations and nonsense articles. The latter are articles that should not or cannot be on Wikipedia in their current form. By comparison, notability is a minor issue. It should not be treated with the same deletion method.
• BLP referencing is a serious issue due to the increased risk of defamation in unreferenced BLPs and the subsequent legal issues. Assertion of notability, by comparison, is minor. This is not reflected in their respective deletion processes, namely the harshly prompt speedy deletion process compared with the mediating nature of the BLP PROD process.
• Speedy deletion offers little chance to explain to a new user inexperienced in the nuances of Wikipedia procedure what is wrong with their article. Speedy deletion criterion A7 is probably one of the most used speedy criteria overall as well as one of the most used on new pages. If that's the case, it suggests that a lot of new article creators are somewhat ignorant of the notability requirements. With so many pages and pages of policies and procedures and guidelines and rules, this is hardly surprising. A ten-day prod, like prod-blp, will allow time for issues to be communicated, explained and, possibly, resolved. If the article is then deleted, it won't be so much of a blow to the new user.
• If the only people who see an A7-tagged article are the article's creator, the deletion nominator and the deleting admin, then there is little way a potentially good article could have been saved. The article rescue squadron can try to save a tagged article but often the person with the most knowledge about the topic is the article's creator, the new user with the least knowledge about Wikipedia's policies and processes. What we need to ask ouselves is whether a simple failure to assert notability (in other words, making the mistake of assuming others know what they're talking about) is sufficient cause to summarily dismiss a contribution as insignificant.
• Tagging a good-faith contribution for speedy deletion and then ignoring both it and it's creator is not a constructive attitude. We should be making the effort to communicate with new users, and not just with a generic welcome tag on their talk page. A notability prod will aid this. Critics might complain about a perceived increase in workload, but all we'd be doing is exchanging one deletion tag for another. (And if people are perceiving Wikipedia as work, then clearly they have the wrong hobby). All in all, what is wrong with taking the time to say, "Hello. I'm so-n-so. Can I help?" I'm sure most of us like helpful shop assistants, so let's extend the same courtesy to our new users.

Don't misunderstand me, though. By all means, let's extend extreme discourtesy to those who would deliberately harm the 'pedia, be they vandals, spammers or worse. But we shouldn't apply the same attitude to people who simply thought their great-aunt Gladys' ability to play the bongos with a pair of walking sticks rated a mention on Wikipedia. There is nothing deliberately harmful about a non-notable article, so let's try to be more understanding, and more welcoming.

LordVetinari (talk) 12:12, 2 April 2011 (UTC)

• Support, largely for the reasons given (which, full disclosure, I had an incredibly minor role in drafting). Ironholds (talk) 12:16, 2 April 2011 (UTC)
• Support - the reason given above are persuasive and with the drop in new editors we need to do something to keep editors. This is a step in the right direction. GB fan (talk) 13:11, 2 April 2011 (UTC)
• Support - a sensible improvement to the system. The 10-day existance non-notable articles won't harm readers because they're NOINDEXed and have a PROD tag to alert readers to the problem. It will help new editors by giving them time to fix problems in cases where they're fixable.--Physics is all gnomes (talk) 14:07, 2 April 2011 (UTC)
• As long as removing it w/o adding refs will result in escalating vandalism-warnings... Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 14:18, 2 April 2011 (UTC)
• Weak Oppose - I would support a shorter time period, maybe 72 hours, no more than a week. If a new user doesn't come back in 3 days, they probably won't come back in 10. But with 10 days, at any given time we might have a pile of 2000-3000 articles to sort through. Finding a salvageable article in these is like finding a needle in a haystack, except there may not even be a needle. Also, NOINDEX does not work on articles. This was an intentional design decision by the WMF technical staff. If they're unwilling to change their minds on this, this would have to use a separate process like the incubator. Finally, if this still uses templates and warnings similar to what we currently use, I doubt this will help anything at all. I doubt that the act of deletion is the only factor in driving away new users, and not the giant unfriendly warning we slap on their talk page or the big red tag on their article. Mr.Z-man 14:38, 2 April 2011 (UTC)
  • It should also have an exception for articles about minors, for privacy reasons. Obviously blatant attacks are dealt with, but minors shouldn't have their personal information floating around on the internet (even if it is hard to find) just because their friends thought it might be funny. Mr.Z-man 14:50, 2 April 2011 (UTC)
    • Agreed, completely; no reason the existing common sense exceptions when dealing with BLPs of minors have to be derogated. Ironholds (talk) 14:51, 2 April 2011 (UTC)
• Support. This makes a whole lot of sense to me, although, like Seb, I'd like to see it be a sticky prod, since the creator removing a prod on a non-notability-asserting article puts us right back to where we started. Speaking as someone mildly terrified of tagging new articles with A7 and A9, largely because they're somewhat ill-defined and potentially bitey, I would very much like to see A7/9-prod become an option for NPPers instead. I would be ok with a length of time other than a week for this prod, though - as Mr. Z-man suggests, perhaps a few days. A fluffernutter is a sandwich! (talk) 14:41, 2 April 2011 (UTC)
• Oppose. As Floquenbeam pointed out in an AfD, WP:NOYOUDONTGETTOKEEPYOURINJOKEONWIKIPEDIAFORSEVENDAYSJUSTBECAUSETHATSWHATTHERULESSAY. Ten days only make it worse. The idea that anyone can create an article about their garage band formed yesterday and have it hanging around for 10 days is simply ridiculous (NOINDEX does not work in mainspace anyway; even if it did it will not stop in-site searches or from someone facebook/twitter/emailing the links). Retaining new editors != keeping crap around for all the world to see. T. Canens (talk) 14:46, 2 April 2011 (UTC)
  • "NOINDEX does not work in mainspace anyway" - that magicword is turned off in mainspace, yes, so doing this requires some software/config changes. Rd232 ^talk 14:52, 2 April 2011 (UTC)
    • What harm is done in allowing the content to (temporarily) stay? Ironholds (talk) 15:04, 2 April 2011 (UTC)
• I've argued before that simply NOINDEXing new articles as standard for a day or two would be good (with perhaps a way to override this where there's good reason). This proposal has some appeal, but I'm a bit concerned that the complexity of it might have unexpected perverse consequences. I think Wikipedia:Village_pump_(miscellaneous)#requiring_autoconfirmation_to_create_articles is probably preferable, and covers much of the same ground, and could be combined with standard noindexing for articles less than (say) 1 day or 1 week old. One advantage of this approach, though, is that it could probably be implemented more quickly, so we could try it and see how it goes whilst still thinking about the alternatives I mentioned. Rd232 ^talk 14:52, 2 April 2011 (UTC)
• Oppose what is needed is a proper use of the A7 tag. It is also the tag I decline speedy reasons with the most. While I appreciate the OP wishing to "save" the occasional good article, and while I also appreciate that newbs need educating, keeping articles which state "Johnny sits next to me in english class and he's really cool" is NOT going to do that. Johnny is not worthy of an article for more than 5 minutes, period. A7 was never intended for subjects of possible or marginal notability, and instead we need to work on getting people to apply it correctly. A sizable number of A7 tags (probably the majority) do not belong, and should have been PROD or AFD tags to begin with, and its just experienced editors who are too lazy to write an AFD page that gets them there. However, there is no need to keep crap articles around for 10 days. If the article is about a subject which has a chance, use prod or afd, but don't pretend that Johnny from English Class has a shot if only we did some research. A7 has its place, and if used correctly it works. --Jayron32 15:10, 2 April 2011 (UTC)
• Oppose I believe that the A7 criteria is over-applied by some NP patrollers, and I've seen admins delete articles where A7 did not apply; however this is a matter of education and better enforcement of the A7 guidelines. The large amount of vanity articles demonstrating no notability whatsoever that are added to Wikipedia on a daily basis is huge and A7 serves an important function in providing a quick and easy means to identify and clear them out. I understand the desire to run a "kindlier, gentler" process as an option, however it should be applied in conjunction with A7/A9 speedy deletion, it should not replace it entirely.--Jezebel'sPonyo^{bons mots} 15:11, 2 April 2011 (UTC)
  • Fair points, Jayron and Ponyo. Could the proposal be amended to be supplementary to A7/A9, to make something between AFD (quite "hard") and PROD (quite "soft" as so easily removed), i.e. a PROD which, like BLP-PROD, can only be removed when the concern has been addressed. Rd232 ^talk 15:15, 2 April 2011 (UTC)
    • Why is something needed between an AFD and a PROD? Seriously, if it needs to "stick", what is the problem with AFD? --Jayron32 15:33, 2 April 2011 (UTC)
      • That's a good question, here's one answer. AfD is overloaded already. Some fraction of AfDs, even on BLPs, close (after a couple relists) for lack of participation. The additional A7/A9 load, which may actually be larger than the existing AfD load, may actually cut into the viability of AfD as a process. (Haven't decided what I think about this proposal, but I did want to answer the "why not AfD" question.) --joe decker^{talk to me} 15:44, 2 April 2011 (UTC)
• Comment I am thinking about making it exactly the same as BLPPROD and requiring at least one single independent reliable source? I honestly can't remember a single case were an unreferenced article in the A7 categories (individuals, animals, organizations, web content) survived AFD, so this would not affect our current standards, we would just be more up front about it. I think some form of A7 will still be necessary however to get rid of the true junk. Yoenit (talk) 16:13, 2 April 2011 (UTC)
• Oppose: eliminates a useful tool, causes process bloat, likely to make the problem worse in some ways. A7 and A9 work fine for the situations they are intended to work: the garage band started last night, dear old Aunt Gladys who played the bongos, the corner grocery store, the mixtape your garage band just made. Yes, there may be people applying A7 and A9 tags when they don't apply, but that's a matter of usage, not a flaw with the underlying criteria. If anything, taking away the A7 and A9 criteria will make the problem of CSD abuse worse: more of the articles will start to be tagged G11 (you're promoting your garage band you started last night) or G3 (the twelfth mixtape article for your garage band is getting disruptive). As an admin, I don't even deal with all A7-tagged articles the same way. Some I delete on sight; some I contact the creator and say that the article is up for deletion, but if you can make clear how the person is notable, the article has a chance of staying; some I decline the speedy but prod; and some I decline the speedy, clean up, and help get on its way as an article about a subject that turned out to actually be notable, once a little digging was done. That said, I don't need a special "prod-A7" tag for the articles that should be prodded; all that's required is an explanation for the prod saying that while there's an assertion of significance/importance, it doesn't appear to be enough to meet the notability criteria. —C.Fred (talk) 16:19, 2 April 2011 (UTC)
• Oppose, many of these pages should be immediately deleted and we don't need ruleslawyering about them. On others, anyone can remove the CSD template and go to PROD or AFD instead. If you see a page that has potential, remove the CSD tag and talk to and work with the original author. Totally agree with C.Fred. —Кузьма^討論 16:39, 2 April 2011 (UTC)
• Oppose, although I empathize with the goal here. What I'd really like to see (and would support wholeheartedly) is A1, A3, A7 and A9 converted to "speedy userfies" instead of speedy deletes, so the editor could work on building legitimate articles and finding sources at their own leisure without having to scramble to "defend" the article with a hangon tag and pleas to the CSD tagger. But there are lots of newly created A7s that genuinely need to be removed from the mainspace quickly, mostly of the "here's my resume" and "she is a friend from my class and is really cool" variety. 28bytes (talk) 16:45, 2 April 2011 (UTC)
• Oppose for the reasons stated above by Jayron32. I also agree with him and others about the over zealousness of some new page pouncers and we need a better way of reining in editors who treat Special:Newpages as a shooting gallery. As long as they are not being blatantly disruptive there's not much we can do about them aside from opposing their RFAs if they run. Anything with even the slightest chance of being an encyclopedic topic shouldn't be tagged for speedy deletion. However, we shouldn't be required to keep articles on garage bands and "Jimmy the awesome grape seed spitter at Buggerville High School" for 10 days for the greater glory of not biting the newbies. --Ron Ritzman (talk) 17:12, 2 April 2011 (UTC)

Well if we don't want this, we need some alternative. Whilst NPPers are vital, there is a problem with trigger happy ones which we just don't seem to do anything about. --Physics is all gnomes (talk) 18:23, 2 April 2011 (UTC)

• Oppose The idea of "delayed speedy deletion" has been repeatedly rejected. Recently, I might add. This is the same idea with a different mechanism. Well intentioned but will cause more problems than it would solve. Beeblebrox (talk) 18:09, 2 April 2011 (UTC)
• Strong oppose - Why should we keep "John Q. Doe was born in 1996, hates homework, and is currently writing this page in the third person"? Reaper Eternal (talk) 18:17, 2 April 2011 (UTC)
• Oppose There exists a problem. There exists a solution to the problem. This is not the solution to the problem. As my idea won't be popular, I'll abstain from mentioning it. Sven Manguard Wha? 19:49, 2 April 2011 (UTC)
• Oppose – Jayron32 hit it on the nose. We should not be inadvertently rewarding those who create John Smith is the most awesometastic person ever!!!; the Dunning–Kruger effect comes to mind. What we need is more vigilant reviewing (from admins, mostly) of A7/A9 to make sure we are deleting what needs to be deleted. –MuZemike 02:50, 3 April 2011 (UTC)
• Oppose; although I appreciate the intent here, there are two issues. One, I haven't seen a huge amount of evidence that we NPPers are doing such a horrible job with A7/A9. Second, we don't need things like this floating around for 7 days; Floquenbeam's AfD comment basically sums it up. We need less garbage floating around here, not more. The Blade of the Northern Lights (話して下さい) 03:57, 3 April 2011 (UTC)
• Support I have recently proposed something like this (as an experiment) elsewhere. I find A7 speedies the hardest to decide, as notability may be implied or potential in an article without an explicit claim. Implementing this change should not change the work load for anybody, as it would merely delay when an admin would be looking at an article to decide if it should be deleted. I also see a change like this as a way to test the assertion that new editors are being driven off because their first attempt at writing an article usually gets deleted. This would be an opportunity to help new editors learn the rules by helping them improve an article rather than deleting it. Of course, that would require extra effort from editors whose chose to help, but I don't think we can solve the new editor retention problem without experienced users helping them. -- Donald Albury 12:06, 3 April 2011 (UTC)
  • If you have to think about it more than 2 seconds, as an admin, just decline it or convert it to a PROD or AFD. If you have to think about "Johnny from English Class" more than 2 seconds, you should reconsider whether working on deletion work is the proper area of Wikipedia for you... --Jayron32 12:55, 3 April 2011 (UTC)
    • Please don't misconstrue what I said. I am quite capable of distinguishing crap from articles that are merely poorly written. But, as it stands now, if I think an article with an A7 tag is borderline, I have a choice of deleting, potentially driving away a new editor, or declining the speedy, potentially leaving a unsourced and poorly written stub to sit for years. I can PROD it, in hopes that someone will improve it, but the usual response to a PROD is to just remove the notice. I am neither a deletionist not an inclusionist. I have nominated my share of articles for PROD and AfD, and about half of my AfD noms get deleted, which I think puts me somewhere in the middle. I have also !voted to keep articles at AfD. I keep seeing talk about how we are discouraging new users, with some proposing that we let all edits and new articles from new users stand, at least for a while, so we don't discourage them. I'm trying to find a way to avoid unnecessarily discouraging new users without compromising the quality of WP. Where is the great harm in allowing an article that may not meet the notability criteria to exist for a few days? Of course, the best way to encourage new users is to help them. I know that takes time and commitment. I am trying to do a little, and I know it is not enough. -- Donald Albury 15:50, 3 April 2011 (UTC)
• Oppose for several reasons. If the intention is to rescue more articles created by new users then this will result in a lot of wasted effort. We get through about 7-8000 A7 deletions per month, which compares to about 2000 each for AfD and PROD. Most A7ed articles can't be salvaged so attempting to put a similar level of scrutiny on them as AfD or PROD candidates will be largely a waste of time. I see a lot of new users complaining when their articles are nominated for deletion through PROD or AfD, and I think that new users are turned off by the fact that the article was deleted rather than the process used. If a user spends time trying to clean up an article to avoid deletion through the proposed mechanism and the article still gets deleted it could be even more BITEy than speedy deletion. If we want to improve new page patrol then better solutions would be to require autoconfirmation for creating pages and greater review of speedy deletions (such as taking more problematic ones to WP:DRV). Hut 8.5 14:04, 3 April 2011 (UTC)
• Oppose. The articles that I have deleted as A7s were not the sort of articles that one would want cluttering up PROD lists, and the number of correctly-deleted A7s is too large to fit that process. There is an issue of abuse of these tags which is something that should be dealt with, but not by removing them. The standard for A7 *must* be much lower than the standard that would see an article kept at AFD - too many editors tag articles inappropriately as A7's, and some also tag articles as A9 before the artist article is deleted. What we need is more scrutiny of the tagging of these articles and removal of rights from editors who repeatedly abuse them. A7/A9 tagging minutes after articles are created, often while it's clear that the editor is building the article up over several edits, is also not helpful. Some sort of time allowance for this sort of article would be useful, but difficult to apply without also allowing the real crud to hang around much longer than it should.--Michig (talk) 16:04, 3 April 2011 (UTC)
• Oppose Completely unworkable and unrealistic. Our backlogs are growing not shrinking. Putting aside the fact that the majority of articles deleted under A7 are not just properly deleted according to the criterion's terms, but would not survive a deletion debate on the merits at AfD, if implemented we would vastly increase our workload and we can't handle that increase. If every one of the approximate 7,500 articles that would have been valid A7s were prodded (which would never happen; also, prodding takes more time which would itself also be an increase in the workload) and just 10% of those the prods were removed, we would have 750 extra AfDs to write, debate and close per month. Of course, this would not happen. Instead we'd still get a large increase, but also a large increase in properly deleted articles escaping. A7 is a doorkeeper process and it is the most important of the CSDs, that would not scale to prodding and AfD. Yes, it would be great if A7, like all of our processes, was not flawed in implementation resulting in a bad outcome for a small subset. Getting rid of A7s because that subset exists here is is a very extreme cutting off our noses to spite our faces form of reaction.--Fuhghettaboutit (talk) 16:51, 3 April 2011 (UTC)
• Oppose - per Ron Ritzman and Michig. Recent research (although the proof was not necessary) has demonstrated that New Page Patrol is in a mess and is largely carried out - in good faith - by the newest and least experienced users. The error was made way back when anyone was allowed to be a new page policeman without any training whatsoever. Even after repeated gentle requests many continue to use it as the fasted way to bolster their edit counts and do not appear to understand the requirements of WP:NPP and WP:DELETION. The solution is to encourage NPPers to slow down and take more time to read what they are tagging. If this is not possible, other solutions are to either turn NPP into a right, such as reviewer and rollbacker, speedy userfication (per 28bytes), or simply to put all new pages (except those created by autopatrollers) into an incubator for 24h so that they can be reviewed by competent editors before being allowed to go live. No new article is so urgent that it must go online as soon as two words have been created - many ordinary web forums require all new posts to be reviewed by a moderator before they are accepted. Kudpung กุดผึ้ง (talk) 16:54, 3 April 2011 (UTC)
• Support/Oppose I am one of the most avid critics of A7/A9 misuse and I frequently argue to be very strict in its application. That said, I'm not completely convinced by any proposal to remove those criteria completely. There are a lot of articles that really need A7: Highschool kids writing about their friends, MySpace bands trying to use Wikipedia to promote themselves, unknown webpages that seek to gain attention etc. There is no point to keep such pages that really will not have a snowball's chance in hell to survive any review and those new users that create those pages usually know that Wikipedia is not the place to talk about their best friends or similar subjects. That said, I do support an attempt to make A7/A9 stricter and to have such a PROD-alternative for articles where it's not clear cut. How about this as a compromise: Let's keep A7/A9 for clear-cut cases and have a PROD-like process like the one proposed here for all other cases, possibly combined with a list of criteria that make a case non clear-cut. Regards SoWhy 17:11, 3 April 2011 (UTC)
• Oppose Nice idea on the one hand, but I have no wish to see the majority of A7 and A9 stuff hang around for 7 days. I think speedy deletion is better Pol430 talk to me 23:33, 3 April 2011 (UTC)
• Comment - The current NPP system is in such disarray for the reasons I stated above, that creating even more options or criteria for NNPers to have to think about would be counter productive - many patrolers are unable to tell the 'clear cut' difference between a hoax and an attack page, a no context and a no content page, and a spam and a non notable page. Kudpung กุดผึ้ง (talk) 23:57, 3 April 2011 (UTC)

I would have liked to have added some comments here earlier but my internet connection went on holiday and is taking the scenic route home. Jayron's comments seem to best summarise the criticisms, so I'll respond primarily to those. This isn't to disparage the weight of other users' comments, however. I'll set aside for the time being the issue of whether the proposed prod should be 10, 7 or 3 days. As it is, I'm beginning to think a shorter time may be better.

First of all, I note that several of the examples used to demonstrate articles that should be deleted under A7 could just as easily be deleted on the grounds of lacking context, or for being nonsense or test pages. Crap articles are not the one's in question here.

As alluded to above, A7 is being used on subjects of possible or marginal notability. I agree that this is a problem, but I disagree that re-educating NPPs will work. To begin with, too many people have too many views of what constitutes notability, admins included. This, combined with the incredible diversity of new articles, means that there there can be no clear-cut definitions of what constitutes notability: there will always be something new that tests the boundaries. That's why we only have notability criteria for some general umbrella topics (e.g. people, businesses) and for only a few specific sub-topics (e.g. academics). Additionally, any re-education would need to be total to be effective. There is no point one admin reminding a NPP to rein in their enthusiasm if another admin is doing the precise opposite. When we consider that NPPs, like other editors, come and go all the time (I've known day-old accounts to become NPPs), any re-education effort would be an unending drain on time and resources.

It's been pointed out in this discussion that “a sizable number of A7 tags do not belong and should have been PROD or AFD tags to begin with”. This is obvious and is exactly the point of the proposal, but the proper tagging just won't happen. First of all, it is far easier (even with Twinkle) to select an existing CSD tag than to write a PROD or AfD. I don't think I ever sent an article to AfD until I learnt Twinkle. It was just too complicated. As for PRODding, in the absence of a pre-written PROD for notability, which is what this proposal is about, CSD tagging becomes a far simpler option. The second reason why people choose CSD over PROD is that a CSD sticks. I rarely touch PRODs other than BLP simply because anyone, article creator included, can remove it without resolving the issues being highlighted. Such removal is supposed to require a justification but this is not and cannot be enforced. If I want to see an article deleted, a PROD is the least effective and least guaranteed means to do so. Hence I, and other NPPs, have often opted for CSD, even in borderline cases.

I also note there is a PR aspect in the proposal that doesn't appear to have been addressed in this discussion. Namely, that a new user's article gets deleted with little more than a generic "F*** off and don't come back until you have something decent." How welcoming is that? The proposal urges NPPs to make the effort to gain the trust and respect of new users. Basically, if an article is truly crap, there are several CSD tags that can do away with it. And if an article is borderline in its notability, the NPP should make the effort to discuss it with the new user, help them to improve the article where it can be improved and help them to do better next time if their article ends up being deleted.

All in all, I'm a bit disgusted that the current attitude appears to be to focus on backlogs and workload rather than on people. If the purpose of the Wikipedia project is to build an encyclopaedia, than I would have thought the emphasis would be on quality rather than quantity. When I worked in fast food, I quickly learnt that the most important customer was the one I was serving, even if there was a long queue waiting to be served. By encouraging my staff to have the same attitude, my store (under threat of closure when I started) became one of the fastest growing in my state with almost half my customers being repeat customers. With this proposal, I'm urging the Wikipedia community to apply the same attitude here. Don't focus on the backlog because we have the rest of eternity to finish that. Instead, focus on the new user. If you find an article with borderline notability that could or should be deleted, don't tag it and forget about it. Talk to the article creator and discuss it with them. At the end of the day, the aim here should not just be to delete the garbage but also to nurture every new user. As I tried to say in the proposal, a constructive edit is still a constructive edit even if notability is in question. Notability is not in the same league as vandalism and spam and should not be treated teh same. The person who created the article should be nurtured, encouraged and helped.

From the progress of this discussion, I can see the main point on which both camps can agree is that CSD A7 can be misapplied. I'd therefore like to change the original proposal from a single yes-no choice to two possible choices, as follows:

A: The original proposal of replacing A7 with an irremovable prod-notability (length and noindexing status open to discussion), OR

B: Keeping A7 but still creating the aforementioned prod-notability for use when notability is possible or unclear. This option can reduce the number of AfD discussions as well as offering an equally simple, and better, alternative to mistagging with CSD.

LordVetinari (talk) 02:28, 4 April 2011 (UTC)

• Strong oppose. Most of the stuff deleted under A7/A9 is rubbish that no waiting period will overcome. Introducing a waiting period means we have cruft lying around for longer reducing the reputation of the encyclopedia, and there's more time for people to remove the tag inappropriately, causing the article to stay around forever (unless you have very dedicated people following up on their taggings).
  To LordVetinari's most recent points, I'm sure we would love to focus on people, but we need to keep it realistic as well. Wikipedia does not need people's business. Unless you have a large army of experienced users ready and willing to work with newbies who are trying to promote their garage bands (etc.) then the suggestion that these articles should not be deleted will generate further backlogs. I have no objection to backlogs as long as they are not being created at a rate higher than they are being cleared; that, by definition, is unsustainable and unmanageable.
  Finally, there is no need for a "prod-notability" tag; a normal PROD will do just fine. Stifle (talk) 10:29, 4 April 2011 (UTC)

• Oppose. I don't see how a new editor expanding their article for 10 days only to be deleted afterwards is any better that having it deleted straight off. I don't buy that given enough time the article will somehow pass notability, which is not related to the article's quality. The few occasional notable topics falsely deleted will get re-created properly (with assertion of notability) eventually. Nuances of Wikipedia are not explained in the articles and keeping an article solely to educate newcomers is not the way to go. Nobody is keeping the editors from communicating with the newcomers, whether their article is deleted or will be in x days. All that said, a "NPROP" for questioned notability, but not clearly A7/A9 could work, but that is a different proposal. —  HELLKNOWZ  ▎TALK 10:54, 4 April 2011 (UTC)

• Oppose Stifle is correct that most of the stuff deleted under these criteria is rubbish. The problem is dealing with the not-quite-rubbish, and that is a much subtler problem. New editors are not helped by being encouraged to work on hopelessly unacceptable articles, they are helped by being guided how to improve those that are presently unacceptable, but capable of improvement. To the extent the we use A7 and A9 on such articles, they're being used wrongly, and any cases noticed should be discussed with the deleting admin, or the new editor should simply be encouraged to rewrite more acceptably. (There is no real point in bringing borderline cases to deletion review , because rather than being immediately restored, the discussion will normally close as rewrite and resubmit, which does not take deletion review.) And I further agree with Stifle that a normal Prod works very well--as long as it is explained to the new editor that there is no point removing the prod tag unless they can show notability -- the message I use when I place such a prod, in addition to the standard notice, is: "If you decide that the article cannot presently meet our standards, you can facilitate matters by placing at the top a line reading : {{db-author}}. When you have the necessary material, then try again. I do not want to discourage you, but to urge you to write a proper article if it is possible; if it is not yet possible, please help us by improving our other articles on related topics." If properly guided, very few new editors will force it into AfD. This is not a question of deletionism/inclusionism--no one should want to include the impossible or delete the possible. DGG ( talk ) 00:32, 6 April 2011 (UTC)
  • Thank you for your support. I should also have been clear in my post that the way of dealing with misapplications of A7/A9 (which I will confess to having engaged in myself sometimes) is to address it with the user, rather than revoke the criteria. Stifle (talk) 11:12, 12 April 2011 (UTC)
• Oppose. I suppose the claim is that we're losing good content because of A7 and A9 deletions, or that it's MEAN to delete recently created articles too fast and we're therefore losing too many new editors, or both. Like all valid CSDs, A7/9 cover cases where it is impossible or extremely unlikely that an encyclopedic article can be written about the subject in question, based on either the subject itself or the current condition of the article. I'd like to see the advocates of this proposal demonstrate that the encyclopedia is losing out on good content because admins are deleting A7/9s too fast. We already have a solution for the rare cases where an A7/9 actually does describe a valid, encyclopedic topic: Post a new article on the subject that asserts its importance. So instead of "Foo McFooey is like soooo tight I have english with him!!!!!", write "Foo McFooey is an American musician who has released four platinum albums^{[1][2][3][4][5][6][7]} and won three Grammys^{[2][3][7][8][9][10][11][12]}". As for the issue of being kind to newbies, we'd be showing them even more unkindness if we gave them the impression that such content is acceptable on Wikipedia. Yes, maybe deleting A7/9s hurts the creator's feelings, but our job is to create a neutral, verifiable encyclopedia, not make all our participants feel good. There are much better ways to retain new users. szyslak (t) 04:00, 6 April 2011 (UTC)
• Oppose A/Question on B. I think A7 should be kept for articles that really do make no assertion of notability at all. Maybe A7 could be rephrased to make it clearer to inexperienced editors how to apply it properly. As for part B, would the notability prod be removable by other editors who dispute it like a CSD? If so that would seem fine, but it is not clear, and could be read to prohibit any non-admin from touching it which I would strongly oppose. Monty₈₄₅ 02:48, 7 April 2011 (UTC)
• Oppose- we say that the tag is "irremovable", but inforcing that is difficult; and most of these articles wouldn't survive anyway. עוד מישהו Od Mishehu 08:26, 13 April 2011 (UTC)
• Oppose as a lot of the above users said, most of the articles tagged under A7 and 9 are junk articles that shouldn't exist. If it ain't broke, don't fix it. This is only slightly out of order, why opt for mass change? —James ^{(Talk • Contribs)} • 10:17pm • 12:17, 18 April 2011 (UTC)

Let's get rid of hangon template

I think we should get rid of the hangon tag, because it appears to confuse new editors while being redundant. It is not common for new editors to manage to use it properly, despite plentiful instructions: hangon is often placed in the wrong place (cosmetic problem only), used to replace speedy deletion template, placed on the article's talk page, the creating/deleting user's talk page or anywhere else. Quite often no reasoning is given, so some new editors seem to think (again, despite instructions) that placing the tag is enough to prevent deletion, while in fact, hangon in itself does nothing.

The contesting process could be simplified by losing the hangon template. To contest the speedy deletion, the user would be directed by the speedy deletion templates to make their arguments on the article's talk page, removing the extra step of hangon in between. This would also make the actual essence of all the templates clear to the user: one really has to explain why the article should stay. Zakhalesh (talk) 18:53, 3 April 2011 (UTC)

The problem is that it's quite likely the reviewing admin won't read the talk page if there's no tag to remind them to check there. Many of them don't check the page history despite the fact they're supposed to. Hut 8.5 18:59, 3 April 2011 (UTC)

I'm not a template specialist, but the hangon template displays a special text if no reasoning has been given. I assume the same behaviour could be incorporated into DB templates - I could show big flashing text (figuratively speaking) if the talk page is edited. Zakhalesh (talk) 19:06, 3 April 2011 (UTC)

Templates such as {{db-a7}} currently advise you to edit the article to add the {{hangon}}, and then to edit the talk page. They could instead advise you to use the one-step process: {{hangon|The plea goes here}}. Would that be simpler for the new editors to understand? -- John of Reading (talk) 20:21, 3 April 2011 (UTC)

I second John of Reading's suggestion. --Cybercobra (talk) 21:36, 3 April 2011 (UTC)

I proposed this a while back on wt:CSD, but never went anywhere with it. Technically the hangon tag is completely redundant. You can make a link in the speedy template "click here to contest this speedy", which allows the user to create a new section on the talkpage/subpage. The template can then detect the existence of a talkpage/subpage and show up as contested. I even had the template transcluding the reason the new user provided, but there was some resistance to that. You can find the sandbox version here. Yoenit (talk) 22:18, 3 April 2011 (UTC)

Hangon tag already has that functionality. I was surprised when I saw that for the first time. Zakhalesh (talk) 04:06, 4 April 2011 (UTC)

Support with comment I suggest getting rid of the hang on template altogether, it does not really seem to serve much of a purpose, and revising the speedy deletion tag wording, and related policy wording, to stipulate that no one should remove the speedy tag except the reviewing admin. This would prevent article authors circumventing CSD policy by logging out of their account or using a different account to remove CSD tags and go unchecked by User:SDPatrolBot. Pol430 talk to me 23:55, 3 April 2011 (UTC)

Wow, serendipity. Yoeneit, what do you mean it never went anywhere? I posted to your talk page a few days ago that we should hammer this out and present it to the community. You never responded and archived the post. It just happens I was working on it tonight and came across this discussion by pure luck, noting the post at the help desk. Since you reverted my last edit to the template but we discussed on my talk page the problem with making the text transclude in the db=templates themselves, I have been working on the next implementation at {{Db-meta/sandbox2}}. For everyone, this was discussed at WT:CSD, here, and there's some discussion at my talk page about the implementation, here.--Fuhghettaboutit (talk) 03:37, 4 April 2011 (UTC)

Is there any actual opposition? Some specific issues that haven't been addressed already? Zakhalesh (talk) 17:38, 5 April 2011 (UTC)

We can't just stop using hang on cold. We need a replacement for its functionality--there has to be a process in place to take up where hang on leaves off. That is exactly what Yoenit suggested a few weeks ago, was worked on, and I have been tailoring for the past few days with {{Db-meta/sandbox2}}. One kink left is that I need to get it to include {{Hang on/notice3}} with a parser function when the talk page exists (when there is no talk page it displays {{Hang on/notice2}}, which is a folded in feature from Hangon, tweaked for the new way the process will work. I have a request out to a template guru to help with that (though writing that here might just get me that help, nudge, nudge, wink wink). Also, this is a very small group to reach consensus on such a wide change affecting a process so many regulars and admins are involved in. If I were just bold and replaced db-meta with the sandbox, I'd guess I'd be reverted very quickly if more formal discussion had not taken place (the community has become much more conservative about change, and reverts just because a large discussion hasn't taken place are now common [as opposed to actually analyzing whether a change is good or bad]). I had planned on writing up a more formal proposal, explaining exactly what the new template does, why hangon is unecessary, how this is better, and so on. Maybe a will be bold once the last tweaks are in place—I think it's much, much better than using hangon—but this may ultimately require a strawpoll.--Fuhghettaboutit (talk) 21:24, 5 April 2011 (UTC)

Well I boldly added it to db-meta but for some reason the notices that inform users to edit the talk page it it doesn't exist, or for admins to check the talk page if it does exist, did not work when it was passed through to the db templates. I have no idea why. It works flawlessly in testing.--Fuhghettaboutit (talk) 03:48, 6 April 2011 (UTC)

Yes, I didn't mean that we should rush for it. When the new DB works, does anyone have any concerns why they'd rather use hangon? Zakhalesh (talk) 04:15, 7 April 2011 (UTC)

Could I request some clarification? 1) Is SDPatrol's proposal to not allow anyone to remove the CSD tag a part of this proposal to remove of hangon? 2) What exactly is going in its place--a link on the speedy template that automatically opens up a discussion on the talk page? If so, does the db template itself get reconfigured so that an admin sees that something has been added to talk? If not, something else? 3) Are the notification templates being similarly changed (the ones we put on the user page of the creating editor)?

1) I won't comment much on this one, and it's not a part of my original proposal. At least in some cases the author/other non-admin must be allowed to remove DB-templates. For example, the placer of the template should be able to remove it, and G7 (author requests deletion) templates should be removable by the author. I don't think we'd lose anything for keeping the SDPatrol system like it currently is. 2) What I thought about was that DB-templates would, instead of recommending the use of hangon, direct the user to the article's talk page, and if the article has a talk page, it would in addition remind the administrator to check the talk page before making a decision. 3) If this change is agreed on, the notifications must be changed, naturally. Zakhalesh (talk) 16:01, 7 April 2011 (UTC)

Woah, it's been done. Thank you, everyone who has been working on it! Zakhalesh (talk) 17:44, 14 April 2011 (UTC)

I wholly support this improved system and like using it. I have made two small suggestions for improvement on the template's talk page. Kudpung กุดผึ้ง (talk) 05:33, 15 April 2011 (UTC)

Edit test cleanup bot

I have proposed writing a bot (discussion here) that would clean up editing tests in the mainspace. This bot would undo edit tests and "accidental mouse click" edits where the following strings (and similar) are added to articles:

• '''Bold text'''
• ''Italic text''
• <big>Big text</big>
• [[Link title]]
• [http://www.example.com link title]
• == Headline text ==
• [[File:Example.jpg]]

Here is a recent example of such an edit. Previously there was an edit filter that would catch these, but currently the cleanup has to be done manually. I've cleaned up a few hundred of these manually, but I think a bot would be better suited to this work. The Bot Approvals Group has suggested coming here to gain a consensus for such a bot, so here I am!

There are two types of cleanup the bot can do: simple cases (where the entire edit is editing tests, like the example above) and complex cases (where the edit test is part of an edit that includes other changes, like this attempted edit). I believe (I hope, at least) the "simple case" cleanup task will be non-controversial, but there are some things to consider regarding the "complex case" cleanup, so I will outline the "complex case" options separately below. 28bytes (talk) 17:15, 5 April 2011 (UTC)

"Simple case" cleanup

Any edits that consist entirely of edit tests or accidental mouse clicks (as described above), the bot will undo.

Support

• As proposer. 28bytes (talk) 17:15, 5 April 2011 (UTC)
• Yes, and also stick {{uw-test1}} on the talk page of the editor. Reaper Eternal (talk) 17:29, 5 April 2011 (UTC)
• Yes, and give a vandalism warning for three-click-+ edits (e.g. [[File:[[File:Example.jpg]][[File:[[File:Example.jpg]]]]]] — that's not an accident) Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 17:36, 5 April 2011 (UTC)
• very good idea. For complex case I would opt for "Option 1 - Partial undo" if that is feasable. HenkvD (talk) 18:02, 5 April 2011 (UTC)
• Support and agree with Seb. Regards, MacMed^talk_stalk 20:11, 5 April 2011 (UTC)
• Support. However, giving a vandalism warning seems unwarranted, no matter how many test-type edits occur; the point is that they are newbies going "wow can a really edit Wikipedia?" and we don't want to bite them. uw-test1 is sufficient. -- King of ♥ ♦ ♣ ♠ 00:18, 6 April 2011 (UTC)
• Support. It sounds like a good idea, but I would suggest giving the editor a grace period of 60-300 seconds to either undo the edit or finish what they were doing. Monty₈₄₅ 03:13, 7 April 2011 (UTC)
• Support. Great idea. More test edit fixing bots would be great.Doc James (talk · contribs · email) 03:29, 7 April 2011 (UTC)
• Support - but don't do vandalism warnings. I've actually seen new editors click on the file button four times trying to create a gallery. Makes sense if you have little knowledge of how Wikipedia works, I'd rather hit them with editing test than vandalism. Mind you if they already have an editing test warning or two that's a different story. Sven Manguard Wha? 06:35, 7 April 2011 (UTC)
• Support - these edits would be reverted on sight by human users, and are simple enough for a bot to identify. עוד מישהו Od Mishehu 07:36, 14 April 2011 (UTC)
• Support - start with edit testing, see how that goes then expand. Small baby steps. —James ^{(Talk • Contribs)} • 11:01pm • 13:01, 14 April 2011 (UTC)

"Complex case" cleanup

There are a number of ways "mixed" edits can be handled:

Option 1 - Partial undo

Remove the edit test part of the edit, but leave the rest of the edit alone. For example, in this edit, the insertion of "* Increasing blood flow to the brain" would not be undone, but the rest of the edit (the insertion of the "example gallery") would be removed.

Option 2 - Complete undo

Undo the entire edit.

Option 3 - Conditional partial undo

Undo the entire edit, unless referenced material is added, in which case only the "edit test" part of the edit would be undone.

Option 4 - Conditional complete undo

Undo the entire edit, unless referenced material is added, in which case the entire edit is left alone.

Option 5 - Do nothing

Do nothing (leave the edit alone.)

Discussion

Please add your comments here regarding the "complex case" options above. 28bytes (talk) 17:15, 5 April 2011 (UTC)

Support

• I would opt for "Option 1 - Partial undo" if that is feasable. HenkvD (talk) 18:04, 5 April 2011 (UTC)
• Support option 1 for now. If this task is deemed not allowable, I doubt many editors would volunteer to work on cleaning up all 100000+ test edits manually. It will probably just end up going back to the edit filter again, which would bring back all the problems we had before that led to the filter being disabled.Also, 3 and 4 are good in theory, but not every valid edit has a ref tag in it and even some referenced edits will not use actual ref tags if it's from a new editor who isnt familiar with the interface. —Soap— 20:15, 5 April 2011 (UTC)
• Option 1. I don't see any harm in this, as long as the bot performs as expected. The worst that would happen is that vandalism is left on the article, but it would happen even if the bot had not come around. -- King of ♥ ♦ ♣ ♠ 00:21, 6 April 2011 (UTC)
• Option 1 sounds like it ought to have a low enough error rate to be a good idea. Perhaps, to assuage concerns about causing problems, the bot could initially just log actions it would have taken, so we can see how well it works. If that looks good for Option 1 (after say 1000 logged "would have done" edits?), then experiment with logging potential actions for complex cases, and see how the error rates look for that; if seeming OK, discuss that further. Rd232 ^talk 12:39, 6 April 2011 (UTC)

Oppose / Do nothing

• Only a human can assess the intent of the edit(s) and make the choice between {{uw-test1}} and one of the welcome templates. -- John of Reading (talk) 19:37, 5 April 2011 (UTC)
• I agree with John. This bot would be good, but I think only for the simple cases described above. These edits will get caught by vandal-fighters pretty quickly anyways. Regards, MacMed^talk_stalk 20:14, 5 April 2011 (UTC)
• Unless it can be shown (using an analysis of some large sample of partial test edits) that whatever method is chosen will work reliably. Bots with high error rates are not acceptable. Both undoing a (partially) valid edit or leaving inappropriate content in an article would be errors IMO. If a human has to follow it around and make sure every edit is correct, it defeats the purpose. Mr.Z-man 21:38, 5 April 2011 (UTC)
• I have reverted a small number of these test edits and I do not recall seeing any useful edit mixed in with the problems, so if an analysis of a representative number of complex cases showed that (say) 95% were all junk, I would support the bot reverting all edits. However, I oppose a bot that would revert only some of the edits because that would give a false air of "checked as ok" to the non-reverted edits, meaning that some bad edits would not be inspected for a significant time. Also, a human who might have been able to just click "rollback" would have to do something a little more complex and hard-to-follow to clean up if a bot had reverted some of the edits. Johnuniq (talk) 07:57, 6 April 2011 (UTC)
• I oppose 2-5, I think you need to get human eyes on an edit before deciding on any of those choices, I'm not really sure on method #1, but if you could get it to work very reliably I would consider supporting it. Monty₈₄₅ 03:19, 7 April 2011 (UTC)
• Option 1 without warnings was tempting, but in the end, there are too many variables. I'd still like to see what you come up with, but I'm not sure it'll work in the end. Sven Manguard Wha? 07:03, 7 April 2011 (UTC)
• The "test edits" probably co-incide with other problems with the edits; only a human can assess the relevance of the other parts of the edit. I may support proposal 1 if the bot would additionally make a report on some human-patrolled page. עוד מישהו Od Mishehu 07:39, 14 April 2011 (UTC)

Comments

• What happened to the edit filter? Stifle (talk) 09:52, 13 April 2011 (UTC)

Patient information boxes

At the recent Wikimedia UK/Cancer Research UK collaboration, the question of patient information links on disease-related articles came up. Charities, governments and health providers have a motivation, almost a duty, to ensure that reliable, high-quality information is provided to people who have or believe they may have a particular disease. It is in Wikipedia's interest that people who have diseases take what they read on Wikipedia with a grain of salt. Many people use Wikipedia as a source of medical information: someone told me that a survey of doctors in the U.S. found that 50% of them have used Wikipedia in diagnosis. In this week's Signpost In The News section, I wrote up a story of a man in Britain who has diagnosed himself on Wikipedia. There have been other stories similar to this.

As it currently stands, there is a potential WP:COI issue if representatives from charities, patient advocacy groups and health information providers like the National Health Service start adding links to the External Links section of articles about diseases, medical treatments and so on. The other issue is that patient information links take Wikipedia slightly away from the encyclopedic mission of the project, and potentially some might feel there are WP:NOT-concerns. For instance, we don't link to "cult deprogrammers" as, I dunno, "Cult information" links from articles like Church of Scientology. The difference here is that whether we like it or not, people are using Wikipedia as a source of medical information. It is in our interest to ensure that people reading Wikipedia get reliable medicine information (just imagine the furor around the inevitable "Wikipedia's dodgy medical information leads to toddler death!"). And Wikipedia is already providing some links to patient information pages, but without overall co-ordination.

The other issue is that there is an inherent POV in linking to patient advocacy, non-profit and governmental websites about a particular disease: they all advocate treating that disease. They are inherently anti-disease and pro-treatment-of-disease. I can't quite think of why anyone in their right mind could be, say, fervently in favour of arthritis. There are certainly people who are pro-suicide, and there are a few things that are widely considered diseases for which there are vocal communities who disagree with the assessment of it as a medical condition: there are people who are "pro-anorexia", people who think autism and other autistic-spectrum disorders like Asperger's Syndrome are not medical conditions but are just variations from that which is considered "neurotypical" by society, and there are people who think being overweight or obese is not as medically dangerous as mainstream medicine makes out. And then there is the rabbit hole of alternative medicine. But, there is already an argument over this: firstly, these are borderline cases. Really, there is not a significant or notable body of people out there who are pro-cardiac-arrests or pro-cancer. Secondly, we already have policies to deal with this: WP:FRINGE, WP:UNDUE and for external links, WP:ELNO.

The proposal then is roughly like this: for medical articles, we have a template of some description that includes 'deep' links directly to patient information pages from reputable, recognized governmental, non-profit, patient advocacy and charitable sector institutions. Preferably, these sources would match the rules given by WP:RS, WP:EL or both. Examples of such groups include the National Health Service, the National Institutes of Health, the Centres for Disease Control, the Red Cross, the American Lung Association, the Royal College of Obstetricians and Gynaecologists, the British Dental Association, Scope (charity) etc. Further examples of the sort of bodies we might link to can be found in Category:Medical associations and Category:Health charities.

Patient information: Lung cancer
Cancer Research UK
American Cancer Association
National Health Service

I've mocked up an example of what one would look like using lung cancer as an example. It's on the right (it's being transcluded from my user space: see User:Tom Morris/Disease Information. I'm not a very good template designer, so obviously, other suggestions and designs are welcome.

I guess the questions are:

1. Does this seem like a good idea?
2. Does this fit in with the project scope of Wikipedia?
3. Are there possible WP:COI or WP:NPOV problems here?
   • To avoid the appearance of impropriety, we could test this first with topics other than cancer.
4. Would specific guidelines be needed, perhaps medical-specific external links guidelines?
5. How could we co-ordinate this? Perhaps through something like Wikipedia:WikiProject Medicine?

Feedback welcome. —Tom Morris (talk) 12:24, 6 April 2011 (UTC)

I'm not saying this is not a good idea, but just pre-supposing one likely objection (and playing a bit of a devil's advocate), while your suggestion that "no one is 'pro-cancer'" may be true, that is not going to be the issue. The issue is there ARE people who are 'anti-cancer-treatment' for some treatments; if Wikipedia appears to endorse one view of treatment of cancer over others, it could be said to be taking a non-neutral point of view. Personally, I disagree on the grounds that there are clearly treatments that work, and those that don't, and Wikipedia should ideally favor coverage of those that work regardless of people's opinion of them. However, my biggest issue is that Wikipedia not give the appearance of attempting to be a medical resource. We have no control over what purposes an end user may do with information at Wikipedia. Wikipedia should strive to be as accurate and reliable as it possibly can be, and this applies to all articles, not just medical articles. We bear no special responsibility in getting a medical article "right" over that of any other article. WP:BEANS may be the most appropriate guide here; we cannot presuppose every way someone may use Wikipedia to screw themselves up, and we may actually do unforseen harm if we attempt to "head-off" every single such misuse of information. --Jayron32 12:43, 6 April 2011 (UTC)

I think that it seems a pretty sensible idea. Worth making sure that we include links relating to services etc. in other English-speaking countries / areas as well as the USA and UK. Pesky (talk) 12:48, 6 April 2011 (UTC)

1. We already link to the NIH (medlineplus) for all disease articles within the disease box in the lead. There is a proposal in place to also link to the NIH for article on medications in the drugbox [4] and to drugs.com which contains FDA info and info from the American Society of Health-System Pharmacists
2. I support linking to information from major governmental and scientific bodies and we frequently do in the external links section. In general linking to charities and patient advocacy groups though is not a good idea. Too many of them are of a commercial nature. There are also false patient groups created by the pharmaceutical industry as a means of promoting a disease.
3. Do we need a special box in the external links section to display this? While I guess it would be an option. But we already have all this information so I am not sure it is really needed. Would wish to see some example of this before I decide if I would support it or not.
4. BTW if you look at the EL at obesity the first one is patient info from the WHO [5] if you look at lung cancer you see pages from the American Cancer Society [6] Doc James (talk · contribs · email) 12:49, 6 April 2011 (UTC)

• Oppose as spambait and unfairly anointing "the usual" websites rather than selectively choosing the best for any given situation. Many such links fail WP:ELNO for duplicating article content or each other. The regular external links section, with the regular guidelines, is good enough. WhatamIdoing (talk) 15:35, 6 April 2011 (UTC)
• I'm against this as a template: I'm not against the links themselves, if relevant to the article and from trusted sources. However, putting them in a special box gives them some special status they don;t deserve. I disagree with WhatamIdoing above; these resources are likely to provide information (in the form of more links, contact details, etc.) that fits fine with the spirit and indeed mostly to the letter of WP:EL. Grandiose (me, talk, contribs) 16:04, 6 April 2011 (UTC)
  • It gives as much as it takes away: yes it gives them a special status, but it also hides them away in a collapsed box. —Tom Morris (talk) 16:22, 6 April 2011 (UTC)
    • I am generally against putting information in a collapse boxes and our current arrangement gives these links sufficient prominence. But I guess the next question is how can we best get the experts who are interested from Cancer Research UK involved with improving medical content on Wikipedia?Doc James (talk · contribs · email) 22:52, 6 April 2011 (UTC)
    • While you propose for the box to be collapsed by default, I don't expect it to stay that way, because WP:ACCESS gently discourages most collapsed boxes as being unusable for some readers with disabilities. WhatamIdoing (talk) 16:30, 7 April 2011 (UTC)
• Some years ago, I made a plea for a similar point - that medical articles should have a disclaimer, to the effect of "Do not take this as a substitute for advice from a medical professional". It was pointed out to me at the time that there are already disclaimers (including a medical disclaimer) in Wikipedia. However, that said, I would be all in favour of making these disclaimers more visible. ACEOREVIVED (talk) 16:16, 6 April 2011 (UTC)
  • There is a medical disclaimer embedded into the general disclaimer. Adding endless disclaimers denigrates the reader. JFW | T@lk 22:57, 6 April 2011 (UTC)
• Oppose, WP:NOT seems the driving force here. We are here to serve every reader, not just for patients looking for information about their disease. There are already several ways by which this information can be linked. JFW | T@lk 22:57, 6 April 2011 (UTC)
• Oppose 1) Wikipedia is not and should not be in the business of vetting good sources of medical information from bad ones. 2) What do we do when homeopathic advocates say they want in, or non-Western medicine sites? ArbCom restrictions aside, I don't want every medicine page to become a battleground. 3) This already exists in the See Also section and/or the Sources section at the bottom of the page. Sven Manguard Wha? 06:32, 7 April 2011 (UTC)
• Oppose per WhatAmIDoing. I'm actually uncomfortable with many of the external links we already have in disease/drug info boxes. These templates encourage a fill-in-the-blanks approach that works against the thinking that is required to see if the link really does meet our WP:EL policy. Some charities and government bodies do have excellent web sites that are a worthy resource to link to, but we need to consider each on its own merits per article. I think the box would encourage the addition of links merely for completeness, and different editors would pile on links for every English-speaking country and US state. Colin°^Talk 07:44, 7 April 2011 (UTC)
  • I wasn't intending to increase the number of links with this but rather cluster them together by type and make them easier to find. I'm not trying to use this to make it so links avoid scrutiny and none of this would change the applicability of existing WP:EL guidelines. —Tom Morris (talk) 07:54, 7 April 2011 (UTC)
• Oppose Wikipedia is prone to misinformation. Let's not make it a lethal fault. ManishEarth^{Talk • Stalk} 09:56, 7 April 2011 (UTC)
  • Could you elaborate? Why would standardising the way we link to a certain class of pretty reliable information providers increase the likelihood of spreading misinformation and potentially lethal consequences? Indeed, providing a way of finding accurate, locally-relevant information for patients is the point of the proposal. —Tom Morris (talk) 10:15, 7 April 2011 (UTC)
    • Well, people usually will trust the info if its handed to them on a platter. If they have to look for it, they'll probably try other faults. I'd be fine with this proposal if it had a process like chemboxes do for verification. See Wikipedia:WikiProject_Chemicals/Chembox_validation ManishEarth^{Talk • Stalk} 11:02, 9 April 2011 (UTC)
• On the whole I support helping patients to find reliable information, but Sven Manguard makes a compelling point about homeopathy. And I can imagine the boxes becoming a battleground for more contentious medical issues like abortion or some mental health problems: we'd need clear guidelines. Is there a big advantage over leaving things in the external links section?--Physics is all gnomes (talk) 21:52, 9 April 2011 (UTC)
• Oppose, Wikipedia is not Boots. Stifle (talk) 10:00, 13 April 2011 (UTC)

Temporary adminship for Coaching

How about when a experienced user applies for Admin Coaching, and a bureaucrat accepts, the applicant is temporarily an sysop, but the applicant asks the coach before doing any action. If would be good to learn the special pages and how to use them. It would be just temporary and the coach would have to accept any action that the applicant does. ~~EBE123~~ ^talk_Contribs 12:11, 10 April 2011 (UTC)

It seems to me that there are two separate parts to admin-ship, first does the community trust the candidate to use the tools in good faith and with an appropriate temperament; and second does the candidate have sufficient experience and understanding of practices and policy to use the mop properly. I think your idea makes great sense in regards to the second part, but as applied to the first, you would have us give a user the admin tool-set before the community has a chance to decide if they are trust worthy. It also runs the risk that a competent admin makes it all the way through the mentoring, only to have the community reject them on trust grounds. I would propose instead that RFA candidates who would have passed if trust was the only concern, but who failed due to concerns about their knowledge of policy, be made probationary admins. They could then be followed closely and either mentored or admonished to be sure they fully research and understand a policy before taking related admin actions. A much lower standard then what applies to current admin removal could then apply to probationary admins who don't seem to be clueful when using the tools. Monty₈₄₅ 17:27, 10 April 2011 (UTC)

Ebe123, if you'd like to be the first participant in any such program, I'd oppose it. But I'd oppose it anyway, because admin coaching is complete unofficial and this proposal would formalize it with some sort of bureaucratic policy that gets in the way of how each coach, well, coaches. /ƒETCHCOMMS/ 03:17, 12 April 2011 (UTC)

Oh, I didn't see this before. It is that at the test wiki, there is a list of places to test them out so, I am asking to close this proposal. ~~EBE123~~ ^talk_Contribs 19:04, 12 April 2011 (UTC)

Local Copy Key Content Hosted on Commons

As a response to Commons deleting an image used hundreds of times on Wikipedia without telling us about the deletion discussion and giving us time to prepare I propose the following safeguards

• Any file that has achieved featured status (Featured Sound or Featured Picture) on English Wikipedia should have a copy hosted locally.
• Any file used on more than 25 pages should be hosted locally.

I have no problem with keeping a copy on commons, but I don't what their unwillingness to communicate with Wikipedia to continue to cause damage to this project. If something heavily used on our project goes up for deletion on commons, someone would have to run a deletion discussion locally. We might end up deleting it too, (or reach a different decision), but at the very least, we'd notice that there was a deletion discussion itself and take corrective steps (finding replacements or delinking) before the image disappears, not after. Sven Manguard Wha? 21:05, 10 April 2011 (UTC)

• Support Sven Manguard Wha? 21:05, 10 April 2011 (UTC)
• Support the local deletion discussion. Make them mandatorily post IFDs on all wikis which use an image more then 'x' times. ManishEarth^{Talk • Stalk} 03:54, 11 April 2011 (UTC)
• Support. I remember from my time at featured pictures that I had to occasionally browse through the FP collection and summarily delist anything that had been deleted on Commons in the meantime. It's annoying, and a waste of time. MER-C 10:15, 11 April 2011 (UTC)
• Support. Haven't been there, haven't done that, don't have the t-shirt, but this sounds sensible and reasonable. A mechanism for Commons to notify WP of commencement of and results from deletion discussions there would be a plus, but such a mechanism outside of WP control shouldn't be relied upon by WP. Wtmitchell (talk) (earlier Boracay Bill) 12:34, 11 April 2011 (UTC)
• Support. Lambanog (talk) 13:02, 11 April 2011 (UTC)
• Strongly support. I'd go even further and move it to "all files currently in use on an en-wiki article are hosted locally", leaving Commons as a strategic reserve of unused images and backup copies of images which other projects may also want to use. The "{{movetocommons}}→deleted on en-wiki→Commons decide it doesn't meet their copyright criteria (which are wildly different to en-wiki's, as en-wiki works on US law and Commons works on law-of-the-country-of-origin)→Commons deletes their copy without bothering to notify anyone" cycle is one of the most irritating experiences Wikipedia can throw at editors, and I'm coming to believe that as a project it's outlived its usefulness to en-wiki. – iridescent 19:40, 11 April 2011 (UTC)
• Strongly oppose. Copyright must be taken into account seriously. It is right that en.wiki allows images under similar licences than commons, under the licence of being PD in the US but not at the home country, or under non-free rationales, but the last two must not be moved to commons anyway, and for the first group, the rules are the same. If we don't clearly use any of the last two types, the rules on what is or isn't a copyright violation, a derivative work, an unsourced image, a treshold of originality, etc; must be the same. To upload a copyright violation or any image with doubtful copyright on purpose here, rather than in commons, counting on that "it won't be noticed", is unacceptable. A copyright violation must be deleted regardless of how many times it is used, and even if it gets featured status (we may decline speedy deletion in such circumstances, but do not ever think that featured images are beyond copyright if the licence details were wrong and nobody noticed it). If the image is free, if you can (as you must) provide the evidence to confirm it's free, upload it to commons and there won't be anything to fear. If it is not free, or you don't know, don't upload it as a free image, anywhere. And if you think that commons deleted an image that was indeed free, appeal the deletion and request that the image is restored. Cambalachero (talk) 20:08, 11 April 2011 (UTC)
  • I take copyright very seriously, and if something is in fact not free use and does not qualify for fair use, it should be deleted. However if something is widely used on this project, we need to be involved in the decision making process. Nothing is to stop the person that nominated the file for deletion from nominating it on Enwiki, where it would proceed like any other FfD. However forcing them to use a local process means that we know that it's up for deletion, and can take corrective steps. An image used hundreds of times suddenly disappearing is disruptive to the project, and as I said below, many on commons see that as "not their problem." Sven Manguard Wha? 21:55, 11 April 2011 (UTC)
    • There's another requirement I forgot: unlike free images, that may be used anywhere under just the limits of style, non-free images must have a rationale for each usage. There is no fair use image out there used "hundreds of times", and if there was image in commons used hundred of times and deleted as a copyright violation, I doubt fair use would have allowed to keep that state of things anyway. As for the "not their problem", that's a misunderstanding: that's not a principle of "commons take priority over other projects", but "copyright concerns take priority over other concerns". Cambalachero (talk) 01:52, 12 April 2011 (UTC)
• Comment. The proposed approach is just a hack. A few years ago the German Wikipedia got bitten after they moved most of their files to Commons (since they have a policy of not using fair use images anyway) and then some of them were deleted due to nuances of copyright law. What we really need is a community that does not stop at the border between different wikis. The easiest way to get such a community would be WikiMedia-wide watchlists. Hans Adler 20:24, 11 April 2011 (UTC)
  • Everything I have come across has told me that won't happen. There are good people on commons, but there are also uncaring zealots. The "that's not my problem" attitude is not only prevalent, but widely accepted. Until they change policy to mandate communication, we cannot trust that they will speak with us when they should. Sven Manguard Wha? 21:55, 11 April 2011 (UTC)
• Oppose. I have recently implemented the Commons fair use upload bot, which is designed to re-upload images to En as fair use candidates before deleting them on Commons, which will obviate this issue as soon as people start using it. Dcoetzee 20:28, 11 April 2011 (UTC)
  • off-topic, but I think that bot is a very bad idea. There are too many cases where a copyright violation can't be hosted as fair use either: unused images, images whose usage do harm the hability of the copyright holder to exploit the image (such as collect-cards), images for an article that already includes fair use images and the new ones can not be justified, unpublished derivative work images (such as fan art), duplicated images, etc. Fair use images should always be uploaded by a human, after considering the context and the expected usage. Cambalachero (talk) 20:48, 11 April 2011 (UTC)
    • The whole reason this proposal is necessary is that many Commons users really don't care how their actions affect the other projects. What makes you think that they would expend any of their precious, precious time to upload back to local projects when they are not willing to expend any time telling the local projects that files those projects use are up for deletion? No offense, but I fully predict that this bot will be very much underused. Sven Manguard Wha? 22:04, 11 April 2011 (UTC)
      • As I understand it, the proposal is that the bot will automatically monitor Commons' deletion log, and everything they don't see fit to grace the hallowed turf of Commons will be automatically deleted there and dumped on en-wiki with a pre-formatted deletion debate, along the lines of "we don't want this, so discuss if you want it or if it should be deleted altogether". The principle is sound, although I suspect the net result will just be that it swamps WP:FFD with 200+ pages at a time and gets blocked for disruption. – iridescent 22:08, 11 April 2011 (UTC)
        • Oh. Either way, I think my option will be better, at least for protecting our most important content form Commons thoughtlessness. Sven Manguard Wha? 22:15, 11 April 2011 (UTC)
    • @Cambalachero: you don't understand how the bot works. Images are uploaded into a special category Category:Fair use candidates from Commons and reviewed by users on En, and deleted if nobody wants to keep them after a certain number of days (or at least that's how I propose the policy will work). @iridescent: FFD will not be flooded - preventing this is precisely the purpose of the proposed speedy deletion criterion. @Sven: Because the bot automatically informs articles which use the image, I don't believe any high value images would slip under the radar in my proposed system. This bot has already been approved for a trial via the En bot approval process. I think this is a much more practical solution to the problem than the maintenance nightmare created by this proposal's needless duplication of content. Dcoetzee 00:22, 12 April 2011 (UTC)

• Regarding the errors of Commons, please see Ultimate attribution error. This problem is solved by more communication with Commons, not by isolating us from them. Hans Adler 22:38, 11 April 2011 (UTC)
  • Commons has had years to come up with something. This is not a new problem. Clearly the easy solution of "more communication" hasn't gotten anywhere. Something has to give. Sven Manguard Wha? 07:00, 12 April 2011 (UTC)
• Support, at least until there's some mechanism in place for automatically notifying projects that a widely-used or heavily-viewed image is in danger of being deleted. I can see no downside whatsoever in keeping a local copy that would weigh against the obvious advantages of doing so. 28bytes (talk) 01:21, 12 April 2011 (UTC)
• Oppose Dcoetzee's solution (above) is a better approach. More communication (suggested by Hans Adler) would be helpful, also. Walter Siegmund (talk) 02:11, 12 April 2011 (UTC)

• Oppose. Copying images with 25+ uses over will not solve the issue unless you want to go and duplicate Commons one-to-one. I would like to remind you that the deletion of the image that spurred the previous discussion leading up to this one was not a result of a deletion discussion but rather a "no permission" tag. There are images lacking permission from the source the uploader specified, images without sources, images without licenses, images stated to have permission sent in to OTRS but never received, images that had emails sent to OTRS that were insufficient. It's taken me quite some time just to bring some of those backlogs to the point where the by-date categories don't go back into last year. I can barely keep up as it is, much less make notifications for a prod-type situation for the hundreds of non-deletion-request images I manage to process in a day, then track which ones I or someone else made notifications for and keeping in mind a seven day period after that (which won't match the day that the other tag was applied), then come back a second time and check all talk pages on all projects for the uses of the image for any objections before finally deleting. And that doesn't take into account that I only know English and would be unable to notify any non-English projects! All that as opposed to deleting after the uploader has been notified and the tag placed on the image for over a week and most times longer. The backlogs I've been going through have had a lot of images used here in only one or two instances. You should direct your wrath to those who don't properly gain permission for their uploads or provide sources and then put the images in use here. A better solution would be to have one of the talented bot operators here monitor the deletion requests, but also no permission/no source/long-pending OTRS/unresolved OTRS tags. The frequency of my actions on the latter can rival others' on the former. Adrignola (talk) 02:39, 12 April 2011 (UTC)
• Oppose No, it would split off enwiki files from Commons discussions. If a Commons file is deleted as a copyvio (yes, this has happened to FPs), then what if the local one is not deleted, either? The problem appears to be Commons; we need to change that or set up a system like Adrignola suggests, with a bot or similar mechanism. /ƒETCHCOMMS/ 03:15, 12 April 2011 (UTC)
• Comment In addition to the Commons fair use upload bot described above, I am planning a bot that will inform local projects (on article talk pages, in their own language) whenever any Commons images is under threat of deletion for any reason (deletion request, no permission tag, no source tag, etc etc). I think this warning will increase engagement of Commons with concerned local editors before the deletion occurs. Dcoetzee 04:18, 12 April 2011 (UTC)
  • Strike the above - what we actually need to do is activate CommonsTicker on this wiki. Dcoetzee 08:37, 12 April 2011 (UTC)
• Oppose as pointless. We can reupload the image here if needs be. Stifle (talk) 11:42, 12 April 2011 (UTC)
• Support The "commons" experiment is a failure. Gigs (talk) 13:30, 14 April 2011 (UTC)

  What is that supposed to mean? --Yair rand (talk) 14:23, 14 April 2011 (UTC)

• Oppose. --Yair rand (talk) 14:23, 14 April 2011 (UTC)

Comment: Adrignola's bot idea is a much better solution all round. We should have a bot to monitor (mirror?) Commons deletion/problem tags and/or make a central list of files affected here which are "key files" per criteria above. Rd232 ^talk 10:26, 15 April 2011 (UTC)

Replacing the {{Hang on}} tag process

When a page is tagged for speedy deletion, the speedy deletion template contains a message explaining to the creator that of they wish to contest the deletion they should place the tag {{hang on}} on the page and then edit the talk page, explaining why the page should not be speedy deleted. Two recent discussions have taken place regarding getting rid of this hangon tag process:

• One at the talk page the CSD; and
• Another higher up on this page.

Some of the issues that have been raised for scrapping the process are:

• Despite the seeming simplicity of the instructions, hangon tags are very often misplaced, and misunderstood: They are placed on the user's talk page; they are placed on the article's talk page; they are placed correctly in the article but not in the correct place, and commonly they are placed in place of the speedy deletion template. A check of 16 articles with hangons was noted in the discussion at WT:CSD and only three were placed properly (this implies that an unknown number of users may have tried to contest a speedy deletion but never managed to place the hangon tag at all);
• Many new article creators do not appear to understand that the act of placing the hangon tag itself has no ability to avoid speedy deletion, but that it is just a prelude to writing a talk page rationale. In that way, the hangon tag may actually hinder them from doing what is necessary to avoid deletion by giving them a false impression that the tag itself has some power;
• They are essentially redundant. All administrators are supposed to check talk pages before speedy deleting, and the placement of the hangon tag appears to have little or no affect on whether a page will be deleted or on the timing of that deletion; only a talk page post that addresses the deletion directly does. In other words, one of the ostensible purposes of placing hangons—to inform admins that a protest is going to happen—is ineffective and just forces creators into a two-step process. What matters is whether a sufficient reason has been given not to act on the speedy deletion tag on the talk page, and that talk page post should be seen by the reviewing admin regardless of whether a hangon tag has been placed.

The issue then, if we decide to get rid of them, is what alternative mechanism to put in place? What has been worked on is a direct link in the speedy deletion templates that takes the user to the talk page with a preformatted area to post their reason for contesting the tagging. Give it a try: . Note that the button detects what namespace the tagged page resides in and will say article/page/template etc. in its preformatted headline, depending on what is up for speedy deletion. Meanwhile, the template detects whether the talk page has been created or not. If it remains a red link it displays the following message:

Note to page author: you have not edited the talk page yet. If you wish to contest this speedy deletion, clicking the button above will allow you to leave a leave a talk page message explaining why you think this page should not be deleted.
If you have already posted to the talk page but this message is still showing up, try purging the page cache.

. If, on the other hand, the talk page does exist, the template will display instead the following message:

Note to administrators: this page has content on its talk page which should be checked prior to deletion.

The draft of this template incorporating these features is at {{db-meta/sandbox2}}. If consensus can be reached, this would replace the current template that all of the db- templates use, located at {{db-meta}}. You can test the template using {{a7-test}}, created for this purpose (it would be best to use the preview button only when doing so). One note: unless some brilliant soul can find a workaround, this will not work with Category:Contested candidates for speedy deletion, so we would lose that category. What say you?

--Fuhghettaboutit (talk) 19:45, 11 April 2011 (UTC)

--Yoenit (talk) 19:45, 11 April 2011 (UTC)

• Excellent proposal. Unless someone finds a very good reason against it, I support it. Hans Adler 20:04, 11 April 2011 (UTC)
• Strongly support this. I can't see any negatives at all. The only thing I'd say is, preserve a non-button method as well for the small but still significant minority who access Wikipedia via a text interface. (Thanks to Amazon's unusual approach to user-friendliness when designing the Kindle, this minority is larger than you might think.) – iridescent 20:08, 11 April 2011 (UTC)
  • Perhaps we could change the wording above the button somewhat so it is more clear that posting on the talkpage directly is a valid alternative. The red text is quite clear, but will not always show up. Yoenit (talk) 20:26, 11 April 2011 (UTC)
• Support the concept, but should the warning when a hold on request has been made be more visible? And is there a way to distinguish wiki project inclusion tags on the talk page from hold on requests? My concern would be that the project tags go into the forum, then a CSD tag gets placed, and it no longer provides instruction to the creator because the talk page exists from the project tags. Monty₈₄₅ 20:20, 11 April 2011 (UTC)
  • nope, unfortunately not. Only the red warning will disappear when a talkpage exists though, the template and button itself will still tell you to post on the talkapge. Yoenit (talk) 20:26, 11 April 2011 (UTC)

Regarding the above two issues, I have added this text to the template "You can also visit the talk page directly and tailor your own message or to see if you have received a response to your message and continue that discussion."--Fuhghettaboutit (talk) 20:47, 11 April 2011 (UTC)

• I like this idea a lot. The only concern I have is time-lag. A user can add a {{hang on}} tag in a very few seconds, then take his/her time composing the full reasons why the CSD criterion does not apply. A good admin will check the timestamps and should grant a few minutes, maybe even an hour or so for the comments to show up on the Talk page.
  With this process, users have a bias toward making their case in that very first post. While a longer, slower and more detailed message is better for the discussion, it's going to be counter-productive if the page gets deleted in the meantime because no one knew that you were working on your explanation.
  Can a button perform two functions - first to add some small flag that a comment is coming (maybe by posting the section header) then a second to open the edit pane? Or is there some other way to solve the time lag? Rossami (talk) 20:56, 11 April 2011 (UTC)
  • There is no way to make the pressing of the button itself cause a message to be place in the article, or at least I was told it was essentially impossible when I asked one of our best template programmers how to do this. My impression from experience is that the placement of hangon tags themselves rarely delays deletion, though I have no empirical study on this (and of course you may always do this and be an exception). But if that's a sticking point, and there is no workaround, then it comes down to a balancing test. Do the problems with hangon that are solved by this outweigh what we lose?--Fuhghettaboutit (talk) 21:11, 11 April 2011 (UTC)
    • I do see the hangon tags getting some deference, at least for articles that look like they're being started in good-faith. The speedy-tag is being used almost as a "please fix this immediately" tag rather than for it's original purpose.
      You're right about the balancing test. If there's no other way around it, this is still an improvement. Maybe two related tags instead? A first button click that creates the section header on the Talk page and transcludes a second "click here to explain your reasons" button which opens the section and allows the overwriting of the "click here" line? I'm hoping that's not as complicated as it sounds.
      By the way, if this process is adopted, we will have to update the user-notice tag as well. Do we have a draft of that one yet? Thanks again for taking the initiative to work on the problem. Rossami (talk) 21:31, 11 April 2011 (UTC)
      • The two clicks is a really interesting idea! Let me think about that. I'll work on the user tags directly.--Fuhghettaboutit (talk) 22:15, 11 April 2011 (UTC)
      • I just played around with how to do this but I'm afraid it's beyond my coding skills. I thought maybe I could use a preload template containing hangon and created {{Hangon click preload}} for this, but as far as I can tell there's no way to get a preload url to work to place text on an existing page and in a specific spot on that existing page.--Fuhghettaboutit (talk) 23:15, 11 April 2011 (UTC)
        • Regarding a draft for user warnings, I've just put one up at {{Nn-warn/sandbox}}. Obviously this will need to be tweaked for other warnings, but the gist is there.--Fuhghettaboutit (talk) 22:33, 11 April 2011 (UTC)
        • If we write (or have someone else write) a javascript that does it, we can add it to the link using "&withJS=<js location>". Cheers. lifebaka++ 04:11, 12 April 2011 (UTC)
• Support - Wording of the statement opened by clicking the button is a bit long, with all the who-ha about tildes and such, but the idea is a five-star winner. Simplification is good. Carrite (talk) 22:26, 11 April 2011 (UTC)
• Support - Agreed about the inefficacy of the existing '{hangon}' process. Quarl ^(talk) 01:40, 12 April 2011 (UTC)
• Support Sensible proposal that is worth a try. Goodvac (talk) 01:49, 12 April 2011 (UTC)
• Support. This seems like a well-designed solution to an obvious problem. I agree with Carrite about dropping the tilde reminder; it's just one more thing for an article creator to stress over and it's really no big deal if they don't sign their plea on the talk page, since the admin can easily figure out who wrote it. 28bytes (talk) 02:06, 12 April 2011 (UTC)
• Support, but prefer an easy javascript solution. See below. /ƒETCHCOMMS/ 03:04, 12 April 2011 (UTC)
  • • Per opinions above I have shortened the talk page preload by removing the signature instructions. Being unsigned is no barrier for us, whereas the instructions may be a complicating barrier for some users.--Fuhghettaboutit (talk) 11:15, 12 April 2011 (UTC)
• Support This is a good proposal. ~~EBE123~~ ^talk_Contribs 19:12, 12 April 2011 (UTC)
• Yes Newbies screw up hang-on tags more often than not. It's not reasonable to expect them to get it right. Gigs (talk) 20:00, 12 April 2011 (UTC)
• Support Lets be bold and implement this right away. Lugnuts (talk) 07:00, 13 April 2011 (UTC)
  • The only thing we would need to wait on is making the (many) user notices we will need including those that Twinkle uses. The form is at {{nn-warn/sandbox}} and I'll get the equivalents for the others done tonight.--Fuhghettaboutit (talk) 12:50, 13 April 2011 (UTC)
• Support, though this could make opposing speedy deletion without understanding of CSD much easier. I'd also support Fetchcomms's idea, if implementable. Guoguo12--Talk--  20:20, 13 April 2011 (UTC)
  • We're up and running. I have changed numerous templates to conform with the new process and am looking for those I missed now.--Fuhghettaboutit (talk) 00:12, 14 April 2011 (UTC)
    • I think I;ve got them all, I've also requested full and indefinite protection for the button image on Commons and will go protect the templates the new db-meta transcludes.--Fuhghettaboutit (talk) 01:35, 14 April 2011 (UTC)

• Neutral — the button itself looks dreadful, and sits awkwardly in the centre of the template. It'd be much more preferable to replace it with a similar line of text. Mephistophelian (talk) 16:14, 14 April 2011 (UTC)
• Support: Out of my time patrolling new pages, most of the article creators have failed to correctly place the {{hang on}}. --43?9enter ^☭msg_☭contribs 21:44, 14 April 2011 (UTC)
• Support. Pure genius. Implement it now. Herostratus (talk) 00:18, 15 April 2011 (UTC)
• Support A little on the ugly side, but a definite improvement in usability. Kudos! --JaGa^talk 17:58, 18 April 2011 (UTC)

New category

As noted, one thing we have lost is the category for contested candidates for speedy deletion. Even though it wouldn't be as targeted, what does everyone think about having a category for speedy delete candidates with existing talk pages? (I'm not sure of the title to use). This would be added to {{Hang on/notice3}}.--Fuhghettaboutit (talk) 13:27, 14 April 2011 (UTC)

I have implemented the new category: Category:Speedy deletion candidates with talk pages. It is limited to tagged articles in the mainspace that have talk pages. It shows at CAT:CSD as Possibly contested (0), and is named that way since it cannot detect whether pages actually have protests but only whether the talk page exists so not all pages inside it will always have protests.--Fuhghettaboutit (talk) 23:25, 15 April 2011 (UTC)

Alternative solution

Go to Wikinews and pick out an article in the "In development, undisputed" section. Notice how the blue message box has a button that says "change", which, if clicked (if you click it, be sure to revert yourself), removes that template and adds a different one. We implement the same javascript on enwiki, put it in the CSD templates, and if a user clicks the button, the js automagically inserts a hangon tag. All we really need to do to make this perfect is for a js popup to prompt for why the page should not be CSD'd, and put that as a parameter in the hangon tag. This would let the reviewing admin look at the reasoning directly on the article (like a prod), instead of opening the talk page as well. Can a techy person look and see if this is feasible? /ƒETCHCOMMS/ 03:04, 12 April 2011 (UTC)

Interesting possibility. It couldn't work just by replacing the CSD template with the current form of hangon tag, or we would be forced to go to history and to the prior version each time to see what the article was tagged with, plus we would lose the ability to have the deletion dialogue preload the deletion summary from the db templates. So I suppose this would need to be coded to detect which speedy template was used and include that with the hangon? I imagine if so we would need either a different version of hangon for each speedy deletion template, and which one would automagically replace the CSD template would be detected by what species of db tag was placed (though multiple tags might be a problem), or alternatively, the new form of hangon would have some kind of multi-parser that would draw from a pages with text for each db-rationale. Anyway, we would need someone very technically proficient and interested enough to help.--Fuhghettaboutit (talk) 11:51, 12 April 2011 (UTC)

I think the code could be tweaked just to add the hangon without removing the original CSD, or to have a parameter in the hangon that says which CSD tag was originally on. (I don't think the technical part is very hard; just wanted to see if anyone thought this would be a more newbie-friendly solution than preloading text/bringing them to a whole other page and possibly confusing them in the process.) I'll ask around to see if this could be done; if it can, do you think it would work or be easier than the original proposal? /ƒETCHCOMMS/ 21:48, 12 April 2011 (UTC)

You know it's hard to say until you see it in a test form, which may reveal options we can't think of now as well as limitations resulting from the mechanics. However, if it can be tweaked so that clicking the button places the hangon tag on the page automatically but still functions the same way to take the user to the talk page with the preload, that would certainly be an improvement, would require changing nothing in this proposal, and is what I ideally wanted to do from the get-go but was told was technically impossible. That would also save the contested CSD category. However, unless we see someone willing to take on the full task very soon, I think we should go ahead and implement this. I will happily do the heavy lifting, such as creating forms for all warning notices that refer to hangon.--Fuhghettaboutit (talk)

• Very strong support' on multiple levels. Not only would this be great for allowing new users to get familiar with how Wikipedia works, and allow the page to not have two massive templates that makes it unreadable, but it would also promote discussion and not just arbitrary decision. Full support. Ajraddatz (Talk) 01:44, 15 April 2011 (UTC)
• OK, with the help of Bawolff (talk · contribs), I have an example up at User talk:Fetchcomms/Sandbox 5. It will require this code in your user js:

Code

addOnloadHook(function () {
    var changeCSDToHangon = document.getElementById('hangonbutton');
    if (changeCSDToHangon) {
        try {
            importScriptURI('https://secure.wikimedia.org/wikinews/en/w/index.php?title=user:Bawolff/mwapilib2.js&action=raw&ctype=text/javascript');
            var button = document.createElement('button');
            button.type = 'button';
            button.appendChild(changeCSDToHangon .firstChild.firstChild);
            changeCSDToHangon .replaceChild(button, changeCSDToHangon .firstChild);
            button.onclick = function () {
                var hangonReason = prompt("Why should this article not be deleted yet?", "");
                if(!hangonReason) return alert("You must provide a reason for why this page should not be deleted!");
                if (this && this.firstChild && this.firstChild.data) this.firstChild.data = "Loading ...";
                api(wgPageName).getPage().
                    setDefaultSummary("Please do not delete this article yet").
                    replace(/^/, "\{\{hangon|" + hangonReason +"}}\n").
                    savePage().
                    lift(function () {
                        alert("Tagging successful!");
                        location.reload();
                    }).
                    exec();
            }
        }
        catch (e) {}
    }
});

• Can a few people try this? I'm still trying too see how to get it to prompt for a reason for the hangon, however. /ƒETCHCOMMS/ 23:48, 15 April 2011 (UTC)
  • I now have it where a prompt appears and passes that as the reason param in the hangon tag. Please try the updated code in the above collapse box and see if it works. /ƒETCHCOMMS/ 20:11, 16 April 2011 (UTC)

It works great! This is much better than the current proposal, IMO. However, make sure to give some more space for the rationale in the prompt, both to allow more text to be written without the beginning of it sliding out of sight, and to encourage better thought-through rationales. --Waldir ^talk 00:47, 17 April 2011 (UTC)

This is very interesting. It shows there is a possibility to place the hangons back in an effective way. However, I think it should work in a quite a different way. What I would imagine would be ideal would be as follows. When a person clicks the button they are transported to the talk page just as they are now, where they can write their rationale with the preload instructions in place. Meanwhile, the clicking of the button would also place the hangon on the article to show that the button had been pressed. providing the normal hangon alert (which would also get back the full functionality of the contested category). The way it operates now is not ideal for a number of reasons. (to lurkers, none of this will make sense unless you try out the code to see what it does).

• First, people need to be able to read the text they write as a unified whole; to go back over it; to compose a complete response possibly over a few paragraphs; to be able to preview it and so on. Writing text in a small text field is incredibly hampering (this format also pretty much guarantees that posts will never be signed by new users).
• The protest needs to be placed at a discussion format, i.e., a talk page. The way this is set up, after the initial post appears in the hangon, there's effectively no way to respond but to click edit this page on the article, then figure out that the text posted is the parameter in the hangon tag ({{Hang on|creator's protest text}}), then use relatively advanced markup right next to the text, such as using <p> to offset a response, and then saving. This will not format well, but it would work somewhat as a response but many users will not know how to post a response at all, and very few creators will know how to respond thereafter. There are often talk page backs and forth on contested deletions and this simply will not allow that or make it so unwieldy to do so that it might as well be seen as a complete bar.
• I don't think the protest should be in the article at all. As someone who has reviewed thousands of db-tags, I can tell you that sometimes we get "FUCK YOU ASSHOLE!" and much worse, such as BLP violations, as the talk page response; now they will be on public view in the article.
• We occasionally see a reason to keep talk pages of CSD discussions even when the article is deleted, but now the discussion is part of the page, so if we delete it, perforce, we delete the discussion. And if we keep the article, the normally behind-the-scenes deletion discussion is permanently part of the page history barring revdeletion. Would we want that?--Fuhghettaboutit (talk) 06:03, 17 April 2011 (UTC)

I like the {{hangon}} + talk page combination, if that can be made to work. We shouldn't rely on editors having JavaScript turned on. With JS off, at least they'd get their message onto the talk page. -- John of Reading (talk) 06:40, 17 April 2011 (UTC)

• OK, so I've created User:Fetchcomms/hangon.js, which creates the button, adds the hangon when clicked, and then redirects to the talk page editing screen with current preload text. Instead of adding all the code to your js page, just add importScript('User:Fetchcomms/hangon.js'); to it and try this at User:Fetchcomms/test (because my previous test page was on a talk page already). Thanks for the feedback, /ƒETCHCOMMS/ 20:01, 17 April 2011 (UTC)
  • Actually, I'll need to tweak the code to work on non-mainspace pages, so don't try that just yet! /ƒETCHCOMMS/ 20:03, 17 April 2011 (UTC)

You were too slow with your second post, and I had already tried it. The button changed to "Loading..." and nothing else happened. I didn't manage to add a "hangon" tag to your test page. -- John of Reading (talk) 20:12, 17 April 2011 (UTC)

Hm, can you try purging and trying again? I fixed the code and it's now working for me. If it still doesn't work, wait for a bit and see if it's just the js being slow; otherwise, I'm not sure what's going on. /ƒETCHCOMMS/ 20:52, 17 April 2011 (UTC)

Two messages on the Firefox error console when I press the button: (1) Empty string passed to getElementById (2) api(wgPageName).getPage is not a function - is there some other stript I have to load before hangon.js will work? -- John of Reading (talk) 21:15, 17 April 2011 (UTC)

Looks nice :) Two things:

1. Change the wording of the message "you're not done until, etc." to something maybe like "A hang-on notice has been added to the page. You must now add your reasons in the edit box that will show up next, otherwise the request to stop the deletion process will be denied."
2. Use the editintro url parameter to provide further instructions, guidelines, links, etc. It could link to an empty page right now, which can later be filled with relevant content. --Waldir ^talk 22:56, 17 April 2011 (UTC)

John, the script utilizes wikinews:user:Bawolff/mwapilib2.js, but that's for creating the button (I think that's the main thing it does), so I'm not sure what's causing your errors—I'm asking someone with a background in javascript to take a look. /ƒETCHCOMMS/ 01:56, 18 April 2011 (UTC)

• Support Much more newbie-friendly and easy, it'd save NPPers, admins and CSD patrolling users a lot of hassle. —James ^{(Talk • Contribs)} • 9:39pm • 11:39, 18 April 2011 (UTC)

What a great combination! Works great. Thanks for working on this Fetchcomms. I suppose the next step is to talk to developers about adding this to the sitewide js file (no idea what it's called)? Have you spoken with anyone yet? User:Tim Starling might be the right person to talk to, though I'm not sure. I would change the text a little bit. Right now it tells the user, in part, "If you do not explain why, your request to prevent deletion will be denied", which implies that if the person adds a reason to the talk page, the page will not be deleted, regardless of the reason provided. The text also assumes it's an "article" and it doesn't tell the person what the purpose of the hang on tag is, as the prior text in db-meta did when it decribed placing the hang on tag. Also, I think hang on should be in quotes here. I would suggest changing it to just: A "hang on" notice has been added to the page. This will alert administrators that you intend to dispute this speedy deletion by explaining why you believe this template should not be deleted on the next page.--Fuhghettaboutit (talk) 01:00, 19 April 2011 (UTC)

Well, any admin can add it in now to Mediawiki:Common.js. However (after I tweak the message as you said), there are two concerns I have that I'd need someone who knows js well to look over: 1) It will work for users with js disabled (just need to change the link in my actual sandbox/test page to the preload one), but I'm not sure about overall accessibility. I'd like some wider testing, at least, first—can you ask a few NPPers or something to check out this thread and test out the js? 2) Bawolff, who was the original author of the base button code, told me that, because this uses a custom javascript library (the Wikinews thing I linked to above), it's slightly hacky and not perfect—good enough for us, yes, but probably not for all users, registered and anonymous. As a result, he suggested the button-creating code be rewritten in jQuery; however, I only know enough to tweak existing code, not devise something from scratch. I'll ask a few javascript wizards to see if they have time to do this, because the current code probably shouldn't be in Mediawiki:Common.js at this point. Thanks for testing the code! /ƒETCHCOMMS/ 02:37, 19 April 2011 (UTC)

A problem

The recently implement changes direct editors (who don't carefully read every word of the db warning) to place their hangon rationale at File_talk:Speedy_delete_contest_button.png. One has already and I expect more to come. The button should probably be unlinked from the user talk page notice, but I can't do that myself unless the license is changed from CC-BY-SA to PD. Suffusion of Yellow (talk) 00:48, 14 April 2011 (UTC)

Damn, I'm sure it's something from one of the talk page notices, not the db-tags. Let me start testing them.

--Fuhghettaboutit (talk) 00:52, 14 April 2011 (UTC)

Yes, I meant the talk page notices. I haven't noticed any problems with the article tags. Suffusion of Yellow (talk) 00:56, 14 April 2011 (UTC)

Okay, I know what's going on. Some of the talk page notices actually provide the button with the same capability as the button in the db tags (where the template always has the article name as a parameter so that that can be passed through to {{{1}}}) and some of them say instead "If you do not believe the article deserves to be deleted, then you may contest the deletion by clicking on the button that looks like this: which appears inside of the speedy deletion... Of course some percentage of users aren't going to read and will click on the button, if it's clickable, so I need to go make it unclickable where it's used like this.--Fuhghettaboutit (talk) 01:01, 14 April 2011 (UTC)

All fixed—the image links in the notice templates are now unclickable. Thanks for looking out!--Fuhghettaboutit (talk) 01:18, 14 April 2011 (UTC)

• • Looking at how it is now being used, all editors , not just the author, are likely to use the button, instead of doing what they are actually directed to do, which is to simply remove the db template and say why on the talk p. or the edit summary. A rewording (and drastic shortening) of the template might help, and I'm going to try one. DGG ( talk ) 04:16, 15 April 2011 (UTC)

Preload content

Thanks, Fuhghettaboutit. The new button is nice. Now that it's been implemented do you mind moving the discussion to Template talk:Db-meta? One issue I've noticed is that hangers-on, who are 99% newbies, don't understand Wiki markup or HTML. So they write their don't-delete rationale inside <-- --> comments, which may be missed by the admin. I suggest we replace the comment characters with language that makes it obvious the template language needs to be replaced. Quarl ^(talk) 04:32, 14 April 2011 (UTC)

Now that you raised it, it's pretty obvious that this would be happening. It's also no burden on us if the preload text is left in place sometimes. I'll remove the comment out tags now. So, do you think we should just copy the entirety of this discussion to the template talk page?--Fuhghettaboutit (talk) 10:08, 14 April 2011 (UTC)

On the talk pages of articles I look through for speedy deletions, I still see the default message up, which doesn't get replaced:

== This article should not be speedy deleted because... ==

Replace this text with your reason for contesting the speedy deletion and then click "save page" below. ~~~~

And then they type their message immediately afterwards or even copypaste what is displayed above. I don't know if there is a way hide this instruction (i.e. via commenting out or something else) without getting in the way of those who are a bit on the slow side? Commons uses various user scripts, many of which are fairly clean and newcomer-friendly, to handle many deletion requests over there; we could implement something like that with this, if site-wide scripts are desired. –MuZemike 09:21, 15 April 2011 (UTC)

It was originally commented out, but this was replaced by the current message because of fear users would break it and end up commenting out their entire post. I can think of two possible alternatives:

1. Use an editnotice to convey the information
2. Change the text to something like this:

== Contested Deletion ==

This page should not be speedily deleted because...

The first option would removed the text completely, while in the second scenario the user hopefully understands he can continue the sentence with his rationale. Yoenit (talk) 10:29, 15 April 2011 (UTC)

I think the second is likely to work much better than the current and can be changed immediately. Let's try it. Not sure about a editnotice. AFAIK that require a separate page to be created each time in the form Template:Editnotices/Page/Talk:NAME. So every speedy deletion protest will create a new page that would only be applicable to the creator and each one would have to be separately deleted when the speedy deletion is done.--Fuhghettaboutit (talk) 11:45, 15 April 2011 (UTC)

The <inputbox> syntax allows for a parameter "editintro=PAGENAME" which makes PAGENAME act as an edit notice. -- John of Reading (talk) 22:41, 15 April 2011 (UTC)

Neat. So I created an editintro for the preload, {{Hangon preload editintro}}, but I don't know if we should use it, or at least use it for the purpose of telling them to leave the tildes in place. You can view what it looks like in the preload at this URL. What seems silly to me is that following the editintro text, quite redundantly at least in part, the sitewide talk page notice already says "This is a talk page. Please respect the talk page guidelines, and remember to sign your posts by typing four tildes (~~~~)". Please do edit this editintro template, possibly removing the stuff about tildes entirely with a different relevant message.--Fuhghettaboutit (talk) 08:37, 16 April 2011 (UTC)

You're right, the signature isn't that important. With a bit more effort, there could be one editintro for each speedy deletion criterion: "To contest an A7 you need to show..." -- John of Reading (talk) 08:57, 16 April 2011 (UTC)

Pretty sure your are referring to an editnotice— an editintro is a bit different. See WP:EDITINTRO. ---— Gadget850 (Ed) ^talk 22:44, 18 April 2011 (UTC)

Ah— inputbox uses the term for something different. ---— Gadget850 (Ed) ^talk 12:04, 19 April 2011 (UTC)

Editintro text

Everyone please take a look at the very rough draft of text that will make up the page notice on the talk page when the creator clicks the button. Please edit it as you see fit. It is at {{Hangon preload editintro}}.--Fuhghettaboutit (talk) 13:11, 18 April 2011 (UTC)

Looks useful but a bit long, especially if we're expecting people to follow the links too. Would it be feasible to do a different one for each CSD criterion, so they could explain the specific problem rather than being so generic? --Physics is all gnomes (talk) 22:23, 18 April 2011 (UTC)

An idea: most newbies don't realise they can ask for userification - in a lot of borderline cases that would be a nice, non-bitey option to offer, so they could have time to improve the article in their own userspace. Could we offer people that option here? (Obviously the admins could decline in cases of articles that are never going to be encyclopedic.)--Physics is all gnomes (talk) 22:28, 18 April 2011 (UTC)

If there's a way to tailor it for each criterion that would be great but I wouldn't know where to start. It would need to detect what CSD template the project page was tagged with. As for the second part, as I said, "please edit it as you see fit." Go ahead and add some text, cut down the length, etc. The template is not live, just a draft.--Fuhghettaboutit (talk) 01:18, 19 April 2011 (UTC)

'Introduction to _' or 'Beginners _' pages.

For many people, from university students to consumers, Wikipedia is both the first port of call and the last word on any topic they wish to research. But Wikipedia, as an encyclopedia, is often written only as the latter - it has to be right, not necessarily easy to learn.

What I propose is a sister institution to Wikipedia dedicated to being a teaching guide, helping people understand just what the Wikipedia article on a given topic is saying. So, in the pages for quantum physics or DDR SDRAM there could be a link to a simpler page written more like an introductory lecture as opposed to a course summary.

Jezaraknid (talk) 05:46, 12 April 2011 (UTC)

We have a few of those, for example: Introduction to quantum mechanics. If you think another topic should have such a introduction page feel free to write it. Yoenit (talk) 15:32, 12 April 2011 (UTC)

I wonder if perhaps it would help if more people were aware of {{wikiversity}}? --Moonriddengirl ^(talk) 16:08, 12 April 2011 (UTC)

Proposal to make userrights self-sufficient

In view of the fact that adminship is not presently a social requirement for higher privileges such as CheckUser, Oversight, and Bureaucrat, it is proposed that these user groups be made self-sufficient by adding certain rights (currently found in the administrative toolset) to each bundle.

This discussion is intended to focus on addressing the technical limitations present in the current makeup of user groups/rights. The related question - whether the administrator privilege should be a social requirement for such privileges - is being discussed elsewhere, and carrying out this technical change would not preclude the ability of the community to implement such a requirement if consensus were found for the same.

Discussion initiated by –xeno^talk 15:13, 12 April 2011 (UTC)

This proposal is being considered at Wikipedia:Requests for comment/Make userrights self-sufficient. –xeno^talk 15:38, 13 April 2011 (UTC)

Article wizard extension

There is currently a discussion on restricting article creation to confirmed users. Independently of this, we could request that an extension be developed to provide for a wizard/guide on creating an article, this would be an improvement to the article wizard. When a user (registered or not) attempts to create an article (by editing a nonexistent article), they're directed to a special page which acts like a wizard. The pages of the wizard can be customized by admins on mediawiki pages. There should be a way for users to bypass the wizard and deactivate it completely at least when they're autoconfirmed. This would detect if the user is unregistered or not, and confirmed or not to give the appropriate creation options. This would be of great help for new users who most often don't know how to create an article. As an intermediary between the current status and full restriction, there is the possibility that new users could be required to use the article wizard for creating articles, without having to put them to AFC. Until such an extension is made, we could try to see if there are reasonable ways to approach the desired result, such as using javascript to direct new users to the article wizard. Cenarium (talk) 20:57, 12 April 2011 (UTC)

I've kicked around similar ideas in the past. It would require a little bit of user testing and acceptance, but I think the overall idea is solid. SDY (talk) 15:34, 13 April 2011 (UTC)

Cenarium, what is it you don't like about the updated wizard (which now gives AFC, draft and live article creation options)? Seems excellent to me, and my suggestion is that it become the required method of starting the first article for all users. Yes, a veteran editor might be quite well versed in policies, but the wizard is useful for checking these off. And it's only about half a dozen clicks to get through it. This would also be in the spirit of avoiding a hierarchy - a core principal. RedactionalOne (talk) 17:26, 13 April 2011 (UTC)

This is not that I don't like it, but most new users don't get to it and instead create their article on the fly, a special page would present them straight away with an article wizard, the form of which can be the same of the current article wizard. Cenarium (talk) 10:55, 14 April 2011 (UTC)

I support RedactionalOne's suggestion of making use of the updated article wizard the required method for all users starting a first new article (or perhaps even the first several articles). I agree that the updated version is user friendly, and this method would be greatly beneficial to first-time article creators in determining whether or not the article about to be created meets the basic WP guidelines or whether it would be best for the user to utilize AFC before proceeding further. This would benefit WP in general by likely reducing the number of unencyclopedic articles created as well as improving the quality of new content added.--JayJasper (talk) 17:49, 13 April 2011 (UTC)

We should have a culture of improving existing articles, not making even more stubby ones. New editors with an idea for a new article should be encouraged to discuss it and get advice/help from experienced editors before they even start to write it. There should in general be fewer forms and wizards, and more human interaction. 69.111.194.167 (talk) 07:54, 14 April 2011 (UTC)

On the "human interaction" point, there are now (small) links to live chat from the wizard, and for articles that may not be notable there is a (not overly helpful) suggestion in the wizard to seek out an experienced editor. I've wondered how we could do better, and not immediately come up with any good answers. Rd232 ^talk 11:41, 14 April 2011 (UTC)

The "live chat" link really needs to be made more prominent before this can become the pathway for all new users to create articles. Ideally, it should be a big green button that says "Get Live Help Now" or something similar, and links to the web chat. Forget the IRC chat, a lot of browsers can't load that directly, and most non-technical users don't use it.--Danaman5 (talk) 12:47, 14 April 2011 (UTC)

I've tweaked the link at Wikipedia:Article wizard (cf WT:WIZ), anyone want to draft something for greater prominence? Rd232 ^talk 21:35, 18 April 2011 (UTC)

(I commented here earlier but it got deleted somehow, so re-posting.) I don't like the idea of an extension, because it essentially means a few devs or a WMF "usability" team will make the major decisions and the community will not get to choose exactly how they want it (cf. Commons UploadWizard, which still does not have an "I don't know the copyright license" choice. Utter foolishness.). But I do agree that a more interactive wizard would be nice. If an extension is the only way to do that (which I suspect it is), then an extension it is. But the community gets to design it. /ƒETCHCOMMS/ 01:47, 18 April 2011 (UTC)

One obvious wizard "extension" is to split AFC by subject, with new article submissions handled by wikiprojects instead of a catchall AFC page. The wizard would ask the submitter to select the article subject from a menu, and then it would post the new article to an appropriate wikiproject noticeboard instead of AFC. If the person chooses "I don't know" as a subject, then a general AFC reviewer would classify it by subject and route it to the right wikiproject. All new authors should get some kind of human feedback about their submission, from someone who actually knows something about the subject matter (that's where the wikiprojects come in). One knowledgeable human comment about article content is a billion times more reassuring to new users than a billion roboticized wizards and welcome templates. 69.111.194.167 (talk) 03:41, 19 April 2011 (UTC)

Proposal to rename 'confirmed' usergroup to 'preconfirmed'

FYI, this is proposed here. Cenarium (talk) 21:54, 12 April 2011 (UTC)

Protected pages

When I was at the protected pages category (Category:Wikipedia protected pages) most of the reasons were because of edit wars concerning a small amount of people (around 3). I am not going to say usernames but how about when possible, we do not do full protection on pages but instead, we do bans (when possible). We remove the bans when they have discussed it on the talk page and a consensus has been made. Like that, if there is a person (that wasn't involved) that would be doing a good edit, they may do it efficiently (I do not really think that a person requesting an edit on the talk page and getting approved by an sysop is efficient). ~~EBE123~~ ^talk_Contribs 22:25, 12 April 2011 (UTC)

Because blocking, to most users in good standing, is considered a direct attack on their character (hence why the extremely high probability on unblock requests for those). Whereas, full-protecting a page is more of a "play nice, now" gesture, forcing both sides of the dispute to get together and discuss. –MuZemike 00:34, 13 April 2011 (UTC)

EBE123 said ban, not block. Whether xe meant that or not, I have toyed with that idea in the past: that we should make more use of a sort of informal, temporary, page ban, say of the type "for 3 days, you can't edit page X, on pain of being blocked", to force talk page discussion by recalcitrant users without punishing everyone. Trouble is, the ability to impose (and how to appeal/enforce) such bans is a bit of a can of worms. It might be possible to figure out how to handle it, but I'm sure more than a few would say it's too much trouble. Rd232 ^talk 03:56, 13 April 2011 (UTC)

I think that if its more than a few it would get more and more difficult so in that case, the page should be protected. But protecting a page affects everyone. Even the ones that were going to do good edits. ~~EBE123~~ ^talk_Contribs 18:42, 13 April 2011 (UTC)

Issuing a WP:TOPICBAN usually requires the admin to take sides. To give a current example, there's a fixed IP user who has been disrupting The Man Who Would Be Queen off and on for a couple of years now. The undesirability of these changes are pretty obvious, since it includes things like re-wording facts like 'The book ends with this scene' to 'The book end with this alleged scene' and a variety of grammar errors, as well as some ham-fisted POV pushing and BLP denigration.

Over time, these changes have been reverted by half a dozen unrelated editors, and I think that the repeated discussions of why editors can't spam "he alleges" into statements that they happen to disagree with now fill the equivalent of two full talk page archives. But to stop the problem would require an uninvolved admin to spend enough time figuring out the situation and reading source like this one to decide to issue the warning. So far, nobody's felt it worth the time to do so. It's far faster and far easier to protect the page or leave even-handed "everybody stop edit-warring and start discussing (oops, I didn't notice the enormous discussions already on the talk page)" comments, so that's what the community gets. WhatamIdoing (talk) 19:57, 13 April 2011 (UTC)

Perhaps it would help if you look at it as two weeks of peace and quiet? I agree with your assessment that the IP is not gonna stop, so discussion with him on the talkpage is useless at this point.Yoenit (talk) 20:31, 13 April 2011 (UTC)

Two weeks?! I saw some protected pages that is indefinite, and it discourages users that were goin to do good edits. ~~EBE123~~ ^talk_Contribs 21:53, 15 April 2011 (UTC)

In the context of that article I suspect "him" may be particularly inappropriate. Peter jackson (talk) 10:08, 14 April 2011 (UTC)

My 2 proposals

When reading a piece of opinion on wikipedia, I got this idea. It is that a IP could submit a page for reviewal by a new page patroller and if the NP Patroller accepts, it can get seen by anyone. If not it just disappears. There would be a log of these. ~~EBE123~~ ^talk_Contribs 22:15, 13 April 2011 (UTC)

You should check out Articles for Creation WP:AFC, IP editors can already create articles there that are then reviewed, and if accepted moved to the article space. Monty₈₄₅ 22:28, 13 April 2011 (UTC)

Merge of Special:Contributions to Special:Log. How about merging Contribs with Log, because that it has the same format, and it is like a log. It's really a log of edits. ~~EBE123~~ ^talk_Contribs 22:15, 13 April 2011 (UTC)

The Log and Contributions are separate because the MediaWiki software has them separated and with good reason, the log is for NON-EDITS, blocks, moves etc. and Special:Contributions is for edits ONLY. —James ^{(Talk • Contribs)} • 10:55pm • 12:55, 14 April 2011 (UTC)

Moving categories

I propose that the ability to move categories be included in the autoconfirmed user rights bundle or created as a separate right. Admins would be able to do more important tasks and we could all resume business as usual. Thoughts? —James ^{(Talk • Contribs)} • 10:52pm • 12:52, 14 April 2011 (UTC)

?? No one is able to move categories. Mediawiki doesn't support it. --Yair rand (talk) 12:56, 14 April 2011 (UTC)

Category renaming is done via bots. --Cybercobra (talk) 00:15, 15 April 2011 (UTC)

Proposal to include an AFD check in the CSD templates

This is a followup to a discussion I started at Criteria for speedy deletion.

The speedy deletion templates used in the article space should incorporate a check that will cause a warning to appear in the template if it is on a page that has been subject to an Articles for Deletion discussion. The Proposed deletion template already has this feature.

Initially I had proposed that the change just apply to the A7 template, where a previous AFD would almost certainly be outcome determinative, either resulting in a G4 if deleted, or ineligibility for A7 if the article had been kept at AFD. Consensus at the previous discussion seemed to be in favor of a broader application of the idea, as an AfD history would likely be relevant to most article speedy deletion nominations, even if not as determinative as it would be in the case of an A7. While the original discussion had pretty strong consensus in favor, it was suggested I post it here to seek broader consensus. Monty₈₄₅ 17:38, 14 April 2011 (UTC)

• Support. --Kudpung กุดผึ้ง (talk) 04:53, 15 April 2011 (UTC)
• Support Yoenit (talk) 06:49, 15 April 2011 (UTC)
• Support, not just for article-space templates but for all of them if there is a way to do it (see my comments in the linked discussion). Thryduulf (talk) 08:28, 15 April 2011 (UTC)
• Support on all CSD tags except G12, because it doesn't matter when a coypvio was discovered. Also, make sure the tag has instructions to check the XfD before removing a tag, as occasionally pages get created with the same title but totally unrelated content (see here for an example). Good idea. The Blade of the Northern Lights (話して下さい) 13:46, 15 April 2011 (UTC)
• Support Besides this being an all around good idea, a common annoyance with articles tagged as reposts is that few people bother to put in the parameter telling reviewing admins the name of the AfD that the G4 refers to, so we are forced to search for it. This would solve the issue.--Fuhghettaboutit (talk) 15:53, 15 April 2011 (UTC)
• Support Sounds like a perfectly reasonable notification so that proper CSD templates end up being used (or not at all). Silverseren^C 15:57, 15 April 2011 (UTC)
• Support - this should not prevent both an AfD and a CSD from being on the page at once though, sometimes one leads to the other. I've from time to time seen a stub on it's second AfD with the first being a delete outcome and put it up for CSD as recreation of deleted material, only for an admin to drop by and say that it's just as bad but not the same bad stub. Outcome remains the same, process changes, and so on and so forth. Sven Manguard Wha? 00:16, 16 April 2011 (UTC)
• Support Makes sense; also, perhaps some sort of warning could also be coded into Twinkle? /ƒETCHCOMMS/ 18:46, 16 April 2011 (UTC)
• Support Makes sense. Less work for admins, less incorrect tagging. —James ^{(Talk • Contribs)} • 9:51pm • 11:51, 18 April 2011 (UTC)

Opt-in advertising

I am surprised to read comments from people who install an advertising-blocker extension to their browser, such as AdBlock for Chrome, but choose to not censure Google's AdSense, as to "give back" to Google for the services provided. In a similar vein, some people might wish to voluntarily accept limited advertising on Wikipedia articles. For such users, I propose that opt-in (and customizable?) advertising be made available on Wikipedia and its sister projects. Do you think this is acceptable/doable/profitable for the WikiMedia foundation? Cheers, Randomblue (talk) 20:16, 14 April 2011 (UTC)

This has been suggested and gone through many, many times. Getting any source of advertising revenue could be really problematic, and risks compromising Wikimedia neutrality. In my opinion, the only way to have any form of opt-in advertising would be to have it enable-able from off-site (browser extension) and coming from a "mostly-unaffiliated" source, that would take the money and donate it to the WMF, with the WMF never acknowledging it as a distinct, separate source of income. Then again, maybe even that would be too dangerous. --Yair rand (talk) 20:32, 14 April 2011 (UTC)

Wikipedia:PEREN#Advertising --Cybercobra (talk) 00:16, 15 April 2011 (UTC)

Per the link above, the answer is "over just about everyone's dead bodies"... Sven Manguard Wha? 03:53, 15 April 2011 (UTC)

The day Wikipedia allows advertising will be the day I vanish from the project and regret the 100s of voluntary hours I spent on it. --Kudpung กุดผึ้ง (talk) 04:50, 15 April 2011 (UTC)

An interesting idea, but I think the current approach of opt-in donating is the better and less contentious road to take. And quite possibly the overhead of managing such a project would cause the WMF to lose money if an insufficient number of people opted in. 28bytes (talk) 04:58, 15 April 2011 (UTC)

Yes, they'll lose millions and then die. If they place ads in Wikipedia, a significant majority of the 10,000 active editors quit en masse, causing a drop in donations from editors. As for the non-editor donors, the loss of editor will allow vandalism to rise, quality to drop, and the site to gradually become unusable, thus causing non-editors to go somewhere else, taking their money with them. In short, if the WMF does ads anywhere and in any form, everything it touches will die. Sven Manguard Wha? 23:52, 15 April 2011 (UTC)

Newbie warning

There seems to be a theme on Wikipedia to "protect" newbies. When I edit articles, I often look at the article's history, but don't bother visiting every userpage. Edits by newbies don't stand out right from the history page. I may be more tactful reverting an edit from a user I know is a newbie, rather than an edit from a random user. I propose to think about developing better signalling of newbies. Would such "discrimation" be positive or negative? How could this be done? Drakefjustin (talk) 13:28, 16 April 2011 (UTC)

You can often tell newbies because the links to their userpage and talkpage are red rather than blue, meaning the pages haven't been created yet. Unfortunately, I think newbies are sometimes given less benefit of the doubt in terms of reverting unsourced changes, because some new accounts are used for vandalism or sockpuppetry. --Physics is all gnomes (talk) 13:36, 16 April 2011 (UTC)

You can view Recent Changes restricted only to those contributions by newly-registered accounts here. – iridescent 14:55, 16 April 2011 (UTC)

Signing in talk namespace

According to WP:SIGN#When signatures should and should not be used, editors should sign their posts in WP:Talk namespace. The preferred option seems to be to use ~~~~. However, there are also the options to use ~~~, which produces only the signature and ~~~~~, which produces only a timestamp. Why do these options exist, if they are clearly not to be used? Another thing is, we have User:SineBot, which marks all unsigned comments in talk namespace as unsigned and automatically produces a signature and a timestamp. Why isn't this bot just reconfigured to properly sign your posts on talk pages? This would eliminate the need to remind lots of editors of signing their posts (which the bot eventually handles for them anyway) and would eliminate these awful looking signatures produced by SineBot, when someone doesn't sign their posts despite being reminded of doing so. I just wonder why these things are the way they are. Toshio Yamaguchi (talk) 23:41, 16 April 2011 (UTC)

• An example of using ~~~~~ by me a few minutes ago — to timestamp a change of !vote in an AfD (see diff). --User:Ceyockey (talk to me) 23:45, 16 April 2011 (UTC)

There are other uses for the substitutions besides signatures. The ~~~~~ option is handy for templates like {{Talkback}}, where a timestamp is desired but not a signature.

Also, SineBot isn't perfect: it occasionally signs things that shouldn't be signed. That's one reason it's best that SineBot's applications of people's signatures should not look identical to people signing messages themselves. —C.Fred (talk) 23:47, 16 April 2011 (UTC)

Sinebot also misses signatures from time to time, especially on heavier used pages. It will only sign the last edit made to the page so if two edits are made back to back and the first one is not signed it will not sign it. GB fan (talk) 23:57, 16 April 2011 (UTC)

Sounds all reasonable to me. Thanks for the information. Toshio Yamaguchi (talk) 00:01, 17 April 2011 (UTC)

Necro-bump: Soft-block of School IPs

We spend far too much time with IP editors. 97% of vandalism is done by an IP.¹ Schools may be able to be blocked for years, but in general, IPs can wreak much havoc and destruction before getting blocked.²³ Therefore, I propose that all school IPs should be softblocked. If they wish to edit, they must log into an account. Incentives for students to vandalize include, but are not limited to the following examples:

• Anonymity
  • With hundreds of students identifiable by 1 IP for 6 hours a day, Idios D. McSlackerus CXIV will believe that nobody will bother combing the school to find a vandal.
  • Because he will be identifiable by that IP for only 6 hours a day, Mr. McSlackerus will believe that even if he gets blocked, he can resume his vandalism at his house.
  • Because the IP identifies the school, and Mr. McSlackerus hates school, he will replace content with "FUCK" to deface the school's reputation as an example for the country's education system. And nobody will know that McSlackerus was the perpetrator.
• Bigheadedness
  • Wikipedia is notoriously famous for being an "unreliable source". Therefore McSlackerus may think "Miss Leed says Wikipedia is unreliable, so we shouldn't use it. Time to mess it up!"
  • Anyone who's been to New Page Patrol must've seen (and hopefully CSD tagged) a self-glorifying or an attack article. McSlackerus may be bullying Corphon Retrosubnum for the roots of his name (body-sound back-under/beneath) and to give his friends a laugh (and to torture poor Corphon) makes an attack page on Wikipedia. Such vandalism is just more fecal material that the CVU and other people will need to clean.

The only reason McSlackerus will log on at school is so he can disrupt Wikipedia. The only reason McSlackerus will log on at school is to vandalize anonymously. He most likely will never bother creating an account, and will take advantage of "anyone [being able to] edit".

Who thinks this preëmptive blocking is bad? I ask you to find 10 school IP edits that aren't vandalism.

“ This isn't an question of assuming bad faith, this is a question of putting our foot down and saying 'enough'. ” — HalfShadow

I hope this proposition garners a good discussion. --43?9enter ^☭msg_☭contribs 00:40, 17 April 2011 (UTC)

It violates core principles, and you're basing your argument on a pre-Siegenthaler study. The likelihood of the WMF permitting pre-emptive blocking (other than the exceptional case of open proxies) is virtually nil, regardless of what "the community" decides. – iridescent 07:12, 17 April 2011 (UTC)

Oppose

As 1. One of the two or three editors/admins who have been carrying out an in-depth research for several months into the quqlity of New Page Patrolling, with thousand of patrolls made myself, and 2. As a coordinator of the Wikipedia Schools project, I can confirm that 1,000s of perfectly good edits are made to school articles by IP users. School articles are indeed perhaps more susceptible to vandalism than most, nevertheless it is quickly caught and reverted. There is also a bot that returns a special school article watchlist. Only in the most serious cases do we need to impose a schoolblock. --Kudpung กุดผึ้ง (talk) 07:37, 17 April 2011 (UTC)

Comment This and this school IP's edits are mainly vandalism-only. --43?9enter ^☭msg_☭contribs 22:41, 17 April 2011 (UTC)

Commenting on comment School IPs do not always have to vandalize the school's article. --43?9enter ^☭msg_☭contribs 21:34, 17 April 2011 (UTC)

• Oppose per my comments in the section above. Your argument is based on a single out-of-date study; while there's a case to be made (albeit one I disagree with) for mandatory account creation, pre-emptive blocking of accounts with no history of disruption is so blatant a breach of Wikipedia's principles, there's no realistic possibility of it happening. – iridescent 07:48, 17 April 2011 (UTC)
• Oppose I don't see enough upsides over the current escalating block approach. How are we going to identify the IPs anyway? Monty₈₄₅ 07:56, 17 April 2011 (UTC)

Comment This helps. --43?9enter ^☭msg_☭contribs 21:34, 17 April 2011 (UTC)

• Oppose: the fact remains that school IPs are regularly blocked anyway, if they're disruptive, often for long periods of time. This system removes a vast majority of the vandalism, and doesn't put nearly so many people off. We risk alienating school-age students (who make up a significant proportion of editors as it is, and even more so of "future editors"), for little benefit. Grandiose (me, talk, contribs) 13:54, 17 April 2011 (UTC)

Comment But they can begin editing at home. Remember I am suggesting that only school IPs to be blocked. --43?9enter ^☭msg_☭contribs 17:27, 17 April 2011 (UTC)

• (ec) Oppose — Despite my annoyance at the antics of some users, I don't think an IP vs. login provides a fair profiling mechanism for identifying troublemakers. If we want to encourage people to use logins rather than IP addresses, provide an easier way to generate a login. For instance, an auto-generated username and password could be presented to any IP user so that one-click would provide them with a non-ip login. The username could be their IP address followed by a sequential alphanumeric code; the password could be quite simple (low security). I think that you would find a substantial number of current IP users would pick up this auto-generated login and say 'thanks ... I just didn't want to go through the rigmarole of creating one myself; now I just tell my computer to remember this and I'm off'. --User:Ceyockey (talk to me) 13:59, 17 April 2011 (UTC)
• Oppose. Nowhere in this proposal was it mentioned how to identify the school IPs. In my experience, I've seen many IPs that look like they're used by a school (large proportion of edits are vandalism, lots of the vandalism focused at one or two schools' articles), but the WHOIS just resolves to an ISP's IP address pool. The current approach seems not only much fairer but also much more feasible: the addresses that need to be blocked to prevent vandalism announce themselves by making said vandalism. —C.Fred (talk) 14:10, 17 April 2011 (UTC)

Comment School IPs don't always vandalize the school's article. --43?9enter ^☭msg_☭contribs 21:34, 17 April 2011 (UTC)

• Oppose - If you can show me how we can automatically identify all public institutions' IPs, then I'd be more willing to support. However, consider that some IPs do make constructive edits, and we do have lots of people playing the countervandalism game... Ajraddatz (Talk) 14:11, 17 April 2011 (UTC)

Comment Above IP and this IP was identified as a school's (although I don't know how) --43?9enter ^☭msg_☭contribs 17:27, 17 April 2011 (UTC)

• Oppose - Frankly, casual vandalism is not that serious of a problem. It's probably the only area of abuse mitigation where tools for fighting it have increased significantly in efficiency while the level of sophistication of the abuse has remained constant. I also agree with Iridescent that we shouldn't be basing anything on a 4 year-old study (and even 4 years ago it had some serious sample size issues for the level of detail that it reports). Mr.Z-man 16:12, 17 April 2011 (UTC)
• Oppose. It's been my experience that admins are not shy about blocking school IPs that have been used for vandalism, so I think the status quo regarding school IPs is preferable to a "preemptive strike" on all schools. 28bytes (talk) 20:23, 17 April 2011 (UTC)
• Oppose Because I know plenty of students using school computers and school networks to make good edits anonymously. (Actually, we should be blocking less and contacting problematic schools more.) /ƒETCHCOMMS/ 01:48, 18 April 2011 (UTC)

Comment Why don't they make an account then? As I suggested, it would be a softblock. --43?9enter ^☭msg_☭contribs 02:01, 18 April 2011 (UTC)

For the same reason that other IP editors choose not to? Monty₈₄₅ 04:22, 18 April 2011 (UTC)

• Oppose IPs are innocent until their actions prove them guilty. While blocking is a necessary evil to stop constant sources of problems, pre-blocking IPs which have done nothing wrong serves no benefit to the encyclopedia, and only serves to harm its core mission. --Jayron32 04:54, 18 April 2011 (UTC)

Brief explanation of what the issues are here

Since the OP appears to be missing the point(s) or misunderstanding the arguments here, the reasons this is not going to happen are:

1. "Anyone can edit" is a core principle of both Wikipedia and Wikimedia. Even if this discussion were to produce a vote in favor of this proposal, it would be vetoed by the WMF and the devs would refuse to implement it. If an admin were unilaterally to embark on a preemptive blocking spree, they would be promptly desysopped.
2. Preemptive blocking would be a major cultural change, and the damage caused by the subsequent resignations would hugely outweigh any putative gains.
3. Softblocking is not a solution. People are (rightly) reluctant to enter their login information on public terminals owing to the potential for abuse by whoever comes after. "Use the secure login" is not an option; most casual users are unaware that it exists, and many (perhaps most) public terminals have https access disabled.
4. The statistic that "97% of vandalism is done by an IP" is based on a single, five-year-old study, on the pre-Siegenthaler Wikipedia which did not have most of the current checks in place, which looked at a tiny dip-sample of 100 randomly chosen articles. Any results from it are meaningless regarding the current Wikipedia.
5. IP "poop!!!" vandalism is a minor issue and is generally caught quickly by the bots and NPP. Problematic vandalism on Wikipedia is the insertion of inaccurate but plausible information on high-traffic pages and biographies of living persons, not the froth of minor goofing around on extremely low-traffic pages. This proposal does nothing to resolve that issue.
6. (most pertinently) Except in a few cases where the school owns its own server and is identified as such on a whois search, there is no way to identify school computers, and thus it would be technically impossible to implement this proposal even should we choose to do so. – iridescent 09:12, 18 April 2011 (UTC)

Perma-hiding latest entry of protection logs from IPs

I propose that the latest entry of the protection log that appears on a protected page when a user edits it be hidden completely from IPs, when a vandal targets a page and they find it's been protected they'll often look to see when the protection expires and if it's very recent, one can only expect all hell to break loose, it wouldn't be much but it'd probably deter IP vandals that timetable their vandalism sessions. —James ^{(Talk • Contribs)} • 10:40pm • 12:40, 18 April 2011 (UTC)

Why would you prefer unpredictable vandalism over predictable vandalism? If a page is vandalised directly after the protection expires it will get indefinite protection soon enough, so this actually seems counterproductive. Yoenit (talk) 12:57, 18 April 2011 (UTC)

Um, that's a bad idea. That feature exists so that the IPs and users editing in good faith know why that the page was protected, so they can find some other way to contribute, and to let the people who edit in bad faith know that we do have humans which are able to stop their actions - a win both ways. The fact that one or two dedicated vandals abuse this is no reason to completely remove it. Ajraddatz (Talk) 18:07, 18 April 2011 (UTC)

Most pages protected for short times are protected due to some event increasing the popularity of the subject. Once the popularity subsides, people no longer care. The majority of vandalism is not done by determined vandals who "timetable their vandalism sessions." Mr.Z-man 20:24, 18 April 2011 (UTC)

We should not remove accessibility for the sake of anti-vandalism efforts. /ƒETCHCOMMS/ 02:25, 19 April 2011 (UTC)

I hadn't thought of it that way. What about preventing blocked IPs from seeing protection logs for the duration of their block? —James ^{(Talk • Contribs)} • 7:12pm • 09:12, 19 April 2011 (UTC)

Won't deter anybody who is determined, and inconvenience lots of other people. (The prevention will have zero effect unless it also prevents logged-in users on that IP, which is not such a great idea). —Кузьма^討論 09:15, 19 April 2011 (UTC)

You're right, those using shared IPs would be confused. This proposal was stupid to begin with :S —James ^{(Talk • Contribs)} • 7:30pm • 09:30, 19 April 2011 (UTC)

Allowing users to upload from URLs

Uploading files from URLs would certainly be beneficial for those that participate at WP:FFU. Would bundling it with File mover be feasible? —James ^{(Talk • Contribs)} • 7:24pm • 09:24, 19 April 2011 (UTC)

• I've wondered about this myself. My guess is that it's just never been implemented, technically.
  — V = IR (Talk • Contribs) 13:41, 19 April 2011 (UTC)

Search results

Why don't we show popular search results on the search page? You know, how some places show the cloud of results, with the more popular ones in a larger font and less popular ones in a smaller font (isn't there code for that in the phpBoard source?)? We don't even have to use that format... just showing, say, top 10 searches would be nice.
— V = IR (Talk • Contribs) 13:39, 19 April 2011 (UTC)

Welcome email

Hello,

When people create an account on Wikipedia, the last step of the process is this: if the person has entered an email adress, the system sends a confirmation email. The text in that email is currently this:

Someone from the IP address $1 has registered the account "$2" with this e-mail address on the English Wikipedia.

To confirm that this user account really does belong to you and to activate e-mail features on Wikipedia, please open this URL in your browser:

$3

If you did not recently register for Wikipedia (or if you registered with a different e-mail address), click the following link to cancel the confirmation:

$5

This confirmation e-mail will automatically expire at $4 (UTC).

~Wikipedia, the free encyclopedia http://en.wikipedia.org

I don't know about you, but I feel it could be more welcoming. As it is, there is not even a sign that there are people behind Wikipedia, which makes vandalism more likely. It is also a missed opportunity to teach people how Wikipedia works. It doesn't matter if all of the new account-holders read the email - they have it in their inbox. I have looked at similar confirmation emails from a bunch of different websites and noticed that many of them are far longer (Skype's email is for instance more than four times the length of this), friendlier ("Hello", "See you on X", "Thanks") and contain advice on how to use the site. Inspired by their versions, I wrote a new confirmation mail:

Hello $2,

Welcome to Wikipedia! You have just joined the free encyclopedia that anyone can edit. To confirm that this user account really does belong to you and to activate e-mail features on Wikipedia, please open this URL in your browser:

$3

This link expires at $4 (UTC).

With your new account, you can among many other things:

• keep track of any changes on your favourite pages using your watchlist
• write about yourself on your userpage
• edit without your IP-adress being visible
• use more advanced editing tools
• send, and occasionally receive, emails to other users.

Naturally, we hope that you start editing the articles. It's the best way to make Wikipedia better. This is how easy you edit Wikipedia: 1. find an article that you want to contribute to 2. click "edit" at the top of the article 3. make your changes in the edit box 4. click "save page" below the edit box. Now, you're done and the page is updated immediately!

Be bold! Edit an article today. It's how every Wikipedia article was written. But remember, all edits you make are checked by volunteers. Click the star at the top of the page to follow any changes to the article.

Learn more about how Wikipedia works by clicking ”Help” in the left hand menu on any page of Wikipedia or by downloading this guide: http://upload.wikimedia.org/wikipedia/commons/f/f0/Welcome2WP_English_082310.pdf

Thanks!

– the other volunteers behind Wikipedia, http://en.wikipedia.org

PS. If you didn't register an account on Wikipedia, feel free to disregard this message or click this link:

$5

I know that this version is not perfect, so feel free to dissect it and make better versions below. A few questions that you can think about:

1. should we include more links, to for instance their watchlist and the Help page?
2. should we make it more visually interesting?
3. can we make it even friendlier?

I would like to at least try out a new version of this message in a few days' time, so please help out in making it better.

Best wishes, Hannibal (talk) 14:45, 19 April 2011 (UTC)