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)
  • Well for one, there is an editor complaining right now on the Bot noticeboard of refs being combined on multiple articles he constructed deliberately not using them, so let me enter an oppose on his behalf while I am here. I too used to write references in this style, but stopped long ago merely to conform and knowing that sooner or later someone would come along with AWB and change it anyway. I don't really feel very strongly about the actual issue of ref styles but I do have a strong opposition to individual human editors being pushed around by automated processes. SpinningSpark 13:43, 24 April 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)

• Oppose bots should be for uncontroversial tasks, and anything that generates human opposition (even if misguided) is not uncontroversial. I find that there is merit in the numerical order of references argument: when I read an article I don't always immediately click down to read the notes, instead I will often look at them afterwards and try to tie them up manually with where they apply in the article. It is inconvenient to have to scroll back up all the time and next to impossible to work out which of abcde... I should click to get to the right place. It is also an added difficulty to have to uncombine references when an additional page number is desired to be added to a passage. I frequently run up against this problem when constructing articles and fully understand editors who do not wish to use this system. SpinningSpark 20:35, 24 April 2011 (UTC)
• Support I've combined references in hundreds of articles, and not a single person has complained about it. Lots have thanked me. I see very little chance of anyone disliking such a change, and having a bot perform this repetitive task would be a great improvement. The editors who do not understand named refs often pick up the idea once they've seen it. As long as this is carefully controlled and checked, it would save lots of duplicated work. I accept there is a remote chance that someone will stylistically object - however, you cannot please all of the people all of the time. The net benefit in naming references - making the source easier to follow, improving the readability of the references sections far outweigh the very small opposition rationales above.  Chzz  ►  15:23, 26 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)
  • There's no need to be offensive. I am almost provoked into opposing just on the strength of that comment - it shows a complete lack of understanding of those of us who actually write articles. Yes, they can be regarded as ugly, they increase code clutter in text view and more importantly, they affect the neat alignment of endnotes/footnotes with the multiple links. SpinningSpark 14:04, 25 April 2011 (UTC)
• Strong Support if exclusion template is implemented The ability to put a template on a page that tells the bot to not change it not only addresses all the steted objections, but also allows for creation of a example page that compares duplicate references with named references. Guy Macon (talk) 02:32, 20 April 2011 (UTC)
• STRONG, STRONG, STRONG OPPOSE—for the reasons discussed here. I have yet to read through all of the comments above, to evaluate others' opinions on this subject. But i already know how—absent some sort of thoughtful and creative implementation—this sort of proposal will (and does) affect my editing. Richard Myers (talk) 18:07, 24 April 2011 (UTC)

Clarification, after reading much of the above. I strong, strong, strongly oppose the original proposal, not the alternate proposals. I will continue to so oppose the original proposals, because the alternate proposals don't go nearly far enough in appreciating the actual human impact that such a bot will have on some editors.

I don't have a strong objection to the idea of removing dup refs from an article that is stable and in some state of completion. I do object in the strongest terms to removing dup refs from an article that is in the process of being edited. And this very thing has happened to me a number of times, so i am very aware of its very negative impact.

A complete change to the citation system is utterly confusing to many editors (it was so to me for a couple of years), and there is also something intimidating about it when it happens in the middle of article creation. In probably eight or so serious, lengthy articles that i've created, i really wish now that i'd had the temerity to revert. Confusion and intimidation can work together on an editor in such circumstance, and absent any helpful information on options, it is easier to just stop editing.

Therefore, before i would support any alternative proposal, it must take into account the impact on real world editors who are diligently working on articles while they are working on those articles. The bot must explain itself more thoroughly, not just in edit summaries but also on the talk page (where "ambushed" editors may comment, discuss, and perhaps determine a response), and the bot must also not just allow, but actually encourage a non-controversial revert of its modifications in situations where it would impact process. A creative solution might be to provide editors with an option not just to revert, but to invite the bot to return to the article in (say) three months. Under such circumstances, i would change my strong, strong, strong oppose to (probably) a simple oppose. Richard Myers (talk) 19:13, 24 April 2011 (UTC)

Note: an article i've been working on, Anti-union violence, just now had duplicate references merged by someone using AWB. This time, i reverted. And i will continue to revert every instance that i encounter that interferes with my process.

Note that i am currently the author of more than 99 percent of the edits to this article (and of a high percentage of edits to the related article, Union violence). Please observe that my editing of these two articles has been an ongoing process, over the past several weeks. Why should i be brazenly interfered with in my editing of these two related articles by a process that is "preferable" and "standard" and "non-controversial", when i perceive it as an ambush that (absent a revert) dramatically and adversely impacts my ability to edit?

Yes, i am irritated. But i'm not trying to be hostile, i'm trying to convey that the impact of a process carried out with (in my view) near impunity is significant, immediate, increasingly pervasive, and VERY detrimental to at least a subset of longtime Wikipedia contributors. Richard Myers (talk) 20:24, 24 April 2011 (UTC)

I have posted a workaround for this article at the other thread. -- John of Reading (talk) 20:43, 24 April 2011 (UTC)

I have implemented the workaround on that article. The current generation of AWB/bots will not fiddle with the references on that article again. -- John of Reading (talk) 05:38, 25 April 2011 (UTC)

• Support, I find the arguments presented convincing, and the downsides only minor. I have one question, though, how does the bot derive a name for the reference? Having said that, I'd support it anyway. It makes a lot of things clearer in editing, etc. I'd like to see this trialed soon. Grandiose (me, talk, contribs) 18:16, 24 April 2011 (UTC)
• Conditional oppose - I oppose this unless some measures are taken to improve the quality. For one, using names like "ReferenceA" (which AWB seems to do if it can't come up with something better) is unacceptable. Named refs with unhelpful names are worse than repeated refs. The bot should also make an effort to not interrupt human editors (ideally almost every bot should do this). It should recognize tags like {{inuse}} and skip articles that have had recent edits (in the last 12-24 hours). Mr.Z-man 14:43, 25 April 2011 (UTC)
• Support Per my support of the original proposal; if that does not succeed, then this is the best we can hope for.  Chzz  ►  15:23, 26 April 2011 (UTC)
• The opposition doesn't surprise me: Every time someone proposes something like this, there is always strong opposition from a minority of editors. For myself, I don't think that this proposal is either very helpful or the end of the world. However, if we're going to have such a thing, it would be appropriate to limit its use to articles that are already re-using named refs (not merely "one tag contains a name"). WhatamIdoing (talk) 23:35, 26 April 2011 (UTC)

Request for guidance on policy

I have carefully reviewed relevant policy/guideline pages WP:REFNAME, WP:CITEFOOT, and WP:NAMEDREFS, in regard to merging duplicate references. Each of these explains that named references are an acceptable alternative. None of these hint or suggest that named references are preferable. Indeed, they seem to be written to give precisely equal weight to each method that is discussed.

I have also explored Wikipedia:Citing sources, which states:

• How to write citations: Each article should use the same citation method throughout. If an article already has citations, adopt the method in use or seek consensus on the talk page before changing it.

To me, that language is very plain. It says, don't just jump into a random article and change the method, get consensus, or don't do it.

Now, this is my problem. In discussion here and elsewhere, i have been informed that named references are "preferable", "highly preferable", "standard", "non-controversial", "more efficient", "saves space", "improves readability", "logical", "beyond clear", a "no brainer", and a "good idea". But where does it say in Wikipedia guidelines or policy that the people who believe all of these things have the right to violate the very clear guideline above (and in my view, the ONLY stated guideline that gives weight to one method over another) which says simply, adopt the existing method, spend some effort to get consensus (or go away)?

In brief, until someone can offer a guideline or policy or a compelling reason which is not simply based upon their own personal opinion, it seems to me that this practice of merging duplicate references (longstanding though it may be) is in direct violation of the only relevant guideline or policy that expresses a preference one way or the other.

What, really, does the existing policy demand of those of you who have your minds made up? Even if you have this strong, strong consensus in your discussions, you are routinely violating a policy that protects many of us article editors! Please tell me where i am wrong. Richard Myers (talk) 23:24, 24 April 2011 (UTC)

I think the more important policies are WP:IAR and WP:BRD. If an article is employing a "consistant" but obnoxious or substandard referencing scheme, I see no problem with boldly trying to fix it. We can't hold month-long discussions on obscure, out-of-the-way articles every time someone wants to make a positive change to an article. The prohibition on changing citation styles is in the spirit of not warring between two equally valid, but different, styles, and not between a substandard style and a better one. Sure, discussion should happen if someone objects to a change, but we shouldn't sit on our thumbs and wait weeks or months for a consensus to emerge every time we want to do something. That's the spirit of WP:BOLD, WP:BRD, and WP:IAR. If you, in good faith, are trying to make an article better, just go ahead and do it. If people object, or disagree with your improvements, allow them to be undone and discuss. But we shouldn't walk on eggshells here... --Jayron32 03:10, 25 April 2011 (UTC)

This is total bullshit, based on your perception of what is "substandard. I often have to revert well-meaning, but utterly arrogant and against policy attempts to "improve" referencing on articles I've created or expanded. The problems come if you don't spot it in time, & can't be bothered to go back, revert & re-add a lot of changes. I've had to virtually abandon articles the cite-Nazis have got at. Johnbod (talk) 21:24, 25 April 2011 (UTC)

While I wouldn't put it that agressively, I also have a few articles I really wish I'd had the confidence to revert style changes and now find I'm really reluctant to return to even though I have more references that could go in. SpinningSpark 21:42, 25 April 2011 (UTC)

That makes at least three of us who have "abandoned" articles in one form or another because someone did something such as changing the notation scheme. Richard Myers (talk) 22:21, 25 April 2011 (UTC)

The rules of use for AWB suggest relying on WP:IAR and WP:BRD is wrong for automated or semi-automated processes. Specifically,

6. The Wikipedia tenet "be bold" is not a justification for mass editing lacking demonstrable consensus.

I would anticipate this rule to be advisable (and perhaps in force?) with all bots, auto or semi-auto. Richard Myers (talk) 18:00, 25 April 2011 (UTC)

Out of curiosity, i did a superficial exploration of the edit histories of those who have supported merged duplicate references, just to see how many editors who do in depth editing of articles support, and how many are opposed, and vice versa. I went back 1,000 edits. Criteria is simple: is there, in the last thousand edits, a substantial string (more than ten or twelve) of edits on the content of a particular non-user page article? I didn't include anyone who didn't appear to state a preference for or against merged duplicate references.

This is by no means "scientific", but here's what i've found.

If i've erred in evaluating anyone's edit history, or if you'd prefer not to be listed, please let me know, i'll fix it. (Alternately, please feel free to edit the table as appropriate.)

editor	in depth editing of standard articles?	support routine merging of duplicate references?
Richard Myers	yes	no
PMAnderson	yes	no
SpinningSpark	yes	no
Johnbod	yes	no
Hegvald	no	no
Ceyockey	no	no (opposed to bot-merger)
Gimmetoo	no	appears to be yes with limitations
joe decker	no	supports alternate
Carl	no	"presumption to keep the original style"
Mr.Z-man	no	conditional oppose
Sailsbystars	no	yes
Kudpung	no	yes
Sandstein	no	yes
Cybercobra	no	yes
SW	no	yes
Guy Macon	no	yes
Collect	no	yes
James (Ancient Apparition)	no	yes
Lambian	no	appears to be yes
Grandiose	yes	yes
Jim Miller	no	yes

Look at my edit history, you'll see many hundreds of edits each, on a comparitively small number of articles per thousand edits. I saw this type of editing history in the most recent thousand edits by just one individual who is here supporting merged duplicate references. In brief, it could be that some folks here are not concerned about routine merging of duplicate references because it doesn't affect their contributions to Wikipedia (at least not judging by the last thousand edits).

Pretty interesting. Richard Myers (talk) 05:09, 25 April 2011 (UTC)

My experience in finding this discussion on this page was pretty much by chance, somewhat roundabout, and only with the kind assistance of another editor. This, in spite of my active search for discussions on precisely this topic. Therefore i wonder if article editors are getting fair representation in this discussion.

I would like to see this discussion opened to more Wikipedians who are just typical editors impacted by the practice of routinely carpet bombing duplicate reference merges, rather than to Wikipedians who may be primarily interested in the technological aspects of bots and what bots do. Can anyone suggest a method of accomplishing this? Let us please try to get an overview of what editors who create in depth articles think. thanks, Richard Myers (talk) 02:17, 25 April 2011 (UTC) (this entry moved to consolidate logical discussion)

Is Wikipedia:Content noticeboard what you're looking for? You might also want to poke WT:FAC, if you want the "top end" of the content-writing aspect of Wikipedia. – iridescent 18:50, 25 April 2011 (UTC)

Hi, thanks. I'll explore options at those links. Richard Myers (talk) 19:13, 25 April 2011 (UTC)

I have put a brief notice here (Content Noticeboard) and here (Featured Article Candidates discussion). Richard Myers (talk) 20:18, 25 April 2011 (UTC)

comment on edit evaluation in table — this reflects as much style of editing as "depth". One edit can accomplish the work of twenty if the content revision is small in each individual edit of the twenty. Therefore, edit count alone cannot be used in this evaluation. It also depends upon the length of the article in question; a small number of edits can completely change a short article but barely dent a large article. What the table actually shows is "who did a lot of edits on a small number of articles" - not "who edits articles in depth" (by my interpretation). --User:Ceyockey (talk to me) 00:54, 27 April 2011 (UTC)

No disagreement with this. The method of analysis is imperfect. However, i feel the information is still useful, and (as you have done), anyone is welcome to change their entry to more accurately reflect their situation. thanks, Richard Myers (talk) 01:12, 27 April 2011 (UTC)

BTW, not trying to disagree with the above, but i learned the hard way some five years ago that a greater number of brief edits are greatly preferable to individual in depth edits, for the simple reason that a computer glitch (such as a browser crash) or a power outage could cause one to lose 30 or 45 or 60 minutes worth of editing effort. After it happened to me a couple of times, i changed my editing practices. I'd be surprised if some other experienced editors haven't learned the same painful lesson. Richard Myers (talk) 05:26, 27 April 2011 (UTC)

Quite right. I learned that as well, but approached it in a different way . . . I grab the wikitext and edit offline, making sure that there were no edits between when I captured the content and when I added back the revised content. I've only had to do that a couple of times in the past several years. --User:Ceyockey (talk to me) 01:14, 28 April 2011 (UTC)

Aspects of this discussion

This discussion about routine merging of duplicate references is, first and foremost, a discussion about a bot proposal. It has been conducted here, and at Wikipedia:Bot_owners'_noticeboard#Concerns.2Fcomplaints_about_bot_tasks_and_practices. I'd like to summarize aspects of the discussion here, as i see it.

• Does routine merging of duplicate references, as currently practiced, adversely impact a significant subset of editors?
• Should duplicate references be routinely merged:

• in articles which have reached some state of completion; and/or,
• in articles in general (including articles not yet in a state of completion)?
• And if so, under what guidelines?

• Is there benefit to consecutive numbering of references, and does that outweigh perceived advantages of merging with named refs?
• When duplicate references are merged, is it acceptable for named references to be auto-generated, or must they always use a real world tag (such as the author's name)?

I don't think this brief list is exhaustive, i'm just trying to keep track of some key discussion points. (Did i miss anything essential?)

But finally and most importantly (to me), has this discussion been carried on before, anywhere, in a forum where a significant cross-section of article editors have a chance to comment? Richard Myers (talk) 19:51, 25 April 2011 (UTC)

Frankly, I have never understood why one would not automatically merge duplicate references. I understand using Harvard style for multiple page refs in the same work, and I understand that there are editors who prefer Harvard vs. MLA vs. APA or whatever. These are stylistic choices in how the final reference appears on the page. But that is all they are - editorial, stylistic choices made by editors. That is what the guideline says to respect. The use of named references to eliminate duplication does not change the format or appearance of the citation itself. I see no benefit in the consecutive numbering because citations are linked. Readers can click the superscript indicator to see the ref, and then click on the matching ref number to returned to the spot where they were reading. Frankly, by refusing to merge references, we are making some author or work appear far more often than is necessary for the article itself. It is a pernicious form of SEO to have the same work appear over and over again on the same page. Unless page numbers are necessary for citations, named refs should be the standard and duplication should be eliminated wherever possible. Jim Miller ^{See me | Touch me} 13:35, 26 April 2011 (UTC)

This. Duplicate ref merging doesn't substantively change the citation style, except insofar as the second-to-last point, which can be countered by the amount of potential References/Notes section bloat which would caused by the duplication necessary to force such consecutive numbering. The last point is a very legitimate concern; regarding AWB or similarly semi-automated tasks, this is where human eyes should be used. --Cybercobra (talk) 16:02, 26 April 2011 (UTC)

I have updated the table. As of now, five editors who have commented actually do in-depth editing of articles, by my cursory evaluation. Four of these five oppose having others jump in and auto-merge duped refs, at least during the article creation process. To me, that is the most significant statistic in this discussion. Richard Myers (talk) 18:05, 26 April 2011 (UTC)

Ad hominem fallacy. We should examine these editors' rationales for opposing. --Cybercobra (talk) 01:24, 27 April 2011 (UTC)

Happy to oblige. I create in-depth articles, including on historical topics.

I just skipped through four of the articles i've recently created. Respectively, they have 184 footnotes and 33 sections, 201 footnotes and 37 sections, 140 footnotes and 36 sections, and 102 footnotes with 12 sections.

Suppose i am working on a new section of one of these articles. I typically am working from the same source(s) with which i created the previous sections. For a given historical article, i may have ten or twenty books stacked on my desk at one time. The ability to quickly locate the correct reference string is vital to efficient article creation.

With my existing work process, i can often find the source(s) i need very easily, just one or two paragraphs above my edit point. I copy the ref string, and change the page number if necessary. Simple, quick, and easy.

If dup refs have been merged in the middle of my article creation process, suddenly it becomes necessary to search the entire article to find the reference string i need, and now there is only one such reference in the entire article to be found. I must leave the section i'm working on, interrupting workflow. Then i must find the edit point again, which i wouldn't have lost if i was working within just two or three paras.

It is much easier to find a given reference string in the section i'm working on, than to have to search thirty or so other sections, then find my way back to the work point. I estimate my productivity in lengthy articles with merged duplicate refs at maybe one-third of what i have routinely accomplished prior to merge.

The author of the bot proposal we're discussing has commented on another page that the disadvantage of having a reference string outside of the current edit window goes away if we edit entire articles, rather than sections of articles. That may be true, but it also takes away the very real advantages of section edits, including the ability to target precisely and easily the section being edited, and avoidance of many edit conflicts. The difference between editing a full article with 30 some sections, and editing one section or a subset of the full page, is very significant, and for several reasons.

I also like to maintain the flexibility to create complex footnotes, sometimes clarifying a particular quotation, adding the source used by the source, or even bundling citations. If i have only abbreviated named references to work from, that means that flexibility is impeded. Full reference strings are much better during the editing process, in my experience.

If i had a way to signal that i was satisfied a particular article was robust enough that major editing is no longer anticipated, and merging dup refs could henceforth be enabled, i would consider that an improvement over current practice. I'm not aware of a way to accomplish that currently, given existing policies/protocols. Richard Myers (talk) 03:14, 27 April 2011 (UTC)

As currently coded, the AWB general fixes do not merge duplicate references in an article where none of the references are named. See this documentation. Currently the default behaviour for a new article with plain <ref> tags is precisely the behaviour you are asking for. To enable the merging, add a "name=" parameter to one of the references. -- John of Reading (talk) 07:06, 27 April 2011 (UTC)

Yes, i understand this. (And i'm very appreciative of the help related to this situation.) It seems that in the past, articles i have been editing have occasionally had a named reference which i wasn't aware of. I'm now more aware of this circumstance, and will be more watchful in the future. But i'm really more concerned about other editors, who may be at the knowledge level i've had the past few years, that is, the situation of not knowing, and not understanding why the article they may have spent a lot of effort on was suddenly converted to merged references. I'm inclined to believe that the article threshold should be much higher than just having one or two or five named references. best wishes, Richard Myers (talk) 09:42, 27 April 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)
  • Please not! Then I would never get finished to press tab to get the save or preview button... mabdul 15:54, 27 April 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)
• Support With the first (or would last be better?) item on the drop down list having no text and leaving the edit summary blank. Guy Macon (talk) 02:48, 20 April 2011 (UTC)
• Support. This could improve the edit summary use of new constructive editors, which would make patrolling recent changes more efficient. There should be an option in the preferences to hide the drop-down list, though. Jafeluv (talk) 11:33, 23 April 2011 (UTC)
• Support, wondered some time ago that there isn't any gadget for that. mabdul 15:54, 27 April 2011 (UTC)
• Comment the auto-edit summary already gets in the way by covering up the minor edit checkbox, and if there is more than one in the list, the save page and preview buttons as well. I would be against this if it is something else that will cover up buttons forcing an additional click to get rid of it. SpinningSpark 13:34, 30 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)

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)
• Support Newbie friendly and easy to use, exactly what we should be trying to do as often as possible. oknazevad (talk) 17:57, 21 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 (2), 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)

I was asked to comment on this, and I'll reply in more detail later - probably over the 4 day weekend! A few brief initial comments. 1) If supporting non JS users is trivial, lets do it, otherwise I wouldn't worry about it. Every remotely modern browser (even IE 6) supports Javascript, and if users choose to deliberately disable it they'll be techies and expect that stuff won't just work™ when they are using the internet. 2) Redoing in JQuery sounds like a good idea, as JQuery works in every browser including IE 6 whereas specific normal Javascript may not work, I can take a look at this over the weekend probably.

Finally someone needs to QA the script in IE 6 on Windows XP before the code goes live, we do need to support those users. -- Eraserhead1 <talk> 20:48, 19 April 2011 (UTC)

Obviously, once this change is made, db-meta will need to be tweaked contemporaneously. {{Db-meta/sandbox2}} now contains the text I would propose to be added upon the change.--Fuhghettaboutit (talk) 21:31, 19 April 2011 (UTC)

Instead of adding an additional template {{hangon}} to the page, could you just add a new parameter (e.g. |hangon=yes) to the CSD template? By making a small change to {{db-meta}} we could create the same appearance but it may be neater and allow for additional functionality and flexibility. — Martin (MSGJ · talk) 11:45, 20 April 2011 (UTC)

That makes sense to me, although I'm not sure exactly how to change the script to add a parameter instead of a whole template. It's not a terribly big deal right now, but combining the two templates would be reasonable in the long run. /ƒETCHCOMMS/ 04:12, 21 April 2011 (UTC)

Code

addOnloadHook(function () {
    try {
		var thisOuter = this;
        $('#hangonbutton').click(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 (thisOuter && thisOuter.firstChild && thisOuter.firstChild.data) thisOuter.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) {}
});

OK, the above uses JQuery and should work - I haven't tested it though. -- Eraserhead1 <talk> 08:56, 22 April 2011 (UTC)

Hm, it doesn't do anything for me—also, is it still reliant on wikinews:User:Bawolff/mwapilib2.js, or does it stand on its own? I think Bawolff was saying that this custom library shouldn't be used for sitewide js. /ƒETCHCOMMS/ 22:59, 22 April 2011 (UTC)

It should be standalone. Where's the test page? -- Eraserhead1 <talk> 18:36, 23 April 2011 (UTC)

User:Fetchcomms/test (might have to change it to work in userspace?). /ƒETCHCOMMS/ 05:04, 24 April 2011 (UTC)

I've made some progress with displaying the message with User:Eraserhead1/hangon.js and that creates and styles (with JQuery rather than straight CSS unfortunately) a "button" and a dialog is shown. Unfortunately I'm having an issue with Firebug claiming that it cannot find the variable 'api' and its not working 100% yet. -- Eraserhead1 <talk> 20:51, 25 April 2011 (UTC)

I get the same issue with the other button as well. I don't think its a JQuery issue. -- Eraserhead1 <talk> 16:38, 29 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:

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

I think the signature should be dropped from the edit form presented when clicking the button - I haven't seen a single case yet where a new user hasn't placed their actual reasoning after the signature, which looks weird and might discourage new users, while having no signature hardly matters. Zakhalesh (talk) 18:22, 20 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)

To do that, one would have to use intricate wiki-markup, {{#if:}} is what I'm getting at. —James ^{(Talk • Contribs)} • 10:45pm • 12:45, 24 April 2011 (UTC)

Feedback

Excellent work in implenting this. I've just used it on the article for Dmytro Blazheyovskyi. Def. a step in the right direction. Lugnuts (talk) 17:31, 24 April 2011 (UTC)

In general, looks good so far. However, from my experience in dealing with blatant attack pages, I think the button can be omitted from the Template:Db-g10 (attack pages) tag. Just about anything tagged as such as G10 attack pages are going to be quickly deleted, and it's a waste of time for the creator and deleting admin to have to consider what is normally a bullshit (pardon my French) reason to contest the deletion. –MuZemike 09:30, 28 April 2011 (UTC)

The old G10 tag had instructions for placing hangon tags as well, so this is really a separate issue. If you experience a lot more contested attack than before the change it suggests that new editors find the new system a easier to use (for better or worse). Yoenit (talk) 09:58, 28 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)

An extension isn't needed for the purpose Cenarium describes. All that's really needed is a way to funnel editors to the existing community-editable Wizard; that may even be doable without a software change, but if a change is required, it could be a very minor tweak. For instance, it could just funnel all page-creating users to a MediaWiki-defined location (if a certain global MediaWiki setting is engaged) and only allow actual page creation if the referring URL is the Wizard; and then allow individual users to turn off that behaviour in preferences (with some MediaWiki settings to limit who can turn it off). That's a little bit of a work (mostly on checking compatibility with existing code and behaviours) but it's not really extension-worthy. Rd232 ^talk 00:41, 20 April 2011 (UTC)

It should be possible to make pages editable via mediawiki namespace. Cenarium (talk) 12:36, 25 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)

The general principle of getting WikiProjects to pitch in helping new articles that fall on their turf is an excellent one, but there substantial practical issues, not least because most wikiprojects aren't active enough to ensure a prompt response. A starting point might be some kind of bot notification system, so that AFC reviewers could classify new articles, and that classification is translated to a notification to the relevant project. Or something else. Anyway, it's certainly very worthwhile, but it'll be a lot of work to set up, so unless someone grabs the idea and tries to run with it, it won't happen. Rd232 ^talk 00:48, 20 April 2011 (UTC)

A system like deletion sorting or RFCs by subject area would be good, I think. I suspect that at least the larger projects would be able to find a few people to keep an eye out for them. Given the current volume and the users' lack of experience, the RFC model (nine general areas) is probably better than the deletion sorting model (hundreds of subcategories). WhatamIdoing (talk) 17:27, 23 April 2011 (UTC)

It seems like maybe this improvement has three steps: a) Tweak the first step of the Article wizard so that, for all users, if they have more than one mainspace edit recorded a Skip button* is added optionally taking them to Step 6 (so as to still give the choice of where to create the article), b) allow the wizard to accept optional info (switches) in the URL calling it, like redlink title, and automatically fill in the 3 boxes in Step 6 with it if specified (the user could still edit the title), and c) make a dev request for redlinks to direct to the wizard instead of a blank article, with a URL that includes article title in the agreed format. Requesting a preference for redlink article creation to totally skip the wizard would probably also be a good idea - for one thing so this function is still possible if the wizard blows a fuse. * This would be useful in general, for instance for quicker access to AfC, if its article page is to be made less discoverable because we're largely channelling people to the wizard.RedactionalOne (talk) 16:05, 21 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)
• Oppose Violates core principles, doesn't have a snowball's chance of ever happening. Guy Macon (talk) 00:00, 23 April 2011 (UTC)
• Oppose, but thanks for the good laugh. I needed that. Ironholds (talk) 23:57, 26 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)

On point 6: Even if the IP can be reliably associated with a school, there's rarely any way to differentiate between the IPs in the student computer lab vs the IPs in the teacher's work room. You'd hardly want to discourage teachers from improving articles solely because they used the same general network as the students. WhatamIdoing (talk) 17:37, 23 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)

Agree. I was wondering why this is the way it is too. I support improving the welcome mail. But I think this is not the right place to propose this, since it is the same with other sites like Commons or Meta. Maybe post at Meta? Rehman 15:07, 19 April 2011 (UTC)

Thanks for the support, Rehman.

Well, the confirmation email is actually used on almost any MediaWiki site so it should really perhaps be held on MediaWiki.org at this location. However, since this is the largest wiki in the world, I thought that it would be easier to crowdsource it here. However, I suggest that we ask for help from Commons and Meta, as well as other language versions, and keep the discussion here.//Hannibal (talk) 15:15, 19 April 2011 (UTC)

Wow. That is one soulless form letter. Your draft is very good. Some suggestions.

IP-adress → IP-address (misspelling)

With your new account, you can among many other things: Among other abilities, your new account will allow you to:

Two additions to the list that follows the above message : * create new encyclopedia articles on notable topics and * customize the way the site displays with different "skins"

keep track of any changes on to your favourite pages using your watchlist

send, and occasionally receive, emails to other users. send and receive emails from other Wikipedia 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! Naturally, we hope that you will help improve Wikipedia's article content. This is how easy it is to edit at 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; and 4) click "save page" below the edit box. That's it – the page is updated immediately! For much more about editing Wikipedia, please consider trying out the Wikipedia tutorial at http://en.wikipedia.org/wiki/Wikipedia:Tutorial

Hope this helps.--Fuhghettaboutit (talk) 20:38, 19 April 2011 (UTC)

It certainly does, Fuhghettaboutit. Thank you. As you can see, I used a few phrases from WP:Why. Are there other sources we can borrow from?//Hannibal (talk) 14:27, 20 April 2011 (UTC)

One suggestion I have is that it be made clear that the email is computer generated, and that replies won't get a response. That's the sort of mistake an inexperienced internet user just might make.--Fyre2387 ^{(talk • contribs)} 20:49, 20 April 2011 (UTC)

Good catch, Fyre2387. By the way, the email is sent from wiki@wikimedia.org. Is that an adress that we could redirect to info@wikimedia.org? See also Mono's version on the Outreach wiki.//Hannibal (talk) 22:00, 20 April 2011 (UTC)

I didn't even know it was possible to change that email message, or I would definitely have proposed a change earlier. I have a slightly different idea: that email is for emailconfirmed status (or whatever it's called), and we should focus on making that brief, to the point, and clear on how to confirm their email address. But after they click the confirm link, is there a way we can send out a second, better welcome message? I'm concerned that the first email will get too long if we explain what confirming the email does (we should mention more detailed what the benefits of confirming the email are), or people will read the welcome part and forget to actually click the confirmation link. /ƒETCHCOMMS/ 02:12, 22 April 2011 (UTC)

Thanks, Fetchcomms, for your comments.

Everything can be changed. You just have to know where the text is and have the user rights to do it :-)

Your idea is interesting. However, there are two arguments against it: first, it is significantly more difficult to send two emails than one, and, secondly, most other websites have one email message with these two purposes. The version I presented above have the two purposes clearly divided in separate paragraphs. There is also another angle on this: as long as we only use the system to send one message to their email adress (something I think we should change later on), we should take that opportunity to tell them something that most people still don't know: how Wikipedia works.//Hannibal (talk) 14:37, 22 April 2011 (UTC)

Here's a new version with all the above comments implemented:

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

Among other abilities, your new account will allow you to:

• keep track of any changes to your favourite pages using your watchlist
• create a user page
• edit without your IP-adress being visible
• use more advanced editing tools
• send and receive emails from other Wikipedia users
• create new encyclopedia articles on notable topics
• customize the way the site displays with different "skins"

Naturally, we hope that you will help improve Wikipedia's article content. This is how easy it is to 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. That's it – the page is updated immediately!

For much more information about editing Wikipedia, please consider trying out the Wikipedia tutorial at http://en.wikipedia.org/wiki/Wikipedia:Tutorial

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

This email is computer generated. You cannot respond to it.

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

$5"

What do you think? How about we try it and see what happens?//Hannibal (talk) 20:58, 22 April 2011 (UTC)

• Looks generally good. I would suggest two slightly-unrelated things (other than a few copyedits/rewordings here and there for your message): one, is there a way the WMF can create a survey/feedback form that we can link to in this message, so it's a better "test" or trial, and so we can get a better idea of what new users like and don't like?; and two, if we want to link to the PDF, I think it would be great to create an onwiki version (like Wikipedia:Contribution_Team/Welcome2) as the PDF is slow to load for me, and starting onwiki might lead to immediate contributions. These aren't ideas that directly impact the message itself, but I think a feedback form is especially a good way to gain insight into creating the best welcome possible. I especially think a non-onwiki feedback option is better (survey.wikimedia.org?) because it's confusing to edit for the first time, and all such onwiki feedback pages are either poorly formatted, or unwatched. /ƒETCHCOMMS/ 23:18, 22 April 2011 (UTC)

I did not know about the Wikipedia:Contribution_Team/Welcome2 page. Really neat.

About the survey. Of course, we would like more data. But surveys take time and my Fellowship ends in June. But, again, we like more data. So here are two suggestions: 1) someone else, like you, run the survey. When we did some surveys for the Account Creation Improvement Project, we first used SurveyMonkey, and then LimeSurvey (which WMF has its own version of at http://survey.wikimedia.org/). It's fairly easy, if the community decides it wants to do a survey. 2) The other suggestion is that we rely on the results. We have pretty stable numbers for how many start edit, and if we tweak this email, this is where the interesting stuff happens, not in a survey. But that's just my two cents. Anyone else?//Hannibal (talk) 13:27, 23 April 2011 (UTC) (PS. Please copyedit as you see fit. English is not my first language, and you always go blind with your own texts.)

Side comment: "English Wikipedia"

Looking at the message text quoted above, I'd like to suggest that "English Wikipedia", if not removed as per at least one draft above, should be changed to "English-language Wikipedia". Regulars know that Wikipedia is partitioned by language, but this message is to new people and invites the misinterpretation that "I registered with the wrong national version; I live in Australia/Canada/Scotland/USA, not England." --70.48.230.31 (talk) 19:59, 26 April 2011 (UTC)

I don't see the phrase "English Wikipedia" above. Am I missing something?//Hannibal (talk) 12:09, 27 April 2011 (UTC)

Online now

I have now edited the page to the version above, with a few minor changes. Let's see in a few days if we see any difference in how the newcomers react.//Hannibal (talk) 20:59, 27 April 2011 (UTC)

Educator's Approval

Whenever a project is assigned at my school, the teachers always announce that we can't use Wikipedia because it isn't always a reliable resource. Since I am a wikipedian, I know that most of the time articles are completely reliable. So I thought that there should be a mark or something on top of reliable articles called the "Educator's Approval" or "Reliable Article." The mark indicates that the article has been read and approved as reliable for students to use in projects and stuff. Once an article receives this mark, it is locked to lower level users to edit. Toontown59153 (talk) 21:04, 20 April 2011 (UTC)

See WP:PROT and WP:Pending changes for schemes vaguely similar to what you suggest. I highly doubt that anything else has any possibility. ╟─TreasuryTag►estoppel─╢ 21:06, 20 April 2011 (UTC)

The problem is that an article may be reliable for the information it provides, but may benefit from being expanded to provide more thorough coverage of a topic, or otherwise improve the article. Blocking new users from doing that will stifle the improvement of articles once that meet some threshold of reliability. We don't even lock down feature articles, that have been through an extensive review process. Monty₈₄₅ 21:15, 20 April 2011 (UTC)

Cf. Wikipedia:Stable versions --Cybercobra (talk) 22:57, 20 April 2011 (UTC)

Our friends at Citizendium have "expert-approved" articles (all 155 of them; they just dropped one not that long ago), but we do not want to go that route. The closest thing we have to that here is an FA. Otherwise, you're kinda on your own; although the purpose of Wikipedia is to be the starting point for research. Check the sources in the articles and read through those, and you should have a feel for how accurate the article is. The Blade of the Northern Lights (話して下さい) 03:17, 21 April 2011 (UTC)

The whole idea is wrong. If students extract the parts they need. And then verify those with the sources provided. Or simply! find a source on their own to verify with. Then even the teacher can't know if it's from wikipedia or anywhere else in practice. Of course just copying facts from articles without checking them could go wrong. But that's quite obvious. But that also applies to "established sources" .. Electron9 (talk) 07:40, 21 April 2011 (UTC)

Blade: "Check the sources in the articles and read through those, and you should have a feel for how accurate the article is." Actually, no. What about all the sources that aren't cited through ignorance or bias? They may say something totally different. Peter jackson (talk) 10:18, 21 April 2011 (UTC)

I said "a feel for" and not "it's the end-all be-all" for a reason. "A feel for" is just a basic idea, or at least that's what I was trying to say. The Blade of the Northern Lights (話して下さい) 22:31, 21 April 2011 (UTC)

In short: we do not expect you, your teachers, nor anyone else to trust us. My views are encapsulated there; take Wikipedia for what it is, as the above posters have suggested. Grandiose (me, talk, contribs) 16:21, 21 April 2011 (UTC)

Once I got past a certain point in school (somewhere in high school, if I recall), we were no longer allowed to use any encyclopedia as a source. We were supposed to go to the secondary sources ourselves and extract the information from those. In that regard, I agree with a statement by a teacher that Wikipedia may not be used as a source cited in the paper. Nothing prevents a student from looking up the Wikipedia article, going to the references section, and consulting the referred-to works directly. Yes, there are vandalism and missing-source issues, and that means people should think as they read and not take what they see for granted. At the end of the day, though, we aspire to be an encyclopedia—and teachers don't like students using encyclopedias as sources. —C.Fred (talk) 16:45, 21 April 2011 (UTC)

I don't think WP should ever directly be used as a source, but it can be assumed that a featured article is probably as reliable as WP is going to get. My tip would be to use the references an article provides, rather than the article itself, as WP is subject to change moreso than print or other web sources. In any case, WP will never introduce brand new ideas, per WP:OR, so everything that is stated in an article is going to be information from elsewhere. AD 17:41, 21 April 2011 (UTC)

I agree with C. Fred. Using tertiary sources is for little kids. If you can write a Wikipedia article based on secondary sources, you can do it with an essay, too. Also, nothing is guaranteed true or reliable. Even the Encyclopedia Britannica had faults. /ƒETCHCOMMS/ 02:15, 22 April 2011 (UTC)

Heh. Since at least the end of World War II, school kids have written their research papers based largely, if not solely, on the contents of an encyclopedia. (In some cases this research consisted of copying an entire encyclopedia article by hand, then putting their name at the top of the page.) For at least as long as that, teachers have told their students not to use the encyclopedia; this has at least kept the problem to a manageable minimum. I figure this abuse of encyclopedias will continue as long as students wait until the night before an assignment is due to start researching & writing their research papers. (For some reason, many school kids have better things to do with their time than homework. ;) -- llywrch (talk) 19:44, 25 April 2011 (UTC)

Create a new CSD - G:13 Unsalvageable WP:NOT Violations

Moved to Wikipedia_talk:Criteria_for_speedy_deletion#Create_a_new_CSD_-_G:13_Unsalvageable_WP:NOT_Violations

Article suggestions

Sometimes when I type in an article name for which there is no article, I get prompted to suggest it but am forbidden from writing it without an editor ID; other, rare times, I am allowed to edit; and still other times, I am not given the link to the well-hidden page for making article suggestions. I wish this could be made a lot more user-friendly. But I know that repeated requests in the past have been ignored and ridiculed. Anyway, I'd like to suggest an article on the Couture Culture or Complex (http://www.ontarioarchaeology.on.ca/summary/middlew.php; The Archaeology of Southern Ontario to AD 1650MJ Shott - American Antiquity, 1993 - JSTOR ). — Preceding unsigned comment added by 211.225.34.163 (talk • contribs)

Request added to Wikipedia:Requested_articles/Social_sciences#Archaeology --Cybercobra (talk) 01:18, 26 April 2011 (UTC)

Suggestion to include FLAC as an uploadable file format

I would like to make a suggestion for FLAC (Free Lossless Audio Codec) to be included as an uploadable file format. Currently Wikipedia (and all Wikimedia Foundation projects in general) do not support any type of lossless audio compression, and FLAC is a lossless audio codec format that is licensed under the GNU General Public License and BSD licenses.

Currently, the only audio format Wikipedia supports is Ogg Vorbis (*.ogg), which is a lossy audio compression format. Lossless audio codecs have the advantage over lossy audio formats such as MP3, Windows Media Audio and Ogg Vorbis, in that lossy audio formats result in a certain amount of data loss, in exchange for a smaller filesize. Although lossless formats have larger filesizes, little audio data is lost due to audio compression. (As a comparison, a lossless FLAC audio file running for 04:22 that is 34MB, when converted to MP3 format at 320kbps, becomes 10.5MB; for MP3 format at 128kbps, the size is further reduced to 4.7MB. Although the 320kbps MP3 will have better audio quality than the 128kbps MP3 file, it will still be lossy in comparison to the FLAC.) There is still decent compression achieved with FLAC though; despite having no loss compared to the original, a FLAC file will have a 30-50% smaller filesize in comparison to an uncompressed studio-quality CD audio track.

Wikimedia projects currently support no kind of lossless audio at all; adding support can open greater avenues in the future. Given that the price/capacity ratio of hard drives is decreasing over time and internet speeds are increasing, filesizes will become negligible in the future as the benefits of lossless formats exceed those of lossy formats. FLAC would be a good choice to begin such support, as it is not a proprietary format like other lossless codecs (for example, Apple Lossless owned by Apple Inc.) but rather, an open and royalty-free format, which complies with Wikipedia's "free encyclopedia" mantrum.

Wikipedia's supported filetypes in other areas all match in with one another. JPEG is a lossy compressed image format well-suited for photographs, PNG is a lossless raster image format suited for diagrams, GIF is suited for animated images, and SVG is suited for vector images. Hence, in regards to images, Wikipedia's filetype support pretty much fits in every hole possible. However, this is not so much the case for audio formats, and hence it would be beneficial to start off filling in empty gaps by supporting a free lossless audio codec.

I am aware that this is not necessarily a village pump topic, and it might be more suited to be addressed towards Wikimedia developers, however I am unsure of what avenues to take to make such a suggestion. Additionally, I would assume that such avenues have few participants, and hence lack of people may potentially result in a lack of overall interest. -- 李博杰  | —Talk contribs email 11:14, 26 April 2011 (UTC)

• Support—it's a free format. It's lossless. I can't think of any downsides. ╟─TreasuryTag►presiding officer─╢ 11:47, 26 April 2011 (UTC)
• Comment FLAC is already allowed in Commons, but must be wrapped in Ogg container: commons:Commons:File types#Sound. Native FLAC container files are not currently allowed, but Ogg files using FLAC codec are. MKFI (talk) 13:31, 26 April 2011 (UTC)
  • I've only checked the allowable filetype extensions for upload, my bad. But, is there a specific reason why the native FLAC container is not allowed? Certainly it has nothing to do with free/non-free formatting; I find it odd that it's only permissible through using an Ogg container. -- 李博杰  | —Talk contribs email 14:35, 26 April 2011 (UTC)
    • Although it is uploadable under the ogg container it is not playable unless downloaded. This makes the format impossible to use in artilces. Zginder 2011-04-26T20:36Z (UTC)
      • There is also very little creation and playback support of FLAC in ogg as discussed here. Zginder 2011-04-27T05:58Z (UTC)

• Comment We've definitely had this discussion before nott too long ago, but I'm not sure where. That said, I also have no problems with it, especially when the original file was in Mp3 (much better to transcode it to lossless than to lossy ogg and make it even worse quality). ♫ Melodia Chaconne ♫ (talk) 13:36, 26 April 2011 (UTC)
• Gods Yes Featured Sounds has run into the issue of not being able to use FLACs a few times. It's painful to try and work around the current arbitrary restrictions placed on free use codexes. What I think is the issue at hand is a) ignorance: the people that control this don't really know multimedia well enough to do this on their own and b) development resistance: there is a bit of a history of the file people asking for things and being told "wait for the next xxxxx" which, after a while, translates into "it's not worth our time to do, go away". Reason 2 is why so much of the in-Wikipedia support for sound files is lacking. Sven Manguard Wha? 15:24, 26 April 2011 (UTC)
• The number one item on my wishlist - Zginder 2011-04-26T20:36Z (UTC)
  • We need this for things like white noise with are impossible to compress and still be white noise. Zginder 2011-04-27T05:59Z (UTC)

• I thought you could upload FLAC in an ogg container. Is that not correct?--Sage Ross - Online Facilitator, Wikimedia Foundation (talk) 20:43, 26 April 2011 (UTC)
• Strongest possible Oppose the only audio format we should allow is MP3 (and possibly AAC these days) because that is the only format which is actually supported out the box by the vast majority of Wikipedia's userbase on Windows or Macs, or on portable devices like the iPhone or Android. Uploading audio into an obscure format like Ogg or FLAC doesn't make the content available to the vast majority of our userbase (though admittedly Android supports Ogg out the box). --Comment by Eraserhead1 from 22:13, 26 April 2011, split in multiple parts by response.
  • We most likely wouldn't use FLAC as the playback format, but rather transcode them to Ogg Vorbis for consistent playback. Another playback format would be a net minus as it would complicate the situation. --brion (talk) 00:17, 27 April 2011 (UTC)
• If people want to use lossless they shouldn't bother. There are far too many lossless formats (Apple's, Microsoft's etc.) that aren't mutually compatible. MP3 at 320kbps is pretty much perfect. --Comment by Eraserhead1 from 22:13, 26 April 2011, split in multiple parts by response.
  • You can't upload MP3 here. --brion (talk) 00:17, 27 April 2011 (UTC)
  • Why would Wikipedia even bother dealing with proprietary formats owned by Apple and Microsoft? Are you forgetting the three word motto that sits underneath the logo on the upper-left corner of this webpage? -- 李博杰  | —Talk contribs email 05:41, 27 April 2011 (UTC)
• Ultimately a free licence for FLAC or Ogg might be nice but it doesn't allow real users to easily access the content which is the whole point of Wikipedia. -- Eraserhead1 <talk> 22:13, 26 April 2011 (UTC)

  Pretty sure we can't use Mp3 for the same reason we can't have 'normal' style fair use. So that'll never happen even if consensus was for it. As for "not mutuallyh compatible" lossless formats, so what? Anyone who wants can convert without quality loss, so there's no harm in offering lossless. ♫ Melodia Chaconne ♫ (talk) 23:56, 26 April 2011 (UTC)

  • There is, sadly, no way in hell that we're going to get MP3 comparability because the file format is still proprietary. I wish it were not so, but we have to abide by the WMF board's rules, even if we think those rules are incredibly stupid sometimes. Sven Manguard Wha? 00:42, 27 April 2011 (UTC)
  • Open standards and open source are an integral part of free culture, which is one of Wikipedia's points. --Cybercobra (talk) 01:28, 27 April 2011 (UTC)
  • MP3 is a standardized format, but not a free format. Also, quote "MP3 at 320kbps is pretty much perfect" - not to everyone. Especially in the case of archiving sounds of historical value to the exact duplicate quality as the original, and for people with expensive sound systems like me who prefer to have everything perfect, and have no grifes over disk space (although this is less relevant to Wikipedia, and more related to obtaining music). -- 李博杰  | —Talk contribs email 03:00, 27 April 2011 (UTC)
    • With the rate that the developers are moving on this mp3 will be free, by expiring patents, and used on Wikipedia before FLAC. Zginder 2011-04-27T05:58Z (UTC)

• Support upload FLAC supported - but not for playback: Looking at Wikipedia as a long term resource, one should consider what formats both preserve content and are likely to be around for a lonnnggg time. I'll let someone else weigh in on whether FLAC will be around in several decades or not, but I do support uploading material in as high quality format as possible. As for playback, I think that pages like http://html5doctor.com/native-audio-in-the-browser/ have some bearing on this. We can anticipate that in the foreseeable future, HTML5 will be supported by the majority of browsers; as pointed out in the linked page, the <audio> element aims to support in-browser playback without the need for a plugin. As noted in this page (albeit from 2010) "there isn't yet a consensus on which codecs to support"; however, the "supported formats" table is telling . . . Ogg Vorbis is there and FLAC is not. Thus, to serve as an encyclopedia of record, we should support a lossless format for upload, and to serve as an encyclopedia for the people, we need to support playback in Ogg format. --User:Ceyockey (talk to me) 01:13, 27 April 2011 (UTC)
  • I am sorry, but I am just really confused here. First off, Wikipedia supports the upload and playback of all sorts of lesser used file types. The .djvu type comes to mind. Second, I'm not sure how you would go about uploading something and not making it available for playback. We'd be a repository of useless files then. Third of all, Wikipedia has built in support for any filetypes people upload here, so the content will be able to be played. FLAC can be downgraded into a lossy format using any number of free programs if someone really needs it. Finally, outside sources like your website have no bearing on what Wikipedia can or should do. The fact of the matter is that FLAC is a non-propriatary option, used in a small number of cases already. The choice here is not "do we make everything FLAC", the choice is "do we continue to turn away or degrade FLAC files or not". Sven Manguard Wha? 03:56, 27 April 2011 (UTC)
    • Agree. We are not advocating or aiming to be replacing everything with FLAC; we are aiming to make the option of having FLAC available, for upload and playback. Whether or not users choose to upload Ogg Vorbis or FLAC is entirely up to them. Being able to host FLAC audio in Ogg containers and not being able to play them is quite useless if the files are intended to be embedded into Wikipedia articles. A reader shouldn't have to download a file just to play it. -- 李博杰  | —Talk contribs email 05:22, 27 April 2011 (UTC)
  • Comparison of layout engines (HTML5 Media) here a better up to date list :p mabdul 19:48, 27 April 2011 (UTC)
    • Much better, agreed, and well sourced (at a casual glance). Another illustration of the superiority of Wikipedia in producing novel aggregations of data without resorting to synthesis. Thank you. --User:Ceyockey (talk to me) 01:20, 28 April 2011 (UTC)

• Would require a stipulation that FLAC cannot be used for non-free audio samples. --MASEM (t) 06:08, 27 April 2011 (UTC)
  • Naturally. Same reason why we don't have 4000x3000 high-resolution JPEGs of non-free images. -- 李博杰  | —Talk contribs email 06:32, 27 April 2011 (UTC)
• Uh, FLAC is already supported as an upload format. You just have to use an OGG container (OGG supports both FLAC streams and lossy stream formats). Typical FLAC encoders support OGG containers for FLAC streams and call them OGG/FLAC or OGG-Flac. I don't think the software will automatically render lossy versions of them, but you can always upload two versions of the audio file and crosslink them. Dcoetzee 06:35, 27 April 2011 (UTC)
  • Since FLAC is not fully supported (limited to the Ogg container; no playback), it would have very little use in an encyclopedia. Wikipedia is an encyclopedia, not a file-hosting service (WP:NOTMIRROR); what use is being able to upload FLACs if they can't be played and used in articles? -- 李博杰  | —Talk contribs email 06:43, 27 April 2011 (UTC)
    • Playback would be nice, but is unnecessary, since FLAC is primarily an archival format. The reason it's useful to the project is that it's important for archival and for editing of sound files without the inevitable generation loss incurred by decoding and re-encoding. The same reason we upload PNG versions of some photos. Additionally, certain technical articles like those devoted to signal analysis or audio compression require sound files for demonstration that have not been altered at all from the original waveform. These cannot be adequately emulated by a lossy format. Dcoetzee 10:47, 27 April 2011 (UTC)
      • The notion of supporting both an archival and a direct playback format was what I was trying to get at in my comment above ("Support upload FLAC supported - but not for playback"). I've been thinking, though, and I'm wondering if we shouldn't rely on Wikisource (or Commons, depending upon the nature of the content) for the archival component and Wikipedia for the direct playback component. --User:Ceyockey (talk to me) 01:24, 28 April 2011 (UTC)
  • @Above, using free formats is nice, but ultimately you have to live in the real world and use formats people actually use and can play on their computers. If licence fees are required to use MP3/H.264 (or whatever is sensible for video) then the Wikimedia foundation needs to pay them. I'd be more than happy to donate money to do so. -- Eraserhead1 <talk> 06:48, 27 April 2011 (UTC)
    • FLAC is a well-known, commonly used de facto standard amongst *cough* music piracy circles err I mean music enthusiasts, and those who store audiovisual data for a living. FLAC is supported by many commonly-used (and open-source!!) software such as Media Player Classic, Media Player Classic Home Cinema, VLC media player, foobar2000, etc etc. In fact, the number of FLAC releases in music torrents and usenet ehh I mean music enthusiast websites have been significantly increasing since FLAC was introduced, and at a much faster rate compared to the introduction of MP4 over AVI. Note that my point is not about using FLAC for music; my point is that FLAC is not a little-known format, and it does have applications in the real world. It can be acceptably and legally used as a lossless codec to store public domain, CC and/or historically relevant audio for use on an encyclopedia. -- 李博杰  | —Talk contribs email 07:14, 27 April 2011 (UTC)
      • The thing is that its not supported out the box by Windows Media Player, iTunes, iPod's, cheap Chinese MP3 players, iOS devices etc. etc. i.e. devices/software that normal people actually use in large numbers. -- Eraserhead1 <talk> 07:18, 27 April 2011 (UTC)
        • Do people browse Wikipedia on their Chinese knockoff iPods? -- 李博杰  | —Talk contribs email 07:22, 27 April 2011 (UTC)
        • Also, as for iTunes/iPod etc., as far as I know they don't support *.ogg either, I remember having to convert a batch of *.ogg to some funny propietary Apple format before putting it on my 5.5Gen iPod two years ago. -- 李博杰  | —Talk contribs email 07:25, 27 April 2011 (UTC)
          • No but they might browse it on their iPad's or other iOS devices or iTunes or Windows Media player - none of which support ogg or FLAC without installing an obscure plugin.
          • Music/video pirates online don't care if their music/video is in an obscure format and watchable by anyone else, as if their content was in widely used formats no-one would make any money out of piracy by selling that same music/video to people. -- Eraserhead1 <talk> 07:38, 27 April 2011 (UTC)
            • I don't think you understand the concept of piracy. Release groups don't intend on making money, they do it for the e-peen. Also, given that motion picture companies and audio recording labels are always complaining how "piracy is killing the industry" and how "they're losing $X billion dollars every year due to these nasty crims", I'm quite sure that the numbers of pirates are quite larger than you are thinking. Piracy isn't something that's done by 3,000 people. Also, to get back on topic, are you able to prove that FLAC is an "obscure format"? What makes a format "obscure" anyway? Not supported by spoon-feeding software companies? If iTunes doesn't support WMA and Windows Media Player doesn't support (insert proprietary Apple codec here), does that make them "obscure formats"? If you mean "not on the same popularity level as MP3", then does that make FLAC as "obscure" as Ogg Vorbis is? Plus, you shouldn't compare anything with MP3 here, as that would be akin to comparing apples and oranges, since FLAC is a lossless format and is completely unrelated to MP3. Wikipedia already has one lossy audio format, but no lossless formats supported for playback.
              I'm certain there are more people using Winamp than WMP. It doesn't hurt to install third-party software (what's the point of a computer anyway? To run compiled code known as "programs", no?), and WMP is poorly-coded bloatware in the first place. The argument that a file format must have "native support from an out-of-the-box operating system" in order to be "not obscure" makes no sense, as Shockwave Flash, Adobe PDF and RAR archives are all widely-used proprietary formats that can only be used with third-party applications. Also, the new range of Nokia smartphones have native FLAC support; wide-range support is gradually getting there, FLAC is a relatively new format, and you can't build Rome in one day.
              Regarding donating to the Wikimedia Foundation to allow them to pay for MP3 use like you have suggested above, that would go against Wikipedia's core principles, namely that Wikipedia is free content. It is the same reason why Wikipedia doesn't have advertisement banners, or that Jimmy Wales doesn't own oil wells in the middle of Tanzania.
              And as for being spoon-fed codecs by Windows/OSX/whatever, you're implying that only simple people browse Wikipedia. Does that mean that smart people who know what they're doing don't browse Wikipedia? Does that mean that, for the sake of simple people, the needs of smart people should be completely neglected on Wikipedia? That we should neglect something that can be of great benefit by the intelligentsia, for the sake of those who are not as experienced? -- 李博杰  | —Talk contribs email 08:12, 27 April 2011 (UTC)
• Support. —James ^{(Talk • Contribs)} • 6:33pm • 08:33, 27 April 2011 (UTC)
• Yes please this would help put FS so much. --In actu (Guerillero) | My Talk 17:54, 27 April 2011 (UTC)

• Support FLAC in ogg is uncommon, so plain FLAC should be supported. Tijfo098 (talk) 20:14, 29 April 2011 (UTC)

been here too long

When I saw "FLAC" in my Watchlist, I thought, oh, it must be another Wikipedia abbreviation for something like "Featured List/Article Criteria". ;-) Hang around here too long (or return after taking a Wikibreak), and you expect every unfamiliar but likely-looking abbreviation to be something about The Project that other Wikipedians expect you to know and recognize without explication. Why you could Dab me with a Prod! (or prod me with a dab, or something like that ....) —— Shakescene (talk) 02:43, 27 April 2011 (UTC)

That's not too bad. I've ended up with various strange slip-of-the-tongues, like saying "but that's not NPOV!" in the middle of an IRL discussion... :/ -- 李博杰  | —Talk contribs email 03:16, 27 April 2011 (UTC)

IRL = Ireland? (Anyway, that's what it means on automobile tags and at international sporting events; otherwise I'm clueless.) I'm GB in USA myself. —— Shakescene (talk) 04:20, 27 April 2011 (UTC)

"In real life". 28bytes (talk) 04:27, 27 April 2011 (UTC)

I pay the price in forgetfulness for my antique communications techniques, sans text, sans tweet, sans IM. —— Shakescene (talk) 05:06, 27 April 2011 (UTC)

We even have a (mediocre) article on that! Real life --Cybercobra (talk) 01:36, 28 April 2011 (UTC)

Advocating Firefox

Whenever I hover on a video, you are advocating for the use of Firefox. I thought Wikipedia is neutral and does not advertise/promote any other products. :/ Please remove this feature --Tyw7  (☎ Contact me! • Contributions)   Changing the world one edit at a time! 01:47, 27 April 2011 (UTC)

Um.... what, where, when? Your statement lacks key examples of when this is happening. How are we supposed to remove something if we have no clue what specifically you are talking about? Ajraddatz (Talk) 03:21, 27 April 2011 (UTC)

No it's a suggestion and it's because you have the Multimedia Beta gadget enabled and it's best supported on Firefox with the Firefogg add-on, please make sure you check the documentation. —James ^{(Talk • Contribs)} • 6:28pm • 08:28, 27 April 2011 (UTC)

Commons Notification bot

Recently the file Vote.svg, which is used on a very large number of pages, was deleted from Wikimedia Commons. This caused some concern and raised the possibility of having a notification bot to track deletions relevant to Wikipedia. There used to be a Commons Ticker bot, but this seems to have been down for some time.

Writing such a bot is actually fairly trivial to do and I have already put together much of the code needed. At this initial stage I am proposing a bot that does the following:

• Monitors the commons deletion logs for images which are used on Wikipedia
• Logs deletions to a central page (i.e. WP:Commons Deletions) for simple tracking
• Posts a talk page note for articles where deleted images are used (example template: User:CommonsNotification/imagedeletion_article)
• If more than, say, 50 articles are affected (or more than 75 pages in all namespaces) the bot would post to a central location - for example WP:AN or WP:VP (or both).

(Added: It will also watch the speedy deletion category and do similar notifications to the above)

The exaqct parameters for when it would post centrally are open to discussion (as well as where to place such a notice). Please suggest other ideas for improving the scope of the bot (although for now it might be best to focus on deletions only).

I have a WP:BRFA open here, but I think it needs central discussion too. --Errant ^(chat!) 09:10, 27 April 2011 (UTC)

Would the bot flag the file when it is nominated for deletion (or tagged for speedy) or only when it has been deleted? Obviously it would be helpful to know of the problem before the file is deleted, so that any appropriate action can be taken to rescue the filoe (either demonstrating it is fit for commons, or if possible and appropriate, moving to en:wiki.Nigel Ish (talk) 09:31, 27 April 2011 (UTC)

I am working on a good way to find out about nominations like that; so, yes, if I can figure out a good way this would be a definite functionality I would want to add :) Watching for actual deletions is easy-peasy (it's about 3 or 4 line of code using "pywikibot") so I started with that. (if anyone can help with a good way to grab the nominations for deletions from commons the help would be appreciated!) --Errant ^(chat!) 09:51, 27 April 2011 (UTC)

I figured a good way to do speedy deletion nomination tracking, so added that to the desc above --Errant ^(chat!) 12:24, 27 April 2011 (UTC)

Looks like a good idea to me; one thing which the bot should do is make sure that all inernal commons links are linked correctly from here, by replacing the "[[" with a "[[:commons:". עוד מישהו Od Mishehu 10:37, 27 April 2011 (UTC)

Good point, added to my TODO list. --Errant ^(chat!) 11:16, 27 April 2011 (UTC)

• We need something and if this looks good to the bot people from a bot standpoint I'd get behind it. Fact of the matter is that Commons is never going to reach out to us and tell us that they're deleting something we use. We have to go to them then and take the information, and this bot seems like a step in the right direction. Sven Manguard Wha? 23:39, 27 April 2011 (UTC)

• Apologies for the confusion, but I am not clear on how a file on Commons could be deleted if it is used extensively on one of the other Wikimedia Projects without some kind of notification. Is it that the governance of deletion on Commons is entirely independent of use? I don't expect a full education as part of this thread, but a pointer to the deletion discussion and/or the salient policies would be helpful. Thanks. --User:Ceyockey (talk to me) 01:35, 28 April 2011 (UTC)

I am not versed in Commons deletions policy per-se but it became clear from the mess over Vote.svg (AN/I thread) that we don't get notified of such a deletion.. Their deletion policy is here and it makes not mention of notification (or even checking). When I raised the issue at their admin noticeboard it didn't get a lot of interest. I figure... it would be awesome if they interacted more with us, but in lieu of that the bot might be able to plug some gaps. --Errant ^(chat!) 08:28, 28 April 2011 (UTC)

See Commons:Village_pump/Archive/2011/04#Proposal_to_increase_project_interconnectivity. Providing notice to all users of an image used on many projects is generally impractical, not least because they speak many languages. A new bot would be great, and I'd be happy to do it myself, but getting the existing bot (CommonsTicker) working on En would be better. Dcoetzee 10:25, 28 April 2011 (UTC)

I couldn't get in touch with the CommonsTicker person, it seems to be dead on all Wikis. The replacement bot I have coded is basically ready to go, just needs approval. --Errant ^(chat!) 11:16, 28 April 2011 (UTC)

Twinkle update

Twinkle probably needs new options in automatic warning notices. For example "Addition of duplicate material" would be helpful. Pass a Method talk 09:55, 27 April 2011 (UTC)

You may be looking for WT:TW. —  HELLKNOWZ  ▎TALK 09:58, 27 April 2011 (UTC)

cheers Pass a Method talk 10:11, 27 April 2011 (UTC)

Anti-vandalism user right for enabling major edits: 24hrs / 5 edits

Currently, any visitor to Wikipedia, registered or not, can make extensive edits to most existing pages. This makes vandalism easy and blocking ineffectual. 97% of vandalism is by IP editors, and most of this is of an obvious nature.

The proposal here would go some way to addressing this, while continuing to allow well-meant and predominantly useful edits by IP and newly registered editors.

Proposal

A new user right automatically triggered when the account has been in existence at least 24 hours and at least 5 edits have been made in mainspace – the Major edit user right.

Algorithm to restrict certain very major edits likely to be acts of vandalism such as:

• blanking
• extensive text replacement
• use of the ‘file’ (and ‘image’) tag
• algorithm-detectable acts of vandalism

Special restrictions may be warranted in the case of biographies of living persons, where even minor edits can lead to defamation, though that’s a discussion topic in its own right.

Benefits

• Reduction in the most offensive and libellous defacement
• Likely increase in registration
• Blocking made substantially more effective
• A boost for the 800 or so active admins, vastly outnumbered by the vandals
• Improved countering of topical attacks, ie on subjects briefly gone viral
• A measure that can be improved over time, ie by algorithm refinement
• Minimal impact on legitimate IP editors
• In keeping with core principal of ‘narrowly tailored’ security measures

The minor edit algorithm

There is an existing algorithm which displays a message to the user if they mark an edit as ‘Minor’ but it appears not to be. This proposal does not advocate using this same algorithm – the creation of a new section, for instance, could be a fairly common IP editor activity, and repurposing the existing algorithm would unduly impact that. However, the existing algorithm provides proof of concept.

An unwanted consequence of allowing only very minor edits for those who had not achieved Major edit status would be an increase in subtle, less readily detectable acts of vandalism.

Not a golden bullet

The perfectly legitimate argument is “Won’t the vandal just vary their edit until accepted?” Quite possibly, but the readership will have been spared those things that have been disallowed – posting of explicit images, for instance. The vandal will either have to put up with a less dramatic form of defacement or register and wait the 24hrs / 5 edits, in which case a ban would be effective at last. If, in a future discussion, consensus is reached for total protection of BLP articles for < 24hrs / 5 edits, that should mark a significant drop in potentially libellous edits – a Foundation benefit.

Related proposal

It has been proposed elsewhere that this 24hr / 5 edit requirement be in place for creation of new articles.

RedactionalOne (talk) 18:15, 27 April 2011 (UTC)

I'm sorry, I don't quite follow. These are, in essence, extra restrictions on registered accounts in their first 24 hours? Would you have to require registration to make these "major edits"? - this would amount to a considerable restriction on IPs. Grandiose (me, talk, contribs) 18:24, 27 April 2011 (UTC)

Yes, IP editors are not registered, and so have not been registered for 24 hours. That is kind of the point. The restriction on article creation by IPs has already been applied, yet that has little impact on the readership because they’re far more likely to visit an existing article. And that existing article, if vandalised, has most likely been defaced by an IP. Clearly (to me, at least) this situation is untenable. RedactionalOne (talk)

Many of the edit filters test for confirmed status (4 days and 10 edits), as well as other more finely defined criteria. They also work hard to identify the vandalism itself, and reduce the false positives that might occur with above blanket restrictions. I've seen many an IP rewrite an article for the better in a single edit. It seems time might be better spent improving the existing algorithms. -- zzuuzz ^(talk) 18:32, 27 April 2011 (UTC)

Well yes, it may be possible to achieve similar results with the Edit filter alone, but on a conceptual basis there’s a problem: an understandable reticence to put a ‘You seem to be a vandal’ message in front of someone who may not be. This proposal gets around that. It instead says ‘You can’t do that because your account is less than a day old’. The stats show that vandals are overwhelmingly spur of the moment. If they register they might start to feel like part of the community and be less likely to vandalise. And if they do, they can be blocked, and a second account will require a further 24 hrs / 5 edits. RedactionalOne (talk) 09:50, 28 April 2011 (UTC)

Meh, entirely unneeded WP:CREEP proposal. The Edit Filter already does this, and insofar as it doesn't do it to your liking, it can be made to do so. No need for extra stuff when existing stuff either works or can be tweaked. --Jayron32 18:43, 27 April 2011 (UTC)

WP:CREEP? This is a place for discussion of proposals. If you’re saying all current policies are perfect, you’ll presumably want to add a similar message to each proposal here! (Does anybody actually read the pages they link to? This linking seems like a really bad habit around here.) That the Edit filter already filters is great, but encouraging registration rather than a dysfunctional ‘anyone can instantly vandalise’ model seems pretty desirable to me. RedactionalOne (talk) 09:50, 28 April 2011 (UTC)

An unwanted consequence of allowing only very minor edits for those who had not achieved Major edit status would be an increase in subtle, less readily detectable acts of vandalism. - That seems like a pretty major tradeoff. If we have to have vandalism, I'd much rather have easily detectable vandalism like page blanking than subtle changes. The other downside is that if we use similar algorithms to anti-vandal software, that software will be almost entirely ineffective and we'll essentially be back to just looking at every single edit, whereas currently I believe software like huggle prioritizes edits based on those algorithms. Note that that vandalism study is 4 years old and used data as old as 2004. Things could be completely different now. It also had some methodological issues that seriously reduce the accuracy. Mr.Z-man 19:03, 27 April 2011 (UTC)

It’s not a trade-off, because I’m not proposing only allowing very small edits. There would be a restriction on, for instance, adding an image tag or editing the target (changing an image to an offensive one). And various other measures against highly offensive or defamatory vandalism. But major changes like adding a paragraph or section would still be possible. The sentence you’ve quoted describes the danger of only allowing minor edits (quite aside from the negative impact on legitimate IPs). The vandal is likely to try several times until the edit is accepted. They’re unlikely to get subtle just because they can’t post an image. RedactionalOne (talk) 09:50, 28 April 2011 (UTC)

Even if its not that subtle, the more obvious a vandal edit is, the easier it is to find. The obvious vandalism - things that can easily be found by bots and semi-auto programs - is typically reverted in seconds. I just don't see this type of obvious vandalism as a serious enough problem to warrant these kinds of restrictions. I would also point out that if IP and new users are allowed to add large amounts of text but not remove it, they may be unable to revert their own vandalism (which does happen regularly) or other vandalism they come across. According to that old, flawed vandalism study, 26% of vandalism reversion is done by anonymous users. Mr.Z-man 16:36, 28 April 2011 (UTC)

The issues people are having here really come down to the experienced IP editors (see my reply to Wnt in IP editors section below). Also, there seems to be a shocking lack of information on vandalism, with studies abandoned and nothing currently in progress. Given that the collection of articles in the small study that was carried out was random(ish) and didn’t look at favourite vandal targets, the actual percentage of vandal edits by IPs could be higher than 18% - already high.

It seems a lot more information would be helpful – both on vandalism stats and coalface issues. A drive to get experienced IP editors interested in registering would be highly desirable. Ultimately, I think unregistered editing will be discontinued, which will quickly see vandalism drop, editor/admin retention rise and our reputation improve. In the meantime, as this proposal is obviously not going anywhere, I’ll see about making improvements to image scrutiny by the Edit filter.

RedactionalOne (talk) 16:59, 29 April 2011 (UTC)

Obvious large-scale vandalism is essentially harmless (say, somebody replacing TFA with just PENIS PENIS PENIS is easily reverted and blocked and does little overall harm and might even do good: obvious vandalism every now and then reminds people not to trust everything they read on Wikipedia). Somebody changing "rabbi" to "rabbit" or vice versa is MUCH harder to detect, and truly harmful changes like subtle number vandalism is almost impossible to notice automatically. —Кузьма^討論 20:32, 27 April 2011 (UTC)

I agree that it’s fairly harmless to the encyclopaedia. But not to the editors, admins or, most significantly, readers. And if a parent finds that their child is coming across explicit images on innocuous articles there’s a danger they’ll try to censor this valuable resource, and that our reputation will suffer.

Again, I’m not proposing only allowing very minor edits. In the case of BLP, I think there’s a case for a blanket ban on < 24 hr edits, precisely because of that ‘rabbit’ issue. However, that’s more contentious. The ‘Accepted (latest)’ box in the corner of some articles is an interesting alternative approach that could have wide benefits for the whole site. It’s pro-reader, as the reader can’t realistically be expected to compare multiple versions when looking something up. The reminder that you can’t trust everything you read on Wikipedia is an interesting thought. But attempting to safeguard the integrity of the content is surely where the focus should lie. RedactionalOne (talk) 09:50, 28 April 2011 (UTC)

Monty845 stated opposition to the proposal here with the following comment: “Existing review of IP and new editor seems to be effective enough that the harm of loosing potentially constructive major edit contribution of new users outweighs any potential upside in reduced vandalism from the proposed restriction.”

You seem to be indicating that, despite about 18% of anonymous edits being vandalism this is fine because the changes are theoretically monitored? By that logic, presumably there’s never going to be any need to change anything, despite, for instance, NPP having a huge and growing backlog. Has it never occurred to people that those wishing to make constructive edits can simply register? Besides, this proposal doesn’t prevent most constructive edits, and an IP editor trying to rewrite an entire article in one edit, as zzuuzz puts it, is likely to come unstuck with the Edit filter already.

If Wikipedia was a company with 40,000 employed editors it could be sued for work practices that unduly stress its workforce: a system where life is made easy for the vandals and hard for the editors, who are faced with a huge and mounting workload of largely avoidable manual reversions – and all in the name of fostering new editors – saps who don’t realise what the working conditions are really like. RedactionalOne (talk) 15:44, 28 April 2011 (UTC)

Except of course that that this wouldn't affect anything at NPP, since it would still allow new users to add content. I don't see how NPP having a backlog is at all relevant here. We have a backlog of cleanup tasks to do too, should we also prohibit people from making edits that aren't perfect? That problem is arguably much more serious to the integrity of our content. We have over 6,500 articles with known POV issues and over 250,000 articles with statements tagged with {{cn}}. The NPP backlog and RC patrol at least have people actively working on them. Mr.Z-man 16:50, 28 April 2011 (UTC)

Well, the related proposal of applying the same 24 hour minimum account age for article creation (and funnelling the user towards the Article wizard for starting that article) would address that. An objection to that proposal was that creation of a new user right was a big deal for just that one purpose – that despite me having explained that there were multiple purposes. However, it turns out that autoconfirmed status is a pseudo-right, and utilising 24 hrs for either proposal should be straightforward, with or without a 5 edit requirement for one or the other. The NPP backlog is illustrative of the human component of the system being near breaking point – nearly a month and growing, I believe. Monty845 was implying that we have plenty of human resources to throw at undoing vandalism. This is a bit like saying that you’re happy having an inbox full of spam every day that takes you an hour to sift through and leaves insufficient time to actually read your mail. RedactionalOne (talk) 16:59, 29 April 2011 (UTC)

Frankly, any opposition to creating a new user group just because it creates a new user group should be ignored. The idea that creating a new user group is difficult (except to get consensus for it) has no basis in reality. Basically every user group created in the past several years exists for a single purpose, so that opposition makes even less sense. As for the "inbox full of spam", when it comes to typical vandalism, we do have users who are happy to sift through it. There are plenty of users who do enjoy recent changes patrol. Mr.Z-man 20:55, 29 April 2011 (UTC)

Wnt stated opposition to the proposal here with the following comment: “The idea of IP editing is to allow users to get right in and do things. This proposal saddles them with a new set of rules, like no use of images. The ban on extensive rewording sounds harmless... except half the time when I look at a diff it shows whole sections of the article deleted and remade, when really I only messed a few words around. Will new users interpret that as Wikipedia being super careful about vandalism, or just being broken/hard to figure out? Plus as someone pointed out at the target discussion, making vandals do smaller edits is not really doing anyone a favor. Page blanking you can fix - the wrong boiling point for tungsten carbide, not so much.”

Unfortunately, images are both a favourite with vandals and hard to police with algorithms, and, as stated, about 97% of vandalism is by IP editors. The obvious solution for legitimate editors who want to add images is to register. IPs carry on for years casually editing because IP access currently allows them to do all they need to (apart from, recently, create articles). If they need to do something that’s not possible via IP editing they’ll register – a useful way of bringing them ‘into the fold’.

Regarding your diffs point, the Edit filter – the technology that would be used – is quite sophisticated and discriminating. It sounds like it would be able to tell in most cases what was a genuine dubious edit. It would simply be using a different set of criteria – much as the criteria are different for non-autoconfirmed users – and presenting an ‘account not yet 24 hrs old’-type message rather than a ‘you appear to be a vandal’ one.

As previously stated, this proposal does not mark an attempt to allow only minor edits. (The boiling point for tungsten carbide provides an interesting challenge – perhaps it would be possible to add some sort of tag system for protecting specific words in an article; trusted users could add these and the Edit filter would protect the text between the tags from easy alteration – a granular level of protection.)

RedactionalOne (talk) 16:22, 28 April 2011 (UTC)

IP editors

I’m struggling to get my head around the obsession with the rights of IP editors over the rights of the readership and those who put so much time into attempting to maintain and safeguard the project. Registration is instant. It doesn’t require an email address, or any other form if identification (apart from IP address, which IP editors are displaying anyway). “You can edit this page right now” is therefore fully compatible with registration. That is Jimmy Wales’ wording of the core value. There is no mention of registration anywhere on his page. It’s true that in this and many other respects the list of values varies widely from the founding principals listed here. But that document also says “These principles may evolve or be refined over time”.

If IP editing was disallowed tomorrow, those people who’ve been making useful IP edits for years would simply register (and wonder why they hadn’t done so years ago!) Many sites ask you to register and give an email address just to comment on a blog. On Wikipedia, registration is quick and easy (although the prefs after doing so are not that user friendly and could be improved). Yes, some vandals would register too, but the overall rate of vandalism would probably drop markedly, and blocking would further improve things. There’s an argument that knowing the IP is useful, but this could easily – and automatically – be made available to those responsible for mitigating attacks. This could be done transparently; for instance, a warning that an edit appears to be vandalism and the user’s IP will be made available to relevant people if they apply it. In practice, though, IP address is obviously not a major deterrent – otherwise IP editor vandalism wouldn’t proliferate as it does.

It’s not a requirement of this proposal, but I think it’s time to reassess the benefits of IP edits versus the relentless harm.

RedactionalOne (talk) 09:50, 28 April 2011 (UTC)

I think that the classic "good IP user" is the person logging in from a public or private library terminal, or perhaps the one using a public Wi-Fi connection from a laptop or mobile device. He's gone there because he doesn't have access to the best references from his home computer. But should he go on Wikipedia and add the information? There could be a keylogger installed on the terminal, or someone could be spying on the wireless connection. If you log into Wikipedia under your username, someone could get ahold of it, make a bunch of vandal edits - before you know what happened, you're staring at The Scarlet Letter telling the world you're a loser in perpetuity. You were supposed to safeguard your account information, after all.

But of course the more common scenario is simply that someone hits on Wikipedia and wants to try it out, and can't be bothered to register. Not uncommon - I must have passed by the forums of many hundreds of newspapers because I couldn't be bothered to fool with them. Now maybe you can alleviate that slightly with salesmanship - making it clearer that e-mail verification isn't required, since it seems like a good 25% of the time such verification e-mails just never get sent. But that simplicity is undermined when people look at X edits/hours for some editing and Y for other editing.

I even have the sense, though, that vandalism edits are not purely harmful. Most of the time we're talking about young kids playing around. The idea that they can just change something seen by the world is subversive, alluring. It will pull to them long after "PENIS" loses its luster. Vandalism also serves as a sort of drill for article maintenance. Admittedly, we probably still have too many "drills" right now, but the frequency has decreased greatly since the old days, and maybe zero isn't the optimal level. Vandalism reverts give evidence that the article really is being watched over, while conveying a message to readers that this is an open encyclopedia and it is not infallible. It may seem nice to be infallible, but no sooner do people start believing this then they start accusing you of giving out dangerous pseudoscientific and quack medical ideas, endorsing racism, etc. etc. Better to remain human. Wnt (talk) 18:54, 28 April 2011 (UTC)

Nicely articulated, Wnt. I agree that a bit of salesmanship on the ease and benefits of registration would be good (as well as ensuring it really is easy and beneficial). I think we struggle to understand the ‘organism’, especially when it comes to unregistered editors, who do more than talk. Maybe that’s part of the answer right there – anonymity means not having the mild shame of someone saying one is using poor grammar or not following such-and-such policy.

However, Wikipedia is built on trust, and an IP editor doesn’t get on that ladder however long they edit. We want them to, or at least we should. We want each editor to be happy to be known for their positive contributions, and to fear the ‘Scarlet Letter’. We should set each user on the bottom rung, and if they decide not to climb then fine. But what we’re actually doing is putting the ladder in another room and hoping they’ll walk in and use it. I notice the proposal for ending IP editing is on the list of those that perennially fail to gain consensus. Better stats and presentation would doubtless help.

The proposal here is not about ending vandalism – a tall order on an encyclopaedia anyone can edit. It’s about making 24 hours a noted milestone that, barring abuse, is more trusted than a freshly created one. The problem of experienced IP editors being (slightly) affected is not a flaw in the proposal but rather a flaw in the existing model, as stated above. And if it presents a reason to register it’s probably more of an opportunity than a problem.

Regarding simplicity being undermined, the Edit filter already disproves this. It operates on differing levels of stringency depending on how trusted the user appears to be – for instance, whether over 4 days / 10 edits – and does this transparent to the user. The 24 hour threshold seems like a useful addition – one which certain trusted operations, which new users wouldn’t be expected to embark upon (ie article creation), could be keyed to.

RedactionalOne (talk) 16:59, 29 April 2011 (UTC)

I think you should read about WP:Pending changes, a proposal to make edits by IPs and newbies 'invisible' unless and until some more experienced person has looked them over for vandalism and libel. It is applied per-article, rather than to 100% of pages, but I think you'll find it interesting. It has the virtue of letting people make changes, without the next unsuspecting reader finding that the page has been replaced by "I LOVE CHEESEBURGERS!" Unlike your proposal, it dispenses with the inherent problem of defining a "major edit" and simply makes them all subject to review.

Fair warning: PC is a big political mess at the moment. Some people decided that they were "lied to" when the community decided after the fact to keep PC in use beyond the originally specified two months, but since a clear majority of the community wants PC in use in some fashion, I think that once a reasonable policy gets worked out, it will be used on some thousands of the articles with the biggest vandalism problems. WhatamIdoing (talk) 19:20, 29 April 2011 (UTC)

Thanks, WhatamIdoing. Funnily enough, I independently came up with the notion that edits of non-autoconfirmed users should not go live immediately, after seeing the ‘Accepted (latest)’ box and mulling over the founding principal which currently blocks moves to ban IP edits. Had realised Pending Changes had gotten political, but not that that was what that little box in the corner is about. So yes, I fully support that. My only question would be over 'Reviewer' status, which looks like it has to be granted by an admin, going against the open nature of the community encapsulated in Jimmy Wales' version of the core values: "...people [should be] automatically given full privileges once they have been around the community for a very short period of time." Obviously account length is not sufficient on it's own, but hopefully some algorithm can be determined to set Reviewer status. RedactionalOne (talk) 17:26, 1 May 2011 (UTC)

MediaWiki:Previewnote

It's been suggested to make MediaWiki:Previewnote more graphical, as it is in the French Wikipedia. See Wikipedia:MediaWiki_messages#Graphical. Rd232 ^talk 22:28, 27 April 2011 (UTC)

New Page Patrolling

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Closed by WP:SNOW ~~EBE123~~ ^talk_Contribs 23:19, 29 April 2011 (UTC)

---

I've just been reading Wikipedia:Village pump (proposals)/Proposal to require autoconfirmed status in order to create articles and was fascinated by how often phrases such as "their article" appeared in reference to the pages created by new users. I find it interesting how so many people referred to new pages as though, in being created by a new user, they somehow belong to that user. Granted, this may simply have been a phrase of convenience rather than fact, but it seems to highlight a view that new pages don't belong to the community but rather to the page's creator. I wonder, then, if this is why new page patrolling often appears so bitey; instead of requesting a page creator to help upgrade a new page, the attitude seems to be to expect the page creator to fix everything. That approach may be fine at WP:FAC, but not at NPP: it places too much expectation on new users.

Therefore, to deal with this and all the other perennial complaints lodged against NPPs, I propose that New Page Patroller become a user right to be earned, as is the case with Reviewer and Rollbacker.

Proposal has been adjusted. Please see below.

It may be argued that NPPs simply need to be educated better about their role. However, don't others find it peculiar that some of those acting as the face of WP (in dealing with new users) are entirely self-appointed and, in some cases, are themselves new users? Letting the comunity decide who represents it will deal with a lot of the criticisms targeted at NPPs, as well as helping to ensure that only those who are sufficiently educated about their role end up doing it.

LordVetinari (talk) 13:22, 28 April 2011 (UTC)

Did you miss the part where new page patrollers were complaining about being completely overworked? The backlog has been rapidly increasing and is at 21 days already, won't be long until we have unpatrolled pages dropping off the back again. Now I honestly believe this proposal will be the fastest way to kill of wikipedia. Yoenit (talk) 13:45, 28 April 2011 (UTC)

Dropping off the back? Then, clearly that's a weakness in the software. Short of fiddling with the software, I suggest Category:Unreviewed pages. Problem solvered. "Please review these pages at your leisure". It's then a simple choice between autocategorising or maually categorising.

And if NPPs are complaining about being overworked, then clearly they have the wrong hobby. I have a large backlog of stamps to sort out in my stamp collection but you'll never hear me whinging. No one is twisting the arms of the NPPs. No one is forcing them to do that task. I don't, however, think it's unreasonable to expect the job to be done properly. LordVetinari (talk) 14:10, 28 April 2011 (UTC)

In that case you will end up with a massive ever growing backlog and nobody to review it. The most important part of NPP is to screen out harmful crap (attackpages, oversightable material, copyvios, spam) and "Please review these pages at your leisure" completely misses that point. Also the BITEY part of NPP is incorrect or hasty speedy deletion tagging, which is not something you could limit with a userright. Another problem you commonly hear is pages with potential being deleted, which is done by admins. Do they automatically obtain this new user right? Then how would this solve anything. Yoenit (talk) 14:55, 28 April 2011 (UTC)

The "complaints lodged against NPPers" are almost exclusively from those who don't do it themselves. That you fail to see how important our work is is your fault alone. It's an inaccessible-enough job as it is, without making it more difficult. Making it a userright won't encourage people to do it, and a large percentage of what people bitch at NPPers for is a direct result of how few people want to do it. And you do not want a backlog at NPP developing lest a page that says, "Let's expose all burakus for what they are!!!!!!!!" with a link to a list of burakumin gets through; that sort of thing could destroy thousands of peoples' lives and send us into disrepute beyond repair. You're exceedingly lucky I caught that particular page, because unlike most English-speakers I know just how bad that is; if there are 20,000+ pages we need to sift through, there's a much better chance something like that would slip through. I can give you other examples if you like, but suffice to say that putting more pressure on us will do nothing but destroy what little control we (for now) have on NPP. The Blade of the Northern Lights (話して下さい) 18:17, 28 April 2011 (UTC)I just realized; "you" was meant to be a more general term, not directed at you specifically, LV. I was in a rush when I typed that, and reading through it again it didn't come out quite right. Sorry. 02:49, 29 April 2011 (UTC)

I suggested (secondarily) Category:Unreviewed pages as it would be no dfferent to Special:New Pages but with the exception that it has no back end from which older new pages may drop off. It's arguable whether or not it should replace Special:New Pages but, if it were used in conjunction, I believe it would massively decrease the workload. Consider: An inital round of NPPs flick through Special:New Pages to decide whether articles belong on Wikipedia; if they don't, they get speedied, prodded or AfDed; if they do, they're passed onto Category:Unreviewed pages for other NPPs and WikiGnomes to tag or fix as appropriate. There may be a shortage of NPPers but there doesn't appear to be a shortage of WikiGnomes, so why not divide and share the task. Perhaps more people will be willing to review new pages if they don't have to wade through attacks, spam etc. I suggest this based on my past experiences in Subway (Eat Fresh!). One person added the meat and cheese, someone else added the salads and condiments, and a third person rung it up at the till. It's a fast-moving conveyor belt that's easily more efficient than the "everyone does everything" chaos of other sandwich bars. (Incidentally, my "please review" comment above directly referred to the immediately preceding suggestion, the one I've just now described. Perhaps I should have explained myself better but I didn't think I'd have to.) LordVetinari (talk) 01:03, 29 April 2011 (UTC)

@Northern Lights. Who's bitching? Not this (former) NPPer. I know what NPP is like and left when I realised I still had more to learn about tagging (but not before coming across extremely new users also identifying as NPPers). As for the "complaints lodged" comment, I am not the one lodging complaints; I was simply referring to the fact that NPPers are often criticised. If my reply at 14:10 on 28 April indicates otherwise, it wasn't intended to. My words at that time were as sarcastic as they were due to the excessively blunt (and somewhat rude) response I got after posting this proposal. ("Hey look, someone's criticising NPP. ATTACK!") LordVetinari (talk) 01:03, 29 April 2011 (UTC)

After all, we are the most hated people around... (I actually like that essay a lot; don't worry Balloonman). In all seriousness, though, it's a rather low-visibility job that I sometimes compare to the people who slog through fair-use images; a lot of users tend to hear about the planes that crash, but not the overwhelming majority of correct tags we make. That's more my point; I've left a small note at the end of my comment above to clarify my true intent. The Blade of the Northern Lights (話して下さい) 03:16, 29 April 2011 (UTC)

Adjustment

In light of the additional proposal I made above, I'd like to change my proposal as follows:

• Add Category:Unreviewed pages to the NPPers toolkit, as described above.
• Make access to Special:New Pages a user right, but only if the Unreviewed category proposal is accepted.

LordVetinari (talk) 01:03, 29 April 2011 (UTC)

You should probably be aware of {{New unreviewed article}} and I suspect you're not. Rd232 ^talk 02:34, 29 April 2011 (UTC)

We really need to overhaul how that's used; right now it's just a giant timesink for a lot of articles that have already been reviewed, but someone forgot to remove the template. I'm not sure how to do that, but something has to give. The Blade of the Northern Lights (話して下さい) 02:48, 29 April 2011 (UTC)

The backlog is much less now that any Twinkle-tagging removes the template. Rd232 ^talk 03:24, 29 April 2011 (UTC)

I worked on the backlog briefly when Special:NewPages was under control, it was around 4000. I did notice a lot of the articles were from late 2009/early 2010. Any hope in getting a backlog drive together to knock that out somewhere? The Blade of the Northern Lights (話して下さい) 03:35, 29 April 2011 (UTC)

That large backlog (now gone) dates from before Twinkle was modified to remove the template, which was implemented in March 2010. Rd232 ^talk 03:41, 29 April 2011 (UTC)

I figured as much. But per this, the transclusion count for that template is at 4558 as of writing, and in going to three random pages two of them were from December 2009. If we can take out all the old ones, using the transclusion stats could be a lot more useful for helping us find the ones that actually haven't been reviewed. The Blade of the Northern Lights (話して下さい) 03:47, 29 April 2011 (UTC)

? The oldest existing category right now relates to articles from May 2010. Rd232 ^talk 18:53, 29 April 2011 (UTC)

Hmmm... I had a video of the Yankees winning their last World Series on in the background, and I probably accidentally typed 2009 instead of 2010. Anyways, it would still be helpful to knock out the older ones. The Blade of the Northern Lights (話して下さい) 19:09, 29 April 2011 (UTC)

• Oppose adding new user rights. This one is likely to become a prerequisite to adminship in the long run, and I don't see how it could make WP:RFA easier to pass. Plus, it is very unwiki to have to apply for the right to edit in a certain way, and we should try to be as wiki as we can. —Кузьма^討論 08:15, 29 April 2011 (UTC)
• Oppose in any form. The point of NPP is to get someone—anyone—to look over the article and make sure it's not obvious garbage. Anybody is capable of determining that "I LOVE CHEESEBURGERS!" is not a suitable encyclopedic article. The folks at WikiProject New Page Patrolling have provided a long list of optional activities, but the only thing the reviewer must do is alert the community to the presence of obvious garbage. If you're getting tripped up by all the extra advice, then ignore it. Obvious hoaxes and outright vandalism should be sent to WP:CSD; unsourced BLPs should be identified as such. Spamming in tags about formatting and links to other articles and such is not required. In fact, it may be discouraging to new editors and offensive to experienced ones, so doing less of that might be highly desirable for the community. WhatamIdoing (talk) 19:28, 29 April 2011 (UTC)
• Very much oppose It would just put more pressure on new Page Patrollers. I think that we should just close this for WP:When pigs fly. ~~EBE123~~ ^talk_Contribs 23:18, 29 April 2011 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal about edits to namespaces by non-autoconfirmed editors

I am just thinking that as sometimes non-autoconfirmed editors are sometimes, well, immature or misguided editors, that we should restrict editing by them to the main, user, and all talk namespaces. It is possible that someone could be being immature or do something stupid and do something like blank the main help page. Anyone have any comments on this idea? Yankeesrule3 (talk) 00:40, 30 April 2011 (UTC)

There are lots of places outside those spaces new users have perfectly legitimate reasons to be editing... for instance all the help desks. If there is a problem at a particular page, get it semi-protected. Otherwise just leave it to routine counter vandalism patrollers or page regulars to fix it. Monty₈₄₅ 02:31, 30 April 2011 (UTC)

What Monty said. Sven Manguard Wha? 04:02, 30 April 2011 (UTC)

This is an unreasonable restriction on users. Our methods of dealing with vandalism are adequate. --Jayron32 05:11, 30 April 2011 (UTC)

Wikipedia administrative areas are secondary to the encyclopedia mainspace. It makes no sense to allow newbie editing in mainspace but restrict it elsewhere. SpinningSpark 06:41, 30 April 2011 (UTC)

This is the free encyclopedia that anyone can edit. Also, many pages, such as the help desk and village pumps are used by anonymous users. I agree that the most vulnerable pages should be semi-protected, rather than restricting editing. -- Hazard-SJ  ±  17:11, 30 April 2011 (UTC)

I agree with the others. It's easy enough to revert, block, and semi-protect if absolutely necessary. BurtAlert (talk) 17:34, 1 May 2011 (UTC)

I can see why someone would suggest it, but per comments above, it's not a good idea. Rd232 ^talk 19:39, 1 May 2011 (UTC)

Signpost and Main Page

I've wondered in the past if we shouldn't expose a bit more of Wikipedia's innards on the Main Page (a section of it for highlighting backlogs, for instance). And I've just noticed that the section "Other areas of Wikipedia" only covers half the page. Why not use the other half to show the WP:SIGNPOST headings? Rd232 ^talk 02:15, 2 May 2011 (UTC)

I don't think the Signpost should be for the general public. However, I agree that a bit more of the inner workings of Wikipedia (as opposed to a finished-looking project) should be visible from the Main Page. Most other Wikipedias (ok, I just checked German, French, Spanish, and Polish) have much more visible content about the project or suggesting contribution than we do. Even just making the "Other areas of Wikipedia" stand out more (it has no images, and is low on a page full with images and information) might help draw people to the Community Portal, where the Signpost is included. I guess the next redesign of the Main Page should focus more on "free" and "anyone can edit" than "encyclopedia". —Кузьма^討論 11:09, 2 May 2011 (UTC)

Next step in Account Creation Improvement Project

Hello,

I just wanted to share with a little about what is going on with the Account Creation Improvement Project, some things of which have important implications for English Wikipedia.

In a few days' time we are going to start more tests on the account creation process, in essence these three MediaWiki system messages:

• http://en.wikipedia.org/wiki/MediaWiki:Fancycaptcha-createaccount
• http://en.wikipedia.org/wiki/MediaWiki:Loginend
• http://en.wikipedia.org/wiki/MediaWiki:Welcomecreation

Previously we've done a few tests (at two points we managed to increase the number of people who actually start to edit from 27-28% to 35%), but what we have coming up is so much more than the minor tests we have done so far.

There are two big differences:

1. Now we are creating two completely new account creation processes that we can test alongside the variations of the original. Both versions are geared towards directing the new users to specific tasks: in one version (not finished yet) we are presenting them with a few tasks that suits their interests and skills. This is a model that we hope can help some of the biggest problem categories out there. In the other version (not finished yet) we are focusing on learning more about the new user and educating him/her in how Wikipedia works through their user page. (As you may know, we treat newcomers worse than veteran Wikipedians, just because we don't know them, which is why we should advice them to tell us about themselves before they start editing.) These two models will be tweaked and refined for a long time, and in the end we will see which one "performs" best. It may be that none of them are better than what we had before, and then we will go back to that model, or it may be that someone from the community comes up with an even better model, and then we'll go with that.

2. The second new thing is that we have some very cool new testing tools. With the help of the tech staff at the Wikimedia Foundation, we can now understand where in the account creation process we lose the new user, and even what happens afterwards (i.e. not on user name level, but only which account creation model is more successful). The blog post that I linked to above explains how and answers most of your questions about that.

Yes, sneakily hidden in this message is a short mention of the fact that we will again perform an experiment that some of you protested the last time we did it (despite it being very succesful, we might add), but we believe that this version will be different in a few aspects:

• the new users will be asked questions about themselves, not be given a whole list of rules to follow, making for identical user pages - it's easier now to find new users who are interested in your subject, and find new users who will be troublemakers, based on their user pages
• they will automatically be sorted into a "New user category". When you feel that the user no longer fits that description (or the user him/herself feels that), that category can be removed/exchanged for a more fitting category
• we will not put all new account in this test model, which means that there is less of a mess to clean up if something bad should happen
• we will let you know in advance before we roll it out and are aware of the problems that can come up

As always, we are not only looking at the results (how many that start editing). We are also listening closely to all comments and suggestions. We try to answer all questions. And we love people coming up with alternatives and ways around problems.

Best wishes, Hannibal (talk) 14:24, 2 May 2011 (UTC)

Combatting linkrot

It is my opinion that WP:LINKROT is a major problem for Wikipedia. Yet no consensus seems to have been reached over an efficient working solution to this problem. There is this toolserver WebCite App which can be used to archive urls at WebCite (see also WP:WEBCITE) using a script by User:Δ. Is it possible, for example, to incorporate this script into the WP:TOOLBOX? This would allow all editors to archive references directly when adding references to an article. Also I think many editors are not aware of archiving services like WebCite. If not already preemptively archived when being added to an article, when a source dies it is in most cases already too late to do something about it. I would welcome the addition of this script to the toolbox with a permanent edit notice in the edit window pointing editors to this tool in the toolbox. Toshio Yamaguchi (talk) 15:36, 2 May 2011 (UTC)

CSS for only new users

At the discussion about MediaWiki:Previewnote someone remarked "There must be some way we can show this to only new users". Assuming there isn't, would it be a good idea to have a way to do this? Perhaps a sort of newusers.css which would allow edit instructions to be highlighted much more boldly? Rd232 ^talk 22:20, 2 May 2011 (UTC)

As of r82285, stylesheets MediaWiki:Group-autoconfirmed.css, MediaWiki:Group-sysop.js, etc, will be loaded automatically if they have content. There are deliberately no stylesheets for the '*' and 'user' groups, mainly for performance reasons, but you can (and should anyway) show the content by default and hide it for autoconfirmed users in Autoconfirmed.css. When the software is next updated to support it, of course. Until then, it might be worth loading those pages with JS to get the functionality immediately, if desired. Happy‑melon 22:55, 2 May 2011 (UTC)