Last modified: 2012-11-09 15:20:12 UTC
Currently, when patrolling our watchlists or Recent changes, we concentrate on edits by anon or redlinked users when on the lookout for vandalism or bad edits. I think it would make a huge improvement in overall reliability if, instead of looking for troublesome users, we just looked for diffs that hadn't been viewed by anyone else yet. When you look at watchlists, recent changes, or contrib lists, there are indicators like m for "minor", N for "new" and "top". In addition, I think every diff should have an "unviewed" flag on it when created ("u"?), and the flag will be turned off when the diff has been viewed by someone besides the person who made that edit. This will make it much more likely that every edit was looked at by at least one well-meaning human editor. The flag should be displayed anywhere a list of diffs are displayed; watchlists, Recent changes, an article's history, etc. I think this would be wonderful for preventing vandalism from going unnoticed for days at a time, and would help with vetting of regular edits, too. Details: * Should it only remove the flag if viewed by an established editor (same people who can move pages or edit semi-protected pages)? * Only if viewed by two or three editors? * When someone views the diff for a number of consecutive edits, should all the flags be cleared?
Viewing is a really bad metric because not only do we not know if the person inspected it, we don't even know if they saw it. They could have clicked the wrong button by mistake and hit back or something. Make it easier and more seamless for relevant people to mark edits patrolled, nothing more or less.
(In reply to comment #1) > Viewing is a really bad metric because not only do we not know if the person > inspected it, we don't even know if they saw it. They could have clicked the > wrong button by mistake and hit back or something. Of course. But how often does that happen? This is also the reason for the requirement that two or three people have viewed it. What would be a better metric? > Make it easier and more > seamless for relevant people to mark edits patrolled, nothing more or less. How? Not enough people will do it, and it won't be any better than it is now.
Use a really big inviting button and make it encouragingly turn into a heart-warming "this page has been patrolled" checkmark when you click on it, sending something off via AJAX to minimize inconvenience.
I don't see very many people doing that, which would make it pointless. Everyone who "patrolled" an edit would have to click the patrol button, or multiple people would patrol it, thinking it hadn't been yet. Same as it is now. Negates the whole point of having it. Knowing that two people have viewed a diff is a very good metric for knowing whether it's been reviewed or not. Even if it someone checks the "patrolled" button, they may not have noticed sneaky vandalism, etc. Automatically marking that a diff has been viewed (by two or three people) and not subsequently reverted is a more reliable measurement of the "goodness" of an edit.
1. Basing it on diff views is nutso bonkers. I often view diffs, but it doesn't mean I've acted upon them. 2. Basing it on patrol flags is much less bonkers and that's the whole reason we have them. 3. The Patroller extension provides workload balancing for recent changes patrol using those flags, and a few other criteria, so multiple people don't review the same changes.
(In reply to comment #5) > 1. Basing it on diff views is nutso bonkers. I often view diffs, but it doesn't > mean I've acted upon them. How often do you view an obvious vandalism diff and then *not* revert it? > 2. Basing it on patrol flags is much less bonkers and that's the whole reason we > have them. We do? > 3. The Patroller extension provides workload balancing for recent changes patrol > using those flags, and a few other criteria, so multiple people don't review the > same changes. It will only work if a large number of people use it. Otherwise it's not any better than the current situation.
(In reply to comment #6) > (In reply to comment #5) > > 1. Basing it on diff views is nutso bonkers. I often view diffs, but it doesn't > > mean I've acted upon them. > > How often do you view an obvious vandalism diff and then *not* revert it? Often enough. > > 2. Basing it on patrol flags is much less bonkers and that's the whole reason we > > have them. > > We do? Have them? Yes. It's just that it's not actually switched on for the English Wikipedia, simply 'cause the interface sucked a bit, and so on. > > 3. The Patroller extension provides workload balancing for recent changes patrol > > using those flags, and a few other criteria, so multiple people don't review the > > same changes. > > It will only work if a large number of people use it. Otherwise it's not any > better than the current situation. That's the case for your suggestion as well, though. In fact, that is the case for *any* tool.
(In reply to comment #7) > Often enough. Often enough that this change wouldn't have any beneficial effect? No. Don't misunderstand. This flag does not indicate "This diff has been through a rigorous review process and has been tagged a good edit by an established Wikipedian." It indicates "This diff has not been looked at by *anyone* yet. Someone needs to check it." This isn't going to *prevent* people from looking at diffs that have already been looked at by others. They still will. This is meant to prevent the really obvious, awful vandalisms and crappy edits that slip past everyone and survive for days or weeks. It would cut vandalism revert times down a lot. > Have them? Yes. It's just that it's not actually switched on for the English > Wikipedia, simply 'cause the interface sucked a bit, and so on. You mean "It's turned off because, in practice, it didn't work?" > That's the case for your suggestion as well, though. In fact, that is the case > for *any* tool. Exactly. I could easily go around clicking the "I have reviewed this diff" button for every vandalism I make, or for bad ones I have looked at but not acted upon, etc. Every suggestion has flaws. So which of the proposed solutions would work *best*? (In real life.) Measuring whether a set number of people have viewed a diff? Measuring how many people have a page on their watchlist? Measuring how many good edits the editor of a diff has made or how long their account has been active? Measuring how many people have actively clicked on a "I have reviewed this diff" button? Allowing people to vote on whether a revision is good or bad (article validation extension)? Anon 70.230.73.20 said it well: "Any validation approach which needs extra work by the users won't bring a significant improvement compared to simply trusting people to improve bad articles through editing."
A flag to indicate that someone has merely *viewed* the diff wouldn't work when anonymous users did it, due to caching, and would require a database write somewhere to update this status. It's a similar prospect to page view counters. The flag that indicates that the change was reviewed in some manner is ultimately more useful.
(In reply to comment #5) > The Patroller extension provides workload balancing for recent changes patrol > using those flags, and a few other criteria, so multiple people don't review the > same changes. Is this extension too expensive to enable on enwiki? or is it not in a state where it could be used? because it looks like it would be incredibly useful. Maybe it could be updated to take advantage of the recently-introduced "undo" facility, for revisions which are no longer the most recent.
(In reply to comment #9) > A flag to indicate that someone has merely *viewed* the diff wouldn't work when > anonymous users did it, due to caching, It doesn't have to. It should only remove the flag if viewed by a logged-in user. > and would require a database write > somewhere to update this status. It's not possible to write to the database? > The flag that indicates that the change was reviewed in some manner is > ultimately more useful. On a wiki, in the vast majority of cases, there's no difference between "view" and "review". People "review" diffs by viewing them, and then deciding whether to leave them as they are (good review) or counteract them (bad review). Anything that requires additional active effort to say the same thing won't be used enough to make a difference.
(In reply to comment #10) > Is this extension too expensive to enable on enwiki? or is it not in a state where it > could be used? because it looks like it would be incredibly useful. Needs testing on a smaller community of users. Dummy test wikis just aren't the same. Expense should probably be considered, though; it certainly isn't a *lightweight* query.
No anti-vandalism system will detect all vandalism, or prevent false positives, so arguing that sometimes a "view" doesn't equal a "review" is irrelvant. The appropriate question is whether automatically flagging an edit as viewed (I think that's preferable to removing an "unviewed" flag) will help. I think for a lot of people it definitely WILL help. I agree with a suggestion above that an anonymous IP editor, or a newly registered editor (less than four days) who views a diff shouldn't have that view counted at all; that increases the chances significantly that a diff view is in fact a review. And if while it would be nice if a diff of a group of edits (specifically, of a set of consecutive edits by the same editor) would also be flagged, if that's difficult to program, let's settle for 90% of the pie and accept a solution where the flag is set only for diffs of one edit. As for anything that requires an editor to click an extra button saying that he/she has in fact reviewed an edit and approves it, unless that does more that tell another editor about the review (as I think it might in the German test, where it might establish a "stable version"), I don't think that people will take the time to do this. Of course, there is a way to split the difference: let editors, if they want, set a preference that every view of a diff automatically says "I reviewed this", and let them REMOVE that flag on an individual basis rather than having to take an action to set it. In any case, flagging needs to be built into the software to be effective -- doing an add-on, like pop-ups, requires too much action by editors to add that to their system.
Don't think of this as a tag that says, "This edit has been viewed/reviewed/confirmed/approved and found to be good". Think of it as a tag that says, "This edit has not been viewed by anyone, ever. Someone needs to check it soon."
Then this is a duplicate of the numerous requests to implement stable version tagging and reviewing, and will be dealt with at the same time as all of those, if not in this form.
(In reply to comment #15) > Then this is a duplicate of the numerous requests to implement stable version > tagging and reviewing, and will be dealt with at the same time as all of those, > if not in this form. How is this in any way related to "stable version" or article review concepts?
"Think of it as a tag that says..." and "...someone needs to check it soon" imply that.
Why wontfix?
We already have patrolled edits, that show ! marks in recentchanges and [mark as patrolled] on diffs.
Because it's ineffective and redundant to both patrolled edits, which we have, and stable versions, which are coming soon.
