Wikipedia:Targeted flagging

From Wikipedia, the free encyclopedia
  (Redirected from Wikipedia:TF)
Jump to: navigation, search
"WP:TF" redirects here. For Task Forces, see Wikipedia:WikiProject Council/Guide/Task forces. For WikiProject Transformers, see Wikipedia:WikiProject Transformers.

Targeted flagging is an attempt to find a collaborative way forward that might be acceptable to those with severe reservations about full FlaggedRevs, and those keen to use such to assist with the "BLP problem", while avoiding the development problems and complications of Flagged protection and patrolled revisions.


The main concerns with flagged revisions seem to be:

  1. If widely deployed, it will destroy the "anyone can edit" ethos, driving potential editors away.
  2. There will inevitably be a long backlog between someone editing an article and that edit being approved

These are legitimate concerns.

However, even for those in "BLP hard-liner" school, there should also be concerns with wide use of flagged revisions:

  1. A wide use of flagged revisions will never get consensus - and the fear that a wide use is the end-game of it will prevent more limited use.
  2. A wide use of flagged revisions will force us to give out "reviewing powers" liberally, meaning the quality of the review will be low.
  3. A wide use of flagged revisions will put pressure on reviewers to approve at a glance - which means that only really obvious violations of BLP (e.g. vandalism) will be noticed - subtle libels, and such as false death notices, will get through.

For this reason, flagged revisions being used on all articles is counter-productive, and even its use on all (or most) BLPs is highly questionable.

Targeted use[edit]

As has been argued elsewhere, the nub of the BLP problem concerns our lower-interest "marginally notable", underwatched BLPs. These are the articles where:

  1. Malicious changes are unlikely to be spotted - because they are on fewer watchlists
  2. RC patrols are less likely to identify less obvious malicious edits as the reviewer knows nothing of the subject
  3. Malicious edits are more likely to remain on the article for days, months or even years
  4. These article may be the only biography on the internet, and thus have more "impact" on the subject's reputation
  5. It is among these articles that we've had the most problems and (some of) the worst press - from false death notices to imaginary gay lovers.


So, here is what targeted flagging proposes:

Deploy flagged revisions only on the least watched biographies of living people.

(Notability is slippery, so we go for the objective and useful and usable criterion of "number of watchers.")

The advantages are:

  1. Although there would be a good number of articles included, a smaller proportion of first-time edits would be to these articles. No high-profile, or even moderately notable articles would ever be flagged - so new editors would not necessarily encounter Flagged Revisions. 97%+ of edits would be to other articles.
  2. Although there would be a good number of articles included, the comparatively low number of edits to such articles would allow for very fast edit approval times.
  3. These are our most vulnerable articles (malicious edits to celebrity bios get reverted quickly - yes, even those to Ted Kennedy) - so this limited deployment would be the most effective in preventing BLP harm. Win/Win

Possible details[edit]

How we might implement Targeted flagging:

  • We might start with a fairly small number of articles (say those currently on no watchlists whatsoever - we can identify these). We look for quality reviews of all edits here, but with an aim of ensuring that edits are approved in minutes.
  • We allow OTRS ops to add a small number low-notability BLPs where there's a genuine complaint of unacceptable material that was not quickly reverted. These are the articles current systems are evidently failing. (By unacceptable I mean untrue and potentially damaging - not just unreferenced and negative.)
  • We perhaps allow for the flagging of articles on a legitimate request from a lesser known subject who has concerns.
  • We do not increase the number of articles flagged beyond this until the "basically no delay" aim is met.
  • If, and when, it is met, we might consider throttling up the system to articles on (say) fewer than 5 watchlists.
  • We stop throttling when the average delay starts to get beyond the "very short time review". I'd suggest that's about 15 minutes max.
  • Admins may not flag articles on a whim or personal decision - any article outside the above parameters would have to be considered and agreed. The default would be "no flagging" - consensus should exist before doing otherwise.


A targeted flagging approach can perhaps unite those who don't want to see flags generally deployed with those who want to see the maximum protection for the most vulnerable BLPs. It would be in the interests of neither concern to dilute the effectiveness of Targeted Flagging by general deployment. Backlogs must be prevented, or this will fail.

Targeted flagging could be for a trial of two months or so, with an understanding that it is dependent on a very short review time being maintained.


Why is targeted flagging better than flagged protection and patrolled revisions (FPPR)?
  1. We can implement targeted flagging NOW; FPPR still needs development work, which has already caused long delays and may cause more.
  2. Flagged revisions (which works on the same technology as targeted flagging) has been fully tested on other Wikipedias (German); FPPR is untried and untested. Let's do what works.
  3. It is not clear when FPPR should be used on an article, whereas targeted flagging is clear in what it is aimed at.
  4. Targeted flagging does not need the complicated distinctions between "full" and "semi" flagged, or between "patrolled edits" and "flagged protection".
  5. Targeted flagging proactively helps the most vulnerable BLPs; FPPR is unclear in scope and open to constant disagreements over which articles are covered.
  6. Targeted flagging does something for vulnerable BLPs as a class and not on a case-by-case basis only after problems have emerged.
  7. There would be no further need to semi-protect BLP articles covered by this. Now, anyone can edit.
  8. Keep it simple, Sally!