Last modified: 2009-02-01 00:06:04 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T19285, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 17285 - Totally overhaul the FlaggedRevs configuration variables
Totally overhaul the FlaggedRevs configuration variables
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
FlaggedRevs (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Aaron Schulz
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-31 18:29 UTC by Happy-melon
Modified: 2009-02-01 00:06 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Happy-melon 2009-01-31 18:29:21 UTC
The concept for FlaggedRevs' flags is fairly simple, but its implementation has grown ridiculously convoluted.  The 'schema' is that there are a small arbitrary number of 'sets' of flags, with an arbitrary number of flags in each set, aranged hierarchically. We can create arbitrary new permissions which are able to sight pages a limited height up each flag set. There are also what I'll call "markers", which are *collections* of flags: currently we have hardcoded three markers, "stable", "quality", and "pristine". We set minimum heights up each flag set that are required for a revision to qualify for each marker, and then manipulating things on-wiki is usually done by marker rather than by flag, eg Special:Stabilisation.  So essentially there are three arrays: one of flag sets, one of editing permissions, and one of markers.

So let's get this straight. We define the flag sets in the variable $wgFlaggedRevTags, but that's actually a dictionary that maps flag levels onto the "quality" marker.  We then specify the length of each flag set in a *separate* variable $wgFlaggedRevValues, which is applied to all the sets (so they must necessarily all be the same length).  We then have $wgFlagRestrictions to define permissions, an array of arrays that is ordered by *flag set* first and *then* by permission.  Having bolted "pristine" onto the system at a later date, we don't even try to allow any flexibility in mapping this marker to the flags, just defining in $wgFlaggedRevPristine a height across all flag sets. We cap it all off with a mysterious $wgFlaggedRevsPrecedence to say whether there is actually any real difference between the two markers.

Now I am fully cognisant of the dangers of hindsight, and the difficulties in writing an organic program like MediaWiki, but am I missing something or is this just completely crazy? :D  

It strikes me that we would be doing ourselves a huge favour if we untangled these configuration settings and created some proper flexibility.  Doing this without breaking backwards compatibility may be difficult, but it will be a Good Thing To Do.  I propose the following default schema:

-------------------------------
#Array of flag sets, and how many flags there are in each set
$wgFlaggedRevsTags = array(
    'accuracy'  => 3 ,
    'depth'     => 3 ,
    'style'     => 3 ,
);
#Markers are groups of flags, used for things like stable version 
#selection; this is an array of available markers and how high up 
#each flag set the article needs to be flagged in order to qualify.
$wgFlaggedRevsMarkers = array(
    'stable'    => array( 'accuracy' => 1 ,
                          'depth'    => 1 ,
                          'style'    => 1 ,
                   ),
    'quality'   => array( 'accuracy' => 2 ,
                          'depth'    => 1 ,
                          'style'    => 1 ,
                   ),
    'pristine'  => array( 'accuracy' => 3 ,
                          'depth'    => 3 ,
                          'style'    => 3 ,
                   ),
    );
#Define new permissions, and limit how high up each flag set they
#are able to flag articles.  Users cannot lower tags from a level 
#they can't set, users with 'validate' can do anything regardless
$wgFlaggedRevsPermisions = array(
    'review'    => array( 'accuracy' => 1 ,
                          'depth'    => 2 ,
                          'style'    => 3 ,
                   )
);
-------------------------------

This remaps the current default configuration onto the new variables (resolving the issue that, by default, the "pristine" marker is off the top of the flag scales), and IMO makes it *much* easier to comprehend what's actually going on.  Note there is no naming conflict ($wgFlaggedRevsTags vs $wgFlaggedRevTags). A way of defining the hierarchy of the markers might be helpful; it seems this is already being done in hardcode.

The benefits of this schema are most obviously to disentangle the markers from the core code, and make them things that can be customised at a site level.  This is valuable as many sites don't make any use at all of the 2D nature of the flags array, they just have one flag set and so would really like a 1-to-1 mapping between the flags in that set, and the markers that they can actually use.  Conversely some wikis may want to develop a more complicated marker system; this allows them to do that.  And of course it stops us adding boundlessly more hardcoded bits and bobs into the system to accomodate the wants of the Wikimedia communities :D Tighter control over markers is also useful for improving Special:Stabilisation and other places where we now have a proliferation of radio buttons for "X", "Y or else X", "Z or else Y or else X", etc etc.  It also reinforces the idea of the "current" version as an implicit marker with values 0 for all flag sets, which is useful for other things.

Integrating this new schema with the old without breaking backwards compatibility is probably quite difficult, although probably not impossible.  A conversion script could map one onto the other without difficulty as a permanent solution; maybe we could write a mapping function to get the data from the old configs.
Comment 1 Aaron Schulz 2009-01-31 20:42:03 UTC
$wgFlaggedRevTags redesigned (with b/c) in r46654. This gets rid of the need for $wgFlaggedRevPristine, and the levels don't all have to be one value. 

$wgFlaggedRevValues removed (with b/c) in r46658. Each tag can have it's own value.

$wgFlaggedRevsPrecedence was tweaked (with b/c) recently to account for pristine revs (it can be 0,1, or 2).

Don't see use in '$wgFlaggedRevsPermisions' variable vs the current one.
Comment 2 Happy-melon 2009-01-31 20:55:00 UTC
Wow, I wasn't expecting it to just get *done* :D

Certainly this is a massive improvement.  It doesn't fully cover the scope of the bug - I was suggesting that we un-hardcode "quality" and "pristine" - but that's what you get if you make such a massively wide scope in the first place :D  Do you think there's mileage in such a move?

With the way you've chosen to nest the arrays, the existing $wgFlaggedRevsRestrictions setting is actually more sensible than my way (I just proposed it for completeness and because it was laid out in the same way as my other arrays).
Comment 3 Aaron Schulz 2009-01-31 21:21:23 UTC
'quality' and 'pristine' are entirely opaque as far as the UI is concerned. Messages could be set to so that 'pristine' means anything from 'featured', 'published', to 'protected'.

It is, of course, unintuitive to use 'pristine' as the software keyword for 'protected' (ala "flagged protection") or something, but I'd rather not use cryptic level keys like 'level1' and 'level2' due to border uses of the software.
Comment 4 Happy-melon 2009-01-31 21:58:01 UTC
I'm more thinking that some wikis may only want to use one marker, while some may want to use ten.  Since there's no direct access to raw flag levels, everything has to be through markers, so if a wiki wanted to (for instance) implement an en.wik-esque quality scale a la [[Template:Grading scheme]], then they'd need at least seven markers to be able to sort logs and so forth by each level.  Or a wiki that uses multiple flag sets might want to create a marker that highlights pages that are strong in one area but weak in another.  Etc etc: since we've created these makers to act as a layer of abstraction over the raw flags, it's a bit rude to deny them the opportunity to customise the marker array as easily as they can customise the flag array.  I'm not saying that we should change the names from "pristine" and "quality", rather that the whole marker principle should be implemented in config variables so that they are as accessible as possible.  Plus it'll mean that when someone asks for a fourth marker there'll be no need to bolt on yet more functions :D
Comment 5 Aaron Schulz 2009-02-01 00:06:04 UTC
Beyond the lack of need for a large number of revision levels, it also has performance and db implications. The main point of the levels is for a stable version selection hierarchy, not for general tagging.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links