| Reedy | |
| Jun 16 2022, 9:52 PM |
| F35247813: SNg (WMF)-testwiki-suppress.png | |
| Jun 16 2022, 10:40 PM |
Per a request from @SNg_WMF, Trust-and-Safety want to be able to do oversight (suppression) training with other colleagues in T&S and in WMF Legal. This is just going to be test content, so nothing sensitive.
To be able to do this, they need to be able to add people to https://test.wikipedia.org/w/index.php?title=Special:ListUsers&group=suppress which currently no one can currently add anyone to that group.
While createAndPromote.php can be used, this isn't very user friendly, nor is scalable.
This doesn't sound good to me. While testwiki is there for testing purposes, there are valid suppressions happening there, e.g. due to users accidentally editing while being logged-out.
When allowing 'crats to add users (including themself) to the suppressor group, it would allow them viewing suppressed content without necessarily having a nda.
Edit: I see 'crat has been removed from the title, but I don't see any local testwiki group this wouldn't apply to (except the local steward group)
Btw. members of wmf-supportsafety are already capable of doing this due to them having userrights-interwiki, is that not sufficient?
This should not be done. Access to the suppress group is governed by the oversight policy, which does not permit staff to just grant access.
@SNg_WMF's access needs to be revoked since the access requirements have not been satisfied.
The beta cluster can be used for training.
This access is available to oversighters, stewards and users in the staff global user group.
We can just add them to the staff global user group then...
@SNg_WMF has access to the suppression tool via the staff global group — they have not been added to any local suppress groups 🙂
That's really not what the beta cluster is for..
To avoid drama that's probably going to be the easiest option.. ✨
Personally, I don't see anything that should be changed at testwiki in this task. If T&S wants to do staff training on suppression, there are three ways I see:
Third option is likely the most sustainable one. The wiki would be capable of self-resetting to a default state, and it could host training materials as well, showing people the tools without any need of a training meeting (except perhaps for questions). It also scales very easily: either we can open it to the public (I'm slightly opposed to that) or we can (semi)automatically issue credentials to people we trust.
First or second option is much easier to do, and from that perspective, might be liked by T&S more. betacluster is slightly better, but if T&S/WMF is willing to update the policies to authorize using testwiki, it's surely a way (so long everyone going through the training is under NDA, and all staff meet requirement).
Re createAndPromote) IMO, the only legitimate uses for that script are 1) creating the first account at a private/fishbowl wiki [no other way exists] 2) emergencies. Using the script to magically add people to groups when there are other ways sounds just wrong to me (especially because it is not logged).
There are too many dramas about granting CU/OS for test/development purposes, even to WMF staff accounts:
There seems to be consensus that we will not do this, because it allows access to sensitive information and because rights can already be granted by users with the global staff right.
