I haven't had any press queries about this as yet, but if I do: what's
the status of putting something into place on de:wp as planned? I
understand it's delayed by devs being busy with the WMF fundraiser ...
- d.
Several collaborators and I are preparing to expand on previous work to
automatically ascertain the quality of Wikipedia articles on the English
Wikipedia (presented at Wikimania '07 [0]). PageRank is Google's hallmark
quality metric, and the foundation actually has access to these numbers
through the Google Webmaster Tools website. If a foundation representative
were to create a Google account and verify that they were a "webmaster,"
they could download the PageRank for every article on the English Wikipedia
in a convenient tabular format. This data would likely serve as a fantastic
predictor. I would also like to compare the Google-computed PageRank to the
PageRank computed via Wikipedia's internal link structure. I don't see any
privacy implications in releasing this data. It also doesn't seem to help
spammers much, as they already know the pages that have a very high
PageRank, and we include rel="nofollow" on outbound links. Nonetheless, I
would of course be willing to keep the data private.
This would only take a few minutes if it were approved. Is anyone out there
who has the power to make it happen?
Cheers :)
Brian
[0]
http://upload.wikimedia.org/wikipedia/wikimania2007/d/d3/RassbachPincockMin…
Dear All,
we have finally finished a technical report describing in detail the
algorithms we use for the Wikipedia trust coloring (see
http://trust.cse.ucsc.edu/). The technical paper not only gives the
algorithms, but describes several ways to quantify notions of text trust for
the Wikipedia, and provides detailed quantiative results on the quality of
our coloring.
The technical report is available here:
http://www.soe.ucsc.edu/~luca/papers/07/trust-techrep.html
We would of course appreciate comments and feedback. I wish a happy weekend
to you all,
Luca
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