Issues with FlaggedRevs

[Erik Moeller]

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.

[Aaron Schulz]

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

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
* 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.
* 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.
--
Erik
DISCLAIMER: This message does not represent an official position of
the Wikimedia Foundation or its Board of Trustees.
_______________________________________________
Wikiquality-l mailing list
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]

Post by Aaron Schulz
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]

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

Subject: Re: [Wikiquality-l] Issues with FlaggedRevs
Date: Tue, 14 Aug 2007 10:54:19 +0200

Post by Aaron Schulz
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

Post by Aaron Schulz
editing, since when you edit a page, it refreshes back to the page,

which

Post by Aaron Schulz
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

Post by Aaron Schulz
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
_______________________________________________
Wikiquality-l mailing list
http://lists.wikimedia.org/mailman/listinfo/wikiquality-l

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

[P. Birken]

Post by 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

[P. Birken]

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]

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

Subject: Re: [Wikiquality-l] Issues with FlaggedRevs
Date: Wed, 15 Aug 2007 15:27:50 +0200
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
_______________________________________________
Wikiquality-l mailing list
http://lists.wikimedia.org/mailman/listinfo/wikiquality-l

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

[Aaron Schulz]

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

Subject: Re: [Wikiquality-l] Issues with FlaggedRevs
Date: Wed, 15 Aug 2007 12:46:43 +0200

Post by Aaron Schulz
Certainly, MW could try to carry over all the previous template/image

IDs

Post by Aaron Schulz
specified from the last stable revision and then re-use those to mark

the

Post by Aaron Schulz
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
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]

Post by 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

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

As for 1), some of the same problems apply as well.


-Aaron Schulz

Subject: Re: [Wikiquality-l] Issues with FlaggedRevs
Date: Wed, 15 Aug 2007 23:54:32 +0200

Post by 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,

Post by Aaron Schulz
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
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]

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

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.

Post by Aaron Schulz
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

Post by Aaron Schulz

Subject: Re: [Wikiquality-l] Issues with FlaggedRevs
Date: Wed, 15 Aug 2007 23:54:32 +0200

Post by 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,

Post by Aaron Schulz
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
http://lists.wikimedia.org/mailman/listinfo/wikiquality-l

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

[Aaron Schulz]

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

Subject: Re: [Wikiquality-l] Issues with FlaggedRevs
Date: Thu, 16 Aug 2007 09:01:20 +0200

Post by 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

Post by Aaron Schulz
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.

Post by Aaron Schulz
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.

Post by Aaron Schulz
Then, diffs are not needed for reviewing." Are you referring to a

trusted

Post by Aaron Schulz
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

Post by Aaron Schulz
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

Post by Aaron Schulz

Reply-To: Wikimedia Quality Discussions
Subject: Re: [Wikiquality-l] Issues with FlaggedRevs
Date: Wed, 15 Aug 2007 23:54:32 +0200

Post by Aaron Schulz
What you cannot do is just have a diff shown on edit and have it

review

Post by Aaron Schulz

Post by Aaron Schulz
*and* save at the same time. As long is the review is done after the

save,

Post by Aaron Schulz
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
http://lists.wikimedia.org/mailman/listinfo/wikiquality-l

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

_______________________________________________
Wikiquality-l mailing list
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]

Post by Aaron Schulz
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.

Post by Aaron Schulz
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.
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]

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]

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

Subject: Re: [Wikiquality-l] Issues with FlaggedRevs
Date: Sun, 2 Sep 2007 18:32:58 +0200
Hiho,
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
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]

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

Post by 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

Subject: Re: [Wikiquality-l] Issues with FlaggedRevs
Date: Sun, 2 Sep 2007 18:32:58 +0200
Hiho,
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
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
_______________________________________________
Wikiquality-l mailing list
http://lists.wikimedia.org/mailman/listinfo/wikiquality-l

[Aaron Schulz]

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

Subject: Re: [Wikiquality-l] Issues with FlaggedRevs
Date: Mon, 3 Sep 2007 21:20:46 +0200
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

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

could

Post by Aaron Schulz
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

Reply-To: Wikimedia Quality Discussions
Subject: Re: [Wikiquality-l] Issues with FlaggedRevs
Date: Sun, 2 Sep 2007 18:32:58 +0200
Hiho,
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
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
_______________________________________________
Wikiquality-l mailing list
http://lists.wikimedia.org/mailman/listinfo/wikiquality-l

_______________________________________________
Wikiquality-l mailing list
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

[P. Birken]

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

Post by Aaron Schulz
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

Subject: Re: [Wikiquality-l] Issues with FlaggedRevs
Date: Mon, 3 Sep 2007 21:20:46 +0200
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

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

could

Post by Aaron Schulz
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

Reply-To: Wikimedia Quality Discussions
Subject: Re: [Wikiquality-l] Issues with FlaggedRevs
Date: Sun, 2 Sep 2007 18:32:58 +0200
Hiho,
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
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
_______________________________________________
Wikiquality-l mailing list
http://lists.wikimedia.org/mailman/listinfo/wikiquality-l

_______________________________________________
Wikiquality-l mailing list
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
http://lists.wikimedia.org/mailman/listinfo/wikiquality-l

[Aaron Schulz]

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

Subject: Re: [Wikiquality-l] Issues with FlaggedRevs
Date: Tue, 4 Sep 2007 14:54:48 +0200
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

_________________________________________________________________
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_SeptHMtagline2

[P. Birken]

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

Post by Aaron Schulz
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

Subject: Re: [Wikiquality-l] Issues with FlaggedRevs
Date: Tue, 4 Sep 2007 14:54:48 +0200
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

_________________________________________________________________
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_SeptHMtagline2
_______________________________________________
Wikiquality-l mailing list
http://lists.wikimedia.org/mailman/listinfo/wikiquality-l