ayg wrote:

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.

ui2t5v002 wrote:

(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.

ayg wrote:

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.

ui2t5v002 wrote:

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.

robchur wrote:

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.

ui2t5v002 wrote:

(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.

robchur wrote:

(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.

ui2t5v002 wrote:

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

robchur wrote:

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.

ui2t5v002 wrote:

(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.

robchur wrote:

(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.

ui2t5v002 wrote:

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

robchur wrote:

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.

ui2t5v002 wrote:

(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?

robchur wrote:

"Think of it as a tag that says..." and "...someone needs to check it soon"
imply that.

ui2t5v002 wrote:

Why wontfix?

We already have patrolled edits, that show ! marks in recentchanges and [mark as
patrolled] on diffs.

robchur wrote:

Because it's ineffective and redundant to both patrolled edits, which we have,
and stable versions, which are coming soon.