Hi folks,
although both Aaron and Jörg keep eluding my requests for some
definite time tables like Jelly, they cannot keep it a secret that the
implementation of the specs is nearly finished. Therefore, we should
start the planning of the next phase, namely testing this on a broader
basis.
First of all, we need a wiki and a datadump. Any suggestions?
Furthermore, we need people to test this. Of course, the people on
this list should be there, but that is the point where we would want
to open up the test more. Personally, I'd say that we spread the word
carefully.
Finally, there is the question of what to test. The implementation was
done in a more flexible way than in the original german proposal, to
allow for more tweaking to the needs of one community or the other.
However, a test is not so good of we do not test in the way it will be
turned on in the wiki. Therefore, I suggest either testing at first
only the simpler original functionality.
Cheers,
Philipp
Hi,
during the last discussions, some misunderstandings have occured due
to the fact, that the current setting is rather abstract. Also, some
members of the german community approached me and said: "wait a
minute, that's not what we wanted." So, maybe we could change the
setting for a few days so that we have the situation from the german
proposal? This might also show whether the more flexible
implementation does indeed work for the more specialized setting.
I first ask this here, because I don't want to delay development by
this request. So if you want to implement something that requires the
more flexible setting with three tags and additional dimensions there
in the next fews days, please just say so.
Bye,
Philipp
If there is to be a status icon for the Version History lines which is to signify the unvandalized state, the one attached might do. I usually try to avoid language-specific content in a simple icon, but in this case I think it will get across the idea better than most alternatives. I guess this would work for the German WP as well as the English WP.
____________________________________________________________
GET FREE 5GB ONLINE STORAGE - Safely store your documents, photos and music online!
Visit http://www.inbox.com/storage to find out more!
Joerg wrote:
> ... next step is to have something along the line of your icons for
> unreviewed/reviewed/stable. Need to integrate it.
The de.WP Sighted/Examined design has three states to be distinguished:
* unrated
* marked as Sighted
* marked as Examined
These states need to be visible in the Version History lists, etc.
I initially thought the proposal to have 3 icons to represent unreviewed, reviewed, and stable states would work as a way showing the three WP.de states. Unfortunately, it seems they do not:
To work, the states would have to correspond like this:
* unreviewed = unrated
* reviewed = marked as Sighted
* stable = marked as Examined
The problem with this is that since Sighted is defined to be "reviewed but not stable", no Sighted version will appear as the default revision of a page, that is, display of the current vandalized version will be preferred over display of the most recent Sighted version, as would an ancient Examined version.
I believe this means the unreviewed/reviewed/stable icon idea will not work as is.
I am getting the feeling that we should bite the bullet (in the American idiom) and recognize in the implementation that the "unvandalized" dimension is special, and should have certain special treatments.
This is very much as applicable to en.WP as it is to de.WP. Even though en.WP may have more dimensions (depth, readability, etc) than does de.WP, the English WP still needs to rely heavily on the "unvandalized" characteristic to make the basic encyclopedia appear halfway reliable.
"Unvandalized" might be special in these ways:
(1) One can set it without setting any other dimension.
(2) If set and no other rating is set, the "unvandalized" icon is displayed.
(3) Perhaps, the right to set "Unvandalized" can be granted separately from other review rights.
(4) Perhaps, a non-null setting in any other dimension requires or implies that "Unvandalized" is set.
The more I think about it, the more it seems to me that the unvandalized attribute fits into the Wikipedia world in a way fairly different from other dimensions like size (stub, etc) and readability (Concise, etc).
Thoughts on a treatment of Unvandalized in some way like this?
-RS
____________________________________________________________
Inbox.com is giving away free iPODs, movie tickets and gigabytes!
Learn more about this contest on http://www.inbox.com/contest
Here is a small issue and a larger issue about the various flagged revision message boxes that appear at the top of articles.
The small issue is that on my IE and Firefox browsers the text usually is too small to read. This seems to be due to the CSS file (and my PC environment). A gif showing a sample is attached. It seems that this box uses the CSS class "flaggedrevs_tag1", which specifies "font-size: 50%" which results in text too small to be useful (it seems to me).
The other issue is whether these sorts of message boxes should be appearing in all the places they currently do. In particular, I think many wikis will want to avoid having any box at the top of the default revision (the "latest stable revision" as the box text says). IMHO, the typical Wikipedia (noneditor) reader shouldn't be burdened with a message box in his face with irrelevant, to him, stuff. If some people are sure this will be wanted sometimes, perhaps it needs to be an option. (I'm guessing an installation CSS change couldn't make the whole box disappear, but I don't know.)
-RS
For those not on internal, just a heads up. I'll send a copy of the
page later after some more eyeballs have looked over it.
---------- Forwarded message ----------
From: Erik Moeller <erik(a)wikimedia.org>
Date: Apr 23, 2007 9:40 AM
Subject: quality.wikipedia.org draft
To: "Local Chapters, board and officers coordination (closed
subscription)" <internal-l(a)lists.wikimedia.org>
I've put up a draft for a page which I think we ought to launch with
much fanfare at quality.wikipedia.org soon:
http://internal.wikimedia.org/wiki/Quality.wikipedia.org
In this, I implicitly propose the creation of a "quality assurance
fund" people could donate to. This would be the first example of a
restricted fundraising campaign; I hereby invite feedback about it. I
think we should budget for quality tech, generally, so I do not think
that having a restricted fund for it would pose any issues.
Implementation-wise, it could perhaps be done using a filter on
donation comments, at least for PayPal.
Another implicit assumption is that we will refactor all the
quality-related pages on Meta into a nice newbie-friendly overview; I
welcome anyone to take the lead on this.
Feel free to edit the page. I think it ought to be more visually
appealing as well, perhaps with a photo (Jimmy or Florence).
In terms of "What you can do" steps, I still think it would be pretty
cool to provide a simple method for experts and other readers to
submit quality reviews of Wikipedia articles, with a radiobutton
( ) submit review publicly
( ) submit review privately
where the private submissions would go into OTRS, and the public ones
onto the talk page. Doesn't seem too hard to do, and might get us
useful feedback.
--
Peace & Love,
Erik
DISCLAIMER: This message does not represent an official position of
the Wikimedia Foundation or its Board of Trustees.
"An old, rigid civilization is reluctantly dying. Something new, open,
free and exciting is waking up." -- Ming the Mechanic
--
Peace & Love,
Erik
DISCLAIMER: This message does not represent an official position of
the Wikimedia Foundation or its Board of Trustees.
"An old, rigid civilization is reluctantly dying. Something new, open,
free and exciting is waking up." -- Ming the Mechanic
I saw the announcement that the software for the test wiki had been changed.
I am still getting problems with the Eric Clapton page on the test wiki.
Would it be helpful for me to investigate the issue myself? Or is there some other action I should take?
----------
This message was sent from a MailNull anti-spam account. You can get
your free account and take control over your email by visiting the
following URL.
http://mailnull.com/
I've been perusing some of the FlaggedRevs code recently (as it has evolved). It seems to be heading in a good direction. I'm not sure what ideas have been rumbling around in all your heads, but I thought I'd share the following thought with you in case it hasn't been brought up yet.
Performance is likely to be something of an issue, and will become more so as the database becomes populated with growing numbers of flagged revisions. Obviously the most common operation is to display the default version of an article. With FlaggedRevs this involves joining rows from the flaggedrevtags, flaggedrevs, and revision tables in a nontrivial database operation. The idea is to mostly avoid this with an additional table.
The table in its simplest form would just have two or three columns:
PageID (primary key)
RevID of the "latest stable revision" by namespace criteria
Valid flag for above RevID (or coded by NULL in revid, etc)
A default-revision access would go directly to this table and if a valid revid is found would then pick up the text of the page from the flaggedrevs table. If not found, the access would proceed as in the current approach. Possibly the access itself should put the resulting revid into the above shortcut table, but maybe this update would be done by a background task, or just by review-updates.
Once filled in, the default-revision access should be much better, even for only occasionally-accessed pages. Having this table requires that an update to the revid or valid flag be done when a page is given a new review setting, so that the new shortcut table will not persistently yield a wrong answer.
Now, all that seems good, but this table also should help with support of the number one wishlist item, per-page default-selection criteria. The shortcut table could record the criteria to be used for the page, perhaps in a text form convertable to the $wgFlaggedRevTags PHP variable which controls the selection.
With that in the table, a default-revision access would again use the revision found if it is set, otherwise select the revision using the page-specific criteria if they are present (otherwise the namespace default, of course). The table would also then be used in the other various flagged-revision queries, since it would be the residence of the per-page revision selection criteria.
I'd guess this idea has no particular implications for the early implementation now advancing rapidly, but it might be useful to ponder for work a bit down the road.
-RS
Hi,
the current status of the project can be found at
http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/FlaggedRevs/spec….
Jörg will work on this project fulltime this week, but will not be
available the week thereafter. Still, the goal is to start testing on
a broader basis before 20th of April. It has turned out, that having
multiple levels for a single flag makes things complicated, for
example when looking at the feature of reviewing versions from a diff.
Following is a copy of the above namend textfile, where I have added
priority levels to the features that are not yet done. Based on this,
Jörg will decide what to do next. Priority 1 is the highest. Feel free
to comment on my priorization, in particular if I made severe errors.
Otherwise, see you next week, I'll greet Benedetto from you ;-)
Bye,
Philipp
The wiki will allow the configuration of "revision tags", which can
then be associated with any revision of an article. Tags are organized
in tag array, where each array represents a set of tags that describe
a similar attribute, e.g., accuracy-related tags would be organized in
one array, while those used for flagging materials for export might be
organized in another. This is to ensure that "levels" of quality
(unvandalized -> reviewed for accuracy -> featured article etc.) can
be represented correctly.
###Status: Works so far
Each tag has certain attributes:
- tag comments: Should the tag support a comment field which explains
why the revision was tagged in a certain way?
###Status: every tag has a comment so far
###Wishlist item: possibility of having no comment field for certain tags.
- permissions: Which user groups have permission to set the tag?
###Status: for overall flagging permissions can be set
###Todo: have it on a per flag basis
###Priority: 2
- stylesheet and UI: not requiring explicit configuration, each tag
should have a stylesheet class and MediaWiki: namespace message(s)
associated with it, to allow for differences in visual and textual
representation
###Status: namespace messages are there
###Todo: css classes and ids
###Priority: 8
- implicit tagging: should this tag be implicitly set by any user
within the associated group when editing? (this will be used for the
"non-vandalized" tag)
###Todo: do it
###Priority: 7
A generic change is required to allow for automatic membership in a
user group when a user has more than X edits and is older than Y days.
###Todo: do it
###Priority: 3
There should be a configuration option which associates a namespace with
- a tag-array
- a minimum level in that array.
###Status: minimum level per tag, not namespace
###Todo: do it
###Priority: 9
This option determines that, by default, the revision shown from this
namespace will be the one from that array which is also >= the minimum
level. So, for instance, one could determine that pages in the article
namespace need to be at least checked for vandalism, or at least
reviewed for accuracy.
###Status: nearly there on a per tag level, last bugs being fixed
###Priority:10
As a high priority wishlist item, these view options should also be
applicable on a per-page basis. The existing protection UI should be
expanded for this purpose. Implementation (and schedule) of this item
will depend on overall implementation progress.
###Todo: do it
###Priority: Wishlist
Whichever view one ends up with, we expect that the top of the page
indicates this, and allows you to switch & get diffs to other views.
###Todo: done
Because MediaWiki currently does not show templates and revisions in
time synchronization, this behavior has to be fixed for old revisions.
When one has expressed a preference for a revision with a specific
tag/level (e.g. "unvandalized") AND this is the most recent revision,
it will be shown together with the most recent equally tagged
templates if they exist, otherwise with the most recent ones.
###Status: shown with most recent ones, images are stored in local
### cache
###Todo: to it for old revs
###Priority: 1
Example: On a page like the Main Page, which includes many templates,
one would typically want to have an unvandalized view of the entire
construction. The Main Page itself rarely changes, but because the
most recent revision is flagged as "unvandalized", it would be
synchronized with templates for which this is also true. When viewing
an older version, however, the templates would be shown as they were
at that date&time.
###Todo: do it
It is crucial that queries for revision lookup are highly performant;
we should aim for a performance impact of less than 10% on uncached
pageviews with a revision tag preference. Needless to say, the feature
needs to interact correctly with Squid proxy caching.
###Todo: comes at the end
Tagging revisions should be possible from three places:
- when editing (with the help of a collapsible diff)
- when looking at diffs
- when looking at revisions without any prior or later tags.
###Status: mostly done
###Priority: 4
A tag can only be set with reference to a diff to the last version
that has the same tag. The Special:Recentchanges tool should be
###Status: on any diff
###Todo: limit to last version
###Priority: 5
customizable to have such a diff link to the last version with a given
tag. It is desirable that this view also includes an icon that
indicates the state of the logged revision (derived from the tag
stylesheets).
###Todo: do it
###Priority: 6
Wishlist items for the future include things like mass vandalism
review and advanced queries. I also have some ideas for phase II of
the project, which I would love to see implemented before the tool is
switched on on the English Wikipedia, but this will wait until phase I
and any adjustments needed for its operations are successfully
completed.
###Extras: Logging