Jump to content

Wikipedia:Volunteer Response Team/Userright RfC

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by MalnadachBot (talk | contribs) at 08:24, 27 February 2023 (Fixed Lint errors. (Task 12)). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Hi all,

Over at Wikimedia Commons, there has been an OTRS userright (applying autopatrolled permission) for quite a while. Although it does little on the surface, it allows a log to be kept of tags showing OTRS permission added by users who are not agents (or not flagged as such). I would like to propose a similar userright (that maybe grants reviewer or something else minor) that can be used with a filter for a similar purpose. I do not have any figures about how widespread this is on enwiki, and doubt I could get them very easily without having to monitor every single use of the template. This will also allow for easy identification of OTRS agents, and avoid situations such as this.

My proposal is as follows: Create an "otrs-user" right on enwiki as well. Then, create an edit summary to pick up any addition of {{permissionOTRS}} or {{ConfirmationOTRS}} by users not in the groups (like this one). The right can be requested on a new subpage of WP:PERM (or requested on the otrs private Wiki, depending on how much disclosure people think this needs on-wiki.

Specific changes to drive
  1. Software Requests (need to be completed by developers)
    1. Create a new user group on enwiki, named OTRS members
    2. Add the read permission to the new group
      Groups appear to require any permission in them in order to work – goal here is to simply have a group exist
    3. Update the sysop group permissions Add groups and Remove groups to include the new group
  2. Edit-filter requests (can be completed by admins/ef-managers on-wiki)
    1. Create an abuse filter to apply tags using the new group as a condition

Just to clarify, this adds no special permissions or rights to any users – it only enables easy identification of agents, and shows up possible abuse of the permission system.

Support

The adding of this flag will probably be done at the same time as applications are being processed because most OTRS admins are also admins here. Green Giant (talk) 08:37, 8 September 2014 (UTC)[reply]

Oppose

  • This looks like a solution in search of an issue. I can't image that there are more than 5 images tagged as received by OTRS per year by accounts that are obviously not answering wikimedia emails. In addition there are a host of questions about this. For instance, would every oversighter get the permission? We all have OTRS access to answer OS tickets but many of us don't touch the images portion of the ticket system. What about people that only have access to chapter queues? On commons this works because most commonsists answer emails about images. --Guerillero | My Talk 04:30, 13 September 2014 (UTC)[reply]
    Hi Guerillero, hmm, I don't know about the situation on enwiki, but I know that our experience on Commons is that this is actually a pretty common issue, see https://commons.wikimedia.org/wiki/Special:AbuseLog?wpSearchFilter=69. There's even a user project dedicated at evaluating all these changes (https://commons.wikimedia.org/wiki/User:Krdbot/af69). As far as your other remarks are concerned, it seems to me that the idea is to restrict this flag to users who actually deal with stuff in Permissions (see the comment section below). Cheers, — Pajz (talk) 10:52, 13 September 2014 (UTC)[reply]

Comments

Why not let other OTRS members add new OTRS members? They are in the best position to verify who has access to what. Microchip08 (talk) 09:59, 1 September 2014 (UTC)[reply]
@Microchip08: not sure if this is possible, I'll ask around. --Mdann52talk to me! 10:40, 1 September 2014 (UTC)[reply]
@Microchip08: I had a chat with a few of the technical folks over on IRC and while this is technically possible, however would need some major code changes, so is not really feasable. --Mdann52talk to me! 11:27, 1 September 2014 (UTC)[reply]
@Mdann52: It looks like it should be easily done; see commons:Special:ListGroupRights section "image reviewers". Cheers, Thanks, L235-Talk Ping when replying 15:22, 1 September 2014 (UTC)[reply]
@Mdann52: I'm not sure who told you this, but it is definitely a very simple configuration change. --Krenair (talkcontribs) 18:54, 4 September 2014 (UTC)[reply]
Agreed with Lixxx235, new Commons license reviewers can be added by both admins and existing license reviewers, so it should be possible to do the same with OTRS. Green Giant (talk) 16:21, 1 September 2014 (UTC)[reply]
I'm not sure that non-admins should be able to assign the right. I don't see a reason to deviate from the current practice. Given the wide array of OTRS volunteers I would suggest restricting the assignment of this right to crats or admins at the very least (I believe on Commons it currently requires a crat). Rjd0060 (talk) 16:00, 2 September 2014 (UTC)[reply]
I'd also note that given the number of new OTRSers that get added, it's not a huge administrative burden if it is only admins who can add this user right to new OTRSers. —Tom Morris (talk) 15:32, 4 September 2014 (UTC)[reply]
@Mdann52: what would be the major hurdles to creating a group that makes use of existing permission lists? As the recent superprotect fiasco showed, creating a group with entire new permissions groups was able to be rolled out rapidly. — xaosflux Talk 17:03, 1 September 2014 (UTC)[reply]
@Xaosflux: I'm not sure. The person who I talked to (in #wikimedia-tech and from WMDE seemed to think it would need a lot of code, but we could request it and see how it goes. I'll file a shell request in a few days unless there is clearly no hope of success (better to get into the queue early!) --Mdann52talk to me! 20:37, 1 September 2014 (UTC)[reply]
Don't imagine this would be very difficult, and finding the sister request that was sued for commons: would be a good reference. — xaosflux Talk 20:51, 1 September 2014 (UTC)[reply]
  • I've read and reread this proposal multiple times, and I'm quite confused about the point. Why do we need to create a userright to review image permissions, since the reviewers already have the OTRS permission? {{Centralized discussion}} says about this discussion "Should OTRS agents have a userright to identify themselves?", which is also unhelpful because the OTRS agents can easily identify themselves without a userright: you just need to add text to your userpage saying "I'm Jimbo Wales from Florida" or something like that. Nyttend (talk) 03:57, 2 September 2014 (UTC)[reply]
@Nyttend: the idea is to make OTRS agents identifiable on-wiki by both users using popups (like sysop), and to edit filters(to stop fake permission templates). This is similar to the very successful they already use on Commons. --Mdann52talk to me! 05:49, 2 September 2014 (UTC)[reply]
I think that's a pretty good way to sum it up. Though I personally feel the latter is of more importance. The former can be rectified by a note on a userpage or a category - but this would help for those who like lists. Rjd0060 (talk) 00:56, 3 September 2014 (UTC)[reply]
  • Perhaps 'autoreview' would be a better userright to add. At the moment pending changes level 2 is not (widely) used so it doesn't have any effect, however if PC2 is used more widely it will be a useful userright for OTRS members to have. Such as if they aren't a reviewer and get a ticket they need to action on a PC2 protected article, their edit would need to be approved. Callanecc (talkcontribslogs) 03:18, 4 September 2014 (UTC)[reply]
  • autoreview is currently included with Autoconfirmed so it's another no-impact change. I'm guessing there are a lot of future user rights for OTRS to have in general, but think that splitting that conversation to another thread would be better then getting that decision in the critical path of this decision. The most likely additional item that would be non-controversial would be to add the "add/remove" groups to this group, for this group only. (enabling self-service). Why it could be contentious is that these are enwiki permissions being discussed, but OTRS is not managed by enwiki. — xaosflux Talk 03:28, 4 September 2014 (UTC)[reply]
  • I actually suspect that allowing groups other than admins and crats to change user rights will be the most controversial aspect as it's a major change from what we currently have on enwiki. Possibly also preventing people from using OTRS templates but that's just a tick box in the Abuse Filter. Callanecc (talkcontribslogs) 04:18, 4 September 2014 (UTC)[reply]
  • Why not make it a global group as mentioned in the supports above? That does make sense as it would probably be easier to accomplish, and be useable on all of the sister projects as OTRS does serve them all. So it would be easier then instead creating it for a local group for each sister project. Since it is already on Commons, why not? --Clarkcj12 (talk) 05:48, 4 September 2014 (UTC)[reply]
  • A global group might not work in the short-term because OTRS is split into numerous queues and most OTRS members only have access to a few queues depending on the type they want to deal with and the languages they can reply in. It is somewhat different from global rollback or global sysops who can perform pretty much the same tasks on any content-wiki. In contrast, an English-speaking OTRS member might have access only to the permissions-en and permissions-commons queues (i.e. image-related matters) but would not be involved in any other queues and thus could not act as an OTRS agent on other wikis like French or German Wikipedia. Having a local group would enable OTRS members to be clearly identified for the specific areas they can work in, once they have been given access to the OTRS system centrally. In the long-term it would probably need a software tweak to enable the global group to be set in such a way that the user would only be identified as OTRS on relevant wikis. Green Giant (talk) 10:17, 4 September 2014 (UTC)[reply]
  • On the question of allowing any local sysop and/or existing OTRS member to grant new OTRS members the right, please bear in mind that OTRS members are highly trusted users who have already undergone a volunteering/selection process on Meta including possibly providing identification to the WMF before they are given access to potentially sensitive material. So for example, when an admin adds the OTRS right to a new member on Commons it doesn't require extensive discussion or analysis because all they have to do is check on meta:OTRS/Users and if need be ask an OTRS admin. Even if a rogue OTRS agent surreptitiously assigns the local right to his/her friends, it will not automatically give them access to the OTRS system; at most they will become a reviewer or an autopatroller. The act of assigning the new right should be logged so we can always review who has performed this action and whether they were justified in doing so. Green Giant (talk) 10:17, 4 September 2014 (UTC)[reply]
  • ALL user groups actions on enwiki are recorded in the user rights log, provided they are performed here (as opposed to by stewards on meta for example). A list of users by group is also always available. — xaosflux Talk 23:12, 4 September 2014 (UTC)[reply]
  • Comment from OTRS admin: If this proposal passes, I am happy to incorporate adding this flag to new OTRS accounts as part of our (OTRS admins) account creation process. The majority of the OTRS admins are administrators locally and could add/remove the flag when they create/close accounts with access to info-en or permission-en related queues. Tiptoety talk 17:49, 4 September 2014 (UTC)[reply]
Yes, it would be limited to only users on OTRS Team, which most agents that deal with images/text usually from my knowledge have access to the permissions-commons and the permissions-en. As least as far as I can tell from this proposal. --Clarkcj12 (talk) 19:08, 7 September 2014 (UTC)[reply]
Mike I believe it is intended only for OTRS members who have access to permissions-en and info-en, because permissions-commons is more relevant over there and has its own equivalent user-right. Green Giant (talk) 20:00, 7 September 2014 (UTC)[reply]
But this user-right would not be assigned to agents with access to info-en only, right? From what I've seen, permissions releases are rarely, if ever, handled through the info-en queue. If this proposal is primarily for setting up a filter to identify users who are adjusting permissions template, an info-en only agent has no more information than a user without OTRS access. Mike VTalk 20:43, 7 September 2014 (UTC)[reply]
I may be mistaken, but can't every OTRS volunteer (I've always had both) at least see (through search at least) tickets in the permissions queue? If so, I don't see why any volunteer wouldn't be able to have this flag. For instance, there might be a post on the OTRS noticeboard that asks about an image that was missed by the OTRS volunteer who handled it that would be seen in the ticket by the other OTRS volunteer. TLSuda (talk) 00:59, 8 September 2014 (UTC)[reply]
Hi Clarkcj12, Green Giant, and TLSuda: Not every OTRS agent can see tickets in permissions queues, there are probably many hundred agents who can't. Basically people with full access to all info-en queues and people with access to the photosubmission queue can also read tickets in permissions. But that's about it. In all other cases, the "Permissions" bit has to be specifically granted at some point which generally only happens when people state they want to help with the issues there. In my opinion it would make sense for the enwiki community (or the entire community if that is implemented globally -- which would make even more sense IMO) to restrict this flag to people with the "Permissions" role in OTRS. I mean, this is about people adding a permissions template on file description / article talk pages, right? People who do that should all be able to respond to and close tickets in Permissions. If there was really someone who regularly adds permissions templates on enwiki pages but has read-only access to the permissions queue through some other role, then I'd argue that in the interest of efficiency they should get the Permissions role in OTRS.
(Note that theire is only one 'Permissions' role in OTRS. This gives full access to all queues that are related to permissions, i.e. permissions-en, permissions-commons-fr etc.)
Best, — Pajz (talk) 10:45, 13 September 2014 (UTC) (OTRS admin)[reply]
  • If group is added, we should centralize all request to one place, such as OTRS noticeboard and verification of existing OTRS agents (or admins) will be required to prevent fake request. Revicomplaint? 04:11, 9 September 2014 (UTC)[reply]
    • Hi, Revi. I think the best way to avert that is, if the proposal passes, the OTRS admins will be tasked with creating the list of users who need to be added and be responsible for either implementing the changes or reporting to the necessary usergroup to make the change. Rjd0060 (talk) 17:28, 22 September 2014 (UTC)[reply]

Group is Ready!

The change has been completed, the user group OTRS members is now available. The group has no special rights, only being granted the redundant (read) permission. enwiki sysops can add/remove members from the group.

To do:

  • (OTRS people) - decide where to coordinate updating this group
    • Include updating the general groups/access levels/permissions documentation pages to be clear what this is, and what it is not
  • (ef editors) - write a log-only (initially) edit filter for what you wanted to accomplish
  • Edit happily! — xaosflux Talk 21:38, 23 September 2014 (UTC)[reply]

And another reminder about the RFC for a global group to supersede this one (see m:Requests for comment/Creation of a global OTRS-permissions user group for that. Also, regarding the above - the edit filter was already set up but needs to be modified to meet en.wiki (it was simply copied from Commons). I've poked somebody on this. There are 6 templates on this wiki that need to be monitored. Rjd0060 (talk) 15:12, 24 September 2014 (UTC)[reply]

I've made a suggestion in the comments for the regex code we could use if people could have a look and make sure it'll work. Callanecc (talkcontribslogs) 06:42, 25 September 2014 (UTC)[reply]