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