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