Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

New ideas and proposals are discussed here. Before submitting:

• Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
• Consider developing your proposal on Wikipedia:Village pump (idea lab).
• Proposed software changes should be filed at Phabricator (configuration changes should have gained a consensus).
• Proposed policy changes belong at Wikipedia:Village pump (policy).
• Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.
• Proposed new articles belong at Wikipedia:Requested articles.

« Archives, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Revisiting past proposal – Viewdelete userright

I know that this idea has been around since the proverbial dawn of time, and a past discussion from 2008 flatly rejected this kind of userright. Almost seven years have passed, yet the reasons for opposing at the time are every bit as relevant today as they've ever been (with the caveat that RfA has become much harder to pass, a reality that I consider irrelevant to the merits of this proposal). Nevertheless, I figured it might be worth another shot – with some modifications.

Speaking as a non-admin, there have been a number of instances where I’ve wanted to review deleted material for research purposes. For instance, one time I was thinking of creating a replacement article for this one, based largely around its negative counterpart (but with stricter inclusion criteria). This has since been done, so the point is moot. At the time however, I faced a conundrum. In order for me to assess whether that was a good idea, I needed to know what the page looked like beforehand so as to develop a better understanding of why it was deleted. Having the ability to view these pages myself would have been far more convenient than asking an administrator for assistance. This is just speaking for myself; I’m sure there are many editors who would use that ability responsibly were it granted to them, but are not interested in full adminship or would not pass an RfA due to a lack of relevant experience. Another example would be Carrite. In 2013, he was nominated for adminship by Dennis Brown on a temporary basis so he could have the ability to review evidence in the Richard Arthur Norton ArbCom case without the tedium of having to consult administrators in order to do so.

The foundation has come out in opposition to any sort of initiative that aims to increase access to deleted (and therefore, sensitive) material. I'd imagine that their strong reservations still stand today, perhaps even more so than at the time. This brings me to my next point, and the major alteration to the 2008 proposal: what I’m proposing is not a tool that would be given out at an administrator’s discretion to any old editor asking for it via WP:PERM. Viewdelete would be granted following a community discussion similar to RfA, wherein the basic question being asked is: “do I trust this user with the ability to view deleted content?” Or, to put it in another light: “will granting this particular user viewdelete cause the WMF legal issues, put anyone’s information at risk, open the flood gates to obvious abuse on their part, or make a mess for administrators to clean up?” After a lengthy discussion (say, 4-7 days, depending on what is agreed upon by the community), either an administrator or a bureaucrat (whoever is tasked with the granting of this tool) will assess the consensus and come to a decision. The threshold for granting viewdelete would therefore be quite high.

Additionally, the restrictions placed on the application of viewdelete would be stringent. In particular, it must not be used for the following purposes:

• Restoring content after it has been speedily deleted per CSD
• Restoring content that was deleted based on community consensus at any XfD page
• Revealing sensitive information for any reason whatsoever, whether publicly or privately

Ideally, administrators would have the authority to automatically revoke viewdelete in the event that it has been misused. I've still not worked out all the fine details of its implementation, which is something I figured could be handled by the community were this to go forward.

I feel that my proposal addresses most of the opposing points that were raised in the RfC from seven years back. Viewdelete would not be a userright that is given out to just anyone, but to people who are sufficiently tenured and thoroughly vetted by the community. The only question that remains for me is whether or not the WMF would be open to this particular suggestion; does this proposal address the question of legality to a sufficient extent for it to be implemented? If the community and the WMF are willing to consider this idea as it is phrased, then I propose we put it to a test run lasting around three months or so. Specifically, we would be looking to see whether or not the workload for the WMF and the oversight team is significantly increased. As this would not be given to just anyone who asks for it, but only to editors deemed trustworthy enough by broad consensus, I do not feel that the exposure of sensitive information would be an issue.

Thoughts? Kurtis ^(talk) 16:37, 4 January 2015 (UTC)

• I'm in favor of it, obviously, but it's hard to see too much traction for creation of such a specialized user right. Carrite (talk) 00:53, 5 January 2015 (UTC)
• Strong Oppose for the same reasons this usually gets opposed: would create legal issues with minimal-bordering-on-zero benefit to offset them. Think of it this way: Viewdelete is the most "dangerous" of the admin tools, at least in the legal sense, as revealing libelous or personal deleted info can't simply be reversed the way a bad protection or block can be. Therefore, the threshold for granting that right would be just as high as RFA itself. Anyone interested in it should just go through RFA. Andrew Lenahan - Starblind 01:33, 5 January 2015 (UTC)

(edit conflict × 2) Why should a perfectly capable and trustworthy individual be forced to undergo a full RfA and all the garbage associated with it to be able to see deleted pages? Say I don't want to be able to protect a page, I don't want to be hassled by other editors asking me to undertake admin tasks, or I don't care about the block status of other users. Why can this not be an option? Dustin (talk) 01:45, 5 January 2015 (UTC)

For the same reason you can't access a police station's evidence room without being a cop, or a bank vault without being a banker: you want keys to the kingdom, you get the scrutiny that comes with them. Hell, if anything passing an RFA is a pretty low bar for the all-you-can-eat buffet of libel, copyvio, and weird details of highschoolers' sex lives that comes with it. Really it would make more sense for Viewdelete to be available not to every admin but admins who have an understanding of libel and intellectual property laws in the US. Andrew Lenahan - Starblind 02:18, 5 January 2015 (UTC)

Admins are supposed to be janitors, not cops. they certainly don't undergo the rigorous (albeit occasionally flawed) training, supervision and vetting of the latter. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:03, 12 January 2015 (UTC)

It is the most "dangerous" of the admin toolbox, yes, but it is also the one least likely to be abused in the hands of a responsible editor. "I want the ability to view deleted pages and revisions" is not going to fly at an RfA – period. If you're not expressing any interest in dispute resolution, XfD, or really anywhere you'd expect to find an administrator, then the community would see no point in granting the bit. Being an administrator requires more than just being responsible; it requires discretion (as in, good judgment). The only real discretion I would expect from viewdelete is the good sense not to be going around and revealing sensitive information. Remember, I did say that the threshold would be very high. Kurtis ^(talk) 02:20, 5 January 2015 (UTC)

"it is also the one least likely to be abused in the hands of a responsible editor" Kind of by definition, in the hands of a responsible editor no tool is likely to be abused. But for a deceitful editor, I would say it's the most likely to be abused - because unless you actually undelete the page, it's not logged anywhere. So if someone was giving deleted information out off-wiki, it would be nearly impossible to trace. RFA looks at competency because that's really all we can measure. We generally just assume trustworthiness. Unless someone is actually caught lying or something, I don't know how we could have a community discussion purely about the trustworthiness of an editor that's not just a grudge-airing and is more reliable than a coin toss. Mr.Z-man 04:11, 5 January 2015 (UTC)

I can definitely understand your concern about the possibility of gaming the system, and about the difficulty of passing such a process. I'm not suggesting that viewdelete should be easy to obtain. Really, such a system would not be much easier to game than the one that exists now, assuming someone really wants to get access to that kind of information. I see people opposed at RfA for all kinds of reasons that have nothing to do with competence or trust: in this RfA, for example, an editor who is clearly trustworthy was denied access to the tools because he did not demonstrate sufficient experience in administrative areas to sway a large enough portion of the commentators into supporting him. If someone with a similar tenure to his were to apply for viewdelete, I'd imagine that they would pass. Kurtis ^(talk) 05:09, 5 January 2015 (UTC)

• (edit conflict) My short answer would be: 'If you want to view deleted pages, then you must run for adminship.' I appreciate the time you have taken to post the above suggestion but I'm fairly sure that the Foundation would not allow it. Perhaps Philippe (WMF) could chime in here. Secondary issues are that creating yet another user right would create more bureaucracy - it would almost certainly need an RfA style application (with all its issues) for the right (so again, why not apply for adminship?). I'm not personally aware that the demand for such a right is sufficiently compelling, particularly as all proposals for unbundling admin tools are perennial failures.

Finally, I reject the notion that RfA has become much harder to pass:

The RfA system has increased its level of maturity since the watershed year of 2007 prior to which the tools were handed out following RfAs of very low !voter participation. We now have a very high turnout at each RfA and even the revered 100+ 'Support' RfA are now perectly commonplace. That said, the !voters at RfA are still very much a transient pool of users, so in reality the criteria are set anew for each RfA depending on who turns out to !vote. By 2014 RfA was also no longer quite the humiliating process it was when I started WP:RFA2011 and Mr Wales supported tha initiative with his famous "horrible and broken process" statement. --Kudpung กุดผึ้ง (talk) 01:42, 5 January 2015 (UTC)

The most important part of my proposal is where I outlined the hypothetical process as being community-driven. This is not like being granted rollback rights; it's much more akin to adminship. As I've said above, an administrator is not only someone who has proven themselves trustworthy enough to be granted access to a certain degree of sensitive information, they must also demonstrate an ability to make tough judgment calls and a willingness to partake in maintenance work or dispute resolution. No one is going to be granted adminship just because they would like access to deleted revisions, even if they were trustworthy enough to have such permissions, as that would be a virtual waste. Kurtis ^(talk) 02:20, 5 January 2015 (UTC)

I think this a bad idea. If a view-deleted editor later decides to become an admin, they basically would have to go thru a second RfA. If you want to unbundle admin tools, a better approach would be a user right to place limited blocks and semi-protects. Oiyarbepsy (talk) 04:51, 5 January 2015 (UTC)

• @Kurtis: Regarding "I’ve wanted to review deleted material for research purposes", see WP:RESEARCHER. Regarding "I was thinking of creating a replacement article for...", see WP:USERFY. I think you can already use Wikipedia:Requests for undeletion for that purpose. Regards, Wbm1058 (talk) 14:56, 5 January 2015 (UTC)

I think the researcher permission only applies to seeing the revision history, as opposed to the content itself. The whole point of this proposal is so that ordinary editors don't have to go to an administrator to view deleted pages. If they are deemed trustworthy enough, they can do so themselves. Kurtis ^(talk) 15:46, 5 January 2015 (UTC)

Correct, it is much like a RevDelete where only the text is deleted. — xaosflux ^Talk 19:37, 5 January 2015 (UTC)

• I agree with the sentiment of unbundling viewdelete from the mop and bucket for purposes of article creation. Wbm1058 already made the excellent point of using REFUND for that purpose. I oppose the nomination's idea of an RfA-like process because RfA is probably too stringent. I don't think the flag should be given out by any single admin, either. Whatever the process, I'd recommend the permission be temporary and responsive to a specific request. "In order to write an article on X I'd like to see the deleted versions of Y and Z.". If the flag automatically hits sundown we can limit contempt for the permission. My question would be, how often does anyone really need to see a deleted version? Chris Troutman (talk) 20:24, 5 January 2015 (UTC)
• Strong oppose per my concerns voiced at the debate at Commons. This is a solution in need of a problem. --Tom (LT) (talk) 22:35, 5 January 2015 (UTC)

  There is or might be a real problem in need of a simple solution: Some days ago I stumbled over two files on commons arriving there as thumbnail of what still was or used to be a decent image here. I think that license reviewers (folks with this right, a bot if that's all what it takes to figure out that 100KB on commons cannot match a deleted 1MB here) should have the right to review what exactly happened here years ago. –Be..anyone (talk) 07:51, 6 January 2015 (UTC)

• I've read all this and I simply do not believe there is a real problem that needs solving here. As creating this user right would be a long and contentious process it does not seem worth the effort. Beeblebrox (talk) 23:33, 6 January 2015 (UTC)
• Oppose per all the usual reasons. Let's just keep it as a package deal. -- œ^™ 02:58, 7 January 2015 (UTC)

From what I can see, most of those in opposition appear to be sysops. Not to say sysops' opinions don't hold equal weight, but I think it would be best to do more discussing before going into all of that !vote stuff. Dustin (talk) 03:04, 7 January 2015 (UTC)

• Oppose, IIRC the WMF has explicitly said that users must go through RfA or an equivalent process to get this, so there's really no point in having it separate. ansh666 05:58, 7 January 2015 (UTC)
• Oppose as a solution in search of a problem. Stifle (talk) 14:04, 7 January 2015 (UTC)
  • This isn't personally directed at you Stifle, but I'm really beginning to hate this sentiment. It's used to rebut just about any proposal, and it says very little. Proposers spend a long while typing detailed descriptions of why a change might be beneficial, only to be dismissed with such a flippant and nearly meaningless sentiment as "solution in search of a problem". In this particular case, the proposer even outlined a very specific situation in which this restriction was a problem for him. Stifle, please don't feel personally obligated to reply to this, as like I said, this isn't directed at you as much as a general comment on the proliferation of proposals getting shot down on these grounds which boil down to "the status quo is just fine, change is scary and unnecessary". Gigs (talk) 17:09, 7 January 2015 (UTC)
    • Thank you, Gigs — I couldn't have said it better myself. ;) Kurtis ^(talk) 17:32, 7 January 2015 (UTC)
    • @Gigs:Great comment. I'm gonna add it to Wikipedia:Arguments to avoid on discussion pages. I quoted you at Wikipedia talk:Criteria for speedy deletion#Clarification of CSD G13. Oiyarbepsy (talk) 15:28, 8 January 2015 (UTC)
    • I'm sorry you feel that the comment wasn't constructive; however, I do believe it is accurate and that writing a short comment is preferable to a long comment that says the same thing, particularly when other users have said the long bit before. There is an occasional fallacy brought up in WP discussions that comments "don't count" towards consensus somehow if they don't have a unique reason attached. Stifle (talk) 16:22, 13 January 2015 (UTC)
• Oppose - First, there have been successful single bit need RfAs in the past, so the current RfA process can be used in that case. And since RfA-esque community support is needed for the viewdelete right anyways I don't see the benefit of breaking it out as compared to say something like template editor. I disagree that RfA's have gotten harder having !voted in them over the years except for the edit count inflation they seem less contenious these days although fewer in number. I can see myself possibly supporting other bits being split off ( and have done so in the past ); but—especially given the requirements from legal—not viewdelete. PaleAqua (talk) 17:30, 8 January 2015 (UTC)
  • "there have been successful single bit need RfAs in the past" - When was the last? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:06, 12 January 2015 (UTC)
    • Most recent such request that I recall was [Wikipedia:Requests for adminship/Trappist the monk]], but I didn't comment in all the RfAs this last year so might have missed another. PaleAqua (talk) 22:50, 12 January 2015 (UTC)
• Oppose - the {{cent}} headline for this discussion asks whether we should "grant highly trusted users with the ability to view deleted content through a consensus-driven process". WP:RFA is the "consensus-driven process" by which the community "grant[s] highly trusted users" with this ability. The Wikimedia Foundation have also stated that there are legal issues with this kind of change. I'd certainly be happy to vote support in an RfA that sought to have time limited access to deleted revisions and pages if I trust the user in question: if someone were to propose allowing bureaucrats more latitude to, say, close an RfA as "promoted for a temporary period of X months" rather than either promoting or not promoting, then the RfA process could accommodate this kind of request. The only reason I can see to have a non-RfA process to grant this right is so that there is less participation and consideration given to a request for the unbundled right rather than the full administrative toolset. I'm not comfortable with this user right being granted with less participation than an average RfA gets. None of that changes the fact that RfA does suck in a lot of ways. The answer to that is to try and find ways to fix RfA rather than short circuit the valuable democratic oversight function that RfA provides. —Tom Morris (talk) 16:04, 11 January 2015 (UTC)

I was actually thinking that "viewdelete" requests could take place on the same page as RfAs and RfBs. I wasn't intending to suggest that this be a process where scrutiny could be evaded. Kurtis ^(talk) 16:51, 11 January 2015 (UTC)

• Oppose in three points. First, I don't really see how it would be useful to create a bureaucracy to give out view-delete rights. Going based on my own experience, I can only think of one deleted article in the nine years I have participated on Wikipedia that I have ever wanted to view post-deletion. And that was only because the result of the discussion was merge and delete, but the merge was botched and a citation was lost. How many times can any editor really say they've needed to access content from a deleted article? Is it really that many times to justify having this ability enabled indefinitely? I don't believe it is.

Secondly, I believe WP:Requests for undeletion and CAT:RESTORE provide perfectly valid options regarding deleted content (CAT:RESTORE is a list of admins who are willing to provide deleted content). If an editor believes they are justified in viewing deleted content, then it shouldn't be too difficult to justify that at WP:UND. And to that point, as I've been thinking about this issue, one question comes to mind: does an editor need access to deleted content urgently? As the title of the essay WP:NORUSH goes, "There is no deadline."

Lastly, and above all else, there is a legal dimension to this proposal. If a representative of the Foundation can no longer say to a client's lawyer that sensitive deleted content is only viewable by "trusted administrators," then the project appears to be weaker. No matter how much trust we can invest in these certain editors who would be approved for the view-delete right, they are still not administrators. I believe it is in the best interest of the project that those people with view-delete be administrators. --hmich176 17:52, 11 January 2015 (UTC)

• Oppose. I gave my main thoughts in my earlier comment. Now that voting has begun, I'll just reiterate that Adminship is about trust and competency. If you give a user only one of the tools and not all three, is it because you only have 33% trust and s/he is only a third as intelligent as a full admin? Anyone who wants one tool should be clever and industrious enough to convince the community that s/he would be competent with all three. --Kudpung กุดผึ้ง (talk) 20:07, 12 January 2015 (UTC)
  • If we refuse to give a user the tools, that says something about our trust. But if the user specifically asks for only one, that says something about the user. Maybe it says he doesn't expect a successful request. Maybe it says he doesn't want to be hassled by requests to block people. Maybe it even says that he doesn't want French spy agencies to arrest him and demand that he delete the article on Radio station military Pierre-sur-High again. The other editor's choice doesn't say anything about my trust in that editor. WhatamIdoing (talk) 22:35, 14 January 2015 (UTC)
• I support the unbundling of the viewdelete and undelete user rights in the circumstances that I outline below and also the creation of some new user rights that I outline below.
  • I am under the impression that unbundling the viewdelete and undelete user rights would be acceptable if the rights were granted by a process that is practically identical to RfA (ie a community !vote, conducted over several days, with the opportunity to pose questions to the candidate etc). I think this would allow the same level of scrutiny that presently takes place at RfA.
  • We might also consider implementing multiple levels of deletion to avoid the problem that some deleted material is considered sensitive. What I propose to call "deletion level 1" would be for articles that are deleted for legal reasons or are otherwise considered to be sensitive (eg articles deleted as copyvios or for WP:BLP issues). What I propose to call "deletion level 2" would be for articles that are deleted for harmless reasons (such as possibly an article about a person who died in the year 1800, or a book published in that year, that was deleted solely on grounds of notability, which contained substantial content verifiable with reliable sources, and not sensitive in any way). It seems to me that the viewdelete and undelete for such a hypothetical "deletion level 2" could be handed out more freely, possibly at PERM or perhaps even given to all logged in users. This would be useful in that we frequently make very bad mistakes about notability (because GNG is so subjective and the SNG are incomplete in their coverage) and certain aspects of WP:NOT, such as failing to transwiki content to sister projects or deleting articles which ought instead to be rewritten or merged per WP:PRESERVE, and so forth. (And some of our exclusionary criteria are questionable, and consensus can change, and we might from time to time abolish particular exclusionary criteria, necessiting review of possibly large numbers of deletions done under them).
  • WP:REFUND is an extremely inefficient means of reviewing or restoring large amounts of deleted content, because it uses two people to do the work of one person and requires discussion between them that may be unnecessary. It is therefore not a viable alternative.
  • Since anyone can remove a PROD for any reason, and removed PRODs cannot be restored, it is not clear why only an admin can undelete an article deleted as an expired PROD. WP:REFUND appears to be an innefficient process for doing this. James500 (talk) 15:44, 14 January 2015 (UTC)

I indented your points to make it clear at first glance that it's one full statement instead of multiple unsigned comments. ansh666 21:45, 18 January 2015 (UTC)

• Oppose - this is maybe a bit stale but I'm adding comments here anyway. I think that viewdelete is a right best left with admins. It's not terribly difficult to get an admin to help with access to or review of deleted content when the situation is appropriate, and whether or not such a request is appropriate is a decision best judged by admins, in my opinion as a non-admin. If a proposal to unbundle the deletion rights nonetheless requires candidates to be subjected to a process identical (or reasonably similar) to RfA, then it's not better than just making them run the RfA gauntlet. And I do think that such an unbundling should require such a process. Ivanvector (talk) 20:27, 23 January 2015 (UTC)
• Comment correct me if I'm wrong, but don't we already have a consensus driven process aimed at highly trusted users that lets them review deleted material? I think its called "RFA" or some thing like that, and its purposes is exactly this. Why then do we need two versions of the same process? TomStar81 (Talk) 12:37, 29 January 2015 (UTC)
• Comment. The 30-day period that would be typical for an RfC will run tomorrow, but this isn't an RfC. I'm just commenting to note that I've read the discussion and don't think it needs a formal closure, but I'm open to other suggestions. - Dank (push to talk) 11:41, 1 February 2015 (UTC)
• Oppose Since most deletions aren't urgent, I see no need for this. If it were unbundling the blocking right, I'd be more likely to be in favor, since that can be urgent, but unless the deletion is a G10, it can wait.--Jasper Deng (talk) 04:33, 5 February 2015 (UTC)
• Not a comment on the proposal, but I believe Kurtis meant to link to Wikipedia:Requests for adminship/Carrite rather than Wikipedia:Requests for adminship/Dennis Brown. ekips39 04:36, 5 February 2015 (UTC)
• Oppose for all he usual reasons (I've gotten tired of listing them...). This is the umpteenth viewdelee proposal we've had lately - can we give these a rest for another year or so now? – Philosopher ^{Let us reason together.} 18:55, 6 February 2015 (UTC)
• Oppose, mainly for the reason outlined by Starblind Cas Liber (talk · contribs) 03:57, 11 February 2015 (UTC)
• Note - the similar (though not the same) user-right package Researcher already exists. - jc37 11:40, 16 February 2015 (UTC)

Proposed user right: Vandal fighter

There has frequently been discussion about making some of the administrator tools available to a lot more editors, and User:Jackmcbarn presented a great idea at Wikipedia:Village pump (idea lab)/Archive 15#New "vandal stopper" user group. The proposed vandal fighter user right would have the following rights:

• Blocks:
  • Can block unconfirmed accounts for a maximum of 48 hours
  • Can soft-block IP addresses for a maximum of 48 hours
  • Can unblock users blocked by other vandal fighters
  • Can NOT unblock users blocked by administrators
• Page protection:
  • Can semi-protect a page for a maximum of 48 hours
  • Can Pending Changes 1 protect a page for a maximum of 48 hours
  • Can unprotect pages that were protected by other vandal fighters
  • Can NOT unprotect pages that were protected by administrators
• Notes:
  • All vandal fighters would also be granted Pending Change reviewer status
  • All vandal fighter actions will be viewable on one or more special pages
  • An administrator can turn a vandal-fighter action into an administrator action, which would prevent other vandal-fighters from removing it.
• Requirements:
  • Vandal fighter rights would be granted by administrators after requests at Wikipedia:Requests for permissions
  • Rights would only be granted to user who meet the requirements of both roll back and pending changes reviewer
  • Vandal fighter rights must only be used for obvious spam and vandalism. Anything else will be considered abuse of the tool and the right will be revoked.

I look forward to your comments. Oiyarbepsy (talk) 23:57, 21 January 2015 (UTC) Pinging editors at previous discussion: @Biblioworm:@LT910001:@TheGeneralUser:@TenOfAllTrades:@Technical 13:@Cenarium:@Scalhotrod:Oiyarbepsy (talk) 23:57, 21 January 2015 (UTC)

The very early votes are indicating that this might pass, but people have several questions and objections. In light of that, I have a request for the voters: if it's still looking like this might pass after a week or two, then please check back at the end of this RfC in case the closers need help in determining consensus on the various suggestions and objections. - Dank (push to talk) 23:22, 22 January 2015 (UTC)

We're at the one-week point; I'll leave some notes in a few minutes at WT:Village_pump_(proposals)#Vandal fighter RfC. - Dank (push to talk) 22:57, 28 January 2015 (UTC)

• To those who believe that anyone who may be trusted with this could go through an RFA, I would like you to know this is not the case. There are many RC patrollers that deal with clear-cut vandals who may not have as much content creation experience (achievements like GAs and DYKs) to be a full admin, due to the complex role that admins play (in settling disputes, closing AfDs, managing user rights, editing site-wide javascript, and blocking long-term abusers whose edits may not be easily categorized as vandalism). Many RC patrollers and members of the CVU would love to help with stopping vandalism by blocking obvious, uncontroversial vandals after giving them four warnings, but unfortunately, they can only continue to revert until an admin acts on the AIV report, which in some cases can take a long time. Sometimes, the vandals are only blocked hours later, when they are no longer active. By creating a new user right that provides these RC patrollers with the ability to block non-autoconfirmed users, but only in clear-cut and uncontroversial cases of vandalism, we can significantly curb vandalism and allow admins to devote their time on more disputed cases and other administrative areas, without leaving room for abuse as the right is removed immediately if it is used on anyone who is not an obvious vandal. Tony Tan⁹⁸ · talk 01:25, 1 February 2015 (UTC)

References

Support (vandal fighter)

Support - Best idea I've seen in awhile. Give me the right and I'll contribute a lot more to fighting vandalism, taking some of the load off admins. If I abuse it, take it away. Unless admins spend more time granting and revoking the right than they currently spend responding to vandalism, which seems very unlikely, it's a clear net gain. I would ask for some kind of vandal fighter summary page covering the necessary tools and procedures, with links to more detailed information (unless something like that already exists). ―Mandruss ☎ 00:11, 22 January 2015 (UTC)

1. Support. As long as the right can be easily removed by an admin, I see no reason why we shouldn't have this right. --Biblioworm 00:18, 22 January 2015 (UTC)

   Support - I agree. this one just might go somewhere. Mlpearc (open channel) 00:53, 22 January 2015 (UTC)
   The opposes have swayed me. Mlpearc (open channel) 04:21, 5 February 2015 (UTC)

2. Not incredibly into vandalism patrolling but can definitely see where this right would be useful, so I support it. --ceradon (talk • contribs) 01:05, 22 January 2015 (UTC)

   Support, provided that the restrictions of the tool are limited to the original specifications in this proposal. If anything else gets added to the function of this user right after this comment, assume that I'm neutral. Steel1943 (talk) 01:20, 22 January 2015 (UTC)

   Moving to "oppose" after giving this some thought. Steel1943 (talk) 16:35, 24 January 2015 (UTC)

3. Support This is a great opportunity to both empower the editors confronting vandalism while relieving the need to push more editors through RfA, where XfD and content creation become required. Chris Troutman (talk) 02:05, 22 January 2015 (UTC)
4. Support I'd much rather see accounts be indeffable, as I mention in the discussion section below, but we can always do that later. Jackmcbarn (talk) 03:50, 22 January 2015 (UTC)
5. Support, but with one reservation: I'm opposed to calling it vandal fighter as that would seem to promote a battlefield mentality. How about vandal control, vandal abatement, or even vandal extermination. The proposal is good one though, and would streamline the normal process of reporting to AIV or RPP and sometimes waiting hours for action to be taken.- MrX 04:05, 22 January 2015 (UTC)

   Well, fighting vandals (especially the sockfarm-creating ones who come back to harass you) does sometimes feel like a battle, but I see your point. --Biblioworm 04:43, 22 January 2015 (UTC)

   • Also support changing maximum 48 hour block to maximum indef block to address some of the objections from opposers.- MrX 01:00, 24 January 2015 (UTC)
6. Support - I know that (assuming I had these rights) I could all but stop reporting IPs at WP:AIV, would usually have better and easier damage control over the user accounts I'd still report there. I'd also probably not have to post at WP:RFPP again. Freeing up those pages would probably help take care of the backlog at WP:SPI (now if only we had some similar demi-adminship to help with that), and resolve issues at WP:ANI quicker. I suspect this would also help with the admin shortage while reducing the risk of abusive admins, as would-be admins would have a vandal-control record to show that they can at least be trusted with that (something that honestly probably better demonstrates admin ability than article creation). Ian.thomson (talk) 04:16, 22 January 2015 (UTC)
7. Support but with some notes. I trust that Jackmcbarn wouldn't propose this sort of thing if he hadn't already determined that it were technically feasible, so I am not concerned about that. What I am concerned about is the automatic granting of other user rights which we already have processes for. I would prefer that granting of those rights were prerequisites for this one, since they are all related and those are better established, rather than potentially granting those more mature rights through what could turn out to be a back door. But I'm not terribly concerned about it - these are fairly weak user rights. I think the benefits outweigh the risks; I'm in to try it. Ivanvector (talk) 04:32, 22 January 2015 (UTC)
8. Support. I think having this right would be a great idea, as blocking vandals could be faster- there will be no need to wait for the administrator- the vandal fighter can block the vandal immediately, without a report to AIV. This is one of the best ideas I have seen. pcfan500talk|my contribs 10:51, 22 January 2015 (UTC)
9. Support - if given out carefully and sensibly, and if it can be easily removed by a full admin or community consensus. Quite frankly, the number of times I've had to report an obvious vandal to AIV, only for the request to sit there for hours - with the vandal still working their way through many articles - due to the lack of any administrators being active at that point is quite depressing. Sometimes this can also come from a topic area being poorly covered by admins, and thus they lack the understanding of what might be a fairly obvious piece of vandalism to someone with some experience in that topic (I can think of some examples of this as well.) Lukeno94 (tell Luke off here) 21:00, 22 January 2015 (UTC)
10. Conditional support As I've said in opposing other admin bit split outs, I could see supporting blocking and think this could be useful. I do have a few restorations. The first is the 48 hour limitation. I'm opposed to any such split out that would just make more work for the admins and agree with a bunch of the concerns on it that have already been. While technically I suppose that makes my !vote an oppose at this time, I see enough disagreement that I'm hopefully that it will change. I also worry about the name but not enough to oppose on that. At the risk of bikeshed'ing how about something like "Wikipedia Watch" or "Sentries"? I'd also like to see some pretty strong removal guidelines in the event of abuse or even careless misuse, for example once someone that has gotten this user right loses through abuse or marked carelessness the only way for them to get similar rights in the future would be a full RfA. Since the right should be somewhat easier to get it needs to be balanced by being easier to strongly revoke. PaleAqua (talk) 23:12, 22 January 2015 (UTC)
11. Support – There is so much rubbish lying around, and so few administrative hands to deal with it. We need some housekeepers to keep an eye on things, so that simple messes can be mopped up. Save administrative time for severe and complex problems. Such a distribution of power will greatly improve the encylopaedia. A right that is easy to give and take away for this purpose is exactly what we need. If a housekeeper fails to carry out his or her duties appropriately, sack him or her on the spot. RGloucester — ☎ 01:09, 23 January 2015 (UTC)
12. Support. Great idea, if an admin is going to be able to remove it. APerson (talk!) 06:45, 23 January 2015 (UTC)
13. Support Nothing is more infuriating than giving a vandal the standard four warnings then making a report to AIV which goes unread for hours, all the while the vandal continues to vandalize articles. I think that this user right would be very useful as a stop gate measure since it would give trusted non-admins the ability to prevent further vandalism by a user until an actual admin can step in. Spirit of Eagle (talk) 07:05, 23 January 2015 (UTC)

    Support in principle. Some of the issues brought up below (standards for giving out the right, possibility of indeffing unregistered users, whether 48 hours of PC is useful, etc) can be ironed out later. I dislike seeing good proposals opposed on technicalities that really aren't important to the broad idea, and I think that broadly speaking this is a good idea. Sam Walton (talk) 11:01, 23 January 2015 (UTC) Withdrawing my support, I've been swayed by the oppose voters, but not quite enough to oppose. Sam Walton (talk) 23:06, 27 January 2015 (UTC)

14. Support a perfectly reasonable suggestion that will undoubtedly be torpedoed by this community's utter inability to ever agree on a major change. Mellowed Fillmore (talk) 17:33, 23 January 2015 (UTC)
15. Conditional support - Initially I was going to oppose, but all of my concerns could be put to bed with a trial; so, I support a trial rollout of this user right. However, it needs a different name, 'vandal fighter' is too combative — to the point it is likely to exacerbate vandal behaviour. I suggest "Moderator", as the proposed abilities roughly reflect what a moderator does in other places on the Internet, or "Sentry", per PaleAqua. Bellerophon _{talk to me} 20:19, 23 January 2015 (UTC)
16. Support This could help reduce some backlogs. Though indefinite block may be better than a 48 hour limit. Graeme Bartlett (talk) 22:56, 23 January 2015 (UTC)
17. Let's give it a test run and see how it goes. Kurtis ^(talk) 00:50, 24 January 2015 (UTC)
18. Support Know what, lets try it out. At the very least it would maybe speed up actions at WP:AIV and some other areas. Lor^Talk 07:40, 24 January 2015 (UTC)
19. Support With maybe a few more restrictions (voting?) to make sure that these rights don't go to unknowledged/abusive editors. Avono (talk) 14:58, 24 January 2015 (UTC)
20. Support as a measure that would give broader access to useful tools to editors for whom some form of review exists to determine that it would be useful for them to have the tools. Per Kurtis, above, we can always test this out for a limited time, and then evaluate the results to see if it is worth keeping. Cheers! bd2412 T 21:43, 24 January 2015 (UTC)
21. Support. This would be useful for experienced recent changes patrollers without much in the way of content creation. I would also like to see the limit on block lengths and protection lengths removed, and the requirements tightened up. Perhaps users who have X many successful requests to AIV and RFPP, and no unsuccessful requests in the last Y months. — Mr. Stradivarius ^{♪ talk ♪} 13:31, 25 January 2015 (UTC)
22. Partial support. To me, the most important part of this proposal is "Can semi-protect a page for a maximum of 48 hours". We have a problem with the length of the process to combat libellous additions to WP:BLP pages. Giving vetted users the right to protect pages that are early in a BLP war would give the full administrators time to examine the problem and decide what to do. Serpyllum (talk)
23. Support. Should, however, need more than simply rollback+reviewer, as those are given extremely liberally. --L235 (talk) Ping when replying 19:16, 25 January 2015 (UTC)
24. Support. My knee-jerk reaction is to oppose this out of fears of hat chasing and misuse. But after some reflect I decided that I trust our users to do this right thing. I think that every new user should be given a chance but once they have demonstrated that they won't play well with others they should be blocked. The blocking and the page protecting with stop large attacks on articles that happen from time to time and free up the administrators to do better things. --Adam in MO Talk 04:13, 26 January 2015 (UTC)
25. Strong support under some conditions. (editor) It would be obvious for an editor to support. Though, since there is a template for other editors to join the discussion, here am I. As an editor, I experience every-day vandalism. It's tiring having to refer to a board to have actions enforced, some of them take awhile meanwhile the vandalism continues. This way, as a Vandal Fighter, the process would be a lot easier and less painful to watch. It will save admins' time, though monitoring would take a great deal of time as well. I agree on the Vandal Fighter board. If extra actions are to be enforced, admins will be there. Though, the process to grant the user rights have to be a lot more than that. As a user mentioned below, it is considered as junior administrators. Granting these user rights, considering the impact it could have, it should be more thorough and strict. Thorough and strict as in go through the user's history. Review if their requests (RPP, AIV, 3RR/EW, etc.) were done properly with valid arguments of their report. If they are randomly making requests, then someone grants the user rights, hell will break lose. I don't suggest a rough process such as admins to grant the rights, just a more thorough examination. I, for one, would be the first to apply. I struggle a lot with vandalism in my watchlist from those whom choose to ignore warnings. I, myself, am well aware of adminship. As an adminstrator for two wikia websites, it would be great to have admin minions, if you will, to help out and run this Wikipedia in order. Not every admin is available to respond to requests, or sever backlog will take time to clean out. I do agree with a statement a user has made. The user rights will be revoked once the user is no longer available. Say, two weeks? Also, I would suggest the admin reviewer who granted the user rights to monitor the user for 48-72 hours (then once after some time) to make sure no non-sense is occuring. Some could go in a spring of protections and blocks. Callmemirela (talk) 05:29, 26 January 2015 (UTC)
26. Strong support (and possible snow close? Come on!) This would really help out, when we vandlal fighter find a vandal and have to wait, some times, up to an hour for a block while the user keeps vandalizing and we have to keep reverting. (t) Josve05a (c) 17:32, 26 January 2015 (UTC)
27. Support We need this, many users can't stop vandals easily with their own rights and we need to be able to block, this would put the vandal count down by a lot. ~HackedBotato ^{Chat with me ♽ Contribs} 18:59, 26 January 2015 (UTC)
28. Support badly needed, since there are only ~575 active admins, and fewer still in the vandal business, with 1000s of vandals a day. KonveyorBelt
29. Support - I would never subject myself to the RfA process even if asked, but this would give much needed tools to editors like me who already have rollbacker and pending reviewer. Perhaps one requirement could be having rollbacker without any complaints for at least a year or two. VMS Mosaic (talk) 09:23, 27 January 2015 (UTC)
30. Support - This is very useful for trusted RC patrollers and allows them to respond to vandalism quickly, without giving too much power to non-admins. It is especially useful in cases like this, where a user vandalized egg 174 times for half an hour, even though an AIV report was quickly filed. Tony Tan⁹⁸ · talk 05:23, 28 January 2015 (UTC)
31. Support - Sounds great! George Edward C – Talk – Contributions 20:30, 28 January 2015 (UTC)
32. Support In practice, while it may be subject to changes, the general concept appears to be sound. Dustin (talk) 01:33, 29 January 2015 (UTC)
33. Strong support with some suggestions. I think that this is an incredibly good idea. AIV is a very tedious and sometimes frustrating process when sysops do not respond quickly. I strongly agree with the portion of the proposal which says that only rollbackers and pending changes reviewers should be granted use of the tool. It should only be given to highly trusted users, almost reaching admin level of trust. In light of that, I have a few suggestions. Like many have mentioned, I don't think that "vandal fighter" is a good name. It seems too warlike and doesn't give an specific description of its purpose. Possibly a simpler name like "blocking rights" or something like that? Second, I think there should be a minimum number of edits and time since joining Wikipedia to even be considered for this right. If not a strict policy, perhaps a general guideline that admins would usually follow when granting this. Third and finally, I think that more than one admin should check the applicant's contribs and qualifications before granting the use of this tool. It is a very delicate tool and I think that a second sysop should check the first's assessment in allowing access to this. However, I would still support this right even if my suggestions aren't incorporated into the tool. I hope it passes! BenLinus1214^talk 03:35, 29 January 2015 (UTC)
34. Support per Chris troutman YatharthROCK (talk) 02:46, 31 January 2015 (UTC)
35. Support Although it should be hard to acquire, possibly like a (very) mini RFA process? RetΔrtist (разговор) 01:07, 1 February 2015 (UTC)
36. Support - seems like a great balance of user rights to me. It would outline good potential admins early on. I would find the (even limited) page protection rights to be extremely helpful sometimes. Whether I would be comfortable with blocking right off the bat is another thing, however, but I would still undertake it eventually. Considering that I have created 0 articles (and don't see myself bothering to attempt to go through that mess any time in the near future), I have a higher chance of walking outside and getting struck both by lighting and a meteor within two minutes than I do passing an RfA. Command and Conquer Expert! ^{speak to me...}_{review me...} 09:33, 3 February 2015 (UTC)
37. Support As someone who does mostly maintenance tasks on Wikipedia, this would be a very useful tool for fighting vandalism. Just yesterday I was trying to stop 3 different IP addresses vandalising a page for over an hour while waiting for someone to respond to an AIV report. Since AIV has proved ineffective, we clearly need more people dealing with this. As Cncmaster points out, many of us vandalism fighters wouldn't pass an RfA as we don't do much content creation. I would however suggest a higher threshold for giving the rights, such as experience with AIV reports, demonstrating they know when a block is appropriate instead of just reverting and warning. Jamietw (talk) 06:47, 5 February 2015 (UTC)

    @Jamietw: - Yes. Myself, I have never observed a direct correlation between the amount of content creation one does and the competency one demonstrates as an administrator. If there is some magical point that I have been missing for four years, I would really like to know what it is. Command and Conquer Expert! ^{speak to me...}_{review me...} 04:52, 6 February 2015 (UTC)

38. Support I support this so long as this proposal fails. In addition, the name "vandal fighter" sounds pretty cool; good name choice, proposer. Tharthandorf Aquanashi (talk) 12:03, 5 February 2015 (UTC)
39. Support Where do I sign up? As a Special:PendingChanges list patroller for the last year or so, I've advocated for this almost from the start of that effort. There is no single perfect solution to dealing with vandals and the majority of the opposition to this proposals seems to be based on this idea being "imperfect". Please, lets start with SOMETHING! --Scalhotrod (Talk) ☮ღ☺ 16:40, 6 February 2015 (UTC)
40. Support I support a very limited block power (short duration, IP only), subject to regular review by administrators, and easy removal of the userright by administrators. Ideally a parallel page to WP:AIV would be set up where vandal fighters would be required to submit a user report before implementing a vandal fighter block, making it easy for administrators to monitor/approve/extend/overturn the blocks as necessary. --Ahecht (TALK
    PAGE) 17:19, 6 February 2015 (UTC)
41. Partial support in order to separate and distribute powers. I prefer PaleAqua's name suggestion "Sentries" however. --Mr. Guye (talk) 01:34, 7 February 2015 (UTC)
42. Support Definitely support this measure, would love to be able to block persistent vandals who are obvious, blatant and unwilling to stop after multiple warnings. I think this would definitely help address some of the admin backlog too, since users with this right would be able to quickly quell persistent problem users. Melody Concerto^talk 00:39, 9 February 2015 (UTC)
43. Support If you can qualify for this you should be able to pass RfA, on that I agree. However RfA has become somewhat ridiculous lately. Gigs (talk) 17:38, 12 February 2015 (UTC)
44. Strong Support If you qualify this is definitely a great idea! Iv'e been helping out at AIV and this is really needed. TheMagikCow (talk) 18:10, 15 February 2015 (UTC)
45. Support but I would agree with shorter periods than the mentioned 48 hours. 12 hours block or semi-protection will spoil the fun of most vandals already. They ones that need more can be dealt with by admins. The Banner talk 12:23, 17 February 2015 (UTC)

Oppose (vandal fighter)

1. Oppose. I understand the motivation here, but I don't think this solves a necessary problem. Even assuming that we need more people capable of blocking obviously disrupting IPs and throwaway accounts (and I'd like some hard data regarding backlog rates at, say, RPP or AIV on that issue), the sort of accounts and IPs that this is intended to target frequently necessitate longer than 48 hour blocks, which means this doesn't actually save administrators an action except in fairly narrow cases. Also, the ability to apply even temporary semi-protection is fairly significant, since it restricts access from good-faith IP editors as well; the implications of this might best be reserved for those who have demonstrated more community trust than needed for the current "vandal fighting" tools like rollback. But, perhaps most importantly, I don't think this is likely to be technically feasible. My understanding of the mechanics of the project holds that in order to create a (semi-)protection level that this right can interact with, without granting the ability to interact with that protection level in general, would require creation of a new protection level (mini-semi-protection, or something). Likewise, something similar would be needed to create blocks that can be issued and undone by this user right without permitting interaction with "real" blocks (if that is even deemed possible to implement, as there are not, so far I am aware, "block levels"). A marginal net gain for substantial software development cost is not something to get hopes up about being implemented. Squeamish Ossifrage (talk) 02:28, 22 January 2015 (UTC)

   For what it's worth, Jack McBarn and others seem pretty sure that this is technically possible and feasible. Oiyarbepsy (talk) 03:20, 22 January 2015 (UTC)

   It saves editors having to chase around vandals while an AIV reports sits there at 4 a.m. EST when most of the North American admins are asleep. It might not save an admin action but it stops disruption quicker. --NeilN ^{talk to me} 03:35, 22 January 2015 (UTC)

2. Oppose. At the time this was proposed at the idea lab, I noted several problems. As well, there was a discussion at Wikipedia talk:Blocking policy#Duration of blocks that is illuminating.
   • Having a group that can block only IPs and non-autoconfirmed accounts creates (or exaggerates) a power disparity in any conflict involving new (or unregistered) editors and more established accounts.
   • Most blocks of IPs and non-autoconfirmed accounts are for periods of time much longer than 48 hours (as are most semiprotections). This leaves a trail of incomplete tasks that regular admins may or may not eventually clean up.
   • Blocking vandalism-only accounts for just a little while doesn't actually work very well. A significant fraction of them come back (days or weeks later) to make more of a mess. Some of them will be autoconfirmed at that point. Virtually none return to make positive contributions (it's far easier, and more sensible, for them to create a new, clean account).
   • We actually don't do a good job of blocking vandalism-only accounts. Issuing short-duration blocks means that even the vandals that we catch once will still get one or more chances to do damage after their blocks expire.

     In other words, this toolset is likely to encourage newbie-biting while failing to effectively deal with vandals. (It just creates double the effort for each administrative action—once from the baby admin/"vandal fighter", and then again from the real admin who has to review the situation and issue a block/protection of adequate duration.) Also, what's with the "vandal fighter" name? It reminds me of the early WP:Counter-Vandalism Unit and its paramilitary ranks, badges, and officious obnoxiousness. We're not fighting a war, we're writing an encyclopedia. TenOfAllTrades(talk) 03:50, 22 January 2015 (UTC)

3. Oppose - At least until the requirements for granting are tightened up substantially. I didn't even have to dig through the history - looking at AIV and RFPP right now, I see bad reports (no vandalism since final warning, not enough vandalism to justify protection) by users with rollback and reviewer rights. Like the AFD stats tool used on RFA, I'd like to see something similar for AIV/RFPP to make sure that the people requesting the right actually know when it should be used. Simply knowing what vandalism is (basically the requirement for rollback/reviewer) does not indicate sufficient understanding of the block/protection policies. Mr.Z-man 05:00, 22 January 2015 (UTC)
4. Oppose I must admit this is better than a lot of unbundling proposals I've seen, but I have a few issues with it:
   • Granting the ability to block anyone, ever should be a community decision, not a single admin decision (ironic, an unbundling proposal that would actually give admins more power)
   • My standard objection to most unbundling proposals: The admin tools form a kit. Giving only some of them to some users will mean they can only deal some of the problem. Deletion, blocking, and protection are all tools used by admins specifically to combat vandalism. If you don't have any one of them you will inevitably have to go find an actual admin to finish the job. Why have two users doing something that one admin could easily do in a matter of just a minute or two?
   • Applying PC protection to an article for 48 hours or less seems silly. In my opinion and I believe in practice, PC is generally more for long-term problems, semi is for short-term ones.
   • Most actual vandals get indef blocked. Having them automatically unblocked after two days gives them an easy way back, and then a real admin will have to deal with that, so what's the point?
   • Rollback and even PC reviewer are low-level content tools. Judging whether a using them responsibly is only one of many prequisites for more powerful tools, and all these tools, even with these time limits, can easily be abused if granted to users who aren't really ready for them.
   • And finally, I don't see any concrete evidence that this is something we actually need. Beeblebrox (talk) 23:49, 22 January 2015 (UTC)
     • "Granting the ability to block anyone, ever should be a community decision" - What? Users get blocked constantly without any community input at all. Oiyarbepsy (talk) 05:05, 23 January 2015 (UTC)

     Yes they do. By people who were granted the right to block through a community based process. Beeblebrox (talk) 06:31, 23 January 2015 (UTC)

5. Oppose WP:RFA is thataway. If you feel like the community can trust you to block people, then go and ask them to let you do so. --Jayron32 01:08, 23 January 2015 (UTC)

   What do you suppose are the chances of me getting full admin rights so that I might better help fight vandalism? Absolute zero. Something like this, far from a shoo-in but a lot better chance than that. How much do I want full admin responsibilities? Not in the slightest. ―Mandruss ☎ 02:13, 23 January 2015 (UTC)

   Mandruss: based on what I saw while reviewing your request for rollback rights today, you have a much higher chance of passing RfA than absolute zero. You may not want to be an administrator, but I don't see why an RfA would be that contentious in your case. —Tom Morris (talk) 04:32, 24 January 2015 (UTC)

   It would be contentious because I've created exactly zero articles (despite the fact that the required skill sets are very different). It should be contentious because I'm eminently unprepared for that job. But I'm more than capable of handling this new right, and there are a lot more like me around. Anyone who opposes because of the potential for damage by abusers of the right, who says that downside is likely be greater than the upside, is making a very negative statement about the Wikipedia community over all. I'm not prepared to make that statement. I know Jimbo wouldn't. Adequate vetting is the answer to any such objections, and it could include elements that have not been used before, such as interviews and references. In other words, the evaluation for this right could be, and should be, somewhere between rollback and RfA. ―Mandruss ☎ 17:38, 24 January 2015 (UTC)

   So you admit you are "eminently unprepared" for the right to block people, and for that reason you are arguing for the right to block people to be given to you because you ask for it. That makes total sense. --Jayron32 02:51, 28 January 2015 (UTC)

   Sorry I wasn't clear. I meant (and thought I said) that I am unprepared for adminship in its entirety. We're talking about a small subset of that for this role, and what I don't already know I could easily pick up in a few hours (this goes to the "summary page" that I suggested in my !vote). And I would have enough sense to tread lightly at first. ―Mandruss ☎ 03:23, 28 January 2015 (UTC)

   There is no userright MORE contentious than the right to block people; arguably it is that right alone which requires RFA; arguing to lessen the restrictions on that one right probably is the lest likely to pass (not that any of them would pass). Protection and deletion can be undone without the social harm caused to editors because of their misapplication. A bad block can ruin a good editor for life. So, if you're looking for a tool to be unbundled from the admin package, you've probably picked the absolute worst one to argue for. --Jayron32 03:25, 29 January 2015 (UTC)

   • It would be contentious because I've created exactly zero articles (despite the fact that the required skill sets are very different). is exactly why I haven't run as well. — {{U|Technical 13}} (e • t • c) 18:39, 24 January 2015 (UTC)

   • I've written some articles (I have a GA and two upcoming DYKs), and I would like to do more work with content, if I can find other topics that have good coverage in other sources (which is becoming increasingly difficult). While the role of content workers/creators is indisputably very important, I still don't understand those who think it is necessary to become an admin. After all, if all the anti-vandals left, the content creators would be on their knees begging them to come back, as they wouldn't have time to create any content if they were forced to constantly protect their articles. --Biblioworm 18:50, 24 January 2015 (UTC)

   I suspect admins, over all, have a very cynical view of the community because they see the worst of us on a daily basis, like cops. Dear admins, your view of reality is skewed. ―Mandruss ☎ 21:37, 24 January 2015 (UTC)

6. Oppose, blocking is too contentious. Guy (Help!) 01:47, 23 January 2015 (UTC)

   @JzG: @Jayron32: The right to block people in general is contentious, but the block right in this proposal is limited to clear-cut, indisputable cases of "obvious spam and vandalism" after sufficient warning is given. It cannot be a block on a suspected sock or on an editor with potential malice, but must be one a user that any impartial editor would agree is a vandal. The "vandal fighter" right would be immediately removed if it is ever used beyond that scope. Thus, the right being discussed here is not equivalent to or as contentious as the block right that admins have. (Pinging others who this reply is also intended for: @Hobit:@RightCowLeftCoast:@-revi:@WilyD:@Philg88:) Tony Tan⁹⁸ · talk 01:49, 1 February 2015 (UTC)

   The software does not recognize who is being blocked; it only allows someone to block or not block. While we tell people they cannot use the power for X, Y, or Z, they still have the technical ability to do so, which is the problem here, and why one must go through RFA. The software does not recognize the difference between contentious and uncontentious blocks, and a badly placed block by someone with an axe to grind does FAR more damage to Wikipedia than does a vandal who waits 5 extra minutes for an admin to respond to an AIV report. --Jayron32 01:54, 1 February 2015 (UTC)

   It is true that the software does not recognize this, but users (admins & non-admins) do. The vandal fighter right could be immediately removed by any admin if there is any usage beyond blocking obvious vandals (which could be reported by anyone), leaving no room for the abuser to "explain" or "justify" their actions. (The user they blocked is either an indisputably obvious vandal or not.) Any vandal fighter may undo the blocking actions of another vandal fighter as well, to minimize potential harm. Plus, vandal fighters would only be able to block users that are not autoconfirmed. Tony Tan⁹⁸ · talk 02:15, 1 February 2015 (UTC)

   You can't put the toothpaste back in the tube here. The badly-placed block has done its damage that no unblock can later undo. The social injury from blocking someone who didn't deserve it is far more damaging, and cannot be undone, regardless of how soon they are unblocked, and whether or not the blocker get's their rights revoked. That's why we require RFA: the community needs to trust the person who gets the right to block enough to not screw it up. Because bad blocks are bad forever. --Jayron32 03:29, 5 February 2015 (UTC)

7. Weak Oppose, I agree with JzG. Weak only because I don't deal with vandalism on a regular basis and I'm unsure how badly it's needed. Hobit (talk) 03:49, 23 January 2015 (UTC)
8. Weak Oppose, per reason given by Jayron. The power to block is a huge power, one that I am even concerned that some Admins have power to use. If some editor were to be given that power, they should have to go through a RfA like process, stronger than the request for permissions preocess. Therefore, unless such a vetting process is created, I cannot support this proposal at this time.--RightCowLeftCoast (talk) 06:40, 23 January 2015 (UTC)
9. Oppose What's the differences with sysop? It is too powerful (especially blocking). — Revi 07:27, 23 January 2015 (UTC)
10. Oppose: Largely as per Beeblebrox's arguments above, but the last paragraph of TenOfAllTrades's contribution expresses something important about the potential negative consequences. AllyD (talk) 07:39, 23 January 2015 (UTC)
11. Oppose - anybody trusted with this would pass RFA, so this is just more of the "RFA is difficult, so let's have two!" silliness. And, of course, labelling someone a "fighter" is just an open invitation to ignoring WP:NOT#BATTLEGROUND. WilyD 10:01, 23 January 2015 (UTC)
    • Not strictly true, if they have little content creating experience but are an experienced anti-vandal patroller, they stand no chance of passing an RfA. Lukeno94 (tell Luke off here) 13:27, 23 January 2015 (UTC)
12. Oppose gamification of blocking and risk of even more drama and contention among established users (who are left to argue over and vet these blocks and their use/abuse) is too high. Alanscottwalker (talk) 14:03, 24 January 2015 (UTC)
13. Oppose - As per Beeblebrox and TenOfAllTrades. Since the vandal-fighting powers of vandal-fighters would be limited, actual vandals would find ways to game the system and get a second chance. Robert McClenon (talk) 01:58, 24 January 2015 (UTC)
14. Oppose - as it stands now. Reiterating what's said previously, the requirements are very weak. Both the userrights rollbacker and reviewer are the easy come, easy go userrights. IMO, much stricter requirements are needed. Elockid ^(Talk) 02:11, 24 January 2015 (UTC)
15. Oppose - ansolutely 100% per Beeblebrox who has once again beaten me to a discussion , saving me from having to do the typing. And thanks also for the analogy by TenOfAllTrades and reminding us how I finally cleaned up the camp-fire and badges brigade activities at the after-school activities hut. More to come in the 'Comments' section below. --Kudpung กุดผึ้ง (talk) 07:26, 24 January 2015 (UTC)
16. Oppose - we rightfully require a good deal of community scrutiny before providing an editor the responsibility of using the blocking et. al. tools. Anyone who's earned the trust of the community to be blocking other editors needs to be given the trust to do so effectively; we're short admin-time enough without adding the burden of having to vet "mini-admin" actions. NE Ent 13:48, 24 January 2015 (UTC)
17. Oppose' Ability to block and unblock is a crucial part of admin tools. If anyone meets the required criteria for vandal fighter, I presume he'd most likely pass an RfA as well. In simple words: there ain't any need to create further complexities. Ethically^Yours! 14:41, 24 January 2015 (UTC)
18. Oppose The ability to block can be very damaging and should require that the editor is scrutinised by the community before being given the right - i.e. by RFA or equivalent. As noted by others, being able to block ips/new users only will be divisive, and will potentilly drive off editors who could be redeemed or have been caught in the backlash of a bad block.Nigel Ish (talk) 14:50, 24 January 2015 (UTC)
19. Oppose, after giving this more thought. I can see this discouraging non-autoconfirmed good faith editors or "vandals-that-eventually-become-constructive" editors if they get a block on their record during the time they are not autoconfirmed. That clean block log is like a perfect score on a report card, and ruining that report, no matter what the circumstance, is something that should only be trusted in the hands of an administrator. Steel1943 (talk) 16:38, 24 January 2015 (UTC)

    Since vandal-fighter blocks would have to be different on some level in the software (to allow other vandal-fighters to undo them, but not sysop blocks, if nothing else), it could be possible to purge such blocks from the log if an admin does not endorse them, either after some period of time or upon request after the user has mended their ways. If an admin does endorse them, they would become sysop blocks and would remain in the log. Vandal-fighters would not need the power to permanently ruin the clean record you mention. Pathore (talk) 02:32, 28 January 2015 (UTC)

20. Oppose per Beeblebrox - Being blocked can ruin your chances of becoming admin so it should be done carefully, Personally I think it's best we stick to RFA as that way there wouldn't be any wars nor blocks. –Davey2010^Talk 21:04, 24 January 2015 (UTC)
21. Oppose - Completely wrong headed. Officially - for any of the good, sensible reasons set out elsewhere in this section. Leaky Caldron 21:11, 24 January 2015 (UTC)
22. Oppose: The main tools available to nonadmins are tools that (when used correctly) have no potential to be contentious. PC reviewing and rollback are for more effective frontline stoppage of obvious vandalism, not discretionary action. Blocking and protecting, tools that have the most potential to be incendiary, should only be performed by those who the community has determined have the tact and cluefulness to be able to do so, not those determined by Joe Admin who happened to be clearing the RFPERM backlog that day. The short-term nature of the actions doesn't mitigate the discretionary nature of the tools. Deadbeef 07:17, 25 January 2015 (UTC)
23. Weak Oppose - I support such a right on paper. I feel that it's a decent idea. But WP:PERENNIAL sums up what I think. The people qualified for such tools should might as well just go for full adminship. Narutolovehinata5 ^tccsdnew 09:41, 25 January 2015 (UTC)
24. Oppose Our biggest issue is retaining new editors relaxing the requirements and increasing the number of people who can do this through the creation of yet another subset of editor rights is fraught with danger of increasing the biting of new editors so with out some documented imminent disaster to avert I dont see a need Gnangarra 11:54, 25 January 2015 (UTC)
25. not a good use of our time per above --Guerillero | My Talk 22:34, 25 January 2015 (UTC)
26. Oppose Per Guy. If we're unbundling some admin rights, blocking should be the last one to be considered, not the first. BMK (talk) 22:41, 25 January 2015 (UTC)
27. Oppose blocking, but would support unbundling a limited form of semi-protection. That's a lot less confrontational than blocking, and can solve an issue while leaving blocking to an admin. Courcelles 23:49, 25 January 2015 (UTC)
28. Oppose, though i fully understand the purpose and motivation and, indeed, was immediately attracted towards supporting the proposal. There are, however, too many reasons that this is not good for the community/encyclopaedia for it to actually become reality (in no particular order):
    • Blocking is something that should only be done by people vetted by the community (RfA);
    • The suggested criteria for obtaining the right are laughably low;
    • A new user-right like this increases the opportunities for hat collecting;
    • New accounts already get bitten (not always, but sometimes) by vandal-fighters, and we don't need to do anything which makes that more likely and more permanent;
    • I'm not sure that this solves a problem currently requiring a solution ~ we already do a good job of vandalism control;
    • RfA already exists for those users who wish to help out in ways they cannot currently. Cheers, Lindsay^Hello 04:27, 26 January 2015 (UTC)
29. Oppose Blocking is highly contentious and I don't feel it should be in the hands of users who were screened and approved by a single administrator. It should be as said above, a community decision. Those who routinely look at WP:AIV, will tell you that a great portion of block requests are not appropriate and often come from editors with thousands of edits. Blocking is not a place where these types of mistakes can occur at such a high degree. Mkdw^talk 00:21, 27 January 2015 (UTC)
30. Oppose In theory it seems okay... but anyone who can block and protect pages can cause substantial damage, regardless of the said limitations. I wouldn't want to issue that right to anyone without community input. If anything it'd have to work like obtaining the abusefilter right, where the request must stand for a full week to allow for anyone to object before granting the right. Then consider all the drama that's going to come with this. You're going to have unconfirmed users running to admins complaining of some vandal fighters misconduct. Meanwhile newcomers might get confused who they're supposed to talk to about blocking and page protection, or confuse vandal fighters for admins altogether... then you'll see vandal fighters responding to reports at AIV and RFPP... just seems like the added bureaucracy is going to do more harm than good. Getting admin attention shouldn't be that hard, and if it is, let's focus on trying to fix that rather than adding a whole new layer of complexity to this user unfriendly environment we work in. If something is very urgent and you're unable to get on-wiki admin attention, consider hopping on #wikipedia-en-help ^connect, type !admin and hit enter. Finally, from a technical standpoint, you're going to need a whole new MediaWiki extension for vandal fighter to work. Good luck with that. — MusikAnimal ^talk 22:36, 27 January 2015 (UTC)

    And +1 to all of TenOfAllTrades's points... especially the argument about incomplete tasks and temporarily blocking vandalism-only accounts. You'll end up with another admin backlog of cleaning up what the vandal fighters weren't able to do. — MusikAnimal ^talk 22:40, 27 January 2015 (UTC)

31. Oppose as written The proposed "vandal fighter" is effectively a "junior admin" and assignment of such a "training mop" should not be at the mere whim of any sysop. We have RfA and we should use it for any kind of user right that gives power over other editors. I could support some kind of "rapid-response anti-vandalism" role if an actual need were shown, but I think that assigning such a right should still go through RfA. Pathore (talk) 02:18, 28 January 2015 (UTC)

    No complaint here, provided article creation is not a criterion. Article creation is not where my strength lies, and I'd have a serious problem with anyone claiming I don't contribute enough to the encylopedia to be worthy of this role. Hell, my application for the right demonstrates my desire to contribute even more. As for looking at AIV and RFPP contributions, fine, if that will help this pass. And I'll set about hunting down problems to appropriately report, so as to build up my numbers quicker. ―Mandruss ☎ 02:27, 28 January 2015 (UTC)

    That would be more-or-less the idea for a "junior admin (anti-vandal)" role. The problem is that I'm uncertain of where exactly the lines should be drawn, or if creating articles really is an important criteria that I'm just not seeing right now. In any case, specialized junior admins would probably end up expected to branch out, with "junior admin" status becoming a stepping-stone to "admin". I'm not sure if there is any good way to avoid that, or if it even should be avoided. Pathore (talk) 02:42, 28 January 2015 (UTC)

    If I'd be required to state that I'm aiming for eventual adminship, count me out. On other hand, when I fail to apply for admin after years of competent service as JA, you could fire me from JA. Move up or move out. ―Mandruss ☎ 05:39, 28 January 2015 (UTC)

    I didn't propose that. I said that it might end up drifting in that direction, and that I'm unsure how to prevent such a drift. Pathore (talk) 06:17, 28 January 2015 (UTC)

32. Nobody should have power to block without passing an RFA. Townlake (talk) 03:29, 28 January 2015 (UTC)
33. Unbundling the tools may be a good idea; unbundling the block button is not. wctaiwan (talk) 06:38, 28 January 2015 (UTC)
34. Oppose. Allowing the block right without sufficient scrutiny (i.e. an RfA) is a bad idea.  Philg88 ^♦talk 07:32, 28 January 2015 (UTC)
35. Oppose, anybody who can do these things should be an admin. Becoming an admin should be easier, and unbundling more rights does not make it easier to obtain the full rights (it might make it harder, as it might introduce an extra step that will soon be seen as necessary). To make becoming an admin easier, just go to WP:RFA and vote "support" a couple of times whenever RFA is nonempty. —Kusma (t·c) 17:03, 29 January 2015 (UTC)
36. Oppose While I would trust some non-admin users to have these abilities, I don't believe that the proposal addresses the problem that it would duplicate work by necessitating reviews of vandal fighter blocks, requiring admins to check if longer protection is needed, and so on. We need more admins, not baby-admins which real admins have to constantly look after. BethNaught (talk) 17:40, 29 January 2015 (UTC)
37. Oppose I don't see what this would accomplish. It looks like the main difference between this proposal and full adminship is 1. page deletion and 2. longer blocks. If you're granting this for vandal fighting, it would make sense to add page deletion too to help with speedy deletion of obvious vandalism; leaving only longer blocks for admins. At that point, adminship would become nothing more than a status symbol, which it shouldn't be at all. If you want those rights, what's wrong with RFA?~ ONUnicorn^{(Talk|Contribs)}problem solving 21:26, 29 January 2015 (UTC)
38. Oppose - There really isn't (or shouldn't be) a drastic dropoff in the level of competency required of someone with any sort of access to the block button, no matter if you're trusted to block new users for two days or old users forever. Anybody who could be trusted with this new right would stand a respectable chance of successfully running for regular adminship. I'm slightly less opposed to the protection side of this proposal, but I wouldn't consider that part of it workable either. --Bongwarrior (talk) 05:19, 30 January 2015 (UTC)
39. Oppose if you want to block people, go to RFA and get the community's support. Tavix |  Talk  04:21, 31 January 2015 (UTC)
40. Oppose, per Beeblebrox. Ironholds (talk) 04:50, 1 February 2015 (UTC)
41. Oppose. The ability to block anyone for any amount of time (with "any" in the existential rather than universal sense) is too much without having gone through RFA. The mistreatment of anons and new users is what drives many potential editors away. -- King of ♥ ♦ ♣ ♠ 05:18, 1 February 2015 (UTC)
42. Oppose - Great idea with a few tweaks, but it appears we can't tweak it. Therefore we should kill this ASAP so we can move on to the next try. (What is the minimum rest period between tries?) ―Mandruss ☎ 03:50, 5 February 2015 (UTC)
43. Oppose - After further thought and some of the above comments, if you can be trusted with this flag you should be able to pass a RfA. Mlpearc (open channel) 04:28, 5 February 2015 (UTC)
44. Weak Oppose. It's an excellent idea, and I'd very much like to see this pass, however instead of Vandal fighter rights would be granted by administrators after requests at Wikipedia:Requests for permissions and something less serious than RFA, but I do think there should instead be some sort of community discussion, per user, in a dedicated discussion subpage, instead of decided by another single individual for promotion. — Cirt (talk) 20:01, 5 February 2015 (UTC)
45. Oppose - Yes, me, a vandal fighter, opposing this very idea. This simply is an example of Wikipedia:Perennial_proposals#Hierarchical_structures, and it doesn't exactly resolve all issues with anti-vandalism. For instance, as mentioned many times, even the most experienced of non-admins make bad WP:AIV reports. Giving such editors the power to block editors would result in a lot of unfair blocks over editing disputes (which AIV is not for yet people still go there to complain. I've seen it myself.). Secondly, if a vandal fighter blocked a vandalism-only account for 48 hours, they would need to go back and file a second report to ask an admin with full powers to extend the block to indefinite, as this is the general practice for vandalism-only accounts -- an indefinite block. This would be a lot more tedious and increase the workload of editors and administrators as they now have to hunt down vandal fighter blocks and extend them appropriately. It would be better to just report at AIV and monitor the user until an admin can drop the hammer and end the whole argument completely. Thirdly, if there is a page under attack, my advice is to get Huggle 2, which automatically updates, so just point it at the page that's under attack and revert malicious edits instantly until an administrator sees your RFPP request (which you should have filed, like any good editor should, ahem). Alternatively, if you are patrolling recent changes and you see an administrator editing (but not monitoring RFPP or AIV so they don't see your request) you can poke them on their talk page. I did that once during a spambot-attack on a page, which was dragging on a bit too long (but thanks to Huggle 2 it was very manageable). Poking an active administrator did the trick fairly well, and was faster than RFPP. It might not be the most practical idea, but it works to an extent. And fourthly, if you can be trusted to block an editor, protect a page, delete a page, and set pending changes protection, consider running for RFA. One of these days. --I am k6ka ^{Talk to me!} _{See what I have done} 14:05, 6 February 2015 (UTC)
46. Oppose Fundamentally because I believe anyone who I would trust to receive this ability I would also trust to be an admin. Alos the specific objections by TenOfAllTrades and Beeblebrox are persuasive. Davewild (talk) 17:09, 6 February 2015 (UTC)
47. Oppose tl;dr, another level of bureaucracy, this wiki needs more workers, not more coppers...--Stemoc 01:42, 7 February 2015 (UTC)
48. Oppose Partly because there is the problem of what IS vandalism? I'm more of a janitor than a cop, but I see quite a lot of "that's not vandalism, that's content dispute" at AIV. Content dispute can also become vandalism, but not always. Partly because I disagree strongly with the right to block for any length of time (meaning 'whatever length of time' is decided) being given out by any single admin. Per K6ka above, if you can be trusted with those rights, you can be trusted with a mop - and I don't think that a whole stack of articles created is a necessity for that. Working with the existing content of articles is just as good to my mind. That's somewhat irrelevant here, anyway. Otherwise, per Beeblebrox et al. Peridon (talk) 19:54, 7 February 2015 (UTC)
49. Strong Oppose We actually don't need such user right as we have ClueBot NG, Huggle, STiki, and other tools that can fight vandalism. Users could manually revert vandalism by simply clicking Edit on an article or you could just use Twinkle to revert vandalism and unambiguous promotion or advertising.
    Admins could block users indef for vandalism or promotion as well. Also, what if you want to participate in AFD's or make constructive edits as I did on Crips? That would be abusing the vandal fighter right and bureaucrats could revoke it, so why revoke a simple right just for making constructive edits if they flag it as abusing it? That would be downright obnoxious, wouldn't it?Snowager (talk) 03:06, 9 February 2015 (UTC)

    I think you're misunderstanding the proposal a little. It doesn't mean that people with the right would be prohibited from doing anything but anti-vandal work, just they could only use blocking and protection for that. They wouldn't be allowed to block users for things like edit warring. Mr.Z-man 15:20, 9 February 2015 (UTC)

50. Oppose The ends do not justify the means. It would only be helpful for a handful of cases, and has potential to be abused in content disputes. Acebulf (talk) 18:49, 14 February 2015 (UTC)
51. Oppose Nominate for adminship anyone who signs up for this right. We need more of those and the level of trust would be virtually the same. --RacerX¹¹ Talk to me^{Stalk me} 18:29, 15 February 2015 (UTC)
52. Oppose It makes no sense to issue only a short temp block to a blatant vandalism-only account, especially in cases where the account name is clearly abusive. Furthermore, access to the blocking tool is a contentious matter, and inappropriate blocks clearly have the potential to cause emotional damage to good faith contributors. Therefore, the decision to hand out the blocking tool to a particular user is one that must be made by the entire community. --SoCalSuperEagle (talk) 19:26, 15 February 2015 (UTC)
53. Strong oppose - anything with "vandal or "fighter" in the name. (see: WP:BATTLEGROUND). And 48 hours is way too long. For this, maybe 12 hours at most, and really leaning towards 1 hour at most. As for unbundling, while I agree that those who moderate discussions and the like may have a different toolset than those who may choose to "police" the wiki. (see WP:MOD.) I think that if you're going to have the ability to block someone, you should have all the tools available to make informed decisions. And I will oppose giving the ability to unconditionally block to anyone who cannot also view deleted for that same reason. This is why I proposed the split of the toolpackage in the other direction. - jc37 12:09, 16 February 2015 (UTC)
54. Strongest oppose: The ability to block or protect should only be given to highly trusted users. If a editor is trusted enough to be granted vandal fighter rights, then that editor should be trusted enough to become an admin. Erroneous blocks or blocks intended to give the blocking editor an advantage (say, in an edit war) can lead to a would-be precious editor leaving the project. Erroneous protections prevent IP editors and unconfirmed editors from legitimately making edits for little reason. Also, this adds complication to the user access level structure. If this user (privilege) is implemented, it should have stricter requirements (my suggestions are below):
    1. 1 year on Wikipedia.
    2. 2,500 mainspace edits.
    3. No recent cases of biting, incivility, or personal attacking.
    4. But overall, no. Esquivalience ^t 02:46, 18 February 2015 (UTC)

Discussion (vandal fighter)

@Oiyarbepsy: In my original idea, vandal stoppers could indefinitely block users who are registered but not autoconfirmed, so that admins wouldn't have to reblock all vandalism-only accounts. Was this change on your part intentional? Jackmcbarn (talk) 00:51, 22 January 2015 (UTC)

@Jackmcbarn:It was not. I misunderstood. I'll can revise if you like, but I like the 48 hour idea better. That way, admins are only necessary for those who come back after their 48, which I suspect is a small minority. Oiyarbepsy (talk) 00:58, 22 January 2015 (UTC)

@Oiyarbepsy: I would like that to be revised. While it's true that admins would only be necessary for those that returned with the limit, they wouldn't be necessary at all without the limit. Jackmcbarn (talk) 01:01, 22 January 2015 (UTC)

If this passes, and after being in place for a month or two, we can change it. Best to start out kind of conservative. Oiyarbepsy (talk) 03:19, 22 January 2015 (UTC)

@Oiyarbepsy: I note that a lot of oppose reasons mention that vandalism-only accounts would get unblocked after 48 hours, which would be bad. Would you consider changing it now to alleviate some of them? Jackmcbarn (talk) 01:24, 23 January 2015 (UTC)

@Jackmcbarn:I'm gonna be honest, I don't think changing that would alleviate anything. The opposers who mentioned that had it as one small item in a laundry list, and I frankly think that change would change anyone's mind. Also, I'm not entirely comfortable to let non-admins block users essentially forever, and it's certainly better for vandals to come back with their original account rather than sock puppets. Finally, enough votes have been made that changing it now would generate a lot of confusion of what exactly people are supporting or opposing. Oiyarbepsy (talk) 05:08, 23 January 2015 (UTC)

• (edit conflict) Comment/question: Could someone explain to me how this proposal's function would be technically possible? I mean, from what I understand, there is a drop-down menu that administrators can use to select how long an editor is blocked for, and as far as I know about this, that cannot be adjusted for a special new user right. (However, I bet improbably wrong, and there's probably some way to edit a page in the "MediaWiki" namespace to allow only certain timeframes to this user right.) So ... can this be done? Steel1943 (talk) 01:03, 22 January 2015 (UTC)

  @Steel1943: This will require software changes to implement, which I plan to start work on once this proposal is closed (assuming it passes). Jackmcbarn (talk) 01:05, 22 January 2015 (UTC)

• @Jackmcbarn: That's what I suspected. It's possible. I was, more or less, wondering since if the only option to make the software allow non-admins the option to block other users would give the non-admin access to the "indefinite block" option, then this would seem more like a tool-unbundling request (and I think that enough of the admin toolset is unbundled already.) Steel1943 (talk) 01:12, 22 January 2015 (UTC)
• Jackmcbarn, please add me as a gerrit reviewer and CC me on the Phab ticket when you're working on this. Thanks. — {{U|Technical 13}} (e • t • c) 01:25, 22 January 2015 (UTC)

Just to be clear, I don't interpret this as meaning the right-holder would be expected to spend most of their time fighting vandalism. I would simply use it to save myself and admins some time, while cutting off the offender sooner, when I run across a vandal while in the usual course of editing business. If that's not the intention, I would still support but wouldn't apply for the right. ―Mandruss ☎ 01:34, 22 January 2015 (UTC)

That's the intention. Jackmcbarn (talk) 01:39, 22 January 2015 (UTC)

Given that the bars for rollback and PC reviewer aren't that high, I'd like to consider more stringent qualifications, like a demonstrated track record at AIV & RFPP to the granting admin's satisfaction. It would require a little bit more due diligence but given the level of access I think that's OK. I also think the name is a little too bombastic; my first thought was "patroller" but that's already used elsewhere. Regards, Orange Suede Sofa (talk) 01:58, 22 January 2015 (UTC)

That would probably count me out. I've hit AIV once (appropriately) and RFPP once (appropriately). Not much of a track record. But I would still be a very good vandal fighter and I certainly know the difference between a clear vandal and a disruptive editor. ―Mandruss ☎ 02:08, 22 January 2015 (UTC)

Right now there are two AIV boards - one for humans and one for bots. Can a third be added that would contain entries that would automatically be added when a vandal stopper blocks someone? Admins could review this board and lengthen blocks if necessary or remove these rights if an incorrect block was made. --NeilN ^{talk to me} 03:41, 22 January 2015 (UTC)

There will be something like that. Jackmcbarn (talk) 03:44, 22 January 2015 (UTC)

Why not give them full blocking ability, only to be used on vandal accounts. Just like roll back can onlt be used in certain situations. Any abuse or use out of scope can be dealt with by removal of the right. It would be much easier to implement and understand. Sincerely, Taketa (talk) 03:55, 22 January 2015 (UTC)

FWIW, I intend to be one of the closers. Similar discussions happen roughly once a year, and I can't detect a pattern; every discussion has had different voters and closers. The most common question for closers is whether we're going to settle it by vote-count or by weight of the arguments ... I can't speak for anyone else, but the best I can tell, most closers approach it the same way. We don't want to take away people's right to speak up and be counted, so if there are a bunch of votes in either direction, that side is going to get the nod ... unless there's a credible argument that people are voting multiple times or being canvassed, but so far, that's never been even a factor. If it's not clear from the numbers which way to go, then we look hard at the arguments ... not with the intention of nullifying votes, but with the intention of listening to what the voters are really asking for. We can't assume that any "no" vote to a new user-right implies that voter wants to see Wikipedia go over a cliff, nor can we assume that a "yes" vote means the voter wants the new user-right to stay in play even if it's not working out. Here's some free advice to both sides: make your case. Present some data. Present some good arguments. Some Wikipedians are kind of dug-in on these issues, but many aren't, and most will listen to you if you listen to them and make your case. One last thing: please check back at the 30-day point or whenever the RfC has run ... if it's not clear which way the RfC is going to go, it would really help if we (the closers) could ask the voters to clarify what you meant or what kind of compromise you'd be willing to settle for. - Dank (push to talk) 04:39, 22 January 2015 (UTC)

Suggest that we have clear rules for removing this access such as with other advanced permissions, including for inactivity or for any actions that lead to a block. — xaosflux ^Talk 04:30, 22 January 2015 (UTC)

Strongly agree here. We should remove for inactivity for the same reason as for admins with the option of giving it back when they return. I think most under-a-cloud type removals ( wheel warring, abuse, careless use that causes too much work, etc. ) should remove the ability to get this right back except for getting the equivalent powers by passing an RfA and becoming an admin. PaleAqua (talk) 01:59, 23 January 2015 (UTC)

Without commenting on the substance of this package, can we please lose FIGHTER from the name. Fighting terminology is not very helpful or welcoming. Patrollers, Blockers, Fixers, Minions, .. open to any other suggestions.. but nothing aggressive please. -- zzuuzz ^(talk) 12:33, 22 January 2015 (UTC)

Antivandal ―Mandruss ☎ 12:42, 22 January 2015 (UTC)

That's what I was thinking. It sounds more professional than most of the other ones. --Biblioworm 13:09, 22 January 2015 (UTC)

How about sergeant-at-arms? Personally I don't like the word "vandal" in the name any more than I like the word "fighter" - it just sounds deliberately confrontational. Ivanvector (talk) 16:55, 22 January 2015 (UTC)

Another closer note: even if the vote is 100 to 5 to to approve "vandal fighters", that doesn't mean it's not possible to call them anything else ... it's reasonably clear that people are supporting the creation of a role, and not necessarily every detail of the proposal. That's another reason it would be helpful for people to stick around at the end of the RfC, to work these things out, if needed. - Dank (push to talk) 20:44, 22 January 2015 (UTC)

I have no opinion about the current specific proposal as advanced for the purpose stated, but just want to comment that this is just the most recent attempt to create a user group holding a subset of the rights currently held by administrators. The proposal has, in the past, most frequently been advanced a form of trial period or apprenticeship as one of the various methods advanced to fix or replace the RFA process. Something like it was also advanced as a means of controlling incivility at disputatious article talk pages. The community has, up until now, never supported these ideas. While I express no opinion about the current proposal for its stated purposes, I support it as a form of creating "junior administrators" for the purpose of working around the current RFA system. Because my support is not for the stated purpose of this proposal, however, I do not feel that it should be considered in evaluating consensus on this proposal unless the "junior administrator" purpose is substantially advanced as a reason for this user right change in addition to its current stated purpose. Regards, TransporterMan (TALK) 15:27, 22 January 2015 (UTC)

In the user-rights RfCs, closers have been asked to comb through all the comments to see if there are people who actually supported or opposed but didn't record a vote in the proper section. I'd appreciate it if you could talk a little more about what you'd like to see happen with this proposal; I can't quite tell if you're supporting, even though you say "support". - Dank (push to talk) 16:07, 22 January 2015 (UTC)

• "Anti-vandal patroller" could be a decent alternative if people have issues with the name (zzuuzz alluded to it in their comment above). I don't think there are many sensible names for this type of userright that don't include "vandal" somewhere; as cool as sergeant-at-arms may sound, or something like Keeper of the Peace, they aren't the most self-explanatory things (although that being said, nor is autoconfirmed!) Lukeno94 (tell Luke off here) 21:06, 22 January 2015 (UTC)
• I have to agree on the name. While it is an accurate description of what the package would be for, it seems overly confrontational. Beeblebrox (talk) 00:47, 23 January 2015 (UTC)
• I like the idea of referring to the proposed user right as a "Housekeeper" right. That's exactly what they'll do. They'll keep the house, and clean-up simple messes on a day-to-day basis. RGloucester — ☎ 01:06, 23 January 2015 (UTC)
• Something vague like sentry could work. But as has been mentioned, the choice of name is really a separate issue and shouldn't bear on one's !vote, and it could easily be a separate discussion. As we all know, getting hung up on details is what kills far too many proposals. For purposes of this discussion we could say rightX or something and get on to more important questions. Any takers? ―Mandruss ☎ 01:14, 23 January 2015 (UTC)

Changing the proposal to a "right X" for the time being seems appropriate, allowing it to be resolved later. I really am fond of the cleaning analogy. It is meaningful without being antagonistic. RGloucester — ☎ 01:16, 23 January 2015 (UTC)

I didn't mean to have implied that I would not support based on the name. I support the proposal, full stop. You can change the name to "bloodthirsty vandal-murdering gravyweasel" and I'll still support it on principle. (but please don't) Ivanvector (talk) 20:10, 23 January 2015 (UTC)

• Question Would the user have to have rollbacker and pc reviewer already, or simply meet those requirements? KonveyorBelt 01:27, 23 January 2015 (UTC)

Since no one is rushing to answer this, I'll offer my take. It says, Rights would only be granted to user who meet the requirements of both roll back and pending changes reviewer. I'm taking that literally. If rollbacker and pc reviewer were prerequisite rights, I assume they would have said that instead. The writer seems articulate enough. FWIW,―Mandruss ☎ 08:02, 23 January 2015 (UTC)

• Questions. This would obviously need software changes, so do any developers here know how likely it would be to get the resources to do it, and would such software development require the WMF's approval? Squinge (talk) 09:14, 23 January 2015 (UTC)
  • User:Jackmcbarn has already offered to do it. I think we can implement new user rights named rblock and rprotect (as in "restricted" block and protect) that allow users with this right to block and protect only within a specific timeframe defined in a wg variable. Zhaofeng Li [talk... contribs...] 09:21, 23 January 2015 (UTC)
    • OK, thanks! Squinge (talk) 09:54, 23 January 2015 (UTC)

Comment – I hate to say it, but it isn't fair that the majority of you are sysops who may look at it differently because you had to go through RfA. This isn't really fair. You all act in good faith, but it really is bad to see the lack of user distribution between admin and non-admin users on the oppose vs support. Some of you bring up legitimate concerns, yes, but some of you don't. Dustin (talk) 03:50, 23 January 2015 (UTC)

How is it not fair for us to oppose something? You can say some of us are wrong, or don't make good points but that doesn't make it "unfair".

I would suggest that you consider the fact that admins who got their tools post-2007 managed to make it through a very difficult process that, despite it's flaws, is designed to weed out those who do not have suitable levels of policy knowledge or the wrong attitude to be going around blocking other users. And even then, we still sometimes fail and the wrong person gets the tools. To shortcut that process so severely so that all anyone has to do is find one sympathetic/gullible admin and -bam- they have half the tools themselves and can cause all kinds of trouble with them is frankly a frightening prospect.

Vandal fighting is important and I think most admins really appreciate the work that is done by non-admin users in detecting and reporting vandals, but without a real test of their judgement and ability to keep their cool, such as RFA, we should not be granting powerful tools like blocking and page protection, which prevent users from editing. We get enough complaints about these things when they are done by qualified admins. Letting anyone with a few good AIV reports just start hammering away would be a serious mistake, and would not ease the workload of current admins. In fact it might make it significantly worse with unblock and unprotection requests getting jammed due to a few trigger happy pseudo admins. Beeblebrox (talk) 06:47, 23 January 2015 (UTC)

can cause all kinds of trouble with them - Yes - for all of about an hour, until their right is revoked. Either permanently, or for a very long time. Sorry, but I'm calling hyperbole and alarmism. I can easily produce five or six experienced, respected editors to attest to my integrity and ability to keep my cool. Just say the word. This process should be about fairly and objectively weighing potential benefits against potential costs, not zeroing in on potential costs and blowing them way out of proportion. ―Mandruss ☎ 07:34, 23 January 2015 (UTC)

Blatant abuse isn't really the main problem (IMO). The biggest problem I can foresee with the proposal as-is is misuse due to inexperience/overzealousness. I'm sure any admin who regularly handles AIV or RFPP can attest to the number of non-actionable reports. At AIV: the worst case is users making low-quality, but good faith edits reported as a vandal. At RFPP it's usually just people requesting semi-protection on a page that's only been vandalized twice in the last month, or only vandalized by 1 user. Improper blocks can easily drive away potential new contributors and overuse of semiprotection goes against one of our core principles - that anyone can edit. I think there's a lot of value to the current system in which most vandalism blocks and page protections are independently reviewed before they're done. Reverting a couple extra vandalism edits because a report sat on AIV for an hour is easy. Convincing a good-faith user to give WP another chance after he's mistakenly blocked as a vandal isn't. Mr.Z-man 14:15, 23 January 2015 (UTC)

But anyone can post at AIV or RFPP. Do you even have to be registered? Obviously the admin is going to spend 15 minutes or so looking the candidate over before granting the right, checking out their history, maybe even engaging them in a brief interview or asking for references. I can't imagine enough bad ones getting through that to offset the benefit of the good ones. If they did, we simply raise the bar a little. No reason to oppose here. Nothing like this will be perfect out of the gate. ―Mandruss ☎ 15:07, 23 January 2015 (UTC)

As I said in my comment further up in this section, without even having to look through the history, I found rejected reports at both pages by (different) users who had both rollback and reviewer. You're assuming that admins will do a thorough job, but that's not what the current proposal says they have to do. It says it will be given to people who meet the requirements for rollback and reviewer, which have fairly low standards. Mr.Z-man 15:39, 23 January 2015 (UTC)

Fair enough. @Oiyarbepsy: Any problem with adding something about vetting? ―Mandruss ☎ 15:45, 23 January 2015 (UTC)

I wrote some fairly detailed suggested text for the above (see page history if curious), then decided it would start us down a path of neverending quibbling over details. Could we simply say something like, Reviewing administrator will vet the applicant and may reject, details to be established separately? ―Mandruss ☎ 17:07, 23 January 2015 (UTC)

On the other hand, it was running into semi-protection that finally convinced me to make an account. Pathore (talk) 05:50, 25 January 2015 (UTC)

• I realize it is kind of late for this, but considering the requirements to be added to this group seems to be the biggest stumbling block, I would support removing the criteria all together and see if there is consensus to create such a group with details about acquiring the right to be determined upon completion of this RfC as successful in determining that such a group that can do these things is needed first. — {{U|Technical 13}} (e • t • c) 02:18, 24 January 2015 (UTC)

Seems this could also work well with obvious UPOL violations. Mlpearc (open channel) 05:22, 24 January 2015 (UTC)

• Comment (I've placed my oppose vote in the voting section above). Some of the supporters make some good arguments but the two main objections I have are 1)The hat collecting, and 2) the fact that rather than reduce admin workload, it will increase it. Any admin who has worked the WP:PERM pages, expecially Beeblebrox and I who have held the fort there for years, will be aware of the extent of hat collecting, and grabbing these rights as trophies, and like many admins in fact, once they've got thier bit they tinker with it for a while then leave their new toy aside. If such a right gets created and if it's up to admins to accord it at PERM, there will literally be a stampede for it. If such a right must be subjected to an RfA style debate, then the cadidates should be sufficiently competent to stand a good chance for the mop. Such a right would simply keep the admins on their toes checking on its use, much in the same way that I patrol the patrolers at NPP who ironically for such an important task, need no qualifications whatsover - and it shows. I don't go to AIV much but when I do I linger there to clear up the backlog and I'm frankly staggered by the number of totally incompetent listings - are those from the 'vandal fighters' the supporters want turned into mini admins? --Kudpung กุดผึ้ง (talk) 08:33, 24 January 2015 (UTC)
• Comment. Many in the oppose section complain that this would increase admin workload. (There seems to be blue highlights scattered everywhere in that section; it could just be coincidence, but it might be something else. [Just kidding; we need some humor around here.]) If that is really the case, why is it that the introduction of the template editor right didn't have the same effect? TE and the proposed antivandal right are similar; both unbundle very potent admin tools. For example, a template editor could ruin the appearance of many pages with a single edit, but when that does happen, an admin can simply remove the right immediately. Not to mention that TE has a strict granting standard. So, TE pretty much disproves the argument that people will "stampede" for the right, create a monumental amount of admin work, and create chaos. --Biblioworm 17:19, 24 January 2015 (UTC)
  • The differences between this and template editor, to me at least, are:
    1. TE requires a demonstration of competence through experience with template editing and work on sandbox versions of protected templates. The proposal here requires only that they meet the requirements for rollback and reviewer, which are often given to people with only a few hundred edits and a couple months of editing experience. That these are insufficient requirements should be plainly obvious. Looking at the last few days of rejected requests for SP/PC in Wikipedia:Requests for page protection/Rolling archive, 13 out of 23 requestors had rollback and/or reviewer.
    2. We don't encourage template editors to make bold, unilateral edits to protected templates. The only edits we tell people to make without discussion are fixes to broken markup and edits that don't actually affect the output. So in practice, most edits to protected templates are still discussed in advance. That's kind of the opposite of the intention here, which is to bypass the pre-action independent review at AIV and RFPP.
    3. No one is going to give up on Wikipedia because they saw a broken template in an article, they might if they're mistakenly blocked as a vandal.
  • Mr.Z-man 20:07, 24 January 2015 (UTC)
    • Why, then, don't we get rid of the rollback right and restrict CSD/PROD/AfD tagging to users who have gone through an approval process? If you're new, having your good-faith edit reverted and your article put up for deletion can be very hurtful, but we have generally low standards for rollback and none at all for NPP. If we tried to institute more strict requirements for any of the things I just mentioned, it would be swiftly rejected by the community. The point here is that there are many things that a regular user can do that can drive away new editors. --Biblioworm 20:35, 24 January 2015 (UTC)
      • Yes, there obviously are things that anyone can do to drive away new users, but that doesn't mean we should ignore that as a concern and give them more ways to do it. You don't need special rights to out someone, should we give everyone checkuser too? If you assume every vandal gets 4 warnings before they're blocked, there are 5 times as many vandalism edits to revert than there are vandals to block (probably more when you consider that many stop before they're blocked and many get more than 4 warnings), so we need a lot more people with the ability to revert than we need with the ability to block. And of the 3 main admin tools, page protection is the least used – RFPP usually gets less than 50 requests in a day. Editing protected templates isn't done very frequently, but TE still solved an actual problem in that the vast majority of admins don't actually have the technical knowledge to review edit requests to templates and modules. Don't get me wrong, I'm not fundamentally opposed to unbundling these tools, but absent a demonstrated problem to solve or a proposed process that won't result in users with 1 month of editing experience being granted the ability to block users, there's no way I can support this. "Backlogs" aren't really a serious problem because backlogs are relative. CAT:CSD is considered backlogged when it has more than 50 requests, WP:AIV is considered backlogged when it has more than 5. Mr.Z-man 21:20, 24 January 2015 (UTC)

@Mr.Z-man: The proposal here requires only that they meet the requirements for rollback and reviewer It doesn't seem particularly fair to keep making that argument when I have proposed a solution to it (see "vetting", above) and the proposal is still pending a response. I'll ping Oiyarbepsy again. ―Mandruss ☎ 22:13, 24 January 2015 (UTC)

MandrussI read it again, and I don't understand what your proposed solution even is, aside from the word vetting. Vetting by who and when and what exactly is being vetted? Oiyarbepsy (talk) 02:59, 25 January 2015 (UTC)

@Oiyarbepsy: Sorry if I wasn't clear. Several opposers have cited as one reason the fact that the bar is no higher than that for rollback and reviewer. That seemed like a reasonable concern to me, and I proposed that the reviewing admin perform vetting of the applicant, to a greater extent than they do for rollback and reviewer. I initially proposed some specifics, here, and then decided that specifics would only bog down this discussion and a consensus on them could be reached later. So I proposed a more general statement to be added to this RfC, which is above. If you think something more specific is needed, that's fine, but I feel that some response to the concern is needed. ―Mandruss ☎ 03:13, 25 January 2015 (UTC) Note that I have now added something about specifics below, per Mr.Z-man's suggestion.―Mandruss ☎ 08:01, 25 January 2015 (UTC)

How is it "unfair"? Lots of people have suggested tweaks to the proposal - letting blocks be indef, changing the name, doing a trial period - but until they're incorporated into this proposal or a new one, I can't just pretend that the issue has been solved when the proposal hasn't incorporated the solution. I even tried to clarify my comment by saying "the proposal here" to specify that it only applies to this proposal. But I would disagree with having a proposal with no specifics. How would that even work? Say we agree to create the new group, but can never come to a consensus on standards - then what? Would people who are opposed to the group in general be forbidden from participating in the discussion for standards? Mr.Z-man 04:48, 25 January 2015 (UTC)

Points taken. Ok then, I think the main specific points should be:

• Interview - The admin could discern a lot about the applicant's suitability for the right by asking them some questions. Some of this goes on at Requests for permissions, but it's ad hoc and not a formal part of the process. It could be done on the applicant's user talk page.
• References - Require at least three references. This could be done in either of two ways. The applicant could provide at least three usernames, and the admin could contact each reference on their talk page. Or, the applicant could ask each reference to post a statement with the request for permission. The main thing here is that the admin should weigh not only what the references say, but also who they are. An applicant who provides three quality references from experienced and respected users should stand a far higher chance of passing vetting than one who provides six references from yearlings, some of whom have some behavior issues of their own.
• History - The admin who reviewed me for rollback apparently took a fairly thorough look at my history, judging by some of the things he noticed. I don't know how common that is for rollback, but it should be done for every request for rightX (my code word for the right proposed in this RfC). A block within the previous year could be an automatic disqualification. There are tons of ways this could be tuned and refined.

It's inconceivable to me that enough bad apples could get through this to make this right a net negative. If a person is going to use the right to make trouble, that should show up in the history review alone, never mind the interview and references. I hope this helps. ―Mandruss ☎ 06:20, 25 January 2015 (UTC)

Enough bad apples used to get through RfA in pre-2007 times, Mandruss, and some still do in spite of our screwing the bar as high as we dare. --Kudpung กุดผึ้ง (talk) 11:26, 25 January 2015 (UTC)

Unless it's done "live" via IRC or Skype, an interview is useless. It's basically an open-book test. People can take hours looking up the "right answer" to questions. All that does is filter out the people who are so clueless they don't even know where to look up the answers. References aren't really any better. No one ever writes a bad reference for someone. At worst they might refuse, but no one will see the refusals, just the positive references from the people who agreed to do it. Looking at history is really the only practical way and is basically what I suggested in my oppose comment. RFA uses an "AFD stats" tool to determine how many AFD !votes a candidate has made and what % were actually in line with the outcome of the debate. If the latter number is too low, it suggests their interpretation of WP:N and WP:NOT aren't in line with what the community expects. If we decided to implement this proposal, I'd like to see similar tools for AIV and RFPP - how many reports have they made and what % are acted upon. If we wanted to get really quantitative, we could establish minimum numbers for both, combined with "general experience" criteria like for Template Editor (1 year+1000 edits, no recent blocks). Looking at a random sample of their rollbacks and PC reviews would also be useful. Leaving too much up to individual discretion is a recipe for inconsistency and standards creep (either getting stricter or more relaxed). Mr.Z-man 16:22, 25 January 2015 (UTC)

• Comment: Comparing Template Editor with Rollback & Reviewer makes a very poor analogy. TE is not a 'power right' - it does not give an editor power over another editor, it just confirms a level of technical competency like getting a driver's licence or a PPL. Rights that give power over users' edits and/or behaviour are magnets to the hat collectors, brownie point seekers, and the power hungry for whom the Wikipedia backroom is just another MMORPG. At the fear of repeating myself, those of us (sorry only admins) who have worked the WP:PERM pages are only too aware of all this.

CSD/PROD/AfD tagging most certainly should be restricted to users who have gone through an approval process, and the fact that NPP doesn't need a right is evidenced by the poor understanding of deletion, the biting of newbs, and the picking of low hanging fruit at the New Page Feed leaving us with a 31,000 backlog. Ironically, WP:AFC - a far less important process - has a bar of 500e/90d that has proven time and time again to be far too low although I proposed it myself in GF knowing that the community would reject a higher one.

To those who are evoking Wikipedia:TINC, all I can say is that such groups exist only among non-admins, namely either those who are sysop wannabes, or those who are so resentful that they will never be given the mop, do all they can to disrupt our processes and bring the very encyclopedia they 'so love' to contribute to into disrepute both on-Wiki and in other places. We certainly don't want to create easier-to-obtain minor rights that will give them a tool to vent their spleen. --Kudpung กุดผึ้ง (talk) 03:46, 25 January 2015 (UTC)

I'll say two things again, in the diminishing hope that someone is actually considering what is being said here. How much spleen can be vented before the right gets revoked? And why are you looking only at the downside? ―Mandruss ☎ 04:01, 25 January 2015 (UTC)

I looked at the 'upsides', Mandruss, and if I thought the idea were a net positive I would be up there in the 'support' section. I'm not. But I haven't suggested that this proposal was made in bad faith, nor criticised anyone's rights to express themselves. --Kudpung กุดผึ้ง (talk) 11:34, 25 January 2015 (UTC)

Ok. Well I've contributed about all I can to this, if I've contributed anything, so I'll just lurk from here on out. May the best side win. ―Mandruss ☎ 11:56, 25 January 2015 (UTC)

Although I certainly respect your opinions, Kudpung, we will obviously disagree on some points. First of all, it's really difficult to overlook the pessimistic tone of your comments concerning non-admins and "newbs". They always seem to assume that the newbies are clueless, cause trouble, and need to be restricted and monitored, while non-admins are portrayed as power-hungry hat collectors who are dedicated to making war and troubling the noble admins. (I'm certainly not suggesting that admins are not noble, but I think people know what I'm trying to say.) Also, the reference to TINC was intended to be a joke, and I clearly marked it as such. (Aside from dragging me to ANI and passing some sanction which says, "Biblioworm is hereby forbidden to use humor and must forever be a serious stone-face", I suppose that people will have to learn how to live with my general light-heated attitude. ;)) In any case, I generally like to think that I'm a fairly well-respected editor who isn't on anyone's "dislike" list, so I'm not going to blow it by getting into some argument over something so minor in the larger scheme of things. --Biblioworm 05:42, 25 January 2015 (UTC)

Of course my comments sound pessimistic, Biblioworm. After six years of campaigning to improve NPP, improve RfA, improve the image of adminship, and four years of seeing life from the perspective of a busy admin, it's clear that I have accumulated a different outlook from that of the non admins. Rather than 'pessimistic' however, I would have preferred my line of thinking to be labeled as 'pragmatic'. --Kudpung กุดผึ้ง (talk) 11:13, 25 January 2015 (UTC)

• I've been thinking a bit about this proposal a put together my thoughts on an alternate version in my sandbox that attempts to at least address some of the opposes and concerns raised. ( FWIW I have zero interest in getting this right myself, similar to how I offered input for the proposal for TE but did not seek/want that right. ) Thoughts? PaleAqua (talk) 08:03, 25 January 2015 (UTC)

  Updated the above link to a version with tweaks made by @Technical 13:. PaleAqua (talk) 23:21, 25 January 2015 (UTC)

Comment: Hello, just thought I should let you guys know that since October 2012, the blocking feature is part of the rollback "package" of user rights at the Portuguese Wikipedia, where I'm also a regular editor. It allows non-admins to block anonymous or non-confirmed accounts for up to 24 hours following cases of "light or destructive vandalism" - equivalent to the examples listed at Wikipedia:Blocking policy#Disruption. Of course I realize that this proposal is aiming much higher, and that both versions of Wikipedia behave quite differently, but because apparently this feature has not caused any significant problem over there, it might be a hint that the proposed changes would work around here. Don't take my comment as a support, though. Victão Lopes ^Fala! 05:32, 29 January 2015 (UTC)

• Is this another solution looking for a problem? Stifle (talk) 10:39, 4 February 2015 (UTC)

Comment: I think that the proposed requirements for being considered for the user right should be more strict than just needing to "meet the requirements of both roll back and pending changes reviewer". I'll state the obvious: I see this proposed user right (as most probably do) as one that should be granted to highly trusted editors who have a very established editing and vandal fighting history. Having both the 'rollback' and the 'pending changes reviewer' user rights should be required before your account is even given a second look by a granting admin. Users who apply should have a long and established record demonstrating their proper use of the 'rollback' and the 'pending changes reviewer' user rights; simply being eligible to be granted those rights is not enough. The user should also have a long and established history of warning users, reporting proper cases to WP:AIV, requesting page protection, and maintaining civility towards others. The account should also have a clean block log. ~Oshwah~ ^{(talk) (contribs)} 02:43, 7 February 2015 (UTC)

I'm with you up until the last requirement. A block at any time in the past should not be a permanent scarlet letter that stays with you for life. I think better wording would be "The user should also have a long and established history (since their last block, if applicable) of warning users, reporting proper cases to WP:AIV, requesting page protection, and maintaining civility towards others." If someone made a mistake, especially as a new user, that shouldn't be held against them if they've been a positive contributor since then. --Ahecht (TALK
PAGE) 03:08, 7 February 2015 (UTC)

I agree. What I should have said was: "The account's most recent block (if any) should be longer than one year ago, and it should be clear that the user has positively learned from their block(s) (through their contributions)". I redacted the statement; it's worded too explicitly. ~Oshwah~ ^{(talk) (contribs)} 03:55, 7 February 2015 (UTC)

You guys do realize you've now gotten to tthe point where the requirements are nearly the same as those expected at RFA, don't you? This is why this proposal is failing to gain consensus in the first place, I thought that was obvious a week ago... Beeblebrox (talk) 19:19, 8 February 2015 (UTC)

Section break 1 - Discussion (vandal fighter)

Since blocking seems to be the most contentious thing here, what are oppose voter's thoughts on making a userright which can only protect pages per the above conditions? Sam Walton (talk) 18:31, 26 January 2015 (UTC)

I think with blocking, it's workable with some changes to the criteria for granting. With only protection, I would oppose it regardless. There is very little need for protection compared to blocking. WP:RFPP only sees (on average) around 2 requests per hour and a significant fraction of those are declined. And with only the one ability, I'd worry about people misusing protection in situations where blocking would be better. Mr.Z-man 22:48, 26 January 2015 (UTC)

• @Samwalton9: Get rid of the blocking bit of this request, and my "oppose" would become a "support". Steel1943 (talk) 23:27, 26 January 2015 (UTC)

• I would recommend a three month trial period for it to be determined if it's privileges will be used positively and in compliance with policy or not.--Nadirali نادرالی (talk) 22:01, 26 January 2015 (UTC)

• I wold also still oppose it if it was just protection. The admin tools are a package. You aren't going to be effective at doing anti-vandal admin work unless you have the whole thing. Let's take attack pages as an example. When an admin sees one they have options. they can delete it, protect it from being recreated, and block the user who created it. They can do any combination of those things as appropriate. This userright would only allow protection, so they could do... what... to stop the vandal? Go find an admin looks like about it. I would also be concerned that protection would be overused since the option to block wouldn't be there. Protection is not actually something we want to do if we can help it, but if it's the only tool you have it's the only one you'll use. Beeblebrox (talk) 22:58, 26 January 2015 (UTC)
• I would switch to oppose if it was just protection. What about this userright would empower a user to stop vandals if all they can do is chase a vandal around and lock down pages they hit? That's no better than chasing them around with the revert button. Ivanvector (talk) 23:43, 26 January 2015 (UTC)
• I would likely switch to oppose as well. I see the risk of misuse for protection to actually be higher than blocking. PaleAqua (talk) 23:50, 26 January 2015 (UTC)
• Again, like AIV, RFPP is a place I rarely go to but when I do I linger to clear out what is there. And like AIV, I'm dismayed at the number of frivolous requests. No, and as per Beeblebrox, if pp were the only tool available to counter-vandalism agents it would almost certainly be over used. --Kudpung กุดผึ้ง (talk) 15:45, 27 January 2015 (UTC)
• WP:AIV clearly demonstrates that a substantial portion of experienced editors request blocks that are unwarranted. It's a clear track record this system would not work and be overused and improperly implemented. I would like to add that I am not against the theoretical application of this feature (if used properly). I simply don't see any indication it would work as theorized as directly indicated in how editors, experienced and inexperienced, already misuse the request for block noticeboards. Mkdw^talk 19:53, 27 January 2015 (UTC)

What displeases you users from this idea? The lack of examination/consideration (Rfa)? If so, how about we propose a mini Rfa for this user right? Callmemirela (talk)

Callmemirela If you were to read the entire topic I think you would find that that aspect has been covered in depth and you will find your answer there. --Kudpung กุดผึ้ง (talk) 02:07, 14 February 2015 (UTC)

Bots (vandal fighter)

Another interesting component that hasn't been touched on in this discussion here that just occurred to me, what about bot accounts. Certainly no-one can deny that one of our best anti-vandal contributors is Cluebot, so I'm wondering if such a new user-right is created, should there be bots that are allowed to have it and make use of it which would certainly be beneficial to the encyclopedia by stopping potential vandals quickly and allowing admins to check through the list at their leisure to confirm or increase the problematic ones. Just food for thought, and I think it is worth discussing. — {{U|Technical 13}} (e • t • c) 16:30, 24 January 2015 (UTC)

• I'm not at all comfortable with allowing bots to decide when to block users or protect pages, so I would oppose this idea. Beeblebrox (talk) 16:33, 24 January 2015 (UTC)
  • I'm expecting there are many who feel the same, which is why I felt it needed to be discussed. If the OP decided to not remove the above requirements (as I suggested would be a good idea) for another RfC to iron that out exactly, then those above requirements would allow for bots if there was no subsection discussion on the matter. I could try to make a case for allowing bots to do this, but will hold off at this time. — {{U|Technical 13}} (e • t • c) 16:56, 24 January 2015 (UTC)

Bots? Are you crazy? Did I actually need to specify that bots can't block, since it seems really obvious that they shouldn't. Has block-bot ever been approved? I seriously doubt it. Oiyarbepsy (talk) 03:02, 25 January 2015 (UTC)

Yes, we have bot-blocking, but under very strict guidelines (c.f. User:ProcseeBot) - there would need to be a strong community consensus established to allow anything like that, the operator would need to qualify for the permissions first, then the community would need to decide it is a task that should be done, finally WP:BAG would need to review the operations -- a steep hill to climb. — xaosflux ^Talk 03:09, 25 January 2015 (UTC)

And ProcseeBot blocks based on purely technical reasons. Vandal and spam blocks require human judgement. Oiyarbepsy (talk) 03:15, 25 January 2015 (UTC)

There was AntiAbuseBot (talk · contribs). Elockid ^(Talk) 03:19, 25 January 2015 (UTC)

Looks like that's been off for about four years. If it was actually possible to make a bot so good at assessing vandalism that it could block users, ClueBot would already be doing it. Blocking users based on article editing requires human judgement. Period. Beeblebrox (talk) 23:03, 26 January 2015 (UTC)

Why this is needed

• I would just like to note that this tends to happen a lot. A prolific vandal targets a page, and then non-admins are forced to play the revert game as they wait for a ban or page protection to occur. I think that the tool set would be useful in situations like this. Spirit of Eagle (talk) 06:16, 27 January 2015 (UTC)
  • Except in that case, the wait was due to a delay in requesting protection. The first vandalism edit was at 3:58, but it wasn't reported to RFPP until 6:11, then it only took 7 minutes for an admin to respond. Mr.Z-man 20:24, 27 January 2015 (UTC)

Bam. Beeblebrox (talk) 20:32, 27 January 2015 (UTC)

Yes, but "Bam" is not always what happens. As much as I wish it were different, the response time is usually not that quick. I've sat down in the morning to review the Special:PendingChanges list to see articles (often BLP and especially on the weekends) that have gone 16-24 hours without review. --Scalhotrod (Talk) ☮ღ☺ 17:09, 10 February 2015 (UTC)

What does blocking and protection have to do with pending changes review? --Bongwarrior (talk) 17:59, 10 February 2015 (UTC)

Bongwarrior, that's how much of the IP vandalism is identified, at least from my perspective. It's not unusual to spot one or more IPs vandalizing across several articles. Here are a couple examples from just the last hour [1][2]. Same 2 articles are vandalized. Patrol the Pending Changes list and this stuff sticks out like a sore thumb. --Scalhotrod (Talk) ☮ღ☺ 18:11, 10 February 2015 (UTC)

And yet during this time the IP editor was able to vandalize 4 more times. Between me reporting the user at 6:07 and the user being blocked at 6:16, the user was able to vandalize 8 more times. If I had had the vandal fighter tool, the vandal would not have been able to vandalize at all after 6:07. I fail to understand why giving a user carte blanche range to vandalize for 10 minutes is a desirable outcome, and the vandal fighter tool still seems like a net positive user right. Spirit of Eagle (talk) 21:09, 27 January 2015 (UTC)

Because the power to block users is rightly reserved for persons who have been specifically appointed to that task by the broader community. Nobody gives carte blanche to vandals, but we also don't want to be handing out the most dangerous and controversial admin tool willy-nilly so that anyone who sees one edit they don't like can shoot first and find a real admin later. You don't like not being able to deal with it, run for adminship. We do need more admins. Beeblebrox (talk) 21:18, 27 January 2015 (UTC)

The problem is that users interested solely in vandalism fighting are unlikely to ever pass an RfA because they don't have enough content editing, article creation, WP:GA/WP:FA, AfD, etc. experience. They are also likely to fail due to the "Diversity" clause of WP:RFAADVICE. --Ahecht (TALK
PAGE) 17:21, 10 February 2015 (UTC)

Cases like this represent a small fraction of semiprotection uses. In most cases, there are only a few vandalism edits in a day, often hours apart. The real problem is that a significant fraction of RFPP requests are declined (15-20%, looking at the last few days in the archive) and a lot of these declined requests are made by people with rollback and reviewer. People also frequently request long-term or indefinite protection when only a week or so is necessary. So for every case where we stop a vandal from making a few more edits, we'd also be protecting a page that doesn't need it. Protection is one of the most sparingly used admin tools, and for good reason. "Anyone can edit" is one of our core principles, so restricting that is kind of a big deal. Mr.Z-man 21:53, 27 January 2015 (UTC)

Mr.Z-man, please spend a week or even just a few days reviewing the Special:PendingChanges list and see if your viewpoint doesn't change. BLP vandalism is CONSTANT and especially bad when the person is part of the current news cycle. Chris Christie, Bill Belichick, Kris Jenner, and various soccer/futbol players and wrestlers are perpetual targets of attack by overzealous fans or vitriol spewing haters. --Scalhotrod (Talk) ☮ღ☺ 17:15, 10 February 2015 (UTC)

I'm not sure what your point is. If they have Pending Changes, then vandalism is much less significant of a problem since almost no one will ever see it. What problem are you describing that this proposal is supposed to solve? We already give out reviewer rights liberally. I don't deny that vandalism and BLP vandalism exists. What I don't see is a justification to give out blocking and protection rights as easy as we give out rollback. Mr.Z-man 18:00, 10 February 2015 (UTC)

Mr.Z-man, then we seem to be discussing different points. I'm simply advocating for the right to be created/granted. As for how its done, I commented below that maybe we need an "RfA Light" that isn't so daunting or vitriolic as the regular RfA process. I am in no way in favor of assigning this right in "wholesale fashion" like Rollback or others are. But support should be given to those that want to contribute their time and efforts to prevent vandalism. --Scalhotrod (Talk) ☮ღ☺ 18:18, 10 February 2015 (UTC)

The problem with this reasoning is that a spree vandal (and that vandal has been persistent since at least the New Year) would only have to plan slightly ahead and make sock puppets a few days in advance. Each sock would then become autoconfirmed (and thus immune to vandal fighter efforts) on its 10th edit. Maybe we do need some kind of "junior admin" with less power and a lower bar to pass RfA, but that should still be assigned by some kind of RfA, not handed out by any sysop. Pathore (talk) 01:38, 28 January 2015 (UTC)

Thinking through this some more, I'm starting to see the many problems that will occur if we give this right away like we do with rollback and pending change review. However, I still think that there are many non-admins who could be trusted to use this right well. I would support requiring that this right be granted through an abridged RFA process. This would greatly would largely prevent the abuse of this right and would still address the concerns I've listed above. Spirit of Eagle (talk) 02:41, 28 January 2015 (UTC)

As far as that particular vandal goes, either long-term semi-protection or an abuse filter will likely be needed. That vandal has already waited patiently for semi-protection to expire the first time and this is the second incident. The WP:DUCK vandalism all seems to come from the same ISP, varying between mobile and a wired service in a particular (large) city. It was amusingly sophomoric once. Edit warring to keep it there is not amusing at all. Pathore (talk) 02:02, 28 January 2015 (UTC)

• How about this case, where the vandal vandalized egg 174 times for half an hour? The vandal was blocked more than half an hour after the AIV report. I am not saying that this case alone is sufficient justification, but it does show that the AIV notice board in its present form may not be efficient enough. Tony Tan⁹⁸ · talk 01:12, 29 January 2015 (UTC)
• What about this user whom created edit warring since December? The user was able to transform into two other different IPs (one, two) whilst the vandalism continued. And they still do. How about this user whom caused edit warring over a stupid edit. They vandalized two pages and a talk page. The user never got the block they deserved. The user converted into different IPs (one, two, three). They continue to vandalize the pages. Callmemirela (talk) 01:43, 3 February 2015 (UTC)
  • I'm not trying to pick on you specifically, but this is one of the biggest problems I've been seeing in AIV reports lately. "Vandalism" is not just a catch-all term for disruptive editing. Edit warring and NPOV violations, except in the most extreme cases, are not vandalism, should not be reported to AIV, and would not be in the scope of this proposed user right. As an admin uninvolved with the topic, edits like this look like a content dispute. So if I see it at AIV I'm either going to spend a ton of time researching it (because the 1 sentence of context in the report likely just called it vandalism) while cases like Tony Tan's sit waiting for action or I'm just going to ignore it or refer the reporter elsewhere. (In this case it looks like you made the correct choice and reported it to WP:ANEW, but if you had this right, protecting the page or blocking the users yourself would be inappropriate for multiple reasons). Mr.Z-man 05:54, 3 February 2015 (UTC)
    • Mr. I understand you're coming from, and I am well aware of AIV, but as admin you have the right to block the user. No administrator did so. They have caused edit warring (both IPs I mentioned) for a long time, and I only got page protections as results. Once the protection is lifted, the edit warring resumes again. And again, I was stuck with page protections. It was not exactly content dispute. The DWTS vandalism was unsourced and faked by a fan. They vandalized the talk page with the same thing over and over again. As an admin, they should had seen the pattern. A protection was not enough. As for the The Fosters vandalism, it was maybe content dispute. But the user continued. It contained no factual evidence that it was not a hate group or it was not following guidelines. This is why this is why this user right is needed. A block of 24 hours maybe would had sufficed for the users to understand. Both users failed and ignored to understand the warnings on their talk pages including their reverts. As an admin, I expected a block to halt the their continued pattern. They continued before, and they will resume once the protection is lifted. They were disrupting Wikipedia, without even consulting others. One did, but it was trolling with the same thing. This is why this user right is needed. It's been two months it has been going on. What are you waiting for exactly? Though, it should only be given to trusted users and a mini-Rfa. (I don't plan on continuing arguing about the edit warring caused by the IP users). Callmemirela (talk) 02:42, 4 February 2015 (UTC)

So, because you disagreed with an administrative decision you should be granted the right to just block as you see fit? This is an excellent argument against this idea. Beeblebrox (talk) 03:03, 4 February 2015 (UTC)

• Vandal fighter rights must only be used for obvious spam and vandalism.
• As for the The Fosters vandalism, it was maybe content dispute. [...] This is why this is why this user right is needed.

I must agree, you're not helping the case for the right. Anything that smells remotely like content dispute is not "obvious spam or vandalism". ―Mandruss ☎ 03:35, 4 February 2015 (UTC)

• Mandruss I am presuming when you mean "I must agree, you're not helping the case for the right.", it is pointed toward that I am not helping my support. I would like to explain myself. I never said that I wanted the user right because I didn't agree with an admin. I included the edit warring as an example which turned into a repetitive pattern of continued vandalism. I was merely explaining of what I experience(d) for every-day edits on my watchlist. I know my intentions may be off the grid because of my previous comment to Mr. Z. I want to be granted the user rights, because I want to stop vandalism. If you read through my history for Jack & Jack and Shawn Mendes, I encounter every-day vandalism from fans, stating themselves as dating the celebrities or adding falsified content and so on. For that, I would use the Vandal Fighter user rights. As for the others, I would continue to do what I do, but I expect an admin to stop the edit warring, because it's been going on for long and no matter what warnings or messages are placed, nobody seems to listen. I apologize if my intentions, if I had the user rights, were unbalanced and pointed to the wrong direction. I was merely explaining what I think should had been done, but then again I am not admin, and as a user, seeing this almost everyday, is extremely frustrating. I'm pretty sure you've been there before. Why I believe the user rights should be granted to users through mini-RFAs remains the same. Not all admins are available, and the continued vandalism goes on. Not every RPP, AIV, 3RR/EW, etc. are answered right away. I admit that this user right is another big job to take on, which is why I suggested the granted admin to review the user for some period time until they deem them correct and the history will show their actions. Callmemirela (talk) 04:31, 4 February 2015 (UTC)

It's true that WP:Vandalism defines the word broadly, listing 21 different types of vandalism. But I don't see any that appear to cover "adding falsified content". To me, that falls under content dispute, and, if the user fails to adhere to the correct process for resolving the disagreement (article talk consensus), disruptive editing. Neither of which fall under the scope of this right. Also the right is not to be used to "stop edit-warring". Edit-warring is disruptive and time-wasting, but this right is not for stopping everything that is disruptive and time-wasting. Per Wikipedia:Vandalism#Disruptive editing or stubbornness, Edit warring is not vandalism and should not be dealt with as such. ―Mandruss ☎ 04:45, 4 February 2015 (UTC)

Mandruss, falsified content as in what I stated before that: fans stating stuff and whatnot which falls under Hoaxing vandalism. As for the IP addresses, I stand corrected. Yes, it is disruptive editing. Though, to me, the vandalism page's first sentence, and in my cases, explains that it compromises the integrity of Wikipedia. Disruptive editing should be considered as such, but it is not. I stand corrected. I will now refer myself to the DRN for them. But I stand on the other pages I mentioned previously for falsified content which does link to this user right. Callmemirela (talk) 05:11, 4 February 2015 (UTC)

Well it's clear that an editor with thousands of edits can be confused about the scope of this right. You have stood corrected twice. If you already had the right, you would have inappropriately blocked multiple users. We could develop a competence test, but that could be too easily gamed. I'm beginning to think we should narrow the scope, at least at first, to include only two basic kinds of vandalism: (1) repeatedly inserting pure garbage characters (and failing to respond to "edit test" warnings), and (2) adding clear racial slurs and hate speech. That would address a large part of the problem while simplifying things enough to make misunderstanding of the scope very unlikely. If that worked out well, we could then consider adding other types of vandalism, one at a time. The vandal fighter "summary page" that I suggested in my !vote would show the current scope, and all vandal fighters would be expected to watch that page for updates. ―Mandruss ☎ 05:37, 4 February 2015 (UTC)

Mandruss Yes, I can agree. After almost two years on Wikipedia, the rules are still in your mind, but not refreshed. I suppose I could blame myself for that. As for your suggestion, I concur. It is best we give this user right a try before going full on with it. We could try with something rather simple then go more complex if the first try is successful. I mean, in all honesty, opposing is useless if we've never given these rights a chance. We can't judge before trying, no? Callmemirela (talk) 03:15, 5 February 2015 (UTC)

Correct. Wikipedia needs to be willing to take some risk if there is to be any real progress. The most successful companies understand this. ―Mandruss ☎ 03:19, 5 February 2015 (UTC)

I think that "racial slurs and hate speech" is too vague and subject to wikilawyering. "Insertion of inappropriate profanity from this list: <words>" would be much clearer, while still including the common types of blatant "shock word" vandalism. What words should count as "shock words" is a topic for another discussion. Pathore (talk) 01:16, 6 February 2015 (UTC)

One of the worst examples of hate speech I've come across made reference to burning Jews. No profanity or shock words there, but the hate was off the scale and the person needed to be stopped in a hurry. ―Mandruss ☎ 06:32, 6 February 2015 (UTC)

If the idea is to dip our collective toes in the water by starting vandal fighters off with a restricted scope, the more clear we can make that scope, the better off we will be. Shock words aren't something a bot could police, because Wikipedia is not censored, and I'd imagine that all of the English shock words do have legitimate use somewhere on Wikipedia. Even a burning synagogue has a place on the English Wikipedia. That said, I'm sure that vandal found a very inappropriate place for his remarks, but we have ANI and AIV for that type of blatant incivility. Knowing how controversial a vandal fighter role will be, even as this sort of "trial balloon", is it not best that we propose the trial balloon with the clearest lines possible? Pathore (talk) 03:32, 7 February 2015 (UTC)

I couldn't really disagree more with this approach. I think if we don't trust someone to tell the difference between blatant vandalism and an edit war, they should't even have rollback, let alone the ability to block or protect pages. This shouldn't be given out to just everyone who asks for it, it should be like template editor or file mover - only given to people with substantial anti-vandal experience and a demonstrated need. I don't think that widely giving out the ability to block will ever be acceptable to a sufficient chunk of the community, regardless of how restricted it is. And since it's impractical to have software restrictions on the reason for a block, now we're back to every block having to be manually reviewed by an admin, which is going to mean even less support. Mr.Z-man 05:22, 7 February 2015 (UTC)

• This latest permutation of the proposal may be the worst one yet. People who are posting hate speech and extreme profanity need to be dealt with by a real admin who can issue indefinite blocks, delete pages and revisions containing hate speech, and revoke talk page access. These are some of the worst vandals and they need a firm hand, not the slap on the wrist that would be all these psudo-admin could deliver. Beeblebrox (talk) 19:25, 8 February 2015 (UTC)

  Agree with Beeblebrox. Aren't the hate speech vandals usually long-term abusive sockmasters anyway? Pathore (talk) 01:24, 9 February 2015 (UTC)

• I can understand why several of you feel so strongly about this. So if this is the case, then what about some sort of "RfA Light" process to be granted this proposed right? RfA is so daunting and has made so many people fearful or just flat out responsibility adverse, that something needs to change. But I don't realistically see a fundamental change at RfA any time soon. We're losing good editors AND Admins[3] faster than we can gain them.

• Maybe the answer is that a limited number of Senior Admins have the power to grant this right and can review each case in more detail. Effectively accomplishing the purpose of an "RfA Light" process. --Scalhotrod (Talk) ☮ღ☺ 17:25, 10 February 2015 (UTC)

I'd like to point out that the "Senior Admins" you suggest sound a lot like our current bureaucrats.

Earlier I suggested sending vandal fighter applications through RfA and trusting that the community would recognize a lower bar for granting it. There really is no consensus here, neither for nor against, and the community is about evenly split. I'm still somewhat on the fence about this, but the "handed out by any sysop" part is why my vote is an oppose for this iteration of the proposal. Pathore (talk) 22:06, 10 February 2015 (UTC)

An "RFA light" with closings by Bureaucrats based on consensus actually sounds like a great idea. Tony Tan⁹⁸ · talk 03:47, 11 February 2015 (UTC)

Well, the WP:RFA page lists the applications for Admins and Bureaucrats (RfX), I don't know what the technical considerations are for this, but if the desire for this right to go through RfA is so adamant, then perhaps a 3rd section could be added. A "RfVR" (Vandal Reverter) section could address the processing of these requests. That way we can have a formal process, tracking, and an archive. --Scalhotrod (Talk) ☮ღ☺ 19:07, 11 February 2015 (UTC)

A Different Approach

Honestly all these arguments seem to be structured around one person having this power. A better approach may be to have multiple people in a certain group vote on that power. Therefore it seems to be more balanced as it is a voting system. Example:

• User A nominates Suspicious Person A to be blocked.
• Other users in that group contribute to the discussion with Support and Oppose etc.
• Users vote on whether Suspicious Person A should be punished or not
• Users then decide on the severity of their punishment

Not sure how this would be implemented, just putting this thought out there.

asdfawesomegreen (talk) 02:31, 12 February 2015 (UTC)

I think you just described how WP:ANI is supposed to work. Pathore (talk) 03:22, 12 February 2015 (UTC)

Actually, let me be more specific.

• User A must be in that special group alone or the "Judge Group".
• Other users meaning "Judge Group" who decide whether they are guilty and vote/abstain.
• The users in the group are sharing the power as in after they select some choices within a certain time limit, it goes into effect.

Ex:

• Judge Group User A votes a ban
• Judge Group User B votes no ban etc.

The person would then be banned by a somehow implemented poll or by a neutral user/administrator overseeing the group

I hope this clears up any confusion asdfawesomegreen (talk) 03:38, 12 February 2015 (UTC)

If the admins are the "Judge Group" you suggest, then you are more-or-less describing WP:ANI as I understand it. The major difference being that ANI is open to anyone. Blocks, bans, etc. are handed out based on consensus at ANI.

The "shared power" concept you advance would be completely useless in this proposal, since the whole point of this proposal is to stop vandals faster than we currently can. Since blatant vandalism-only accounts get indef blocked as soon as an admin finds them, the only way we can make that first block hit the vandal faster is to have more people looking and able to block a new vandal. The proposed steps are (1) vandal vandalizes, (2) vandal fighter blocks vandal for up to 48 hours, (3) admin reviews block within 48 hours and indef blocks vandal, thus, no more vandalism from that vandal. Our current process is more like (1) vandal vandalizes, (2) someone doing anti-vandalism patrol notices and makes a report at WP:AIV, (3) admin at AIV sees report and indef blocks vandal. The reason for the proposal is that a new vandal can sometimes do quite a bit of vandalism between steps (2) and (3) of our current process. Pathore (talk) 05:53, 12 February 2015 (UTC)

Delay publication to anon/mobile to allow time for review

I propose delaying the publication of edits to anonymous users with no editing session (including readers of mobile web and mobile apps) by a few minutes, to allow time for review. An anonymous page view at any given time would check the last few minutes of editing history. Reverts would be detected by content hash. A revision would be selected for display which stood unreverted for longer than the review period. If no such revision can be found within some limit of revision count and time, the newest revision would be shown. This simple heuristic is designed to be efficient to implement. Technical details would be similar to FlaggedRevs (WP:PC) -- there would be a single linear history, and clicking "edit" would show the newest revision.

The motivation is Reid Priedhorsky's 2007 paper which stated that despite revert time being short, popular pages commonly had hundreds or thousands of page views of the vandalised version. -- Tim Starling (WMF) (talk) 19:25, 29 January 2015 (UTC)

• Groan. I mean, I get it, but surely you are aware of what an epic struggle it was to get us where we are with PC. It literally took five years and several massive, contentious RFCs. You're not going to get a change like this through by just posting about it here. I'm also wondering if this is just you or if the foundation actually wants this. Beeblebrox (talk) 19:33, 29 January 2015 (UTC)
  • It is my own proposal, I have not discussed it with other WMF staff members. I wanted to bring it here first, because I care about what the community thinks. -- Tim Starling (WMF) (talk) 19:44, 29 January 2015 (UTC)
    • size for relative importance: does that mean you're using your staff account for this as a coincidence? Martijn Hoekstra (talk) 20:11, 29 January 2015 (UTC)
      • I have been instructed to use my WMF account for all edits made on work time. I argued for using WMF accounts only when speaking ex cathedra or performing an office action or whatever (i.e. never) but this was explicitly contradicted. I will add a note about this to my user page. -- Tim Starling (WMF) (talk) 20:24, 29 January 2015 (UTC)
• I would support this for BLP's only (I'm undecided about the broader implementation) Would such a thing be technically feasible? Martijn Hoekstra (talk) 19:39, 29 January 2015 (UTC)
  • Yes, it is technically feasible, assuming BLP pages are or can be tagged somehow. It would probably add a couple of days of development time. -- Tim Starling (WMF) (talk) 19:55, 29 January 2015 (UTC)
    • Category:Living people? Sam Walton (talk) 19:57, 29 January 2015 (UTC)
      • Yes, it would possibly work, although a page will drop out of that category if it is blanked. You would need a more stable view of category membership. Maybe a couple of days was overly optimistic. I would be interested if Martijn Hoekstra could explain the rationale for limiting it to BLPs. Is the idea that vandalism of BLPs is more impactful? What is the tradeoff which prevents it from being deployed on pages where vandalism is less impactful? Personally, I care about quality, and reader perceptions of quality, on all pages of Wikipedia, not just on BLPs. -- Tim Starling (WMF) (talk) 20:11, 29 January 2015 (UTC)
        • Yes, I could. I assume I have the minority POV that it's not so much of a problem to have the occasional vandalism shown to visitors. It re-enforces the idea that anyone can edit, and that this is something you can do right now, analogous to the 17th century Wikipedia principle of always leave something unfinished. This off course completely breaks down in the face of BLP violations, which weigh heavier than recruitment efforts of our encyclopedia project. In that light yes, I do feel that vandalism of BLPs is more impactful than other vandalism. I'm undecided (not opposed per se)about whether or not presenting users with a possible inferior product - which would be the case only if the part of Wikipedia that has changed in the past few minutes of review time is inferior to Wikipedia five minutes ago, which gives rise to some interesting implications if we accept that as true, and I'm not 100% sure of - outweighs that public reminder and recruitment tool. But before bursting in to that discussion I first wanted to know whether or not it was feasible or not. Martijn Hoekstra (talk) 20:26, 29 January 2015 (UTC)
          • I slept on this, and came to the following conclusions. The first conclusion is I forgot to thank you for the proposal. Thank you, we need to keep looking out for changes to improve the project, proposals like these are important. The second conclusion is that the feature would increase the utility of Wikipedia to the reader at each momement iff the utility of the sum of all edits that are not reverts within the delay period is negative. That's fairly subjective even if we had complete data, which we don't. So it comes to a gut feeling-enhanced educated guess. And my guess is that that's not the case for the proposal as written. But I think we can do better; for some edits, we know they are likelier to be damaging than others. If we hook in to those mechanisms to trigger the delay, it is more likely that this feature has a positive impact. There is talk of the grand AI in the sky, but waiting for that would be unnecessary; we already have the edit filter. Currently the edit filter can log, warn and disallow. If we could add delay to that set (is that technically feasible?), I would certainly support it. Martijn Hoekstra (talk) 09:43, 30 January 2015 (UTC)
• Question: is this basically setting automatic WP:PC for all members of Category:Living people? It goes against our protection policy (and Wikipedia's mission) to preemptively protect pages, but I think I can see the benefit of preventing anonymous drive-by BLP vandalism and would support per WP:IAR. I think there's a lot of details to work out. Technical question to Tim's point above: if protection were applied to members of the category (assuming that is technically feasible) then that protection should prevent the page from being blanked by an anon, yes? Ivanvector (talk) 20:18, 29 January 2015 (UTC)
  • No, as I read this proposal it's not about protection, it's about delaying new edits; if the edits stood uncontested for more than a few minutes it's assumed sufficiently good for public display. Also, the BLP issue is not part of the original proposal, it's just a ball I threw in the air as a question. Martijn Hoekstra (talk) 20:33, 29 January 2015 (UTC)
• A technical question: Anonymous views are by far our largest volume, and as far as I know they are effectively served via static proxies. Have you already considered the load implications of this proposal? It could add orders of magnitude of load on the actual DB servers (which may or may not be a problem, but should be considered). --Stephan Schulz (talk) 20:41, 29 January 2015 (UTC)
  • I think Tim might know one or two things about the infrastructure, and if he explicitly notes it would be efficient to implement, it's likely true. Martijn Hoekstra (talk) 20:50, 29 January 2015 (UTC)
    • Well, the algorithm he describes above is certainly not highly complex, but it does seem to move from a static request to a dynamic request, and indeed one with multiple data base accesses (get the history, get the proper revision). I can imagine some clever ways to improve performance, but a straightforward implementation is a potentially serious performance issue. So I am interested in a statement, especially by someone who knows the infrastructure. --Stephan Schulz (talk) 22:14, 29 January 2015 (UTC)
      • Depending on the implementation, this could actually reduce load on the main servers, since the caches would not need to recheck their copies at all until the delay expires. If there is no delayed edit pending, then the page served to anonymous users cannot change until after (1) an edit is made, and (2) the delay expires. This would mean that the caches would not need to contact the main servers at all until the delay expires. Which leads to the question: Would an anonymous user still immediately see their own edits? Pathore (talk) 22:31, 29 January 2015 (UTC)
      • Here is my idea for implementation: since no change is possible until the review period expires, we can just delay the HTCP CLR requests using a queue, instead of doing them on save. That takes care of most of the feature, with no increase in backend traffic. In fact, it could reduce server load because it makes it possible to send an Expires header to clients. Continuous high-frequency editing would work as long as duplicate entries are not removed from the HTCP CLR queue. If a backend request is received during the review time despite the delayed HTCP CLR message, send the old revision with a short Cache-Control: smaxage. Then Varnish will send a second backend request with an If-Modified-Since header after the review time expires. If there was no revert, MediaWiki can respond with a 304, which is fairly cheap since it doesn't require loading i18n etc. An anonymous user would immediately see their own edits, because editing causes a cache-suppressing session cookie to be sent, and MW would send the current revision to users with a session cookie. -- Tim Starling (WMF) (talk) 23:07, 29 January 2015 (UTC)
        • Thanks! Now I can start thinking about the social effects ;-) --Stephan Schulz (talk) 09:35, 30 January 2015 (UTC)

• I'm still processing this idea, but my initial reaction is: wiki means fast. Intentionally adding a delay seems to be a direct contradiction of this fundamental principle. If we implemented this proposal and anonymous user A vandalized the page, anonymous user A would see the vandalism, but other anonymous users would not, as I understand it. What would happen when anonymous user B goes to edit the page? Wouldn't there immediately be a disconnect between what's shown on the page and the (uncached) edit view?

  Broadly, we currently have the purge action (hack) in place because we're so bad about keeping content up to date. Our *links tracking database tables are a mess and contain plenty of bad entries, refresh jobs can get dropped or forgotten resulting in indefinitely stale content, etc. Given that we already struggle to show current content and that cache invalidation is a notoriously hard problem, I'm hesitant to add another caching layer that could make the situation worse. --MZMcBride (talk) 23:42, 29 January 2015 (UTC)

• No worse than the disconnect that occurs when someone edits a page between when you load the page and when you click the "Edit" link, which happens occasionally. --Ahecht (TALK
  PAGE) 19:10, 30 January 2015 (UTC)

• I've thought about this a bit and I see two ways of looking at it. The idea of letting the caches lag in a controlled manner to reduce server load for heavily accessed and frequently edited pages, while simultaneously denying recognition to vandals and edit warriors, could be an improvement that I could support. In this view, it is a sort of "Pending Changes 0" applied automatically to heavily edited pages, and there should be a list somewhere of pages where the currently shown revision is more than X minutes out of date (because no revision since then has stood for the delay period) and any autoconfirmed user should be able to endorse another user's existing revision ("looks good to me") with immediate effect.

We need to be very careful with this: in the other view, "you see your edits, but others don't" is more-or-less the basic concept of a shadowban. Doing that to all anonymous users with no assumption of good faith at all, is just not the Wikipedia way and I would vehemently oppose such a proposal. Note that both of these are technically almost the exact same thing, the only difference is the motivation behind them. Pathore (talk) 01:49, 30 January 2015 (UTC)

• I'll sign up as one of the closers if this turns into an RfC. There's nothing wrong with throwing this out for discussion, and it looks like you're getting some good feedback, but be aware that if it looks like there are still a lot of unresearched questions when the RfC starts, any perceived lack of preparation is likely to generate some opposition. I'll be happy to supply links to previous related discussions if you want them. Could you summarize the results of the 2007 paper for us? - Dank (push to talk) 02:45, 30 January 2015 (UTC)
  • I would definitely be interested in reading previous related discussions, thanks for the offer. Here's a relevant quote from the paper: "42% of damage incidents are repaired essentially immediately (i.e., within one estimated view). This result is roughly consistent with the work of Viegas et al., which showed that the median persistence of certain types of damage was 2.8 minutes. However, 11% of incidents persist beyond 100 views, 0.75% – 15,756 incidents – beyond 1000 views, and 0.06% – 1,260 incidents – beyond 10,000 views." The paper is reference 14 in the article Reliability of Wikipedia. My proposal here is not discussed in the paper -- instead, the authors suggest improving tools for human review. -- Tim Starling (WMF) (talk) 04:31, 30 January 2015 (UTC)

Thanks for your comments, everyone. It sounds like this would likely be rejected if I took it to an RFC, so I'm going to drop it as originally proposed. Martijn's idea of making publication delay be an AbuseFilter action is interesting, I'll make a note of that for further analysis. Making it a selectable PC protection level would also be technically feasible, but it sounds like it would be a lot more trouble on the community side due to strongly held views about PC. -- Tim Starling (WMF) (talk) 23:19, 30 January 2015 (UTC)

(I think you're referring to my comment.) I just want to clarify that I was not suggesting making delay a selectable pending changes level. Since the infrastructure for delay would be shared with pending changes in your proposal, I was loosely calling the delay "PC0", but I meant to suggest that the software would apply it automatically to pages with more than X requests/sec to lessen the load on the main servers. Reducing the visibility of vandalism would be a beneficial side-effect, but the main goal is to make better use of the caches. Pathore (talk) 01:46, 31 January 2015 (UTC)

• @Tim Starling (WMF): Delaying the visibility of all edits indiscriminately would almost certainly be rejected, even if only for a subset of articles. But if only edits automatically assessed as 'suspicious' are delayed, then this would likely be accepted. In fact, I'm working on such a proposal at Wikipedia:Deferred changes. The abuse filter or bots would defer suspicious edits, marking them for review by pending changes reviewers. (This is an improvement on the old Wikipedia:Deferred revisions, see also the request at phab:T51770.) This also allows a mild form of blocking called 'moderation'. I haven't made a formal proposal yet but I may go ahead shortly, especially if there is interest among developers to work on such a feature. Cenarium (talk) 17:27, 31 January 2015 (UTC)
  • The FlaggedRevs UI is quite tightly coupled to its DB schema, which makes schema changes to support new features like that potentially touch a lot of code. I don't think there is much developer interest in digging deep into the guts of FlaggedRevs at the moment. -- Tim Starling (WMF) (talk) 04:22, 1 February 2015 (UTC)
    • @Tim Starling (WMF): The bare minimum is a userright that allows to apply and remove pending changes protection without leaving an edit. Everything else can be done by bots : the bot checks for edits that require being deferred, when it detects one it enables pending changes protection (without leaving an edit), accepts the latest revision before the last user edited, then the edits appear automatically at Special:PendingChanges. When a new revision is accepted, either due to a revert or a manual review, the bot removes the pending changes protection (without leaving an edit). It would be better, but not necessary, if this were another flaggedrevs level, so that it appears differently at Special:StablePages (and to get specific mediawiki messages), and that it automatically accepts the revision preceding the last user, and automatically removes itself when a new revision gets accepted (to avoid unnecessary logged bot actions). Then we can think of having abusefilter defer directly instead of using bots as intermediaries, which would be faster, but it's not the crucial point. Cenarium (talk) 03:09, 3 February 2015 (UTC)
• I've put some thought into this and I don't think I can support it. We already have legions of vandal fighters racing to revert vandalism faster than ClueBot can detect it. Blatant vandalism is a problem, but it is usually dealt with very quickly. Delaying all edits by IP users doesn't seem tome like it would be a very effective tool in the ongoing struggle against vandals, and it completely ignores the fact that a lot of vandal edits ctually come from newly-registered users. I floated a different idea regarding them a few years ago and maybe it's tiome to revist that: New accounts are often created by vandals in order to grant them the ability to instantly create new articles. Anyone with experience in vandal fighting knows this. They create attack pages, nonsense pages, pages about their exploits on the playground or the xbox, etc. If we restricted article creation to WP:AUTOCONFIRMed users they would have to wait four days and make ten good edits befroe they could create whole new articles that need to be deleted. For the vast majority of vandals, i.e. teenage schoolboys goofing off, the reward would not be worth the effort and they don't have the patience to begin with. I'd much rather see that change than the one proposed here. Beeblebrox (talk) 18:57, 31 January 2015 (UTC)

  We already restrict file uploads to autoconfirmed users, maybe similar reasoning can support limiting the creation of articles in mainspace. Can you point to the discussion that led to the restriction on file uploads? I'd like to read it, but the closest I've been able to find was this, from December 2009, that mentions autoconfirmed status already being required to upload files. The archives for Wikipedia talk:Upload don't seem to mention it. Pathore (talk) 22:14, 31 January 2015 (UTC)

  There was Wikipedia:Autoconfirmed article creation trial but it wasn't implemented, apparently restricting page creation beyond registration is a no go for the WMF. Even then, since then, NPP has been more streamlined and AFC has taken over a substantial portion of page creations, actual or potential, so it's less of a problem that it was back then in my opinion. (FYI, in my proposal I suggested that deferred page creations be noindexed.) Cenarium (talk) 00:29, 1 February 2015 (UTC)

  @Beeblebrox: I didn't say anything about edits by IP users, I think you're the first person to bring up that idea. I was talking about delaying all edits. -- Tim Starling (WMF) (talk) 04:22, 1 February 2015 (UTC)

  I think the first sentence is tripping people up. ("I propose delaying the publication of edits to anonymous users with no editing session (including readers of mobile web and mobile apps) by a few minutes, to allow time for review.") "Anonymous users" is often used interchangeably with "IP editors," which is actually how I read this thread until just now. I thought we were discussing only delaying edits by "drive-by IPs" (people not logged in with no editing experience). That's how I interpreted "no editing session." I'm not sure if I'm alone in this confusion. --MZMcBride (talk) 05:25, 2 February 2015 (UTC)

The language could certainly be more clear as it does seem I misread some aspects of it. Beeblebrox (talk) 03:07, 4 February 2015 (UTC)

• I might be missing something, but isn't this more or less the original "pending changes" system from 2008 or so, as used on dewiki & elsewhere, before we ended up writing an enwiki-specific version? It's not a bad method, but it doesn't look like it's become any more popular... Andrew Gray (talk) 20:12, 31 January 2015 (UTC)
  • It doesn't seem similar to me. -- Tim Starling (WMF) (talk) 04:22, 1 February 2015 (UTC)
  • My understanding of FlaggedRevs is that the idea was to have humans pick a good state of an article and then typically manually review untrusted edits to the article before establishing a newer good state. This proposal seems to be suggesting a similar idea, but without needing manual review (to establish a newer good state of the article) and instead using an automatic timer. Under this automatic timer, there would be an intentional delay placed at the HTML cache layer to not purge the page for an unspecified(?) amount of time during which patrollers would have a grace period to catch the edits before the article is purged.

    My reading of this discussion is that it needs clarification of the time period (review time/delay until live) we're talking about (30 seconds? 10 minutes?) and it needs clarification of what kind of edits would be delayed from purging the HTML cache. That is, what does "no editing session" mean? --MZMcBride (talk) 05:33, 2 February 2015 (UTC)

If I've understod this correctly (Tim can complain if I'm wrong), this proposal means the following:

• All of us logged-in editors will see exactly what we see right now. For the purpose of this proposal, this group is called "editors".
• People who are editing while logged out will see exactly what they see right now. We'll call this group "editors", too.
• This proposal only affects people who are both logged out and have not edited recently ("no editing session"). We'll call this group "readers".
  • According to unrelated research, an editing session can generally be assumed to have ended if you haven't made any edits in the last ~30 minutes.
• This proposal requires zero extra effort. Unlike FlaggedRevisions/PendingChanges, there is no manual review needed. No intervention by editors. Zero increase in our workload. It's all automatic.
• This proposal says (only for the one affected group, "readers") that if and only if
  1. an article has been edited very recently and
  2. that last edit was not a revert,
• then the reader will not see the very latest (potentially vandalized) version. Instead, the reader will see the latest "stable" version, meaning the latest version that wasn't still being evaluated by ClueBot and/or RecentChanges patrollers.
• "Very recently" means a short period of time, probably in the range of 30 seconds to three minutes.

Consequently the question is basically this: Would you rather that "readers" (i.e., people who are not you) saw the absoultely latest and sometimes vandalized versions of all articles, or would you rather that readers saw (very) slightly older, and noticeably less vandalized, versions of articles? Whatamidoing (WMF) (talk) 01:58, 3 February 2015 (UTC)

FWIW, the "no edits in the last 30 minutes" is a proposal I haven't seen before, and I don't know how RfC voters would react. - Dank (push to talk) 02:08, 3 February 2015 (UTC)

That particular measurement need not be the one used (I'd have assumed 24 hours as a more natural one), but there has been some good research in how long people spend editing and how to predict whether they're done, and 30 minutes of inactivity is apparently a very good predictor. Therefore, any delay in excess of that very short time will very likely be sufficient. Whatamidoing (WMF) (talk) 07:51, 3 February 2015 (UTC)

The problem is that those high visibility articles, often related to current events, tend to be edited heavily, with some having one or more IP edits every minute. So if we put a relatively long delay, such as two minutes, it effectively means that those articles would be un-editable for IPs, while if we put a relatively short delay to counter this, say 15 seconds, the efficacy of the delay to prevent display of vandalism would be severely limited. In my opinion, it's much better to automatically identify actually suspicious edits and defer them for manual review. And then the server overhead is on the edit (or defer action if a bot does it), not the page views. Cenarium (talk) 02:41, 3 February 2015 (UTC)

There is nothing in Tim's proposal that would stop an IP from editing. Tim's proposal is only about what people see when they read the page. The edit button would still be present, the contents of the edit box would still be exactly what you and I see, and the only 'difference' is that what the IP would find in the edit box would (sometimes) be different from what the IP read on the page. (In other words, the IP would experience exactly what all editors routinely experience on rapidly edited articles.)

However, the particular edge case you mention was directly addressed in the original message: "If no such revision can be found within some limit of revision count and time, the newest revision would be shown." That means something like, "If an article is being edited very rapidly, then we'll just show the latest (possibly vandalized) version, exactly like we do right now". Nobody would ever read a version that is very outdated. Whatamidoing (WMF) (talk) 07:51, 3 February 2015 (UTC)

I didn't mean that IPs would be technically prevented from editing, but that it would be very difficult to make edits in those circumstances due to the systematic delay and resulting discrepancy, much more so than for registered users, since they could not know which version is live. (Even on rapidly edited articles, we have windows of opportunity of several seconds at least, with rare exceptions.) It should be considered that merely trying to edit would not make you in an 'editing session' subsequently, so you would still get the delay after a failed edit attempt. If the server would check for edit attempts (loading a action=edit url), it would remove this problem after a first failed attempt, but it may be tricky to accomplish server side. The extract from the original message that you quote concerns high speed edit wars, as you mentioned earlier, which is only a small subset of rapidly edited articles. Cenarium (talk) 16:07, 3 February 2015 (UTC)

This is why I suggested allowing any autoconfirmed user (or even any registered user) to endorse an existing pending revision of any such delayed article, with immediate effect. How many vandals bother to make autoconfirmed sockpuppets? Pathore (talk) 01:23, 6 February 2015 (UTC)

I generally endorse Cenarium's concern. However, if the delay is kept down o around 30 seconds (or any other "less than one minute") time, I don't think the burden on "readers" who are switching their status to "editors" would be too great. – Philosopher ^{Let us reason together.} 18:51, 6 February 2015 (UTC)

• This doesn't feel like a proposal at this stage; but instead, a very good idea which I hope comes to fruition.--John Cline (talk) 16:30, 6 February 2015 (UTC)

I'm probably coming to this thread late, & after everyone has moved on to other threads. However, this proposal illustrates an important -- & potentially fatal -- contradiction: which is primary, letting anyone edit, or proving the most accurate information possible. If it is to let anyone edit, then this proposal should not be implemented. If it is to provide the most accurate information possible, then it needs to be implemented. In the past, the en.wikipedia community has tried to prioritize accuracy (e.g., various proposals for dealing with new page creation), only to see the WMF quash community consensus. On the other hand, WMF has taken actions favoring accuracy (e.g. its support for WP:BLP policy). I have the impression that the Foundation wants it both ways, & penalizes the community whenever it prioritizes one of these -- letting "anybody" edit vs. accuracy -- over the other. In my comment above I am not accusing Tim Starling as contributing to this contradiction; as he remarked, his posting from a WMF foundation was forced upon him. And besides, unlike other Foundation employees he came to the community first with his idea, & did not impose them upon us as other innovations have. -- llywrch (talk) 00:46, 10 February 2015 (UTC)

Proposal regarding flag icons in infoboxes

Okay, this is my first attempt at a proposal, so be gentle. I attempted to ascertain if there was a particular format (as per IJBalls suggestion, but failed to determine if there was one (perhaps I simply did not look in the right place). Anyway, here goes.

WP:ICONDECORATION states that "Icons should serve an encyclopaedic purpose and not merely be decorative. They should provide additional useful information on the article subject, serve as visual cues that aid the reader's comprehension, or improve navigation." In the first instance, the inclusion of a flag icon, directly next to the name of the administrative unit, is redundant, and solely for decorative purposes. Since the name of the country/state/province is already included, it provides no additional useful information. While it does serve as a visual clue, it is questionable as to whether or not it aids the reader’s comprehension, since a reader would have to know the flag of the geographic area in order for that to be the case. And it does not improve navigation, since the geographic name already provides the link.

WP:WORDPRECEDENCE states that "Words as the primary means of communication should be given greater precedence over flags ..." This is pretty explicit.

MOS:INFOBOXFLAG begins with "Generally, flag icons should not be used in infoboxes, even when there is a "country", "nationality" or equivalent field: they are unnecessarily distracting and give undue prominence to one field among many ..." It goes on to say, "Flag icons should only be inserted in infoboxes in those cases where they convey information in addition to the text. Flag icons are visually distracting in infoboxes and lead to unnecessary disputes when over-used."

However, after these pretty specific guidelines, it goes on to muddy the waters by saying “Human geographic articles – for example settlements and administrative subdivisions – may have flags of the country and first-level administrative subdivision in infoboxes ..." It becomes even more confusing when it goes on to say, "Where a single article covers both human and physical geographic subjects (e.g. Manhattan), or where the status of the territory is subject to a political dispute, the consensus of editors at that article will determine whether flag use in the infobox is preferred or not."

This has been discussed, and there has never been a consensus reached, but neither have either of the two guidelines I mention above been brought into the discussion.

What I propose is to make it more clear when flag icons should or should not be used in geographic infoboxes. When you factor in all three of the above guidelines, the first two would seem to indicate a preference to not including them in infoboxes. When you look at the third, it begins by agreeing with them not being included in infoboxes, but then goes on to contradict the other two guidelines, and the earlier paragraphs within its own guideline. And it does so without giving any reason whatsoever. I propose that we change the guideline to read that flag icons should not be used in infoboxes for ANY geographic articles, either physical or natural. I think this would make the standard consistent. Onel5969 (talk) 04:32, 1 February 2015 (UTC)

Discussion (MOS:INFOBOXFLAG)

Comment – I agree with this proposal, but am wondering if it is in the "correct format" for proposals. So I'd appreciate any comment from knowledgeable editors on that aspect of this... --IJBall (talk) 16:46, 1 February 2015 (UTC)

• Support This has been a long time coming. This particular guideline is one of the most debated and ignored guidelines on wikipedia. In My Opinion, Flag icons would not be used in any infobox at all. They are 100% useless in infoboxes 100% of the time. A slim, but vocal, minority of editors have been able to successfully "protect" their sphere of articles from the removal of infobox flag icons for several years now. The most notable would articles pertaining to Tennis, Golf, and Formula One racing. The most common argument that these few editors use to keep their icons are that these sports use flags in their internal media. Whatever! The point is that there are some very vocal editors out there who might see this proposal as an attack on their pet projects. In respect to geographic articles, I think that they are useless there too. Yet the vocal minority is notably absent from these articles as there are many articles that do not contain flag icons and for some reason the world continues to turn without them. Some articles do contain flag icons and usually these have been added, or removed, and even debated on a case-by-case basis. And everything I just said, goes the same for military articles as well. They are useless.--JOJ ^Hutton 17:33, 1 February 2015 (UTC)

I do not understand why flag icons would be appropriate in the articles you mention, because the competitors in those events are almost never competing for their countries, except in very specific matches (where they would be named as part of a team). Risker (talk) 23:48, 7 February 2015 (UTC)

• It's a bizarre claim that the flags in the Manhattan infobox draw attention - in fact all they appear to do is inform the reader of related flags Alanscottwalker (talk) 17:53, 1 February 2015 (UTC)

And are totally unnecessary... --IJBall (talk) 17:57, 1 February 2015 (UTC)

So you say. Others say it's a Good article. There is no reason to WP:CREEP over such a thing. Alanscottwalker (talk) 18:10, 1 February 2015 (UTC)

"Good article" status is about the words in the article. That has absolutely nothing to do with Flag Icons in the Infobox. Removing the Flag Icons doesn't suddenly mean that Manhattan will lose "Good Article" status. And none of that has anything to do with whether using the Flag Icons in Infoboxes is properly "germane" or not. --IJBall (talk) 18:23, 1 February 2015 (UTC)

Obviously, the editors of the article found them germane. But the need to micromanage them and turn them off (because of an 'i don't like' position over "true" germaness) is apparently strong in some. Alanscottwalker (talk) 18:29, 1 February 2015 (UTC)

FTR, I don't agree that "they are 100% useless in infoboxes 100% of the time" – I'd put this kind of article down as example of a narrow case in which Flag Icons in Infoboxes actually serve a useful purpose (e.g. in those cases where there exists lists of things from many different nations in Infoboxes). But I would probably agree that Flag Icons are unnecessary in Infoboxes about 90% of the time, so I probably don't disagree with you all that much. I certainly agree that they are 100% unnecessary in all "city" articles, and the "human geographic, i.e. settlement, articles" carve out from MOS:INFOBOXFLAG should be eliminated. --IJBall (talk) 17:57, 1 February 2015 (UTC)

Flag icons should not be used where text can convey the same information - that typically being the nation, state, providence, etc., that the city/person is part of. (Needless to say, the obvious use of a country's flag in a country's infobox is fine, this is part of the base data for a country). --MASEM (t) 18:37, 1 February 2015 (UTC)

Why does this need to be one size fits all? And what person are you talking about? Alanscottwalker (talk) 19:11, 1 February 2015 (UTC)

• Oppose - Most of the present language of MOS:ICON was adopted by five or six editors in October 2007 with little or no Wikipedia-wide notice and no participation from members of the sports, military, ship and other relevant WikiProjects. It is a classic example of an unadvertised "local consensus" on a talk page for a guideline that is supposed to provide project-wide guidance. Even the on-wiki talk page discussion strongly hints that the five or six editors knew what they were doing, and had adopted a controversial change without widespread notice and input, effectively gaming the concept of "consensus" (see MOS:ICON talk archive). Based on the last several years of MOS:ICON talk page debates, I have little doubt that the present MOS:ICON language could not achieve an effective consensus in support of it (see, e.g., recent RFC on point). While I do believe that the use of flag icons should be limited and appropriate, I will oppose any attempt to change MOS:ICON that does not expressly sanction the use of a single 7mm flag icon to symbolize the "sporting nationality" of Olympic athletes and other members of their country's national sports teams in biographical articles. Such limited use is entirely appropriate, and I believe that you will find that there is widespread support for that proposition. Given the checkered history of the present MOS:ICON language, I would also like to know where this proposal is being advertised on-wiki? Dirtlawyer1 (talk) 18:42, 1 February 2015 (UTC)

  Question - Why is this proposed change to MOS:ICON being at Village Pump, and not on the relevant MOS:ICON talk page? As far as I understand it, proposed changes to guidelines are usually opened and discussed on the talk page for the particular guideline. This location for this proposal strikes me as quite odd and contrary to normal process. Dirtlawyer1 (talk) 18:52, 1 February 2015 (UTC)

  Because, 1) we want to find out if it is even in the correct format for a proposal like this, and 2) (I think...) a wider audience of opinions on the draft proposal was desired. --IJBall (talk) 18:55, 1 February 2015 (UTC)

  IJBall, I am all in favor of determining the correct format for the RfC -- generally, successful RfCs ask a narrowly drawn question that can be answered "yes" or "no", followed by as much rationale as discussion participants care to add. I, too, am in favor of as much project-wide notice and participation as can be achieved for proposed changes to style formatting guidelines that offer project-wide guidance. That having been said, I am unaware of any previous proposal to change MOS provisions that has been initiated at Village Pump -- can you provide any examples? Again, this strikes me as a very odd (and inappropriate) forum to be discussing the appropriate use of flag icons in article space. Dirtlawyer1 (talk) 19:10, 1 February 2015 (UTC)

  Wikipedia talk:Manual of Style/Icons, which is the talk page for MOS:ICON, has 229 watchers. This page has 2,649. --Redrose64 (talk) 19:25, 1 February 2015 (UTC)

If we'd known the proper "procedures" for this we wouldn't have asked here.  ;) This is Onel5969's first proposal, and I've never done one before either, which is why I suggested he ask for guidance here. At this point, I guess if Onel5969's proposal is deemed to be in the "correct" format (or we're told we should do an RfD...), then it can be moved to Wikipedia talk:Manual of Style/Icons. So really, at this point, all that's desired is guidance on what needs to be done here... --IJBall (talk) 20:00, 1 February 2015 (UTC)

As IJBall pointed out, this is my first shot at a proposal. Dirtlawyer1 - I began the proposal here, because if you go to WP:PROPOSAL, it says, "The first step is to write the best initial proposal that you can. Authors can request early-stage feedback at Wikipedia's village pump for idea incubation and from any relevant WikiProjects." I had already gotten feedback from the US City project, so I felt the next step was here. Onel5969 (talk) 20:50, 1 February 2015 (UTC)

• I'm really not sure exactly what is being proposed here. The last section starts with I propose is to make it more clear when flag icons should or should not be used in geographic infoboxes. which I Support as clarification is normally a good thing; the same section ends with I propose that we change the guideline to read that flag icons should not be used in infoboxes for ANY geographic articles, either physical or natural. which I strongly oppose as BUREAU CREEP and too restrictive. There are obviously cases where using the flags is beneficial and informative and by changing the guideline to prohibit such use will just end up with multiple cases where WP:IAR will simply be invoked as appropriate. — {{U|Technical 13}} (e • t • c) 18:48, 1 February 2015 (UTC)

Hi Technical 13. Can you provide some example where you think that Flag Icons in Infoboxes are appropriate in a "geographic" type article. I believe Onel5969's proposal is mostly directed at "city" articles, like, say, this one (see the 'Country' and 'State' fields), in which the use of Flag Icons in the Infobox seems to many of us to be totally unnecessary. So it would be useful if someone could give some examples where Flag Icons might actually be constructive... Thanks! --IJBall (talk) 18:53, 1 February 2015 (UTC)

You have a preference for that article not to have those unobtrusive flags? Take it to the article talk page and perhaps the editors who are concerned and knowledgeable on the subject might agree with you (or not). Alanscottwalker (talk) 19:00, 1 February 2015 (UTC)

Inter-article consistency on matters of style is a good thing, that's why we have MOS. There is no reason or justification for flags to be used this way in San Francisco, for example, but not in Los Angeles. So it would make zero sense to take this up on the talk page for Los Angeles. ―Mandruss ☎ 21:11, 1 February 2015 (UTC)

So now we have at least three article linked in this discussion where the editors found the icons pertinent to the infobox. So, it's backwards to now say - 'oh no, we can't even be bothered to convince you at the article, we must shackle you and your editorial discretion.' Alanscottwalker (talk) 21:25, 1 February 2015 (UTC)

Oh I have no doubt there are many more than three. We have no way to know what was in the minds of those editors, and it's more than plausible to believe they just did it because the flags are pretty (which they are), which is a clear misuse per WP:ICONDECORATION. The only defense I've read is that current MOS represents a false consensus - which has been allowed to stand for seven years according to the person making that claim. We don't get to ignore guidelines because we don't feel they are legitimate; we either follow them or work to change them. ―Mandruss ☎ 21:32, 1 February 2015 (UTC)

You've misread the current MOS, it specifically allows these editors to do their good work, without you interfering in articles you claim to not even know about, much less care about - just because you for wish to disagree with their valid choices. Alanscottwalker (talk) 21:40, 1 February 2015 (UTC)

If some other part of MOS supports such usage, then it contradicts WP:ICONDECORATION and the contradiction needs to be resolved. As I read it, that's what this thread is about. Now that you're making it personal, this ends our interaction. ―Mandruss ☎ 21:49, 1 February 2015 (UTC)

The current MOS is clear enough on this - it's allowed; that's just you disagreeing with the proviso that already exists. Alanscottwalker (talk) 21:57, 1 February 2015 (UTC)

The desire is to change the current policy on this, because several of us feel that it is bad policy, and that it contradicts both other parts of MOS:INFOBOXFLAG, as well as other policies outlined by Onel5969 and Mandruss. That's why we came here for suggestions on the draft proposal. You can disagree with the attempts to change the policy, but you can't argue that editors don't have a right to try and change it. --IJBall (talk) 22:01, 1 February 2015 (UTC)

Yes. Unlike the prior interlocutor, you are aware that current guideline (not policy, MOS is not policy) has allowed this for a long time. Moreover, the evidence from articles is that the editorial choice has made sense to them for those city articles. Alanscottwalker (talk) 22:09, 1 February 2015 (UTC)

Well, the other issue is that it's been inconsistently applied – i.e. no flags at London or Paris or Berlin, or (most, but not all) articles on Canadian cities apparently, but flags at some (though not all!) U.S. city articles (and at some random European "village" articles" I've seen). So a consistency in guidelines seems to also be strongly desirable in this instance. --IJBall (talk) 22:23, 1 February 2015 (UTC)

Different places are going to have different needs, different relationships to their various jurisdictions, and different editors - so, I ask again why one size fits all - when it is only going to impinge on editorial judgement and discretion, where there is no need to do so. (there is no wish to force London editors to do anything, but somehow LA/SF/MANHATTAN editors must conform!) Alanscottwalker (talk) 22:28, 1 February 2015 (UTC)

• Oppose The longstanding consensus explicitly permitting the use of flag icons in settlement articles doesn't need to be changed. It does need to be clarified, as evidenced by the edit warring by editors who misunderstand the meaning of human and physical geography, which has been the underlying trigger for many of these battles. Alansohn (talk) 04:24, 2 February 2015 (UTC)
• Comment - remember also that there is a completed and finalized RfC that specifically allows flags for international sports people to be in the infobox. No one bothered to put it in the MOS for some strange reason, but it is the defacto consensus that it is allowed. Fyunck(click) (talk) 05:13, 2 February 2015 (UTC)
  • There is no value to the community in a consensus that exists only in the minds of one or two dozen editors among hundreds of thousands, and in some well-hidden archived thread that only they know about. If it's not in MOS, it's not a legitimate consensus as far as I'm concerned. The "some strange reason" you refer to is that somebody dropped the ball. ―Mandruss ☎ 05:23, 2 February 2015 (UTC)

    That would be incorrect. RfC's are quite binding and are sourced as protocol all the time. For instance the RfC that censors all English spellings of Foreign names, regardless of the amount of sources, never made it to MOS. Yet that RfC is the law of the land at Wikipedia and as ironclad as if it was in MOS. Fyunck(click) (talk) 06:12, 2 February 2015 (UTC)

    That is a completely unworkable system for all but the most experienced editors who have the time to keep up with such developments. But I'm not going to take this thread any more off topic by debating that with you here. ―Mandruss ☎ 07:24, 2 February 2015 (UTC)

    What's funny is, I agree with you. I used to argue as you just did but was slapped down pretty hard several times in the past when these RfC closings kept being alluded to in deference to what was plopped into MOS. I also complained about things put into MOS with no discussion whatsoever... things that had slipped in. I was told by editors that since no one complained at the time they were now, in effect, a MOS Guideline. So you never know what you'll run into at Wikipedia. It's an adventure to be sure. Fyunck(click) (talk) 07:55, 2 February 2015 (UTC)

    It's not the only way Wikipedia has become designed by the experienced, for the experienced, and yet we wonder why we can't keep new editors. Duh. ―Mandruss ☎ 08:00, 2 February 2015 (UTC)

I am confused by the original proposal where it states:

"I propose that we change the guideline to read that flag icons should not be used in infoboxes for ANY geographic articles, either physical or natural."

In this context I would assume "physical geographic articles" and "natural geographic articles" to be the same thing. Did user: Onel5969 mean to say "either political or natural" or "either human or physical"? --RacerX¹¹ Talk to me^{Stalk me} 10:34, 2 February 2015 (UTC)

Hi Racerx11 - yes, that's exactly what I should have written: "either human or physical" - as in keeping with the confused and contradictory way the guideline is currently written. Onel5969 (talk) 14:39, 2 February 2015 (UTC)

Oppose. Thanks Onel but I dont see anything wrong with guideline as it is. I have removed flag icons from over 5000 geographic infoboxes, using the guideline and referencing it in my edit summaries. To my knowledge, not a single one of those 5000+ actions have been reverted or challenged. I have done mountains, mountain ranges, passes, lakes, rivers, glaciers, deserts, and currently islands. The island articles can be hard to call. If the island itself has a flag, I tend to leave it in place because with some smaller islands, that article may be the only place on WP where we have the opportunity to show the reader that flag. For larger islands it's been fairly straightforward. Ireland and Great Britain do not get flags because those are physical geographic articles about those natural islands. At Republic of Ireland and United Kingdom, flags are welcome. It gets trickier with some of the smaller islands where their name is the same as a political subdivision. I those cases I go by the content and wording of the article. If in doubt I leave the infobox as is, with or without flag icons. --RacerX¹¹ Talk to me^{Stalk me} 15:22, 2 February 2015 (UTC)

• Strong oppose. Unhelpful rule creep, and Mandruss' comment of 08:00 is quite right. Nyttend (talk) 12:58, 2 February 2015 (UTC)

Request for clarification: I don't understand your position here, especially as it appears that Mandruss agrees with the OP (and myself) that the current MOS:INFOBOXFLAG policy is a mess that is in need of further clarity, especially in light of its contradiction with WP:ICONDECORATION. IOW, if you agree with Mandruss, it should seem that you should be in "support". --IJBall (talk) 16:33, 4 February 2015 (UTC)

• Oppose. Well meaning proposal, and I appreciate it being brought here rather than a lightly watched, local page. However, I agree with others that rule creep is unnecessary in this case, and I particularly endorse Dirtlawyer's comments. Ultimately, I find much of the prohibition against flag icons is built on a foundation of little more than WP:IDONTLIKEIT. Resolute 14:49, 2 February 2015 (UTC)

So, to be clear, you actually support junking MOS:INFOBOXFLAG in its entirety? Because that's what you seem to be saying. --IJBall (talk) 23:55, 3 February 2015 (UTC)

• Support - If for no other reason, sorting out this flag-in-the-infobox thing would cut down on a lot of edit waring. My experience with flags involves their addition to the infobox in articles about American and Canadian towns and cities. A small number of editors support them, and this has led to endless reverts, edit wars, and nowhere discussion on multiple talk pages, such as here, here, here, here, here, here, and here. Insofar as flags being added to "infobox settlement" templates, both "sides" interpret MOS:INFOBOXFLAG differently. Those that want to add flags, believe "MOS:INFOBOXFLAG" defines towns and cities as "human geographic articles", which allow flags. Those opposed to flags believe "MOS:INFOBOXFLAG" defines towns and cities as "both human and physical geographic subjects" (with the example being Manhattan), where flags can only be added after consensus has been reached. I feel MOS:INFOBOXFLAG needs to clearly define what each of these entities mean. I also feel infobox flags are cosmetic cruft. Thanks. Magnolia677 (talk) 04:40, 3 February 2015 (UTC)
  • There is no ambiguity about the use of flags in the infobox for populated places. There may be some confusion and misinterpretation, but it means what it says:
    • 1) "Human geographic articles – for example settlements and administrative subdivisions – may have flags of the country and first-level administrative subdivision in infoboxes" - Every article for a populated place is an article for a settlement / administrative subdivision, and they are "human geographic articles" because humans have defined their boundaries. So Chicago, Edmonton and Astoria, Queens are designated as appropriate places to put flags in infoboxes.
    • 2) "however, physical geographic articles – for example, mountains, valleys, rivers, lakes, and swamps – should not." So there are no flags in the infoboxes for Mount Rainier (mountain), Grand Canyon (valley), Mississippi River (river), Great Salt Lake (lake) or the Okefenokee Swamp (swamp), and it would be appropriate to remove flags from the infobox for Lake Ontario.
    • 3) "Where a single article covers both human and physical geographic subjects (e.g. Manhattan), or where the status of the territory is subject to a political dispute, the consensus of editors at that article will determine whether flag use in the infobox is preferred or not." There are no mountain cities (where a city and mountain overlap), nor is there a valley city, river city, lake city or swamp city. But there are places where a settlement / city (a "Human geographic article") overlaps an island (an example of a "physical geographic article"). While the overlap is not 100%, Manhattan is offered as the example of a case of a "single article [that] covers both human and physical geographic subjects" because it is settlement (as a borough of New York City or a county in New York) that is also an island. Note that Manhattan is chosen specifically for that reason, and not New York City, Chicago, Edmonton or Los Angeles; This exception has nothing to do with the size of the place or the scope of the article. This is the only ambiguous situation where consensus is needed, because of the overlap of human geography (may be used) and physical geography (may not be used).
  • If we read what the Wikipedia:Manual of Style/Icons guideline actually says, we would have fewer problems (and edit wars based on misreadings). Alansohn (talk) 18:18, 3 February 2015 (UTC)

This is the policy that we are trying to change. Really, the "carve out" for Flag Icons for human settlements is completely nonsensical IMO, and contrary to the spirit of MOS:INFOBOXFLAG as stated in its first 1-2 paragraphs. If that stays in, then I really think MOS:INFOBOXFLAG needs to be junked as a guideline in its entirety, as it's mishmash of mess right now. --IJBall (talk) 23:48, 3 February 2015 (UTC)

If Manhattan, as Alansohn asserts, "is chosen specifically" as an example of a city that is also a physical geographic article, simply because it is an island, then you'd think "island" would be included as one of the examples listed at MOS:INFOBOXFLAG of what a "physical geographic article" is? Instead, it specifically doesn't mention "island"; it states "physical geographic articles – for example, mountains, valleys, rivers, lakes, and swamps". Again, MOS:INFOBOXFLAG needs to be clarified. Magnolia677 (talk) 23:55, 3 February 2015 (UTC)

It seems clear that under the current MOS islands should be part of that. Is Manhattan an article primarily about a borough on an island (that's a flag icon), or is it primarily about an island with a borough on it (that's no flag icon)? Reasonable cases can be made for either. I have currently no opinion about whether that policy is good or should be changed, but that islands logically belong in the category physical geography is obvious, and arguing about that borders wikilawyering. Martijn Hoekstra (talk) 10:52, 5 February 2015 (UTC)

If a guideline is that prone to misinterpretation by intelligent people, it's a clear sign that it needs to be clarified. In many cases, possibly including this one, the guideline is actually more complex than is really needed, and some compromise could be made in the name of simplicity. The average 100-hour editor should not have to spend a lot of time studying the nuances of a guideline to apply it correctly. ―Mandruss ☎ 00:01, 4 February 2015 (UTC)

• After many years and many, many major disputes about the use of flag icons, I do not believe that they are ever appropriate in infoboxes, under any circumstances, with the exception of the country's flag on the article about the country. Edit warring about flags has resulted in some of the most contentious and damaging disputes on this project over the years. In fact, I would like to see the flag icons severely restricted so that they aren't present in templates either; whether people realise it or not, all those flag icons in the templates at the bottom of pages costs more load time than the actual written content of the page. Risker (talk) 23:55, 7 February 2015 (UTC)

  Exactly. They may look pretty, but there is never a good use of flag icons in the infobox. These lists, even the ones in the infoboxes, need to be moved to the appropriate sections and leave the infoboxes to the bare minimum. This will happen some day, but right now there are too many people who simply want them there for no other reason than that they want them there.--JOJ ^Hutton 00:59, 8 February 2015 (UTC)

  Yep. Classic I just like it. ―Mandruss ☎ 01:18, 8 February 2015 (UTC)

• Comment And some people might think they are useful when they are used in lists in the infobox, such as the examples previously mentioned, but what about This Bullshit on the Billy Casper and just about every Golf biography. This is clearly not a list and is clearly unnecessary to convey information. Unfortunately a single user has every single golf biography on his watch list and resists any and all attempts to remove these unnecessary decorations from the infobox. The user uses no other explanation other than that they are used. Huh?--JOJ ^Hutton 18:58, 8 February 2015 (UTC)
  • This is what happens when you leave too much to editorial judgment. To paraphrase an oldie but a goodie, if it weren't for bad editorial judgment they'd have no editorial judgment at all! ―Mandruss ☎ 19:05, 8 February 2015 (UTC)
• Let me know when it's over I personally don't think they belong in the infoboxes of any human except heads of state or founders of nations, but others disagree. I would rather not see them in articles for geographic locations, unless it is the flag for that specific location (national flags for nations, sub-national--provincial, state, county, city, etc.--flags for those areas) but it's currently an established practice to include all national flags in sub-national regions. The way to deal with this is to change consensus, not edit wars on individual articles against established norms. Walter Görlitz (talk) 00:21, 9 February 2015 (UTC)
• This problem has been solved! An editor went into Wikipedia:Manual of Style/Icons and arbitrarily changed the wording of the Manual of Style so it supported his own interpretation. No need for consensus anymore. Magnolia677 (talk) 23:18, 9 February 2015 (UTC)
  • That earns an automatic block, I hope? I can't make sense of the page history or I'd answer my own question. ―Mandruss ☎ 23:22, 9 February 2015 (UTC)
    • I'm not sure of the correct protocol for something like that, but even if we agreed with the change, shouldn't that change be reverted with an edit summary something to the effect of "This wording is currently being discussed at Wikipedia:Village pump (proposals)#Discussion (MOS:INFOBOXFLAG)"? The edit in question is still the current revision. And shouldn't the user be given at least some kind of informal warning? --RacerX¹¹ Talk to me^{Stalk me} 00:30, 10 February 2015 (UTC)
      • Meh... That change is not something even I would quibble with. The problem with that paragraph isn't the last sentence (current, or former, form) – it's the first half of the first one. --IJBall (talk) 21:37, 10 February 2015 (UTC)
• Keep as is most guidelines are imperfect and subject to wikilawyers' quibblings, but what was decided was a compromise that has ended the edit wars on whether flags should or shouldn't be on certain infoboxes. Truth is, the flags are all over the place: in geographic articles, sports articles, diplomacy articles, military articles, biographies, etc. {{flag}} says it's used on 398,000 articles. So, any change will inevitably mean lots of work of doing/undoing this - and no doubt more work when Consensus changes, which would better be spent in building an encyclopedia. Carlossuarez46 (talk) 20:46, 12 February 2015 (UTC)

Display of pending changes notice when latest revision is accepted

On pending changes protected pages, there is a small notice with some information on pending changes that is automatically inserted at the top right of the page, located on the left of the traditional protection icon, see e.g. at Red Hot Chili Peppers. Note that the accepted (latest) text is not visible to unregistered users. This functionality substantially duplicates the protection icon, isn't as customizable as the later since it's hard-coded, and is useful only when the latest version has not been reviewed (since it indicates that the latest version is unreviewed). I propose to change the behavior of this notice when viewing the stable version, so that it is shown only when the latest version is unreviewed (i.e., is pending). This way, it doesn't duplicate the protection icon and its presence is a signal making it more obvious when there is a pending revision. This would only affect unregistered users (who always see the stable version) and registered users having set their preference as 'show stable version'. From what I can see, this needs a bug request. Cenarium (talk) 00:42, 5 February 2015 (UTC)

Good idea. The hard-coded icon combined with the lock icon seem especially redundant when viewing a pending-changes protected article while logged-out. (Which always shows the stable version.) Tony Tan⁹⁸ · talk 02:29, 5 February 2015 (UTC)

I believe that idea should be filed under this project on Phabricator:. Whatamidoing (WMF) (talk) 00:54, 12 February 2015 (UTC)

@Whatamidoing (WMF): I've made a commit allowing such customization that awaits review. Cenarium (talk) 19:05, 16 February 2015 (UTC)

Pre-Speedy Deletion tag

I propose the creation of a Pre-speedy deletion tag. I have been on new page patrol for a while now, and one thing that continues to annoy me is people prematurely tagging articles. I feel you need to give the person at least 15 minutes to add content, and in most cases, justify its notability. I created the tag you see below and used it for about 3 days. It was very successful it letting other editors know that the article was already being watched and should not be tagged yet.

Example: {{db-pre}} Unit388 (talk) 05:39, 7 February 2015 (UTC)

• Strongest possible oppose. You are an extreme new user here with only a few days and very few edits. You need to understand that such proposals are discussed in depth at their respective talk pages and are expected to reach a consensus long before even a test is deployed. I have already deleted your unilateral work once and you have flagrantly recreated it again. Not even I get to unilaterally make new policy on Wikipedia - we do things in collaboration here. --Kudpung กุดผึ้ง (talk) 05:46, 7 February 2015 (UTC)
  • Hey. He was being WP:BOLD. That is still an allowed behavior here, regardless of how it might annoy some editors. Please exhibit some good WP:BITE tolerance. --User:Ceyockey (talk to me) 06:18, 7 February 2015 (UTC)

Kudpung it was a constructive attempt to improve the encyclopedia. We are not a bureaucracy and we encourage editors to be bold, even new ones. I don't think the idea of a notice warning that a CSD may happen if it is not improved is a radical change. It is not as though Unit was suggesting the use of the tag to be be mandatory. The argument that some time should be given to meet standards before CSD is applied seems like a good one. Chillum 06:33, 7 February 2015 (UTC)

Ironically, Kudpung violated speedy deletion to enforce speedy deletion. Restore it, Kudpung, take it to TfD if you have a problem with it. Oiyarbepsy (talk) 07:13, 7 February 2015 (UTC)

No he did not. The deletion was consistent with WP:CSD#T2. The template did make statements that were a misrepresentation of policy. While he may have handled things better the deletion was not the problem. Chillum 07:48, 7 February 2015 (UTC)

• • I think it goes without saying that I think people should not bite and should assume good faith... --Biblioworm 15:57, 7 February 2015 (UTC)
    • AGF? sure. But BITE? Lets not kid ourselves on that point. This is a new account, but not a new user. If it is who I believe it is, I am mostly just curious to see how long it will be before they fall back into old habits. Resolute 17:39, 7 February 2015 (UTC)

      @Resolute: How can you tell this is not a new user? --User:Ceyockey (talk to me) 20:37, 7 February 2015 (UTC)

      New users don't have the system savvy this one does. They don't start out with new page patrolling - they wouldn't even know what it is. They typically don't understand how to create templates and don't form the sort of convictions that Unit388 displayed from basically their first edit. This is an account with an agenda. The proposal itself is fine and dandy, but I dislike when histories are masked. Resolute 19:31, 8 February 2015 (UTC)

      Newbies aren't always clueless. What if he's a former IP, or a legitimate clean start? We shouldn't make legitimate users play clueless when they're really not. After all, I did start with NPP (I stumbled across it somehow), so I guess that I have to be hiding my history, right? As the essay says, we should focus on improving Wikipedia rather than spend our time trying to figure out what sinister "agendas" an intelligent newbie has. --Biblioworm 13:34, 11 February 2015 (UTC)

      Also, I believe that one of the persistnt complaints about NPP is precisely that too many newbies are involved. (I don't know if it's true, or what percentage constitutes "too many", but it's been a common complaint.) WhatamIdoing (talk) 01:35, 12 February 2015 (UTC)

Where this would be useful is for re-creation speedy deletes. Non-admins can't tell if a page actually is a re-creation and need admins to review the previous version to compare. I can't say anything about the tag created here, since it was deleted. The concept described by the original poster does not obviously violate policy. Oiyarbepsy (talk) 07:13, 7 February 2015 (UTC)

The example was deleted but have a look here if you want to see what it looked like. https://en.wikipedia.org/wiki/User:Unit388/draft-speedy Unit388 (talk) 07:16, 7 February 2015 (UTC)

I think a tag like this is a good idea. But, it's incomplete. It shouldn't be the obnoxious deletion-red, and it needs to print how long ago the tag was placed in case the original placer forgets to check up on it. Also, the text size is obnoxiously large. Oiyarbepsy (talk) 07:20, 7 February 2015 (UTC)

I agree that the original implementation was not ideal but this is a wiki after all. I have read the deleted template and I think if something like this is developed we should jut start fresh. A carefully crafted tag by a group of editors could provide a much needed optional choice to give editors time to salvage their content. I have seen many times a CSD'd article been undeleted and brought up to standards, why not skip the middle part? Chillum 07:44, 7 February 2015 (UTC)

Well if we are having to start fresh, here are some things we can keep/add/remove:

• Red backround
• Big red cross
• Includes the text "Marked for Pre-Speedy Deletion"
• Includes the text "do not mark this page for speedy deletion"
• Includes the name of the user who placed the tag
• Includes time created stamp(or some type of countdown)
• Includes warning not to remove the tag
• Includes justification for placing the tag

Unit388 (talk) 09:13, 7 February 2015 (UTC)

Alright I was able to get a clock going, but its not fully operational yet.

{{User:Unit388/draft-speedy|Unit388}}

Unit388 (talk) 10:09, 7 February 2015 (UTC)

I just took the liberty of changing the formatting of your draft. The heading code was doing unpleasant things to the section headings here. —C.Fred (talk) 17:06, 7 February 2015 (UTC)

• Support, in principle. I think it would be a good idea for patrollers to have some tag to let others know that the author should have time to work on the article. However, I think the name and design of the tag could be improved upon. --Biblioworm 15:57, 7 February 2015 (UTC) Oppose, per Fuhghettaboutit's comment. I wasn't aware of that template's existence. --Biblioworm 00:31, 8 February 2015 (UTC)
• Could this problem be solved by informing new page patrollers to not speedy tag new articles seconds after they're created? That appears to be the crux of the issue. Sam Walton (talk) 16:59, 7 February 2015 (UTC)

IMHO, that depends on the nature of the speedy. Copyvios should get speedy-deleted on sight. Spam gets a little more leeway to see if the article can be fixed. Personally—and even though I'm an admin and have the technical capability to delete on sight—I give the creators of an article about 10 or 15 minutes if I've tagged it A7. That gives them time to provide references or explain the situation. It would be nice to have that in-between of "Oh, that new page you just created? It needs some work ASAP or it will be deleted." —C.Fred (talk) 17:08, 7 February 2015 (UTC)

If you give people 10 or 15 minutes then I don't know what's stopping anyone else from doing so too. If we did want to take some steps towards helping new users we could include some directions on how to move a page to userspace to the A7 tag, or how to contact the tagging user to inform them you're about to fix the article and to please remove the tag. This seems like a convoluted solution to a simple problem. Sam Walton (talk) 17:28, 7 February 2015 (UTC)

• I also support the concept, in principle. I've thought about adding one particularly for A7 articles with a message along the lines of "This article, in its current state, is a candidate for speedy deletion. It was recently created, so the creator is being granted more time to expand the page. If you are the creator: Please expand the article to clearly state how the subject is notable, significant, or important, and please cite reliable sources independent of the subject that show its notability. If you are not the creator: please allow the creator of the page to improve the article. If, however, a reasonable period of time has passed and the article has not been worked on, feel free to proceed with the speedy deletion process." —C.Fred (talk) 17:02, 7 February 2015 (UTC)
• Oppose - We have a conspicuous warning above the edit window when creating new articles. We also have draft space, user sand boxes and an article creation process. While I agree that most articles should not be tagged for speedy deletion seconds after creation, I don't think placing a four day (or even four hour) speedy deletion moratorium is helpful. I might have a different opinion if we didn't have nearly 10,000 unreviewed articles, many of which should be deleted for various reasons.- MrX 17:40, 7 February 2015 (UTC)

That 3 day countdown is an example. The intent was to have a 15 minute clock.(Turns out template coding is hard!) Unit388 (talk) 22:50, 7 February 2015 (UTC)

• Oppose - As noted by MrX, editors should not create incomplete articles in article space, and incomplete articles in article space may be speedied. Adding the content or references is what draft space or named user space are for. Robert McClenon (talk) 17:57, 7 February 2015 (UTC)

  @Robert McClenon: "...editors should not create incomplete articles..." ← Sorry, but this is not a sensible statement. 99% of articles are incomplete, and those which are "barely there" are suitable for being tagged with {{stub}} and it's family of templates. --User:Ceyockey (talk to me) 19:40, 7 February 2015 (UTC)

  I meant, of course, that editors should not create very incomplete articles, articles that are so incomplete that they qualify on their face for speedy deletion. Robert McClenon (talk) 19:48, 7 February 2015 (UTC)

  @Robert McClenon: I'll not think "of course" when seeing a comment like you made because there have been editors who feel exactly as you stated (now I do not count you among them, as you've clarified) who feel that even the stub I created here (and subsequently expanded) should not be in article space as it is not of sufficient quality for any encyclopedia. Fortunately, that type of editor has gone nigh on extinct over the past 10 years. --User:Ceyockey (talk to me) 19:55, 7 February 2015 (UTC)

  Actually, Robert, the existing CSD policy says that you should not tag articles for speedy deletion on grounds of being incomplete (A1 and A3) during the first 10 minutes or so of their existence. The only obvious difference between what the new editor wrote and what the policy already says is that the one says "about 10 minutes" and the other says "about 15 minutes" (and generates an edit conflict when you add it, which is highly undesirable [because inexperienced editors usually lose their work—the very work you were demanding—when they encounter an edit conflict]). WhatamIdoing (talk) 01:35, 12 February 2015 (UTC)

• Oppose—There are multiple existing options for giving editors with a desire to delete on sight pause. Among these are a) the {{stub}}—related templates I mentioned above, which signal "this article is just barely getting started; please help to build it" and b) {{In use}}, which signals that there is editing in progress and that deleting it will just interfere with improving the article. I think there are other examples to add to these. With respect to the {{In use}} template, if there is not a timer attached to this, it would be a good thing to add one. Another possibility is to auto-add either a stub or in-use template when an article is created. --User:Ceyockey (talk to me) 19:45, 7 February 2015 (UTC)
• Oppose I can't really see the point. If an article looks like it's really got a future but is incomplete, it's better to suggest userfication. If it looks decidedly iffy, one might as well use prod. If it's a really speedy speedy case, it shouldn't be used. The template above looks more intimidating to me than the actual speedy template. I do agree that some things are being tagged too soon, but that doesn't mean they're going to get deleted that soon. Spam, attack, blatant hoax and copyvio - yes, they go asap. And total no hoper A7s like "Shaun is in year7 and he likes mrs Dobson and plays fotball"... Other things can wait for around an hour, and I for one leave them around that long. Peridon (talk) 20:19, 7 February 2015 (UTC)
• Oppose Speedy deletion is a deliberately simple and quick process with strong community support. There is no need to addd a pointless new layer of process to it. Beeblebrox (talk) 21:22, 7 February 2015 (UTC)

I agree that it would be better if editors just waited abit, but unfortunately it doesn't work like that. It seems to have become like a race to see who places a tag first. Another thing i'v noticed is that admins don't really assess the articles creation time, if they agree with the tag they delete it.(This is a good things, it means once reviewers have done their job the deletion can take place fast). So, the area of error is the users. I think new page patrol should should become more a review process. A reviewer takes an article under their wing, they are then responsible for the follow up. Unit388 (talk) 22:46, 7 February 2015 (UTC)

Try this for size (with proper formatting):

In my view, any tag like this should be optional and only for new pages. Oiyarbepsy (talk) 21:35, 7 February 2015 (UTC)

• Totally oppose, since the concept already exists: Articles have WP:PROD, templates and some file criteria have a 7-day waiting period, and G13 has a 6-month wait. The route for creating delayed speedy deletions would be to propose a new criterion, or propose changes to an exiting one. Not pursuing either of the paths I just mentioned and supporting this discussion's changes equate to unnecessary instruction creep. Steel1943 (talk) 22:52, 7 February 2015 (UTC)

• ...And, also oppose per Fuhghettaboutit since {{Hasty}} exists. In fact. I don't see any reference of that template anywhere on Wikipedia:Criteria for speedy deletion; information about {{Hasty}}'s existence and use should probably be added to the speedy deletion criteria page. (Pinging Chillum since they also referred to this template in one of their comments below.) Steel1943 (talk) 02:27, 8 February 2015 (UTC)

• Oppose perl Steel1943 Steel makes a very strong point that this is already a thing in the criteria that need it. I also agree that any template must follow a change in policy that supports it. If we choose to alter the policy so that a warning time can be given then we can create such a template or just modify an existing one. Chillum 23:01, 7 February 2015 (UTC)
• Oppose as redundant with existing template. Er... guys and gals – what this discussion seeks already exists, and in a form that does not transgress some of the concerns raised here, and exactly tracks the consensus from many discussions that resulted in Wikipedia:Criteria for speedy deletion#cite_note-Hasty-6. I created it in 2008 and though it is used, and to good effect, obviously it needs better advertising or this conversation would have been cut short by someone bringing it up. See {{hasty}}.--Fuhghettaboutit (talk) 23:10, 7 February 2015 (UTC)

• Wow, did not know about that. It is worth noting Wikipedia:Templates_for_discussion/Log/2013_December_1#Template:Hasty where this template underwent community review and was kept. Chillum 23:45, 7 February 2015 (UTC)

• Yeah... shudder... possibly the most frustrating thread I've ever been involved with at Wikipedia, because most of the people responding just did not understand the template's purpose, use background or function.--Fuhghettaboutit (talk) 00:01, 8 February 2015 (UTC)

• I'm unable to read in depth here, but multiple similar other templates already exist and integrating functionality into the Db templates to ensure the article isn't deleted as csd if it's too new and still being worked on is pending a magic word that was requested on bugzilla quite some time ago. I'm unable to look up the number right now, but will as soon as I can for anyone interested. — {{U|Technical 13}} (e • t • c) 03:08, 8 February 2015 (UTC)
• Oppose - Personally .... I see no point in it whatsoever, We have different and imho far more helpful tags so yeah I just don't see the point. –Davey2010^Talk 03:58, 8 February 2015 (UTC)
• Oppose - Per Fuhgettaboutit: the Hasty template is sufficient for the proposed purpose. Shanata (talk) 06:40, 8 February 2015 (UTC)
• Well, yes, but the Hasty template is only placed after the Speedy tag has gone (if there's even time to do that... these things move fast sometimes). Besides which, 15 minutes? Reallty? What's your hurry? It it's not libel or penis vandalism, there's no hurry. Relax. Don't let the "speedy" in "speedy deletion" confuse you; it really means "no-brainer deletion", speed in the sense of not requiring the man-hours of a well-populated and drawn-out discussion than speed in the clock or calendar sense -- again, aside from emergencies.

We want to avoid placing speedy templates if it is at all reasonable to do so. We do have {{Under construction}} which looks like this

Category:Pages actively undergoing construction

and which is usually placed by the editor doing the work but can be placed by anyone I suppose, and allows several days for the article to be brought up to some reasonable level of qualify. I'd recommend to the OP and anyone else who comes across an article that's no good but 1) isn't an emergency (libel etc.) and 2) has some reasonable chance of possibly becoming a marginally useful article, to apply this tag. Jesus, give the guy more than 15 minutes for chrissakes. Herostratus (talk) 14:49, 8 February 2015 (UTC)

I think that's an excellent point point. Between the under construction tag, the hang on tag, and PROD we already have this covered. All three have been in use for a very long time and are supported by the community. This pre-speedy isn't and shouldn't be. It's an overly simplistic idea that would inevitably cause more problems than it solved. Beeblebrox (talk) 19:36, 8 February 2015 (UTC)

• Oppose - an alright idea in the spirit of not biting the newcomers but this is what WP:PROD is for. Speedy deletion is for pages that have absolutely no hope whatsoever of being accepted as articles, because they're nonsense, they make no attempt to establish notability, they're obviously made up, they are blatant attacks, they have technical issues, and so on. Pages which qualify for speedy deletion are obvious - that's why we allow bypassing the normal collaborative deletion processes (i.e. discussions). The criteria are not for articles which just need more time or more content to get better, and someone who tags such an article for speedy deletion is abusing the process. Ivanvector (talk) 15:13, 9 February 2015 (UTC)

• Oppose Speedy Deletion is not lightning fast (though it could be), it's designed to dispose with unnecessary red tape and discussions in which there is no hope for besides deletion via our regular speed deletion processes (Prod, XfD, etc). Criteria for Speedy Deletion have been finessed and debated for a significant time and we've come to a community endorsed consensus on how to interpret the Criteria. The main complaint, as I see it, is that nascent pages are being nominated for CSD far too soon after their creation. If that's the case, creating a technical speed bump does not help with operator error. Train people using the NPP tool on how to consider things better or remove them from the activity stream (either via polite request or topic ban). Bike-shed solution in search of a problem to fix. Hasteur (talk) 18:57, 12 February 2015 (UTC)

• Idea: modify the speedy deletion template to append a category when it is added. The category should be the current time (GMT) rounded to the nearest 10-minute mark, plus an agreed-upon Grace Period. Since speedy deletions are supposed to be speedy, a date is not required, which allows the categories to be continually reused. The Grace Period may be very short, or nonexistent, for certain deletion reasons i.e. random ranting about your neighbor complete with address and credit card number, but should be hours long for most reasons like patent nonsense or completely uncited. The template, as pasted, should indicate how long the Grace Period is. Edits by someone other than who posted the template that alter the time listed or remove it can be flagged by abusefilter for further examination. Wnt (talk) 16:52, 17 February 2015 (UTC)

Why on earth would we want to allow an hours-long grace period for patent nonsense or completely empty pages? Nothing of value is lost when they are deleted. Beeblebrox (talk) 23:34, 17 February 2015 (UTC)

NPP review structure

In light of the pre-speedy deletion tag failing to gain consensus, I propose we change NPP to allow a reviewer to take an article under their wing, to be exclusively their review project. AFC allows a user to mark an article as under review, this is effectively what I'm proposing.

Benefits:

• Would not interfere with those who don't adopt the system as it will be optional.
• Allows more careful investigation before tags are placed
• Moves NPP in the direction of more experienced reviewers
• Could latter be expanded into article categorization for custom review scripts(like AFC)

Example tag:

{{User:Unit388/draft-review|Unit388}}

Don't fear change people. Unit388 (talk) 02:57, 8 February 2015 (UTC)

• Has there been an issue with the NPP process that this is intended to address? Praemonitus (talk) 03:44, 8 February 2015 (UTC)

• Echoing an issue raised in the discussion of the previous proposed template, what is the need for this? We already have planned changes to the CSD templates to prevent tagging of a new and active article waiting on needed support in the software. This looks to me like creeping bureaucracy. Further, take an article under their wing, to be exclusively their review project(emphasis mine) sounds like a proposal to weaken WP:OWN. Unless, I've misunderstood something here, my position on this proposal is "No... just.... no". Pathore (talk) 06:40, 8 February 2015 (UTC)
• Oppose This looks unnecessary. If a reviewer is talking with (not just 'to') the author (meaningfully) about improvement, and there are signs of this getting through, the article should be given leeway by other patrollers and admins. If the reviewer is really serious about reworking things, they can userfy it and work with the author on it, or if it needs very little work, just don't tag it and do get on with it. But there is no exclusivity involved. Or again, just put a note on the talk page to say that things are being sorted. Admins SHOULD check the talk page before deleting, and if they don't, can simply restore it when they go to delete the talk page. I could see the use of this template possibly being abused or misused. Peridon (talk) 13:25, 8 February 2015 (UTC)

  Thanks for your note. I've responded on my talk page. -User:Peridon

+1. Supporting Peridon's 'oppose' arguments. --User:Ceyockey (talk to me) 06:12, 12 February 2015 (UTC)

It should be noted that Unit388 is selectively canvassing editors for support on the above two proposals. Resolute 19:36, 8 February 2015 (UTC)

• Oppose Clearly a knee-jerk reaction to the discussion above, seems to violate WP:OWN and is something a user can do if they wish without needing any tags or new, needless processes. Beeblebrox (talk) 19:42, 8 February 2015 (UTC)
• Oppose - A case has not been made for the need or utility of such a template. I would strongly urge the proposer to learn more about Wikipedia and NPP before proposing any more such templates.- MrX 19:48, 8 February 2015 (UTC)
• Neutral - I don't see the harm in this. My only concern is the language "to be exclusively their review project" (emphasis added) - this violates WP:OWN. No page on Wikipedia is exclusively anybody's. However, I think that the effect of this proposal is already covered nicely by {{Under construction}}, and I don't see the point in duplicating it. And I especially don't want to see AfDs with oppose comments like "You can't delete this article on my basement web business! It's tagged as under review!" and I'm worried that this opens that door. Ivanvector (talk) 15:38, 9 February 2015 (UTC)
• Oppose, solution looking for a problem I think. Stifle (talk) 11:50, 16 February 2015 (UTC)

Delete "autochecked" usergroup

The autochecked usergroup has no use since its unique permission, 'autoreview', is possessed by all autoconfirmed users, and in order to be effectively autoreviewed, 'autoconfirmed' is checked too. Due to the way FlaggedRevs is written and for compatibilities with other configs, it is not possible to make it into a potentially useful group as was thought originally. Therefore, I suggest to simply delete it. Cenarium (talk) 09:18, 12 February 2015 (UTC)

• Oppose as Wikipedia:Autochecked users tells us that it is required for WP:ORANGELOCK pages. Since there are pages using that level of protection, and There is only a consensus for implementation if and only if an rfc concerning criteria for its use gains community-wide consensus first. (PC/RfC 2013), there is consensus for proposals 1 and 2 and 7 to be used as criteria, but only if PC2 is implemented in the future.(PC/RfC 2014) then it is improper to delete this usergroup there certainly is potential and we just need to put the pieces together in the 2015 proposal and see if there is consensus to establish PC2 using the wording in proposals 1, 2, and 7. — {{U|Technical 13}} (e • t • c) 17:11, 12 February 2015 (UTC)
  • @Technical 13: I have written the documentation on autochecked you cite, and as it seems unclear I rewrote it. I had exactly the plan you mention in mind for this group until I started delving into FlaggedRevs code to help in developing deferred changes, and passive reviewing, and it's clear that "autoreview" cannot be used for this purpose since all autoconfirmed users must have it. Cenarium (talk) 19:12, 12 February 2015 (UTC)
    • I'll need to dig in to the technicalities of how PC2 works on another day when I'm not in class, but I'm fairly certain it can be done. Then we can have a discussion on how it works and if the community still wants to have the ability to flag people to bypass all PC without just giving them PC reviewer which might be another topic all together. Where was the discussion to create this usergroup, that might be useful to help understand some of the background. Thanks. — {{U|Technical 13}} (e • t • c) 19:32, 12 February 2015 (UTC)
      • There was no discussion, it's bundled with FlaggedRevs and should have been unset from the start. If we want to allow autoreview on PC2 without review, then we need to create another userright for it, e.g. "super-autoreview", but "autoreview" cannot be used. Cenarium (talk) 19:47, 12 February 2015 (UTC)
• oppose The current limited "IAR" use of PC2 is actually a good thing, it's acting as a very limited trial that will inform any future discussions on the use of PC2. (i.e. the wiki won't crumble if we use it in limited cases). I'd say the future prospects for PC2 are good at this point and we shouldn't mess with its technical basis right now. Gigs (talk) 17:50, 12 February 2015 (UTC)
  • @Gigs: As noted above, it's technically impossible to use this group for the purpose you mention. Cenarium (talk) 19:12, 12 February 2015 (UTC)
    • Nothing is technically impossible, you just haven't figured out how to make it work yet. — {{U|Technical 13}} (e • t • c) 19:32, 12 February 2015 (UTC)
      • It's technically impossible to use the 'autoreview' userright for this purpose due to the way FlaggedRevs is written now, and this cannot be modified in any way that would satisfy developers, I'm pretty sure of that. 'autoreview' is the first check made, and all others follow, bypassing this check would cause issues with other configs, or it would require a hack, when the alternative of using another userright check for it is preferable. Cenarium (talk) 19:47, 12 February 2015 (UTC)
        • Does it hurt anything to leave it, even if it is buggy? Gigs (talk) 19:51, 12 February 2015 (UTC)
          • Yes, it does, it confuses people, and they can see it from plenty of places where this confusion can't get cleared up. For example at Special:ListGroupRights, the description 'Have one's own revisions automatically marked as "accepted"' can be true or false depending on whether the group also has 'autoconfirmed' or not. It's the third group at Special:ListUsers, it wastes people's time. Cenarium (talk) 20:01, 12 February 2015 (UTC)
            • "People" is very broad---readers never see this, and I'd gamble that a large variety of editors never venture in to those special pages. — xaosflux ^Talk 20:12, 12 February 2015 (UTC)
              • The page gets hundreds of page views each month. We can't know how many see the usergroup and its misleading name and description, but it's probably much more than that, a thousand a month at least, and those who don't click can't get cleared up about the purpose of the group. Cenarium (talk) 10:09, 13 February 2015 (UTC)
• Support It's completely useless. @Technical 13 and Gigs: Even if we were to allow PC2 at some point, the group as it stands now would still be useless, since there'd be no way to allow its members to review pages that autoconfirmed users couldn't do. (Yes, we can change this, but we can also bring the group back if we ever want PC2.) Jackmcbarn (talk) 12:51, 13 February 2015 (UTC)
  • Seems like unnecessary BIKESHEDing to me. I don't approve of that, but if the rest of the community insists it be red instead of blue, I won't put up too much of a fuss about it. I think too much user time is being wasted on this group to remove it just so we can add it back later, and I won't be specifically watching... — {{U|Technical 13}} (e • t • c) 15:52, 13 February 2015 (UTC)
    • It's very little time compared to the cumulated time wasted by the hundreds of users seeing this page every month, and those who don't click it and get confused about it. And again it wouldn't be a matter of adding it back, it cannot work as is, we'd need other userrights, and we might as well use WP:Autopatrolled. I honestly thought it would be uncontroversial, especially when all is needed is to change two lines in the config. Cenarium (talk) 12:34, 15 February 2015 (UTC)
• I guess I support this, but this useless "autoreview"/"autochecked" group should not be getting created by FlaggedRevs in the first place. Although Hungarian Wikipedia made this request on a local-wiki basis in phab:T74055, I think it would make more sense to see why this group is getting created, and to get rid of it (or at least make it optional) in the FlaggedRevs code. It's clearly something we don't need here. — This, that and the other (talk) 13:17, 16 February 2015 (UTC)
• Fix: Remove the "autoreview" right from the group. Create a new right which does grant the ability to be automatically reviewed, and assign that right to this group. Technology is plastic. I don't see any satisfactory explanation of why this is impossible beyond "we haven't written it yet." --NYKevin 23:27, 17 February 2015 (UTC)

Proposed change to unsigned templates

Right now if you place an {{subst:unsigned}} template (and its many sibling templates), you get something like this:

Here's my comment blah blah blah. — Preceding unsigned comment added by Example (talk • contribs) 00:00, 12 February 2015‎

I suggest changing it to this:

Here's my comment blah blah blah. Example (talk) 00:00, 12 February 2015‎

This is all about good faith. Everyone forgets the tildes sometimes, so why should there be a permanent record of a routine ordinary goof? Such a scarlet letter is not good faith. The link on the word unsigned is not vitally important. The signing bots will post on user's talk pages if they forget several times, and experienced Wikipedians will tell new users this too. The worst that happens without it would be that the sign-bots sign a few more posts, which isn't a problem. Oiyarbepsy (talk) 03:00, 13 February 2015 (UTC)

Generally we don't want to change things on talk pages, even if we're "correcting" mistakes (such as leaving out a signature), in such a way that is misleading as to who it was that made the change. The unsigned template specifies that the previous comment was unsigned so that it easy to see which part of the comment was written by the original poster and which part was added later. --Preceding signed comment added by Ahecht (TALK
PAGE) 03:40, 13 February 2015 (UTC)

Well, you could place a small note stating Signed by Someone'sBot Oiyarbepsy (talk) 05:45, 13 February 2015 (UTC)

• It's kind of funny to me that {{Unsigned}} violates the typical form defined in Wikipedia:Talk page guidelines#unsigned of —[[User|''USERNAME'']] ''TIMESTAMP OF EDIT'' (UTC) yet is encouraged to be used despite the fact it is a template that appears to me and a few others at least to indicate bad faith. What I find even more hilarious is that the following section, Wikipedia:Talk page guidelines#sigclean it is indicated that attempts to fake a signature may be edited in a way that changes the signature to the standard form with correct information (—{{subst:User|USERNAME}} TIMESTAMP OF EDIT (UTC)) or some even simpler variant. So, why not just dump all of the unsigned templates and make it easy by just one template for all situations? — {{U|Technical 13}} (e • t • c) 04:06, 13 February 2015 (UTC)

I am not sure I follow the logic here, and I have studied some.

1. User X forgot to sign their post.
2. Therefore, user X is evil. QED.

Please enlighten me. — Keφr 19:22, 13 February 2015 (UTC)

I see no badge of shame here; that seems to be a gloss added by the reading of the linked word "unsigned" as having an accusatory effect. I read it as a simple, neutral statement of fact which serves the dual functions of informing the user of the need to sign while also sending them to an information page to learn about signing, and by context making it clear the post is not by the user (an important clarification to the user and everyone else). I'm sure gobs of users have learned about signing as a result of this template. The timestamp is not left out of the template (see its documentation). The fact that the timestamp is not usually included is just a function of the bot that places unsigned being too dumb to be sure which revision in the history is the correct one right? If that complexity could be added to the bot, I'd support that, but I don't see a need for a change to the template.--Fuhghettaboutit (talk) 19:38, 13 February 2015 (UTC)

• I also find it puzzling why anyone would perceive a simple mistake being corrected as implying an assumption of bad faith. Beeblebrox (talk) 20:46, 13 February 2015 (UTC)

We could use a variant on User:Oiyarbepsy's proposal:

Here's my comment blah blah blah. p.p. Example (talk) 00:00, 12 February 2015‎

which is closer to usual sigs, but makes the action clear and retains the link to Wikipedia:Signatures. (See Per procurationem.) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:28, 13 February 2015 (UTC)

I'd rather we use a note that we don't need to explain to everybody. P.p. is obscure, even for a Latin abbreviation. Thus my suggestion, signed by user or signed by another editor if not specified. Oiyarbepsy (talk) 00:33, 14 February 2015 (UTC)

In case you didn't notice, my suggestion not only includes a link, but also abbreviation markup (try hovering your mouse pointer over "P.p"*; or view the source HTML code). And "P.p." is the correct annotation to use in such a case. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:23, 15 February 2015 (UTC)

I like this idea. Obscure or no, it takes up very little space. Although "p.p." is obscure, Wikipedia is hypertext, and it would be a link to Wikipedia:Signatures, where the Latin abbreviation could be explained. Pathore (talk) 03:51, 14 February 2015 (UTC)

Like Pathore, I like the p.p. with mouseover and link. It is concise and indicates exactly what was done rather than delving into why it was done. However, might be better to have:

Here's my comment blah blah blah. --xyzq p.p. Example (talk) 00:00, 12 February 2015‎

The template could take the form of {{subst:ppsign|Example}}, where ~~~~ was added by the code in order to deter spoofing (i.e. user:qwerty using the template instead of user:xyzq but attributing it to user:xyqz). --User:Ceyockey (talk to me) 12:35, 16 February 2015 (UTC)

This change would affect all unsigned templates currently in use unsubsted and would therefore change many archive pages etc. Also, this proposal amounts to autosigning, so new users won't learn how to sign properly. Then, once they get above the signing bot's edit threshold of 800 edits, they'll wonder why their signatures don't show up any more. Also, as I have previously said, the template as it stands is not a sign of bad faith. Any reasonable person will understand that people make mistakes -- including experienced users -- and won't hold it against newbies. Per Kephir, I just don't comprehend it. BethNaught (talk) 08:15, 14 February 2015 (UTC)

The signature bots all put a notice on user talk pages if a user repeatedly fails to sign, so they will know. Oiyarbepsy (talk) 09:00, 14 February 2015 (UTC)

Changing archived pages in this manner would do no harm; and there is plenty of precedent for changing templates which are unsubst on such pages. We already use Autosigning. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:19, 15 February 2015 (UTC)

In my experience the few users who are actually bothered by this just go back and add their signature. I don't see any tangible benefit to this idea, frankly the whole thing seems petty and unimportant. Beeblebrox (talk) 23:13, 15 February 2015 (UTC)

Lower case type for all internationally recognised terrorist and criminal organisations, and convicted criminals.

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

re - http://en.wikipedia.org/wiki/Islamic_State_of_Iraq_and_the_Levant etc

Don't use capital letters for these psychopaths - it only serves to boost their status.

islamic state; they are not islamic, they are not a state.

They are not even muslims.

isil

isis

Call them daiish – apparently they don't like it and it is used as a derogatory term in some parts of the Middle East. Though even this is just another acronym of islamic state.

Only use lower case type for all internationally recognised terrorist and criminal organisations, and convicted criminals.

Please pass this to your policy making people asap

PWWJ — Preceding unsigned comment added by P W W Jones (talk • contribs) 21:28, 15 February 2015‎

Wikipedia merely summarizes mainstream academic and journalistic sources and uses the terms they use. Capitalization is not intended as any sort of glorification. Ian.thomson (talk) 21:49, 15 February 2015 (UTC)

We use what the reliable sources use. They capitalize, we capitalize. If you think this change should be made, go talk the reliable sources into changing how they refer to these organizations/people and then we will follow suit. -- GB fan 21:50, 15 February 2015 (UTC)

English has rules for using capital letters. Proper names in English are capitalized; see MOS:NAMECAPS. Further, "ISIS" and "ISIL" are also acronyms; see MOS:CAPSACRS. Pathore (talk) 22:08, 15 February 2015 (UTC)

I would like to add, regardless of what the sources add, Wikipedia goes by the rules of standard English. If the sources fail to use this, then they fail to be reliable sources.--Nadirali نادرالی (talk) 01:05, 16 February 2015 (UTC)

Indeed, until daiysh becomes the accepted name in English language reliable sources, we can't use it. As nice as it would be and as many editors would agree with you, certain rules are in place and must be followed, with only a certain amount of room for bending. Sir William Matthew Flinders Petrie | ^{Say Shalom!} 26 Shevat 5775 22:23, 15 February 2015 (UTC)

• Per all the above, as much as we might personally dislike a group or person, we do not and should not deliberately insult them either. This would create a very slippery slope that is best avoided. Beeblebrox (talk) 23:10, 15 February 2015 (UTC)

Welllllll, you could insult the them in every-day life, in social media, and everywhere else as is only right given that they are khawarij, but it mustn't get into the editing process here, of course. One productive thing you could do is to be vigilant on Daiysh-related articles for POV-pushing edits as there are some supporters of this group that like to help out their 'cause' and turn Wikipedia into another battleground. There's tons of people watching those articles already, but it never hurts to have an extra set of eyes. Just be civil about it as you are better than them. Sir William Matthew Flinders Petrie | ^{Say Shalom!} 26 Shevat 5775 23:55, 15 February 2015 (UTC)

I suppose the real question is who defines which entities are the terrorists. A few terrified Iraqi civilians might like to put george w. bush at the top of that list, even if he calls what he is doing "shock and awe" instead of "terrorism". Furthermore, if one looks at the manner in which anti-terrorist legislation is being abused in the United Kingdom, the supposed terrorists are anyone from Icesave to the Guardian newspaper. K7L (talk) 22:14, 16 February 2015 (UTC)

In terms of editing Wikipedia, the reliable sources as always. Sir William Matthew Flinders Petrie | ^{Say Shalom!} 28 Shevat 5775 04:56, 17 February 2015 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Should tagged recent changes be shown as unpatrolled ?

Tags added by the edit filter or, when implemented, by bots can be very helpful to track down certain type of vandalism, other inappropriate changes, or wikitext mistakes and visual editor bugs, among other things. Tags are listed at Special:Tags and recent changes can be filtered by tag. However, it is difficult to know when an edit has been checked - one needs to load page history and check manually when not the latest. This is inefficient, but could be improved using the native patrolling feature of mediawiki. For users with permission to patrol (at the moment, autoconfirmed users), a red exclamation mark would be visible next to unpatrolled tagged changes, and when clicking the diff a [mark this revision as patrolled] button would be visible. When patrolled, the red exclamation mark would disappear. Rollback also patrols automatically the reverted edits. Recent changes can be filtered by unpatrolled edits, so with this, we could very easily see which edits have been dealt with, and which still need checking. We could have a list of ignored tags (for example visual editor, HHVM, etc), which don't need to be shown as unpatrolled. It can be implemented without much difficulty, so is this something that we want ? Cenarium (talk) 12:45, 16 February 2015 (UTC)

As a follow up to this prior discussion on showing pages expanded from redirects at Special:NewPages. As pointed out there it would be difficult to do so, but if those are tagged by a bot, then they will be able to show up unpatrolled at Special:RecentChanges, and they can be patrolled there this way. Cenarium (talk) 18:58, 16 February 2015 (UTC)

Should Wikipedia use HTTPS by default for all readers?

Should Wikipedia redirect all readers (logged in or not) to the secure version of the site by default to help protect readers' privacy? Wikipedia currently supports it, but by default visitors are directed to the HTTP version of the site. Making HTTPS the default setting would prevent governments, internet service providers, and hackers from snooping on visitors' traffic and seeing what a reader is reading. Many major websites, including Google, have already implemented this a long time ago. This would have little effect on the viewing/editting experience, and according to Jimbo, it wouldn't be a difficult change to implement. Tony Tan⁹⁸ · talk 20:33, 16 February 2015 (UTC)

References

No. Privacy is very important for me, but money (paying 20€ for 5GB bandwidth monthly) beats it. Besides all those wannabe-secure protocols turned out to be insecure snake oil in hindsight. Users should be free to skip this overhead if they don't want it, same idea as "web fonts" and other cruft best handled by Noscript, Adblockers, or /etc/hosts. –Be..anyone (talk) 02:39, 17 February 2015 (UTC)

Not if it can be avoided. An encrypted page is more difficult to cache, so ISP's can't just serve up a local copy and must go back to the WP servers each time. K7L (talk) 02:49, 17 February 2015 (UTC)

It's so necessary that I use the browser extension HTTPS Everywhere from the EFF which forces an encrypted end-to-end connection if the servers have the capability, which Wikipedia has. Every connection I make here is encrypted and I had forgotten that the default is plain HTTP. - Becksguy (talk) 05:55, 17 February 2015 (UTC)

If this is simple to implement, as apparently Jimbo said, then I strongly support this, for the reasons given by the OP. In response to Be..anyone, people would have a way to turn it off (create account, set prefs to HTTP) but I believe this change would bring more benefit to privacy-concerned readers who don't know how to or can't install add-ons to enforce HTTPS, than disadvantage to ones who don't want HTTPS for some reason. BethNaught (talk) 08:12, 17 February 2015 (UTC)

I left a note on Jimmy Wales' talk page about this, since we're quoting his ideas in the first place. BethNaught (talk) 08:19, 17 February 2015 (UTC)

If I recall correctly, there were issues where some censor organisations block the wikimedia sites over https, but not over http. What's the status on that? Martijn Hoekstra (talk) 11:38, 17 February 2015 (UTC)

@Martijn Hoekstra:Yes, China used to block HTTPS connections to WP, but it doesn't do that any more. See here. Tony Tan⁹⁸ · talk 13:45, 17 February 2015 (UTC)

Well, that's something. How about the others, i.e. Iran, Burma, Emirates, others? Martijn Hoekstra (talk) 13:53, 17 February 2015 (UTC)

I was thinking about that too. There isn't a lot of information. Censorship of Wikipedia mentions HTTPS only when discussing China, and a Google search for "wikipedia https censor" doesn't return much. If anything, defaulting to HTTPS should only discourage censors. Tony Tan⁹⁸ · talk 14:27, 17 February 2015 (UTC)

Keep both available. Defer to WMF on default. I think it's clear that we should preserve the ability of users to access pages in either HTTP or HTTPS according to personal preference, for a number of reasons above. As for which page is the default, this is one of those rare cases where I'd actually prefer to kick this up to the experts rather than attempting a community decision. There are so many quantitative decisions - how much bandwidth, how much potential censorship, how much surveillance, how likely it is that Heartbleed was replaced long before it was made public, how much load on the servers... we need someone who genuinely knows what he or she is doing to make that sort of judgment call. Wnt (talk) 16:45, 17 February 2015 (UTC)

I have a very strong preference for HTTPS as the default worldwide. But I also agree with Wnt that there are many many complex variables and careful study is needed.--Jimbo Wales (talk) 17:30, 17 February 2015 (UTC)

Question: How would this even work? If I put en.wikipedia.org/wiki/Metasyntactic_variable in the location bar, most browsers will assume HTTP. If we wanted to change the "default" to HTTPS, we'd need to redirect. But if we redirected, HTTP would no longer be available, which according to Wnt and Jimbo is a Bad Thing. Can someone clarify the technical implementation for me? --NYKevin 00:00, 18 February 2015 (UTC)

For readers, there are any number of options. For example, one might make http://en.wikipedia.org/ redirect to https, but not change other entry points. Or one might redirect to https whenever someone first enters Wikipedia with an outsider referer specified (e.g. all links from Google trigger https). Or when someone enters the http site, we might provide them with a dismissable popup box asking if they want to move to https and then remember that choice with a cookie. Lots of things are possible, some more reasonable than others. I agree with the above users that a decision like this is really more of an issue for the WMF to try and judge whether https is an appropriate option for most readers, and how to implement that if so. Dragons flight (talk) 00:30, 18 February 2015 (UTC)

I don't think that Jimbo said it would be a bad thing if HTTP was no longer available, but I agree that we should allow choice. I also agree that the WMF should be making the final decision, but do you (the community) agree that the WMF should consider a change from the current (HTTP-default) mode? Tony Tan⁹⁸ · talk 02:07, 18 February 2015 (UTC)

Request for Comment

There is a request for comment at Wikipedia_talk:Autopatrolled#Request_for_Comment:_Including_AFC_acceptance, asking for opinions and comments on whether the bar should be shifted for granting the autopatrolled user right. Please make all comments, questions or ideas there.- McMatter ^(talk)/_(contrib) 20:41, 16 February 2015 (UTC)

Suggested improvement for accessibility by editors

I am a relatively new editor and have found the WP 'back of house' to be particularly non-user friendly. I know that I have jumped in at the deep-end, taking on a rather daunting task rather than easing in more progressively and that this has accentuated some of the difficulties I have experienced. I think; however, that my experiences serve to highlight some problematic areas.

I had thought to raise this in a project area but these appear to be inactive so, here goes. I think there are three things that could be done relatively simply that would make all of the 'back of house' content much more accessible for all editors, but particularly new editors.

1. Create a servants entrance. By this, I mean, a 'back of house' home page accessible from every page, possibly just for logged in users but that is a policy decision. It could either be across the top, where the log in/log out and associated options are or it could be with the options on the left of screen under the Wiki globe. These are just suggestions.
2. A back of house search box. This would be similar to the MOS specific search box but would cover all of the 'back of house'. This could be located on the log in/log out line at the top of page and be active/visible when logged in. A back of house search box could be confusing if generally seen.
3. Create a more intuitive way to identify and access material from the 'back of house'. In practice, this is likely to be incorporated into the 'servant's entrance'. Books have (at least) two main ways available for tabulating the information within: a table of contents and an index. The former would be like an hierarchical guide - basically lists of policies, guidelines, essay, templates etc in alphabetical order. The latter would provide functional or conceptual groupings such as all articles about referencing, arranged around key words or concepts and sub-groupings. Furthermore, it may/should be possible to annotate entries to provide context and improve accessibility even more.

My ideas are not contingent on restricting access to only logged in users. I have very little idea about how to approach the actual nuts-and-bolts of such a 'project' but I perceive that a lot of the functionality is readily adaptable from what exists. Cinderella157 (talk) 10:13, 17 February 2015 (UTC)

@Redrose64, to clarify my restaurant metaphor of 'back of house', I mean all of the documents and pages that aren't in what others have called, the main space, article space or the encyclopedic area. I would include in the back of house things like: policy, guidelines, essays, template user guides, tutorials etc. Cinderella157 (talk) 23:34, 17 February 2015 (UTC)

Well, the first thing I'm seeing investigating this post is that our project space has no contents page. WP:HOME leads to an inactive Wikiproject, WP:Portal is about portals, WP:Main is about the main page and WP:Content redirects to a portal. Even if we did agree to add the link Cinderella suggests, we have no page to link to. I think the best place to link to for such an idea is Wikipedia:Five pillars, which has a lot of links to our key policy and guideline pages. Oiyarbepsy (talk) 21:20, 17 February 2015 (UTC)

My proposal is in 3 parts with the suggestion that servants'entrance or user home be a portal from which users can more easily navigate around WPs back of house. It can also have otherthings too but I would see this as its primary function. Cinderella157 (talk) 23:34, 17 February 2015 (UTC)

Are you aware of the Category:Wikipedia directories and its contents, like Wikipedia:List of policies and Wikipedia:Glossary? Similarly, Special:SpecialPages shows many special pages and Special:AllMessages shows all of the Wikipedia interface messages. – Philosopher ^{Let us reason together.} 21:46, 17 February 2015 (UTC)

Thanks, I was aware of one of these pages. My proposal is about how one becomes aware of these pages. Furthermore, my proposal is about being more inclusive (all of the back of house) than what any of these individual pages are. Cinderella157 (talk) 00:23, 18 February 2015 (UTC)

• I could see creating a portal to do this, and i think if anyone wanted to they could just create it. Beeblebrox (talk) 23:30, 17 February 2015 (UTC)

Not certain if you mean by that , that no special permission is needed or if you mean that anybody has the capacity to undertake the task? Part of the reason for addressing this here is the limitation of my own capacity to perform the task (the know-how). Also, for it to be effective, the door would need to be somewhere visible (as I have discussed/suggested). I perceived that placing the door would probably require some sort of permission or special access. Cinderella157 (talk) 00:41, 18 February 2015 (UTC)

I think what Cinderella157 is saying is that we should have an (optional) secondary Main Page for editors where the most commonly used special pages are organized into categories. It should have links to the Village Pump, the Policies, the Noticeboards, and Project Pages, so that all are within easy reach of a new editor. The reason Cinderella is asking for someone with permissions is that such a page should be created by an experienced user, and once created, it should be easily accessible to all logged-in users, such as through a link on top next to the "log out" link. Tony Tan⁹⁸ · talk 02:18, 18 February 2015 (UTC)

This is pretty close - especially the second bit: "The reason I am asking ...". Yes, "an (optional) secondary Main Page". It is designed for all editors but would be particularly helpful for new editors. I am thinking of some 'quick links' but I am also thinking of something encompassing all of the wiki pages (not in the article space). I am visualising both a table of contents, based on a hierarchy of page types, and an index, which is conceptual and may include pages (as links) appearing multiple times because they relate to multiple 'concepts'. The indexing would use multiple levels to hone in on specific concepts within broader concepts. I would envisage this possibly working off info boxes that can be expanded. This would then make it possible to see the 'full' range of available information (pages) without actually leaving the page. I would describe this a being more 'visual'. Links have their uses and their limitations. You need take a guess on which is is the best and then you might follow multiple links (crumbs) before you realise it it is a dead-end trail and you have to backtrack. By seeing a fuller range of options, you increase the likelihood of finding the correct path more quickly or even getting to the correct page more directly because of the multi-level index structure. Cinderella157 (talk) 03:58, 18 February 2015 (UTC)

For everyone saying we need a 'Portal'... We already have one, it's even linked from the sidebar. We could probably take better care of it though :) —TheDJ (talk • contribs) 10:16, 18 February 2015 (UTC)

OK, so we have the portal and it does do some of those things. You had to drill down one level before you started getting 'how to' info and flit off the page. There is something like an index but not a table of contents that I could see. There is also the search feature I raised. Cinderella157 (talk) 21:58, 18 February 2015 (UTC)

Transclusion of to-do lists on WikiProject tags

There is a proposal at Wikipedia talk:WikiProject Council#Proposal: Disallow transcluded to-do lists. Please comment there. PrimeHunter (talk) 23:51, 18 February 2015 (UTC)

Last chance for a while

From what I've seen in past years, right now is probably the last chance for a while that we might be able to pass some proposal that will lead to some eventual reduction of the growing admin-work backlogs. We've had three or four recent votes that people probably won't be willing to repeat anytime soon (see here and following, here, here, and maybe here). I'd like to hear evidence either way about what admin-related work is or isn't getting done these days, particularly the work that concerns bad actors (spammers, vandals, socks, etc.), and any proposals anyone wants to make on how to tackle the problem. I'll consider adding any promising proposals to WP:CENT but not to the RfC list, for now, because I don't think it would be smart to string this out 30 days. For recent discussion on the backlogs, see here (particularly Risker's comment), and search for "backlog" in most of the recent WP:AN archives, for instance here, here, here and here. For an explanation of why it's happening, this chart from the discussion in November (one of the links above) may be helpful:

	2008	2009	2010	2011	2012	2013	2014 (projected)
Active admins	943	870	766	744	674	633	570
Admin promotions	201	121	78	52	28	34	21
Admin attrition (actual, not net)	263	194	182	74	98	75	85

- Dank (push to talk) 23:59, 18 February 2015 (UTC)

P.S. The first line of the chart measures the number of admins remaining who had made something like 30 edits or more over the previous two months. The second line is the total gained that year, and the third line is the total lost that year. 2014 figures were estimates. - Dank (push to talk) 01:52, 19 February 2015 (UTC)

Somaly Mam, character assasination of an anti-sex slavery advocate

Somaly Mam is a former child prostitute from Cambodia. Until 2013 she was heralded internationally as a heroine and advocate, saving thousands of children. Then there was a Newsweek article The Holy Saint (and Sinner) of Sex Trafficking claiming to find holes in her original story [4]. For a normal politician such articles are part of the cut and thrust, but Somaly Mam quietly resigned from all her positions, she said to protect the organisation she founded from ongoing attention. Marie Claire magazine published a piece Somaly Mam's Story: "I didn't lie" , strongly challenging the evidence provided by Newsweek. [5]. The US State Department reports, sex trafficking and underage prostitution is rife across Cambodia. Believe what you like about the details, it is highly unlikely that Somaly Mam's original story is a total and/or proven fabrication.

Nevertheless, the wikipedia article on Somaly Mam is strongly biased against Somaly Mam. It's conclusions are far more definitive and condemning than Newsweek, saying "sex trafficking and abuse claims were disproved" and "she pretended to be a nurse". It provides details of a internal report which sofar has not been publicly disclosed. Her success in advocacy is underplayed. Each section of this article is entirely biased against Somaly Mam. Marie Claire is mentioned, but not the independent investigation that alleged Newsweek undertook poor journalistic practices and false claims.

Although it is possible that editors are following Newsweek's lead, is there is a chance that sex tourists who visit Cambodia go on to edit this page? Yes, we deal with biases and lobbying everyday, but pedophilia is not just an opinion. It's not about one person's reputation. Pedophilia networks use the internet to lure children and hide their tracks. Wikipedia cannot be used as part of this. Not only should the article be cleaned up, we should follow the edits of those who put the page in this state. There may be other damage being done. How can we afford to not check this out? 104.237.54.139 (talk) 08:12, 19 February 2015 (UTC)