Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check for existing global lock requests at SRG #36

Open
GeneralNotability opened this issue Apr 25, 2021 · 1 comment
Open

Check for existing global lock requests at SRG #36

GeneralNotability opened this issue Apr 25, 2021 · 1 comment

Comments

@GeneralNotability
Copy link
Owner

Per https://en.wikipedia.org/w/index.php?title=User_talk:GeneralNotability&diff=1019806653&oldid=1019576071&diffmode=source.

@Dreamy-Jazz
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants