Stewards' noticeboard/Archives/2019-09

2019 Persian Wikipedia Arbitration Committee Election

Hello Stewards,

This is the fourth year that the Persian Wikipedia community is going to hold the Arbitration Committee Election using SecurePoll just like the English Wikipedia. We have taken care of all the arrangements. We just need one steward or two to volunteer to serve as scrutineer(s). We would prefer if scrutineers do not have much involvement with fawiki in order to help preserve the integrity of the election. The current timetable will have voting between 25 October and 7 November. We expect a voter turnout of about 100 users, so the task would not be boring or time-consuming. Like last year, we will use phab:T230614 for further coordination. Please feel free to contact me if you have any questions. Thanks in advance, 4nn1l2 (talk) 10:49, 1 September 2019 (UTC)

I'd be happy to help. – Ajraddatz (talk) 13:06, 1 September 2019 (UTC)

I can help in that too. einsbor _talk 14:43, 1 September 2019 (UTC)

Thanks. I added your names to fa:ویکی‌پدیا:انتخابات هیئت نظارت/دور دهم#برگزارکنندگان and subscribed you both to phab:T230614. 4nn1l2 (talk) 16:14, 1 September 2019 (UTC)

If needed I would be glad to help aswell. Linedwell ^[talk] 20:21, 1 September 2019 (UTC)

Thank you Linedwell; we will list you as a reserve scrutineer. 4nn1l2 (talk) 15:05, 3 September 2019 (UTC)

This section was archived on a request by: 4nn1l2 (talk) 16:14, 1 September 2019 (UTC)

Change of global rights

Hej!

On svwiki, we are discussing the removal of the move-rootuserpages-right from non-sysops. It has now come to our attention that Global renamers do not have this right. To not cause problems, we would therefor need to add this right to this global group. Do we have to start a RfC about it, or could such a request pass without a wide discussion? Sextvå.tvånoll.ettsjunoll.sjufyra (talk) 17:20, 27 September 2019 (UTC)

@Sextvå.tvånoll.ettsjunoll.sjufyra: global renamers is not actually a global group; its just a user group on meta. Unfortunately then, removing the right would probably mean that global renamers couldn't move the pages. However, can I suggest the following solution:

• Create an abuse filter that, if the user is not a sysop, prohibits any moves of root user pages

This would effectively remove the right from non-sysops. But, since the prohibition would be implemented via the abuse filter, it wouldn't affect moves that are a part of global renames; global renames are exempt from abuse filters (see CentralAuthHooks::onAbuseFilterShouldFilterAction). Would this solution meet your needs? --DannyS712 (talk) 17:56, 27 September 2019 (UTC)

The global rename process ignores standard user rights restrictions when performing actions. Removing this permission from non-admins will not impact the global renaming workflow. Regards, – Ajraddatz (talk) 19:51, 27 September 2019 (UTC)

Big thanks! Sextvå.tvånoll.ettsjunoll.sjufyra (talk) 06:37, 28 September 2019 (UTC)

This section was archived on a request by: Trijnstel_talk 16:45, 28 September 2019 (UTC)

Thoughts on revitalization of Steward_requests/Global

Not only poor performance with global requests directly help vandals, but it also leads to frustration of users. One can submit a request for an IP block, see it suspended in the backlog for days, and finally denied on pretext that the abuser already changed IP. A possible solution follows:

1. Select a pool of 7–10 stewards handy with (un)blocking and locking job, at least for typical cases.

   Other stewards should generally specialize on other jobs, but of course should not be precluded from making certain job in this sector, as explained below.

2. One person of the pool should be on duty at any moment of time.

   It shouldn’t be implemented as a kind of periodic timetable, fixed-duration shifts, etc. Going on- and off-duty can be made by dynamic, real-time agreements. “Shifts” may be of variable duration due to requirements and preferences by each steward.

3. For each new development about global blocking and locking during his/her duty the steward in question should make an assessment.

   It may be expressed in approval, denial, putting {{status| on hold }}, removal (for obvious disruption), but some other modes exist too. The steward on duty may simply make a comment in the section suggesting the reason why is s/he unsure which action to entertain. Calling for help from another authority should also be permitted, under pretexts: a LTA for whom a better expert exists, unfamiliar language in evidence, some specifics of an involved wiki, special unfamiliar tasks, etc.

4. If time permits, the steward going off his/her duty should brief the replacement steward.
5. A steward going on-duty should also make assessments for some (if not all) cases from the backlog.

Regards, Incnis Mrsi (talk) 17:54, 5 September 2019 (UTC)

Stewards are volunteers, they shouldn't be made / mandated to stay online / on duty at a specific time. If you really/absolutely need a fast response (vandalising IP on the run sort of stuff), pop over at #wikimedia-stewards (on IRC) and make a request.  — FR (mobileUndo) 18:04, 5 September 2019 (UTC)

To be fair IRC requests are fairly slow lately too but I don't know the solution to the backlog and I'm not even sure what this proposal is actually proposing. Praxidicae (talk) 18:07, 5 September 2019 (UTC)

• SRG gets so backlogged because 1) technological limitations mean that endless spambot accounts are allowed to be created, and 2) it is very difficult for us to see the abuse coming from an IP range and the potential consequences of blocking it. If you can get the WMF to implement a better CAPTCHA and create a tool that instantly or nearly instantly loads the global contributions for an IP address or range, and includes useful links that complement our workflow, then the problem would go away tomorrow. A script that easily allows us to close SRG requests would also be nice. Other than that, I don't think your idea would be workable. I handle requests in my free time, which is highly variable and often not confined to set hours. I know that most other stewards are in a similar position. – Ajraddatz (talk) 18:14, 5 September 2019 (UTC)

Ajraddatz I mentioned this in another thread but it seems this year that Stewards have gotten overloaded (whether that's a result of an influx of abuse/spambots, I don't know, well except there seems to be an exceptional amount of spam) but I'm wondering if perhaps twice yearly elections might help? Praxidicae (talk) 18:19, 5 September 2019 (UTC)

I personally doubt it, though I would be open to trying it. Most stewards are very inactive, but the reality is that less and less people want to become a steward. We've gone from 20+ candidacies per year to under 10 on average, at a time when our workload has significantly increased. – Ajraddatz (talk) 18:22, 5 September 2019 (UTC)

Again “… dynamic, real-time agreements” – no preset hours for anybody. Even no disaster for the case when nobody was on duty for some few hours, perhaps only urging to expand the pool. What namely should the script do: payload actions, stamping {{status}} and writing a closure statement, no more? Incnis Mrsi (talk) 18:26, 5 September 2019 (UTC)

@Ajraddatz: Why not create a global group, global-blocker? I am sure it will be helpful to reduce backlog over at Steward Requests/Global. As for the hat collecting issue, we should grant this right via a community discussion and with a very strict criteria. Masum Reza^☎ 12:05, 8 September 2019 (UTC)

Unfortunately, the global community has not supported that idea in the past. – Ajraddatz (talk) 14:19, 8 September 2019 (UTC)

Ah. Sorry. Masum Reza^☎ 16:44, 8 September 2019 (UTC)

• Is it not the case anymore that that page is mainly for non-urgent requests, while urgent stuff gets done on #wikimedia-stewards by waking up everyone using the dreaded "@stewards" followed by "!stewards"? If so, I would say the way the page works is perfectly fine. --MF-W 12:23, 9 September 2019 (UTC)

  @MF-Warburg: to me, an urgent request may pertain to a crackpot pushing rubbish as an IP (or going amok with an acc) on no less than two Wikimedia sites at rate comparable to possibilities of using [rollback] by a global rollbacker. Ordinary vandals, spammers, and puppeteers raise regular (not urgent) requests… but on most sites there are 7–8 days for doing a regular request. Not so many global block requests are granted (or processed at all) within 8 days here. Incnis Mrsi (talk) 20:36, 9 September 2019 (UTC)

  To be honest, I don't understand how this is a reply to my point. Can't "crackpot rubbish IPs", i.e. urgent cases, be reported in #wikimedia-stewards? Are they not dealt with in a reasonable time there? --MF-W 12:24, 10 September 2019 (UTC)

  They are not dealt with in a reasonable amount of time there during the European night. A large majority of stewards who use IRC do not use a persistent IRC connection, so they often don't even see these requests in their backlogs.--Jasper Deng (talk) 06:42, 11 September 2019 (UTC)

  especially during the part of the night when both the US East Coast and Europe are asleep. I'm not on IRC much anymore but when I had to come on and get an emergency desysop I had to wait several hours. --Rschen7754 07:21, 11 September 2019 (UTC)

• I can't make any promises right now, however I will try to create a script for closing requests at SRG — FR (mobileUndo) 18:31, 9 September 2019 (UTC)

  Might not be necessary - looks like User:ASammour/test.js does this! – Ajraddatz (talk) 20:29, 9 September 2019 (UTC)

Proposals_for_closing_projects/Deletion_of_Bulgarian_Wikinews#statement

LangCom has recommended the closure and deletion of this project, but some of the rationale relates to the alleged abuse of admin permissions. --Rschen7754 18:44, 11 September 2019 (UTC)

I think we may make notes of it but I don't think we are going to do something given that the site is going to be wiped anyway... — regards, Revi 00:33, 17 September 2019 (UTC)

Steward Closure Requested

Hello. A community consultation on the use of partial/temporary bans is scheduled to open shortly. At that page, a steward closure is explicitly suggested. I'd like to get an uninvolved volunteer willing to close that discussion. Such a closure will likely minimize drama, especially on en.wiki. If this request is in an incorrect location, please move it to the correct one. Thanks, Tazerdadog (talk) 10:50, 16 September 2019 (UTC)

Are you asking for a volunteer to close it in the future, or are you asking for a volunteer to close it now? Vermont (talk) 23:42, 16 September 2019 (UTC)

It is not open so it cannot be closed now - I take it as they are asking for someone to close it in the future. (NOTE: Not me.) — regards, Revi 00:35, 17 September 2019 (UTC)

I am asking for a volunteer to close it after the discussion has finished. Tazerdadog (talk) 15:29, 17 September 2019 (UTC)

I think it's unlikely any steward would volunteer that now, prior to the actual discussion. It's probably best to just wait, as the stewards are aware that they are being asked to close it. Vermont (talk) 17:44, 17 September 2019 (UTC)

If WMF wants us to close it before they do it themselves, they know where to ask for our closure and the door is open. (Whether any of us decide to do the work is a different story but anyway) If they think they want to clarify this before the consultation begins, I think they would ask us before then. — regards, Revi 14:43, 18 September 2019 (UTC)