You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I could see this working by either having the code remove any account which is already listed for a lock, fail if there is a report which has all the accounts listed (which is what Global Twinkle does I think based on https://github.com/Xi-Plus/twinkle-global/blob/master/modules/twinklearv.js#L610), or only remove accounts which have been reported in a section for being a sockpuppet.
The last is the most difficult, but I think would be the best. Determining what makes a report a sockpuppet report would be a difficult to get right, but perhaps if the report contains keywords (such as sock, links to sockpuppet pages etc.) that may work. It would prevent issues where a global lock request which has been filed without evidence is rejected but the account should have been locked as a sock (and would have been if it was reported along with the others). Perhaps this is too much work to write and maintain.
The second, which is what Global Twinkle does may be best. This is because the preexisting Lock request, as mentioned in the example above, may be declined due to lack of evidence. This failing of any post to SRG should encourage the user of spihelper to go to SRG to check the report, and add the sockpuppetry in if it's not there. This may also be the fastest option of the three as the script can exclude when any account from the list to request a lock for isn't present in a preexisting report the script is checking.
The first means that in cases of a report which once a CU was run more accounts were found, the new report does not duplicate any account listed at SRG for a lock. However, in cases where the account was reported and then not locked, due to lack of evidence in the preexisting report or because it was for a invalid lock reason, the excluded account is then left without a lock without anyone from SPI or stewards at SRG being aware the account was missed (without further investigation). Usually accounts at SRG from enwiki SPI should be blocked at SPI, but with non-admin clerks being active they may skip the local block for a global lock to save time.
Per https://en.wikipedia.org/w/index.php?title=User_talk:GeneralNotability&diff=1019806653&oldid=1019576071&diffmode=source.
The text was updated successfully, but these errors were encountered: