Steve Bennett wrote: If you can't distinguish between a small correction or vandalism, this probably means the fact isn't sourced. Either add a source, or if you can't at least a {{citeneeded}} or related tag. Indeed. I believe edit summaries should be made mandatory, that would really help to detect vandalism. Ruud

On 8/23/06, Prasad J <prasad59(a)gmail.com> wrote: Do we need to? A huge amount of vandalism on wikipedia is a result of "can I really edit this?" as evidenced by the high levels of self revert. Because of this, it is sound policy to warn on the first incident rather than block. Unfortunately we don't have a good way of closely monitoring the contribs of a warned user, but thats another matter. In any case, our primary concern on this matter is to be accurate... it doesn't matter if the error was induced through an honest mistake, idle curiosity, or malicious intent. We still must detect and resolve it.

On 8/24/06, Ray Saintonge <saintonge(a)telus.net> wrote: I hope I'm misunderstanding you. If someone is editing a paragraph and changes the year 105 to [[1050]] you think it would be inapproiate to warn them to execute more care?

On 8/24/06, Gregory Maxwell <gmaxwell(a)gmail.com> wrote: It would be fascinating to construct a sort of dynamic trust metric where people have trust ratings that cause all kinds of interesting things to happen. Anons could be given 3 out of 10, and slowly start heading upwards if they register and keep their noses clean. Vandalism-detection bots could take into account the trust metric to work out if a change is likely a mistake or deliberate. Lots of fun, but probably terrible for social harmony. Steve

On 8/23/06, Ruud Koot <r.koot(a)students.uu.nl> wrote: Sure, but extremely few dates anywhere are sourced. Consider a midlength article with no sources at all, and someone comes and changes one date. Sure, you can put {{citeneeded}}. But will it help? We're not quite at the point of treating unsourced information as the exception as the rule :) Um, what does "mandatory" mean. If you're talking about a technical solution, it's a waste of time. Incidentally, I have managed to get my edit summary usage up to 100%. It was tough, but I've finally changed my habits. Steve

On 23/08/06, Ruud Koot <r.koot(a)students.uu.nl> wrote: The result will be (a) added nuisance (b) to exchange blank edit summaries for "asdfsadfsadfsadf".

Phil Sandifer wrote: A single random letter would be more efficient... especially when otherwise the edit summary would be longer than the edit itself. Ec

David Gerard wrote: Such an edit summary would at least make it clear we're dealing with vandalism. Sock puppets might reveal themselves by using similar nonsense summaries. It might be worth the added nuisance? Ruud

Ruud Koot wrote: It seems like the subtext message to vandals is, "If you want your vandalism to last accompany it with a sensible edit summary." :-) Ec

On Wed, 23 Aug 2006 15:20:47 +0200, "Steve Bennett" <stevagewp(a)gmail.com> wrote: Ditto. I added a script to monobook.js :-) Guy (JzG) -- http://www.chapmancentral.co.uk http://en.wikipedia.org/wiki/User:JzG

On 8/23/06, Guy Chapman aka JzG <guy.chapman(a)spamcop.net> wrote: I think I switched on the "prompt me" but finally manage to remember it anyway. The two hardest summaries for me to come up with are: - redirects (I usually put either "rd" or "rd common misspelling" etc) - changes to my monobook.js - too bad the RfA nazis don't take into account *what* you're editing when you fail to leave an edit summary :) Steve

On 8/23/06, Ruud Koot &lt;r.koot(a)students.uu.nl&gt; wrote: Right. In my mind there are really two tightly related problems: 1) Catching that a simple piece of factual data has been changed. and 2) Actually verifying that the change is good. (1) is more important, because if we don't know that a change is made we can't verify it... But I also think that (1) is the easier part to improve... We could have a bot detecting many such changes and place them on a list, for example. Not a complete solution, but with a little effort we could probably quadruple our effectiveness. Over time, such features could be enhanced in a decentralized way by things like invisible <fact></fact> tags that tell bots about immutable text. (bot would keep a list of fact tags it has seen in an article and warn if one is changed or removed) Some cynical offlist mail I received suggested that I might really be advocating stable versions here.... and it's true that I think stable versions will be a vast improvement on this point. But even with stable versions I'm not confident that such changes would get the high level of scrutiny they deserve, and that any technical or social improvements we come up with would also be useful in a future with stable versions. (2) is much harder... If the fact is cited to an online resource then it is just a question of motivation to get people to check. ... But what if it's cited to an offline resource or, more commonly, not cited at all? I have mixed feelings about how to address (2)... We could, for example, treat the case like a dispute over uncited material, where our default action is usually to remove the uncited claims and request that the disputing parties provide citations. But since there is so much totally uncited basic data, such a policy would have the effect of creating a new form of vandalism... and potentially result in an overall reduction of good information. We could also revert unless the later editor justifies their claim.... but I've seen a number of comment less date changes which did check out, so that too has problems. I like the suggestion of changing the edit summary text to the most simplistic "Please explain your edit" or the like. I am not sure I see the benefits in mandatory edit summaries... at least today the lack of a summary is a reasonable indicator that the edit may need a deeper look.

On 23/08/06, Alphax (Wikipedia email) &lt;alphasigmax(a)gmail.com&gt; wrote: Such a system would have far more applications than just preventing date vandalism. I was toying with an idea like this a little while ago, to help sort out some of the metadata mess in biography articles (specialised infobox + dates in lead + persondata = redundancy!). I have looked at the Semantic Wikipedia's efforts, but they seem to be exactly backwards to what I have in mind: specifying the raw facts somewhere, something like this pseudosyntax and made-up dates: <metadata-specification> <date-of-birth>[[19 July]] [[1891]]</date-of-birth> <date-of-death>[[6 August]] [[1954]]</date-of-death> <metadata-specification> and then being put into the article wherever needed (again pseudosyntax): {{random-specialised-infobox | born = <metadata>date-of-birth</metadata> | died = <metadata>date-of-death</metadata>}} Mr Smith (<metadata>date-of-birth</metadata> - <metadata>date-of-death</metadata>) ...