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! Try now!