• That final step doesnt look very fair, in fact it looks like its predetermined that despite any support for the checkuser they will lose their rights. By first holding the discussion open for more people to agree to remove the tools, and then if that doesnt work well lets vote and go by weight of numbers until we remove the tools. This policy smells much more like an internal self anointed power grab by ARBCOM. Gnangarra 10:30, 25 February 2016 (UTC)[reply]

@Gnangarra: As far as I am aware, the existing inactivity procedures and standards have been around since 2011. This is simply a codification of how ArbCom may choose to enforce that activity requirement. Kevin (aka L235 · t · c) 14:03, 25 February 2016 (UTC)[reply]

Yes and no, the "five actions in a quarter" was preexisting -- the whole automatic removal unless you can find three arbs to object is entirely new. The old procedure was largely the same, except it required an affirmative vote to remove the permissions (a majority of all active arbitrators explicitly voting to support removal). The new system doesn't require a vote unless three arbs explicitly object. This is now the only process arbcom has where the status quo can be changed by the inaction of a majority. There's a big difference between getting people to explicitly vote for removal versus a pocket veto of silence resulting in a removal. Courcelles (talk) 17:38, 25 February 2016 (UTC)[reply]

What is a "pocket veto of silence"? All the best: Rich Farmbrough, 00:10, 26 February 2016 (UTC).[reply]

Since a motion or proposal required an affirmative vote from a majority of arbs, arbs who oppose a proposal can -- for whatever reason -- can simply ignore the proposal and not vote on it. An arb listed as active who chooses not to vote on a proposal is effectively voting oppose. This turns it around on its head, a failure to vote is now a support. (Not sure how common pocket veto is as a term outside the US, sorry). Courcelles (talk) 00:32, 26 February 2016 (UTC)[reply]

Talk about a counter-intuitive solution to a non-problem. We are already suffering from attrition in the ranks of functionaries at all levels and we are now going to automatically strip users of permissions if life happens, preventing them from being on-project (or they simply are contributing in other ways), meaning that they no longer have tools when they are in a position to be of assistance? How is this beneficial to the project? What's the rationale? I'm sure there must be one, but I'm stretching my mind to imagine one which seems like it would be a net benefit to the project...Snow ^{let's rap} 03:44, 26 February 2016 (UTC)[reply]

In a 10-1 vote, I was the 1, so I have to agree with you. This was a bad motion, and the idea of "active as an editor/admin" absolutely should be considered. Courcelles (talk) 06:07, 26 February 2016 (UTC)[reply]

Having done one or two checkusers checks in my time, can I say with disappointment that there is a consideration that activity with the tool is the predeterminator for retention of access. We want CU checks run for reasons to maintain access to tools??? I would much prefer to see activity based around active communication, consultation, and managing the requisite queues, answering specific questions relating to CU and the undertaking of audit activity of existing logs. Naturally there is balance, and if someone is not using the tools for extended periods then they do not need access to the tools, it would seem to me that a mature approach is needed, rather than a simple measure of use of tool. :-/ I am a little disappointed that the ArbCom is not seeking community consensus on this matter, and is become an exclusive decision-making body, rather than a committee for arbitration. — billinghurst sDrewth 13:47, 26 February 2016 (UTC)[reply]

Agreed. This was a bad decision. Watch as functionaries start grasping at situations where they can use their tools. Or worse, checkusers doing baseless checks just to satisfy activity requirements. -- œ^™ 07:34, 28 February 2016 (UTC)[reply]

As above, the activity requirements didn't change with this motion, and have been the same since 2011. We are discussing updating them. (See also Callanecc and Kelapstick's posts here.) Opabinia regalis (talk) 08:47, 28 February 2016 (UTC)[reply]

Given that there's frequently a back log at SPI, greater checkuser activity would be a good thing. Nick-D (talk) 00:36, 5 March 2016 (UTC)[reply]