All,
The proposed behavior of the flagged revision extension is to show the last reviewed version only to anonymous users. I submit that this is should be default behavior for ALL users (subject to personalization settings override, I guess). The question here is not just of vandalism control, but also of making Wikipedia's content creation process more deliberative. The power to command an article's content by submitting the last edit is an incentive not only for vandalism, but also the sort of uncivil version contention that has long been damaging the community's social fabric. In making the last reviewed version of an article the default view for practically ALL users, we remove the incentive for not just vandalism, but all sorts of unsocial behavior.
I think most of you know more than I do about the dynamics of user contributions to the Wikipedia, but I am seriously worried that showing stable revisions, rather than the most up to date revisions, will change for the worse how the Wikipedia evolves.
For one thing, this would delegate spam fighting almost entirely to a cadre of editors: others, even though they are motivated contributors, would not bother manually checking the latest page for every page they read, and thus, they would not discover whether the latest page is altered. The "good samaritan" phenomenon of people casually landing on a page, and fixing it, would be much reduced.
I fear even the incentive to edit pages would be reduced. People are motivated by instant gratification. Anonymous users, while they contribute a lot of spam, contribute also the majority of the factual, correct, and informative content of the Wikipedia (this is just a matter of statistics; I could easily post statistical data on this). Already now, the experience of an anonymous user contributing to the Wikipedia is not very positive: often, well-intentioned contributors are reverted, rather than helped, because they violate some style or convention or other thing they are not aware of. I fear that if we introduce the extra step, that their contributions will be put in a sandbox, maybe with many alternative versions by different users, and no clear probability that their version will be at some point included, we will provide a major discouragement for all those contributors.
Not all on-line communities are successful. The Wikipedia so far has been wildly successful, and I am worried at the change of something as fundamental as the principle of wikis: always show the last revision, make it easier to undo spam than to do it, and trust that most people are helpful. I am worried that the inflow of contributions, and especially, the variety and background of contributors, will shrink significantly. I am worried that dedicated contributors will continue to contribute, but the casual users, experts of some domain, that so far have contributed a very large proportion of the factual content of the Wikipedia, will withdraw.
Luca
On Oct 8, 2007 6:16 PM, Jonathan Leybovich jleybov@gmail.com wrote:
All,
The proposed behavior of the flagged revision extension is to show the last reviewed version only to anonymous users. I submit that this is should be default behavior for ALL users (subject to personalization settings override, I guess). The question here is not just of vandalism control, but also of making Wikipedia's content creation process more deliberative. The power to command an article's content by submitting the last edit is an incentive not only for vandalism, but also the sort of uncivil version contention that has long been damaging the community's social fabric. In making the last reviewed version of an article the default view for practically ALL users, we remove the incentive for not just vandalism, but all sorts of unsocial behavior.
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
I don't think that is a good idea. It removes much of the editing incentive of getting an account and makes editing more tiresome for those who edit the most (users).
-Aaron Schulz
Date: Mon, 8 Oct 2007 18:16:03 -0700 From: jleybov@gmail.com To: wikiquality-l@lists.wikimedia.org Subject: [Wikiquality-l] default views
All,
The proposed behavior of the flagged revision extension is to show the last reviewed version only to anonymous users. I submit that this is should be default behavior for ALL users (subject to personalization settings override, I guess). The question here is not just of vandalism control, but also of making Wikipedia's content creation process more deliberative. The power to command an article's content by submitting the last edit is an incentive not only for vandalism, but also the sort of uncivil version contention that has long been damaging the community's social fabric. In making the last reviewed version of an article the default view for practically ALL users, we remove the incentive for not just vandalism, but all sorts of unsocial behavior.
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
_________________________________________________________________ Help yourself to FREE treats served up daily at the Messenger Café. Stop by today. http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_OctWL...
Users may do most of the editing in terms of number of edits, but original information (even is misformatted) comes, right now, predominantly from anonymous users. I believe that they will be disincentivated to edit, if their edits won't be reflected immediately, and I think the process that has made the Wikipedia so rich risks an abrupt slowing.
Luca
On Oct 8, 2007 8:33 PM, Aaron Schulz jschulz_4587@msn.com wrote:
I don't think that is a good idea. It removes much of the editing incentive of getting an account and makes editing more tiresome for those who edit the most (users).
-Aaron Schulz
Date: Mon, 8 Oct 2007 18:16:03 -0700 From: jleybov@gmail.com To: wikiquality-l@lists.wikimedia.org Subject: [Wikiquality-l] default views
All,
The proposed behavior of the flagged revision extension is to show the last reviewed version only to anonymous users. I submit that this is should be default behavior for ALL users (subject to personalization settings override, I guess). The question here is not just of vandalism control, but also of making Wikipedia's content creation process more deliberative. The power to command an article's content by submitting the last edit is an incentive not only for vandalism, but also the sort of uncivil version contention that has long been damaging the community's social fabric. In making the last reviewed version of an article the default view for practically ALL users, we remove the incentive for not just vandalism, but all sorts of unsocial behavior.
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
Help yourself to FREE treats served up daily at the Messenger Café. Stop by today!http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_OctWLtagline
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
On 10/9/07, Luca de Alfaro luca@soe.ucsc.edu wrote:
Users may do most of the editing in terms of number of edits, but original information (even is misformatted) comes, right now, predominantly from anonymous users.
I'd love to see a solid citation for that. I'm not disputing it but I've seen the claim a lot and I'd love to be able to talk about that matter in a more nuanced way than "less"/"more". For example, how does the ratio differ for niche articles compared to more "core subjects"?
I believe that they will be disincentivated to edit, if their edits won't be reflected immediately, and I think the process that has made the Wikipedia so rich risks an abrupt slowing.
I agree that this might be a possible outcome.
Why are people opposed to changing the software so that after an anon edits he sees the most recent version of the article for the rest of his browsing session?
I expect that for the vast majority of users that behavior would have almost all the beneficial effects of the current instant-gratification behavior, but without the negative impact to quality.
So long as the flag pushing tends to be faster than browser sessions are long this would behave the same for the users as if their version were approved right away.
I would hope that version flag pushing should be roughly as fast as vandalism reversion, i.e. much faster than browsing session lifetimes. But I only expect this to be true if the flagged version is the default view, thus creating some urgency for flag pushing.
If flag pushing were somewhat too slow we could use longer lived cookies, but there are performance implications (and workarounds) to consider there.
On 10/8/07, Aaron Schulz jschulz_4587@msn.com wrote:
I don't think that is a good idea. It removes much of the editing incentive of getting an account and makes editing more tiresome for those who edit the most (users).
I don't agree.
I think that instead we should improve the interface and operation so that it's not tiring for *anyone*. If there is a problem editing from the flagged version then it should be fixed, not just left to only impact people who will complain less.
One thing I've seen suggested is making anons always see the most recent revision on articles they have recently edited (a session length cookie could be used for tracking that). That idea could be extended to logged in users and also be applied to pages which the user has watchlisted. There should be no performance impact from these because editing sets a session cookie already, and page loads for logged in users already check watchlist status.
Doing this would do a lot to unify the view of Wikipedia for both logged in logged out users even when there was widespread use of flagging.
luca@soe.ucsc.edu wrote:
I think most of you know more than I do about the dynamics of user contributions to the Wikipedia, but I am seriously worried that showing stable revisions
I too am worried: I am worried that people with long term histories of categorical opposition to anything like stable versions might be playing too much of a role in our implementation choices and we may end up with a compromise system which combines all of the harms every proposal and none of the charms.
We had a prior system for revision quality markup, "mark as patrolled". The feature was considered a failure by many of our larger communities. Many people, myself included, believe it failed because marking a revision didn't accomplish anything useful so there was little incentive for anyone do anything with it.
If we do not use the ability to show the flagged version by default, I fear that the revision flagging will be little more than marked as patrolled and as much of a failure.
But at the end we don't need to worry about the worries: Instead we can simply use objective measurements. If we turn on users defaulting to the flagged revisions on ten thousand well distributed articles, we can then track the performance. We can measure the amount of editing before and after, we can automagically or manually measure the amount of vandalism, we can see how often readers are seeing a stale versions and how stale.
There is no reason to be afraid, we can use data to illuminate the dark.
The aggressive debating over the supposed risks of this feature are counter productive. None of us know what will happen because this is new ground. All any of us can do is guess. It would be really arrogant of us to think that we'll have it right at the first cut.
What we should be discussing is not how stable versions should be done but rather we should be discussing how to *study* stable versions.
My preference for a more aggressive implementation comes not because I think I have some magic understanding that proves everyone's worries wrong, instead it comes from two factors. (1) A more substantial change should produce results which are easier to measure. (2) I view the more aggressive implementation is closer to the ideal from the quality perspective and since we are trying to improve quality we should probably start testing from the ideal and back off until we remove the negative side effects.
So, how can we best study the results?
On 10/9/07, Gregory Maxwell gmaxwell@gmail.com wrote:
One thing I've seen suggested is making anons always see the most recent revision on articles they have recently edited (a session length cookie could be used for tracking that).
Usability wise that seems tricky. Imagine making an edit, then passing the link on, only to find that both viewers see different things. Also, one benefit of having a different default view is to disincentivize vandalism -- if the user mistakenly _believes_ their edit has taken effect, vandalism is not disincentivized.
Perhaps it is solvable with reasonably clear UI messages. But I'm not sure a simple "Your edit has been submitted and will be shown to all readers pending review" message isn't sufficient.
But at the end we don't need to worry about the worries: Instead we can simply use objective measurements. If we turn on users defaulting to the flagged revisions on ten thousand well distributed articles, we can then track the performance.
It would probably be least controversial to immediately do it on all articles that are currently semi-protected. Can you quickly get the number of those?
It would be slightly more controversial to do on the featured & good articles.
On 10/9/07, Erik Moeller erik@wikimedia.org wrote:
Usability wise that seems tricky. Imagine making an edit, then passing the link on, only to find that both viewers see different things.
That can mostly be resolved by sending the user to a static revision url after saving, I suppose.
Since the pages can be changed users will either need to have some awareness of the process or they will be confused. For example, their change could be reverted or the purge could be missed causing their anonymous browsing / cookieless friend to view a slightly stale page.
I just think it's better to make the possibly confusing cases as infrequent as possible.
Also, one benefit of having a different default view is to disincentivize vandalism -- if the user mistakenly _believes_ their edit has taken effect, vandalism is not disincentivized.
I'm not sure we understand the mechenism of vandalism well enough to know without measement. Certantly expirenced/repeat/frequent vandals will observe the futility, but I don't think we know what proportion of vandals fit that profile.
Perhaps it is solvable with reasonably clear UI messages. But I'm not sure a simple "Your edit has been submitted and will be shown to all readers pending review" message isn't sufficient.
I think it might be, but really we're just guessing.
But at the end we don't need to worry about the worries: Instead we can simply use objective measurements. If we turn on users defaulting to the flagged revisions on ten thousand well distributed articles, we can then track the performance.
It would probably be least controversial to immediately do it on all articles that are currently semi-protected. Can you quickly get the number of those?
I agree that semied pages are probably uncontroversial.
But they are not as useful for some sorts of measurments because we won't be able to measure how much default sighted slows editing. There also aren't very many of them.
Protection settings according to toolserver (enwp data is two weeks old):
project page restrictions number of NS0 non-redirect pages | enwiki | | 2026122 | | enwiki | move=:edit= | 999 | | enwiki | edit=autoconfirmed:move=autoconfirmed | 196 | | enwiki | move=sysop | 97 | | enwiki | edit=autoconfirmed:move=sysop | 17 | | enwiki | edit=sysop:move=sysop | 6 | | enwiki | move=autoconfirmed | 5 |
| dewiki | | 658385 | | dewiki | edit=autoconfirmed:move=autoconfirmed | 1937 | | dewiki | move=:edit= | 607 | | dewiki | move=sysop | 75 | | dewiki | edit=sysop:move=sysop | 13 | | dewiki | edit=autoconfirmed:move=sysop | 10 | | dewiki | move=autoconfirmed | 4 | | dewiki | move=sysop:edit=sysop | 2 |
It would be slightly more controversial to do on the featured & good articles.
In addition to any large classes, I think it would be useful to also apply it to some number of pages quasi-randomly selected. Probably something around 10000 pages would make sense. We could set a study end date and undo the setting at that point and also gather data on page activity after the change is removed.
On 09/10/2007, Gregory Maxwell gmaxwell@gmail.com wrote:
In addition to any large classes, I think it would be useful to also apply it to some number of pages quasi-randomly selected. Probably something around 10000 pages would make sense. We could set a study end date and undo the setting at that point and also gather data on page activity after the change is removed.
10000 isn't enough to prevent one determined person messing with the results.
I may be able to use a similar hook call like a function in flaggedrevs now to make it so that when a user edits a page where the stable is the default, it redirects them to the page with the stable=0 url, so that they can see their edits, rather than the stable version.
-Aaron Schulz
Date: Tue, 9 Oct 2007 12:37:46 -0400 From: gmaxwell@gmail.com To: wikiquality-l@lists.wikimedia.org Subject: Re: [Wikiquality-l] default views
On 10/9/07, Erik Moeller erik@wikimedia.org wrote:
Usability wise that seems tricky. Imagine making an edit, then passing the link on, only to find that both viewers see different things.
That can mostly be resolved by sending the user to a static revision url after saving, I suppose.
Since the pages can be changed users will either need to have some awareness of the process or they will be confused. For example, their change could be reverted or the purge could be missed causing their anonymous browsing / cookieless friend to view a slightly stale page.
I just think it's better to make the possibly confusing cases as infrequent as possible.
Also, one benefit of having a different default view is to disincentivize vandalism -- if the user mistakenly _believes_ their edit has taken effect, vandalism is not disincentivized.
I'm not sure we understand the mechenism of vandalism well enough to know without measement. Certantly expirenced/repeat/frequent vandals will observe the futility, but I don't think we know what proportion of vandals fit that profile.
Perhaps it is solvable with reasonably clear UI messages. But I'm not sure a simple "Your edit has been submitted and will be shown to all readers pending review" message isn't sufficient.
I think it might be, but really we're just guessing.
But at the end we don't need to worry about the worries: Instead we can simply use objective measurements. If we turn on users defaulting to the flagged revisions on ten thousand well distributed articles, we can then track the performance.
It would probably be least controversial to immediately do it on all articles that are currently semi-protected. Can you quickly get the number of those?
I agree that semied pages are probably uncontroversial.
But they are not as useful for some sorts of measurments because we won't be able to measure how much default sighted slows editing. There also aren't very many of them.
Protection settings according to toolserver (enwp data is two weeks old):
project page restrictions number of NS0 non-redirect pages | enwiki | | 2026122 | | enwiki | move=:edit= | 999 | | enwiki | edit=autoconfirmed:move=autoconfirmed | 196 | | enwiki | move=sysop | 97 | | enwiki | edit=autoconfirmed:move=sysop | 17 | | enwiki | edit=sysop:move=sysop | 6 | | enwiki | move=autoconfirmed | 5 |
| dewiki | | 658385 | | dewiki | edit=autoconfirmed:move=autoconfirmed | 1937 | | dewiki | move=:edit= | 607 | | dewiki | move=sysop | 75 | | dewiki | edit=sysop:move=sysop | 13 | | dewiki | edit=autoconfirmed:move=sysop | 10 | | dewiki | move=autoconfirmed | 4 | | dewiki | move=sysop:edit=sysop | 2 |
It would be slightly more controversial to do on the featured & good articles.
In addition to any large classes, I think it would be useful to also apply it to some number of pages quasi-randomly selected. Probably something around 10000 pages would make sense. We could set a study end date and undo the setting at that point and also gather data on page activity after the change is removed.
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
_________________________________________________________________ Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare! http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailn...
Aaron Schulz wrote:
I may be able to use a similar hook call like a function in flaggedrevs now to make it so that when a user edits a page where the stable is the default, it redirects them to the page with the stable=0 url, so that they can see their edits, rather than the stable version.
Yes, it seems fairly important that when an anon "edit draft"'s a page which has Default:Stable that after Submit he is directed to the current version (which he just created). This is (1) less confusing since he expects to see the change he just made, (2) useful since he may look over what he did and see it needs expansion or correction.
A good suggestion. I don't see how anons would have much incentive to edit usefully otherwise.
On 10/9/07, R. S. Shaw shaww@inbox.com wrote:
Aaron Schulz wrote:
I may be able to use a similar hook call like a function in flaggedrevs now to make it so that when a user edits a page where the stable is the default, it redirects them to the page with the stable=0 url, so that they can see their edits, rather than the stable version.
Yes, it seems fairly important that when an anon "edit draft"'s a page which has Default:Stable that after Submit he is directed to the current version (which he just created). This is (1) less confusing since he expects to see the change he just made, (2) useful since he may look over what he did and see it needs expansion or correction.
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
I also heartily support this. In particular inexperienced users often need several edits to make their intended contribution. If the software factually prevents them doing so, then we are raising the bar too high. And I also think that this ranks higher than a possible disincentive to vandals.
Bye,
Philipp
2007/10/10, David Goodman dgoodmanny@gmail.com:
A good suggestion. I don't see how anons would have much incentive to edit usefully otherwise.
On 10/9/07, R. S. Shaw shaww@inbox.com wrote:
Aaron Schulz wrote:
I may be able to use a similar hook call like a function in flaggedrevs now to make it so that when a user edits a page where the stable is the default, it redirects them to the page with the stable=0 url, so that they can see their edits, rather than the stable version.
Yes, it seems fairly important that when an anon "edit draft"'s a page which has Default:Stable that after Submit he is directed to the current version (which he just created). This is (1) less confusing since he expects to see the change he just made, (2) useful since he may look over what he did and see it needs expansion or correction.
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
-- David Goodman, Ph.D, M.L.S.
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
wikiquality-l@lists.wikimedia.org