Stewards' noticeboard/Archives/2021-06

From Meta, a Wikimedia project coordination wiki

Remove de.wikinews from GS opt-out

There is consensus from the de.wikinews community to allow global sysops to operate here. See wikinews:de:Benutzerin_Diskussion:Aholtman#Global_Sysops amongst others. Leaderboard (talk) 19:26, 2 June 2021 (UTC)

Done Ruslik (talk) 20:58, 2 June 2021 (UTC)
This section was archived on a request by: ~~~~
User:1234qwer1234qwer4 (talk)
13:49, 10 June 2021 (UTC)

Add maiwiki for AAR

Here is the community consensus opened for a week now, could you please add maiwiki for AAR? Kind regards, — Tulsi Bhagat contribs | talk ] 03:58, 5 June 2021 (UTC)

@Tulsi Bhagat: Why does it need to be added? It has no activity policy, thus it will be affected by AAR. --Rschen7754 05:06, 13 June 2021 (UTC)
Oh sorry, my bad. I got something wrong. Kind regards, — Tulsi Bhagat contribs | talk ] 06:22, 13 June 2021 (UTC)
This section was archived on a request by: — Tulsi Bhagat contribs | talk ] 06:22, 13 June 2021 (UTC)

Is WM:NOP targeting VPSs?

It's questionable, since I thought they're not public (their usage is restricted to their customers) in most case; such as GCP and AWS. --Semi-Brace (talk) 06:43, 4 June 2021 (UTC)

Generally not but it may be difficult to distinguish them in practice. So, if an IP address is abused then it will be assumed that it is an open proxy. Ruslik (talk) 16:25, 5 June 2021 (UTC)
@Semi-Brace Note it's very easy to spin an AWS/GCP instance and proxy your traffic through it (and to become their customer). Any time you spin an instance there, you'll generally receive a new IP address. It works similar to "normal" VPN – you can't use ProtonVPN without registering with them (and becoming their customer, even if on the free plan), but since anyone can register and use ProtonVPN's services to get new and new IPs, it's considered open as well.
Corporate proxies are different, as they require you to be somehow affiliated with the company (you can't use my employer's VPN without being their employee, for instance).
This is my personal understanding of the policy, and not a statement on behalf of stewards Martin Urbanec (talk) 12:40, 8 June 2021 (UTC)
This section was archived on a request by: Martin Urbanec (talk) 13:10, 19 June 2021 (UTC)

The RFC was closed on 18 February 2021 by Martin Urbanec stating that The bot had a genuine mistake that caused some non-proxy IP addresses to be blocked. This bug was fixed. There is nothing else to do here., even though the operator of the bot never reported fixing the bot, and quite the opposite, repeatedly denied existence of the bug in his bot. I don't see any indication that the bug was fixed, and Martin Urbanec didn't want to elaborate on this when I asked him at his talk page. Consequently, I would like the RFC reopened. --Crash48 (talk) 17:21, 7 June 2021 (UTC)

@Crash48 I'd appreciate a reminder before escalating the issue to the rest of the stewards. I didn't reply only because I didn't see your message.
I talked to @Q-bit array about their bot, and they admitted the bug and fixed it. Once I confirmed that the IPs I was aware of were unblocked (and not blocked when I edited ruwiki from them), I closed the RfC, as I believed (and I still believe) it is now unactionable.
Before reopening the RfC, I recommend to talk to @Q-bit array first – communication is much more efficient than RfCs. If you wish, I'm happy to act as a mediator.
Sincerely, Martin Urbanec (talk) 12:36, 8 June 2021 (UTC)

Closing this section, as there's no further comment, and I still believe there's nothing actionable here. --Martin Urbanec (talk) 13:10, 19 June 2021 (UTC)

This section was archived on a request by: Martin Urbanec (talk) 13:10, 19 June 2021 (UTC)

SRG backlog

There's a lot of requests in SRG that have not been taken any action yet, the oldest of which is almost a month old (16 May). MarioJump83! 02:05, 13 June 2021 (UTC)

@MarioJump83: Probably relates to the quality of the requests. Some people jump to requesting blocks when it is not appropriate (for example, dynamic IP addresses, local abuse, very short term abuse), and/or place a big long list of IP addresses. Stewards are responsible for blocking people and fielding the complaints so would typically check such requests by various means and in a thorough, somewhat time-consuming manner. So when the enthusiastic, though not necessarily diligent, place requests based on their limited knowledge it can hinder rather than help the process. [This is not reflecting on all requests there, just some of them. Also noting that I am long not a steward, so I am talking in general rather than knowing exactly where and what is happening in steward-world.]  — billinghurst sDrewth 02:27, 13 June 2021 (UTC)
To me it seems that what is lacking is 1) user education about what is abuse, and what stewards can reasonably do about it. that the template. 2) Modification to the template syructure so that reports that are typically about IPs where the abuse is short term in duration, firstly is more obvious that it is a short term block required, AND autocloses after a day or two, so that that such requests are quietly archived if not actioned. Maybe the ability to set a close date/time in status, or a modified form of status.  — billinghurst sDrewth 03:51, 13 June 2021 (UTC)
For me, my struggle is the lack of explanation often given or the lack of knowledge about abuse. When either of these two exist, I tend not to process them, though I should decline them (the script we have is not working) just so I can get through the rest of the backlog. It eventually creates a backlog of poorly done requests that are harder to deal with. Anyone placing the "Long term abuse" reason should be explaining more than just that, otherwise it's not worth the post in my opinion. -- Amanda (aka DQ) 14:37, 21 June 2021 (UTC)
@AmandaNP: I would agree, which is why I went through them last week and clerked them at face value, not knowing any CU implications.. I culled those that were expired or those that I considered problematic. I did add notes to many, and highlighted those that I thought should be undertaken, and with a term recommendation. It would be good if you good review those and process those with which you agree. —The preceding unsigned comment was added by Billinghurst (talk) 23:34, 21 June 2021 (UTC)
Ahh I hadn't seen that in my quick look today. I will go take a look as I have time. I also was speaking more to the accounts side, as I haven't nailed down the tools for IPs just yet, but will look either way. -- Amanda (aka DQ) 02:06, 22 June 2021 (UTC)

Comment Comment Stewards either need to block the IPs or close the section, or work with the community to get the reporting in the SRG to a standard that assists them.

  • You are elected to manage, so may be it is time that you did it. I didn't realise you got to pick and choose the nice duties.
  • If stewards don't want to do it then why have you put your hand up to do these tasks? Would those stewards who nominated themselves with the abuse issue as a reason living up to their mandate?
  • If there are problems with the submissions then who has the responsibility to improve the quality of the submissions? Is it the community or the stewards. All I am seeing is a lack of leadership and a disregard for the community.
  • If the only accountability for stewards is an election, and they don't communicate or make themselves accountable during the year, then that is truly sad.

That may be harsh, though I think that I am qualified to make the assessment. — billinghurst sDrewth 01:21, 25 June 2021 (UTC)