Page MenuHomePhabricator

Enable blacklist for FlaggedRevs on Arabic Wikipedia
Closed, DeclinedPublic


Author: rajulbat

The Arabic Wikipedia has voted to restrict usage of the FlaggedRevs extension exclusively to pages that are exposed to excessive vandalism. In order to implement this, we need to implement a solution whereby administrators can specify on which pages the extension should be enabled.

Link to vote (in Arabic):

Version: unspecified
Severity: enhancement
See Also:



Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 1:10 AM
bzimport set Reference to bz40499.
bzimport added a subscriber: Unknown Object (MLST).
bzimport created this task.Sep 25 2012, 4:43 AM

There is no currently any way in the FlaggedRevs extension to specify a set of pages.

Your change requires a feature request on this extension.

We could for example add a way to restrict the extension to a set of categories, and add articles with excessive vandalism in the set.

This could take a little time to implement.

Meanwhile, you could be willing to discuss and request a mesure transitoire (interim step) like:

  • disable FlaggedRevs (and rely on semi protection for pages with excessive vandalism)
  • restrict FlaggedRevs to the main namespace (currently it's also enabled on images, templates, portal and annexes).

If you wish to review your current configuration, relevant information could be found in bug 19332.

[ Confirming bug. Adding shell keyword. Priority low, as this is blocked by a code change. ]

I created the feature request in bug 40502.

I gave the categories as sample, but in your case, as you want this ability to be controlled by sysops, it should be a page like MediaWiki:flaggedrevs-blacklist.

Dereckson added a comment.EditedSep 26 2012, 5:09 PM

I checked again the local discussion URL and we'll seee last proposal were 5 pro, 4 against, 1 neutral.

  • The first diff given by Ciphers is a note this score isn't a local consensus.
  • The second diff is a previous consultation with a large majority against
  • In the third diff, we learn Rajulbat isn't a confirmed editor but declared himself a new contributor on ar. in Augustus and announced his agenda: to drop the flagged revisions system, with an outreach motivation.

RajulBat, I share yours concerns about outreach, but the wiki configuration is a matter of local consensus. Consensus isn't a majority, it's more a general agreement.

I let this bug open few days for more feedback, but am offering to close it in RESO WONTFIX.

This doesn't drop any merit to your suggestion to extend flagged revisions so he can be used as a blacklist (T42502).

[ shell -> shellpolicy ]

rajulbat wrote:

The implementation of FlaggedRevs was never voted on to begin with, and no consensus was reached. The extension was implemented arbitrarily (or after an obscure "Speak now or forever hold your peace" announcement). On the other hand, the recent vote was announced as much was allowed (in the mailing list, in the Village Pump, and on an announcement/message board internally) and remained open for any user to vote for an entire month. In the end, 5 voted to limit the use of the extension only to certain pages, and 4 opposed this proposal.

[ The previous changes ]

The extension were requested after a discussion between Meno25 and Ciphers with an approval by Cyanos.

But you'll note in this discussion, they all agreed. This is a consensus : the Wikimedia culture tends to prefer quiet discussions to majority votes. The discussion took place in the village pump, a correct place to discuss such matter.

Furthermore, the change were requested on Bugzilla end June. It's only early Augustus the configuration occured. This 6 weeks delay would have allowed any interested people to come and shout "I've relaunched the discussion with strong objections, there isn't consensus anymore.".

2 years later, a new discussion occurs to change the configuration. This discussion didn't lead to a full restriction of the extension, but to disable editors autopromotion and to add 2 new namespaces, Portal: and Annex:

This can be revisited at the following URLs:

  • [[ar:ويكيبيديا:الميدان/أرشيف/تقنية/06/2009]] (section 1)
  • Bug 19332
  • [[ar:ويكيبيديا:الميدان/أرشيف/تقنية/10/2011]] (section 10)

I stress on the point the 2011 discussion were documented rather a comprehensive way by Ciphers.

[ Local consensus ]

The conditions to request such change is mainly an internal matter to the Arabic Wikipedia.

Our responsibility is only to check this consensus exists, not to be a "chamber of appeal".

It's on ar.wikipedia you have to convince other contributors you get a consensus.

If you would be interested by my personal opinion, you'd discover I consider 5 people for a change, 4 against, 1 neutral isn't a consensus, because even if you don't count the neutral opinion, you have virtually the same number of people supporting than rejecting your change.

I would even dare to think your change would be more arbitrarily as nobody opposes the first, but 4 people opposed yours.

This is really the difference between a "discussion to reach an agreement" and a "vote". We tend to prefer the first on Wikimedia communities. And when we use numeral votes, the threshold tends to be 2/3 (some meta RfC or fr. "prises de décision"), 3/4 (the threshold of support votes to become administrator on commons., but the bureaucrat has a discretion power to judge community consensus instead) or 80% (the same for fr., not documented and unofficial, as it's the bureaucrats who check if there is or not a consensus and judge the validity of against votes).

Some votes use Condorcet method to get a winner proposal among 3 to 8, instead to use raw numeric stuff.

It's rather rare (but still exists) to only use 50% as threshold. On some wikis (e.g. fr.), the threshold could be discussed before the vote start.

[ Now, the matter being clarified to be a Pro-Against-Neutral 5-4-1 vote, and implementation change a consensual (if alas not populated) discussion, it's safe to assume there is no consensus. ]

Restricted Application added subscribers: JEumerus, Matanya. · View Herald TranscriptOct 19 2016, 4:55 PM