There are a lot of drive-by commentless date changes. Much (but not all of them) are vandalism. They are often difficult to fact check, and these days with so much vandalism reverted by bots, I'm worried that even more date changes are being missed.
I believe this is one of the most serious and shameful areas of factual error on Wikipedia, although perhaps it is not the most urgent nor the easiest to improve on...
An example: Tonight I reverted a date vandalism to [[Pioneer plaque]] which was made over a year ago (http://en.wikipedia.org/w/index.php?title=Pioneer_plaque&diff=14242706&a...).
In that case, it would appear that the edits of a good user hid the bad diff.
Does anyone have any good ideas kicking around in their heads on how to improve this situation... I've thought of some things but I'd like to collect some ideas.
On Wed, 2006-08-23 at 00:39 -0400, Gregory Maxwell wrote:
There are a lot of drive-by commentless date changes. Much (but not all of them) are vandalism. They are often difficult to fact check, and these days with so much vandalism reverted by bots, I'm worried that even more date changes are being missed.
I can't necessarily speak for anyone else, but my instinct would be to revert edits that consist solely or almost solely of uncited date changes on sight and ask the editor responsible to provide a reference in the article if he or she wants to re-add . As editors, we should have a high standard of verifiability for such basic and easily researched facts as dates.
On 8/23/06, Christopher Larberg christopherlarberg@gmail.com wrote:
On Wed, 2006-08-23 at 00:39 -0400, Gregory Maxwell wrote:
There are a lot of drive-by commentless date changes. Much (but not all of them) are vandalism. They are often difficult to fact check, and these days with so much vandalism reverted by bots, I'm worried that even more date changes are being missed.
I can't necessarily speak for anyone else, but my instinct would be to revert edits that consist solely or almost solely of uncited date changes on sight and ask the editor responsible to provide a reference in the article if he or she wants to re-add . As editors, we should have a high standard of verifiability for such basic and easily researched facts as dates.
Thanks for raising this issue, it's something that had bothered me. I see a lot of these little changes (frequently population changes, number of career wins of some sportsperson etc...) and am torn between assuming good faith (and respecting the wiki model that people are making small improvements), and suspecting vandalism.
Could we replace the linked "Edit summary" text next to the edit summary box with something more explanatory, like "Please explain this change"? Maybe just for anons? I don't want to revert good changes, but without a description or anything, it's really tough!
Steve
Steve Bennett wrote:
Thanks for raising this issue, it's something that had bothered me. I see a lot of these little changes (frequently population changes, number of career wins of some sportsperson etc...) and am torn between assuming good faith (and respecting the wiki model that people are making small improvements), and suspecting vandalism.
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.
Could we replace the linked "Edit summary" text next to the edit summary box with something more explanatory, like "Please explain this change"? Maybe just for anons? I don't want to revert good changes, but without a description or anything, it's really tough!
Indeed. I believe edit summaries should be made mandatory, that would really help to detect vandalism.
Ruud
How would you distinguish honest errors from malicious vandalism, especially with reagrd to something like dates? I could edit an article to reflect that World War 2 ended in 1935, without intending to do so because of a typographical error? Unless the edit is obvious vandalism, (like saying World War 2 ended in 2045-which cannot, reasonably, be termed a typograhical error), it would be difficult to seperate the vandals from those who make such errors while typing or as a result of looking up the date from a source that is not correct.
On 8/23/06, Prasad J prasad59@gmail.com wrote:
How would you distinguish honest errors from malicious vandalism, especially with reagrd to something like dates? I could edit an article to reflect that World War 2 ended in 1935, without intending to do so because of a typographical error? Unless the edit is obvious vandalism, (like saying World War 2 ended in 2045-which cannot, reasonably, be termed a typograhical error), it would be difficult to seperate the vandals from those who make such errors while typing or as a result of looking up the date from a source that is not correct.
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.
Gregory Maxwell wrote:
On 8/23/06, Prasad J prasad59@gmail.com wrote:
How would you distinguish honest errors from malicious vandalism, especially with reagrd to something like dates? I could edit an article to reflect that World War 2 ended in 1935, without intending to do so because of a typographical error? Unless the edit is obvious vandalism, (like saying World War 2 ended in 2045-which cannot, reasonably, be termed a typograhical error), it would be difficult to seperate the vandals from those who make such errors while typing or as a result of looking up the date from a source that is not correct.
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.
Unless there is an evident pattern in the editor's behaviour, the only way to resolve the problem is to fix the error, and go on with life. Warning a person for making an obvious typo, and blocking him if he makes a second typo strikes me as an extremist attitude.
Ec
On 8/24/06, Ray Saintonge saintonge@telus.net wrote:
Because of this, it is sound policy to warn on the first incident rather than block.
Unless there is an evident pattern in the editor's behaviour, the only way to resolve the problem is to fix the error, and go on with life. Warning a person for making an obvious typo, and blocking him if he makes a second typo strikes me as an extremist attitude.
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?
Gregory Maxwell wrote:
On 8/24/06, Ray Saintonge saintonge@telus.net wrote:
Because of this, it is sound policy to warn on the first incident rather than block.
Unless there is an evident pattern in the editor's behaviour, the only way to resolve the problem is to fix the error, and go on with life. Warning a person for making an obvious typo, and blocking him if he makes a second typo strikes me as an extremist attitude.
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?
You aren't misunderstanding me at all. That change may or may not be valid. Wikifying the date is a perfectly normal edit. Maybe 1050 was the correct year; maybe adding that "0" was a simple slip of the finger; I can't know outside of the context. I would assume good faith, fix the error, and carry on with something else. If he persists in the error after that I might want to initiate a friendly dialogue.
I have been around here long enough to have made my own share of typos, some of which I find exceedingly stupid when they are pointed out. That happens to the best of editors. Unless you can convince me that all your edits are perfect, it would be better that you not expect perfection from others. When you berate newbies with such trivialities you do a good job of showing that this is NOT a welcoming community.
Ec
On 8/24/06, Gregory Maxwell gmaxwell@gmail.com wrote:
block. Unfortunately we don't have a good way of closely monitoring the contribs of a warned user, but thats another matter.
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
Steve Bennett wrote:
On 8/24/06, Gregory Maxwell gmaxwell@gmail.com wrote:
block. Unfortunately we don't have a good way of closely monitoring the contribs of a warned user, but thats another matter.
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.
It would entirely depend who you made the data available to. If it was only available to a small group of people...
On 8/23/06, Ruud Koot r.koot@students.uu.nl wrote:
Steve Bennett wrote:
Thanks for raising this issue, it's something that had bothered me. I see a lot of these little changes (frequently population changes, number of career wins of some sportsperson etc...) and am torn between assuming good faith (and respecting the wiki model that people are making small improvements), and suspecting vandalism.
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.
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 :)
Indeed. I believe edit summaries should be made mandatory, that would really help to detect vandalism.
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
Steve Bennett wrote:
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.
If was thinking of letting MediaWiki enforce edit summaries. Why would that be a waste of time? At least the "Prompt me when entering a blank edit summary" preference should be enabled by default for anonymous and new users.
Ruud
On 23/08/06, Ruud Koot r.koot@students.uu.nl wrote:
If was thinking of letting MediaWiki enforce edit summaries. Why would that be a waste of time? At least the "Prompt me when entering a blank edit summary" preference should be enabled by default for anonymous and new users.
The result will be (a) added nuisance (b) to exchange blank edit summaries for "asdfsadfsadfsadf".
On Aug 23, 2006, at 9:32 AM, David Gerard wrote:
On 23/08/06, Ruud Koot r.koot@students.uu.nl wrote:
If was thinking of letting MediaWiki enforce edit summaries. Why would that be a waste of time? At least the "Prompt me when entering a blank edit summary" preference should be enabled by default for anonymous and new users.
The result will be (a) added nuisance (b) to exchange blank edit summaries for "asdfsadfsadfsadf".
Nonsense! I'm sure at least 10% of our contributors will go with "boobies" instead.
Best, Phil Sandifer sandifer@english.ufl.edu
You are standing in an open field west of a white house, with a boarded front door. There is a small mailbox here.
Phil Sandifer wrote:
On Aug 23, 2006, at 9:32 AM, David Gerard wrote:
On 23/08/06, Ruud Koot r.koot@students.uu.nl wrote:
If was thinking of letting MediaWiki enforce edit summaries. Why would that be a waste of time? At least the "Prompt me when entering a blank edit summary" preference should be enabled by default for anonymous and new users.
The result will be (a) added nuisance (b) to exchange blank edit summaries for "asdfsadfsadfsadf".
Nonsense! I'm sure at least 10% of our contributors will go with "boobies" instead.
A single random letter would be more efficient... especially when otherwise the edit summary would be longer than the edit itself.
Ec
On 8/23/06, Ray Saintonge saintonge@telus.net wrote:
A single random letter would be more efficient... especially when otherwise the edit summary would be longer than the edit itself.
Ec
I belive that problem is being worked on (rm rv sp MT).
David Gerard wrote:
The result will be (a) added nuisance (b) to exchange blank edit summaries for "asdfsadfsadfsadf".
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
On 23/08/06, Ruud Koot r.koot@students.uu.nl wrote:
David Gerard wrote:
The result will be (a) added nuisance (b) to exchange blank edit summaries for "asdfsadfsadfsadf".
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?
Perhaps, or perhaps the vandal detection bots could look for blank entries. Or perhaps they do now.
- d.
Ruud Koot wrote:
David Gerard wrote:
The result will be (a) added nuisance (b) to exchange blank edit summaries for "asdfsadfsadfsadf".
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?
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 8/23/06, David Gerard dgerard@gmail.com wrote:
On 23/08/06, Ruud Koot r.koot@students.uu.nl wrote:
If was thinking of letting MediaWiki enforce edit summaries. Why would that be a waste of time? At least the "Prompt me when entering a blank edit summary" preference should be enabled by default for anonymous and new users.
The result will be (a) added nuisance (b) to exchange blank edit summaries for "asdfsadfsadfsadf".
B) is good. Another way to annoy nuisance edits, and another data field for the bots to latch onto.
~maru
On Wed, 23 Aug 2006 15:20:47 +0200, "Steve Bennett" stevagewp@gmail.com wrote:
Incidentally, I have managed to get my edit summary usage up to 100%. It was tough, but I've finally changed my habits.
Ditto. I added a script to monobook.js :-)
Guy (JzG)
On 8/23/06, Guy Chapman aka JzG guy.chapman@spamcop.net wrote:
On Wed, 23 Aug 2006 15:20:47 +0200, "Steve Bennett" stevagewp@gmail.com wrote:
Incidentally, I have managed to get my edit summary usage up to 100%. It was tough, but I've finally changed my habits.
Ditto. I added a script to monobook.js :-)
It's actually now part of Mediawiki. Look at Preferences->Editing->Prompt me when entering a blank edit summary. It's very irritating, and therefore very useful.
On 8/23/06, Guy Chapman aka JzG guy.chapman@spamcop.net wrote:
On Wed, 23 Aug 2006 15:20:47 +0200, "Steve Bennett" stevagewp@gmail.com wrote:
Incidentally, I have managed to get my edit summary usage up to 100%. It was tough, but I've finally changed my habits.
Ditto. I added a script to monobook.js :-)
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 23/08/06, Steve Bennett stevagewp@gmail.com wrote:
On 8/23/06, Guy Chapman aka JzG guy.chapman@spamcop.net wrote:
On Wed, 23 Aug 2006 15:20:47 +0200, "Steve Bennett" stevagewp@gmail.com wrote:
Incidentally, I have managed to get my edit summary usage up to 100%. It was tough, but I've finally changed my habits.
Ditto. I added a script to monobook.js :-)
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 :)
Redirects seem to automatically produce an edit summary now...
On 8/23/06, Ruud Koot r.koot@students.uu.nl 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.
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.
Gregory Maxwell wrote:
There are a lot of drive-by commentless date changes. Much (but not all of them) are vandalism. They are often difficult to fact check, and these days with so much vandalism reverted by bots, I'm worried that even more date changes are being missed.
I believe this is one of the most serious and shameful areas of factual error on Wikipedia, although perhaps it is not the most urgent nor the easiest to improve on...
An example: Tonight I reverted a date vandalism to [[Pioneer plaque]] which was made over a year ago (http://en.wikipedia.org/w/index.php?title=Pioneer_plaque&diff=14242706&a...).
In that case, it would appear that the edits of a good user hid the bad diff.
Does anyone have any good ideas kicking around in their heads on how to improve this situation... I've thought of some things but I'd like to collect some ideas.
Ultimately we need some sort of wiki-meta-data system which is seperate from the articles...
On 23/08/06, Alphax (Wikipedia email) alphasigmax@gmail.com wrote:
Ultimately we need some sort of wiki-meta-data system which is seperate from the articles...
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>) ...
On 23/08/06, Gregory Maxwell gmaxwell@gmail.com wrote:
An example: Tonight I reverted a date vandalism to [[Pioneer plaque]] which was made over a year ago (http://en.wikipedia.org/w/index.php?title=Pioneer_plaque&diff=14242706&a...).
In that case, it would appear that the edits of a good user hid the bad diff.
Does anyone have any good ideas kicking around in their heads on how to improve this situation... I've thought of some things but I'd like to collect some ideas.
Yeah, in my view this is really a problem with the current wikipedia software- it doesn't highlight the low-fidelity nature of a previous edit and the good standing user ends up essentially authorising the edit.
In other words, if editors are shown a diff from anonymous or low edit count editors they are much more likely to check it out.