Wikipedia

Wikipedia:Village pump (proposals)/Archive 120

< Wikipedia:Village pump (proposals)
Latest comment: 9 years ago by SD0001 in topic Proposal for new redirect tagging template {{R with history}}
Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 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, 215

Proposed user right: Vandal fighter

Latest comment: 9 years ago299 comments130 people in discussion

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.

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.[1] Sometimes, the vandals are only blocked hours later, when they are no longer active.[2] 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 Tan98 · talk 01:25, 1 February 2015 (UTC)

References

  1. ^ Example: Winedmoves (contribs | filter log), 174 vandalism edits to egg, active for half an hour after the AIV report
  2. ^ Examples : 82.215.225.196 (contribs | filter log), Lokolkok (contribs | filter log), 201.242.44.46 (contribs | filter log), 190.207.207.70 (contribs | filter log), Azbycx100 (contribs | filter log)
Discussion and comments from the talk page for this proposal:

I'll leave a few notes here at roughly one-week intervals; my tendency to speak up as a closer hasn't bothered people in the previous user-rights RfCs I've closed, and my feeling is that the spirit of NPOV almost requires it, for a discussion that's really never stopped over the last 12 years. (I'm supposed to be reflecting the community's POV, as expressed in this and past discussions, and I don't want to just spring that POV on you at the end.) But there's a problem that overhangs all these discussions, and I haven't even seen anyone try to argue otherwise. We have enough admins and people assisting admins to get the most critical work done now (just barely), but when the current admin corps moves on, the 22 new admins per year that RfA is producing aren't going to be sufficient. This problem has solutions, but the best solutions require helping the new guys along ... and I'm not saying no one is doing this, but we're not doing enough of encouraging and training and vetting tomorrow's admin corps.

The current RfC tries to tackle the problem by letting non-admins get some experience pushing admin buttons, which might also prepare them to move on to bigger things, but this RfC isn't close to a consensus yet for any one position. And I take the bar to be higher than "consensus" in this case, based on past discussions. Most of the admins and people doing similar work who we really rely on, the ones who can grind through heavy workloads while feeling relaxed and focused, are not looking to have a daily fight with the community over the legitimacy and value of what they're doing ... they need broad support, or else their enthusiasm declines rapidly for this kind of self-sacrificing work. If a solid 25% of Wikipedians are pushing back against what you're trying to do every day, you're not going to be effective doing it.

So, for the moment, the big problem remains. Unless the admin fairies start dropping admins out of the blue sky, we're going to have to find something that works better than what we're doing now, or risk the future of the English Wikipedia. Actually, what the supporters and opposers are saying gives me more hope than usual here; many arguments on both sides are sound, and I think we're close to eliminating from consideration all the things that won't work ... which in theory, gets us closer to finding what will work. I can imagine projects that would give non-admins the chance to cover significant bite-sized chunks of the admin workload that aren't currently covered by non-admins. (The reason it hasn't happened yet is simply that it can't be done "on the cheap"; people will need to invest time and commit to making it work.) But that's up to you guys; I'm just a closer. - Dank (push to talk) 23:48, 28 January 2015 (UTC)

Thanks, very thoughtful comments. Do you intend this as a discussion area (which would seem to duplicate the discussion part of the RfC) or more of a "blog" about your involvement in the RfC? ―Mandruss ☎ 00:36, 29 January 2015 (UTC)
Thanks. Say anything you like, and if this starts overlapping the main discussion, we'll move it there. - Dank (push to talk) 01:02, 29 January 2015 (UTC)
Ok, I will. The chances of my ever wishing to take on adminship would be greater in multiple small steps than in one giant leap for Mandrusskind. That's pretty much it in a nutshell. ―Mandruss ☎ 01:29, 29 January 2015 (UTC)
The problem, as I see it, seems to be that the community currently insists that admins be generalists. While some administrative tasks, like closing contentious AfD discussions, may meaningfully require experience with making articles, others, like blocking spammers and blatant vandals, do not. Currently, the community insists that candidates at RfA do more or less everything well, and that severely limits our pool of candidates. I think that we will ultimately need a broader acceptance of specialist admins and various forms of "junior admin" status may be helpful for getting more good candidates into that pipeline, although I do not have any concrete proposals right now. Pathore (talk) 01:54, 29 January 2015 (UTC)
  • The community would never go for it, and I accept this, but Pathore is correct here. The admin bit needs to be split into two or three specialized set of tasks for content admins (moderators), user admins (SPI AIV UAA etc), and technical admins (sysops). Maybe if we can get some of these lesser bits created they can be developed over time to fill these three rolls, and that is the best I can hope for here. — {{U|Technical 13}} (e • t • c) 02:05, 29 January 2015 (UTC)
    I never said "split" because that isn't feasible. In practice, there is considerable overlap between the needed rights for content and user admins, for example, both of them would need block buttons. Having an "admin" class with all of the tools remains appropriate. I only argue that we need to be more accepting of candidates that would not use all of the tools, at least not immediately. Various "training mops" may be also be useful in that direction, and I could support requiring admin candidates to have held and performed well in a "junior admin" role prior to an RfA for full adminship. Pathore (talk) 21:13, 29 January 2015 (UTC)

Meta discussion: RfC process

It has already been proposed that it should be possible to expunge a bad block. That makes perfect sense to me, and it kills the ruined-for-life argument, but it hasn't been added to the RfC. It seems that the RfC can't be modified without consensus on each modification, and there is no mechanism for reaching such consensuses. I don't get it; if there was no consensus required for the original proposal, why would we need consensus to modify it in response to opposers' objections? Sure, people would have to re-evaluate their !votes based on the changes. So what? How is that a big problem compared to the virtually inevitable stalemate that will result without it? It's called iterative negotiation, a part of collaboration and teamwork. ―Mandruss ☎ 10:43, 29 January 2015 (UTC)

I can't help by highlighting any one voter comment above the others, but if there's demand for it, I could prepare a survey to present to the voters so that people can indicate which of the main "talking points" they agree with so far. Would that help? - Dank (push to talk) 19:50, 29 January 2015 (UTC)
A summary of the major issues raised could be helpful. I would consider adding a revised proposal if the summary were clear enough and it looks like I could address the objections. Would a revised proposal belong in its own section on the page or in a subsection of the existing proposal? Pathore (talk) 21:52, 29 January 2015 (UTC)
Given how much discussion we've had already, I would suggest that iterative improvement should take the form of a new RfC after this one is complete. Changing a proposal after discussion has started opens a can of worms, because the discussion that led to the changes might not make sense afterwards. This is probably why there are "perennial proposals"--no one has worded them well enough for the community to accept on a first try, and the needed iterative improvement has not been done. (On the other hand, some of them may simply be bad ideas. I don't really know.) Pathore (talk) 21:46, 29 January 2015 (UTC)
I'm not sure what the status of this idea (suppressing bad block log entries) is. However, from looking at phab:9871, I think that User:Aaron Schulz might be the right person to ask. WhatamIdoing (talk) 17:09, 31 January 2015 (UTC)
I have a comment on that, but I'll refrain since it would be out of place and therefore confusing. This subsection is a meta discussion about RfC process. Bad block removal was only an example to start the discussion. ―Mandruss ☎ 19:51, 31 January 2015 (UTC)

Current votes: (49/61).-Yoshi24517Chat Online 16:04, 9 March 2015 (UTC)

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)
  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. LorTalk 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)
    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)Striking support upon further consideration. I'm still not going to oppose though. --L235 (t / c / ping in reply) 22:53, 14 March 2015 (UTC)
  23. 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)
  24. 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)
  25. 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)
  26. 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)
  27. Support badly needed, since there are only ~575 active admins, and fewer still in the vandal business, with 1000s of vandals a day. KonveyorBelt
  28. 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)
  29. 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 Tan98 · talk 05:23, 28 January 2015 (UTC)
  30. Support - Sounds great! George Edward C – Talk – Contributions 20:30, 28 January 2015 (UTC)
  31. 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)
  32. 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! BenLinus1214talk 03:35, 29 January 2015 (UTC)
  33. Support per Chris troutman YatharthROCK (talk) 02:46, 31 January 2015 (UTC)
  34. Support Although it should be hard to acquire, possibly like a (very) mini RFA process? RetΔrtist (разговор) 01:07, 1 February 2015 (UTC)
  35. 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)
  36. 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)
  37. 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)
  38. 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)
  39. 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)
  40. 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)
  41. 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 Concertotalk 00:39, 9 February 2015 (UTC)
  42. 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)
  43. 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)
  44. 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)
  45. Conditional support This is a really conditional support. This is establishing yet another level of hierarchy, below the admins. Till now, it's mostly based on page protect and approving permission requests, but now, it's even more complicated. As someone working with CSD, I feel that there should be a delete usergroup too. But there isn't, well, not on enwiki, atleast. I feel this unbundling is good but it could also be for the worse. I think the nays will have it. But, although the reasons are swaying, I see no harm. --QEDK ♠ T ♥ C 18:20, 19 February 2015 (UTC)
  46. Support I don't like the name though. We should have a less descriptive name like Manager (short for vandalsim manager). Vandal fighters could be inducted through a type of mini-RfA process with questions to test their response to various situations. This could be done at "WP:Requests for permissions/Vandal fighter/USERNAME" Comments from administrators and bureaucrats may be given slightly greater weight. SD0001 (talk) 08:42, 28 February 2015 (UTC)
  47. Strong Support I have always thought this is a great idea with one amendment that the RfP must run for a week. I can't tell you how many times I have been stuck uselessly reverting someones edits while waiting half an hour for someone to check and respond to AIV. Basic admins rights groups need to be formed so admins can spend time reducing other backlogs and to allow a introduction into admin-ing to get some experience before getting the mop. I also think maybe a Delete usergroup for experienced AfD'ers and a Speedy Delete group for experienced taggers. EoRdE6(Come Talk to Me!) 16:00, 5 March 2015 (UTC)
  48. Support This idea seems to be beneficial to Wikipedia. Eric - Contact me please. I prefer conversations started on my talk page if the subject is changed 21:34, 5 March 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)
      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 Tan98 · 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 Tan98 · 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)
  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. EthicallyYours! 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. –Davey2010Talk 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, LindsayHello 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. Mkdwtalk 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. --RacerX11 Talk to meStalk 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)
  55. Oppose Unpacking the admin tools is a WP:PEREN that the community repeatedly opposes. What we need is more candidates for admin, not admin-lite. Anyone with some experience who wants to run for admin, drop me a line and I'll try to help you through the process. But not this way. --Dweller (talk) 10:58, 19 February 2015 (UTC)
  56. God forbid no! Just another attempt by people who haven't a hope in hell of passing RFA to get some special tools and status to lord it over lesser users. Wikipedia should not be a MMPORG and any attempts to make that worse should be burned with fire.... Spartaz Humbug! 14:38, 19 February 2015 (UTC)
  57. Oppose, users wishing to obtain these rights should go through the regular RFA process. Nakon 21:03, 19 February 2015 (UTC)
  58. Oppose, I must admit, I laugh a bit... I've been fighting Vandalism and Spam on more than 500 Wikis globally as Global sysops, out of thousand and thousand of reverts and hundreds of deletion afaik I only block 2-8 users. Seems useless when you can report them to Stewards (global case) or local admin(local case), and English Wikipedia admin are always here to help (we have too many Admin IMO) just found out out of 1300+ admins only 500+ are active, just report them to Administrator and it will be solved accordingly. PS : If this proposal uses User:Esquivalience Idea of criteria, I might think about supporting this.--AldNonUcallin?☎ 05:09, 22 February 2015 (UTC)
  59. Oppose as per Esquivalience. smileguy91Need to talk? 18:01, 28 February 2015 (UTC)
  60. Oppose. I understand that one would need to fight vandals, but these rights are administrator rights that only a few very trusted users would be able to use, and would require nominations and !voting similar to an RfA or to License reviewer on Commons. If there are only a few "vandal fighters", there is no need to go through all this effort. Admins' noticeboards, AIV, RPP, etc. would notify admins of vandalism just finely for non-admin users. Epic Genius (talk) 16:15, 4 March 2015 (UTC)
  61. Oppose as per User:Esquivalience. Green547 (talk) 14:48, 7 March 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)
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)

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)

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)

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)
  • 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. Mkdwtalk 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)
I would support Cluebot getting a blocking ability that could only be used if a user has three, .9 or higher scoring edits within an hour that Cluebot has reverted. But looking above I am alone in this opinion. EoRdE6(Come Talk to Me!) 12:53, 11 March 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 Tan98 · 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 Tan98 · 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)
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.
Latest comment: 9 years ago6 comments4 people in discussion

My fellow editors, I have looked in the Perennial Proposals section and it seems to be historic now so I hope you will forgive me for raising it again. Also I have a variation in mind and a two part proposal. 1. I believe that there should be new category of Wikipedia editor, somewhere between a regular editor and an administrator, a Trusted Editor, and that these editors should receive some kind of meaningful financial recompense for their work, if they apply for it. As should Administrators. Some editors are financially comfortable and some are not. I am long-term unemployed, have mental health issues and will probably never have a regular job again. If I could make some money out my work here it would make a big difference to my life. I think I can fairly claim to have made a contribution to this shared project of ours as my user-page shows. Surely I cannot be the only poor Wiki editor and this would help others like me. Poverty kills thought, as has been pointed out. I don't think I am being unreasonable. There should be some kind of probationary period for this Trusted Editor status and it could be revoked if the Editor does wrong. 2. Linked to the above I believe that we should charge Facebook for using our content. Not much and I don't have a specific figure in mind but just a tiny amount for each time one of our articles is 'liked' on Facebook would generate a lot of revenue. I know that Wiki is 'not for profit' and I respect that, but Facebook has a revenue of $12billion while here on Wikipedia there are perpetual requests for donations. Surely that can't be right? That's not natural justice. If the funds generated by such a charge are redistributed to poor editors here that would not hurt our 'not for profit' status, would it? Jimmy Wales is worth $1million so life can't be so hard for him. I have had to go to a food-bank once in the past and may have to again. So what do other editors think? SmokeyTheCat 10:15, 11 March 2015 (UTC)

As to the second, all content on Wikipedia is released under a license which allows reuse by absolutely anyone, under specific conditions that don't include payment, so it would be illegal. As to the first, Wikipedia has enough trouble getting enough money as is, so I doubt that it would be doable. עוד מישהו Od Mishehu 09:15, 11 March 2015 (UTC)
So why can't we change that license? Do you not share my sense of injustice that Facebook, which so vastly wealthy, uses our content for free, while we rely on donations? SmokeyTheCat 10:08, 11 March 2015 (UTC)
We are not here to earn money, for that editors can go to Britannica or the like. We are here to make information available and freely accessible for everyone. Second the license can't be revoked, something that has been released under the current license stays under that. So we shouldn't and can't change the license. For the first idea, what yardstick should editors' contributions be compared with? Some create content; GAs, FA's, DYKs, FPs, etc. Others work behind the scenes and maintain SPIs, enforce arb sanctions, etc. Others do simple copy editing. Others like me patrol new pages and tag some for deletion. Secondly, there would be a mad rush for this "trusted" usergroup. So definitely no. --Fauzan✆ talk✉ mail 10:43, 11 March 2015 (UTC)
Oh well, I guess it's back to the Food Bank I go ... :-( SmokeyTheCat 16:47, 13 March 2015 (UTC)
Od Mishehu got it slightly wrong, it's not violating any license to charge for WP content. However, the license effectively lets them get it for free, so it's not likely Facebook would bother paying for it. Gigs (talk) 20:07, 20 March 2015 (UTC)

Proposed permissions change: Edit Notices

Latest comment: 9 years ago29 comments17 people in discussion

Currently we restrict the ability to create or edit notices project-wide (except User/User_talk: space) via the MediaWiki:Titleblacklist to administrators and template editors. I propose loosening or removing this restriction. A technical discussion (Wikipedia:Village_pump_(technical)/Archive_135#Editnotice_permissions_by_namespace) reveals this can be accomplished without software changes.

A range of options is available including:

a) Removing the restriction entirely
b) Allowing edits but not creations
c) Removing the restriction by namespace (e.g. allowing for all namespaces except Article)

In all situations, standard protection could be deployed to protect any specific edit notice.

Proposed: — xaosflux Talk 21:53, 7 March 2015 (UTC)

Discussion (Edit notices)

Prior to any sort of !voting, would like to have an open discussion period, please contribute below. Thank you, — xaosflux Talk 21:53, 7 March 2015 (UTC)

I think the current situation is (b) that people can edit it once created. They do create another opportunity for vandals to be disruptive. Also they are not that useful, so I think the current situation is OK. Graeme Bartlett (talk) 22:01, 7 March 2015 (UTC)
  • Remove the restriction – No reason to place a restriction on edit notices. If a restriction isn't absolutely needed, it should not remain. In events where disruption occurs, protection can be applied, as with all other Wikipedia pages. RGloucester — ☎ 22:04, 7 March 2015 (UTC)
  • Keep current system Our purpose is to build the encyclopedia, not exercise free speech through creative use of edit notices. What problem is this proposal addressing? Is there an example of a problem to the encyclopedia from an inability to tweak edit notices except by discussion followed by an edit request? Johnuniq (talk) 01:22, 8 March 2015 (UTC)
What should be in question shouldn't be what is gained from removing protection but what is gained in invoking it. Ours is a free encyclopedia and our default state is "yes", not no, so please justify your !vote in those terms. ResMar 01:53, 8 March 2015 (UTC)

I would suggest that the right is reduced to auto-confirmed on request, one page at a time rather than in mass. If there is a very highly-visible page, it should remain template-protected, but most should eventually be opened up to auto-confirmed editors. However, no rush. Oiyarbepsy (talk) 03:32, 8 March 2015 (UTC)

  • I would generally be OK with loosening the restrictions to autoconfirmed and higher. Any kind of vandalism on these notices would not affect our readers, just the editors. Edit notices don't seem to be a highly-visible _target and we can always protect edit notices of high traffic pages or policy pages if needed. What's the volume of edit requests to these notices that would be reduced if the restrictions were lessened? Nakon 03:58, 8 March 2015 (UTC)
  • We should treat edit notices the same way we treat talk page notices or article notices (both of which are way more visible): editing should be allowed by all users by default. If there's a specific reason to restrict editing of a particular page, that can be handled via the normal means (page protection, user blocks, AbuseFilter, etc.). --MZMcBride (talk) 05:25, 8 March 2015 (UTC)
  • This would probably result in the unnecessary creation of too many unnecessary editnotices. But allowing autoconfirmed users would not be a bad idea, considering that my edit request for the editnotice of this page is still pending! SD0001 (talk) 07:18, 9 March 2015 (UTC)
    • It wasn't pending because there was no-one to look at it or carry it out, it was pending because it is an incomplete request. Was there a discussion and consensus? It seems like it is questionable to add the requested text, and there will need to be. — {{U|Technical 13}} (e • t • c) 13:19, 9 March 2015 (UTC)
      • This delves in to the realm of "Should we require discussion and consensus before ANY edit notice is created/edited" - in which case admins and template editors shouldn't be editing them either without the same process. — xaosflux Talk 14:27, 9 March 2015 (UTC)
        • I'm not sure ANY is the word I would use, I see no reason that user editnotices should require a discussion and consensus for example (not that they are protected or require it now, although I would like to see them protected in a similar way that user .css/.js is only it should be TE/full or the user's own (I think user .css/.jss should be TE/full as well, but that is a different discussion)). I think obvious and clear changes for typos or whatnot are also fine "please replace accept with except in the sentence 'Do not add new items to the list accept for cases where there is a clear consensus'". Requests like "Please keep the discussion constructive. Off-topic comments should generally be avoided. If it is really necessary to add off-topic comments, please use collapsible boxes." are all generic things that apply to all pages (except for the collapse sentence that would require consensus since it might cause an accessibility consern). This specific request was also for WP:Village pump (proposals), which is a high traffic page and any change should be discussed before being implemented. — {{U|Technical 13}} (e • t • c) 15:33, 9 March 2015 (UTC)
        • @Xaosflux : It should be, and in practice is, like usual mediawiki messages. Noncontroversial is good to go (otherwise nothing would get done), if unsure ask on talk page to see if there's any objection, and if likely controversial then seek consensus.  Cenarium (talk) 21:31, 9 March 2015 (UTC)
  • If everybody and her dog including me can edit this spam we'll get more spam. Doesn't sound like a good idea for me, why do you think it's fine? –Be..anyone (talk) 10:00, 9 March 2015 (UTC)
    • Be..anyone: I don't understand your comment here. Can you please elaborate? How does what you're saying here not apply to the rest of Wikimedia? Any page is a potential (a)venue for spam. Nearly anyone can add a visible notice to a talk page or to an article. The edit screen is comparatively less visible, so I don't see why we would erect extra restrictions for it. --MZMcBride (talk) 20:23, 9 March 2015 (UTC)
      Most edit notices I saw were distractions, added by the owners of a page as some kind of private policy not related to real policies. E.g. edit notices on commons telling me that all system messages are documented on mediawikiwiki, which turned out to be untrue when I read it for a local system message. E.g. edit notices telling me to use some TemplateBox on commons instead of the template data manager, because that was in fact state of the art some months ago. So far tspan style="color:#00FF00;">Talkhe feature never failed to be a nuisance for me, limiting the write access to Brion might be a better plan. –Be..anyone (talk) 20:46, 9 March 2015 (UTC)
  • Six years ago, I invented the use of the Mediawiki:Titleblacklist for protecting edit notices. At the time, I was in favor of semiprotecting them rather than applying full protection, basically in the spirit of allowing more editor freedom. However, most of the other people that participated back then believed that edit notices were too much a part of the interface to allow generic editors to touch them, so we ended up with full protection. Personally, I'm still in favor of relaxing restrictions on per-page edit notices. For those, at most only one page at a time could be vandalized, so it doesn't seem like a big deal to me. Dragons flight (talk) 19:07, 9 March 2015 (UTC)
  • I would oppose any relaxation of restrictions in mainspace, since as I mentioned at VPT, some editnotices can be incredibly biting to newcomers and a major dissuasion to editing, totally uncalled for or violate assume good faith. This is by far the biggest danger, not vandalism. Vandals are spotted quickly, but this can go unnoticed since editnotices aren't as visible as page content, and cause much more harm in the long term. For this reason, I consider these editnotices high risk templates. As such, only users trusted to edit such templates, i.e. template editors and admins, should be able to edit these. As for editnotices in other namespaces, the same holds for many pages, probably dozens in Wikipedia namespace, those aimed for new editors mostly. I wouldn't object to a decrease in restriction to autoconfirmed for editing but only if these pages are identified and their editnotices placed on template protection. I would still oppose creation since we can't know in advance which page is going to be sensitive and template-protect their editnotices. However it should be noted that this may be a hassle to implement.  Cenarium (talk) 21:31, 9 March 2015 (UTC)
  • Keep current system - effectively, edit notices are a part of the interface. While we did decide to relax it for the userspace (giving users the right to decide what their own edit notices look like), I see no advantage to relaxing it elsewhere - there are OWN issues (completely irrelevant for a user in his/her own space), issuess of potential for vandalism in these sensitive locations, etc. עוד מישהו Od Mishehu 10:20, 10 March 2015 (UTC)
  • Allowing a large group of people to change the edit notices, even for some articles, would create a lot of problems with vandalism and edit warring. Experienced users are much better at deciding where edit notices should be and what they should say. PhantomTech (talk) 05:44, 11 March 2015 (UTC)
  • I would prefer keeping the current system, though I do have a proposal to create (yet) another user group that has the technical ability to override the title blacklist for the purposes of creating and maintaining editnotices on my list of things eventually to do. --L235 (t / c / ping in reply) 19:50, 11 March 2015 (UTC)
I'd just allow it as a legitimate reason for getting TE status, bar security risk. There is such a thing as too much un-bundling and the cases where this would be necessary are even narrower. ResMar 04:50, 13 March 2015 (UTC)
@Resident Mario: I'd personally argue that the level of trust for template editors is (far) higher than the level of trust for simply creating and editing editnotices, because template-protected pages are usually quite high-risk with much disruption possible from a rouge template editor, so under the principle of least privilege people that just need to edit editnotices should not have the (unrelated) ability to edit highly technical templates. And this is coming from a template editor who was granted the right just for creating Arbitration-related editnotices- see my user rights log. Then again, maybe it's just me. I'll get around to proposing it at WP:VPR... eventually. --L235 (t / c / ping in reply) 22:38, 14 March 2015 (UTC)
  Lixxx235: I was the editor in question who inspired this particular proposal, hehe, because I needed to be able to create and maintain editnotices in the Signpost domain. The reason I say that it'd be too much is that there would be too few cases where it'd be necessary to justify the additional paperwork, IMO. We only have 99 template editors and it's been two years; we'd have maybe 6 editnotice editors. It's just not practical. ResMar 22:41, 14 March 2015 (UTC)
@Resident Mario: Ah right, my bad. :P Ignore my last comment then :) --L235 (t / c / ping in reply) 22:44, 14 March 2015 (UTC)
  • I would support a proposal to remove the restriction all together. Page protection can be used as needed, and good faith editors would be freer to improve Wikipedia; subject to her consensus. I suspect angst will carry the day, however; as it too often does.--John Cline (talk) 11:27, 23 March 2015 (UTC)
  • Per my test on testwiki:MediaWiki:Titleblacklist, I support adding "autoconfirmed" to the TBL listing so that anyone who is autoconfirmed can edit these while protecting them still from anon/new account vandals. I can't see any reason someone who is a new account or an anon would ever have for changing these outside of what an occasional request for an edit on their behalf (just like any other semi-protected page) wouldn't be able to handle. — {{U|Technical 13}} (e • t • c) 12:11, 23 March 2015 (UTC)

Hybrid editor

Latest comment: 9 years ago8 comments8 people in discussion

The visual editor has received mixed reception, for familiarity and functionality reasons. However, I think many of the issues could be solved if you could run the visual editor side by side with the traditional source code editor. Adding a word in the source would show up immediately on visual editor, and changes with the visual editor would modify the source mid-edit. This has several benefits:

  • Helps explain the functions of the code visually for those who are unfamiliar with it.
  • Makes checking the "show preview" button unnecessary for everyone; the changes are apparent immediately.
  • Provides an easy learning curve for new editors: they can gradually do more work in the source code as they get more familiar with it.
  • Helps smooth out new feature adoption for experienced editors: putting visual editor in wider use makes it easier for veterans to see/learn new features.

This wouldn't require any totally new features. The aim would be to simply integrate the two editing modes that are already in place. As far as I know, this has not been proposed: "hybrid editor" brings up only one comment on bringing source editor features into visual, rather than running them in parallel. Forbes72 (talk) 04:15, 16 March 2015 (UTC)

I know that Wikia has an editor like this - as VE has been developed with them, maybe it is possible, I guess server load may be an issue. Even if just hosted on Toollabs, this would be good. I often use VE, and if I am doing anything major, I do switch to source code and check out what it's done. Mdann52 (talk) 12:18, 16 March 2015 (UTC)

Support I believe this is a great proposal, especially for new editors. They get to learn better in the hybrid editor, in my opinion. What would complement this is if the changes are highlighted, as in the differences shown when you cick on "diff" in the history section of each article. Sam.gov (talk) 12:57, 16 March 2015 (UTC)

Support An interesting idea. I like it. Do that. --Jayron32 13:01, 16 March 2015 (UTC)

Support as opt out gadget. Also, an integrated live diff engine would be good too. --Fauzan✆ talk✉ mail 12:40, 18 March 2015 (UTC)

Support I've never seen this done in a browser as opposed to a program so I'm not sure how it would deal with long pages, but something can be figured out I would be a great tool. If implemented, it shouldn't be the default editor for all users since, according to a discussion on forcing https, there are a lot of Wikipedia users who use older technology to browse and edit Wikipedia. If https will cause them problems then having to work with an editor constantly generating previews will be a nightmare, however everyone should have easy access to it by default so that new editors don't have problems finding it. PhantomTech (talk) 15:41, 18 March 2015 (UTC)

Support; this would allow us to get the best of both editors. Wikitext editor is currently best for most stuff, while VisualEditor is good for adding columns to tables (which is extremely tedious in wikitext). This would allow users to add columns with VisualEditor, while actually populating the cells with the wikitext editor, without having to make a bunch of edits. StringTheory11 (t • c) 21:50, 19 March 2015 (UTC)

 
VisualEditor in 2011
I can ask the product manager about this. However, as a point of fact, this was done in the original version, and it was basically declared to be a disaster. WhatamIdoing (talk) 19:39, 23 March 2015 (UTC)

Days of Year and individuals to list on the pages

Latest comment: 9 years ago5 comments3 people in discussion

the Wikipedia:Days of the year has been "cleaning up" the days of year articles removing individuals who are not "internationally recognized". The problem with that is they have no clear criteria for determining what that means. It's not listed on their project page at any rate. It's also not clear to them. Here is an example:

They clearly have no idea and are being capricious in he application of their supposed criteria, or worse-yet, making it up as they go along. I'm not saying the pages shouldn't be cleaned-up, but the criteria must be clear before starting, and the results of applying it should be similarly clear to any editor. WP:N is sufficiently clear for most other stand-alone lists, so I'm not sure why it would create recentism in this project. I'm also not sure how "three or five articles", a current proposal from project members, doesn't suffer from creating another problem. A category would be sufficient for most subjects (born on August 2 or died on August 2) or even allowing a bot to deal with the care and maintenance of such a list. I don't even mind their proposal to move all births and deaths from the date pages and onto stand-alone pages. However, their discussion as a project has been ongoing in their smaller circle, and I believe it has implications to many other projects and the English project as a whole, so I'm bringing it up here. Walter Görlitz (talk) 18:01, 13 March 2015 (UTC)

This does not seem to me to be an appropriate place for these comments. However, those who are interested can find the details of the actual discussion and constructive proposals for criteria here - Wikipedia_talk:Days_of_the_year#June_11_and_removal_of_entries_by_Deb.Deb (talk) 16:13, 15 March 2015 (UTC)
Of course. You're the one who has been opposing me at every turn. The actual discussion can take place here just fine. There have not been any constructive proposals there, only alternate ones. Walter Görlitz (talk) 04:07, 20 March 2015 (UTC)
Walter, I think you might want to look into Wikidata. Their entries should record the complete birth date for every person, and it is supposed to be fairly easy to search for "anyone born on August 2". Then you could put a link to that query in the August 2 article, and readers will have immediate, constantly updated access across all wikis, without needing to create enormous categories here. WhatamIdoing (talk) 19:36, 23 March 2015 (UTC)
How many readers of Wikipedia are going to go directly to Wikidata? Similarly, a category page would do the same. We're not discussing category pages but articles. Walter Görlitz (talk) 14:23, 24 March 2015 (UTC)

Proposal:Move protect ITN articles

Latest comment: 9 years ago9 comments7 people in discussion

Recently, the Villa Castelli helicopter crash article appeared on ITN. During its time there, it was moved twice. I have no issue with the moves, or the editors moving them, as both moves were made in good faith and were not problematic as such, although the did mean that the link from {{ITN}} was a redirect, not a direct link.

It is rare that an article will need to be moved with any great urgency whilst it appears on ITN. Therefore I propose that all main (i.e. bolded) articles listed on ITN be move-protected at Admin level for the duration that they appear on ITN. In practice, a one week protection should cover most appearances. If there is a pressing need to move an article, WP:RM will be available. This proposal could be extended to cover all articles linked from ITN, but I'm not sure that there is a real need, as most of the other links will be to relatively stable, established articles.

Discuss. Mjroots (talk) 20:49, 16 March 2015 (UTC)

What problem would this solve? ―Mandruss ☎ 21:00, 16 March 2015 (UTC)
@Mandruss: having a link to a redirect from the main page. Mjroots (talk) 21:13, 16 March 2015 (UTC)
Why is that a problem? Beeblebrox (talk) 23:22, 16 March 2015 (UTC)
AFAIK, it is an accepted convention that links to redirects are avoided from the MP. Mjroots (talk) 18:49, 17 March 2015 (UTC)
Is it? Can you point to where this convention is written down somewhere? TFAs are specifically move-protected, but that may be for different reasons. I was unaware that every link on the main page (especially those articles still being developed or in states of flux) were immune from being moved to a more proper name. Can you point me to where your read this? --Jayron32 05:23, 18 March 2015 (UTC)
No, you got it wrong. It is perfectly acceptable to link to redirects from articles. See WP:NOTBROKEN, as well as the various usages of {{This is a redirect}}. SD0001 (talk) 17:37, 25 March 2015 (UTC)
TFAs are already move-protected for the period from their selection through the date they appear on the Main Page as the TFA. I wouldn't see a problem with extending this convention elsewhere regarding Main Page content. Imzadi 1979 → 04:09, 18 March 2015 (UTC)
Oppose. Linking to a redirect is OK. A direct link looks slightly better and the main page is high profile so we generally make direct links when the content is written but if a page is moved later then it's no big deal to have a redirect until the link is updated. ITN items often don't have an established name yet, and new developments may necessitate a move. Let's not add bureaucracy to that. I'm not aware of a widespread problem with bad moves of ITN items. PrimeHunter (talk) 00:43, 19 March 2015 (UTC)

revision numbers

Latest comment: 9 years ago7 comments7 people in discussion

When someone uses the undo link, the automatic summary confusingly uses an unexplained, mysterious revision number instead of the time stamp of the reverted edit. This often makes it very hard or impossible to find the reverted edit in the history. I suggest the following changes:

  • the revision numbers should be displayed next to each edit
  • the automatic undo summaries should at least also display the time stamp or only that
  • the automatic summary should include a link showing the difference between the versions

--Espoo (talk) 08:35, 19 March 2015 (UTC)

I don't knoiw if this is possible - just FYI, we're talking about MediaWiki:Undo-summary, where $1 is the revision number and $2 is the name of the user. עוד מישהו Od Mishehu 14:06, 19 March 2015 (UTC)
A "difference between the versions" is just a diff of current vs previous-to-current, and that's already there. I don't support revealing the revision number in the normal history display (too technical and rarely useful). But it would be easy to write a gadget or bit of userland .js to do so, since it's just parsing/adjusting the display of data that is already present. DMacks (talk) 14:16, 19 March 2015 (UTC)
Espoo also posted to Help talk:Page history#missing info on revision numbers. I moved that discussion to MediaWiki talk:Undo-summary#Missing info on revision numbers before seeing it was also posted here. I suggested a link to the old diff in the automatic summary. Please only post the same in one place, or link other posts to a chosen page for the whole discussion. PrimeHunter (talk) 14:21, 19 March 2015 (UTC)
Perhaps we might change "$1" to "[[Special:Diff/$1|$1]]", and thereby include a link to the relevant version? It's a minimal difference, but it might be helpful… {{Nihiltres|talk|edits}} 16:56, 19 March 2015 (UTC)
I was about to propose exactly that change until I read your comment. If character count is a concern, could we make single-character redirects to the relevant pages? Or will that not work without software changes? If software changes are required, I propose making S:D and S:C aliases for Special:Diff and Special:Contributions, respectively. Pathore (talk) 20:20, 19 March 2015 (UTC)
If you're familiar with diff IDs, the revision number isn't mysterious at all, and it's quite useful because you can go directly to the revision by changing the URL or using Special:Diff. If we follow Nihiltres' suggestion and add a link to Special:Diff, confused people should be able to understand a lot better. Nyttend (talk) 18:10, 25 March 2015 (UTC)

Deceased Wikipedian

Latest comment: 9 years ago4 comments4 people in discussion

{{Deceased Wikipedian}}, by default, displays a generic chunk of text: "Their userpage...their memory". However, if you link the username, the template will detect the user's gender (if it's been specified) and reword accordingly; see it in use in a test on my userpage. Using "His" and "Her" seems to be a bit more respectful, and a bit more personal, than a generic message, if it's possible. What if we redid the template so that it automatically detected gender unless told otherwise? For example, if we did this and then placed {{deceased Wikipedian}} on my userpage, it would look just like what my userpage does now with {{deceased Wikipedian|Nyttend}}. By "told otherwise", I mean that we could set it so that it only does this when neither the |note nor the |message parameters are used, since obviously we wouldn't want to override a customised message. We could have it ignore the |page parameter, since that simply changes "user page" to something else.

I've made this proposal here, rather than at the template's talk page, because I expect to get broader input here than there. Note that I've advertised it at the talk page, however. Nyttend (talk) 18:18, 25 March 2015 (UTC)

A tool to import a category or list into another language

Latest comment: 9 years ago1 comment1 person in discussion

I think a tool to import a list or category into another language is needed just as much as a tool to sync lists & categories (see the upper section).

It could be used when creating a new category or list (e.g. in German) that already exists in another language (e.g. English) or for extending an existing one.

The tool would scan through the category/list equivalent of another language (eventually also multiple languages) and check if an article in the own language-space exists.

If so it wouldn't add those articles automatically but present the results to the user so one can decide which entries are actually appropriate.

--Fixuture (talk) 21:44, 26 March 2015 (UTC)

Latest comment: 9 years ago3 comments3 people in discussion

Anyone know a way to automate scanning for links to the journals listed at: http://scholarlyoa.com/publishers/

©Geni (talk) 01:04, 27 March 2015 (UTC)

-- Gadget850 talk 02:00, 27 March 2015 (UTC)
Note that the author of the list, Jeffrey Beall, goes by the username Denverjeffrey, although he's not been particularly active lately. Nyttend (talk) 12:20, 27 March 2015 (UTC)

Fix problem with references on talk pages

Latest comment: 9 years ago11 comments8 people in discussion
Tracked in Phabricator
Task T70324

I would like to propose that someone should fix the long-standing design flaw whereby references are automatically expanded at the bottom of talk pages. Initially these references would appear to an editor be correctly positioned, but as the talk page subsequently develops, they inevitably end up appearing to be attached to a totally unrelated later thread, far away from the place where they are relevant. References on talk pages should be expanded only as a result of a deliberate editor directive placed at the appropriate point on the page. In this way they will remain in the correct place. 31.51.134.71 (talk) 22:07, 17 March 2015 (UTC)

This template {{reflist-talk}} remedies that problem. When placed within the thread containing the references, the references are positioned only at the bottom of that particular thread rather than the bottom of the talk page.--JayJasper (talk) 22:57, 17 March 2015 (UTC)
T70324 --  Gadget850 talk 23:10, 17 March 2015 (UTC)
It doesn't remedy the problem. The references should be expanded ONLY if {{reflist-talk}} is present. Adding this should be the responsibility of editors who want the references to appear. The burden of discovering {{reflist-talk}} and inserting it in the appropriate place should not fall on uninvolved editors who later contribute to a talk page, only to find spurious references appearing next to their comments. 31.51.134.71; 00:47, 18 March 2015 (UTC)
I agree this is an annoying phenomenon. However, it wouldn't be if people would just use links on talk pages and not format them as refs. Why anyone adds the extra code to make something into a ref when they know they are on a talk page is something I will never understand. Beeblebrox (talk) 18:30, 18 March 2015 (UTC)
The devil's advocate in me says "why should someone have change formatting solely to make talkpage look nice for material copied from (or destined to be copied to) articles while discussing the article content, which is the only reason we have article talkpages at all?" DMacks (talk) 18:41, 18 March 2015 (UTC)
If the poster is presenting information that they would like somebody else to insert into a locked article, then including references is preferred behavior. If the reference is conveniently formatted in the correct manner, then that is even better. Hence, I don't think we should be deterring people from posting citations just because it is a talk page. Praemonitus (talk) 18:43, 18 March 2015 (UTC)
The goal of the interface feature is that refs should be findable, which is critical on article pages. But I agree confusing on talkpages if you're using the current last section on the page that gets refs from previous sections. But it *still* means those footnote marks (in the previous sections) work correctly, which is pretty important IMO. Maybe the interface should put the automatic reflist at the end of the major section (h2 level) rather than at the end of the page for talk namespaces. That also prevents possible archive-bot confusion that could result from a template being placed after the last actual item in a talkpage section (it would have no datestamp at the end). DMacks (talk) 18:51, 18 March 2015 (UTC)
Re:my earlier comment: I meant that the template {{reflist-talk}} "remedies" the problem from a technical standpoint, when it is utilized. I agree with the OP that adding it should be the responsibility of the editors who actually insert the references to begin with. I like DMacks' suggestion that the interface should place the automatic reflist at the end of the section, rather than the bottom of the talk page. If such a thing is doable, I would heartily support it.--JayJasper (talk) 22:02, 18 March 2015 (UTC)
From what I have seen, a lot of this occurs when an editor copies a chunk of text from the article onto the talk page for discussion and it includes refs. Before the introduction of the AGRL, we had namespace detection and did not show an error on talk pages. --  Gadget850 talk 22:27, 18 March 2015 (UTC)
What about having a bot that automatically added {{reflist-talk}} to the bottoms of any level-2 sections on talk pages that have ref tags? --Ahecht (TALK
PAGE) 18:21, 28 March 2015 (UTC)

FYI, Wikimedia is working on a potential replacement for our current talk page system, WP:FLOW. In Flow, references appear and the bottom of the particular post. Here is what it looks like. Oiyarbepsy (talk) 14:52, 25 March 2015 (UTC)

Bring back recognition to mobile WP version!

Latest comment: 9 years ago7 comments5 people in discussion

Before in the mobile edition of Wikipedia, it showed at the top the hours or days since last revision and the user name. Now the username is not there. Bring it back and even consider it for the full desktop version. That is how we encourage people to update this site and not think some editorial board does it. — Preceding unsigned comment added by Newbie 93 (talk • contribs) 02:15, 22 March 2015 (UTC)

must have been a glitch because it now is the way it used to be. — Preceding unsigned comment added by Newbie 93 (talk • contribs) 03:31, 22 March 2015 (UTC)
I still really dislike the inclusion of the last editor to revise the article. It doesn't in any way encourage people to edit the site -- in fact it looks more like the opposite, implying that a particular editor WP:OWNs the article. It may even encourage pointless editing just to get someone's name splashed across the top of an article (by the same sorts of people that clog up so many comments sections on other websites with "first post!" and the like). --Ahecht (TALK
PAGE) 14:09, 23 March 2015 (UTC)
I'm confused by your comment. You're saying that "it doesn't in any way encourage people to edit the site", but it may "encourage pointless editing". Which is it? Kaldari (talk) 20:50, 23 March 2015 (UTC)
It would be great to see any data about this, or at least some example edits. I haven't seen any edit (in dewiki), which was made just to push the name to the article, but maybe i just don't see them :) --Florianschmidtwelzow (talk) 19:15, 24 March 2015 (UTC)
@Florianschmidtwelzow: Sorry, I should've said "it doesn't in any way encourage people to constructively edit the site" --Ahecht (TALK
PAGE) 18:24, 28 March 2015 (UTC)
@Newbie 93: In beta and experimental mode of the website, this line is now undergoing a test in which it is placed at the bottom of the page instead of the top of the page. Perhaps that is why you think it is gone ? —TheDJ (talk • contribs) 19:17, 23 March 2015 (UTC)

A tool to synchronize lists & categories

Latest comment: 9 years ago3 comments3 people in discussion

I think a tool to synchronize lists & categories is badly needed if it doesn't yet exists.

For example I'd like to syn this category: Category:Science_fiction_horror_films with this list: List of science fiction horror films

(It should check all links on the list and compare it to all links on the category [and in this case its sublists])

--Fixuture (talk) 21:38, 26 March 2015 (UTC)

Support S a g a C i t y (talk) 08:10, 30 March 2015 (UTC)
Support Sounds like a good idea. Psychotic Spartan 123 02:11, 31 March 2015 (UTC)
Latest comment: 9 years ago1 comment1 person in discussion

Discussion moved to Wikipedia:External links/Noticeboard. SD0001 (talk) 17:04, 31 March 2015 (UTC)

Proposal for new redirect tagging template {{R with history}}

Latest comment: 9 years ago1 comment1 person in discussion

Please comment on Wikipedia:Requested_templates#.7B.7BR_with_history.7D.7D. Thanks, SD0001 (talk) 19:14, 31 March 2015 (UTC)

Should Wikipedia use HTTPS by default for all readers?

Latest comment: 9 years ago91 comments33 people in discussion
Many informative comments on both sides, without any real consensus. The most salient point is that this issue is highly technical and affects the performance and security of the site; therefore it is best left to the paid professionals of the WMF (see WP:CONEXCEPT). Therefore I close this discussion as "wrong forum". Interested parties may like to monitor the relevant workboard where active progress is being made. — Martin (MSGJ · talk) 12:08, 30 March 2015 (UTC)

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.

{{Request close}} 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.[1] Tony Tan98 · talk 20:33, 16 February 2015 (UTC)

References

  1. ^ http://arstechnica.com/tech-policy/2012/09/jimmy-wales-threatens-to-encrypt-wikipedia-if-uk-passes-snooping-bill/

Clarification: This proposal is not asking the community to make a "final decision" about the implementation of this change itself. Instead, it is asking whether the community thinks that the WMF should consider a change from the current HTTP-default mode. Tony Tan98 · talk 19:47, 21 February 2015 (UTC)

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)
That becomes impossible. If https is blocked (as is likely in some countries), there is no way to create an account and change it to http. They have to get to the site. While Western nations think of this as an increase in privacy, people in totalitarian nations will find it's a reduction of access. --DHeyward (talk) 02:44, 20 February 2015 (UTC)
I understand what you are saying, but I think it would be an increase of access. If a nation is totalitarian enough to block HTTPS, then it would be at least also filtering HTTP traffic by keywords. If the country is filtering instead of blocking the entire site, it means that while the nation does not want certain articles to be read, it doesn't want to block WP entirely because of the academic articles. By moving to HTTPS by default, it is actually more likely that the government would want to unblock HTTPS than to block off WP entirely because every country has researchers and students that need access to good information, which WP has. China currently has one of the most restrictive firewalls, (besides the countries that completely block off the internet), yet it allows https connections to Wikipedia. It is not just a privacy issue; HTTPS prevents selective filtering and tampering of the site. Tony Tan98 · talk 03:09, 20 February 2015 (UTC)
No, I don't think it does. If they control the DNS table, network routes, firewalls, etc, they can do MITM intercepts and https gives a false sense of security. Does wikipedia have enough 3rd party trust certification (and does China allow it?). Nokia did this with their browser and proxies and stored the HTTPS requests as clear text on their proxies and played MITM for requests because they could. Once you start to layer on the necessary privacy features, it will limit what works for individual users. http will always work if https is compromised or blocked and should be the default. https is fictional security without 3rd part, trusted certificates. --DHeyward (talk) 04:33, 20 February 2015 (UTC)
Yes, they control DNS, network routes, and firewalls, but not certificates. This means that any interception will trigger a browser warning. Even if they do control certificate authorities, they would not use it for the purpose of censorship as it would leave undeniable evidence and lead to the revocation of CAs (Certificate Authoritys) under their control. In the case of China, even though they own the CNNIC CA, which is trusted in most browsers, they don't use it because if they illegally issued a false certificate, they will leave evidence (in the form of a saved .crt file) and their CA will be revoked. Thus, in HTTPS they cannot selectively filter content on a website that they do not control because they will not be able to decrypt the traffic or manipulate it without triggering warnings in browsers.
About the "3rd party trust certification," HTTPS uses the public key infrastructure, which is based on certificates issued by trusted authorities. These authorities issue certificates for websites after they verify that the requester is the actual operator of the website. Because Wikipedia currently supports HTTPS, it already has a valid certificate issued by GlobalSign. These certificate authorities are currently used in China for online banking, so they are definitely allowed. By the way, you may find this informational video to be useful. Thanks, Tony Tan98 · talk 04:52, 20 February 2015 (UTC)
I don't consider censorship to be the main issue. It's snooping. Say a suspected dissident accesses Wikipedia through https; they think it's end to end encryption but with control of the network, firewall, DNS and CA - the dissident is really talking to a government computer that issues a certificate and that government computer (or more likely a hop or two away across a DMZ firewall) is establishing the TLS with WP. WP has no way to verify the request inside the firewall isn't valid (the same way they only see my ISP's IP address, not my local network IP). Dissidents computer has altered DNS table for wikipedia so it thinks it's actually talking to WP and gets a valid TLS certificate from China's CA - if NSA can do it without network control (which they do), China will have no problem. Now all his requests are visible to the government, yet he thinks it's secure. Which is the larger concern? I'd rather they think all requests are visible then a false sense of security that https is "secure". Censorship is not the problem, it's _targetting of individuals that they are suspicious of. Wholesale certificate spoofs won't happen but it will most definitely happen to high value _targets. --DHeyward (talk) 04:38, 21 February 2015 (UTC)
Where does China get a valid certificate for wikipedia.org from? CNNIC? When word of that gets out, all browsers will promptly restrict CNNIC certificates to .cn domains if they don't remove CNNIC entirely. This is an attack that only works until it is discovered, then CNNIC's credibility goes to nothing and they will lose the ability to ever do it again. Remember DigiNotar? That's what happens when CAs get caught issuing bogus certificates. Pathore (talk) 05:03, 21 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 Tan98 · 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 Tan98 · 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 Tan98 · talk 02:07, 18 February 2015 (UTC)

Oppose Initial access should be the widest and most available protocol. That's http. I'd rather have a user start with http and debug https rather than having trying to figure out why their http request failed during a redirect to https. We have no way of knowing what access is available from an ISP or a particular platform. If a government decided to shutdown https traffic to Wikipedia, I don't think it's WP's place to lock that country out or make them debug why it doesn't work. Keep it simple and http the default. --DHeyward (talk) 02:38, 20 February 2015 (UTC)

While that used to be the case in China, the situation has changed there. There is currently no evidence of any government in the world blocking HTTPS access to Wikipedia while allowing HTTP access, but there is evidence that some governments are filtering keywords in HTTP requests. Thanks, Tony Tan98 · talk 03:15, 20 February 2015 (UTC)
They don't have to if they control DNS, firewalls and certificates. https and http are the same in that case. --DHeyward (talk) 04:33, 20 February 2015 (UTC)
They are not the same. Please see my reply in our other conversation closer to the top in this section. Thanks. Tony Tan98 · talk 04:52, 20 February 2015 (UTC)

Oppose Misconfigured or old proxies tend to interfere with HTTP websocket traffic they don’t understand, but those same proxies will just forward on the encrypted HTTPS traffic. And, what about all the extra load on the servers? The CPU load has been known to increase when we switch to SSL and now only a few people use SSL, imagine if everyone was to use it all of a sudden. --QEDK ♠ T ♥ C 08:26, 20 February 2015 (UTC)

HTTPS used to cause a lot of extra load on the server many years ago, but now technology (both software and hardware) has improved and the difference is negligible. According to Adam Langley, a Google Security Engineer, "SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead" when Gmail switched to HTTPS default. This website offers more information about TLS performance. If properly implemented with SPDY and HTTP/2, it may even be faster than plain old HTTP. Moreover, the WMF would be the final judge on whether something can be implemented anyways, right? Tony Tan98 · talk 14:11, 20 February 2015 (UTC)
Yes, you're right, thanks for pointing it out. Most CPUs now can handle 1500 handshakes/second/core or more. But, then, as it happened with StackExchange sites, switching to active/active load balancers (costs money) because sometimes SSL fails to utilise multiple physical cores. Encryption makes caching an load balancing much harder. This might result in a huge performance penalty. But connection setup is really a show stopper for most applications. On low bandwidth, high packet loss, high latency connections (mobile device in the countryside) the additional round trips required by TLS might render something slow into something unusable. And, as recently, uncovered some computers could have been hijacked already, as the recent Superfish incident has shown. Just another generic man-in-the middle attack, where the self-signed certificate allows the software to decrypt secure requests. I'm not citing this as a reason for oppose, just noting something that happened. And also, if people want to enable https when available, they have the HTTPS Everywhere extension. But in the end, it's WMF's call. --QEDK ♠ T ♥ C 15:49, 20 February 2015 (UTC)
  • Oppose this has made access for me difficult in the past in some countries and if we want to expand our users this is probably not the way to do it. --Tom (LT) (talk) 00:18, 21 February 2015 (UTC)
  • Agree after HTTP/2 is implemented and proven stable on English Wikipedia server for users in USA. • Sbmeirow • Talk • 04:51, 21 February 2015 (UTC)
  • Strongly Support Let me list some reasons here:
    1. When security is concerned, allowing both HTTP and HTTPS is not ideal. Since we use HTTP by default for anonymous visitors, if you use Google to search something, you will find that all Wikipedia links are HTTP. The problem is that even if you are a registered user, when you click a Wikipedia link on Google, your browser sends its first request in clear text, so your ISP, government, and any man-in-the-middle still know which articles you have viewed. Even worse, an active man-in-the-middle can modify the server's response so that you never receive the 301 redirect to HTTPS, and most people don't realize the difference. This is especially true for mobile browsers, some of which omit the protocol and lack a lock icon. This is why redirecting HTTP to HTTPS is not so secure. By enabling HTTPS by default for everyone ensures that search engines index HTTPS links.
    2. What we also should do is to enable HTTP Strict Transport Security (HSTS). When browsers receive this header, all future requests to Wikipedia are automatically sent over HTTPS, and users cannot ignore certificate errors. Ideally, we should include Wikipedia in Chrome's HSTS preload list (which is also used by IE, Firefox, and Safari), so that the user's first time visit is secured. But note that whenever Wikipedia is preloaded on the HSTS list, there will be no options for anyone to disable HTTPS on Wikipedia.
    3. Google promotes HTTPS. Websites that use HTTPS get a higher ranking. (HTTPS as a ranking signal)
    4. After we adopt HTTP/2, using HTTPS will be faster than HTTP and this will be especially true for users with high latency. Please have a look at https://www.httpvshttps.com/. My test showed that "SPDY is 56% faster than HTTP". (HTTP/2 is based on SPDY.) Although HTTP/2 standard supports plaintext, at least Firefox will never support plaintext HTTP/2.
    5. China no longer blocks https://*.wikipedia.org, but does block https://*.m.wikipedia.org/ and http://zh.m.wikipedia.org/. I would really appreciate it if Wikimedia Foundation can change the DNS record of mobile-lb.eqiad.wikimedia.org to an IP address which is not blocked in China.
    6. Among Alexa Top 10, Google, Facebook, YouTube, Yahoo, and Twitter require HTTPS on their homepages. If they can require HTTPS, why couldn't we?
    7. W3C and Internet Architecture Board officially encourage websites to use HTTPS by default:

    The IAB urges protocol designers to design for confidential operation by default. We strongly encourage developers to include encryption in their implementations, and to make them encrypted by default. We similarly encourage network and service operators to deploy encryption where it is not yet deployed, and we urge firewall policy administrators to permit encrypted traffic. (IAB Statement on Internet Confidentiality)

    The Web platform should be designed to actively prefer secure communication — typically, by encouraging use of "https://" URLs instead of "http://" ones (although exceptions like "localhost" do exist). [emphasis in the original] (Securing the Web)

    Chmarkine (talk) 10:29, 21 February 2015 (UTC)
  • Oppose Make it opt-in instead, and redirect only when a cookie is found (set by clicking a banner promoting secure access). This is more conservative in my opinion. Zhaofeng Li [talk... contribs...] 11:13, 21 February 2015 (UTC)
    @Zhaofeng Li: But the problem is that MITM can remove the cookie if it is not secure. This does prevent passive MITM, but it doesn't work if an active MITM is present. Chmarkine (talk) 11:32, 21 February 2015 (UTC)
    If unfortunately the final consensus is to make HTTPS opt-in, I hope we implement it with HSTS (i.e. introducing Extension:HSTS, authored by User:Seb35). Chmarkine (talk) 11:42, 21 February 2015 (UTC)
    Browser usually provide some visual hints when the page is transmitted over a secure connection (a green padlock besides the address bar, for example), and users can easily notice if a crypto downgrade attack is being used against them. The HSTS idea looks good to me, but do note that users won't be able to turn it off easily in case they want the insecure version back. Zhaofeng Li [talk... contribs...] 11:52, 21 February 2015 (UTC)
    Yes. The indicator is actually obvious, but I worry many users just don't look at it. A research in 2006 concluded "participants who received no training in browser security features did not notice the extended validation indicator and did not outperform the control group." I hope users nowadays are more educated in web security, but I still believe websites should provide best security by default to most users. Chmarkine (talk) 12:11, 21 February 2015 (UTC)
  • Oppose Unfortunately, I'm not seeing how this proposal actually benefits Wikipedia's mission. Instead, the rational used to justify it is to get around ISPs'/countries' filters that block content they find objectionable. However, I don't believe that it is Wikipedia's place to find bypasses around these filters in the first place. —Farix (t | c) 15:12, 21 February 2015 (UTC)
That is not the only rationale of this proposal. Governments in most countries (including the USA) are now known to be monitoring internet traffic and putting them in large databases. This means that the articles that each reader reads are likely to be logged. Not only does HTTPS make large-scale snooping very difficult, it also prevents ISPs from monitoring what any given user has read or searched for on Wikipedia, protecting readers' privacy. This is one of the primary reasons that Google switched to HTTPS default for all searches. Tony Tan98 · talk 16:14, 21 February 2015 (UTC)
I don't believe switching to https will do anything to protect people from spying much less prevent them from being logged. Besides, this falls into the realm of WikiMedia Foundation's Privacy Policy and something that rest solely on the Foundation to decided. This is not something that should be up for discussion among Wikipedia editors. —Farix (t | c) 18:31, 21 February 2015 (UTC)
@TheFarix: As I stated above, the reasons for using HTTPS include: 1) preventing man-in-the-middle attacks, 2) improving performance (when HTTP/2 is used), 3) getting higher rankings on Google, 4) IAB and W3C encouraging using HTTPS. Using HTTPS on Wikipedia is just like using HTTPS on online banking websites, because "it has become apparent that nearly all activity on the Web can be considered sensitive, since it now plays such a central role in everyday life" (Securing the Web). Chmarkine (talk) 18:36, 21 February 2015 (UTC)
@TheFarix: It is a well established fact that HTTPS encryption protects people from spying and traffic logging. It is not a matter of opinion or belief. When a user visits a HTTPS secured website, the ISP can only see the domain name of the server, not the actual contents that the user is sending and receiving. In the case of Wikipedia, this means that the ISP will only know that the user is using Wikipedia, but it cannot tell what articles are being read and what terms are being searched for. The protection that HTTPS offers is described in detail in the articles HTTPS and Transport Layer Security, and elsewhere on the internet as well. I also recommend that you read the earlier questions, answers, and comments in this section about HTTPS.
I do agree that the WMF should make the final decision about whether to implement something like this. What this proposal is asking is whether the community thinks that the WMF should consider a change from the current HTTP-default mode. Thanks, Tony Tan98 · talk 19:34, 21 February 2015 (UTC)
Our purpose is to grant all of humanity access to the sum of human knowledge. If people are being prevented from viewing Wikipedia because of mass surveillance and censorship (regardless of source), then we have a problem that is interfering with our purpose. I honestly do not see the point of writing Wikipedia articles if the people who need the articles' information the most are being prevented from reading them, and feel that any proposal that gives more people access to Wikipedia's content is a good proposal. Spirit of Eagle (talk) 04:07, 25 February 2015 (UTC)
  • I've been supporting and advocating this move far a very long time now. There's no reason why internet traffic in general should not be encrypted (welcome to 2015, performance is not an issue anymore). And readers' privacy is only one part of the reason. The other is integrity of the data (website) delivered to the client (reader). Only an encrypted connection ensures that the data is not tampered with on it's way to the reader (as, for instance, here). --bender235 (talk) 21:59, 21 February 2015 (UTC)

Oppose, I'm sorry, I thought wikipedia was for the world and not just the first world countries? not everyone has fast internet speed, we may be in 2015 but internet wise, most countries are still in the 90's ..I ONLY edited on dial-up with my previous account (and not by choice) and because then Wikimedia didn't force people onto https, i was able to edit faster, https as mentioned above is pathetic in caching information, especially scripts which will make the wiki much slower for anyone with low internet speed, I'm on HSDPA and i can barely get a speed on 20kbps on the wiki. There is an OPTION to enable https on Preferences, I urge people who want "safety" to enable that and those that care for performance over security, like me would prefer to stay on, this is an ORGANIZATION, not some underground hacking/torrenting site that needs to be secured from the governments..This is WIKIPEDIA, not WIKILEAKS...All governments spy on people, that doesn't mean we live in fear all our lives..its not like we exchange private information or illegal stuff on Wikipedia that we need to "secure" ourselves from the government.......are we?--Stemoc 23:23, 21 February 2015 (UTC)

Browsers do cache content over HTTPS. The "2015" mention in bender235's comment was mostly referring to servers and their configurations, not the Internet connection. (You will see that if you click on his link.) Moreover, even though first-world governments are not as concerning, as you mentioned, Wikipedia is for the world, and there are governments in this world that restrict access to the web and filter content on Wikipedia. Not every government in the world is benevolent, and while it is not the primary objective, enabling HTTPS by default can certainly help protect readers and give them better access to information. Of course, like mentioned above, making it default does not mean there will be no way to opt-out. For your specific editing needs, you will still have the option of using HTTP by changing your account settings. Tony Tan98 · talk 00:05, 22 February 2015 (UTC)
@Stemoc: Totally understandable. But the good news is that only after a few months, you do not have to make the choice between security and performance. With HTTP/2 over TLS, you can enjoy both high speed and security. HTTP/2 over TLS is even faster than HTTP in most cases, in terms of load time and bandwidth. ([5][6] [7]) Since some browsers refuse to implement plaintext HTTP/2, we have to enable TLS in order to use HTTP/2. Chmarkine (talk) 01:54, 22 February 2015 (UTC)
High speed and security? I tried https a while back, net speed rarely went past 10kbps (thats as worse as dial-up) ..i don't care for security, our government does not care what people post on wikipedia and it definitely does not cache scripts well, reloading the same scripts over and over again everytime you try to make a simple edit or refresh the page is tiring, especially if they take a while to load...btw, anyone that wants to look up information on wikipedia even on countries where its restricted will always find a way to do so (proxies etc), we do not make it hard for everyone else because just a handful are missing out and as mentioned above, I prefer an opt-in option to an opt-out one..I'm just tired of WMF making stupid decision and then enforcing them and regarding the opt-out option, thats absurd Tony, HTTPS should be an OPT-IN option, not an OPT-OUT option and definitely NOT the ONLY OPTION.--Stemoc 02:27, 22 February 2015 (UTC)
Please check out this image, you can definitely forget the idea that everybody living in some kind of "first" world area can afford Internet connections that do not suck. Just in case adding an oppose, because I forgot that near the begin of this thread. € 0,02 by Be..anyone (talk) 02:38, 22 February 2015 (UTC)
@Stemoc: I never say https is fast today. I mean https will be faster than http after we adopt http/2, which will be available later this year. I know you don't care about security, but http/2 is faster than http. Why do you still hate it? Chmarkine (talk) 03:03, 22 February 2015 (UTC)
@Stemoc: Are you able to use Google search through your slow internet connection? Tony Tan98 · talk 03:14, 22 February 2015 (UTC)
Ofcourse i can use Google search, the shitty speed is only limited to wikimedia wikis which gets even worse on https, my net is slow but bearable but then i'm on Wikimedia more than I google so i do not see the reasoning (even then it takes forever to do google "image" search)..as per Be---anyone, it seems that slow connection is a problem in first world countries too so I really don't see a reason to "force" https on everyone..I think people who are supporting this idea are definitely NOT on slow connection or else they would understand how hard it is to browse, let alone edit wikipedia--Stemoc 04:40, 22 February 2015 (UTC)
Google uses HTTPS by default. You said that you are able to use Google search (over HTTPS) normally on your slow internet connection. Thus, HTTPS is not the issue that is slowing down your access to Wikipedia. Moreover, editors with accounts will have the option to disable HTTPS if they wish to do so. Also, I spend half of my time in China, and I know what it feels like to use a slow internet connection. Tony Tan98 · talk 05:06, 22 February 2015 (UTC)
when did i say it did?, I said it makes it worse as and also i generally use Google DNS so google will run faster either i like it or not and also there is a stupid bug on wikimedia created by csteipp which no one wants to fix which automatically FORCES users into https if they edit any page by mistake on https, the only way to get out of it is to clear all your cookies from *wikimedia/*wikibooks/*wiktionary and the 4 other domains and clear all centralauth cookies and log in and they go to all wikis and try logging in... I'm a file mover on commons which means if i fix a file name, my account automatically goes to all the wikis the image is on to replace the file but if i get logged out of a wiki because of this bug, it ignore that wiki which means the file remains unchanged..first they added the "forceHTTPS" cookie without asking for user opinions and now this....I'm part of the SWMT which means on some days i edit over 20 wikis and sometimes more, this flaw is not helping...https may be ok for those who edit only ONE wiki like most of those here, but its a PITA for users like me..you can't revert vandalism on a smaller wikis if you have to wait 30-45 seconds for all the effing scripts (js/css) to load...--Stemoc 06:58, 22 February 2015 (UTC)
  • Support - I totally agree. In the pre Snowden era, this probably would have been opposed as unnecessary and/or burdensome, although it's now absolutely necessary (per Google, Snowden, and many others) and it's barely burdensome, if at all. Yes there is censorship. But the chilling effect of surveillance has a negative impact on our mission. There are many places in the world in which asking questions about religion, sexuality, women’s rights, abuse, among others, or editing forbidden Wiki articles, can result in actions taken against them by their families, community, employers, or the state (judicial and extra-judicial). Wikipedia is an invaluable resource for information, but not for those that are afraid to access it because big brother or others are looking over their shoulder. - Becksguy (talk) 04:01, 22 February 2015 (UTC)
  • Oppose for viewing, Support for logging in and editing. Restricting HTTP access to Wikipedia's public content doesn't provide any real security gain, and it makes caching harder. It's also likely to break some older devices, such as the Kindle with free Wikipedia access. However, editing actions and logging in should be secured. John Nagle (talk) 07:55, 22 February 2015 (UTC)
  • Comment Shall we move the discussion to meta, since this is a Wikimedia-wide issue affecting all communities? Zhaofeng Li [talk... contribs...] 01:11, 24 February 2015 (UTC)
Doesn't really matter as one of the devs mentioned on IRC a few days ago that we will be moving to https (either we like it or not) ..--Stemoc 01:26, 24 February 2015 (UTC)
  • Support Everyone should be able to read Wikipedia articles without having to fear government surveillance or censorship. If people who need Wikipedia's information are prevented from getting it because of mass surveillance or censorship, then our purpose of granting people access to the sum of human knowledge is under attack and needs to be protected. Even if this RFC does not pass, I think that we should do a better job of informing readers about HTTPS, and make it easier to switch in. Spirit of Eagle (talk) 01:44, 24 February 2015 (UTC)
  • Strongly support per Becksguy, at all times. In addition, with attacks that rely on starting with an unencrypted channel, there's more and more reason to start off encrypted to begin with. I question concerns of users who are talking about bandwidth use, as well; I'd like to see some actual numbers showing TLS overhead versus average article sizes before I'd give those comments any credence. // coldacid (talk|contrib) 03:35, 25 February 2015 (UTC)
    Chmarkine explains it even better, above. Even HSTS can be defeated by a man in the middle if you start with unencrypted communication. Default to HTTPS, the sooner the better. // coldacid (talk|contrib) 03:39, 25 February 2015 (UTC)
  • Perspective Please don't pretend this is for site security. If we cared about site security, we'd have a password policy. I'm also kind of baffled by this hypothetical use case of someone who has to fear people eavesdropping their Wikipedia reading habits, but is ignorant of the use of HTTPS. Where does this end? Remove public editing histories? A one-way hash for editor names? The whole concept of a Wiki is open and public. Not secure and secret. Gigs (talk) 16:57, 25 February 2015 (UTC)
No straw men please - you know very well that those things aren't going to happen. For one thing it would violate the license terms, and editors can be pseudonymous anyway if they choose. You're right that this wiki is public, but that only covers overt participation, not reading, where people would have a legitimate expectation of privacy.
Also, I don't think (generally) people are saying this move is for site security, it's for the readers' security. BethNaught (talk) 17:07, 25 February 2015 (UTC)
Please actually read the above proposal, Gigs. It is (mainly) not intended for site security, but for the security & privacy of readers. No one is proposing to make this wiki secretive; it is and always will be open and public. I genuinely hope that you were actually confused and not trying to make a straw man argument. Tony Tan98 · talk 17:45, 25 February 2015 (UTC)
This is also another reason to either block editing via Tor or at least include a big "you are not as anonymous as you think" message on the edit pages served to Tor exits: an attacker able to observe your network traffic can trivially correlate bursts of activity with Wikipedia's public edit histories. Edits look different from reading: reading a page is a large response to a small request, while editing is a large response to a large request. If we really want to take the paranoid approach, we should modify the software to include random bits of other articles (as comments) in every page sent over HTTPS. Currently, an attacker might be able to guess what articles are being read by looking at the sizes of the responses from the servers. Pathore (talk) 22:45, 25 February 2015 (UTC)
@Pathore: While what you are saying (traffic analysis) is certainly theoretically possible, it is currently not an easy task for even a government to use for mass snooping. It is not "trivial." Moreover, Wikipedia does not allow edits from Tor unless the user logs in and has IP block exemption.
The main purpose of this proposal is to prevent mass snooping (and censorship) of readers by upgrading to the HTTPS protocol by default, which is what many other websites such as Google have started to do years ago. As a side benefit, HTTPS also ensures the integrity of data being transferred, so that a user can be certain that the page from Wikipedia has not been tampered with (censored or inserted with ads) while in transit.
We are not trying to take the "paranoid approach" and there is currently no need to "include random bits of other articles." Given the sheer number of articles we have and the current state of technology, it should be very difficult (currently) for someone to use traffic analysis to correlate encrypted traffic to specific articles that are being read. However, because it is trivially easy to sniff unencrypted traffic using tools such as Wireshark, I strong believe that we should enable HTTPS encryption by default for all readers. Since you have not yet stated it, may I ask for your opinion on this proposal? Tony Tan98 · talk 01:49, 26 February 2015 (UTC)
Correlating public edit histories to network activity is trivial, especially over a longer period of time, and identifies the network location behind an account, fingering an editor.
Identifying pages based on their size is neither trivial nor particularly accurate, but should be a concern if we are really worried about our readers' privacy, given the poor standards of "evidence" associated with mass snooping fishing expeditions. Exactly how accurate such an attack would be depends on the distribution of page sizes given links. (A snoop can guess that users tend to follow links from the page that they are reading; this means that if pages A and B are the same size, but A links to C and B links to D, which are different sizes, a snoop could guess that a user was more likely on A or B, based on a subsequent request that appears to be either C or D. This game of Guess Who? scales, although I don't know exactly how well.)
If I understand correctly, HTTP/2 allows the server to send the client extra resources that have not (yet) been requested. We could use this to return a number of random extra articles (that the client will cache) with each request, further enhancing reader privacy. Even looking at someone's cache wouldn't tell you what articles they were reading, since the server stuffed extras in there at every opportunity. Exactly how to choose those extra items is a good question.
I'm currently unsure of my position on this proposal. On one hand, Jimbo has promised to push Wikipedia towards HTTPS in response to privacy-violating politicians and I don't want to take whatever leverage Jimbo may have for human rights away by pushing that change regardless. On the other hand, the article you cite is from almost three years ago; perhaps the situation has changed and it is now necessary for the community to stand behind making good on its founder's promise. Has this come to pass? Do we need to stand behind Jimbo making good on his promise? Pathore (talk) 03:06, 26 February 2015 (UTC)
Opposed It'll break links and infrastructure. It breaks caching important for overseas users and increased latency (unless WMF's planning 20+ more data centers). And unless we're padding the payload its still vulnerable to the Google Suggest side channel attack. — Dispenser 18:03, 5 March 2015 (UTC)
1. I don't understand what you mean by breaking links and infrastructure. Could you please explain?
2. Browsers do cache content over HTTPS.
3. TLS isn't slow anymore. I spend half my time in China, the other half in the U.S., and I use HTTPS; I have not experienced any noticeable latency or slowness. Tony Tan98 · talk 08:20, 10 March 2015 (UTC)

Just a quick update on where we are with this. Consistent with Jimmy's comments here, we do believe encryption should ultimately be the default for all web traffic, on our sites and elsewhere. That said, we have significant work lined up on improving the performance of Wikimedia's HTTPS infrastructure (phab:T86666, phab:T35890) which we aim to complete in coming weeks. We're also collecting global performance metrics as we tune our setup. We need to fully understand performance impact and other potentially negative consequences before any switchover to HTTPS for all traffic (or a less dramatic solution, such as pointing search engines to the HTTPS version).--Erik Moeller (WMF) (talk) 06:08, 7 March 2015 (UTC)

The web is inexorably marching toward secure encrypted traffic. See today's NY Times op-ed piece Stop Spying on Wikipedia Users, written by Jimmy Whales and Lila Tretikov, in which they discuss a lawsuit against the NSA. I think that nails it for us here. Offering Transport Layer Security (or TLS/HTTPS) for Wikimedia projects with opt-out as the default is the only way to go. Otherwise, due to human nature, too many readers/editors will not opt-in which results in those using encryption as standing out, and therefore being _targeted for increased surveillance. Everyone needs to use encryption all the time and everywhere, such that it becomes the norm. - Becksguy (talk) 15:29, 10 March 2015 (UTC)

  • Support. Chmarkine's and bender235's rationales above convince me. Using https will make all Wikipedia pages secure, as opposed to fast and insecure; performance isn't really an issue at this point. More and more webpages on the internet are using https. However, https should be opt-in for unregistered users. Epic Genius (talk) 01:37, 17 March 2015 (UTC)
  • Oppose. Some internet browsers, particularly embedded browsers which receive few updates after their release, may have difficulties with this. I'm sorry, but I just don't see any importance in this. Exactly what on wikipedia needs to be secure? People are arguing for more privacy without considering whether there's anything worth securing. ― Padenton|✉   01:28, 26 March 2015 (UTC)
    Who the hell is browsing Wikipedia on a phone so old that its browser doesn't support HTTPS? I highly doubt that we'll have people trying to read the site on some circa 2000 feature phone. // coldacid (talk|contrib) 02:04, 26 March 2015 (UTC)
@Coldacid: A lot of phones don't, even more embedded browsers don't (such as those in TVs or game consoles) ― Padenton|✉   16:02, 29 March 2015 (UTC)
Could you give a specific example? Most phones today support HTTPS. Tony Tan98 · talk 18:12, 29 March 2015 (UTC)
Pretty sure every game console of this and the last generation support HTTPS as well. Without some naming and shaming of recent devices by Padenton, I find myself unable to believe their claim. I wouldn't mind if WMF would chip in with some user-agent stats for the past year as well, so we have an idea of how (in)frequently users without HTTPS support even come to Wikipedia. // coldacid (talk|contrib) 18:38, 29 March 2015 (UTC)
  • This is NOT about securing Wikipedia content (which remains open and available to anyone), rather its about protecting user's privacy in accessing WP, in much the same way a battered women is given anonymity to protect her from reprisals. Something quite different and in the opposite direction from securing WP. - Becksguy (talk) 08:48, 29 March 2015 (UTC)
@Becksguy: Sorry, I didn't mean to imply anything about applying protection to wikipedia articles. This has nothing to do with battered women. So you're talking about preventing people from knowing what pages a user views? Is there any significant user survey in addition to the arguments above that users want such things? Sadly, there is a systemic bias in any Wikipedia namespace discussion towards active editors. There is already a setting to enable secure connection, and I don't see why that is not enough. ― Padenton|✉   16:02, 29 March 2015 (UTC)
@Padenton: Internet traffic to Wikipedia has been specifically identified as one of the _targets for NSA mass surveillance, and HTTPS can make monitoring by governments, ISPs, or other parties as difficult as possible. HTTPS can also prevent Wikipedia content from being selectively censored or inserted with ads by ensuring the authenticity of delivered content. While there is currently an option for users to use HTTPS, the default is HTTP (plain text), and research has shown that as many as 95% of users don't bother to change the default settings simply because they are not aware. Google, along with many other companies/organizations, has already made HTTPS the default or even the only method of accessing its websites. By making HTTPS the default method for accessing Wikipedia, we can protect those users with almost no noticeable change in experience for them. Tony Tan98 · talk 18:12, 29 March 2015 (UTC)
@Tony Tan 98: I still don't see how anyone has reason to be afraid of what their wikipedia browsing history shows, what is it you think the government will find out? Google is not Wikipedia, people don't type the same things into Google that they do into Wikipedia. People don't type in "How do I make bomb" or "where can I find child porn" into Wikipedia's search bar. Ad insertion is exclusive to a few obscure ISPs, non-intrusive, and there's a setting to make https the default method for accessing wikipedia in preferences. The 3rd link is irrelevant. People can make their own choices about their own privacy. If you want to propose a banner at the top of the page letting people know about the setting, I wouldn't oppose that. ― Padenton|✉   18:37, 29 March 2015 (UTC)
If Wikipedia browsing history is useless, why is the NSA _targeting it? Such history shows what a user has been reading and what his/her interests are. Its sensitivity can be seen in the lawsuit that the WMF filed against the NSA.
What is the downside of using HTTPS? Usually things are disabled by default only when there are downsides; otherwise they are enabled by default. For example, why not remove airbags from cars and make it an option for people to install it themselves? Surely people should "make their own choices about their own" security? Because the benefits of having an airbag outweigh the virtually nonexistent downside.
This proposal does not prevent people from explicitly opting to not use HTTPS, but simply makes it the default should the user decide to go by the default. The benefits of using HTTPS (protection of privacy, prevention of selective censorship, assurance of authenticity, etc.) outweigh the possible downsides. Tony Tan98 · talk 20:11, 29 March 2015 (UTC)
  • Oppose If individuals are concerned about governments, internet service providers, and hackers from snooping on their traffic, they may elect to use https as I do. Forcing it on individuals is not appropriate. I would argue that also extends to editors changing links to other sites used as references to secure connections also. Walter Görlitz (talk) 04:10, 26 March 2015 (UTC)
  • This proposal does NOT force HTTPS on anyone; users are completely free to opt out at anytime. What it does change is the default to secure, rather than insecure. If someone doesn't like it, just opt-out. - Becksguy (talk) 09:00, 29 March 2015 (UTC)
  • Support – While some might argue that users can choose to opt in, we know that most people are unaware of the issues and will take no action even if they are told of them; defaults should be set in the general best interest for those that will leave it at the default. —Quondum 18:56, 29 March 2015 (UTC)
  • It appears that one of the reasons for opposing is "I have nothing to hide", so why encrypt. To which some might reply: (1) "I have nothing to hide... from those I trust." Does anyone that hasn't been living under a rock since the Snowden revelations, seriously think in their most optimistic pipe dreams that anyone that snoops on our communications has the slightest concern for our individual best interests or rights, or that those that commit surveillance on us are our friends? With global surveillance, there is so much data gathered about us, stuff that maybe doesn't seem important at the time, that can come back and bite us in the ass. Remember Big Brother. And today this is reality, not paranoia. (2) There are places in which people have very legitimate and real fears about surveillance. Places and communities where, for example, if someone is outed by viewing the kind of information that is taboo or contraband, they can suffer punishment, beatings, imprisonment, and execution, both judicial and extrajudicial. (3) When Windows XP was released in 2001, it had a form of firewall that was off, thus disabled by default (opt-in mode), and these machines were rapidly infected with various malware (viruses, worms, etc.) that also infected other vulnerable machines. Microsoft set the firewall default to enabled (opt-out) in SP2, realizing that users and the internet needed protection. No one manned the barricades when that default was changed. (3) Our mission is to realize "...a world in which every single person on the planet is given free access to the sum of all human knowledge." We will fail if there are those that are afraid or unable to access this knowledge due to surveillance or censorship and the very real and serious consequences thereof. - Becksguy (talk) 02:51, 30 March 2015 (UTC)
  • Oppose - I'm puzzled by this. If you're in the telephone directory, then apart from your number any Tom, Dick or Harry can see your home address. But if the NSA accesses your IP address, so what? There's no "IP directory" which links that to your name and address. 87.81.147.76 (talk) 10:38, 30 March 2015 (UTC)
They aren't just accessing your IP address, and HTTPS wouldn't prevent them from doing so. What it does is encrypt all data between you and the server, even what pages you are looking at. Using your example, this would be like the NSA not only being able to know your address and telephone number even if you have them unlisted, they can also read all your mail and hear all your telephone calls. And there is an IP directory, the one that your ISP keeps on you. They also know, and can possibly keep and therefore track, every connection you make through them. Without HTTPS your ISP can see that you visited this page, and all the text that is on it. Jerodlycett (talk) 10:52, 30 March 2015 (UTC)
There seems to be some synthesis going on here. If I type "google" into my browser and click on "Gmail" the url that comes up is https://www.gmail.com. So are you telling me that even with that "s" on the end the NSA can still read my email? 87.81.147.76 (talk) 11:18, 30 March 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.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_120&oldid=1138369464"
  NODES
Canvas 1
chat 2
Community 46
HOME 3
Idea 52
idea 52
Interesting 2
Intern 23
Javascript 1
languages 2
mac 7
musik 2
Note 20
OOP 11
os 567
server 14
swift 1
text 18
Training 4
twitter 1
Users 113
Verify 2
visual 11
web 27