Hiho,
as you maybe know, it was St. Patrick's Day on Friday, which means
that Jörg, who lives in Dublin, has taken the opportunity to do some
hiking this weekend. Next week, he will be not available due to
intense travelling for other projects, however, on the ferry he will
have time to do stuff for us.
Nevertheless, he is confident to have an unoptimized prototype ready
until easter.
Bye,
Philipp
There will be a big Board + Staff meeting in Florida next weekend. It
would be really helpful to be able to show something with regard to
revision annotation / stable versions. Will it be possible to get some
prototype or at least mock-up up by March 14?
--
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
Don't wonder about the broken signature in my previous post. It was modified
by the mailing list software. :p It inserted a ">" at "from the beginings on.
That's what I want to make sure." I have seen this bug on other Wikimedia
lists. Maybe a config issue...
Daniel Arnold / Arnomane
Hi *,
just a short question:
If there is a page, and User A comes along and flaggs it, after which
User B comes along and flags it another way, what do we do?
a) User B overrides User A, we only store the latest flag
b) User Bs flag is used, because it was the latest (keeping both flags)
c) Apply some method to determine an average
d) Show all flags
What do you think?
Cheers,
Joerg
Philipp&Joerg -
could you elaborate on:
> i) First adapt the database model to the new features (article
> history, new user groups).
Currently user groups are not defined in the database, but in
includes/DefaultSettings.php through the $wgGroupPermissions array.
The _membership_ in particular groups is defined in the user_groups
table. What need is there to change the database?
Brion was not on the list yet, so I just added him.
--
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
Some summary comments about things brought up on this list:
Erik wrote about some details, which attributes may be useful/are intented.
> tag comments: Should the tag support a comment field which explains
> why the revision was tagged in a certain way?
I think this would cause some interface problems:
a)
The history would contain multiple comments for a single version, as wan't to
tag an older version without making this the newest one.
b)
The Changelog entry isn't that often used currently. As it is intented to
allow the basic ("sighted") flag to all users with 30 edits/30 days (or a
similat threshold) and to allow tagging on save as well (if the user did
check the sighted button) this would cause more harm than benefit.
c)
So maybe only for the "checked" version tag which can only be applied by a
tiny group of appointed users could use such a thing. Buteven in this case
I'd advocate for some reedit feature of history comments (something we
definetely could reuse in other context, such as correcting third party
credit afterwards right in the history).
> permissions: Which user groups have permission to set the tag?
The "sighted" version is an automatic threshold such as 30 days/30 edits.
The "checked" version people should be an appointed group different from
admins. Thatfor I advocate beureaucrats to be able to appoint those people.
> implicit tagging:
IMHO no. Per default the checkbox setting these flags on editing should be
unchecked (but maybe configurable via user settings). People often edit an
article several times until they are happy. So something like "whoops I did
automatically set sighted flag on a half done version" is not good.
@Joerg Baach (and others):
Are there any further mockups wanted (beside the ones already ceated by me) If
so which one?
http://commons.wikimedia.org/wiki/Image:Mockup-sighted-version-diff.pnghttp://commons.wikimedia.org/w/index.php?title=Image:Mockup-sighted-version…http://commons.wikimedia.org/w/index.php?title=Image:Sighted-version-mockup…
@all: Are there any other mockups about that?
Chers,
Arnomane / Daniel Arnold
Hi *,
just wanted to give a word - I am still alive, reading and playing
around with the mediawiki software, short of creating my first code.
Things are getting a bit clearer, some stuff is a bit surprising
(following my mysql.log).
Tomorrow I will be mostly offline, heading to London, but having stuff
on my Laptop on the ferry. I will give you a note on wednesday, maybe
already some first code bits then, but most likely quite a couple of
questions. ;-)
Yours,
Joerg
For those not on internal, here's the mail which explains the
parameters of the implementation that is currently underway.
---------- Forwarded message ----------
From: Erik Moeller <erik(a)wikimedia.org>
Date: Feb 17, 2007 7:04 AM
Subject: Wiki quality / stable version update
Dear all -
after a couple of failed attempts, Philipp Birken and I have tried to
make sure that the stable version project is firmly on track. For the
members of the Advisory Board: this project is meant to ensure that we
can distinguish between different versions of an article: those
reviewed for vandalism, those reviewed for quality, and those not
reviewed at all.
We have now reached an agreement with Joerg Baach, an experienced
freelance developer, to implement the project for us. We have met
Joerg in person, are confident in his abilities, and have given him
reasonably precise instructions how the first implementation should
operate.
Under the specs we agreed upon, Philipp Birken from Wikimedia Germany
will be Joerg's point of contact. We have also set up a mailing list
for a group of invited people to discuss questions and issues with the
implementation as they arise (not so much to debate, once more, the
entire proposal that has been agreed upon).
For this purpose, I'm happy to hear suggestions of people who would be
useful contributors to this list. These should be individuals who have
made notable contributions to the quality discussion in the past.
Members of the Advisory Board who are interested are also invited to
contact me, but please do read the full proposal below.
After implementation is complete, I intend to open up the list, and
make it the primary forum for brainstorming on quality improvement
initiatives.
Joerg was officially authorized to begin work last Wednesday. We hope to
have something presentable within 4-6 weeks, to be installed on
test.wikipedia.org first, and then tested on de.wikipedia.org once
Brion gives the technical go-ahead and the main kinks are worked out.
Once implementation is making visible progress, I will also discuss
separately with ComCom about the best way to communicate it to the
community and the press. For now, please do keep this reasonably
confidential, as there's always a risk that the project will fail or
be delayed once more for unforeseen reasons (and posting to a public
mailing list almost equates to posting to the New York Times these
days).
== The implementation ==
The specs to implement are a variation of the proposal by Philipp and
other German Wikipedians, found at:
http://de.wikipedia.org/wiki/Wikipedia:Gesichtete_Versionenhttp://de.wikipedia.org/wiki/Wikipedia:Gepr%C3%BCfte_Versionen
The changes are aimed mostly at making the feature more flexibly
configurable, and streamlining some of the UI tasks.
The feature is to be implemented as an extension, if at all possible.
It must be GPL-licensed and will be committed to the Wikimedia
Subversion server.
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.
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?
- permissions: Which user groups have permission to set the tag?
- 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
- 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)
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.
There should be a configuration option which associates a namespace with
- a tag-array
- a minimum level in that array.
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.
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.
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.
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.
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.
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.
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.
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
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).
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.
--
Peace & Love,
Erik
"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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Is there any paper available about the choosen implementation for
stable versions?
Btw, I'm [[:en:user:agtfjott]], [[:no:user:agtfjott]] and also
[[:no:user:jeblad]]. At no.wikipedia.org I'm a bureucrat.
John
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFF5S26ffzlVDUjJkQRAv9GAJ9N6hXynevpihyZfSVpNHdpGuuDPgCfZX+r
EznPIwJaeUIgP07H4xZ4274=
=+X9R
-----END PGP SIGNATURE-----
Hiho,
I just talked to Joerg on the phone and here comes the first update so
far. As you know, Joerg has been sick with fever the last week and was
unable to start the project. He is back on track now and has started
to go deep into the code.
This is his plan for implementing the proposal:
i) First adapt the database model to the new features (article
history, new user groups).
ii) Provide functions and interface to access the new data fields.
iii) Give meanings to the new user groups.
Take care,
Philipp
P.S. Brion, is it possible to contact you by phone again? I told Joerg
that you are the person to ask in case of questions about the code
itself.
