I like this idea but would make one important change. I'd make it a rolling count so that signatures older than 2 or 3 weeks (or a month or whatever) would drop off. That would make sure the process was tracking admins for current or recent issues. Otherwise a signature that's a year old would count for as much as one that's a day old. The point is that we'd want to react to recent events and not just keep a list of everyone an admins been in conflict with in the indefinite past. With that change I think this makes the most sense out of all the recall proposals...it's light weight, it runs itself and has a clear path. RxS ( talk) 16:14, 25 October 2009 (UTC)
- Conceivable, of course, but then we'd need to lower the hundred users threshold, and have another parameter to calibrate... Sandstein 18:48, 25 October 2009 (UTC)
- It'd be a simple task for a bot to clear out entries past a certain age. The threshold might be better at 20 or something...but to have no expiration on signatures (even if a editor has left the project, banned, changed his mind but forgot they signed etc.) doesn't make tons of sense to me. RxS ( talk) 21:41, 25 October 2009 (UTC)
As currently written this proposal fails pretty much all my tests for a fair and workable system for desysopping.
- Scenario 1. in 2017 Arbcom close the case Gender of the White House cat, desysopping two admins for wheelwarring and three for canvassing. Several disappointed participants retire and as is now customary for unblocked users flouncing off the project, sign all one thousand reconfirmation requests before they leave. Amongst the admins tipped over the 100 bar are eleven admin bots, and dozens of admins who haven't edited since George W Bush was President.
- Scenario 2. A job interview in 2014. I see you are an admin on Wikipedia and I found this page where 62 users are calling for you to be sacked. Oh that's nothing, every admin has one of those pages and most have more signatures than that, yes it was stupid of me to edit Wikipedia in my own name.
- Scenario 3. In 2012 a sockpuppeteer confesses to having had scores of accounts in 2011 that each signed dozens of reconfirmation requests before they retired. A checkuser confirms that the retired accounts cannot be investigated as we don't store old IP information that far back, therefore we cannot confirm or refute the confession and don't know whether those !votes should be struck or remain valid.
I would be somewhat mollified if !votes expired if the !voter was blocked or had not edited for a month, and were struck if they did not give a reason why they supported the desysop. Or if a bot emailed signers each month in which another signature was added and gave them a link to click to confirm they still supported the measure. But overall this fails all my tests of a workable desysopping procedure, and in my view would be an unworkable drama generating trollfeeding exercise. Ϣere SpielChequers 12:29, 26 October 2009 (UTC)
I like this idea but would make one important change. I'd make it a rolling count so that signatures older than 2 or 3 weeks (or a month or whatever) would drop off. That would make sure the process was tracking admins for current or recent issues. Otherwise a signature that's a year old would count for as much as one that's a day old. The point is that we'd want to react to recent events and not just keep a list of everyone an admins been in conflict with in the indefinite past. With that change I think this makes the most sense out of all the recall proposals...it's light weight, it runs itself and has a clear path. RxS ( talk) 16:14, 25 October 2009 (UTC)
- Conceivable, of course, but then we'd need to lower the hundred users threshold, and have another parameter to calibrate... Sandstein 18:48, 25 October 2009 (UTC)
- It'd be a simple task for a bot to clear out entries past a certain age. The threshold might be better at 20 or something...but to have no expiration on signatures (even if a editor has left the project, banned, changed his mind but forgot they signed etc.) doesn't make tons of sense to me. RxS ( talk) 21:41, 25 October 2009 (UTC)
As currently written this proposal fails pretty much all my tests for a fair and workable system for desysopping.
- Scenario 1. in 2017 Arbcom close the case Gender of the White House cat, desysopping two admins for wheelwarring and three for canvassing. Several disappointed participants retire and as is now customary for unblocked users flouncing off the project, sign all one thousand reconfirmation requests before they leave. Amongst the admins tipped over the 100 bar are eleven admin bots, and dozens of admins who haven't edited since George W Bush was President.
- Scenario 2. A job interview in 2014. I see you are an admin on Wikipedia and I found this page where 62 users are calling for you to be sacked. Oh that's nothing, every admin has one of those pages and most have more signatures than that, yes it was stupid of me to edit Wikipedia in my own name.
- Scenario 3. In 2012 a sockpuppeteer confesses to having had scores of accounts in 2011 that each signed dozens of reconfirmation requests before they retired. A checkuser confirms that the retired accounts cannot be investigated as we don't store old IP information that far back, therefore we cannot confirm or refute the confession and don't know whether those !votes should be struck or remain valid.
I would be somewhat mollified if !votes expired if the !voter was blocked or had not edited for a month, and were struck if they did not give a reason why they supported the desysop. Or if a bot emailed signers each month in which another signature was added and gave them a link to click to confirm they still supported the measure. But overall this fails all my tests of a workable desysopping procedure, and in my view would be an unworkable drama generating trollfeeding exercise. Ϣere SpielChequers 12:29, 26 October 2009 (UTC)