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.
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@wikimedia.org Reply-To: Wikimedia Quality Discussions wikiquality-l@lists.wikimedia.org To: "Wikimedia Quality Discussions" wikiquality-l@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@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
2007/8/14, Aaron Schulz jschulz_4587@msn.com:
- 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
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
From: "P. Birken" pbirken@gmail.com Reply-To: Wikimedia Quality Discussions wikiquality-l@lists.wikimedia.org To: "Wikimedia Quality Discussions" wikiquality-l@lists.wikimedia.org Subject: Re: [Wikiquality-l] Issues with FlaggedRevs Date: Tue, 14 Aug 2007 10:54:19 +0200
2007/8/14, Aaron Schulz jschulz_4587@msn.com:
- 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
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org 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
2007/8/14, Aaron Schulz jschulz_4587@msn.com:
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
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
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
From: "P. Birken" pbirken@gmail.com Reply-To: Wikimedia Quality Discussions wikiquality-l@lists.wikimedia.org To: "Wikimedia Quality Discussions" wikiquality-l@lists.wikimedia.org 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 Wikiquality-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
_________________________________________________________________ More photos, more messages, more storageget 2GB with Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migr...
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
From: "P. Birken" pbirken@gmail.com Reply-To: Wikimedia Quality Discussions wikiquality-l@lists.wikimedia.org To: "Wikimedia Quality Discussions" wikiquality-l@lists.wikimedia.org Subject: Re: [Wikiquality-l] Issues with FlaggedRevs Date: Wed, 15 Aug 2007 12:46:43 +0200
2007/8/14, Aaron Schulz jschulz_4587@msn.com:
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@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
2007/8/15, Aaron Schulz jschulz_4587@msn.com:
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
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
From: "P. Birken" pbirken@gmail.com Reply-To: Wikimedia Quality Discussions wikiquality-l@lists.wikimedia.org To: "Wikimedia Quality Discussions" wikiquality-l@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@msn.com:
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@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
2007/8/16, Aaron Schulz jschulz_4587@msn.com:
- 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.
- 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
From: "P. Birken" pbirken@gmail.com Reply-To: Wikimedia Quality Discussions wikiquality-l@lists.wikimedia.org To: "Wikimedia Quality Discussions" wikiquality-l@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@msn.com:
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@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
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
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
From: "P. Birken" pbirken@gmail.com Reply-To: Wikimedia Quality Discussions wikiquality-l@lists.wikimedia.org To: "Wikimedia Quality Discussions" wikiquality-l@lists.wikimedia.org Subject: Re: [Wikiquality-l] Issues with FlaggedRevs Date: Thu, 16 Aug 2007 09:01:20 +0200
2007/8/16, Aaron Schulz jschulz_4587@msn.com:
- 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.
- 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
From: "P. Birken" pbirken@gmail.com Reply-To: Wikimedia Quality Discussions
wikiquality-l@lists.wikimedia.org
To: "Wikimedia Quality Discussions" wikiquality-l@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@msn.com:
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@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
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
Wikiquality-l mailing list Wikiquality-l@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
2007/8/16, Aaron Schulz jschulz_4587@msn.com:
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
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
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@gmail.com Reply-To: Wikimedia Quality Discussions wikiquality-l@lists.wikimedia.org To: "Wikimedia Quality Discussions" wikiquality-l@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@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
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@msn.com:
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@gmail.com Reply-To: Wikimedia Quality Discussions wikiquality-l@lists.wikimedia.org To: "Wikimedia Quality Discussions" wikiquality-l@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@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
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
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
From: "P. Birken" pbirken@gmail.com Reply-To: Wikimedia Quality Discussions wikiquality-l@lists.wikimedia.org To: "Wikimedia Quality Discussions" wikiquality-l@lists.wikimedia.org 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
2007/9/3, Aaron Schulz jschulz_4587@msn.com:
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@gmail.com Reply-To: Wikimedia Quality Discussions
wikiquality-l@lists.wikimedia.org
To: "Wikimedia Quality Discussions" wikiquality-l@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@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
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
Wikiquality-l mailing list Wikiquality-l@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
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@msn.com:
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
From: "P. Birken" pbirken@gmail.com Reply-To: Wikimedia Quality Discussions wikiquality-l@lists.wikimedia.org To: "Wikimedia Quality Discussions" wikiquality-l@lists.wikimedia.org 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
2007/9/3, Aaron Schulz jschulz_4587@msn.com:
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@gmail.com Reply-To: Wikimedia Quality Discussions
wikiquality-l@lists.wikimedia.org
To: "Wikimedia Quality Discussions" wikiquality-l@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@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
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
Wikiquality-l mailing list Wikiquality-l@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@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
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
From: "P. Birken" pbirken@gmail.com Reply-To: Wikimedia Quality Discussions wikiquality-l@lists.wikimedia.org To: "Wikimedia Quality Discussions" wikiquality-l@lists.wikimedia.org 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_SeptHM...
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@msn.com:
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
From: "P. Birken" pbirken@gmail.com Reply-To: Wikimedia Quality Discussions wikiquality-l@lists.wikimedia.org To: "Wikimedia Quality Discussions" wikiquality-l@lists.wikimedia.org 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_SeptHM...
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
wikiquality-l@lists.wikimedia.org