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.
Thinking about Wikipedia layout, just about every longer page has an
image, infobox, or other "data overview template". All these have one
thing in common: They are located in the upper right corner of the
page.
The summary box of the stable versions feature is in the upper right
corner of the page.
Anyone else see a layout nightmare approaching?
Magnus
I've tried to document the basic behavior on
http://wikixp.org/qa
but there's definitely a need for more screenshots and in-depth
explanations. Is anyone volunteering for the English version? This
would be an opportunity for someone who can't contribute code to help.
I'd be happy to give you full access to the test site so you can try
out everything.
NOTE 1: http://www.mediawiki.org/wiki/Extension:FlaggedRevs has a
little bit of material already.
NOTE 2: We may have to re-do some of the shots as the UI evolves.
--
Toward Peace, Love & Progress:
Erik
DISCLAIMER: This message does not represent an official position of
the Wikimedia Foundation or its Board of Trustees.
Brion is continuing to review the FlaggedRevs extension for security
and scalabilty. (He's already made several fixes.) Meanwhile, I've set
up a small demo of the extension in the configuration which I propose
we should use for the English Wikipedia. Please don't hit the server
too hard or I'll have to take it down. :-)
http://wikixp.org/qa/
(This is courteously hosted by the University of Bamberg in
collaboration with Open Progress.)
The page should pretty much be self-explanatory.
Thanks once again to the two main developers of the extension, Aaron
Schulz and Jörg Baach.
--
Toward Peace, Love & Progress:
Erik
DISCLAIMER: This message does not represent an official position of
the Wikimedia Foundation or its Board of Trustees.
See
http://wikixp.org/qa/index.php5/Wishlist_and_bugs
--
Toward Peace, Love & Progress:
Erik
DISCLAIMER: This message does not represent an official position of
the Wikimedia Foundation or its Board of Trustees.
Dear All,
I have been following the various threads on tagged revisions.
As many of you know, we have been developing a trust coloring of the text of
Wikipedia articles. The trust value of a word depends on the computed
reputation of the author of the text, as well as on the reputations of all
visitors to the page; for more information, see
http://trust.cse.ucsc.edu/where a demo is also available.
In a short time, we will have new (we hope better) version of the demo out,
and we will ask for your feedback; we plan by the end of October to have a
demo with all the English Wikipedia, as of the Feb 6 2007 dump (the last
complete one), colored. We are still a few months away from doing the
coloring for an on-line, up-to-date, version of the Wikipedia, but we are
working towards that goal.
It may be fun to start thinking at how tagged revisions and trust coloring
may fit together. My impression is that one would be able to get something
superior to either of them separately. For instance:
- If an article lacks a manually tagged revision, one could select as
"stable" revision a recent revision where as little text as possible is
marked low trust (orange background).
- Currenly, text becomes more trusted due to edits: if one edits a
paragraph, one lends a bit of her/his own reputation to the paragraph (on
the assumption that one reads the paragraph she/he is editing). A mechanism
similar to trusted revisions would enable users to say "I agree with this
paragraph and I have checked it" without need for editing it.
- If a manually tagged revision becomes quite old with respect to the
most recent revision (we can measure age both in terms of edit distance and
in terms of n. of intervening revisions), we could detect it, and offer
instead of the automatically tagged revision, a revision that is more
recent, and with no (or as little as possible) low-trust text.
- We could monitor articles where the tagged revision becomes old (as
above), and good candidate revisions are available later, and alert people
in the "watch list" of the article, so that they might consider going to the
article and tagging a newer revision.
These are just ideas that came on top of my mind; I am curious to know which
other suggestions or thoughts you might have. As I said, we are still more
than a month away from a version of trust coloring that works for the
up-to-date wikipedia, but since we are thinking of how to architect the
system, it might be worth to think at how it fits with tagged revisions...
Another issue is this: might it be that, once the trust coloring is
available, the need for showing tagged revisions by default is lessened? If
a trust coloring becomes only one click away, perhaps it is the
trust-colored and tagged revisions that should be available on demand, and
the up-to-date revision should be shown as default, as it has been so far?
I am very interested in your comments...
Best regards,
Luca
--- "P. Birken" <pbirken(a)gmail.com> wrote:
>
> No, this is indeed a valid concern. A feature that allows to unflag an
> article is not included. Unflagging sort of happens by creating a new
> version and flagging that one instead. So, once an article has been
> flagged, it is "in the system". However, initially no article is
> flagged.
Leaving aside the sighted flag for a moment, what about the quality version
flag? Suppose it is given erroneously, because someone made a mistake in
checking the sources for the article - this can happen easily. In that case
there should be a way to unflag the article, no?
Ulrich
>No, this is indeed a valid concern. A feature that allows to unflag an
>article is not included. Unflagging sort of happens by creating a new
>version and flagging that one instead. So, once an article has been
>flagged, it is "in the system". However, initially no article is
>flagged.
On en.wikibooks, a major concern is the ability to "freeze" a book during a semester so that students and teachers have a consistent book version to work from. That said, we would like to have a "stable" version of the book that appears to student readers while a "development" version can continue to be worked on in the background. I guess what I'm most interested in is:
1) The ability to show a flagged version of some pages to all readers by default, but allow development to continue on the "current revision" of the page.
2) The ability to show the current development version of pages that dont need to be frozen, by default.
Now, there are ways to do this kind of thing using clever page protections now, but I think it would be generally preferrable to have the flaggedrevs extension streamline this process for us. Is this kind of thing going to be feasible?
--andrew Whitworth
_________________________________________________________________
Kick back and relax with hot games and cool activities at the Messenger Café.
http://www.cafemessenger.com?ocid=TXT_TAGLM_SeptWLtagline