Issues with FlaggedRevs

List overview All Threads
Download

newer

older

Re: [Wikiquality-l] stable...

Betatest soon

Erik Moeller

13 Aug 2007 13 Aug '07

5:01 p.m.

I'm trying out FlaggedRevs to see how far we are from deployment. I'm seeing the following issues right now (local install, default configuration): * Diffs that are not to the current revision point to the wrong version. (i.e. the review panel at the bottom will tag the current revision, even if neither of the two revs are current). * Edits by users who can review should not need to be reviewed at least at the basic level; is there any way to configure this? It seems pointless to flag edits by trusted users as being in need for vandalism review. * When the last sighted version and the current version are identical, anon users (if so configured) still have to click through to the "current" (identical) version to edit. This seems an unnecessary hoop to jump through. These seem like core issues to me. In addition, some wishlist items: * In the original specs we suggested that users can approve unreviewed changes with a collapsible diff + checkbox on the actual edit page when editing an unreviewed version; this still seems like a very simple way to integrate review into normal editing workflow. * Switching the default view for all non-registered visitors would be a very radical thing to do when we haven't figured out yet how scalable the system is. Changes might end up being unreviewed for weeks as a result, rendering articles about current events unusable and making it much harder for new users to discover the site. It seems more sensible to change the default view on a per-page basis for some highly problematic pages which are currently semi-protected, and to gradually increase the number of pages that are in this mode. I'll try to come up with some more feedback regarding the UI. -- Toward Peace, Love & Progress: Erik DISCLAIMER: This message does not represent an official position of the Wikimedia Foundation or its Board of Trustees.

Show replies by date

Aaron Schulz

14 Aug 14 Aug

10:01 a.m.

1) Diff error should be fixed now. 2) This is complicated. You cannot review revision without knowing the templates/images used in it, which even with the page in edit mode and a diff is not enough. Just parsing it and pulling it from there can review vandalism to templates/images. Doesn't seem that bad to have to review after editing, since when you edit a page, it refreshes back to the page, which has the tag and diff link to the last reviewed version. This is for the default UI...indeed the other one is more annoying about this. Perhaps the simply UI should be for anons only? 3) Again, the main UI is easier for this. It has the "editable" link in the tag that goes to the page in edit mode. It's hard to fit that into the simple UI. On top of that, it would be confusing, as some reviewed pages would be directly editable and some wouldn't (we already have protection to confuse people to), they may not get the "if it's the top version" rule. Optional stuff: 1) See 2) above, same reasons apply. 2) This might be useful, but it's getting kind of complicated and more confusing to new users. It complicates the "override with latest, best, stable revision" rule. Maybe something to think about later. -Aaron Schulz

...

From: "Erik Moeller" <erik(a)wikimedia.org> Reply-To: Wikimedia Quality Discussions <wikiquality-l(a)lists.wikimedia.org> To: "Wikimedia Quality Discussions" <wikiquality-l(a)lists.wikimedia.org> Subject: [Wikiquality-l] Issues with FlaggedRevs Date: Mon, 13 Aug 2007 17:01:35 +0200 I'm trying out FlaggedRevs to see how far we are from deployment. I'm seeing the following issues right now (local install, default configuration): * Diffs that are not to the current revision point to the wrong version. (i.e. the review panel at the bottom will tag the current revision, even if neither of the two revs are current). * Edits by users who can review should not need to be reviewed at least at the basic level; is there any way to configure this? It seems pointless to flag edits by trusted users as being in need for vandalism review. * When the last sighted version and the current version are identical, anon users (if so configured) still have to click through to the "current" (identical) version to edit. This seems an unnecessary hoop to jump through. These seem like core issues to me. In addition, some wishlist items: * In the original specs we suggested that users can approve unreviewed changes with a collapsible diff + checkbox on the actual edit page when editing an unreviewed version; this still seems like a very simple way to integrate review into normal editing workflow. * Switching the default view for all non-registered visitors would be a very radical thing to do when we haven't figured out yet how scalable the system is. Changes might end up being unreviewed for weeks as a result, rendering articles about current events unusable and making it much harder for new users to discover the site. It seems more sensible to change the default view on a per-page basis for some highly problematic pages which are currently semi-protected, and to gradually increase the number of pages that are in this mode. I'll try to come up with some more feedback regarding the UI. -- Toward Peace, Love & Progress: Erik DISCLAIMER: This message does not represent an official position of the Wikimedia Foundation or its Board of Trustees. _______________________________________________ Wikiquality-l mailing list Wikiquality-l(a)lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l

_________________________________________________________________ Messenger Café open for fun 24/7. Hot games, cool activities served daily. Visit now. http://cafemessenger.com?ocid=TXT_TAGHM_AugHMtagline

P. Birken

10:54 a.m.

2007/8/14, Aaron Schulz <jschulz_4587(a)msn.com>om>:

...

2) This is complicated. You cannot review revision without knowing the templates/images used in it, which even with the page in edit mode and a diff is not enough. Just parsing it and pulling it from there can review vandalism to templates/images. Doesn't seem that bad to have to review after editing, since when you edit a page, it refreshes back to the page, which has the tag and diff link to the last reviewed version. This is for the default UI...indeed the other one is more annoying about this. Perhaps the simply UI should be for anons only?

Mhmh, that doesn't sound good. However, I do not get the technical problem: instead of requiring the user to save the page and then review the change manually, shouldn't it be possible to simply perform a specific review automatically after saving the page? Regarding the templates: the version of templates that is shown when editing is hardwired to the version I review, right? If that is so, then assuming that the editor has looked at the templates and therefore performing the review automatically seems reasonable. Bye, Philipp

Aaron Schulz

9:46 p.m.

Certainly, MW could try to carry over all the previous template/image IDs specified from the last stable revision and then re-use those to mark the new version after editing as stable. This still has two problems: 1) New templates added in the edit would not have a specified ID, same for images 2) Pages would have templates that get continuously out of date as people just review on edit like this. I suppose to avoid those, you could not only show the diff to help them see the changes, but show a preview of the changes. This would require some sort of "force preview" thing, which would make the "preview before edit" user option seem kind of silly. Also, it wouldn't be far off from justing letting people save and then click the diff to review. I don't want people to get too hung up reviewing things on every minor edit they make. Even if a page gets 10 edits/day, it only takes1 person every 1-2 days to keep it up to date (unless it is documenting a current event with much info coming in, in which case more people would be editing, so more would likely review). -Aaron Schulz

...

after

editing, since when you edit a page, it refreshes back to the page,

which

has the tag and diff link to the last reviewed version. This is for the default UI...indeed the other one is more annoying about this. Perhaps

the

simply UI should be for anons only?

_________________________________________________________________ Tease your brain--play Clink! Win cool prizes! http://club.live.com/clink.aspx?icid=clink_hotmailtextlink2

P. Birken

15 Aug 15 Aug

12:46 p.m.

2007/8/14, Aaron Schulz <jschulz_4587(a)msn.com>om>:

...

Certainly, MW could try to carry over all the previous template/image IDs specified from the last stable revision and then re-use those to mark the new version after editing as stable.

P. Birken

3:27 p.m.

I just saw another problem with this: currently, while an edit by a trusted user is not automatically marked as sighted, it is marked as patrolled and thus, other users don't see the exclamation mark to show that this edit has not been reviewed. As an aside: I'm currently getting error messages at http://tools.wikimedia.de/~stable/phase3/ when logged in, namely Warning: Unexpected character in input: ''' (ASCII=39) state=1 in /home/stable/public_html/phase3/languages/messages/MessagesDe.php on line 2319 Parse error: syntax error, unexpected $end, expecting ')' in /home/stable/public_html/phase3/languages/messages/MessagesDe.php on line 2319 In my preferences, the german interface is selected. Bye, Philipp

Aaron Schulz

10:49 p.m.

The issue with them being autopatrolled was fixed in my last commit, which fixed the revision ID bug. I didn't update /stable yet. -Aaron Schulz

...

_________________________________________________________________ More photos, more messages, more storageget 2GB with Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_mig…

Aaron Schulz

10:52 p.m.

OK, yes, you can manually take them to the diff with the parsed version below after editing and ask them to review. That is possible, though just one click off from them clicking on the diff to stable on the tag after they save. What you cannot do is just have a diff shown on edit and have it review *and* save at the same time. As long is the review is done after the save, it's fine. I suppose I can redirect the user right to the diff after saving if that's what you want. Though I may need to add a hook to /trunk. -Aaron Schulz

...

Certainly, MW could try to carry over all the previous template/image

IDs

specified from the last stable revision and then re-use those to mark

the

new version after editing as stable.

I still do not get it. After saving the edit, everything should be there and could be parsed in a subsequent review call and it shouldn't make a difference whether this is an automatic or manual call. Or am I comletely off the track? Bye, Philipp _______________________________________________ Wikiquality-l mailing list Wikiquality-l(a)lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l

P. Birken

11:54 p.m.

2007/8/15, Aaron Schulz <jschulz_4587(a)msn.com>om>:

...

What you cannot do is just have a diff shown on edit and have it review *and* save at the same time. As long is the review is done after the save, it's fine.

Aaron Schulz

16 Aug 16 Aug

12:38 a.m.

1) As for new articles, it only takes one click to review it, and often pages start off pretty rate, so some users may end up wanting to unreview it for a while then. 2) I don't know what you must be referring to by "the creation of new versions by trusted users in the case that the current version is sighted. Then, diffs are not needed for reviewing." Are you referring to a trusted user editing a page that is already sighted? Again, if they add a template/image, you cannot just take the current version of those templates/images and make them part of a sighted revision. If while I was adding an image to a reviewed page, as a reviewer, the image was vandalized, you'd end up with a bad stable version. As for 1), some of the same problems apply as well. -Aaron Schulz

...

What you cannot do is just have a diff shown on edit and have it review *and* save at the same time. As long is the review is done after the

save,

it's fine.

OK, but that's not a problem. The setting Erik and I are talking about are twofold, namely the creation of new articles by trusted users and the creation of new versions by trusted users in the case that the current version is sighted. Then, diffs are not needed for reviewing. Bye, Philipp _______________________________________________ Wikiquality-l mailing list Wikiquality-l(a)lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l

_________________________________________________________________ Learn.Laugh.Share. Reallivemoms is right place! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us

P. Birken

9:01 a.m.

2007/8/16, Aaron Schulz <jschulz_4587(a)msn.com>om>:

...

1) As for new articles, it only takes one click to review it, and often pages start off pretty rate, so some users may end up wanting to unreview it for a while then.

Every unnecessary click is one too many, as it will cause users not to use the system and/or to get annoyed. Usability is very important. As the threshhold for sighted is very low, I don't see a problem with this being done automatically. Having the first version of an article sighted will not protect from RfDs anyhow.

...

2) I don't know what you must be referring to by "the creation of new versions by trusted users in the case that the current version is sighted. Then, diffs are not needed for reviewing." Are you referring to a trusted user editing a page that is already sighted? Again, if they add a template/image, you cannot just take the current version of those templates/images and make them part of a sighted revision. If while I was adding an image to a reviewed page, as a reviewer, the image was vandalized, you'd end up with a bad stable version.

Well, yes, but what's the point. I can either use preview, or if I forgot, I simply create anoother version directly afterwards with the correct template. Having a template vandalized is rare, having users creating new versions happens all the time. Bye, Philipp

...

What you cannot do is just have a diff shown on edit and have it review *and* save at the same time. As long is the review is done after the

save,

it's fine.

_________________________________________________________________ Learn.Laugh.Share. Reallivemoms is right place! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us _______________________________________________ Wikiquality-l mailing list Wikiquality-l(a)lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l

Aaron Schulz

11:45 a.m.

Even if they do use preview, if they are editing just a section, which people often do, they still can't review any of the others. I tried to make this so vandalism only gets in if the user didn't see it and accidentally reviewed it. Introduces automatic mechanism like this becomes more of a calculated risk. That said, I can add a global variable to autoreview changes, such as: a) A new page by a reviewer/trusted user b) An edit to a page where it's current revision is the stable one too As long as template/image vandalism is low and quickly reverted, I suppose it could be worth it. -Aaron Schulz

...

1) As for new articles, it only takes one click to review it, and often pages start off pretty rate, so some users may end up wanting to

unreview it

for a while then.

2) I don't know what you must be referring to by "the creation of new versions by trusted users in the case that the current version is

sighted.

Then, diffs are not needed for reviewing." Are you referring to a

trusted

user editing a page that is already sighted? Again, if they add a template/image, you cannot just take the current version of those templates/images and make them part of a sighted revision. If while I

was

adding an image to a reviewed page, as a reviewer, the image was vandalized, you'd end up with a bad stable version.

>From: "P. Birken" <pbirken(a)gmail.com> >Reply-To: Wikimedia Quality Discussions

<wikiquality-l(a)lists.wikimedia.org>

>To: "Wikimedia Quality Discussions" <wikiquality-l(a)lists.wikimedia.org> >Subject: Re: [Wikiquality-l] Issues with FlaggedRevs >Date: Wed, 15 Aug 2007 23:54:32 +0200 > >2007/8/15, Aaron Schulz <jschulz_4587(a)msn.com>om>: > > What you cannot do is just have a diff shown on edit and have it

review

*and* save at the same time. As long is the review is done after the

save,

it's fine.

_______________________________________________ Wikiquality-l mailing list Wikiquality-l(a)lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l

_________________________________________________________________ Learn.Laugh.Share. Reallivemoms is right place! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us

P. Birken

1:40 p.m.

2007/8/16, Aaron Schulz <jschulz_4587(a)msn.com>om>:

...

Even if they do use preview, if they are editing just a section, which people often do, they still can't review any of the others.

Yes, that's a problem.

...

I tried to make this so vandalism only gets in if the user didn't see it and accidentally reviewed it. Introduces automatic mechanism like this becomes more of a calculated risk. That said, I can add a global variable to autoreview changes, such as: a) A new page by a reviewer/trusted user b) An edit to a page where it's current revision is the stable one too As long as template/image vandalism is low and quickly reverted, I suppose it could be worth it.

Yeah, I'd say the risk is worth taking. However, you got me thinking. What happens, when I change a template? If I understood you right, this won't be visible in current versions, if they are sighted? Bye, Philipp

P. Birken

2 Sep 2 Sep

6:32 p.m.

Hiho, I have one minor and two major points: i) Minor: When browsing through the version history, I think the status of that version should show. ii) Major: Currently, when there is a quality version, this overrides a younger sighted version. This is not as it was planned and since quality versions do not scale, this would lead to readers seeing usually rather outdated versions of articles. I think that the value of quality versions is mostly as a tool of going systematically through our article base and for those who want to reuse our content. It might be, that for example WikiSource or WikiNews might find the current setting useful, but I don't think that this is a good idea for Wikipedia. iii) Major: When the current version is sighted, an IP still does not see the edit button. This is a major restriction for IPs and is factually something like "IPs cannot edit here anymore". While not fundamentally opposed to this, this is a very deep topic and it is in my opinion not this extension that should answer this. Either we do not want IPs to edit, than we should shut them down, but please not via a backdoor from an extension that is about different things. So, please make it so that IPs see an edit button when the current version is sighted. Bye, Philipp

Aaron Schulz

3 Sep 3 Sep

2:14 a.m.

I am not sure the top revision will be sighted most of the time. So we could still see many pages with no 'edit' tab. In the standard UI, editing is conveyed in the message. For the .de one, something is needed to make it clear that you can edit. Maybe a 'draft' tab would help for these cases? -Aaron Schulz

...

From: "P. Birken" <pbirken(a)gmail.com> Reply-To: Wikimedia Quality Discussions <wikiquality-l(a)lists.wikimedia.org> To: "Wikimedia Quality Discussions" <wikiquality-l(a)lists.wikimedia.org> Subject: Re: [Wikiquality-l] Issues with FlaggedRevs Date: Sun, 2 Sep 2007 18:32:58 +0200 Hiho, I have one minor and two major points: i) Minor: When browsing through the version history, I think the status of that version should show. ii) Major: Currently, when there is a quality version, this overrides a younger sighted version. This is not as it was planned and since quality versions do not scale, this would lead to readers seeing usually rather outdated versions of articles. I think that the value of quality versions is mostly as a tool of going systematically through our article base and for those who want to reuse our content. It might be, that for example WikiSource or WikiNews might find the current setting useful, but I don't think that this is a good idea for Wikipedia. iii) Major: When the current version is sighted, an IP still does not see the edit button. This is a major restriction for IPs and is factually something like "IPs cannot edit here anymore". While not fundamentally opposed to this, this is a very deep topic and it is in my opinion not this extension that should answer this. Either we do not want IPs to edit, than we should shut them down, but please not via a backdoor from an extension that is about different things. So, please make it so that IPs see an edit button when the current version is sighted. Bye, Philipp _______________________________________________ Wikiquality-l mailing list Wikiquality-l(a)lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l

_________________________________________________________________ A place for moms to take a break! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us

P. Birken

9:20 p.m.

Yes, it is not clear wether this will scale or not. I am reasonably sure that it will on de, but of course I cannot be certain. But, what's your reason to remove the editbutton, when the current version is the sighted one? Best wishes, Philipp 2007/9/3, Aaron Schulz <jschulz_4587(a)msn.com>om>:

...

_________________________________________________________________ A place for moms to take a break! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us _______________________________________________ Wikiquality-l mailing list Wikiquality-l(a)lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l

Aaron Schulz

4 Sep 4 Sep

2:12 a.m.

I'm just worried it will be inconsistent and confusing. Some pages will have an edit tab and some won't, when both are editable. Some people may assume they can't edit pages that don't have an edit tab then. Not to mention it's not really correct to say one 'edits' the stable version, and the templates/images can be quite different then what they were supposedly editing. Having a tab like 'draft (editable)' or something for the short UI might be better. It would consistently convey that users can edit, and even if the stable version is a few revs behind. Sighted versions should scale, but there may be some small edits/spelling corrections/tweaks that are pending review, even if it's just 1-3 edits. -Aaron Schulz

...

I am not sure the top revision will be sighted most of the time. So we

could

still see many pages with no 'edit' tab. In the standard UI, editing is conveyed in the message. For the .de one, something is needed to make it clear that you can edit. Maybe a 'draft' tab would help for these cases? -Aaron Schulz >From: "P. Birken" <pbirken(a)gmail.com> >Reply-To: Wikimedia Quality Discussions

<wikiquality-l(a)lists.wikimedia.org>

To: "Wikimedia Quality Discussions" <wikiquality-l(a)lists.wikimedia.org> Subject: Re: [Wikiquality-l] Issues with FlaggedRevs Date: Sun, 2 Sep 2007 18:32:58 +0200 Hiho, I have one minor and two major points: i) Minor: When browsing through the version history, I think the status of that version should show. ii) Major: Currently, when there is a quality version, this overrides a younger sighted version. This is not as it was planned and since quality versions do not scale, this would lead to readers seeing usually rather outdated versions of articles. I think that the value of quality versions is mostly as a tool of going systematically through our article base and for those who want to reuse our content. It might be, that for example WikiSource or WikiNews might find the current setting useful, but I don't think that this is a good idea for Wikipedia. iii) Major: When the current version is sighted, an IP still does not see the edit button. This is a major restriction for IPs and is factually something like "IPs cannot edit here anymore". While not fundamentally opposed to this, this is a very deep topic and it is in my opinion not this extension that should answer this. Either we do not want IPs to edit, than we should shut them down, but please not via a backdoor from an extension that is about different things. So, please make it so that IPs see an edit button when the current version is sighted. Bye, Philipp _______________________________________________ Wikiquality-l mailing list Wikiquality-l(a)lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l

_______________________________________________ Wikiquality-l mailing list Wikiquality-l(a)lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l

P. Birken

2:54 p.m.

Aw man, templates suck! After some more surfing, I can only say that the current situation is already confusing enough. For example, when an IP does not see an edit button, but clicks on "History", the edit-button appears. Mh. Somehow, Arnomanes idea of an editbutton that behaves situation dependend becomes more appealing, as dows the main GUI. I'lll think some more on this. I found one more minor point that could improve usability: in the Reviewing Box, the review button could be moved to the right of the selector menus. The point is, that in the case that there is only one dimension of flags, this makes the box much more compact (the button would be where "Depth" is now). And I think most wikis will use this setting. Best wishes, Philipp 2007/9/4, Aaron Schulz <jschulz_4587(a)msn.com>om>:

...

I am not sure the top revision will be sighted most of the time. So we

could

<wikiquality-l(a)lists.wikimedia.org>

_______________________________________________ Wikiquality-l mailing list Wikiquality-l(a)lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l

_________________________________________________________________ Test your celebrity IQ. Play Red Carpet Reveal and earn great prizes! http://club.live.com/red_carpet_reveal.aspx?icid=redcarpet_hotmailtextlink2 _______________________________________________ Wikiquality-l mailing list Wikiquality-l(a)lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l

Aaron Schulz

6:34 p.m.

Yeah, the edit tab on history pages can be a bit confusing. I've been playing around with tab schemes now. See http://amidaniel.com/testwiki/index.php/Sun -Aaron Schulz

...

P. Birken

9:52 p.m.

Yes, that looks better. I think the best option would be if there would be a draft link that disappears after clicking and instead, the edit button would appear. Most people would notice that. Or even better, if "draft" would turn into "edit" (or "edit draft") in line with our older discussion of keeping the number of tabs minimal? Bye, Philipp 2007/9/4, Aaron Schulz <jschulz_4587(a)msn.com>om>:

...

Yeah, the edit tab on history pages can be a bit confusing. I've been playing around with tab schemes now. See http://amidaniel.com/testwiki/index.php/Sun -Aaron Schulz

_________________________________________________________________ Discover sweet stuff waiting for you at the Messenger Cafe. Claim your treat today! http://www.cafemessenger.com/info/info_sweetstuff.html?ocid=TXT_TAGHM_SeptH… _______________________________________________ Wikiquality-l mailing list Wikiquality-l(a)lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l

6078

days inactive

6100

days old

wikiquality-l@lists.wikimedia.org

Manage subscription

19 comments

3 participants

tags (0)

participants (3)

Aaron Schulz
Erik Moeller
P. Birken