Discussion:
Status and Priorization before Easter
P. Birken
2007-04-02 18:36:20 UTC
Permalink
Hi,

the current status of the project can be found at
http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/FlaggedRevs/specs.txt?view=markup.
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
Erik Moeller
2007-04-03 03:38:45 UTC
Permalink
Post by P. Birken
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.
This all looks good; we should be able to attract more volunteer
developers once it becomes clear that this is going to be the system
that is put into action. One comment -
Post by P. Birken
- 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
I think that's pretty important to have; if want vandalism review
(which is going to have the biggest PR impact) to be scalable, we need
to be able to flag lots of changes by trusted users automatically as
non-vandalism.
--
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
Gregory Maxwell
2007-04-03 03:47:57 UTC
Permalink
Post by Erik Moeller
I think that's pretty important to have; if want vandalism review
(which is going to have the biggest PR impact) to be scalable, we need
to be able to flag lots of changes by trusted users automatically as
non-vandalism.
My understanding of this feature was that if the current version is
trusted and a trusted editor edits it, their version will preserve the
non-vandalized level of review automatically. Correct?

(I'm working on some models predicting how long we can expect between
not vandalized flaggings given some reasonable assumptions)
Erik Moeller
2007-04-03 04:00:36 UTC
Permalink
Post by Gregory Maxwell
Post by Erik Moeller
I think that's pretty important to have; if want vandalism review
(which is going to have the biggest PR impact) to be scalable, we need
to be able to flag lots of changes by trusted users automatically as
non-vandalism.
My understanding of this feature was that if the current version is
trusted and a trusted editor edits it, their version will preserve the
non-vandalized level of review automatically. Correct?
Yes, that's how it should work. If it is not trusted, it would be nice
if the editor can see an expandable (JavaScripty) diff and quickly
approve previous edits as unvandalized _while_ making his own.
--
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
Joerg Baach
2007-04-03 17:22:46 UTC
Permalink
Hi *,
Post by Erik Moeller
Post by P. Birken
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.
Just to give credit where credit is due - most of the code is currently
submitted by Aaron, who does an excellent and fast job, if you ask me.
So this is not about me deciding, but us having an idea on how to
prioritize.
Post by Erik Moeller
Post by P. Birken
- 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
I think that's pretty important to have; if want vandalism review
(which is going to have the biggest PR impact) to be scalable, we need
to be able to flag lots of changes by trusted users automatically as
non-vandalism.
Mmmh, I take it that people will discuss this and Philipp will change
the priority according to the outcome of the discussion ;-)

Cheers,

Joerg
Aaron Schulz
2007-04-03 05:13:30 UTC
Permalink
OK, nice list, if there are any devs that would like to work on these,
please do so. I'll try to dig into parser.php to play around with
dynamic/synched parsing.

<html><div><FONT color=#3333cc>-Jason Schulz</FONT></div></html>
Subject: [Wikiquality-l] Status and Priorization before Easter
Date: Mon, 2 Apr 2007 20:36:20 +0200
Hi,
the current status of the project can be found at
http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/FlaggedRevs/specs.txt?view=markup.
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
- 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
- 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
_______________________________________________
Wikiquality-l mailing list
http://lists.wikimedia.org/mailman/listinfo/wikiquality-l
_________________________________________________________________
Need a break? Find your escape route with Live Search Maps.
http://maps.live.com/?icid=hmtag3
Joerg Baach
2007-04-03 17:23:45 UTC
Permalink
Hi Aaron,
Post by Aaron Schulz
OK, nice list, if there are any devs that would like to work on these,
please do so. I'll try to dig into parser.php to play around with
dynamic/synched parsing.
Great!

Thx,

Joerg

Loading...