https://bugzilla.wikimedia.org/show_bug.cgi?id=17285
Summary: Totally overhaul the FlaggedRevs configuration variables
Product: MediaWiki extensions
Version: any
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: Normal
Component: FlaggedRevs
AssignedTo: [email protected]
ReportedBy: [email protected]
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.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
