Commons:Checkusers/Requests/Materialscientist

Support = 44; Oppose = 12; Neutral = 1 - 79% Result: Unsuccessful. --Krd 04:46, 12 September 2023 (UTC)[reply]

Materialscientist

Vote

Materialscientist (talk · contributions (views) · deleted user contributions · recent activity (talk · project · deletion requests) · logs · block log · global contribs · CentralAuth)

Scheduled to end: 00:00, 11 September 2023 (UTC)

Dear colleagues, I would like to help the project by performing checkuser duties. My motivation is cleanup. I do that daily as an admin on en.wiki and Commons and as a checkuser on en.wiki (since 2009, 2012 and 2013, respectively). Experience tells that having access to CU logs on two projects, especially en.wiki and Commons, greatly increases the chances of making a right assessment of a user.

Here are my en.wiki admin and CU statistics. None of my CU actions were found inappropriate. Materialscientist (talk) 05:54, 27 August 2023 (UTC)[reply]

Votes

Support - No issues, will hopefully clean up a growing socking problem on this wiki...--Ste moc 07:26, 27 August 2023 (UTC)[reply]
Support --Minorax^«¦talk¦» 07:50, 27 August 2023 (UTC)[reply]
Oppose per below. --Minorax^«¦talk¦» 09:45, 7 September 2023 (UTC)[reply]
Support Юрий Д.К 08:07, 27 August 2023 (UTC)[reply]
Support user has ~2 million edits globally 💀 ----modern_primat ඞඞඞ ^TALK 09:21, 27 August 2023 (UTC)[reply]

Neutral ----modern_primat ඞඞඞ ^TALK 15:34, 10 September 2023 (UTC)[reply]

Support as above. Yann (talk) 13:19, 27 August 2023 (UTC)[reply]
Support Glrx (talk) 13:33, 27 August 2023 (UTC)[reply]
Support unreservedly. I have had nothing but good experiences with their work.🇺🇦 Timtrent 🇺🇦 talk to me 🇺🇦 13:55, 27 August 2023 (UTC)[reply]
Support -- Abzeronow (talk) 15:26, 27 August 2023 (UTC)[reply]
~~Support~~ —‍Mdaniels5757 (talk • contribs) 15:36, 27 August 2023 (UTC)[reply]
Struck pending response below. —‍Mdaniels5757 (talk • contribs) 19:13, 4 September 2023 (UTC)[reply]
Unstruck. I'm reiterating my support, and would like to explain why the objections below don't hold water with me. First, the SPI (and ACC CU queue) backlog on enwiki is. to me, not relevant to whether Materialscientist would be helpful here. I think hardening the /32 IPv6 block appears to be an error in judgment, but given that they have made 6,510 CheckUser blocks ([1]), a small number of errors is inevitable, and, unless the errors are unusual or indicate recklessness in using the tools or blocking, not a factor for me. I am assured that the CU tool was in fact used before blocking that range, so JJMC's objection that it was not appears baseless (indeed, non-CUs don't have access to CU logs, so JJMC and I have no way of knowing that a range was checked before blocking other than the word of a CheckUser). Since this does not appear to be a pattern, and the other objections are not availing to me, I continue to support this nomination. —‍Mdaniels5757 (talk • contribs) 22:28, 4 September 2023 (UTC)[reply]
@Mdaniels5757: I think you've misunderstood. As a member of the Ombuds Commission, JJMC has global access to each wiki's checkuser log. AGK [•] 11:15, 5 September 2023 (UTC)[reply]
Ah. That makes me more concerned. However, I don't think that a CU block must be made immediately following a check (although that's presumably most common), but rather that it must be based on recent CU data (recent enough that any changes are unlikely). The statement that "I've checked that range 7 times" in the month prior to the block makes me feel believe that Materialscientist was not shooting from the hip. —‍Mdaniels5757 (talk • contribs) 16:57, 5 September 2023 (UTC)[reply]
Re-struck my support. I now Oppose per TonyBallioni below. —‍Mdaniels5757 (talk • contribs) 14:01, 6 September 2023 (UTC)[reply]
Support - Highly trusted user. — Diannaa 🍁 (talk) 15:50, 27 August 2023 (UTC)[reply]
Support Taivo (talk) 19:28, 27 August 2023 (UTC)[reply]
Support Mike Peel (talk) 19:31, 27 August 2023 (UTC)[reply]
Support —Yahya (talk • contribs.) 21:39, 27 August 2023 (UTC)[reply]
Support Highly trusted and experienced user of Wikipedia, I think he can provide benefit to Commons on this capacity. NikosLikomitros (talk) 01:49, 28 August 2023 (UTC)[reply]
Support Support. Highly capable and clearly knows what he is doing Robertsky (talk) 03:13, 28 August 2023 (UTC)[reply]
Support--UltimoGrimm (talk) 08:50, 28 August 2023 (UTC)[reply]
Support --Ameisenigel (talk) 10:50, 28 August 2023 (UTC)[reply]
Support—Teles «Talk to me ˱_{C L @ S}˲» 12:41, 28 August 2023 (UTC)[reply]
Support Riad Salih (talk) 13:06, 28 August 2023 (UTC)[reply]
Support. —Hasley 14:14, 28 August 2023 (UTC)[reply]
Support --MZaplotnik^(talk) 14:23, 28 August 2023 (UTC)[reply]
Support —MdsShakil (talk) 15:01, 28 August 2023 (UTC)[reply]
Support --Ferien (talk) 19:00, 28 August 2023 (UTC)[reply]
Support GMG ^talk 19:41, 28 August 2023 (UTC)[reply]
Support -- King of ♥ ♦ ♣ ♠ 22:45, 28 August 2023 (UTC)[reply]
Support --Hugo (talk) 02:57, 29 August 2023 (UTC)[reply]
Support Trusted and experienced. ─ The Aafī (^talk) 09:30, 29 August 2023 (UTC)[reply]
Support EN-Jungwon 10:24, 29 August 2023 (UTC)[reply]
Support Thank you for volunteering! --TenWhile6 (talk | SWMT) 14:05, 29 August 2023 (UTC)[reply]
Support Yep. The Herald (Benison) (talk) 18:41, 29 August 2023 (UTC)[reply]
Support Absolutely, yes. — Red-tailed hawk _(nest) 01:44, 30 August 2023 (UTC)[reply]
Support -- Ariadacapo (talk) 06:07, 30 August 2023 (UTC)[reply]
Support FitIndia ^Semi-retired 14:44, 30 August 2023 (UTC)[reply]
Support --Adamant1 (talk) 02:31, 31 August 2023 (UTC)[reply]
Support Andy Dingley (talk) 21:49, 31 August 2023 (UTC)[reply]
Support --Kritzolina (talk) 17:13, 1 September 2023 (UTC)[reply]
Support Jianhui67^T★C 18:14, 1 September 2023 (UTC)[reply]
Support. Aszx5000 (talk) 19:41, 1 September 2023 (UTC)[reply]
Support – Ammarpad (talk) 10:59, 2 September 2023 (UTC)[reply]
Oppose I am contesting your statement that "None of my CU actions were found inappropriate.". I find that en:Special:Redirect/logid/148499599 was an inappropriate CU action. You changed an IPv6 /32 anon. only block for a Jio range to a hard block, marking the new block as a CheckUser block. This caused a wave of appeals due to collateral. Since, per policy, I could not modify your CU block, I requested that another CU investigate the collateral and reduce the block. Another CU restored the block back to anon. only within hours of your modification, citing "significant collateral". Collateral aside, you marked the block as a CU block, but it was not backed by use of the CU tool. This unacceptably made the block unreviewable by non-CUs. If you cannot use the tool appropriately on a wiki where you already have it, you should get access to it on another wiki. — JJMC89 (T·C) 17:13, 3 September 2023 (UTC)[reply]
"I find that en:Special:Redirect/logid/148499599 was an inappropriate CU action." - indeed, that single action was found inappropriate by some users, and I still don't know who they were. There was no discussion that involved myself. Five long-term blocks were issued to that range before mine within 1.5 years. A public discussion was started a month after my block here. It didn't find the blocks inappropriate. All that said, I don't question the decision (of lifting my block or finding it excessive). Materialscientist (talk) 22:42, 3 September 2023 (UTC)[reply]

"it was not backed by use of the CU tool" - I have to disagree. We are talking about a busy ::/32 range. Getting its CU log is technically challenging even on a fast internet; hence we often scan parts of a range. According to Drmies that IP range has "1500 entries in the CU log since February 2021". Some partial results are kept on CU Wiki. That IP range has been CU-scanned ca. 100 times in the period 18 May 2023 to 30 August 2023 alone. I've checked that range 7 times from 20 May 2023 to 26 June 2023. My block was issued on 26 June 2023. Materialscientist (talk) 22:42, 3 September 2023 (UTC)[reply]
I'm personally not going to comment or vote because of (active or former) hats and this is not a community I regularly contribute, but I am concerned. I have had to repeatedly and excessively reduce rangeblocks at ACC because of how blatantly they ignore colleterial, and I did it for years. I know the CU training is lacking, but I also learned how to block just through CU expirience, or looking at how busy ranges are. It causes more work for others. I haven't been doing ACC as frequently recently, but the previous pattern was long and extensive. -- Amanda (she/her) 21:45, 3 September 2023 (UTC)[reply]
Amanda, for the record, I highly value your work and comments on CU mailing list. I wish you have talked to me personally so that I could learn from you. Materialscientist (talk) 22:42, 3 September 2023 (UTC)[reply]

During that May-June timeframe, your checks were of /64s, which doesn't come close to the amount of due diligence that you should have performed before hard blocking a /32. Had you performed appropriate checks or recognized the range/provider, you would have seen/known the amount of collateral and not hard blocked the /32. Justifying a hard block of this range would need some very serious abuse. For comparison, the abused T-Mobile IPv6 /32 with a more extensive block log isn't hard blocked. — JJMC89 (T·C) 23:14, 5 September 2023 (UTC)[reply]
The abuse was serious, but I admit my block was excessive. Frankly, I did mean to hardblock the range, to stop a certain maniac, but forgot to change the duration, and it was taken over from the previous block by Ad Orientem. Materialscientist (talk) 00:10, 6 September 2023 (UTC)[reply]

I have some feeling that Materialscientist in this application is confronted for the first time with the accusations, although the issue, not saying if it is or is not any, happened weeks ago. Am I right? --Krd 05:23, 6 September 2023 (UTC)[reply]
Krd, I made a formal complaint to the en.wiki ArbCom weeks ago about the one incident I am directly aware of, because like Amanda below, I think MS's blocks are excessive in general, but this crossed the line from excessive to abusive since he was preventing review by non-CUs when he had not checked a range he had marked as a CU block. From what I was told when I asked about what I could say in this RfCU, en.wiki ArbCom agreed that it was a problem and intended to send a reminder but because of an administrative oversight they forgot to send the reminder email to Materialscientist. For clarity: based on his responses here I no longer think it was abuse of status, because I don't think he saw it as making a block without performing a check, but that also raises other concerns as I mentioned below. TonyBallioni (talk) 12:56, 6 September 2023 (UTC)[reply]
Thank you for the feedback. I'm referring to the "I wish you have talked to me personally…" above. If there was never any personal conversation about the problem but the only feedback is an oppose vote in the next application, I think the procedure is questionable; using an issue against a candidate which is unresolved because it was never addressed, in my opinion is not a good thing. Krd 17:47, 7 September 2023 (UTC)[reply]
Oppose - per JJMC89 - Faendalimas (talk) 17:30, 3 September 2023 (UTC)[reply]
Oppose while I have no issues with his CU actions, I do have an issues with the unreviewable blocks he has made in his capacity as a CU. While Materialscientist and I have different views on vandalism blocks, which I don't really hold against him, what I do have an issue with is that he has CU block very large ranges as hard blocks without running a check. This has the impact of preventing non-CU admins from reviewing without the input of a CU; and for IP ranges most won't review because they assume something private was involved. While it is not an abuse of the tool itself, it is an abuse of the status to make a block unreviewable. I'm opposing on those grounds. Note that I cannot speak to any specific block per the privacy policy, but the en.wiki Arbitration Committee can confirm that I have reported this abuse in the past. TonyBallioni (talk) 17:51, 3 September 2023 (UTC)[reply]
See my reply above. I am well known on en.wiki for a highly liberal view on my blocks, allowing to lift them at will. All you need is a brief message on my talk. Further, most admins merely assume that CU blocks are unquestionable and don't even try to discuss them. CUs, me included, may and do reveal some block details and reasoning, on Wiki and/or off Wiki. The discussion that I've linked above. Is an example of how it could be done. Materialscientist (talk) 22:42, 3 September 2023 (UTC)[reply]
Materialscientist Did you made a CheckUser block without running a check? If so, why? I thought that CheckUser blocks are only for blocks involving CheckUser data, right? —‍Mdaniels5757 (talk • contribs) 19:13, 4 September 2023 (UTC)[reply]
No, see my reply to JJMC89 above. Further to that, some targeted users from that range alternately edited using accounts and IPs (this is easy to tell from editing pattern and filter logs); this gave extra data on the editing activity. Materialscientist (talk) 21:39, 4 September 2023 (UTC)[reply]
You didn't check the whole range, only some /64s. (see above) — JJMC89 (T·C) 23:14, 5 September 2023 (UTC)[reply]

Mdaniels5757, so I can't really get into specific details because of the privacy policy but to put this in clearer terms, what Materialscientist is saying here isn't factually accurate and while I don't think he is lying as it isn't intentional, the fact that his response to this has been what it is actually makes me more concerned because it shows he doesn't understand how CU and IP range blocks work.
Basically what MS did was make a range block that could be the equivalent of an entire geographic region with millions of people as a CU hard block based on the results of checks of individual connections within that range. Yes, the range has been abusive, but that's a major problem. Additionally, while he is correct that the CU tool times out on large ranges, that is actually an indication that a hard block should not be placed - it times out after around 5000 hits in a range. That means it is highly active and contains significant collateral. His response to JJMC89 above shows a lack of understanding of how this works. The other problem is that we can see if someone checks a range even if it times out: Materialscientist did not even try to check the range I have a concern about. Just individual connections. The fact that he has said he intended it to be a hard block is also really concerning because with the collateral that he should have known would be there, it means that he was intending to cut of editing access to a large number of users to stop one person from editing.
To be clear, I don't think any of this was done in bad faith based on his responses here. But I do now have even more serious concerns now because the responses show a lack of understanding of how what he wants to do works. (Also, I'm traveling until after this RfCU is done, so responses will probably be significantly delayed.) TonyBallioni (talk) 13:09, 6 September 2023 (UTC)[reply]
Just a comment here for people unfamiliar with how privacy works the users here with private knowledge are saying as much as they can they cannot give specific details because of the Privacy Policy. I voted above in agreement with JJMC89 I am familiar with the case it was brought to my attention for a clarification on this policy. I agree with TonyBallioni that MS is acting in good faith, but my personal view is he could use some more experience on ENWP where there are highly experienced people to guide him particularly on this issue of range blocks. The collatoral damage is significant and is best avoided. He needs some time to learn these tools better before venturing to multiple projects. Cheers Faendalimas (talk) 18:02, 6 September 2023 (UTC)[reply]
Support--Kadı Message 18:49, 3 September 2023 (UTC)[reply]
Support --Ooligan (talk) 04:20, 4 September 2023 (UTC)[reply]
Support ―― Phoenix7777 (talk) 08:53, 4 September 2023 (UTC)[reply]
Oppose per JJMC89 and Amanda --Guerillero ^{Parlez Moi} 10:07, 4 September 2023 (UTC)[reply]
Weak oppose per some of the above Herby ^{talk thyme} 10:18, 4 September 2023 (UTC)[reply]
Oppose - My en.wiki SPIs not uncommonly take 5-12 days to be reviewed. If en.wiki CUs are so overburden as implied by these (unacceptable) turn-around times, they do not appear to have the capacity to extend themselves into other projects. Эlcobbola _talk 13:53, 4 September 2023 (UTC)[reply]
I cover different tasks on en.wiki and Commons. I don't cover SPIs on en.wiki (there are 46 active CUs over there), and get to en.SPIs via personal messages. My reaction to such messages is quick. Materialscientist (talk) 01:21, 5 September 2023 (UTC)[reply]
Support 1989 (talk) 17:14, 4 September 2023 (UTC)[reply]
Support --Ruthven (msg) 07:40, 5 September 2023 (UTC)[reply]
Support Thanks for volunteering. --Bedivere (talk) 03:26, 6 September 2023 (UTC)[reply]
Support - Beyond My Ken (talk) 07:28, 6 September 2023 (UTC)[reply]
Oppose Some of the arguments made sound like en-wiki internal struggles, but Elcobbola makes a fair point. Materialscientist's answer to their oppose confuses me. They are an en-wiki CU but they don't handle public requests made via formal channels, but they handle private requests as some kind of express VIP-lane? Natuur12 (talk) 21:23, 6 September 2023 (UTC)[reply]
I'd assume they mostly use the tools in the course of their own antiabuse investigations. 𝟙𝟤𝟯𝟺𝐪𝑤𝒆𝓇𝟷𝟮𝟥𝟜𝓺𝔴𝕖𝖗𝟰 (𝗍𝗮𝘭𝙠) 23:39, 11 September 2023 (UTC)[reply]
Correct. Roughly a dozen of abusers per day require an urgent CU scan on en.wiki to quench their activity; on a bad day this could be dozens. They are priority on en.wiki for abuse fighters like me, and perhaps user:Zzuuzz. When handling SPIs, the starting checkuser has priority and advantage, because they have past data from the case. This is a reason why other checkusers often pass, resulting in a backlog. The situation is very different on Commons, where vandalism is much less frequent, and SPIs have priority. Materialscientist (talk) 00:25, 12 September 2023 (UTC)[reply]
Oppose per multiple concerns raised above, in particular by TonyBallioni and Эlcobbola. --AFBorchert (talk) 17:30, 7 September 2023 (UTC)[reply]
Oppose I suggest they improve the CU practices in English wikipedia first, before coming to commons. Эlcobbola and specially Natuur12 made good points. Due to my own experience in the English Wikipedia I oppose CU action on secret (not public) evidence.Paradise Chronicle (talk) 06:35, 8 September 2023 (UTC)[reply]
I note for the closing bureaucrat's consideration that your experience on enwiki is summarized at w:en:Special:Permalink/1168241769#Paradise Chronicle. —‍Mdaniels5757 (talk • contribs) 21:27, 8 September 2023 (UTC)[reply]
Not quite correct, the "investigation" leading to the CU block without public evidence (no diffs or links to eventual mistakes) is to be found here. I then tried to find out why I was blocked, (for which edits), as I was not adverted of any mistakes at the talk pages by the blocking CU. Paradise Chronicle (talk) 22:29, 8 September 2023 (UTC)[reply]
Oppose.--RZuo (talk) 07:41, 9 September 2023 (UTC)[reply]
Support. -- Michael Bednarek (talk) 14:31, 9 September 2023 (UTC)[reply]
Oppose, per JJMC89, Amanda, and Эlcobbola. Still like to say thank you for volunteering. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 22:55, 10 September 2023 (UTC)[reply]
Oppose Per Amanda et al, as well as my own experience along similar lines. --AntiCompositeNumber (talk) 17:32, 11 September 2023 (UTC)[reply]
Oppose per the concerns raised above by a number of experienced functionaries. Extraordinary Writ (talk) 18:50, 11 September 2023 (UTC)[reply]

Comments

Question Per m:Volunteer Response Team/Volunteering#Materialscientist I understood that you are going to focus on deletion request and permission tickets. Is CU an additional task you like to introduce to yourself at the same time? --Krd 07:32, 27 August 2023 (UTC)[reply]
Yes, these two are absolutely unrelated. Roughly speaking, the VRT nomination is about handling DRs, while CU aims at fighting abuse. I do both. Materialscientist (talk) 07:47, 27 August 2023 (UTC)[reply]
Question: Would you CU block an editor without having received a report against them from anyone on commons? (I was blocked like this in the en.wiki, that's why I ask.)Paradise Chronicle (talk) 06:50, 2 September 2023 (UTC)[reply]
Question:Would you CU block an account without having adverted them of an eventual violation? (I was also CU blocked without having been adverted of a violation on en.wiki and would have happily just edited with one account if given the option before being CU blocked)Paradise Chronicle (talk) 08:05, 2 September 2023 (UTC)[reply]
I guess you refer to a well-meaning editor who didn't know our policies on the use of multiple accounts, and your questions are 1) whether a checkuser may access CU logs without a community request? They may, at their own risk. All CU actions are logged, they can be questioned, and result in removal of CU rights. 2) Whether a checkuser may block on sight if they find evidence of abusing multiple accounts? Same answer. 3) What is my approach to 2)? It is highly individual. On-sight blocks are justified only when the situation is crystal clear, otherwise there must be a discussion, public or via email (e.g. via checkuser mailing list). The block severity depends on the situation. In case of abuse it may be indef hardblocks to all involved accounts. In case of obvious ignorance, the user may get away with a friendly message on their talk asking to consult our policies on the use of multiple accounts. Materialscientist (talk) 08:16, 2 September 2023 (UTC)[reply]
Thanks for the answer. For potential readers to clarify: Materialscientiest was not the CU who blocked me, and I AGF on them that they'd have AGFed my actions at the time as well. I have often observed them combatting vandalism during my rollback runs in the en.wiki. Paradise Chronicle (talk) 08:56, 2 September 2023 (UTC)[reply]

Commons:Checkusers/Requests/Materialscientist

Materialscientist

Votes

Comments

Navigation menu

Search