Wikiquality-l February 2007

wikiquality-l@lists.wikimedia.org

3 participants
4 discussions

Re: [Wikiquality-l] First steps
by Erik Moeller 10 Mar '07

10 Mar '07

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

4 4

Fwd: Wiki quality / stable version update
by Erik Moeller 28 Feb '07

28 Feb '07

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_Versionen http://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

1 0

Method for choosing stable version
by John Erling Blad 28 Feb '07

28 Feb '07

-----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-----

2 1

First steps
by P. Birken 28 Feb '07

28 Feb '07

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.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Wikiquality-l February 2007