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(a)gmail.com
To: wikiquality-l(a)lists.wikimedia.org
Subject: Re: [Wikiquality-l] default views
On 10/9/07, Erik Moeller <erik(a)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(a)lists.wikimedia.org
http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
_________________________________________________________________
Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare!