Meta:Requests for comment/Meta checkusers and stewards
Appearance
The following request for comments is closed. After more than four months of discussion, there is no consensus to grant local CheckUser rights to stewards here at Meta, even discounting my own vote. 25 supporting votes and a percentage of support of at least 70/80% is needed to grant this permission to only one user, and this proposal is very far to achieve this level of support. Syum90 (talk) 11:39, 19 August 2016 (UTC)
Statement of the issue
[edit]A simple proposal: during their term stewards are given CU access. Meta can also elect permanent local checkusers (regardless of their possible stewardship).
The reason: this will reduce workload by avoiding the need to make checks at loginwiki, thus increasing transparency since meta would become a central place for logging. Please tell if this provision should be valid even when and if global checkuser will be implemented. --Vituzzu (talk) 20:10, 8 April 2016 (UTC)
Comments
[edit]- I completely agree with the proposal. Currently all Meta CheckUsers are stewards, which in practice means we're allowing access to a small group of the stewards and preventing the others from performing checks here, which makes no sense. I think the local CU group was supposed to also include non-stewards who wish to help, otherwise it'd be better to just remove it in order to allow all stewards to fulfill this role. Defender (talk) 20:27, 8 April 2016 (UTC)
- Yep that was another proposal but it won't solve a thing since:
- Meta can elect non-stewards checkusers at any time
- Stewards would need to add (and remove) them from the group, exactly the issues we want to solve. --Vituzzu (talk) 20:45, 8 April 2016 (UTC)
- The reasoning above is a bit misleading: loginwiki provides the exact same data as Meta would provide, except for edits, since we can't edit at loginwiki. That said, we mostly use CU to global IP block locked accounts since we lack a global autoblock feature. Also, I was elected CheckUser before being elected steward two times (cf. RfCU #1 and RfCU #2). Why I should be removed when I was community elected to perform this job? Non steward CU's included Herby and Tiptoety who performed and excellent work here. This will virtually prevent non-stewards to access this right even if they need to on the perception that we've got already "too many of them". Why I shouldn't be allowed to continue if I decide to step down as steward in the future? Most of Meta-Wiki maintenance is not performed by stewards. —MarcoAurelio 09:58, 9 April 2016 (UTC)
- I certainly agree that what we need is a global CU tool, but that is years in the future. I also agree that there should be the potential for local non-stewards to become CUs - but I would like to balance that with usefulness for stewards performing cross-wiki work. Adding cu/cu-log to the local steward group might be a good way of handling that, though I can understand your concerns with it taking over the local role. Ajraddatz (talk) 20:25, 9 April 2016 (UTC)
- Yep that was another proposal but it won't solve a thing since:
- Support - and this should remain in place, even with global checkuser if/when it arrives. This also has past precedent, as it was done on meta before 2006 but then removed by some unknown discussion. Ajraddatz (talk) 20:39, 8 April 2016 (UTC)
- support as per above. —DerHexer (Talk) 21:14, 8 April 2016 (UTC)
- I support this, but as it would conflict with the global CU policy, I think a RFC on a global scale would be necessary to achieve this. --Rschen7754 00:40, 9 April 2016 (UTC)
- In what way would it conflict the policy? I think the SE meets all the criteria described there. --Vogone (talk) 18:30, 9 April 2016 (UTC)
- Oppose - we already have loginwiki for this, granting all stewards +CU here is overkill. What we need is a truly global CU feature to deterr crosswiki abuse instead of this. —MarcoAurelio 09:36, 9 April 2016 (UTC)
- However I accede to the point used by Ajr on his RfCU, that checking on loginwiki is a pain, since that wiki does not allow custom CSS/JS due to security issues. If this proposal passes, I think it'd be better that, instead of adding CU flag to every steward, we added checkuser and checkuser-log rights to the local steward group. —MarcoAurelio 09:39, 9 April 2016 (UTC)
- And also bear in mind Meta:Meta–steward_relationship#CheckUser. Local requests should still be handled by locally elected personel only, which will virtually dissapear on the grounds that we've got already too much people with access. I don't think having steward rights should allow us to take over all the roles at Meta. Meta is build by a lot of people, not only us who just use it to make our work. —MarcoAurelio 09:41, 9 April 2016 (UTC)
- With phab:T102254 being fixed an now being able to parse info from loginwiki to MultiLock at Meta, I reafirm my opposition. —MarcoAurelio 10:31, 14 May 2016 (UTC)
- Oppose per MA --Herby talk thyme 10:18, 9 April 2016 (UTC)
- Oppose Does not sound like a good idea to me, for the reasons outlined by MarcoAurelio. Perhaps I would be fine with a proposal where stewards do not take over any of the local roles, but it would be hard to make sure this would be followed. --Vogone (talk) 18:27, 9 April 2016 (UTC)
- Actually MA's is a no-reason. He pointed an obvious alternative and a future solution without pointing any actual drawback out. Trying to explain myself better: the process of self assigning +CU at loginwiki, CU and remove is a waste of time which deters stewards from checking, for example, *every* spambot found. Evaluating pros and cons I see a reduction of workload vs. no drawbacks. --Vituzzu (talk) 01:05, 10 April 2016 (UTC)
- As far as I am aware most stewards active in this area just keep their flag on loginwiki and do not add/remove it every time. See also Special:UserList/checkuser. --Vogone (talk) 01:37, 10 April 2016 (UTC)
- This is true. However, there is still the issue of css/js not loading on login, so we can't use/develop any tools to expedite the abuse response from there. Allowing stewards to +cu at meta and leave it on would be an easy policy fix that would save those of us very active in the area a considerable time added up. Ajraddatz (talk) 01:47, 10 April 2016 (UTC)
- As far as I am aware most stewards active in this area just keep their flag on loginwiki and do not add/remove it every time. See also Special:UserList/checkuser. --Vogone (talk) 01:37, 10 April 2016 (UTC)
- Actually MA's is a no-reason. He pointed an obvious alternative and a future solution without pointing any actual drawback out. Trying to explain myself better: the process of self assigning +CU at loginwiki, CU and remove is a waste of time which deters stewards from checking, for example, *every* spambot found. Evaluating pros and cons I see a reduction of workload vs. no drawbacks. --Vituzzu (talk) 01:05, 10 April 2016 (UTC)
- Oppose adding stewards to local CU group, per reasons exposed by MA and Vogone. I can agree on adding checkuser and checkuser-log rights to the local steward group, although I don't like the idea, but only if it is really needed and with clear indication not to be used to perform local checks.--Syum90 (talk) 09:40, 11 April 2016 (UTC)
- As far as I have noticed, this proposal is intended to focus on addressing the technical limitations encountered in performing checks at loginwiki, due to security restrictions that prevent scripts to be loaded. Moreover, there is a lot of unlogged IP edits related to LTAs on meta-wiki - not to mention that eventually some accounts happen not to be created on loginwiki. At first, I was inclined to support this proposal. However, I find it more suitable to carry out a technical change for adding both checkuser and checkuser-log rights to the steward local usergroup, for non-local checkusers. Of course, it should also include an explicit prohibition made on a policy basis regarding the usage of the tool outside the global scope - which primarily involves dealing with LTA, spambots and any sort of cross-wiki abuse. Bearing in mind that this wiki is well monitored by the Ombudsman Commission, I don't see any problems with adding these rights to the local group. RadiX∞ 20:18, 12 April 2016 (UTC)
- I think I have now to mention that WMF is considering enabling now some scripts there, such as User:Glaisher/cuCAMultiLock.js, on the extension itself; and is also considering enabling mw:Extension:Gadgets as well, so the whole point of this proposal might be moot sometime soon hopefully. —MarcoAurelio 13:51, 13 April 2016 (UTC)
- This still leaves unsolved another somewhat neglected aspect of the problem as stated: unlogged IP edits on meta related to LTAs/spambots and some occasional issues with account creation on loginwiki. RadiX∞ 14:26, 13 April 2016 (UTC)
- That is for locals to take care of, then. —MarcoAurelio 15:04, 13 April 2016 (UTC)
- Not necessarily. If such anonymous editing is related to LTAs or spambots, then it is a potentially cross-wiki issue. RadiX∞ 04:06, 4 May 2016 (UTC)
- Would you say the same if those anonymous editing happened on enwiki, dewiki or frwiki? —MarcoAurelio 10:32, 14 May 2016 (UTC)
- Not necessarily. If such anonymous editing is related to LTAs or spambots, then it is a potentially cross-wiki issue. RadiX∞ 04:06, 4 May 2016 (UTC)
- That is for locals to take care of, then. —MarcoAurelio 15:04, 13 April 2016 (UTC)
- This still leaves unsolved another somewhat neglected aspect of the problem as stated: unlogged IP edits on meta related to LTAs/spambots and some occasional issues with account creation on loginwiki. RadiX∞ 14:26, 13 April 2016 (UTC)
- I think I have now to mention that WMF is considering enabling now some scripts there, such as User:Glaisher/cuCAMultiLock.js, on the extension itself; and is also considering enabling mw:Extension:Gadgets as well, so the whole point of this proposal might be moot sometime soon hopefully. —MarcoAurelio 13:51, 13 April 2016 (UTC)
- Support the solution and rationale provided by RadiX, local meta CU should stay local, but any technical convinience possible should be provided for stewards to make their life easier. —Ah3kal (talk) 08:01, 13 April 2016 (UTC)
- Support Same as Ah3kal. Archi38 (talk) 13:51, 12 May 2016 (UTC)
- Support, but please make a CU statistic like at loginwiki then. Luke081515 21:34, 17 May 2016 (UTC)
- Oppose per MarcoAurelio. Jianhui67 talk★contribs 12:16, 21 June 2016 (UTC)
- Oppose per MA. — regards, Revi 08:16, 6 July 2016 (UTC)
- Oppose per MarcoAurelio.--Grind24 (talk) 16:48, 18 July 2016 (UTC)
- Oppose per above. --Atcovi (Talk - Contribs) 22:24, 7 August 2016 (UTC)