Commons:Village pump/Proposals/Archive/2017/04

Defaulting to gender neutral language in policies and help pages

Contributors here may be interested that a proposal for a policy on gender neutral language to become a default for Wikipedia policies, help and guidelines is open for votes at Commons:Village pump#Defaulting to gender neutral language in policies and help pages. The proposed policy is strictly limited in scope and so excludes any other pages, talk pages or any discussion by individual contributors. Thanks --Fæ (talk) 14:36, 10 April 2017 (UTC)

Warning re-users

(second time I've brought this to a new forum)

can we please get something done about this (that is, this). Yes, even on the template that marks it as having been reviewed by the legacy bot. DS (talk) 20:50, 10 April 2017 (UTC)

To be honest, i see no need. --Steinsplitter (talk) 11:05, 13 April 2017 (UTC)

A proposal to improve the wording in some templates and related guidelines for better communication

From my on experience as part of my activities to bring new content creators to Commons and to help them on how to complete the formalities, I came to know that many of our guidelines and templates are poorly written which cause avoidable discomfort and frustration. (One example; there are many.) From my participation on many recent discussions on COM:AN and COM:ANU, my understanding is that this is a longtime problem. Further, it causes to create many disputes between the content creators/uploaders and administrators/patrolers. I think this can be avoidable to some extend my improving the wordings. So I'm proposing a few changes that I noted already. Jee 04:51, 7 April 2017 (UTC)

No permission and no source tags

Currently Template:No permission since, Template:No source since, Template:No license since, (to make it clear "No license since" is not part of this proposal) and similar templates have only a predefined message which conveys nothing to the delivering end. What we really need a custom message that explains why the requesting volunteer thinks the file page requires further information that the uploader needs to provide. It can be many different reasons like 1. the requesting volunteer thinks the uploader is the subject in the media and the copyright holder may be different. In such cases, we need a permission from the copyright holder. Otherwise, the uploader needs to make reasonable arguments that it can be a selfie or had contributed enough to claim a co-authorship. 2. a source is provided to a website in the source field or as watermark and the requesting volunteer thinks the work is not of the uploader and needs a permission from the copyright holder. Otherwise, uploader needs to convince us that both the uploader and the copyright holder are same. We have account verification email format for this. 3. a license is provided for the photo but not for the artwork depicted. A permission from the artist is required. 4. there can be similar N cases and a predefined message is quite useless in all these cases. So I suggest to either 1. make a provision to include a custom message where the requesting volunteer can mention why s/he thinks further information is required. S/he must explain how it can be achieved in an easier manner. Such a provision somewhat exists in Template:Speedydelete. 2. or deprecate these templates and use normal deletion requests. Jee 04:51, 7 April 2017 (UTC) (modified to include the option to stop using of these templates too as suggested by some users.)

 Support This is a problem I have run into many, many times, and Jee's suggestion seems eminently sensible. Template:No permission since is particularly confusing as it usually means "Actually a permission is given, but I just don't believe it". A distinction that is far too subtle for most new unploaders without some sort of custom message explaining why. The ability to add custom messages would help not only to educate uploaders but would also significantly assist admins who are attempting to save for Commons images that are in actual fact OK. It would also dissuade admins from over-speedy use of the delete button. --MichaelMaggs (talk) 11:03, 7 April 2017 (UTC)

 Comment what about simply stopping the whole usage of Template:No permission since and Template:No source since? I think those tags hardly save time compared to a regular DR. I think we can avoid a lot of trouble if we just get rid of those two tags and always use regular DRs instead. For obvious copyvio, we still have {copyvio}. Template:No license since may be fine to keep, but this tag has the advantage that it is typically added within a few days after upload, when the uploader may still be around. Also the lack of a license is not open to interpretation and does not need an explanation by the tagger. Jcb (talk) 11:20, 7 April 2017 (UTC)

Natuur12 made such a suggestion here. I've no objections to it. Jee 12:46, 7 April 2017 (UTC)

Should we propose this at a place where more people will read it and will comment to it? For now, I will completely stop pasting those two tags. I cannot remember any situation where a regular DR would not work. Jcb (talk) 15:42, 7 April 2017 (UTC)

I added a notification on the talk pages of both tags. There are substitutions tags too (Template:Npd, Template:Nsd). Do we need to add notification there too? Jee 16:31, 7 April 2017 (UTC)

Could be a good idea. It will have quite some technical implications, so it would be good that many people are aware. Some gadgets will have to be modified if we decide to abandone these two processes. Jcb (talk) 16:40, 7 April 2017 (UTC)

Notification added on them too. Thanks. Jee 16:53, 7 April 2017 (UTC)

I would agree that 'no permission' and 'no source' are particularly problematic. The issue, really, is that they are (at least, in how they are actually used) open to interpretation in a lot of cases. Examples of what I mean are what MichaelMaggs said above, "Actually a permission is given, but I just don't believe it", or "a source, such as own work, was given, but I don't believe it". Using these templates, such files eventually get processed as speedies, but they are really not the kind of "most obvious cases" that are supposed to be handled via speedy deletion. They should instead go to DR. - Revent^talk 04:29, 9 April 2017 (UTC)

Thanks Revent. So we've at least five people agreed that these templates are problematic. The next question is, whether modifying this to include a custom message or deprecating them and to use normal deletion requests is the best option. The template offers the uploader to convert it to a DR; but I don't know whether it is effective as chances that a newbie user may make his contesting opinions on their talk page instead of using it. if no advantages, I think we may deprecate them. Jee 04:49, 9 April 2017 (UTC)

I am not good at technical kind of Wiki work enough but as there is the option to convert the template into a DR by clicking the button, could the template do it automatically? I mean it like when a user adds Template:Npd or Template:Nsd it would start a DR with predefined reasoning? --Mates (talk) 12:20, 9 April 2017 (UTC)

Thanks Mates. Yes; I think it is possible to code to auto-generate a DR using the pre-fixed wording and custom texts the user added. Jee 14:22, 9 April 2017 (UTC)

• The wording (sentence) in {{No permission since}} is fine IMO : "This media file is missing evidence of permission. It may have an author and a source, but there is no proof that the author agreed to license the file under the given license. Please provide evidence of permission by either providing a link to a site with an explicit release under a free license or by sending a declaration of consent to permissions-commons@wikimedia.org. Unless this issue is resolved, the file will be deleted seven days after this tag was added and the uploader was notified".
  I find that is quite clear. Maybe the visual can be modified a little bit better and the text improved. But I'm not sure the text will be more understandable with regular DR, you will find sometimes simply "no permission" or even "the link is not good" for the rationale and I wonder how it will be more understandable for the new uploaders than the template, furthermore the use of templates allow possible translations, with DRs you lost that. If there is modification, I think the templates have to be modified but not the principle of the templates. Christian Ferrer ^(talk) 13:39, 9 April 2017 (UTC)

I'm not a regular to these maintenance categories, and I just take a look in Category:Media missing permission as of 5 April 2017, I don't see why the template is not adapted for such images, and why it should have a DR instead, and why the DR will be more understandable for the uploader. It could even be speedy deleted now from my point of view, because copyvio it is, and you will not have a better source with a regular DR. Then we are already very kind to notify the uploader and to let them 7 days... However, I'm not sure to understand why this one, an "own work", was tagged with "no permission" by Ytoyoda, is it because there is no EXIFs?. Christian Ferrer ^(talk) 14:04, 9 April 2017 (UTC)

That's said it's true that, in case the uploader want to ask/say something, there is near no chance that the new uploader can fully understand the button "convert to DR" from {{X-To-DR}} and/or what this means. Christian Ferrer ^(talk) 14:20, 9 April 2017 (UTC)

Thanks Christian Ferrer. 1. I didn't question the meaning of the existing text. Instead, what I demanded (in first paragraph) is, we need a "custom text explains the current issue in this particular file" in addition to the generic text. 2. Files having these templates can't be speedyed; they need to stay for 7 days just like a normal deletion request. 3. Your example is self explaining. Files are mostly tagged not because a source is missing; but the requesting user think it is not trustable. But there is no provision in those template to explain why s/he can't trust the uploader. 4. Yes; "convert to DR" is too technical. Something like "click here and add your explanation if you have any" may be better. Or an auto generated DR as Mates commented above. Jee 14:32, 9 April 2017 (UTC)

@Jkadavoor: yes I mainly agree except for "Files having these templates can't be speedyed", this one is tagged with no permission but it have to be speedyed. Exemple, if I find this image without the "no permission" tag in the "uploads by new users" where it currently is, I will speedy delete it because it is obviously a screenshot, but because it has a "no permission" tag, it will become protected for 7 days? I tend to disagree, and I sometimes speedy close regular DRs too, for obvious copyvios. Christian Ferrer ^(talk) 14:45, 9 April 2017 (UTC)

Yes; any files, even in a deletion request can be speedyed if it meets COM:CSD. What I meant was a "no permission" or "no source" tag expects a fix from the uploader or others within seven days and so those tags themselves are not a reason for speedy. To prevent a speedy, the uploder need to use Template:OTRS pending which also needs a fix. See my proposal below. Jee 16:40, 9 April 2017 (UTC)

• I changed the text in {{X-To-DR}}, feel free for administrators to revert if it is not good. Christian Ferrer ^(talk) 15:12, 9 April 2017 (UTC)

I think it is possible to amend {{No permission since}} and {{No permission since/layout}} for it have {{lang|{{{lang|}}}|{{{reason}}}}} a "reason" field as for the {{Copyvio/layout}} and then to modify the MediaWiki:VisualFileChange.js at the relevant areas:

'np': { tag: "{{subst:npd|1=%REASON%}}\n", summary: "Missing [[COM:PERMISSION|permission]]." }, instead of 'np': { tag: "{{subst:npd}}\n", summary: "Missing [[COM:PERMISSION|permission]]." },

and

'np': { minLenReq: 11, reasonText: 'mdInsertDeleteReasen', reasonParse: 'mdDelteConfirmation', bLimit: 140 }, instead of 'np': { minLenReq: 0, bLimit: 140 }, of course the size of the reason field is arbitrary and can be longer

and

'np': { cleanReason: true, tasks: ['mdPrependTemplate', 'mdNotifyUploaders', 'listMobileUploadSpeedy'], userGroups: ['user'] }, instead of 'np': { tasks: ['mdPrependTemplate', 'mdNotifyUploaders', 'listMobileUploadSpeedy'], userGroups: ['user'] },

I think that if it is carefully done, then this may require the user to put forward an additional visible reason in the tag on the file as for the copyvios tag. Christian Ferrer ^(talk) 16:44, 9 April 2017 (UTC)

Good suggestion. Let us wait for more opinions as this should be done professionally. Also, if we are planning to keep these templates without replacing with DRs, we need to improve the warnings on talk pages too. Currently it is not clear that the uploader needs to make his arguments in the file page; not on the user talk page. I doubt any admin will check the user talk pages before a deletion. Jee 16:56, 9 April 2017 (UTC)

•  Oppose, the templaters are doing it wrong: Template:No permission since should ONLY be used when the file is missing evidence of permission, that is, no Author field; Template:No source since, should ONLY be used when the file is missing essential source information, that is, no source field; and Template:No license since should ONLY be used when the file does not have sufficient information on its copyright status, that is, no License field or down below. Not believing the Author, Source, or License should lead to a DR.   — Jeff G. ツ 04:56, 10 April 2017 (UTC)

• Thanks Jeff. From your words, it seems you support the proposal "in spirit". :) Jee 05:13, 10 April 2017 (UTC)

@Jkadavoor: I don't think it's necessary. Templaters who do it wrong should be admonished. Uploaders who provide provably wrong info should be met with a freeform speedy, those who provide gray area info should be met with a freeform DR, and those have provably emailed OTRS correctly should be met with {{subst:op}}. Granted, those three templates need documentation with clear examples, but it shouldn't be that hard to figure out. Templaters can follow up with a note, if they want.   — Jeff G. ツ 05:46, 10 April 2017 (UTC)

I pretty much agree with Jeff G. here, though I think it is also acceptable to use 'no permission' in cases where the uploader specifically says they are not the author, but it's reasonable to assume (for instance, they say they obtained the image via email) that such permission actually was given.... basically, as a prompt to submit the needed OTRS ticket.

I very, very strongly believe, however, that in any case where the required information is given (even if in the wrong place, or in the history) and the question is simply if we believe it that the file should go to DR. - Revent^talk 07:05, 10 April 2017 (UTC)

And see Update on Commons:Email templates and Grin's comment there. This is a common problem we're facing when we try to bring a new established photographer here. The user name s/he created may be a pseudonym and even without a user page. Most new users don't know how to create a user page.) The patrollers will find the images in web and tag them with "no source" or "no permission". The user wonder and continue his uploads. They will be threatened and blocked. they will never come back and accuse the helping volunteers like us too for exposing them to shame. Jee 08:55, 10 April 2017 (UTC)

If the file is marked as own work, then it technically has source and even permission, although it can be fake. I do not mark such files as missing source or permission. What do you think about making impossible adding no source or no permission templates using gadgets to files having own work template? Adding them manually will still remain possible, but in my opinion these templates are added mostly using gadgets. Taivo (talk) 10:16, 10 April 2017 (UTC)

Taivo, here it was added using COM:VFC. Does this can be prevented? Jee 11:53, 10 April 2017 (UTC)

I think, that modifying VFC this is possible. Taivo (talk) 12:03, 10 April 2017 (UTC)

Thanks Taivo, then it can be consider as another option and to deprecate the "no permission" template as "no source" will be enough for all purposes. Jee 13:41, 10 April 2017 (UTC)

Most responses seem to go in the direction of disabling or discouraging the usage of the two tags. I will investigate in the coming hours which users paste the tag the most and ask their attention to this discussion. Jcb (talk) 14:39, 10 April 2017 (UTC)

A quick look at a few day-cats tells that the following users may be interested in this discussion: @~AntanO4task: @Ronhjones: @Ytoyoda: @НоуФрост: @Racconish: @Thibaut120094: @EugeneZelenko: @XXN: @LX: @Shev123: @Secondarywaltz: - Jcb (talk) 15:42, 10 April 2017 (UTC)

I do not know English so well to participate in the discussion. It's very sad if there is a text field in the template, and not for example "select the reason", again because of poor knowledge of the language ... It would be great to develop a list of "standard reason" and select the desired message. If changes are accepted, will the gadget be fixed? - MediaWiki talk:Gadget-QuickDelete.js? --НоуФрост (talk) 18:08, 10 April 2017 (UTC)

A good idea will be to call a colleague @Sealle: - he has a great practical experience. ‎--НоуФрост (talk) 18:12, 10 April 2017 (UTC)

I'm not sure where to jump in, it's not clear to me what exactly is being proposed or why, but since I got pinged, I suppose I should comment. If I understand correctly, under the heading "improve the wording in some templates", we have a rather vague proposal to delete problem tags that have been around since the creation of Commons. No plans for which policies need to be rewritten or which gadgets to update. Just delete them and replace them with something terrific, I guess. In this case, something terrific seems to be that someone uploading unsourced content will be met not by a message in their own language informing them of what information they need to provide, but by a notification about possible deletion, where they have to respond to a message in whichever language the nominator chose. I'm sorry, but this proposal isn't thought through or developed enough to merit further discussion. I'd advise picking one problem tag at a time, analysing how it gets used, identifying what works and what doesn't, identifying changes needed to improve the situation as well as side effects that the proposed approach would have. —LX (talk, contribs) 14:51, 15 April 2017 (UTC)

LX, we are discussing only templates here; Template:No permission since and Template:No source since. And the proposal is either 1. make a provision to include a custom message where the requesting volunteer can mention why s/he thinks further information is required. Or 2. deprecate these templates. Does it vague? Jee 07:33, 16 April 2017 (UTC)

I think discussing one template and one proposal at a time rather than multiple templates and multiple proposals for each would have made things clearer. As for custom messages, it's not clear whether the proposal is to make them optional or mandatory. As for deprecation, it's not clear what the proposed plan is. And in general, it's not clear what cost/benefit analysis has been done. —LX (talk, contribs) 07:48, 16 April 2017 (UTC)

LX, I fully agree with you. In fact, I started this only as a discussion (see general discussion at bottom) to get some feedback and later progressed this way. Do you think this can be split now? Jee 07:58, 16 April 2017 (UTC)

To be brutally honest, I have a hard time seeing anything really useful coming out of the current discussion. I think the best thing to do would be to do the suggested analysis work before making proposals with some more structure to them. —LX (talk, contribs) 08:11, 16 April 2017 (UTC)

The issue is not the templates themselves, but the way they are used, and the way the tagged images are deleted. It is OK to use these templates when there may be a chance that a permission is coming. If the files are just copied from social networks, they should actually be tagged as copyright violation (with a reason why they are copyvios, which is currently missing in the copyvio template). That way, the uploaders may understand better what's the issue. Then, when deleting files, it is necessary to check that 1. the templates were used appropriately (if not, create a DR), 2. that the permission/source/license are still missing, or if the issue was fixed. It is also important that the uploader is informed, so that s/he has an opportunity to fix the problem. I often move speedy tags into regular DRs just because the uploader was not informed. Regards, Yann (talk) 15:17, 10 April 2017 (UTC)

If it can help : I tag as copyvio only if the uploader claims it is own work while there is an obvious proof this is not true and in such case I include the proof, unless it is a very obvious case such as a cover or a poster ; I tag as no permission when the work is attributed to a party different from the uploader without that party's permission. I seldom use no source templates. I don't mind changing if it can help (and if it does not become too cumbersome). — Racconish^☎ 15:52, 10 April 2017 (UTC)

Racconish, see #Update_on_Commons:Email_templates. The uploader can be original copyright holder just created an account to upload those files on the request of a Wikimedian. In fact, our COM:OTRS page demands the copyright holder to create an account and upload themselves whenever possible. Then we threaten the copyright holder and even block them which is unfortunate. Jee 16:22, 10 April 2017 (UTC)

I understand what you mean. But isn't the template precisely dong that, asking the uploader to send the permission? A good faith uploader would then contact me, asking for help and I would try to help him out. — Racconish^☎ 16:30, 10 April 2017 (UTC)

A newbie will not understand anything; thanks to the complexity of our development tools. Fortunately some of them contact us through Facebook. We recently opened some groups for providing help. Jee 16:37, 10 April 2017 (UTC)

@Yann: You are mistaken about {{Copyvio}} not having a field for the reason... it does, it's 'no source/license/permission' that don't.

@Revent: Yes, there is a reason, but it is not shown to the uploader's talk page. Sorry if I was not clear. Regards, Yann (talk) 09:15, 12 April 2017 (UTC)

@Yann: We should add a field for the reason to {{subst:copyvionote}}, and update {{Copyvio}} accordingly. This will not only better inform the uploader, but also future visitors to the uploader's user talk page once the file has been deleted.   — Jeff G. ツ 03:53, 13 April 2017 (UTC)

@Jkadavoor: One thing that I unfortunately see way to often, that we still need the flexibility to deal with, is the cases of new users who rapidly upload a number of copyvios from multiple sources with obviously false 'own work' claims simply because that's the path of least resistance to what they want, which is to stick an image in an article. There are times when it's quite obvious that no permission if going to be forthcoming, simply because it's someone that has the 'everything on the net is free' mindset that people apply to Facebook. I'm not, of course, saying we should immediately block such people, but there is a point where 'own work' claims are just obviously wrong, usually because the uploader can't possible be multiple people. I do agree with Racconish, however, that if I a going to speedy something as an 'obvious copyvio' I will always tag it first, usually with a link to the original source (or a statement like 'dozens of TinEye hits that long predate the upload here'), and then delete it using the 'trash can' (which prefills that rationale into the deletion log). About the only time I delete something with the 'default' log entry is when it's 'per whatever DR', and I think that should be standard practice. - Revent^talk 04:17, 12 April 2017 (UTC)

Yes Revent, I'm aware that some people try to misuse our system by uploading files from various sources claiming "own work". The difficulty for us is, how we will distinguish them from genuine established photographers/copyright holders just happened to create a new users account here. For that purpose I wish to encourage the use of Template:Verified account and a separate "email format" to confirm that permission. Unfortunately OTRS seems not matured enough or don't have enough resource to handle it (from Krd's words). This leads to a problem as our current guideline advise the copyright holder to upload the file whenever possible. The copyright holder who follow this advice will create an account which will ended up a non-verified account and prone to get blocked. See my discussions with FDMS4 here and here. Jee 04:39, 12 April 2017 (UTC)

If I remember rightly, the original purpose of Template:No permission since, Template:No source since and Template:No license since was to tag files that have no permission, no source, or no licence at all. They were never intended to be used where these things are present but are incorrect or fake. I'd like to see these or similar templates restricted to situations where mandatory data is actually missing. Where something mandatory is missing, it should be relatively straightforward for admins to use a tool to delete such files after 7 days without the need for custom messages or very much research. Even a bot could do that.

Where data is present but is arguably incorrect or fake, the file should either be tagged in a different way (with a custom reason given, as Jee suggests), or sent straight to DR. At present, going straight to DR might be simplest, but as we quite frequently have very large DR backlogs I do think it would be worth providing some different tags that would allow deletion after seven days in the common situation of an obviously wrong source or licence. There are a lot of these, and I don't think we want to be increasing the overhead by sending them all to DR.

Perhaps we could introduce new 7-day tags such as Template:Permission queried since, Template:Source queried since and Template:License queried since, in each case requiring a custom reason and a clear automated notification to the uploader. These tags would be specifically for use on recently uploaded files (say a less than one month old), with older files having to go to a full DR. The major tools used for tagging should enforce this; manual tagging can't easily be stopped, but manual mistaking is unlikely to happen often enough to be a real problem. --MichaelMaggs (talk) 17:41, 10 April 2017 (UTC)

I think it would be a bad idea to add even new deletion processes. Currently, unlike in the old days, the delreqhandler helps us handling DRs quite fast. Simple DRs with obvious reasons get closed almost always within 8 days. The taggings do no longer play a significant role in keeping our backlogs within reasonable limits. I thing a tag like 'Permission queried since' with a custom reason has no added value compared to a regular DR. Jcb (talk) 19:41, 10 April 2017 (UTC)

I disagree, for two reasons:

1. there may not be much of a DR backlog at present, but that is historically unusual even in the era of delreqhandler. Backlogs depend hugely on the availability of a few highly active admins, and we absolutely must not assume that that will continue. DRs require significant input, both from admins and from the wider community, and we should avoid overloading them with large numbers of ‘obvious’ cases;
2. as Jee has correctly pointed out, it is important that we keep in mind the uploaders’ perspective. To a new user, sending a file to DR is quite an aggressive act (‘your upload is so bad that the community has been asked to delete it’), whereas a query tag with custom or selectable text can be much friendlier (‘we would like to help you to correct a problem with one of your uploads, and here's what you need to do ’). The difference in the message is of crucial importance. --MichaelMaggs (talk) 03:46, 11 April 2017 (UTC)

@MichaelMaggs: I thought I remembered similarly. However, I went back to the beginning of Template:No permission. It has always been about proof of permission, rather than existence of an Author field. An author could just be assumed as the uploader, but proof of permission is a sticky wicket. Proof of no permission (copyright assertion with no free license on the source webpage is easily tagged {{Copyvio}}) is one thing. Indicators of potential problems include: mismatched names of authors in info section, EXIF, source website, and watermark; low resolution; lack of EXIF; mismatched dates; higher resolution available elsewhere; prior uploads elsewhere; and uploader track record. Any one of those can contribute to the tagger's suspicion about the proof of permission on a file. For this particular tag, why not add a freeform field so that the uploader and reviewing admin have a clue about the tagger's reasoning? "Please email proof of permission via OTRS" could go a long way.   — Jeff G. ツ 05:04, 12 April 2017 (UTC)

Jeff, it is exactly the initial proposal ("1. make a provision to include a custom message") which MichaelMaggs supports and you oppose. Jee 05:10, 12 April 2017 (UTC)

@Jkadavoor: I only  Support for Template:No permission since because it is so sticky and the other two are binary (has or doesn't have source, has or doesn't have license). See the strikeouts I did above.   — Jeff G. ツ 05:42, 12 April 2017 (UTC)

Jeff: So you support adding such a provision for Template:No permission since? Could you make it clear in that comment you voted? BTW, I didn't meant to discuss "no license" template here. I strike-off that part in above for a better clarity. Jee 05:50, 12 April 2017 (UTC)

@Jkadavoor:  Done two paragraphs above.   — Jeff G. ツ 06:09, 12 April 2017 (UTC)

•  Oppose. The major problem is people who abuse the tags, e.g. tagging {{Own}} images with {{Nsd}} because they don't believe the claim, and then they throw a fit and try to make problems for the admin who rejects the tag because the image obviously has a source. If it were merely a timing thing, I'd perhaps agree with the proposal, but MichaelMaggs (and maybe Jee, but I've not read everything up above) has a good point about the new user's perceived difference between "We're getting rid of this" and "This will probably be removed, but you can stop that by providing important information". The solution is to ignore tag abusers the first time around and to sanction them if they persist in their disruption, not to let their abuse cause further problems. Nyttend (talk) 03:10, 12 April 2017 (UTC)

  Nyttend, you're right on Template:No source since (corrected) as it can't be used on files having a source. But the current wording of Template:No permission since explicitly allows to use it even when an author and a source is provided if the tagging user don't believe it. But that template has no provision to mention why the tagging user think so. Jee 03:23, 12 April 2017 (UTC)

  @Nyttend: Not to digress (you are right about misuse) but I think the drama that eventually led to this whole discussion was more caused by way too many cases of files with such tags actually being deleted when the problem was someone either not believing the claim, or not noticing that the information was hidden in the description field after a mangled transfer from another project. - Revent^talk 03:41, 12 April 2017 (UTC)

There are many, many uploads with obvious false claims of own authorship. It is unreasonable to file DRs, i.e. manually typing a reasoning, in all these cases. I propose a script is created for these cases. It would file a DR with a standard reasoning, e.g. The source and authorship claims provided is obviously incorrect or dubious. --Leyo 08:38, 13 April 2017 (UTC)

• Making stuff even moor complicated isn't helpful, thus is oppose this proposal. --Steinsplitter (talk) 15:44, 15 April 2017 (UTC)

  You aren't referring to my proposal, don't you? Otherwise, you wouldn't have made a bullet point I guess. If you did, I don't understand your point, I'm afraid. --Leyo 21:02, 15 April 2017 (UTC)

•  Comment This discussion show two things, firstly some persons thinks the tag is not enough didactic or/and not enough educational in the meaning it don't really help the uploader. Secondly that's shows that some of our (experienced) users uses this tag to tag images that have "ownwork" as source, but in the opinion of the user who put the tag, the image is obviously not an own work.
  Regarding the first part I don't see why one can have a reason to oppose a potential improvment of the wording/sentence in the templates in both the file page and the uploader talk page in the extend that the new wording/sentence don't change the meaning of the tag but will be a potential educational improvment for the new uploaders.
  Regarding the second part, that is more complicated, as we should not make our users feel guilty to hunt about potential copyright violations, but in another way I don't see what is the issue to make a DR each time the image is an "own work". In both situations DR vs "no permission", the image stay here at least 7 days, in both situations the images have to be opened and to be checked by an administrator, the only difference is that the administrator, in case of a DR, have to click one more time to close the DR.
  Here is an "own work" tagged with "no permission", though the image is uploded with "own work", the uploader is on the photo and can't be the photographer, and the current wording of the NP template is fine in a certan way "This media file is missing evidence of permission. It may have an author and a source, but there is no proof that the author agreed to license the file under the given license." That currently may describes well the case of this photo.
  So I guess that one of the issues of the discussion here is about if we continue or not to keep this kind of "freedom"/ease allowed by a wording a little fuzzy and subject to interpretation in the templates, to the administrators to decide whether the image deserves to be deleted or not. That lead us to a question what is the first purpose of the template? to really have a permission (a valid free linked source) or to be a way/tool used by some persons to highlight potential copyvios. Or maybe these both purposes?
  Another exemple on how we approach things differently, this file was tagged by Revent, me when I find such a complex logo, I tag it with a copyvio tag and I delete it just after to have done that...why? because there is less than 1/10000 chance that we have a permission for this image, that's all, and in this way we avoid a double check for an obvious copyvio. Christian Ferrer ^(talk) 22:49, 15 April 2017 (UTC)

Christian, 1. it seems there is no objections for adding a provision to provide custom reasoning in Template:No permission since. We may wait for more opinions for a few more days though. 2. For Template:No source since, some people think that tag need not be changed; only restricting its use to where the "source" is really missing is enough. But some other people think that tag need to be allowed to use in cases where the mentioned source is disputed. So we need a consensus on how to settle on the use of this template. 3. For this file, "the uploader is on the photo and can't be the photographer" may not be true. We need to clarify whether it is a selfie or not. For that purpose the tagging user need to make this argument in a DR or in the modified Template:No permission since having a provision for that. Otherwise we are dismissing the right of the uploader to make his defense. He is not even getting a clue why it was tagged. 4. I agree with you on this; the source and author has no connection to the uploader as that user had already uploaded from various sources. So we only need to check the Commons:Threshold of originality claim. Jee 04:45, 16 April 2017 (UTC)

It seems what's actually being proposed is changing a few times a day here, so please don't be too quick to declare consensus. When you say "adding a provision to provide custom reason", do you mean adding the possibility or requirement? That's not clear, and it makes a huge difference. When it comes to {{no source since}}, it's not as binary as some make it out to be. In addition to the source field being completely blank (which is unusual in the day of the Upload Wizard) and a variety of reasons to doubt {{own}} claims, there are also files with no verifiable source (e.g. files sourced to "google", "Bob" or "asdasdasdflkj"). As I said above, trying to discuss multiple tags at once and not doing enough analysis before proposing changes, I think, one of the reasons this discussion turned out so messy. —LX (talk, contribs) 07:32, 16 April 2017 (UTC)

It must be a "required" field as in Template:Speedydelete. Jee 07:38, 16 April 2017 (UTC)

Why can't the uploader be the photographer in File:Noha al yousef personal photo.jpg? Maybe it's probably not, but every modern camera has a timer and that shot could easily have been set up and taken by the person in the photograph. And the tag says "It may have an author and a source, but there is no proof that the author agreed to license the file under the given license." when you're actually saying "I don't believe the author is who it says it is." That's not at all helpful to an uploader.--Prosfilaes (talk) 07:22, 16 April 2017 (UTC)

I agree with that, this tag is used by several experimented users for "own work" images. The best exemple stay the one I provided above. File:Puko.jpg (size 960 × 640 without EXIFs) was uploaded by Suchy2316 with "own work" (this was the first and only upload from this user, therefore nobody could think at about a bad upload history), the image was tagged by Ytoyoda with "no permission" and then deleted by Yann with the log "Copyright violation, see Commons:Licensing". I precise that I searched, before the deletion, in the web and did not find any result for this image with google-search image. Though I don't claim the image to be restored, a DR with this rationale : "Small size without EXIFs, unlikely to be own work", could have been more appropriate. Christian Ferrer ^(talk) 07:49, 16 April 2017 (UTC)

This show that the "no permission" tag was here used to highlight a possible or a likely copyright violation, and then when checked by an administrator, because it have a tag, the image is speedy deleted with another log entry. Christian Ferrer ^(talk) 08:09, 16 April 2017 (UTC)

Yes, to me this falls in the likely copyright violation: small professional style image without EXIF, and the sole contribution if this user. I would welcome a better feed back to the uploader, but in this case (no answer), it won't change the result. Regards, Yann (talk) 08:16, 16 April 2017 (UTC)

I'm perfectly fine with the deletion of such images which fits perfectly within our precautionary principle, however the log entry is not good, or at least not accurate. This is not a copyvio, it is a "likely copyright violation: small professional style image without EXIF". In both case I agree the the image may be deleted, but it is not at all the same thing. Christian Ferrer ^(talk) 08:34, 16 April 2017 (UTC)

An attempt to exemplify the phrasing improvment in the {{No permission since}}
{| cellpadding=6 style="margin:0.5em auto; width:80%; background-color:#FFFFF8; border:2px solid #FF0000; padding:5px; clear:both; direction: ltr" class="layouttemplate"
	Thank you for uploading this file. However this media file is missing evidence of permission. It may have an author and a source, but there is a significant doubt that the author agreed to license the file under the given license, for one or more of the following reasons: The author does not match with the uploader username If you, as uploader, you are also the author then write your username in the author field and {{Own}} in the source field If you are not the author then ask the author to send a declaration of consent to permissions-commons@wikimedia.org. The source is {{Own}}. However one or more criteria make us think this media may not be an own work. These criteria can be a small size, no EXIFs, professional style image, metadatas showing a different author/copyright holder name than the uploader Please upload a higher-resolution file that includes the EXIFs In order to prove the name in the metadatas match with your real name, please send a declaration of consent to permissions-commons@wikimedia.org The source is a direct link to an image not a link and not an {{Own}} work Please provide a link to a site with an explicit release under a free license . The source is a link to a site without an explicit release under a free license Please provide evidence of permission by either providing a link to a site with an explicit release under a free license or by sending a declaration of consent to permissions-commons@wikimedia.org If you have fixed one of these problems, if you have any explanation, or that you think the use of this template {{No permission since}} is not justified on this media please click on the button Convert to DR just below this template and write your reason or your explanation. Unless this issue is resolved, the file will be deleted seven days after this tag was added and the uploader was notified (2024). Administrators: Check the history to ensure that information has not been removed through vandalism Check the usage of this file in other Wikimedia projects This page was last edited by JarektBot (talk | contribs | logs) Usage of this tag: For categorisation purposes, always use {{subst:npd}}. If you didn't use an automated tool, use {{subst:image permission|File:Village pump/Proposals/Archive/2017/04}} ~~~~ to notify the uploader.

Christian Ferrer ^(talk) 11:32, 16 April 2017 (UTC) |}

Adding provision for ticket number in Template:OTRS pending

Currently it is advised to "upload the image to Commons and place the tag {{subst:OP}} ("OTRS Pending") on the file description page in addition to the license chosen by the copyright holder" even before "asking the author to forward the email with their clear statement of permission to permissions-commonswikimedia.org". This is contradicting to what is written on the template: "An email containing details of the permission for this file has been sent in accordance with Commons:OTRS." It was written far before OTRS implemented auto response system with a ticket number. The file will get deleted within 30 days as OTRS has a backlog above 50 days. This will create unwanted frustration and conflicting between the copyright-holder, helping volunteer who do outreach to make this upload possible and admins who delete it. This can be easily avoidable by adding provision for ticket number in Template:OTRS pending. The admin who see the file on the 30th day as still not processed can check the ticket (if OTRS access) instead of straightaway deleting it. (I suggest more admins to apply for OTRS access.) Further, it is very difficult for an OTRS volunteer who is a non-admin to process a ticket after the file get deleted (from my experience). So I suggest to add provision for ticket number in Template:OTRS pending. (Modified as Krd showed his discomfort on non-OTRS volunteers using Template:OTRS received.) Jee 04:51, 7 April 2017 (UTC)

•  Support, and I have also volunteered for OTRS, including permissions-commons, to help with the backlog. Short term, we should extend the deadline on {{subst:OP}} to backlog+10 days, or 6052 days.   — Jeff G. ツ 05:05, 10 April 2017 (UTC)

  I disagree with extending the time when possible copyvios might stay on Commons. Short term, we can include a sentence into the auto-responding system which would say: "The OTRS backlog is currently quite big, it might take more than 50 days before you ticket is being handled. Do not worry if the file get deleted, we will restore it once your requests is successfully processed. Sorry for inconvenience." --Mates (talk) 06:20, 10 April 2017 (UTC)

  Mates, Extending the time is beyond the scope here. It is a legal demand that we can't keep files without confirmed permissions for long time. Even keeping them for more than 7 days with an excuse "a mail has been sent; but we don't know where it is" is a stretch. That's why we need to know the ticket number at least. Jee 06:46, 10 April 2017 (UTC)

  Thanks, Jee. I have seen your statement about that down in the general discussion. I was not sure if Jeff is aware of it. Anyway I can see your point in that ticket number need however there are some queues that don't have the automatic responses such as permission-cs. Truth is that those queues are quite small and their backlog does not often exceed 7 days. Still as there is no autoresponse the client gets no information about the ticket number and thus cannot put the number into the template. --Mates (talk) 07:36, 10 April 2017 (UTC)

  Thanks Mates; I was not aware of it. Still it can be added, keeping it as an optional parameter. Jee 07:41, 10 April 2017 (UTC)

  I saw it, thanks.   — Jeff G. ツ 16:36, 10 April 2017 (UTC)

  Full disclosure, I'm now an OTRS agent, and I'm working to reduce the permissions-commons backlog, but my work here is my own unless I indicate otherwise.   — Jeff G. ツ 04:48, 13 April 2017 (UTC)

•  Support, can be very helpful. -- Geagea (talk) 07:58, 10 April 2017 (UTC)
•  Comment This should be accompanied with the detailed process steps on how to do it, probably separately for the copyright holder and the OTRS agent handling the case. The problem I have mentioned was that OTRS agent may get a ticket with a permission for a media file not yet uploaded. It may be ovious to find the OTRS ticket from a later-uploaded image accompanied by otrs pending template (if it contained the OTRS id) but it's almost impossible the other way: to find the image (uploaded later, using a yet unknown name, as usually, or even worse, only pointing to an external URL) based on the info in the OTRS ticket. I can only speak for myself but as an agent I process the OTRS tickets and not the uploads, so either I cannot do anything (since tickets don't properly link to the image I should process) or I don't do anything (if I don't process tickets but uploads but I don't monitor file uploads); the problem is that as an agent I only monitor the OTRS queues, not the file upload logs. --grin ✎ 08:15, 10 April 2017 (UTC)
  • But there's a good proposal summary on Commons_talk:OTRS#Simplifying_the_instructions at the end. --grin ✎ 08:30, 10 April 2017 (UTC)
•  Support along with the summarised proposal. --grin ✎ 08:31, 10 April 2017 (UTC)
• Comment: I looked into the current coding of {{subst:OP}}, {{OTRS pending}}, {{OTRS pending/backlog}}, Commons:OTRS/backlog, and {{No OTRS permission since}}. I found that, no matter the backlog, {{OTRS pending}} and Commons:OTRS/backlog will give a minimum of 60 days before using {{No OTRS permission since}} to file into Category:No OTRS permission, but Category:No OTRS permission says in part "Their uploaders were notified at least 15 days ago and permission still has not been received" and "Pages are placed into this category automatically by addition of {{No OTRS permission since}}, but files only actually appear in the category if they have been tagged for at least 15 days." That number 15 is untrue and should be changed to transclude Commons:OTRS/backlog. I also found that {{OTRS pending}} says in part "Once 30 days have passed since the date given, the template automatically applies {{No permission since}}." Similarly, that number 30 is untrue and should be changed to transclude Commons:OTRS/backlog. I additionally found that, even though {{subst:OP}} can only create {{OTRS pending}} templates with month names in English, some of our uploaders are manufacturing {{OTRS pending}} templates with month names in languages other than English, such as Bulgarian, Italian, Japanese, and Portuguese, placing their files in the limbo Category:OTRS pending - No timestamp given, so we need to be vigilant in patrolling that category. Template logic that can obviate the need to do so would be very esoteric. Those languages are based on my examination of that category and repair of seven files therein earlier today (about two hours ago). The backlog currently stands at 51 days.   — Jeff G. ツ 14:12, 10 April 2017 (UTC)

  Interesting info which I was not aware of. Thanks. Jee 16:25, 10 April 2017 (UTC)

  You're welcome. Barring objection, I plan to boldly change those untrue numbers and implement logic to warn of a bad date in an instance of {{OTRS pending}} after 24 hours.   — Jeff G. ツ 16:41, 10 April 2017 (UTC)

   Done   — Jeff G. ツ 23:40, 11 April 2017 (UTC)

How about using a template we already have, Template:OTRS ticket, which takes a ticket number as the required parameter and indicates that the ticket exists, with a link to the ticket? It is not discussed above. It would be added by the uploader or advisor with access to the ticket number from the autoreply, and it could easily be searched for by an OTRS volunteer. On or a day before deletion day, the file could be reviewed by any OTRS volunteer, using the linked ticket number as a key back into the OTRS system to quickly determine why the ticket hasn't been closed yet and what to do about that.   — Jeff G. ツ 05:32, 12 April 2017 (UTC)

I had seen it after creating this proposal. The function seems same; but it looks to use in discussion pages than in a file page. Further, no documentation available for it. Jee 05:59, 12 April 2017 (UTC)

Ok, how about a new template, say Template:OTRS autoresponded, that looks like Template:OTRS received (including docs) but indicates the ticket is in queue and has not yet been seen by an OTRS human, and doesn't cause Krd discomfort?   — Jeff G. ツ 06:18, 12 April 2017 (UTC)

That seems nice. Glad to see we are progressing into more constructive and practical ideas than simply dismissing any suggestions and resist to change/improve. Thanks! Jee 06:39, 12 April 2017 (UTC)

@Jkadavoor: Thanks. Template:OTRS autoresponded and its feeder Template:OA are ready for review. Cats, translations, and integration with the rest of the family can follow.   — Jeff G. ツ 07:09, 12 April 2017 (UTC)

•  Oppose, don't make stuff even more complicated. And Template:OTRS autoresponded is imho not helpful, yet a other template which is confusing users. --Steinsplitter (talk) 15:46, 15 April 2017 (UTC)

Update on Commons:Email templates

We need two templates; one for file permissions and one for account verification. See, note #4 in Commons:Email templates suggests "For images, we prefer that you upload them to Wikimedia Commons, place {{subst:OP}} somewhere on the file description page, and provide the URL(s) of the uploaded content in your e-mail." This has several issues. 1. Any upload of copyvio without permissions will attract an immediate block after a warning. In my OTRS volunteer time, I had seen many blocked account whereas they had send a valid email to the OTRS which were not processed unfortunately. Blocking an account for uploading copyvio while we ourselves ask them to upload is terrible. 2. When the copyright holder upload themselves, the file already has a license as so demanding an email again with a license is redundant and somewhat nonsense. What we need is a simple statement from a verifiable address that both copyright holder and the Commons user who upload it are same. Further,it makes their life much easier as they can contiue uplading without further mails to a long queue which is unlikely to be processed in near future. Jee 04:51, 7 April 2017 (UTC)

•  Support definitely. Happens way too often, that the copyright holder uploads the file, someone puts it on speedy or remove it, block the user or take actions which lead to blocking. Plenty of cases where the website imagery was uploaded by the owner, or that the uploader already had (an informal but proper) permission to do so. (As in "message to admins: before dletion/blocking please ensure that the uploader had his/her chance to react on the accusations as s/he may be the same person as the copyright holder.") --grin ✎ 08:19, 10 April 2017 (UTC)

• grin, I just created a mail format for account verification. Feel free to enhance it. Jee 03:44, 15 April 2017 (UTC)

Update on Commons:OTRS

I already stared a discussion at Commons_talk:OTRS#Simplifying_the_instructions; please participate. Jee 04:51, 7 April 2017 (UTC)

General discussion

This is a draft I request as much as opinions and suggestions prior to proceed. Pinging Clindberg and Moonriddengirl for some expert opinions on legal matters too. Jee 04:51, 7 April 2017 (UTC)

Comment from my personal OTRS permissions agent's point of view: None of the above processes are broken, except that backlogs may cause single issues once in a while. --Krd 05:15, 7 April 2017 (UTC)

Agree with Krd. None of the above processes are broken, except that backlogs may cause single issues once in a while. --Steinsplitter (talk) 06:11, 7 April 2017 (UTC)

I wonder why both of you are commenting like this. Does something need to be "broken" prior to think about an "improvement"? Then it will be an attitude problem. Jee 06:16, 7 April 2017 (UTC)

Krd, Steinsplitter, like Jee, I'm rather surprised at your responses. All systems and processes can be improved. Perhaps Jee you could give some more examples in the discussion here. I'm rather doubtful that "None of the above processes are broken". -- Colin (talk) 07:17, 7 April 2017 (UTC)

In fact, None of the above processes are broken. Some people are tying to search a solution for a problem which don't exists. I hardly believe change the process in the suggested way will be a improvement. --Steinsplitter (talk) 07:34, 7 April 2017 (UTC)

Colin, I can bring a lot of examples; but not worth the efforts if this is the attitude of (some of) our admins. They are hardly willing to look from the ordinary user's side. See for example, this comment by Grin. My interaction with him so far is very gently and hopeful. (He is an admin; that's why I've still some hope in them as a whole.) The actual problem in that case as Grin commented is "communication must be improved"; not just Jcb or Jim. Jee 07:48, 7 April 2017 (UTC)

Not really sure why we need to link to "broken". I don't think the attitude here is respectful. I presume then, if all our procedures and policies and best practices are just fine, we won't be seeing any vague "I don't like the way this admin does XX or did XX" DRFA threats any time soon??? Hmm. -- Colin (talk) 08:32, 7 April 2017 (UTC)

If my answer to the question for opinions was disrespectful, please accept my apology.

The point I refuse is to build processes to workaround issues that are solely cause by backlog. We don't need a process that can cope with a 50 days backlog or a 100 days backlog, because we cannot keep files without validated permission that long in any case, so we'd be only delaying the issue and creating the same thing at larger scale. The plain and straightforward solution is to reduce the backlog, all efforts should be IMHO concentrated on that topic, if possible to below 7 days, which resolves all of the above mentioned problems and even more, without adding new complicated procedures. --Krd 08:47, 7 April 2017 (UTC)

Thanks Krd for this comment. Note that nowhere I proposed to extend the time to keep a file because the ticket is not processed. Instead what I mentioned is, an admin with OTRS can immediately check the ticket instead of deleting the file when the 30th day approached if the file has tagged with the ticket number. Currently the file will be tagged with "otrs-pending" which only means a mail have been sent. The OTRS volunteer needs to search and find it which is unnecessary as we already have an auto-response with the ticket number. My other suggestions like providing rooms to include custom messages are already appreciated in other threads when I first suggested it. See, we need to improve our legacy systems whenever a new feature is (like auto-response) already available. Why we're not making use of it? Jee 09:05, 7 April 2017 (UTC)

Because from experience it doesn't work. To give you one example, see User:Krdbot/af69, the list of OTRS tags added by non-OTRS users. If we push uploaders to handle half of the process themselves, we end up in even more search and validate work that nobody will ever be able to keep up with.

Another example is your proposed email template for account verification. We neither have any procedure nor the manpower on OTRS to handle account verification at full scale, and as soon as we start handling verifications regularly and provide a template, this starts to increase to an unmanageable amount. Happened exactly this way on other projects. Also not taking into account at all that account verification cannot replace individual permission, so don't help a lot here at all.

I'd prefer to start this discussion in smaller batches and at lower level and much slower speed, to be able to evaluate all aspects. I don't think any catchall proposal will be the best choice. --Krd 09:20, 7 April 2017 (UTC)

"We neither have any procedure nor the manpower" = process is broken. a redunkulous backlog, or inability to perform a task is the definition of brokenness. Slowking4 § Sander.v.Ginkel's revenge 13:02, 10 April 2017 (UTC)

1. I understand your point on Template:OTRS received as you want to keep it reserved for OTRS volunteers. Then we can modify Template:OTRS pending and provide room to mention the ticket number. Anyway Template:OTRS pending without ticket number is useless as the copyrightholder know the ticket number on the moment he receive the auto-response. 2. I disagree with your argument that account verification cannot replace individual permission. See for example, about my Facebook account. I will publish most images there for identification at least one week prior to upload here. Do we need individual permission for every upload? 3. Yes; this is a slow draft. I've no plant to face an voting soon without collecting a lot of opinions from as much as people. Thanks for the suggestions. Jee 09:33, 7 April 2017 (UTC)

Regarding yourself we don't. For the average user who thinks he is the copyright holder but really isn't, or who doesn't know about DW, we maybe cause some new problems, especially for company accounts. --Krd 09:37, 7 April 2017 (UTC)

OK; let us see some more opinion on this. For us (the long time volunteers who are trying to bring our friends to Commons), it will be a stopping block if fresh emails to OTRS is required for every new batch of uploads. Instead it will be very convenient if one email to verify the account is enough. See one example. Jee 09:52, 7 April 2017 (UTC)

We already have Category:Custom license tags with OTRS permission to solve similar problems. There are probably more points which already have solutions or at least things related that can be reused, that's why I suggested to keep discussion slower. --Krd 09:59, 7 April 2017 (UTC)

It is a very different matter. There (eg: Template:DmitryRyazanov), a Commons volunteer like me is uploading their files from an (or more than one) external source. Here we identify a person who had previously published his work off-wiki without a free license. In my example, the person is a well known naturalist and had published several book. After his account is confirmed, he will publish his works directly from his computer. He will upload; not me. They will be high resolution original files; not the low resolution Facebook or web contents. This is the way I bring high quality contents to Commons. Jee 10:09, 7 April 2017 (UTC)

Hi, Thanks a lot to Jee for starting this. I quite agree that there is a need for improvement. Copyright is already quite a difficult matter, no need to increase the confusion with procedures ordinary people do not understand. On the other hand, the main issue is still the huge OTRS backlog. But it should not be a reason not to improve our process. It is a bit of the egg and chicken problem: we lack committed contributors, but potential contributors are driven away. Regards, Yann (talk) 09:18, 7 April 2017 (UTC)

Thanks Yann. Jee 09:33, 7 April 2017 (UTC)

Thank you, Jee. This is an area that, while perhaps not 'broken', is in need of improvement, and your constructive ideas are very helpful. As Krd has mentioned, it will be easiest to deal with the various issues separately or in small batches, otherwise the discussions get very confused. As you have already set out various suggestions above, with clear headings, could I suggest that editors post specific comments on each in the relevent sections rather than here at the end? --MichaelMaggs (talk) 10:45, 7 April 2017 (UTC)

Thanks MichaelMaggs. Yes; feel free to comment under each section and use this section for generic comments! Jee 12:37, 7 April 2017 (UTC)

I definitely would like to improve the wording or tone of several of our templates -- I haven't looked at these in depth, but I did have some general comments when I answered a question on my talk page -- see this comment. I'll look back here in more detail when I have more time. Carl Lindberg (talk) 16:28, 7 April 2017 (UTC)

Thanks Carl Lindberg. It is nice! Take time, I expect this discussion will be here for a month. Pinging Whatamidoing (WMF) and Steven Walling too! Jee 16:37, 7 April 2017 (UTC)

Hi Carl Lindberg, after reading that discussion, I spend some time on reading various "problem/deletion templates". There are several templates exists ({{Copyvio}}, {{Speedydelete}}, {{Fair use}}, etc) and none of them will make an automated notification to the userpage. Instead, the requesting user need to add one ({{Copyvionote}}, {{Speedynote}}) manually. This seems to avoid delivering of several messages if a group of files are nominated for deletion. But it open the loophole that no notification is delivered. The wordings of Copyvionote has been questioned by several people. The warning "Wikimedia Commons takes copyright violations very seriously and persistent violators will be blocked from editing." seems noway "user friendly". The experience a user shared recently well explain it. It seems we need to include a sub-section for these templates too in this discussion. Jee 03:55, 10 April 2017 (UTC)

I agree with Carl Lindberg that we should improve the wording in some of the templates. Some templates could be made more welcoming; for others, a clearer/more complete set of directions is more important. WhatamIdoing (talk) 20:24, 11 April 2017 (UTC)

@Krd: the problem is that the system right now contains ambiguity which results lots of friction, including deleted images which have proper permissions, users banned because one description differs from another and agressive_admin_01 reads one and the user reads the other. Most of the cases triggering these events were not about "newbies who think they're the copyright owner" and not about "backlog". Most of them was about what template serves what purpose and should be used when and how, or when and how not. Specifically people have been using discussion->upload->otrs_pending_template->email_to_otrs->otrs_id and some admins thought that's unacceptable and worths a block, since half of the pages said this is okay, or kind of it is, and the other half vaguely suggested otherwise. And people got blocked and getting about desysopped, possibly due to these "non-broken" processes. I'd say any process resulting unneeded blocks and aggression is "broken", possibly not in the dictionary way. --grin ✎ 22:12, 10 April 2017 (UTC)

I again try to simplify, sorry if too much: Then these mentioned admins are mistaken, a thing that can be easily addressed. In my opinion nothing that warrants to drop all established procedures at once.

I'm not against improving things, I'm rather in favor or continuous improvement. What I oppose is "There is any problem, so here's a proposal to rebuild everything from scratch. Vote now!" Again a bit exaggerated, but this is still my feeling when reading the above discussion. --Krd 07:01, 11 April 2017 (UTC)

I may have been phrased my thoughts wrong, and maybe we collectively do. The main topic is not changing any process but defining it. Right now the process is defined by a few template documentation and a few guidelines, and they are not agreeing. We should fix them to describe the same process, I guess in this you agree as well. The problem is that we cannot fix them unless we know which one describes the process which is the basis of changing the others to describe the same process. Partially the problem is impolite admins, yes, but I believe in some cases the mismatching descriptions have lead to the problems, or at least significantly amplified it. Could you exactly specify what you believe the process now is? Can I upload an image then insert OTRS pending template then send OTRS email? Shall I include image URL, OTRS id in the second email? Can I (as an mere volunteer) forward the permission email to otrs? And lots of similar questions which have both answers correct and both wrong, based on which document you choose to pick in your argument. Not even that I want to restrict the process! If I am free to do whichever of these this should be said clearly, and said in all of the documents (maybe even transcluded). Lack of clarity and lots of ambiguity is the key problem here.

However you have to see it that by "unifying" the various documents we have to either "drop" the process which was based on misunderstanding or the opposite: we have to say that al of them is valid. (And remove blocks and undelete images which were based on wrong process…) Since any of them could change the policy (for those who used a different process so far) this may or may not require a call for some concensus. --grin ✎ 09:57, 11 April 2017 (UTC)

The only useful process IMO is:

1. obtain permission from the copyright holder
2. upload the image and insert otrs-pending
3. let the copyright holder send the permission within 7 days, including the file name/url the permission refers to
4. if the permission is incomplete, OTRS agent replaces otrs-pending with otrs-received

Don't send things multiple times because this creates confusion and increases processing time.

And of course you can forward a permission e-mail, so we at least have anything to work with. The OTRS agent will decide if that's sufficient or if we need some kind of confirmation. (In most cases they will ask to let the copyright holder send it directly.) --Krd 10:26, 11 April 2017 (UTC)

 Support as a sidenote I (as an OTRS agent) completely support the process above to be implemented throughout all the templates. --grin ✎ 10:39, 18 April 2017 (UTC)

Krd: 1. Here, we are asking the "helping volunteer" to upload the file and add "otrs-pending". Here (on note #4) we ask the copyright holder (you) to upload the file and add "otrs-pending". 2. Here we are asking the helping volunteers to forward the permission mails. Here we are advising the helping volunteer to ask the copyright holder to forward the mails. There are several such mismatches throughout our existing set of instructions. That's why I opened Commons_talk:OTRS#Simplifying_the_instructions and we're arriving into a consensus at grin's last comment. Jee 11:32, 11 April 2017 (UTC)

Also, Krd, there are many issues of obtaining permission (#1) to use a medium. One of them is identifying a holder if anonymous or unknown. Another is, even when a holder is identified, risking commercial interests of a holder. There are more issues to explain, yet... I can provide just two. --George Ho (talk) 11:45, 11 April 2017 (UTC)

See the wording at Template:OTRS pending: "An email containing details of the permission for this file has been sent in accordance with Commons:OTRS." See how this is contradicting with Krd's suggestion #3. Jee 11:50, 11 April 2017 (UTC)

I also agree that "the process" is poorly defined, and that we need to be clearer about what the ideal/most common process is, and make the templates work with that. Does it matter if every person first uploads and then immediately sends a message, or if some of them do it the other way around? No, it probably doesn't matter. But we should give them a set of directions that will always be functional, even if some small variations are acceptable. WhatamIdoing (talk) 20:24, 11 April 2017 (UTC)

I 100% agree with Krd. --Steinsplitter (talk) 15:49, 15 April 2017 (UTC)

@Krd: Wherever we solicit forwards, can we please ask for full Internet headers in plaintext, or at least email addresses? I've been dealing with some people who don't send them at first.   — Jeff G. ツ 23:54, 17 April 2017 (UTC)

I don't understand the question. Where do we solicit forwards? Is your question anything not covered by the OTRS permissions guidelines? --Krd 00:10, 18 April 2017 (UTC)

I am sure he wanted to request anyone who forwards emails to forward them with all the header informations (Reveiced:, return-Path:, ...) and not just some vague joke about the original headers, like some mail agents do (like: "From: John Doe // To: me"). Unfortunately I believe this is close to impossible, knowing the general awareness of the email headers (which is close to nil). We should kindly request it (I wholeheartedly agree), but by no means should we require it. --grin ✎ 10:39, 18 April 2017 (UTC)

Oversight bans

The following discussion is archived. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

The proposal formulated below in #Proposal to amend blocking policy could have enjoyed from more users commenting, but, as there was no opposition, and everybody who commented agreed, it becomes part of the policy]]--Ymblanter (talk) 19:44, 28 April 2017 (UTC)

---

The recent, and long-running, case of Dr. Bernd Gross has exposed a flaw in the Wikimedia Commons blocking policy... the Oversighters were unable to impose a needed block, due to lack of a community mandate to do so, for a prolonged period, and we were eventually forced to essentially act 'in God mode' to do so.

The Commons community has a longstanding opposition to the idea of creating an Arbitration Committee... and I agree. However, I would like to propose that a committee composed of those administrators with the ability to view oversighted material (this would be both oversighters, and those stewards who are also Commons administrators) be given a community mandate to impose a ban for egregious and repeated violations of Commons policies that can only be justified on the basis of oversighted material. In such cases it is unfortunately impossible to clearly justify such a ban to the community, since the relevant edits have been oversighted.

Such a ban would be appealable to either the Ombudsman commission (an extension of their mandate) or the Support and Safety department of the Wikimedia Foundation.

In all such cases, before a ban is implemented, m:Legal should be consulted. - Revent^talk 02:00, 27 March 2017 (UTC)

It surprises me that people like this aren't globally locked instead, when oversight, stewards, Legal, and Support and Safety are involved. Images can be uploaded to local wikis too, and dangerous behavior can be switched over to local wikis when a Commons ban would be done. Cross-wiki spammers are locked easily, and none of their spam usually needs to be oversighted anywhere. Daphne Lantier 02:53, 27 March 2017 (UTC)

@Daphne Lantier: The oversighters received, via email, a statement from SuSa that, after consultation with Legal, they believed that a ban from us was more appropriate. The point of this proposal is to ask for an actual community mandate for such actions, with the group of Commons administrators who can provide input to such an action made as wide as the privacy policy allows (by including those admins who are stewards). - Revent^talk 03:16, 27 March 2017 (UTC)

•  Oppose I have to disagree with Legal and SuSa. I think a global lock would be more appropriate in cases where someone is doing something bad enough to require repeated oversight suppression. Legal and SuSa need to think about the danger of these kinds of people picking up shop and moving to another project to reboot their activities. I don't think this process should be dumped on Commons oversighters and steward-admins. Daphne Lantier 03:30, 27 March 2017 (UTC)

@Daphne Lantier: I cannot disagree. When they decline to act, however, Commons needs some mechanism for such an action when it is clearly needed. An 'oversight block' was delayed for far too long due to a lack of a community mandate. - Revent^talk 03:41, 27 March 2017 (UTC)

•  Support I had asked about it long ago. I understand what Daphne Lantier but s/he may not ware that Commons community had showed their discomfort on actions by stewards and SuSa people without discussing with Commons. I think this (joint actions by OV and SuSa) is a good compromise. And SuSa can advise stewards to take a global action later or simultaneously. Jee 04:00, 27 March 2017 (UTC)

@Jkadavoor: The difference here is that I'm asking the community to endorse such bans when they have been endorsed by the 'committee' as a whole... essentially, using the authority granted us as admins 'en banc' to apply a ban that can only be reviewed by those with access to non-public information. The case of Dr Gross (since the community did not object) clearly implies that such authority exists... formalizing this will prevent such bans (which should be extremely rare) from being delayed due to a lack of an explicit community mandate. - Revent^talk 04:25, 27 March 2017 (UTC)

I noticed that part to include the Common admins who are stewards too as they too can access non-public data. I'm not sure whether it is required as I'm happy with the decisions of the OV team as a whole. But I've no objections if they too included. Jee 04:42, 27 March 2017 (UTC)

•  Oppose any introduction of totally new structures for a single background case. We can either block the user or apply for an office ban; I don't see that anything in between is required. --Krd 05:30, 27 March 2017 (UTC)

@Krd: This is hopefully exceptionally rare, but in the the case mentioned the WMF explicitly declined to act, while endorsing that the community do so. The Oversight team was reluctant to do so, however, as it was clearly beyond our mandate...eventually we simply did so due to a lack of other options. The case stretched on for years because of a lack of having any body with a mandate to act in such cases... it will hopefully not happen again, but someone needs the authority if it does, so that future cases can be resolved rationally. - Revent^talk 05:46, 27 March 2017 (UTC)

If you guys do an {{oversight block}} based on having to suppress uploads or edits numerous times, I doubt you'll get many people who object. Most people know what oversighting of uploads or edits usually involves. Just get rid of the reluctance. You were elected by the community to the trusted position of oversighter. The community trusts oversighters to protect them, and understands that sometimes a dangerous/problematic user may have to be blocked as part of a case. Daphne Lantier 05:54, 27 March 2017 (UTC)

Absolutely +1, Daphne Lantier. The linked discussion make the impression that the user was blocked too late. Blocking earlier is the most simple solution. Creating a full scale set of new measures and responsibilities at different groups of people doesn't appear reasonable to me. --Krd 06:00, 27 March 2017 (UTC)

@Krd: Oversight does not, currently, have the mandate to impose blocks as 'oversight actions', much less bans. We eventually acted simply as a group of admins who had access to the relevant evidence, but an actual ban that was not subject to community review (while clearly needed) was still still not technically within our authority as admins. My proposal was to spread the authority to impose such bans, since they cannot be subject to community review, across as wide a group of administrators as possible under the privacy policy. If the community decides to add such authority to the mandate of the oversight team, that is also acceptable, but someone needs it before another such case occurs. - Revent^talk 06:26, 27 March 2017 (UTC)

I don't see why an OS should not be able to block a user based on information gained though the OS process, and I also don't see why community review should be required for such cases. Compared to CU, blocks for abusing multiple accounts are done regularly, and there is no community review either, for the same good reasons. --Krd 06:36, 27 March 2017 (UTC)

@Krd: Concerns about OS taking such actions, in the absence of a community mandate, were being expressed on the mailing list years before I became an OS... they were, in fact, related to the extant case. On other projects, such authority (to block on the basis of non-public information) belongs to an Arbitration Committee. The case of CU is different, in that you can publicly justify a block on the grounds of 'this is a match' without revealing NPI, and CU blocks are accepted by the community as a matter of routine. CUs clearly have a mandate for such blocks, and they are not unappealable... this has been (so far) a unique case, and the OS have no mandate for a ban that can only be appealed to those with access to NPI. If the community wants to add that to the role of Oversight, that is fine, but I'd personally prefer that there be an agreed-upon means for appeal. - Revent^talk 07:12, 27 March 2017 (UTC)

The typical venue for appeal is any second or third other OS. When most or all OS agree that a block is justified, I don't see what additional appeal should be required. --Krd 07:21, 27 March 2017 (UTC)

@Krd: The issue is that the community has not actually granted the OS team a mandate for that... the mandate for OS is only for suppressing material within strict limits, not imposing blocks or bans. Since the established practice is that the OS team, due to an inherent lack of transparency of the role, acts 'en banc', an appeal to another OS is somewhat meaningless. - Revent^talk 07:32, 27 March 2017 (UTC)

(Edit conflict) Daphne Lantier and Krd, what about mentioning about {{Oversight block}} and {{Checkuserblock}} based on confidential evidence in Commons:Blocking policy? So far it is not documented there; just a mentioning about Checkuserblock in appeal section. If it is added, I think checkusers and oversighters can use the tool formally. Now they are using it 'in God mode'. (Whether or not to consider admins who are stewards is a different point. I think the inclusion of it here makes this discussion too complicated.) Jee 06:30, 27 March 2017 (UTC) I meant addition of this (with appropriate correction suitable for Commons) in our blocking policy. Jee 06:47, 27 March 2017 (UTC)

@Jkadavoor: I included those admins who are stewards because that role grants them the ability to view oversighted material... if the OS are acting to block or ban editors on the basis of NPI 'as admins', instead of as part of the oversight role, then it makes sense to include all admins who can see the relevant material in the group that makes such a decision. - Revent^talk 07:20, 27 March 2017 (UTC)

@Revent: Why does it take a group? If I saw you block someone because of oversight information, I would trust that you did what needed to be done. The community elected you and other oversighters because they trust you. The same goes for checkusers. If one checkuser finds some sockpuppets, we don't expect them to alert all other checkusers. If a user needs to be blocked based on OS info, go ahead and do the block. We don't need some exact policy for every action. That an oversighter is going to block someone who is a danger to other Commons users is part of the trust involved in electing oversighters. Nobody is questioning this particular block. You probably could have done it sooner and been fine. Daphne Lantier 07:40, 27 March 2017 (UTC)

Revent, I understood why you included the stewards. But Commons has a known hate to create new groups. Recently I contacted a SuSa member regarding an EN matter as their names are included in the functionaries list. But the user said they will not usually read the mails in that list or interfere in such matters as they prefer the local community elected members handle it. I suppose here the stewards prefer the OV team handle the matter even though stewards and some staff can see everything. Daphne Lantier, you are correct on "If one checkuser finds some sockpuppets, we don't expect them to alert all other checkusers." But every CU action is available for other CUs for a review; every OV action is available for other OVs for a review. The community trust the team as a whole; not as individuals. That's why we can't have a CU or OV if only one member in a project. (I think Commons also need a functionaries concept as this project is growing fast.) Jee 08:05, 27 March 2017 (UTC)

@Daphne Lantier: If an admin deletes a file, the fact that the file itself existed, and the deletion log entry, is publicly visible. The same is the case with blocks. Oversighters can not only redact the fact that a file ever existed, in a way that is completely invisible to other administrators (needed when the file name itself is oversightable), but we can completely redact the fact that an account ever existed, including the log entries of it's creation and block (needed when the account name is itself oversightable). The role is extraordinarily open to abuse, inherently intransparent, and held by very few people. We have to watch each other, because nobody else on Commons can.

Admins are expected to be able to justify their actions... even when an account is blocked on the basis of deleted copyvios, a couple of hundred admins are able to look at the deleted contributions and see the evidence... this is not the case for oversighted material. "Trust us, the evidence actually exists" is an unsatisfactory answer, when we have not actually been granted a community mandate for such actions. Typically 'oversight blocks' are only imposed when the account name is itself some form of egregious personal attack, and we make the account name completely disappear... this has been a uniquely different case.

The OS team has been, long before I was a member, reluctant to assume the role of a self-appointed ArbCom, taking actions beyond our community mandate on the basis of private information. I don't think that is a bad thing. - Revent^talk 08:25, 27 March 2017 (UTC)

@Revent: What if you're the only OS online and you find someone who has uploaded nude pictures of a former girlfriend and is publishing her phone number, address, and saying terrible things about her? You're going to handle it and take care of the problem. You can't wait. For a more complicated case like the DR., our OS team can discuss it and take what they feel to be the proper action. This is what we elected them to do. We trust them to do what's best for Commons, and I'm sure community members who voted for OS members envisioned that a few blocks would likely be needed. But if a definite mandate is seen to be needed, than I guess it can't hurt. Stewards on the other hand are not elected to perform OS functions or participate in OS-related business here on Commons. Giving them a new right to be semi-OS here sounds like overkill. Daphne Lantier 08:35, 27 March 2017 (UTC)

@Daphne Lantier: The practice is that we suppress the material and then notify the other oversighters of the action via the mailing list, for review by the team. The oversight policy is, however, quite explicit about the exact limits of our mandate, and the only case where we are specifically sanctioned to implement 'oversight blocks' is when the account name is itself oversightable.

Stewards already have the technical ability to view oversighted material. Those stewards who are admins here are thus competent, as admins, to give opinions about any potential block based on oversighted material, without acting as oversighters (which they cannot do without granting themselves the role). - Revent^talk 08:54, 27 March 2017 (UTC)

If I may interject: @Daphne Lantier: first thank you for your comments, I appreciate your reflection on the matter. Now, you seem to think in terms of what needs to be done in an emergency, and it is a fair point that we would block a nude-girlfriend-uploading offender on the spot, and oversight the images; but, the question is also how and when we could impose a ban on such a user, i.e. have the emergency block, which is done as an immediate measure to prevent further problems, condoned as a long-term disciplinary sanction. I see these two things as very different matters, and as much as I share your view that trusted people should have the leeway to take discretionary measures in an emergency (usually "preventing people from hurting themselves" is what is comes down to), I am far less comfortable with long-term decisions being taken without review and a clear mandate. This is both a matter of the trust we as Oversighters have to deserve from the community, and of the confidence we deserve that the steps we might have to take will have the legitimacy they need. Rama (talk) 09:15, 27 March 2017 (UTC)

•  Support mandate, oppose any new bureaucracy or official group. Seems reasonable to ask the community to provide such a mandate if it has never been explicit. It sounds like both of the opposes above also support some kind of mandate, but are just worried about making things more complicated. Revent, could you provide more details on how you envision this would be implemented? Kaldari (talk) 08:18, 27 March 2017 (UTC)

@Kaldari: I don't think any kind of technical implementation, or 'formal' new group, would be needed. The process would simply be (in the unfortunate case of such a situation happening in the future) that either the oversighters come to a consensus on the mailing list about such a block, or we cc those stewards who are commons admins (since they can see the evidence) into the discussion, and that group as a whole comes to a consensus. The issue in such a case is not, really, that the block would not be within the scope of any particular admin's mandate 'as an admin', it's that the evidence for it can't be publicly disclosed, and so the blocking admin can't really justify it to the community. - Revent^talk 08:36, 27 March 2017 (UTC)

•  Support mandate,  Oppose the creation of any new group. COM:BP is in need of revision anyway, and we should amend it to include a mandate for cases like this. The policy needs to be clear about behaviour that is blockable - and make it clear that, rarely, the behaviour causing the block won't be visible to most Commons editors. Where an admin blocks in such a case, for example using OS information, a notification should always be posted here. It would be good practice for several admins who have access to the information to confirm the block or, where it's not an emergency, for them to gain private consensus it in advance. All who agree should then sign the notice. In other words, COM:BP should be updated to reflect more or less what you did here. It seems pretty reasonable. MichaelMaggs (talk) 09:09, 27 March 2017 (UTC)
•  Oppose The proposal lacks definition, for example whether all oversighters need to agree, whether stewards and oversighters have different roles or votes, whether the process followed is a discussion or a vote, the circumstances that require involved stewards or oversighters to abstain, whether the accused has any right to examine the evidence or pass that to their representative/advocate, to what extent decisions are based on what can be proven or based on statements, the process for publishing the facts of actions taken and to what extent redaction or total secrecy is appropriate or ethical. The appeals procedure is essential, but has been left basically as a chalk mark where there should be a well defined governance process, as it is not credible that WMF support and safety are an appeal body or would be interested in taking that role on. This proposal may be a good idea, but it is not yet a working proposal that can be scrutinized. --Fæ (talk) 14:57, 27 March 2017 (UTC)

 Question @Revent, Rama: you have both used the terms 'block' and 'ban'. I'd like to be clear exactly what you mean, as some comments above seem to use the terms interchangeably, and others distinquish. En.W editors often use 'block' to refer to an action against a named user account and 'ban' to an action against a person. By 'ban' in this context do you mean an account that is indefinitely blocked on Commons with no expectation of being unblocked? Or something else? --MichaelMaggs (talk) 16:05, 27 March 2017 (UTC)

I used the terms as meaning

• a block is applied to a user account or an IP for either disciplicary reasons or for technical reasons: they might wish it so, or the admin might block to prevent continuation of repeated copyright violations, etc. Some blocks are lifted upon a mere request from the affected user.
• a ban is a very strong disciplinary measure, sanctionning repeated, serious offences. It is implemented by means of indefinite blocks that are not easily lifted and by checkusers.

I hope that using the terminology in this manner did not confuse anybody, and I am open to amending my vocabulary should this wording be imprecise. Cheers! 19:27, 27 March 2017 (UTC)

 Question @Krd: You're on the Ombudsman commission. What's your view on the commission being asked to take on this additional appeal role, as has been suggested? MichaelMaggs (talk) 16:23, 27 March 2017 (UTC)

I cannot speak for the whole commission, who didn't even have a chance to think about it yet. If you asked me I'd say the scope of the commission can be changed by the WMF board or anything related only, not by any Commons proposal.

Besides that and my general doubt as point out above, I also agree with Fæ that this proposal is not prepared well enough and should be thrown back to the phase discussion and elaboration, and not be voted on in this state. (Sorry to say this, and with all respect for the OS' work.) --Krd 17:06, 27 March 2017 (UTC)

•  Oppose any new construction. We have five oversighter and all of them are admin. If a local ban is preferred each of them may just apply the ban, e.g. with "based on oversighted material" as a block reason. If someone has reasons to doubt the block reason, they may contact one of the other 4 oversighters to ask for a second opinion. If we somehow cannot trust one of our oversighters is these cases, they should not be an oversighter in the first place. Jcb (talk) 16:34, 27 March 2017 (UTC)

•  Comment No objection about the principle that oversighters take a collective decision when it is necessary, including a block or a ban. However the proposal needs more discussion, as mentioned by Michael Maggs above. There are several details that need to be clearly defined before this being a formal policy. Regards, Yann (talk) 17:44, 27 March 2017 (UTC)

•  Oppose per Jcb, I trust the oversighters here and I don't think we need a new mandate or group for such cases. --★ Poké⁹⁵ 02:08, 28 March 2017 (UTC)

•  Support, see my comment below.   — Jeff G. ツ 04:06, 31 March 2017 (UTC)

•  Oppose I trust the oversighters. --Steinsplitter (talk) 16:04, 4 April 2017 (UTC)

How to handle appeals

There seems to be a growing consensus that we could amend COM:BP to give those admins who have oversight permissions a formal mandate, in this type of exceptional case, to take a collective decision to issue a block or ban based on confidential OS information that cannot be disclosed to the community. The exact wording would still need to be finessed, but we would essentially be giving that group of admins formal power to do what they have already done in this case.

More difficult will be the question of whether there should be an independent appeal and, if so, to whom. Taking the suggestions above, the options seem to be as follows:

1. There should be no independent appeal

We trust the oversighters to do what they need to do. If the subject objects, they would need to contact the oversight team privately and try to persuade them to reverse their decision.

Pro:

• No new body needs to be set up
• Simple

Con:

• If we consider that the principles of natural justice should apply, we should be very wary of condemning editors on the basis of confidential evidence, with no possibility of appeal.

2. Appeal publicly to the Commons community

Pro:

• The appeal is handled entirely on Commons
• No new body needs to be set up

Con:

• Not a proper appeal. As the community cannot be told the confidential basis for the decision, it is not realistically able to act as an appeal body that could question the result. The only possible control would be a general revolt by the community, which would inevitably result in the resignation of the entire group of oversighters.

3. Appeal to WMF Support and Safety department, or to some other WMF body.

Pro:

• WMF legal will have relevant legal expertise
• No new body needs to be set up

Con:

• The decision is taken out of the hands of the Commons community, and passed to the Foundation
• It is unlikely that the Foundation will agree, and as in this case they may prefer to leave the matter to the community

4. Appeal to the Ombudsman Commission

Pro:

• No new body needs to be set up

Con:

• The decision is taken out of the hands of the Commons community, and is passed to a body that is appointed by the Foundation
• The Commission was not set up to act as an appeal tribunal, and may not have the relevant expertise
• The Commission may not wish to accept the task, or may not be permitted to do so by the Foundation

5. Appeal to a new Commons Appeal Panel

Pro:

• The appeal is dealt with locally by a new panel answerable to Commons community
• The panel could, if approved by the community, handle a number of other difficult issues, including taking appeals against indefinitely blocked editors who have had email and talk page privileges removed, and for whom there is currently no viable appeal route.

Con:

• A new mechanism would need to be set up to appoint such a panel
• There may be a legitimate concern that we will end up with a body too much like the English Wikipedia's Arbcom (which few here would welcome). But that could be dealt with by drafting the panel’s rules of engagement closely and carefully.

6. Other options (please specify)

As has been suggested above, it is too early to start a formal vote, but it would be interesting to get the views of the community on the various appeal options listed above. Which would we prefer? MichaelMaggs (talk) 22:55, 27 March 2017 (UTC)

Discussion on appeals

I would favor appealing directly to the oversight team, as they are the folks with the evidence and knowledge of the situation. All the other options either pass the buck to the WMF or require a lot of new bureaucracy. @MichaelMaggs: Would you mind changing "There should be no appeal" to "Appeal directly to oversight team", as that seems more accurate. Kaldari (talk) 23:48, 27 March 2017 (UTC)

I don't think that would be accurate. The whole concept of an appeal requires independent review of a decision: Wiktionary defines the term as "An application for the removal of a cause or suit from an inferior to a superior judge or court for re-examination or review." Asking the team who made the decision to think again is not an appeal at all but a request for reconsideration. I've added the word 'independent' to make it clearer. MichaelMaggs (talk) 04:29, 28 March 2017 (UTC)

• 1 is the only option that makes any sense to me. I don't understand why the OS' couldn't ban from the beginning of their role. The buck has to stop somewhere, and the WMF clearly doesn't want it to stop with them. Useful public information could include that the OS' were unanimous, or that the offender engaged in this, that, or the other type of prohibited behavior that endangered themselves, the project, the WMF, a certain person or persons, or the general public. Using an example from above, "Doxxed an ex" or "Grossly violated personality rights of an ex" would be great justifications, as would "Posted child porn" or "Kept making defamatory usernames". "Posted child porn" is a particular problem for the entire WMF, as WMF servers and disk arrays in Florida which hosted such material could be seized by local, state, or federal law enforcement, and the same might be true in Germany or elsewhere.   — Jeff G. ツ 04:03, 31 March 2017 (UTC)

Are there any further comments specifically on the appeal procedure? Only two editors have so far responded to my request for feedback on possible appeal mechanisms, both of whom favour Option 1, above ("There should be no independent appeal").

To be clear, there seems to be consensus that we should give the group of admins who have OS permissions a formal mandate to block, without setting up a special new group to do that. Now we have moved on to discuss what should happen once, as here, the OS admins have completed the block. Should there be any further or higher level of appeal? I would personally favour Option 5, as I don't think it's legally or morally justifiable for volunteers on this project to make binding decisions that can never be independently reviewed on the basis of confidential evidence. Still, if it turns out there is some other consensus, I can draft some more detailed wording for formal approval on that basis.

Pinging editors who have contributed to the first part of this thread: @Revent, @Daphne Lantier, @Jkadavoor, @Krd, @Rama, @Fæ, @Jcb, @Yann, @Pokéfan95, @Jeff G.. --MichaelMaggs (talk) 15:38, 4 April 2017 (UTC)

The amount of volunteer time is limited plus active volunteers with any appetite to discuss 'internal' policy can be counted with close to one digit. I suggest the proposal is cut right down to the most sensible options and presented in simple English, or an interested subgroup work together to come back with a single final proposal which takes account of previous observations or may be little different from current practice. --Fæ (talk) 15:46, 4 April 2017 (UTC)

Option 1 works for me as long as there are several oversighters involved and supporting the decision (5 people in the case leading to this discussion). It should be a team decision. If this doesn't work, I am open to another system. Regards, Yann (talk) 16:02, 4 April 2017 (UTC)

An appeal authority is always more democratic and transparent; but I don't see such a possibility without setting up a functionaries team like arbcom. I saw in meta that "crats" is the functionaries where no separate arbcom exists. But crats have no rights to see the confidential information. That may be the reason why Revent suggested about another team which includes all OS members and stewards who are admin here. So my suggestions: 1, Choose option one and blindly believe the OS' decision if they acted as a team. 2. Upgrade the crats as functionaries. In such case, they need to disclose their identity to WMF and sign up the confidentiality agreement. 3. Accept Revent's suggestion as existing OS members and stewards have already access to the confidential information. Jee 16:40, 4 April 2017 (UTC)

Option 1 is the best for me, as long as there are several oversighters supporting the decision as Yann said above. ★ Poké⁹⁵ 00:33, 5 April 2017 (UTC)

@Yann: @Pokéfan95: One thing that seems quite clear from discussion on the list is that the current OS, at least, are not going to ban anyone unless we are all in agreement. - Revent^talk 01:45, 5 April 2017 (UTC)

If all the active OSs are unanimous, there is no one left with access to the data to process an appeal. Aside from 5 above, other extreme solutions are 7 having one OS recuse from the 1st ban vote (much easier), or 8 electing another OS. Otherwise, we are left with the unanimous decision of the five wise souls in OS-land, as we would be with the nine wise souls in the US Supreme Court. So for appeals, in order, I would go for 7 next time, 1 this time, 7, 1, then the more odious 8, Stewards, and WMF Legal.   — Jeff G. ツ 12:54, 5 April 2017 (UTC)

Renumbered because we sort of had a 6 already.   — Jeff G. ツ 22:23, 5 April 2017 (UTC)

Proposal to amend blocking policy

There is a good measure of agreement about the principles, so let's now move on to the detailed drafting. Here's my proposal for a new section to be added to Commons:Blocking policy:

• Edited to ensure that checkusers are not affected. --MichaelMaggs (talk) 15:27, 12 April 2017 (UTC)
• Minor copy edits. --MichaelMaggs (talk) 10:38, 13 April 2017 (UTC)

This seems clumsy and overly reliant on the above discussion for context. If dropped verbatim into the blocking policy, it could easily be read to relate to blocks made by checkusers as well (e.g. "Except in an emergency, non-oversight administrators should not block on the basis of information that cannot be shared publicly.") CU information is, by definition, information that cannot be shared publicly and CU blocks are "on the basis of confidential information." CU blocks are also not beholden to opinions or consensus of oversighters ("An editor who is blocked or banned under this section may not be unblocked without the approval of the oversighters.") This needs to better address the specific circumstance of blocks based on oversighted information (not the overly broad confidential) so it can be properly interpreted from a context-less position in the blocking policy. Эlcobbola _talk 14:50, 12 April 2017 (UTC)

Good point about CU information. I have made amendments to exclude that. --MichaelMaggs (talk) 15:27, 12 April 2017 (UTC)

I think it can be more simplified and without excluding CU blocks. Otherwise we need to amend our blocking policy again to define CU blocks. This is my wordings based on en:Wikipedia:Blocking_policy#Confidential_evidence: "Blocks based on confidential evidence: If a user needs to be blocked based on information that will not be made available to all administrators, that information should be sent to a Checkuser or Oversighter for action whichever as applicable. These editors are qualified to handle non-public evidence, and they operate under strict controls. Administrators holding Checkuser or Oversight privileges may block users based on non-public information revealed through the checkuser tool, or on edits that have been suppressed ("oversighted") and are inaccessible to administrators. As such, an administrative action is generally viewed to be made in the user's capacity as an oversight or checkuser, although the action itself is an administrative one. All such blocks are subject to direct review by other Checkusers or Oversighter as applicable. An editor who is blocked or banned under this section may not be unblocked without the approval of the Checkusers or Oversighter as applicable. An editor who wishes to have their block or ban reviewed should approach privately the Checkusers or Oversighter as applicable, who will consider the request as a group." Jee 16:48, 12 April 2017 (UTC)

That goes beyond the discussion we have had above, which I was attempting to capture here, but I agree that it would make sense to include CU blocks if we can get consensus for that now. What do others think? --MichaelMaggs (talk) 17:11, 12 April 2017 (UTC)

It makes good sense to exclude CU blocks from this section, via the "under this section" portion of "An editor who is blocked or banned under this section may not be unblocked without the approval of the oversighters." I would even go so far as adding another "under this section" portion to form "An editor who wishes to have their block or ban under this section reviewed should approach the oversighters privately, who will consider the request as a group."   — Jeff G. ツ 03:46, 13 April 2017 (UTC)

Jee, Would you go along with the wording in the box above, for now? While blocking policy does need to be updated to include CU blocks, that can probably best be done by an entirely new discussion. Adding CU into the draft text at this point considerably broadens this thread beyond its original scope of 'Oversight bans', and risks drawing objection that there has not been sufficient discussion. --MichaelMaggs (talk) 08:33, 13 April 2017 (UTC)

• MichaelMaggs, I've no objections if the community think so. Jee 10:06, 13 April 2017 (UTC)
• OK for me. Yann (talk) 10:10, 13 April 2017 (UTC)
• +1 Christian Ferrer ^(talk) 11:00, 13 April 2017 (UTC)

 Question Could someone from the oversight team provide a definition of what "group consensus" means in this proposal? I would like to see a record of precisely how this will work, so that if it changes behind the scenes over time, the Oversight team should explain the new process to the community. Thanks --Fæ (talk) 10:51, 13 April 2017 (UTC)

If anyone from the OS team wants to comment, that's fine, but the policy deliberately does not attempt to enforce a specific internal procedure on the team. They need the flexibility to respond according to the needs of the moment, and we can't predefine exactly what they should do. The discussion above has concluded that we trust them to do the right thing, and to define consensus in a reasonable way that works for them. --MichaelMaggs (talk) 11:06, 13 April 2017 (UTC)

That sounds okay superficially, but long term I can easily envisage this leading to resignations; based on past events with similar groups. The way the internal processes work is not something that has to be secret, and should be a matter for consideration when electing suitable Commons Oversighters. --Fæ (talk) 13:04, 13 April 2017 (UTC)

Given the small number of OSs and the level of commitment that the position represents, we can safely expect consensus to measn unanimity. Rama (talk) 17:45, 17 April 2017 (UTC)

In the case that started this, there was an original 'temporary' indef block with unanimous agreement, and then eventually a ban (again unanimous) after both trying to resolve this with the editor over months, and talking with SuSa and Legal. Such bans should be, and I think all the OS clearly agree based on the history of that case, an absolute last resort that we all agree is needed. - Revent^talk 19:22, 20 April 2017 (UTC)

I think this is a better wording than the original proposal. --Rschen7754 00:35, 20 April 2017 (UTC)

Closing

Could I ask an admin to close this, please? This has been a significant thread that doesn't deserve to find itself archived without a conclusion. --MichaelMaggs (talk) 08:30, 26 April 2017 (UTC)

I will have a look later today.--Ymblanter (talk) 08:46, 28 April 2017 (UTC)

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Labelling for Machine Learning / Artificial Intelligence

Would it be possible to have a tool for marking up the images with labels, pointing into Wikipedia - the combination of wikipedia's detailed meaningful text, and a huge database of images should be an awesome dataset for AI. Eventually you can imagine tools using convolutional networks to render imagery *from* the text, or vica versa. I imagine such labels would also be helpful for translation (visual vocabulary, including descriptive phrases).

How would this sit with community guidelines? I tried using 'image notes' to do this , and apparently that not's intended.

I also note it's possible to have image hotspots (image map not image notes) with links, these dont show up as 'annotations', but are still clickable. I think this is what I'm after.

artificial intelligence is dependant on labelled data; at present the best labelled datasets come from proprietary sources; You can get hold of labelled images, but the 'full context' of the wikipedia database jumps out as being a particularly great opportunity for the world. More data is always better. MfortyoneA (talk) 12:03, 15 April 2017 (UTC)

@MfortyoneA: There are already such projects, e.g. LabelMe of the MIT, I do not really understand why you want to duplicate these efforts.

But anyway: you can of course establish such a tool on your own server (e.g. using Drupal or Wordpress and annotation tools like [1]) and use images from Commons (you can find the corresponding guidelines on Commons:Reusing content outside Wikimedia/technical).

Regarding a tool within Commons: As I already wrote on your talk page I don't see any advantage for such annotations within Commons. And for a proposal of an extra tool (aka a Mediawiki extension) you would have to go to the developers at the Phabricator (see also Commons:Bugs) and to the Wikimedia Foundation (e.g. here) which will have to finance the development. And you will have to point out the advantages of your proposal for the Wikimedia universe (or at least for the world of free information). To produce a database for AI improvement is in my opinion nothing the Wikimedia Foundation is dedicated to, but maybe I'm wrong...

Anyway: This is nothing we can decide here.

Nebenbei gefragt: Ist deine Muttersprache deutsch? (Dein Gebrauch von "eventually" lässt mich das vermuten... Dann müssen wir nicht mühselig auf Englisch aneinander vorbeireden). --Reinhard Kraasch (talk) 17:41, 16 April 2017 (UTC)

- LabelMe is good but far fewer people know about it ... In my view the opportunity is the extra context of wikipedia itself; e.g. trying to think what the best label is for something, one can go and search wikipedia for articles that give consensus on what things are actually called. Just about anything in this world has more detail behind it than the average person realises at a glance (domain specific jargon, subtle variations, details). The beauty of wikipedia is the linked structure leading you to things you didn't know you were looking for. Think how we also have 'wiktionary'. Imagine the labels also being available as hints for translation between languages (words with more context). The links will also enhance the searchability of the images, and suggest images that could become illustrations for wikipedia articles. each image would contribute by almost functioning as a search-index. Imagine a tool which used all existing data to provide hover card labels for any terms that have labels associated with them. There might be an intermediate stage with redlinks , where we might have image-labels associated with something but no article (yet), hovering on the redlink could at least show you visually what the phrase refers to MfortyoneA (talk) 19:04, 17 April 2017 (UTC)

- "finance the development." .. from what I saw the existing tool is nearly enough, so a simple modification should suffice (it just needs an option to make links without the popup note, to de-emphasise them or whatever). I could probably figure out how to do that but the difficult bit is actually getting a consensus to accept it. MfortyoneA (talk) 19:04, 17 April 2017 (UTC)

- "To produce a database for AI improvement is in my opinion nothing the Wikimedia Foundation is dedicated to" .. it might not be their original mission statement, but the data is there, the format is already very useful, and data-driven AI is going to rule the world. wikimedia commons does seem to state a goal is "educational"; fine grain links to increasingly precise information might increase the educational value MfortyoneA (talk) 19:10, 17 April 2017 (UTC)

Anyway: You would have to go to the developers and ask for a modification of the ImageAnnotator. And to do so you will have to seek other Commons users supporting the idea (which mostly means: promising to undertake the additional workload of the labelling itself). Right now I only see you and me talking about the advantages and the disadvantages. Not that you misunderstand me: I graduated about machine vision in the 70s and am still interested in the issue, but I do not see how such a project will fit into the Commons community (and I for myself have enough other work, so I would not spend any time on labelling). Even if there were such a tool: there is nobody around to use it. BTW: The existing annotation tool is hardly used either, since most Commons users just upload images and nothing more. --Reinhard Kraasch (talk) 20:02, 17 April 2017 (UTC)

build and they will come. I dont mean to sound like 'encouraging spam', but you know how many people want to add content to wikipedia, and there's argument about 'notability' : anyone trying to add content to wikipedia might have an incentive to add labelled images (whether or not the actual page makes it through). The labelling can be seen as 'extending wikipedia' (imagine on that side, a 'what links here' tool will reveal the images). I sometimes kill time going through wikipedia finding things to link.. quite specifically this activity is an 'explorative' state. It's slightly more satisfying making a change rather than *just* reading. I'm sure I'm not unique.

but I do not see how such a project will fit into the Commons community - I see it as benefiting the whole inter-wiki; it's also not *just* machine vision, but enhancing the potential of machines to comprehend the wikipedia-text; humans have a database of life experience (including visuals) that each word is linked to. MfortyoneA (talk) 10:01, 18 April 2017 (UTC)

Try to find other supporters and then go on. --Reinhard Kraasch (talk) 12:14, 18 April 2017 (UTC)

It's an interesting idea but I don't think Commons is the place and I think it's a few years too late... In 2010 this would have been a fantastic idea but in 2017 companies (read Google) have already developed algorithms far more advanced than a human workforce for analyzing images and their contents... (See their posts about machine learning in street view, Google Goggles, REcaptcha, Google Crowdsource, etc) if someone were to implement this, I think it would be in Google-verse not Wikipedia as it really doesn't support our goals... Wikidata is about as far to the machine learning database as WMF goes to that right now... EoRdE6^{(Come Talk to Me!)} 04:16, 7 May 2017 (UTC)

Proposal on de-adminship for cause

It has been evident for some time, most recently during this discussion and this one, that our policy on community de-adminship requests is unclear and inadequate. It has not been reviewed for years, and cannot be relied upon either to support the right of the community to challenge admins where there appears to be evidence of serious problems, nor to protect admins from unreasonable de-adminship requests. Here is the current text:

I would like to propose a simple revised procedure. Cancel the current text, and replace with this:

De-adminship for cause

.

Community power to remove administrators

The community has the power to revoke the rights of an administrator who is routinely acting against policy or misusing the admin tools, or whose behaviour routinely falls below the standards expected of an administrator as set out in Commons:Administrators. The procedure set out here must be followed; de-adminship requests that do not comply will be closed by a bureaucrat as inadmissible. De-adminship is not normally appropriate for individual errors or behavioural issues that the admin has credibly committed to address. For individual grievances, please lodge an informal report at Commons:Administrators' noticeboard/User problems.

Preliminary discussion

Prior to a formal de-adminship request being lodged, a preliminary discussion must be held on Commons:Administrators' noticeboard/User problems, to be notified to the administrator on their talk page. It must be focused specifically on the question of whether a de-adminship request should be filed. The purpose of the discussion is to strike a balance between the right of the administrator not to have to face unreasonable de-adminship requests, and the right of the community to formally challenge the administrator if there appears to be evidence of serious problems.

The preliminary discussion should remain open for at least seven days from notification. It should then (unless the matter is a mere formality) be closed by a bureaucrat after consultation with the other bureaucrats. The closure should specify whether the threshold for filing a de-adminship request has been reached, but without giving any opinion on the eventual outcome of any such request.

The threshold has been reached if there is consensus to that effect, or there are serious, documented, and widely-acknowledged concerns, made in good faith, that the administrator routinely acts in a manner incompatible with their admin status, and it appears unlikely that this will change.

Drafting the request

If the threshold has been reached, a draft community de-adminship request may be drawn up by any editor, who should post a notice to Commons:Administrators' noticeboard/User problems calling for community input and signature by sponsoring editors.

Once the draft is ready (not less than seven days after the call for input), it may be converted to a formal de-adminship request, to be lodged on behalf of the sponsoring editors using the procedure for requesting adminship, as set out at Commons:Administrators.

The de-adminship request

The administrator must be notified on their talk page, and the request timed to open for public discussion and vote at least seven days later, to allow the administrator the opportunity to prepare and file a response. During this period no changes to the request may be made, and nobody other than the responding administrator may vote or comment. Any postings made will be removed as inadmissible.

The de-adminship request should remain open for at least a further seven days. It should then (unless the matter is a mere formality) be closed by a bureaucrat after consultation with the other bureaucrats. The closing bureaucrat will use their usual discretion, and will not treat the process as a vote. Normal standards for determining consensus, however, do not apply and the admin's rights will be removed if more than about 50% of editors expressing informed and reasoned opinions support that result.

Edit: strike 'consensus', per discussion. --MichaelMaggs (talk) 14:19, 20 April 2017 (UTC)

The main improvements are:

• clarify that the community has the power to de-sysop on the basis of serious behavioural shortcomings, and not only for misuses of the technical admin tools.
• involve the bureaucrats as a group in closing the initial discussion and the de-admin itself. De-admin requests happen rarely, but they can be important and expose strong community disagreements. It is reasonable for more than one bureaucrat to be involved, and would not represent a huge additional burden on the group.
• replace the completely unclear phrase “some consensus for removal” with a more clearly-defined threshold (while acknowledging that judgement will be needed, as we don't want the closure to be done on the basis of a raw vote).
• provide minimum time periods to allow for adequate preliminary discussion, for the community to review and comment on the draft de-sysop request, and for the responding admin to prepare a response without having to do so while voting is going on.
• replace the unclear and internally-inconsistent expression "majority consensus" with a more definite rule providing greater guidance to the closing bureaucrats.

If this seems a reasonable way forward, I'll make minor amendments to the wording as discussion proceeds. Constructive improvements are welcome. MichaelMaggs (talk) 13:28, 19 April 2017 (UTC)

Discussion on de-adminship for cause

• Much better than our old policy which is confusing. Though the phrase and widely-acknowledged concerns might be more food for Wikilawyers. Natuur12 (talk) 13:56, 19 April 2017 (UTC)

That provides required guidance to the closing crats, as we don't want a raw-vote threshold. --MichaelMaggs (talk) 14:12, 19 April 2017 (UTC)

•  Support in principle although "more than about 50%" seems to be vague. Rodhullandemu (talk) 14:03, 19 April 2017 (UTC)

It could say "a majority" or "more than 50%", but that would imply that the closing crats have no discretion other than to rubber-stamp the raw vote count. Adding 'about' emphasises their discretion. MichaelMaggs (talk) 14:39, 19 April 2017 (UTC)

•  Neutral I don't see any change, besides more words are used. No reason to support, no reason to oppose. --Krd 14:34, 19 April 2017 (UTC)

  The main changes are highlighted in the 5 bullet points above. --MichaelMaggs (talk) 14:42, 19 April 2017 (UTC)

  … and I for myself don't see anything that isn't already clear and set. Sorry. --Krd 14:46, 19 April 2017 (UTC)

•  Weak oppose if I have two choose between two texts saying same, I would choose shorter Mardetanha ^talk 14:47, 19 April 2017 (UTC)
•  Oppose A solution to a problem that does not exist. And for that by far too many words. --Reinhard Kraasch (talk) 14:49, 19 April 2017 (UTC)
• I have quite a few concerns:

1. The procedure does not seem to permit de-admin for a single gross violation of admin tools or horrendous behaviour. I think while rare, there may be cases where an admin does something that the community feels is, on its own, just too awful for them to be permitted to retain the tools. It may be they are blocked already for such behaviour. An example of tool-misuse could be INC unblocking Livio in full knowledge that recent unblock requests had not achieved consensus, combined with a personal feud with the blocking admin. INC knew that was beyond the pale and would lead to his de-admin but went ahead anyway. There were other factors and many previous events in that case, but that's an example I think of someone crossing the line, and for which only a single unrepentant act could be required for a de-admin vote.
2. The three periods of seven days adds up to twenty-one days of continued admin power. Is there a need to be able to request a temporary suspension of admin powers, or to request an admin desist from engaging a particular action related to the complaint (e.g. block/unblock, or deletions/tagging) while their adminship is under review? Also, if the voting/consensus is snowball then may it be shortened?
3. I agree with Natuur12 that "widely-acknowledged concerns" is unclear and open to interpretation according to the bias of any 'crat. Particularly when some people express their opinions on the form of "The community is sick and tired of..." and "we are all fed up with..." which gives a false sense of wide concern and agreement. In previous discussion on the consensus for Jcb, Natuur12 had a completely different definition of "consensus" to me, or to e.g. the Wikipedia:Consensus definition. For example, 10 support and 12 oppose is not a consensus, nor is 12 support and 10 oppose: both are clearly a lack of consensus. A consensus is a wide agreement among a group. Do we need to document this with a Commons:Consensus page that describes the term/policy in ways relevant for Commons?
4. The "made in good faith" clause expects one to judge the motive of those commenting and dismiss on that basis. In such heated votes, viewpoints are expressed in an adversarial manner with polarized language and cherry picking examples to make a case. Given that Commons is as unlikely to improve here as politicians are likely to start being truthful, surely the job of any closing 'crat is to sift through the evidence and make a judgement in spite of the bad faith, selective evidence, and spiteful comments. So I don't think that clause helps.
5. I like the idea that the decision to run a de-admin should be made by "a bureaucrat after consultation with the other bureaucrats". This will prevent any random person making a personal interpretation of the discussion and going ahead regardless. I think however, the 'crats should consider that where there is little or no consensus, then the subsequent de-admin is likely to be similarly divisive and unsatisfying. This does not mean that we should all disband and go about our own ways, but that there is a problem for which the community cannot agree on a solution. It is likely then that we expect the 'crats and others to work towards finding an alternative solution than de-admin. For example, further mediation, the success of failure of which, could provoke a more certain community response.
6. There is an implication that the sole mechanism to deal with an admin who frequently falls below the standard expected of the community is to form a mob and chop their head off. The proposal talks of a "preliminary discussion" but really it is not a discussion because it is "focused specifically on the question of whether a de-adminship request should be filed" -- in other words a binary debate yes/no vote. Voting doesn't produce a consensus but can only document an existing range of polarised and nonconstructive viewpoints. It doesn't encourage any efforts to mediate with the admin and attempt to resolve the issue without a de-admin vote. Then when we go to de-admin, once again there is this immediate vote that only provides two outcomes: lose the bit or retain the bit. There's nothing here to suggest we should first aim for resolving the issue, and perhaps require folk to document that serious good-faith attempts have been made to do so, and they have been rejected or failed.
7. The admin in question may in good faith believe their actions are for the best of Commons. While we don't want to create rules to prevent every stupidity, recent discussions have highlighted flaws in our procedures, tools, policies, best-practices, where the admin is exacerbating the system problem. The focus here, on simply debating whether the admin should be forcibly retired, does not encourage any constructive examination of those factors.

-- Colin (talk) 15:08, 19 April 2017 (UTC)

Colin, your list of 'quite a few concerns' is significantly longer than the actual proposal. If you'd be prepared to work with me to develop the draft, that would be much appreciated. I'll comment on each of your points if so. Will you help with a policy that will overcome your concerns? The added complexity, though, may not be attractive to those editors who prefer extreme brevity over procedural clarity. MichaelMaggs (talk) 15:30, 19 April 2017 (UTC)

I think we'd be better to start with a list of what doesn't work currently and what changes might improve things. A bit like your bullet point list. Perhaps it would help to have a list of previous community discussions that have succeeded or failed to generate a de-admin. Some (including one 'crat) seem convinced there is no problem, and if that is the case, it is pointless to polish and refine policy text, if we can't agree on issues/changes. But if there is a consensus to change some aspects, then the exact wording of any policy can be decided afterwards. -- Colin (talk) 20:42, 19 April 2017 (UTC)

•  Question Sorry if I missed that, but I think it maybe lacks a clear definition of what is a "consensus" in the Preliminary discussion, I can read "The threshold has been reached if: there is consensus to that effect...". But in the last similar discussion, regarding Jcb, there was a vote, and it is a fact that there was disagrements about what should be a "consensus". Is it a vote? if yes then is 50% sufficient? Or is it a bit unclear in purpose? this is just a question. Christian Ferrer ^(talk) 11:22, 20 April 2017 (UTC)

There is no agreed definition of 'consensus' (just one of many problems with the existing policy). It would be useful to agree that, and to create the page Commons:Consensus. --MichaelMaggs (talk) 13:01, 20 April 2017 (UTC)

Follow the Oxford English Dictionary definition. We do not need an essay which turns an existing word into an odd project specific neologism. The issue here is that the !vote should be simply a vote. The only reason we talk slightly inappropriately about 'consensus' for the RfA procedures, is that we wish the closer to have discretion to discount single purpose accounts or similar. This can be done by including the element of discretion in the vote procedure definition, it's a one-liner. The word "consensus" should probably be avoided becoming key for future wikilawyers, as it literally means reaching an effective unanimous result, which can never apply to a vote process where 50% is set as the boundary. If you review the past RfA cases, this has never been a significant issue. --Fæ (talk) 13:26, 20 April 2017 (UTC)

 Done @Christian Ferrer: Reference to 'consensus' struck. --MichaelMaggs (talk) 14:19, 20 April 2017 (UTC)

The OED simply defines it as "a general agreement". There is no one official way of determining if we have a consensus but there's plenty advice out there on how not to go about achieving one: hence the essay on WP. By removing the word "consensus" from the proposal, but retaining "closed by a bureaucrat after consultation with the other bureaucrats", all you are doing is implicitly expecting the 'crats to form their own consensus or declare they failed to reach one themselves. And without this "consultation with the other bureaucrats" clause, that Fae objects to, it then falls back to the case that any random user, in good faith or bad, can interpret the discussion how they see fit. -- Colin (talk) 16:01, 20 April 2017 (UTC)

•  Oppose due to the implicit and avoidable increase in the role of Bureaucrats, conflating the leadership role with having more direct authority. In practice, a RfA, de-sysop request or the (theoretical) confirmation RfA are procedural votes that should not be ignored, the RfA procedure even states this quite technically with "normally requires at least 75% in favour, with a minimum of 8 support votes". Right now the RfC I started on gender neutral language on en.wp is being argued about, because a vote split is being claimed to not be a "consensus" despite a 20%+ majority and all the reliable sources happening to support the opinions of the majority; indicating to me there's quite a bit of confusion in the general community about what consensus actually might mean in practice. In the Jcb desysop case mentioned above, it is not acceptable that we went through a double jeopardy situation, where the noticeboard ended up being equivalent to holding a desysop vote, and yet a technically correct move to run a desysop process ended up getting ignored because of the opinions of Bureaucrats, so the community never got to state its consensus view. When it comes to a community vote, it seems highly unlikely and inadvisable that any bureaucrat would descend from the heavens to override a majority vote. If something goes wrong, such as excessive off-wiki canvassing, this can be openly discussed, and corrective action may be as simple as the community agreeing to keep the vote open for a significantly longer time than usual, or even close the vote, but have another one a week later. Either of these options are better in terms of governance and transparency, than Bureaucrats having some private off-wiki discussion which may include evidence that the community never gets to see, and then telling the community their result. At the end of the day, adminship is a question of holding the mop, which most people will say is "no big deal", so there's no excuse to craft an arcane process as if this were electing the Pope. --Fæ (talk) 11:45, 20 April 2017 (UTC)
• I think both Michael (here) and Fae (at Wikipedia) made the same mistake. They saw a problem (does everyone agree there is a problem?) they come up with a solution (does everyone like the solution, especially one that proposes multiple changes?) and then they propose some (lengthy, complex) text that codifies that solution in policy/guideline (does everyone like the text and where the text is inserted and agree its a policy or a guideline or applies only to English, applies only to articles/images/help/policy/talk, etc) and then we vote. Either because the proposer sticks their own support vote after their proposal, or because that's what people here do anyway, even if you ask them to discuss. There's so many opportunities for being unhappy with the proposal that it is no wonder it often fails and the discussion is an angry mess.

Whereas Wikipedia:Consensus describes a process (and various ways to achieve it). The aim should be to form a consensus. Step by step. Then a vote is just a way of confirming if you have achieved that consensus and could be decided by some arbitrary threshold depending on how serious the change is (though from recent UK experience, a 50% threshold is considered just fine for even the most serious of changes to your country). I don't see why it would be different for admin issues. First establish some agreement there is actually a problem with the admin (or whether the problem lies with other admins or uploaders or "the system"). Then establish some agreement on a solution (of which de-admin is only one of many options and comes with quite a penalty). Then perhaps agree the wording of such a solution (assuming it isn't simple like removing the bit). Adminship, particularly for those are are highly active admins or highly opinionated admins, most certainly is a big deal, and has the possibility of doing great harm to either our content or the users. But admins are humans, not machines, so switching them off is far from the only method of dealing with problems. -- Colin (talk) 13:19, 20 April 2017 (UTC)

 Info An interesting series of responses so far. Some editors think the proposal is good, some don't see any problem that needs solving, and some agree that current policy is flawed but are dismissive of the proposal for a wide variety of reasons.

At present I can't see a way forward other than to ask editors to bear in mind that it's far, far easier to knock a proposal down than it is to make it in the first place. Telling a proposer at length that they've started from the wrong place or that they've got it all wrong does not encourage positive contributions from others. Quite the reverse. Actionable suggestions or counterproposals presented in a positive way to the community and driven forward by any editor who has a different perspective would help move the discussion on. I'll leave this open for further opinions. MichaelMaggs (talk) 14:08, 20 April 2017 (UTC)

Michael, I've helped write several guidelines and proposed changes to such over the years. Some have succeeded (two on WP, one on Commons) and some have crashed and burned. I'm sorry if you think it discouraging, but I don't think presenting a 500-word complex proposal to the community out-of-the-blue is the approach to take. At the very least, if you are going to make a proposal that involves the 'crats, it might be good to start by getting them on board to begin with. -- Colin (talk) 16:01, 20 April 2017 (UTC)

• @MichaelMaggs: firstly thank you for your several attempts to improve our guidelines and policies, though I did not participe very much, I look at your goodwill with a benevolent and grateful glance. Regarding my issue with "consensus", my suggestion is to arbitrarily decide on the limit to be atteined for the community can ask a De-adm. Exemple:

"The threshold has been reached:

if there is consensus to that effect,

by consensus we mean here, in an arbitrary way, at least 5 autopatroller users in favor of a De-adm, and at least a strict majority in favor of a De-adm

or there are serious, documented, and widely-acknowledged concerns, made in good faith, that the administrator routinely acts in a manner incompatible with their admin status, and it appears unlikely that this will change."

It is a limit easily attainable but also easy to counter to avoid the abuses. And "a strict majority" is an egalitarian and democratic side. And this makes it possible to avoid that all "decision power" or at least all the responsability go to bureaucrats to decide if there is indeed a consensus or not (with all the reproaches that can come afterwards). A rule has the advantage to be a rule. Christian Ferrer ^(talk) 17:06, 20 April 2017 (UTC)

• @MichaelMaggs: what's the rational for the The de-adminship request step? Why not just move straight from the consensus to hold a de-admin request to a de-admin request? ColonialGrid (talk) 08:37, 22 April 2017 (UTC)

@ColonialGrid: Do you mean the drafting step? Its purpose is to encourage a well-written and thought-out request with input and support from more than one editor. It provides an opportunity for the community to point out potential problems and to fix them before the de-admin request is posted and voting is in progress. The idea worked well in this recent situation (see the discussion on the talk page, in which a variety of potential problems with the draft were pointed out). MichaelMaggs (talk) 09:44, 22 April 2017 (UTC)

• @MichaelMaggs: sorry, yes the Drafting the request step, thank you for picking up on my mistake. Can you explain how the discussion you have linked to has aided in the de-admin process? All that appears to have happened is that the request has stalled; I consider this totally against the communities wishes as expressed in the preliminary discussion, where there was a consensus to move forward with a de-admin process. What benefit does this drafting offer that would not be picked up in either the preliminary discussion or the formal de-admin? Without any better justification that 'idea worked well in this recent situation' (which links to a stalled re-admin request, indicating to me that it clearly didn't work), I cannot support this bureaucratic burden, as I see it solely as a way of slowing down de-admin processes, potentially stalling them. I would support this proposal if Drafting the request were removed, or altered significantly so it could not be used as a filibuster technique. ColonialGrid (talk) 08:31, 27 April 2017 (UTC)

@ColonialGrid: I say it 'worked well' on the basis that the creator of the proposed de-admin request was sufficiently convinced by the arguments raised in that drafting discussion to change their view and (effectively) to withdraw their draft:

After a substantial amount of supporters for a desysop of Jcb expressed their opinion I went ahead and tried to prepare a DRFA but Jcb, Colin and Jee do have valid points. The case presented isn't a strong one. Either I suck at preparing a DRFA or the complaints aren't solid enough to actually warrant a desysop.

See the User:Natuur12/Jcb section of COM:BN. Others could write a new draft, but no-one has done so. Aside from this specific example, a drafting discussion does one of two things: it helps the drafter create a strong and well-argued de-admin request or (if no-one is prepared or is able to do that) it encourages the community not to press ahead with a poor, ill-prepared, or unlikely-to-succeeed request MichaelMaggs (talk) 10:19, 27 April 2017 (UTC)

• Sorry, but I'm not at all convinced. We have no such procedure for admin requests, and have had no problem with de-admin requests in the past (that I know of). I feel the existing processes are robust enough, with a preliminary discussion and the actual de-admin request being the places to thrash out the ins and outs. I see this step as nothing more than needless bureaucracy (at best) or wanton obstruction (at worst). My biggest problem with the concept, as you have proposed, is that there is a minimum time, but no maximum; it can effectively be used as a filibuster technique. If you are seriously concerned about poorly drafted de-admin requests (which I am yet to see as an actual problem) then I suggest that the comments of the closing 'crat(s)/admin(s) be used as the wording for the de-admin request, which is opened immediately after the preliminary discussion is closed, by the closing 'crat(s)/admin(s). ColonialGrid (talk) 09:32, 29 April 2017 (UTC)

• Currently some bureaucrats seem to think that the community cannot remove/discuss about removing admins in some cases even where a lot of editors are asking for it, so there seems to be something to fix indeed. One simple solution could be to establish that the bureaucrats do not need to block a desysop discussion before it's completed, so that they don't feel forced to do something in such seemingly unclear cases. I'm not sure what the proposed text would go in the same direction. Nemo 17:56, 22 May 2017 (UTC)
• As Krd, I think that it is already possible to have a deadmin request for the reasons outlined, however I have to advice against relaxing the requirements for deadminship as it leads to use deadminship processes as throwing weapons to use against "unconfortable" administrators who perform needed but impopular actions, as I've seen elsewhere in a couple of major projects. Regards, —MarcoAurelio 17:52, 29 May 2017 (UTC)