Discussion:
Flagged Revisions too instrusive
Andrew Whitworth
2007-09-24 12:59:26 UTC
Permalink
As it is planned, the feature is simply too intrusive. Once an
article is flagged as "sighted", there is no way back.
I have to wonder whether this is a valid concern or not? I have not read all the documentation, so forgive this post if it's totally ignorant. It has been my assumption that FlaggedRevs would allow us to flag an article, unflag an article, or update a flag on an artical. Ie, an article that has been flagged previously should be able to have that flag removed and the most current revision of the page displayed by default. Is this the case?

--Andrew Whitworth
_________________________________________________________________
More photos; more messages; more whatever – Get MORE with Windows Live™ Hotmail®. NOW with 5GB storage.
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_5G_0907
P. Birken
2007-09-24 16:47:01 UTC
Permalink
Post by Andrew Whitworth
As it is planned, the feature is simply too intrusive. Once an
article is flagged as "sighted", there is no way back.
I have to wonder whether this is a valid concern or not? I have not read all the documentation, so forgive this post if it's totally ignorant. It has been my assumption that FlaggedRevs would allow us to flag an article, unflag an article, or update a flag on an artical. Ie, an article that has been flagged previously should be able to have that flag removed and the most current revision of the page displayed by default. Is this the case?
No, this is indeed a valid concern. A feature that allows to unflag an
article is not included. Unflagging sort of happens by creating a new
version and flagging that one instead. So, once an article has been
flagged, it is "in the system". However, initially no article is
flagged.

Nevertheless, In the limit, when you assume that every article has
been flagged, every edit by non-editors (IPs and recently created
accounts) would have to be flagged or reverted in a reasonable amount
of time. This is the question of scaling. Does a wiki manage this?
Then everything is fine. If not, then either the software will have to
be improved in this aspect (which will be one of the goals of the
Beta) or you shouldn't use this setting of flagged revisions. In
particular young wikis should simply not use it.

As for other settings, there currently is simply the setting to always
show the current version, but still links to sighted or quality
versions. As Erik said, in the future there will also be a
per-page-feature that allows to toggle the default view per page.

Bye,

Philipp
Gregory Maxwell
2007-09-24 17:09:30 UTC
Permalink
On 9/24/07, P. Birken <pbirken-***@public.gmane.org> wrote:
[snip]
Post by P. Birken
Does a wiki manage this?
Then everything is fine. If not, then either the software will have to
be improved in this aspect (which will be one of the goals of the
Beta) or you shouldn't use this setting of flagged revisions. In
particular young wikis should simply not use it.
[snip]

and as I pointed out recently: if the wiki can not manage it that
would mean a great many edits are going completely without review.
That would be a very bad thing for a highly read Wiki (like the
primary language editions of Wikipedia), and arguably an unethical
situation.

If a popular project can't keep up with the reviewing then we need to
solve that problem.

I'm not too worried. If a popular project really couldn't keep up with
reviewing in a timely fashion the projects would be saturated with
vandalism. Flagging should make reviewing more efficient, so we should
have confidence.
P. Birken
2007-09-24 17:46:40 UTC
Permalink
Post by Gregory Maxwell
[snip]
Post by P. Birken
Does a wiki manage this?
Then everything is fine. If not, then either the software will have to
be improved in this aspect (which will be one of the goals of the
Beta) or you shouldn't use this setting of flagged revisions. In
particular young wikis should simply not use it.
[snip]
and as I pointed out recently: if the wiki can not manage it that
would mean a great many edits are going completely without review.
That would be a very bad thing for a highly read Wiki (like the
primary language editions of Wikipedia), and arguably an unethical
situation.
If a popular project can't keep up with the reviewing then we need to
solve that problem.
I'm not too worried. If a popular project really couldn't keep up with
reviewing in a timely fashion the projects would be saturated with
vandalism. Flagging should make reviewing more efficient, so we should
have confidence.
Well, I wholeheartedly agree with you. There's nothing more to say on
that note :-)

Cheers,

Philipp
Bryan Derksen
2007-09-25 00:06:12 UTC
Permalink
Post by Gregory Maxwell
I'm not too worried. If a popular project really couldn't keep up with
reviewing in a timely fashion the projects would be saturated with
vandalism. Flagging should make reviewing more efficient, so we should
have confidence.
What would really be neat is a variant of special:randompage that only
returns pages whose latest revision is unreviewed. I'm sure there'll be
list pages for that sort of thing but jumping around randomly makes
things seem less like "work" to me.
Conrad Nutschan
2007-09-25 06:26:59 UTC
Permalink
Post by Bryan Derksen
What would really be neat is a variant of special:randompage that only
returns pages whose latest revision is unreviewed.
That seems in real, the random funktion has to become a namespace
prefix choosing field?
P. Birken
2007-09-25 06:42:36 UTC
Permalink
Post by Bryan Derksen
What would really be neat is a variant of special:randompage that only
returns pages whose latest revision is unreviewed. I'm sure there'll be
list pages for that sort of thing but jumping around randomly makes
things seem less like "work" to me.
That's right, that sounds neat.

Bye,

Philipp
ulim
2007-09-24 17:07:05 UTC
Permalink
Post by P. Birken
No, this is indeed a valid concern. A feature that allows to unflag an
article is not included. Unflagging sort of happens by creating a new
version and flagging that one instead. So, once an article has been
flagged, it is "in the system". However, initially no article is
flagged.
Leaving aside the sighted flag for a moment, what about the quality version
flag? Suppose it is given erroneously, because someone made a mistake in
checking the sources for the article - this can happen easily. In that case
there should be a way to unflag the article, no?

Ulrich
Chad
2007-09-24 17:23:49 UTC
Permalink
Let's assume for a minute that this feature gets deployed on the projects.
Large projects get it and small ones don't, for the purposes of this
analogy.

Given that vandalism wouldn't appear to the majority of viewers of the site
(anons), wouldn't this therefore mean vandalism in and of itself would go
down? Vandalism is committed (as far as I know) to get the shock value of
having someone read a wrong page. However, on the wikis that do not have
this feature, would it make vandalism go up? Given the vandals would find
out which have it and which don't (an easily obtainable piece of
information), would they potentially take a higher effort on those wikis
that don't have it, since they know it is more likely to not get reviewed?
That being said, we have very few dedicated vandals. The majority of vandals
are drive-bys who (when seeing their vandalism doesn't work on the English
Wikipedia) would give up, I think.

-Chad H.
Post by ulim
Post by P. Birken
No, this is indeed a valid concern. A feature that allows to unflag an
article is not included. Unflagging sort of happens by creating a new
version and flagging that one instead. So, once an article has been
flagged, it is "in the system". However, initially no article is
flagged.
Leaving aside the sighted flag for a moment, what about the quality version
flag? Suppose it is given erroneously, because someone made a mistake in
checking the sources for the article - this can happen easily. In that case
there should be a way to unflag the article, no?
Ulrich
_______________________________________________
Wikiquality-l mailing list
http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
Adam Biswanger
2007-09-24 17:50:15 UTC
Permalink
I'm less concerned with blatant vandalism than sly, subtle mistakes (think John Seigenthaler), and even good-faith errors. I think we've misidentified the problem- we needn't worry about an short-lived, all-caps declaration that so-and-so is such-and-such. Vandalism is a problem, yes, but it isn't the biggest one. We need a more rigorous review system that will address important factual errors (there are plenty of them) and give Wikipedia more scholarly credibility. The concept of quality flagging is a good start, but are there any concrete plans as to how it will work? The only plans I've heard are just ideas. Will an editor be able to issue a quality flag just by giving it a quick review, or will there be thorough, comprehensive process?

Chad <innocentkiller-***@public.gmane.org> wrote: Let's assume for a minute that this feature gets deployed on the projects. Large projects get it and small ones don't, for the purposes of this analogy.

Given that vandalism wouldn't appear to the majority of viewers of the site (anons), wouldn't this therefore mean vandalism in and of itself would go down? Vandalism is committed (as far as I know) to get the shock value of having someone read a wrong page. However, on the wikis that do not have this feature, would it make vandalism go up? Given the vandals would find out which have it and which don't (an easily obtainable piece of information), would they potentially take a higher effort on those wikis that don't have it, since they know it is more likely to not get reviewed? That being said, we have very few dedicated vandals. The majority of vandals are drive-bys who (when seeing their vandalism doesn't work on the English Wikipedia) would give up, I think.

-Chad H.
Post by P. Birken
No, this is indeed a valid concern. A feature that allows to unflag an
article is not included. Unflagging sort of happens by creating a new
version and flagging that one instead. So, once an article has been
flagged, it is "in the system". However, initially no article is
flagged.
Leaving aside the sighted flag for a moment, what about the quality version
flag? Suppose it is given erroneously, because someone made a mistake in
checking the sources for the article - this can happen easily. In that case
there should be a way to unflag the article, no?

Ulrich

_______________________________________________
Wikiquality-l mailing list
Wikiquality-l-RusutVdil2icGmH+5r0DM0B+***@public.gmane.org
http://lists.wikimedia.org/mailman/listinfo/wikiquality-l


_______________________________________________
Wikiquality-l mailing list
Wikiquality-l-RusutVdil2icGmH+5r0DM0B+***@public.gmane.org
http://lists.wikimedia.org/mailman/listinfo/wikiquality-l



---------------------------------
Don't let your dream ride pass you by. Make it a reality with Yahoo! Autos.
Gregory Maxwell
2007-09-24 18:12:32 UTC
Permalink
Post by Adam Biswanger
I'm less concerned with blatant vandalism than sly, subtle mistakes (think
John Seigenthaler), and even good-faith errors. I think we've misidentified
It's a mistake to think that flagging is only expected to help with
obvious vandalism. Right now obvious vandalism is the noise that
often hides more subtle vandalism.

Here is an example: A somewhat subtle vandalism (changing a date)
http://en.wikipedia.org/w/index.php?title=Pioneer_plaque&diff=prev&oldid=14242706

was missed because right after it a more obvious vandalism was made
which was reverted:
http://en.wikipedia.org/w/index.php?title=Pioneer_plaque&diff=next&oldid=14248233

The problem remained for over a year, until I stumbled across it as a
casual reader: http://en.wikipedia.org/w/index.php?title=Pioneer_plaque&diff=71317234&oldid=68432539

(Incidentally I think this would be a good example for the trust
coloring system.. it would be a good argument for it as the date would
have been highlighted in the revisions near the change, and an
argument against it.. since the date would look trusted later on even
though no one ever reviewed the change)

Flagging will give us a 'more trusted' point to diff against, which
will reduce problems like this. Some people, like myself, believe that
it will also reduce the total amount amount of simple vandalism thus
freeing up resources to work on harder cases.

Certainly flagging will not stop malicious parties who are well
informed and dedicated to their cause. It is often considered a bad
idea to reject partial solution because it does not cure all problems.

You may well be right that correcting subtle vandalism is more
important, but that does not preclude improving the situation for more
obvious vandalism.
Adam Biswanger
2007-09-24 18:42:25 UTC
Permalink
Post by Gregory Maxwell
It is often considered a bad
idea to reject partial solution because it does not cure all problems.
You may well be right that correcting subtle vandalism is more
important, but that does not preclude improving the situation for more
obvious vandalism.
I certainly am not objecting to the idea of article flagging, and I certainly haven't rejected the idea because it isn't perfect. I am trying, however, to wander in the direction of article flagging as certification of truth, not certification of good-faith.
Post by Gregory Maxwell
I'm less concerned with blatant vandalism than sly, subtle mistakes (think
John Seigenthaler), and even good-faith errors. I think we've misidentified
It's a mistake to think that flagging is only expected to help with
obvious vandalism. Right now obvious vandalism is the noise that
often hides more subtle vandalism.

Here is an example: A somewhat subtle vandalism (changing a date)
http://en.wikipedia.org/w/index.php?title=Pioneer_plaque&diff=prev&oldid=14242706

was missed because right after it a more obvious vandalism was made
which was reverted:
http://en.wikipedia.org/w/index.php?title=Pioneer_plaque&diff=next&oldid=14248233

The problem remained for over a year, until I stumbled across it as a
casual reader: http://en.wikipedia.org/w/index.php?title=Pioneer_plaque&diff=71317234&oldid=68432539

(Incidentally I think this would be a good example for the trust
coloring system.. it would be a good argument for it as the date would
have been highlighted in the revisions near the change, and an
argument against it.. since the date would look trusted later on even
though no one ever reviewed the change)

Flagging will give us a 'more trusted' point to diff against, which
will reduce problems like this. Some people, like myself, believe that
it will also reduce the total amount amount of simple vandalism thus
freeing up resources to work on harder cases.

Certainly flagging will not stop malicious parties who are well
informed and dedicated to their cause. It is often considered a bad
idea to reject partial solution because it does not cure all problems.

You may well be right that correcting subtle vandalism is more
important, but that does not preclude improving the situation for more
obvious vandalism.

_______________________________________________
Wikiquality-l mailing list
Wikiquality-l-RusutVdil2icGmH+5r0DM0B+***@public.gmane.org
http://lists.wikimedia.org/mailman/listinfo/wikiquality-l



---------------------------------
Luggage? GPS? Comic books?
Check out fitting gifts for grads at Yahoo! Search.
John Erling Blad
2007-09-24 19:03:41 UTC
Permalink
There are several stumbling effects of flagged revs.

The vandalism will have a larger window where it will be observed before
it goes away unnoticed. This is often named probability of detection in
military projects. In the present UI in Wp this is a major problem. The
window is very short and when the vandalism passes out of this window
the chance of detection rapidly drops of to a level given by the reading
frequency of the article. The sighting process will (can) lock the
vandalism in a indefinitely much larger window. This increases the PoD
but will also be the prime reason why people observe that the system
doesn't scale well. That is, the users observe the edits that previously
went away unnoticed.

An other thing closely related to this is an ability to verify several
previous versions in one operation, ie qualifying a new version as
sighted without regard to previous history. This makes the whole process
much more effective then the present method of patrolling. As a
guesstimate this can give a factor of 2-3 times, but limited to how
effective the UI is on conveying the information from the previous edits.

Lastly there are a very odd effect that will emerge if the users that do
patroling/sighting observe the ''unsighted'' versions in a cumulative
way. By marking the versions as sighted they will successive concentrate
on those versions that contains vandalism. This increases the
effectiveness several times, increases the time one unsighted version is
observable and therefore increases PoD.

I believe sighted versions will need fewer patrolers because they will
be more effective, and the result will be articles with less vandalism.
Unfortunatly the system breaks down ungracefully when the patrolers
can't keep up and the vandalism starts to pile up. On the good side the
heap of vandalism can be handled later as long as the heap don't
consistently builds up over some time.

John E
Stephen Bain
2007-09-25 07:28:50 UTC
Permalink
Post by ulim
Leaving aside the sighted flag for a moment, what about the quality version
flag? Suppose it is given erroneously, because someone made a mistake in
checking the sources for the article - this can happen easily. In that case
there should be a way to unflag the article, no?
Yes, I can see this being a problem. It should at least be possible
for a user to change the flags that they themselves have set.
--
Stephen Bain
stephen.bain-***@public.gmane.org
Loading...