Wikipedia talk:Flagged protection and BLPs/FAQ
Appearance
- Q:Why the fuss about biographies of living persons / Why are they more special than any other article?
- A:The essays in Category:User essays on BLP give an idea of other users' take on this issue. The problem essentially boils down to the potential to do harm to real people. Wikipedia articles tend, for one reason or another, to rank quite highly in internet searches, and a libellous/defamatory and inaccurate statement about someone can cause harm to their reputation for each person reading it - there are even reports of people missing out on jobs because of inaccurate information. Wikipedia serves millions of readers a day who are not editors, so it is important that what they read is accurate when that information can affect other people's lives adversely. In terms of reversion being the answer, there are two counter-arguments:
- If even a few people read the article before reversion, it can have a damaging effect.
- The BLPs of less notable individuals are not heavily watchlisted and so the vandalism lingers for longer
- Q:Why do we need a separate usergroup / Isn't this just more bureaucracy / elitism ?
- A:Opening the project up to allow everyone, anonymous and otherwise to contribute to currently protected articles is a good thing in many people's eyes. The separate issue is protecting BLPs, for which FlaggedRevs has often been touted. In previous discussions, it has proven difficult to distinguish between the differing roles and perceived responsibilities of someone reviewing a flag-protected non-BLP article and someone reviewing a BLP article. This largely arises from the autoconfirmed threshold being relatively low, which is because it is intended as a balancing act between deterring vandals and allowing new good-faith editors to easily establish themselves. Rather than making Flagged protection more stringent by changing this threshold, creating a new BLP usergroup separates the problem out so that it can be considered separately.
- Q:Won't this make it more difficult to review BLPs because promotion isn't automatic?
- A:Promotion could be made automatic if some suitable editing metrics could be determined. The separate group would still be required to distinguish the abilities of the usergroup. Editors in good standing with no recent history of vandalism should have no problem rapidly acquiring the permissions from the well-frequented WP:PERM.
- Q:Why not just give it to Rollbackers?
- A:Rollback is a tool for reverting obvious vandalism. The conditions for obtaining it may differ from those of a BLP reviewer, and, perhaps more significantly, the conditions for removal. As an analogy, it makes sense not to have to remove someone's toolbox if they are only incapable of using the hammer properly.
- Q:Why should Administrators automatically be BLPReviewers / have more power?
- A:This proposal doesn't change the status quo, but there is an understandable perception of cause for concern. As such, the proposal makes it clear that the sysop group will not be granted the power as part of the sysop package of tools, but be granted them separately. It shall be assumed that Admins can be trusted, since they are appointed by the community into a position of trust. This will, however, allow this particular tool to be removed from an admin perceived to be abusing it, without the horrendous litigation of an Arbcom decision to have them desysopped.
- Q:What about backlogs? Won't the backlogs be enormous?
- A:We don't know. The inevitable comparisons to the German Wikipedia are irrelevant since they flag all of their articles with a much smaller userbase. This proposal will flag a small minority of our articles, much smaller in magnitude to the German implementation, and we have a significantly larger userbase.
- Q:Flagged revisions in any form are bad, because it drives contributors away
- A:Ok, not really a question, but a common concern. There is no evidence that this happens. All wikis are currently seeing a trend towards a drop in contributors, not just those who have implemented FlaggedRevs, so it is an error to directly link the two. The flagged protection aspect of this proposal should actually mean that all can contribute to the development of articles.
- Q:Isn't this just creep towards implementation across the whole wiki?
- A:In the first instance, this is a trial, not an implementation. It took years to get us to this discussion, it may take months before this is even approved/rejected. If this proposal were fully implemented, then in itself, it would not lead to wider use because it specifically applies only to BLPs and articles that should be protected under our existing policies. This should also reduce fears of creep beyond scope, since this proposal is no more liberal about Flagged protection than our existing state of affairs. To implement this wiki-wide would, in my opinion, be impossible to achieve because so many oppose it, including the author of this proposal.
- Q:Why trial both Flagged protection and BLP simultaneously?
- A:Principally, if we're to treat the two as having different requirements, we need two systems. And if we have two systems, we need to make sure that we can cope with them both at the same time. Plus, it is a more valuable test of the backlog concern and a more efficient process to run multiple tests at the same time.
- Q:What if one half of the trial works and the other half doesn't?
- A:If the community, in discussion following a trial, decides that only one of Flagged protection or BLP protection is working out, I would hope we'd see that in the consensus formed. If it happens, we could simply undo the part of the system that doesn't work and retain the part that does. That's why it will be so important during these discussions that people do more than just write support or oppose, since it is the reasons that matter.
Talk pages are where people discuss how to make content on Wikipedia the best that it can be. You can use this page to start a discussion with others about how to improve the "Wikipedia:Flagged protection and BLPs/FAQ" page.