Requests for comment/Creation of a global OTRS-permissions user group

The following request for comments is closed. consensus determined, and group has been created.


Set proposal for discussion closing on 7 November 2014

Proposal edit

OTRS volunteers are important members of the Wikimedia community who respond to e-mail inquiries (called "tickets") sent to Wikipedia and other sister sites via the addresses listed on various "Contact us" pages. In addition to general question/answer-type correspondence, a portion of OTRS is dedicated to handling copyright and licensing permissions. Specifically, agents here verify copyright releases for files to be used on Wikimedia projects. These agents have "permissions access".

Once an agent reviews a permissions email sent to OTRS (assuming the ticket contains a valid release) they will then tag the file with the appropriate template (such as Template:PermissionOTRS).

Ever since these templates were put into place, there have been users (non OTRS agents) adding the permission templates to files. Sometimes they are legitimate. However many times the user is (sometimes knowingly) forging the permission to make it appear as if there is an archived ticket when really the supplied ticket number either does not exist or is for an unrelated file.

It has been difficult to combat this as the only way to review these edits were manually. However, when AbuseFilter/Edit filter was implemented, this made monitoring the usage of these Permissions templates much easier. Around the beginning of 2010 Commons created an "OTRS-member" user group. In July 2010 Commons created an AbuseFilter to "tag" all edits that were of a non OTRS-member adding an OTRS permission template to a page. Then, the edits could be manually reviewed for accuracy.

In August 2014, an RfC was created on the English Wikipedia to create a similar user group for OTRS members. As of this proposal, that RfC is still ongoing with moderate support.

Neither group (on either project) have any associated user rights that actually do anything that they cannot already do as editors. The user group is meant solely for easy identification. Otherwise, the only official method for identifying OTRS members is via a list on Meta that is only updated 1-2 times per month by an OTRS administrator. Other unofficial methods of identification include a voluntary list at OTRS/Personnel, local userboxes on the userpage of an agent and user categories.

I am requesting a global user group to be created to supersede the local groups. I am told that a global group cannot be created without any associated user rights so some obscure right would need to be added to the group (such as "purge"). This would also be required to allow local wikis to create AbuseFilters to monitor edits as they desire. A suggested name for the group would be OTRS-permissions members or something similar.

Some other notes:

  • Would make maintenance of the user groups easier thus making the actual group membership a more accurate representation of a users OTRS status. It would also centralize the location for the group-granting/removals. (For instance: OTRS administrators would not need to notify multiple wikis if a user resigns from OTRS so that their group can be removed).
  • Only users with access to the permissions queues would be assigned the global group
  • The global group will be on an opt-in basis per wiki, via the 'wikisets' options available to stewards
  • The global group should be mandatory to all users with permissions access

Discussion edit

This proposal was first presented to current agents for tweaking. It has been discussed over the years and now that individual wikis are beginning to create their own local (but duplicitous) group for this I thought that a global group would be a simpler solution. - Rjd0060 (talk) 17:36, 22 September 2014 (UTC)[reply]

  • Support Support, though detail to be confirmed as it increases a workload. There is value in the ability to identify a user with a role, and the ability to write a (global) filter that can identify that the user is, or is not, within a group. There should be some discussion about the number of users within this group, their addition to and removal from a global group, and the rights changes that come with that, and by whom. Where it becomes a larger manual task, then we need to look to either automate, the creation of bulk tools or the allocation of the ability to assign the rights to others outside of stewards. [Have you ideas around the numbers we are talking? How many now (bulk addition)? How many per month? (ongoing maintenance)] The increased globalisation has some great benefits, though it increases workloads, and there needs to be a means to manage reasonably a diverse set of rights, permissions and tasks with accountability, visibility though often more ease than a singular, and manual process.  — billinghurst sDrewth 00:00, 23 September 2014 (UTC)[reply]
Hi billinghurst. I would say we add roughly 3-8 users to the permissions role per month. As for removals, that typically only comes when a user account is closed. Roughly the same number of users will resign in a given month and a few times per year OTRS administrators perform bulk maintenance closures of inactive accounts. I do not believe the workload would increase too severely and while I am not a steward, I would imagine they are capable of absorbing this. If they would rather not, we could discuss other options - though I am not sure what options we have within MediaWiki to do this. - Rjd0060 (talk) 00:29, 23 September 2014 (UTC)[reply]
Thanks, sounds okay, and we review as/if necessary. If there are a lot of initial addition, then we may need to ask a developer whether we can push it through with an API run or a developer about how to undertake a bulk addition on the back end. <shrug>  — billinghurst sDrewth 01:16, 23 September 2014 (UTC)[reply]
Ah, yes. Currently, there are 383 users with permissions access. Rjd0060 (talk) 02:22, 23 September 2014 (UTC)[reply]
@Legoktm and Hoo man: is there an easy means to add 380+ people to a global user group? Either by the API or by back end magic? Thanks.  — billinghurst sDrewth 02:03, 1 October 2014 (UTC)[reply]
I filed bugzilla:71495 for creating an API module for this, I'd rather not resort to backend magic :) Legoktm (talk) 03:29, 1 October 2014 (UTC)[reply]
I suppose so. But if a user has photosubmissions access they more than likely have permissions as well. Currently 4 users have access to photosubmissions but not permissions. I would guess this was an oversight of some sort. On this note, I may suggest an internal change whereby the roles come together given the close relationship between the two queues. Thank you for pointing this out! Rjd0060 (talk) 17:47, 23 September 2014 (UTC)[reply]
Please also add the info-nl/wikiportret queue, since that has the same purpose as photosubmission, though you only need access to info-nl. This means uploads after someone sends in a photo, thus it also means adding OTRS tags. (And I know people with access to info-nl, but not permissions). Plus there are queues where permissions are forwarded to, such as info-sv. Maybe we should just add every OTRS member to the global group. Trijnsteltalk 12:36, 24 September 2014 (UTC)[reply]
Hi Trijnstel. There was discussion about adding every agent to the group (in fact, that is what my original proposal called for). However, after discussion it was decided to best specify/target the group, and given the fact that permissions-related queues are the only reason a user would generally need to act on wiki on behalf of OTRS, that is really the most important subset of users to categorize. In light of your comments, I think some internal changes would be best suited to integrate all info-nl users with wikiportret access (which may be al of info-nl, I would have to check) into the permissions role - as I suggested with photosubmissions. Rjd0060 (talk) 14:54, 24 September 2014 (UTC)[reply]
And what about info-sv then? Because I know, for example, that Fluff has added OTRS tags based on tickets which were moved to info-sv (permissions-sv doesn't exist yet) - which was also why he got the OTRS member flag on Commons. And that's also why I said that everyone in the OTRS-member usergroup on Commons should be added to the global group. (There are most likely more exceptions.) Trijnsteltalk 15:01, 24 September 2014 (UTC)[reply]
Trijnstel, those tickets should not be stored in info-sv. Permissions tickets that do not have their own queue should be stored in the parent permissions or permissions-commons queue. They should never be stored in info queues, with the exception of wikiportret. Rjd0060 (talk) 15:11, 24 September 2014 (UTC)[reply]
I know. And I'm not doing that anymore. But others still do. So maybe you should inform everyone or so. Trijnsteltalk 15:33, 24 September 2014 (UTC)[reply]
  • To address the issue of photosubmissions users (who add tags to the pages when they upload files), they will also be members of this group. Photosubmissions and permissions users have very similar tasks - and they can also view tickets in the others' queue. Rjd0060 (talk) 02:44, 3 October 2014 (UTC)[reply]
On a secondary note, images already designated as Public Domain on commons are often deleted for any reason, often inappropriately. OTRS volunteers do not review or act to preserve these images. I would not want any such group of volunteers going through "Fair Use" NASA images to declare them PD, sent up to commons, only to have them deleted, and the uploader then has to re-upload them. --Marshallsumter (talk) 21:26, 26 October 2014 (UTC)[reply]
  • Oppose Oppose It seems like the only reasoning behind this is the possibility to create abuse filters containing information about OTRS permission membership. But how many wikis are in need of such filters? I guess in the best case perhaps 4 or 5 of our approx. 800 wikis will decide to make use of such filters, all of them being maintained by a big community. So why waste stewards' time to assign users to a meaningless group if such groups can also be locally implemented and maintained where needed (like also on Commons)? I believe the abuse filter argument is a pretty weak one and all the efforts needed to create a global group aren't worth it due to the very low re-usage. Regards, Vogone (talk) 21:41, 26 October 2014 (UTC)[reply]
To answer your question, the stewards I've spoken with have not been opposed to the idea - other than some being concerned about the initial granting if this were to pass. Anyhow, currently an OTRS admin will have to contact the crats of each wiki with filters (currently there are two - but this should grow, to ensure that the OTRS permissions tags are properly used). But yes, that is the only intended purpose for this group. It would be easier to contact one person (a Steward) to assign a right rather than contacting each and every wiki where such a right exists (currently 2 - but as I said, it would be sensible for other wikis to consider implementing similar filters if this were to pass). Rjd0060 (talk) 21:46, 26 October 2014 (UTC)[reply]
  • Support Support, "purge" is a cute hack. –Be..anyone (talk) 21:47, 26 October 2014 (UTC)[reply]
  • Support Support for sure. Vogone, it will also allow building Apps/Scripts to find OTRS members (aka Wikimedia Support Team) so if someone urgently needs one, they can find one who recently edited and speaks the language they prefer. This is just one example how it could be useful. Unified appearance across projects is another not to be underestimated advantage. -- Rillke (talk) 22:07, 26 October 2014 (UTC)[reply]
    And such Apps/Scripts cannot rely on local Commons group membership information? Vogone (talk) 22:19, 26 October 2014 (UTC)[reply]
    Of course. But other projects will assign probably different names and then the script is not portable and the mess begins again. It's already shit when you just import wiki markup from German Wikipedia to Commons and files are not included because they use the localized inclusion form (Datei:). And when visiting German Wikipedia, I want to know whether someone has OTRS access without querying all local wikis that make use of this right (which would be another list to be maintained). OTRS membership is a global property so it should be a global user group. -- Rillke (talk) 21:08, 5 November 2014 (UTC)[reply]
  • Support Support Very good idea.--►Cekli829 06:31, 27 October 2014 (UTC)[reply]
  • Support Support Nice! --► Ricknator (talk) 07:12, 27 October 2014 (UTC)[reply]
  • Support Support --Kolega2357 (talk) 08:54, 27 October 2014 (UTC)[reply]
  • Support Support Most useful. Asav (talk) 09:22, 27 October 2014 (UTC)[reply]
  • OpposeNeutral Neutral I would only be okay with proliferation of cross-project groups like this if the software were set up to allow local communities to override permissions granted to individuals of such groups. Unless local communities have the ability to remove particular privileges globally granted to such users, the only way a local community could prevent the exercise of such rights would be to block the user account, which is a ridiculously blunt instrument to force the local community to wield in order to achieve what should be a surgical result. --Pi zero (talk) 13:49, 27 October 2014 (UTC)[reply]
    On a technical note, this user group won't add any additional rights to users; the only purpose of it is to identify OTRS agents that volunteer in specific queues. The group will contain some right already available to everyone (read, most likely). I sent out the mass message yesterday which erroneously said that it would include the autopatrol right - that isn't the case. I mistakenly thought that was still part of the proposal, but I edited as many messages as I could to remove it. This proposal is also opt-in, not that it really matters for a group with no associated rights. Ajraddatz (talk) 16:37, 27 October 2014 (UTC)[reply]
    I'm aware that, technically, this doesn't have additional rights attached yet. Once the group exists, it's a temptation, an attractive nuisance for such things. It should be built into the structure of the software that local communities are naturally able to override such rights locally on an individual basis; and, seems to me, as long as it isn't, making such cross-project groups more common is a problem.
    It's sad to watch as local control of local projects is systematically worn away, one small, individually "harmeless"-seeming decision at a time. --Pi zero (talk) 17:05, 27 October 2014 (UTC)[reply]
    Hello, Pi zero. I'll reply to all of you (including Sargoth and Rochefoucauld who appear to have the same concerns) here: I'm sorry that you appear to believe this is all one big conspiracy (to take over the wikis?) - but there really are no ulterior motives here. You're free to worry about anything you'd like, of course. As much as I'm free to clarify people spewing misconceptions and/or misinformation all over the place. So I'll clearly state for a final time (hopefully): As I stated in the proposal, the group is intended solely for identification purposes. Your concerns are unfounded - both because you're the only ones talking about the problem (which does not exist) and because any changes to the group (even though there won't be) would need community approval just as the creation would. Thanks all for your comments. Rjd0060 (talk) 22:03, 27 October 2014 (UTC)[reply]
    Rjd0060, I obviously can't speak for others, but for my part, I'm not talking about a "conspiracy" in the canonical sense. It isn't necessary for a nefarious cabal to plan these things (which is usually difficult to pull off at scale anyway :-). I'm talking about trends and statistical likelihoods (reread my comments above; no conspiracies involved). Statiscially, things that increase local control don't get done, nor do things that are likely to encourage trends toward greater local control in the future; while things do get done that decrease local control, or that are likely to encourage trends toward lesser local control in the future. Things like that are most effective when the cause is systemic — when there isn't a conspiracy in the conventional sense — because you can't fix the problem just by exposing Dr. Evil's plot. --Pi zero (talk) 00:14, 28 October 2014 (UTC)[reply]
    @Pi zero: The software is set up to do exactly as you ask. It is called "sets" and the proposal as forward would produce a set (functionally to which all public wikis will be added) and a global group right that is applied to this set. Wikis that wish to be excluded from a set such as this would be asked to demonstrate a local consensus, where demonstrated then a steward would make the requisite change. If you are concerned about an individual, and you are looking to utilise the message edit filters, then you can exclude individuals if you so choose.

    If we follow your logic about creating groups then nothing would ever change with regard to rights, and there would be a disconnect between the development of the wiki and the ability to do things. Incremental changes made with full and open consideration and approval of the broader community allows for the right changes, in the right time frame. That an RFC is put to the community for a change that has no permissions impact and yet allows communities to do things is a good sign of positive thinking by the OTRS team. If communities choose not to utilise something, that is quite okay too, the choice is theirs.  — billinghurst sDrewth 04:32, 28 October 2014 (UTC)[reply]

    From this I conclude mainly that I'm not explaining myself well. However, in this case I think if I don't know my way around the specifics well enough to explain myself, then I oughtn't be outright opposing the proposal; so I'll just be neutral. I should know by now, it's not possible to get deeply involved in everything I care about. --Pi zero (talk) 11:40, 28 October 2014 (UTC)[reply]
  • Support Support. Multichill (talk) 19:12, 27 October 2014 (UTC)[reply]
  • Support Support. Stephan Kulla (talk) 19:59, 27 October 2014 (UTC)[reply]
  • Support Support Legoktm (talk) 22:03, 27 October 2014 (UTC)[reply]
  • Neutral Neutral. I am not convinced that we need a global effort for now as we only have two projects that could use it and have already provided solution locally for any issue related. We are just arguing on a possibility of others wanting to use the filter on future, having in mind that only a few projects use files locally. Not many reasons to oppose though.—Teles «Talk to me ˱C L @ S˲» 23:32, 27 October 2014 (UTC)[reply]
  • Support Support - JetzzDG (talk) 04:17, 28 October 2014 (UTC)[reply]
  • Oppose Oppose - this is not as useful as can sound, and per Marshallsumter and Vogone comments. --Zerabat (discusión) 12:37, 28 October 2014 (UTC)[reply]
  • Support Support Ziko (talk) 23:51, 28 October 2014 (UTC)[reply]
  • Oppose Oppose per Vogone. There are only a few wikis using an abusefilter for this purpose, so having a global group for this seems like overkill. --Glaisher (talk) 05:11, 30 October 2014 (UTC)[reply]
  • Support Support --Roberto Segnali all'Indiano 17:21, 1 November 2014 (UTC)[reply]
  • Neutral Neutral, basicly it would only be more a formal change than anything concrete (it was correctly recalled that local wikis already have their tags, when the tags will be updated nothing of notable will have been added). Rather, I'm not convinced that the inclusion into the global group should be mandatory for all OTRS guys: many of them actually don't connect their wiki account with their OTRS work, and even if this is true mostly for our... "diplomats", I believe that all OTRS operators should be let free to decide on their own whether to request these rights or not. Either way, however they move they still should trigger one of the filters, local patrollers would find them just the same. I'm not against it, but it's a very little gain, imho --g (talk) 02:46, 3 November 2014 (UTC)[reply]
    The proposal is only for the creation of a group and the qualifications for population of the group, whether it is mandated surely would be with OTRS and would be an OTRS discussion, I am not sure that they are making it compulsory, and surely opt out is possible. Further to the numerous local creations and notifications, and "no advantages", the purpose is to not require so many local creations, and instead have one streamlined process, and the advantages for the smaller and sister wikis will indeed be present (centralised, and opportunity for global filters), though whether it will be for wiki which you represent ... <shrug>.  — billinghurst sDrewth 03:46, 3 November 2014 (UTC)[reply]
    It's written in the last line of the above section that it should be mandatory; I understand that in the end it will be a OTRS discussion, but since the argument has been introduced here... :-) --g (talk) 08:09, 3 November 2014 (UTC)[reply]
    Good point, the additional notes are OTRS's not those that apply for the overarching creation of the right (my opinion), and as said, "notes". @Rjd0060: I would hope that OTRS were not made mandatory, simply recommended.  — billinghurst sDrewth 09:52, 3 November 2014 (UTC)[reply]
  • Support Support per billinghurst. Restu20 10:21, 3 November 2014 (UTC)[reply]
  • Support Support While I understand some of the concerns above I believe I have given my two cents at the location of those comments. I still strongly believe the benefits outweigh the cons here and do support the proposal (which I created). Rjd0060 (talk) 11:02, 3 November 2014 (UTC)[reply]
  • Oppose Oppose - What permissions/rights would it have? apart from being a global group and until that is clarified, I don't really see the need to create another 'useless' group..--Stemoc 11:51, 3 November 2014 (UTC)[reply]
    @Stemoc: it says very clearly, it has no rights, it is a label as used at Commons, but to be made available globally.  — billinghurst sDrewth 12:00, 3 November 2014 (UTC)[reply]
    • I'm aware, but again, why have a global group without permissions in the first place; as mentioned by Vogone, it is quite redundant or as Glaisher puts it, an overkill....--Stemoc 12:10, 3 November 2014 (UTC)[reply]
      • It is certainly not. Why do some people wear badges? Not because it gives them more permission; instead it helps people who see them to identify them as what they intend to. -- Rillke (talk) 21:15, 5 November 2014 (UTC)[reply]
  • Oppose Oppose per above --Zhuyifei1999 (talk) 05:47, 4 November 2014 (UTC)[reply]
  • Support Support for better identification.--J.Wong 12:55, 4 November 2014 (UTC)[reply]
  • Support Support The rationale for this seems clear enough. Emufarmers (talk) 01:18, 5 November 2014 (UTC)[reply]
  • Support Support--Alexmar983 (talk) 00:22, 6 November 2014 (UTC)[reply]

Closing statement edit

This RfC is officially closed. There is consensus that this user group be created; as such, I have created the global group with the 'read' permission. Membership will consist of users assigned to the permissions queue; however, relevant user accounts should not be added to the group until an efficient method of doing so has been explored (i.e. not just stewards manually flipping it on for an undetermined number of people). Since the global group contains no additional rights, it will not be opt-out, since that technical function would do nothing in this case. In the mean time, it would be of great help if a complete list of users who need access could be compiled. Thanks to all who contributed to the discussion. Ajraddatz (talk) 07:22, 7 November 2014 (UTC)[reply]

Thank you, Ajraddatz. We will work out the specifics and contact the stewards when we're ready. I'm told by legoktm that this can be done automagically via API - and he's willing to write a script for the steward willing to implement the initial granting, once we're ready. Thanks all and we'll be in touch (likely via email to stewards@). Rjd0060 (talk) 22:19, 7 November 2014 (UTC)[reply]