Author: happy_melon

Description:
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.

Version: unspecified
Severity: enhancement