P. Birken wrote:
> ... However, I think some more visibility of this stuff would
> be useful. A nice compromise could be to include all flaggings and
> removal of flags of higher level than sighted into the history and the
> recent changes. What do you think?
>
It seems to me this is not really needed. Normally this case would happen when a reviewer is correcting himself, as after he accidentally put Quality on the wrong revision. It's appropriate that the revision history simply show the current thinking on the state of the revision (which it does).
If the lowering/removal of the Quality rating is due to a conflicting assessment by a different reviewer, then it should be noted or discussed on the talk page. The change information is available in the log, and needn't also be in the history. (It does add clutter to the history, and is inconsistent.)
Hiho,
on the testpage (http://wikixp.org/qa/index.php5/Wishlist_and_bugs),
someone brought up the point that if a flag is removed or lowered in
level, this nowhere appears except in the logfile and that it
therefore might look that flags just disappeared.
Aaron deliberately didn't include flagging messages into the recent
changes or the version history, as this would simply be spam and I
fully agree. However, I think some more visibility of this stuff would
be useful. A nice compromise could be to include all flaggings and
removal of flags of higher level than sighted into the history and the
recent changes. What do you think?
Bye,
Philipp
(sorry for my English and for the crossposting)
I known that the FlaggedRevs extension is under a review stage and their
development is devoted basically to the needs from the most known Wikimedia
project. This is ok to me, no worries on it. But since more Wikimedia
projects have users watching the development of this feature, I think that
only two future official wikis for the public beta testing is insufficient.
Wikisource, for example, have LabeledSectionTransclusion and ProofreadPage
enabled on all of yours wikis. These extensions may have issues to work
appropriately with FlaggedRevs. Enabling these two extensions at the same
wiki devoted to the English Wikipedia beta-testing may generate some
troubles with the en.wp users that don't known how and why Wikisource have
these extensions, to exemplify with only one of the possible reactions. Not
enabling these two extensions + FlaggedRevs at someplace may create false
hopes. And I think that knowing that issues and waiting for someone with the
required skills to fix them when get time to work on it is more proper
instead of a community (a Wikisource wiki) gaining consensus to request
FlaggedRevs getting enabled and finding that a new nice feature brokes another
one.
[[:m:User:555]]
I know I'm dropping in a bit late, and perhaps this was already handled, but
while I was testing this evening, it seems to be that when a non-editor
reverts a page back to the last sighted version, it still reads current.
Wouldn't it make sense that if the version reverted to is in and of itself
sighted, that that should be reflected, regardless of the person performing
the revision?
Or am I missing something?
Thanks,
--Avi
--
en:User:Avraham
----
pub 1024D/785EA229 3/6/2007 Avi (Wikipedia-related) <aviwiki(a)gmail.com>
Primary key fingerprint: D233 20E7 0697 C3BC 4445 7D45 CBA0 3F46 785E
A229
All,
The proposed behavior of the flagged revision extension is to show the
last reviewed version only to anonymous users. I submit that this is
should be default behavior for ALL users (subject to personalization
settings override, I guess). The question here is not just of
vandalism control, but also of making Wikipedia's content creation
process more deliberative. The power to command an article's content
by submitting the last edit is an incentive not only for vandalism,
but also the sort of uncivil version contention that has long been
damaging the community's social fabric. In making the last reviewed
version of an article the default view for practically ALL users, we
remove the incentive for not just vandalism, but all sorts of unsocial
behavior.
Luca de Alfaro wrote:
> For one thing, this would delegate spam fighting almost entirely to a cadre
> of editors: others, even though they are motivated contributors, would not
> bother manually checking the latest page for every page they read, and thus,
> they would not discover whether the latest page is altered. The "good
> samaritan" phenomenon of people casually landing on a page, and fixing it,
> would be much reduced.
This is a circular argument, though :-) , as the current last
edit/default view policy is what makes things such as link-spamming
effective. And while I agree discouraging casual contributions is a
very important concern, one could also play devil's advocate and point
out its drawbacks, particularly the accretion of small nibblets of
information on an article until whatever style it once had is ruined.
But in any case I completely agree that more data is needed, and very
likely different policies may be warranted across different Wikipedias
(or within the same Wikipedia at different stages of its development).
Here are some possible determinants of when an article's default view
should be its last flagged revision, which lend themselves naturally
to configuration options on the extension:
* after an article has been featured
* after an article has accumulated X # of stable revisions
* if an article is in a poorly covered category (this option should
support recursive flagging down the category tree)
More determinants can probably be suggested or uncovered after the
extension has been deployed.
Am I not seeing something, or is the new system only installed in article
space? If so, is the intention to extend it to wikispace?
See http://wikixp.org/qa/index.php5/WikiQA_demo:Reviewer or
http://wikixp.org/qa/index.php5/WikiQA_demo:Editor
--Avi
--
en:User:Avraham
----
pub 1024D/785EA229 3/6/2007 Avi (Wikipedia-related) <aviwiki(a)gmail.com>
Primary key fingerprint: D233 20E7 0697 C3BC 4445 7D45 CBA0 3F46 785E
A229
Hi,
The "template problem" has created quite some debate (rightly). I just hope
that new people read the old threads about it (this has been discussed quite
often in the past) and I think all possible solutions have been proposed and
debated enough.
Although I don't like the current band aid (templates are always embedded with
most recent version) it works for the time being in our test wiki and we
should focus IMHO atm a bit more on severe bugs and UI issues (and then later
come back to templates) like the ones posted on
http://wikixp.org/qa/index.php5/Wishlist_and_bugs (please less wishlist for
the time being).
I'd suggest some systematical review of the UI by everyone (and trying to
confirm, solve, etc. bugs of others).
Arnomane
Of all the issues identified so far, reverts strike me as the most
significant. You revert vandalism, you don't want to have to re-apply
sighting. This happens right now both on manual and automatic reverts.
We're already applying sighting automatically when the user is in the
editor group and the current version is sighted. How about also doing
so if the current version is not sighted, _and_ the text of the
submission is identical to the text of the most recently sighted
revision?
There would be some performance hit due to the comparison, but
hopefully it wouldn't be too bad as it would only kick in on reverts.
Is the basic idea sound? Is there a simpler way?
--
Toward Peace, Love & Progress:
Erik
DISCLAIMER: This message does not represent an official position of
the Wikimedia Foundation or its Board of Trustees.
Good evening folks,
I have committed the last German translations of the Flagged Revisions
into SVN a few minutes ago, it's up-to-date.
But some remarks about the German nomenclatura, so I will continue in German:
Flagged revisions = Stabile Versionen = Name des Projektes, unabhängig
vom Prüfstatus
sighted revision = gesichtete Version = 1. Stufe, vor allem frei von Vandalismus
quality revision = geprüfte Version = 2. Stufe, fachlich geprüft und
für fehlerfrei/vollständig usw. befunden
review(ed) = überprüft = der Vorgang, der zur gesichteten _oder_
geprüften Version führt. Mir gefällt hierbei nicht die sprachliche
Nähe zur "geprüften Version", etwas besseres ist mir leider noch nicht
eingefallen. "Stabilisiert" als Ableitung von "Stabile Version" wäre
zwar konsequent/logisch, gefällt mir aber auch nicht.
Dazu bzw. insgesamt Anmerkungen/Tipps/Verbesserungsvorschläge für die
deutsche Übersetzung?
Ich hoffe, dass alle deutschen Meldungen in sich konsistent sind,
werde aber noch weiter in Eriks Testwiki herumspielen.
Raymond.