Page MenuHomePhabricator

Hacking: Provide a clickthrough workflow for file copyright email permissions
Open, MediumPublic

Description

The current Commons workflow for file copyright permissions requires the copyright owner to email OTRS, if unable to specify a free license for the files in a website where they are published.

File are uploaded with {{OTRS-pending}} on it, and the OTRS agent verifies the permission by replacing the template with {{OTRS received}}. Before or after the upload, often contacted by an editor, the copyright owner emails a permission to OTRS, referring to the specific works in question.

There are many problems with this:

  • The burden of writing a correct boilerplate permission is on the uploader. This does not works well in practice; less experienced users often omit some obscure but important requirement (e.g. permission for commercial reuse) and the OTRS agent has to refuse. This annoys uploaders and copyright holders and wastes the time of OTRS agents.
  • The process involves more manual work for the OTRS agent than ideal (OTRS backlogs are huge) and extra work for the uploader.
  • The software has no concept of permissions; the workflow is enforced by external hacks (e.g. AbuseFilter to prevent non-OTRS-agent users from adding {{OTRS received}}) which makes it hard to reuse in other wikis.

One solution would be to use a post-upload permission workflow with a clickthrough interface: the editor uploads the file to non-public storage, receives a secret link, sends it to the copyright holder, the copyright holder can see the image and give permission via clickthrough. The text of the permission does not depend on the editor or the copyright holder (neither of which are usually very knowledgeable about technical details of free content licensing), and OTRS agents only get involved once a boilerplate text which has been pre-approved by them is accepted.

A possible implementation:

  • When uploading via Special:Upload[Wizard], there is a checkbox "I need to request permission for this image".
  • When the box is checked, the upload goes to the permission stash (a new type of upload stash). The uploader can add license, description and other metadata, but the image is not public, does not appear on recent changes etc.
  • Unlike the normal stash, the image is still visible to anyone (not just the uploader) via a new special page Special:PermissionRequest/<secret token>. The page has a boilerplate text for the selected license; the text can be accepted via clickthrough.
  • The uploader only needs to send the link to this page to the copyright holder. After the copyright holder accepts by clickthrough another secret link is generated (along with some boilerplate text for an email message). The copyright holder needs to send that link to OTRS in email.
  • OTRS agents can verify the permission by clicking on the secret link, reviewing the permission, and clicking accept, at which point the image becomes public.
  • If the verification does not happen for a given period of time, and the image gets deleted.

The Lyon Hackathon will be a good chance to come up with initial user stories/mocks and think about the future of uploadstash.

This card tracks a proposal from the 2015 Community Wishlist Survey: https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey

This proposal received 9 support votes, and was ranked #68 out of 107 proposals. https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Moderation_and_admin_tools#OTRS_permissions_checker

Event Timeline

Tgr raised the priority of this task from to Needs Triage.
Tgr updated the task description. (Show Details)
Tgr subscribed.
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Nemo_bis renamed this task from Provide a clickthrough workflow for file copyright permissions to Provide a clickthrough workflow for file copyright email permissions.Feb 5 2015, 8:24 AM
Nemo_bis set Security to None.

This only works for the case where the copyright owner is also able to perform the upload: do we have statistics on how common this case is?

The gist of this proposal is to keep using email for permissions, but move the content of the permission to an attachment stored on wiki. Is this really worth it? Can't we just provide a form which produces a correct email? Ideally the output of the form would just be a mailto: link with all the necessary content; but many don't know how to use email, so we might need to connect to their mailbox directly.

I think we'd also get requests for the ability to move images back into the permission stash, because some users will inevitably misunderstand or just forget to tick "I need to request permission for this image".

Matthewrbowker triaged this task as Medium priority.

This only works for the case where the copyright owner is also able to perform the upload: do we have statistics on how common this case is?

I don't see why that would be the case.

The gist of this proposal is to keep using email for permissions, but move the content of the permission to an attachment stored on wiki. Is this really worth it? Can't we just provide a form which produces a correct email? Ideally the output of the form would just be a mailto: link with all the necessary content; but many don't know how to use email, so we might need to connect to their mailbox directly.

Email is somewhat understood as a legal tool for creating contracts, and has some value as an audit trail. Being able to show that the email was sent by the copyright holder, and the copyright holder organization being able to use the email details to figure out (for example) which employee exactly wrote it is important. So I think we need to stick with email and it needs to be sent by the copyright holder from their own mail system.

Using mailto: instead of / next to showing the boilerplate text is certainly possible; I'm not sure about the user-friendlyness of mailto: links.

Email is somewhat understood as a legal tool for creating contracts, and has some value as an audit trail.

Some value compared to what? Sources appreciated. The best tool is direct publication under a free license, according to the Creative Commons website.

The best tool is direct publication under a free license, according to the Creative Commons website.

I'm not sure about that. What if six month later they redo their website, and another six month later they demand to know by what right do you use the image? Especially in large organizations, where employees come and go, it's easily possible that no record remains that someone gave a permission at some point.

Of course, direct publication + email is better than just email, but if someone is willing to go the direct publication route, they can just copy/paste some boilerplate text, I don't think a tool is warranted for that. But that would put most of the burden on the copyright holder (and thus decreasing the probability of success) - sending a permission email is much simpler than modifying a web page.

Also, this tool should be implemented with reusability in mind - many projects allow non-free images in which case direct publication is not an option.

Refining the workflow and creating a mockup or prototype could be a hackathon project.

It is time to promote Wikimedia-Hackathon-2015 activities in the program (training sessions and meetings) and main wiki page (hacking projects and other ongoing activities). Follow the instructions, please. If you have questions, about this message, ask here.

Tgr renamed this task from Provide a clickthrough workflow for file copyright email permissions to Hacking: Provide a clickthrough workflow for file copyright email permissions.May 21 2015, 9:52 PM
Tgr updated the task description. (Show Details)
IMPORTANT: If you are a community developer interested in working on this task: The Wikimedia Hackathon 2016 (Jerusalem, March 31 - April 3) focuses on #Community-Wishlist-Survey projects. There is some budget for sponsoring volunteer developers. THE DEADLINE TO REQUEST TRAVEL SPONSORSHIP IS TODAY, JANUARY 21. Exceptions can be made for developers focusing on Community Wishlist projects until the end of Sunday 24, but not beyond. If you or someone you know is interested, please REGISTER NOW.
Quiddity subscribed.

Notes:
This task has some potential, as a possible candidate for a strongly qualified Outreachy/GSoC candidate.

The planned implementation makes sense to at least one OTRS agent, but would definitely need to be verified with a larger number of other OTRS agents, before development progressed.

@Tgr is potentially willing to be the primary mentor, if his other proposed mentor project isn't accepted first.

Note that the linked wishlist discussion was about (part of) the same use case but a different proposal.

Guess I'm doing some task necromancy here, but the current file copyright pemissions workflow is a pet peeve of mine and thought that we could try to improve it somehow during next Wikimedia Hackathon.
I'm not a developer myself, but I'd like to help to make this tool and workflow better so that we don't lose so many file uploads due to a rather obscure process.

What do you think?
Pinging those users that seemed the most active in the thread & other that might be interested to know: @Tgr @Qgil @Nemo_bis @Krenair @Aklapper @Quiddity @Toniher @KRLS

Aklapper removed Tgr as the assignee of this task.Jun 19 2020, 4:26 PM

This task has been assigned to the same task owner for more than two years. Resetting task assignee due to inactivity, to decrease task cookie-licking and to get a slightly more realistic overview of plans. Please feel free to assign this task to yourself again if you still realistically work or plan to work on this task - it would be welcome!

For tips how to manage individual work in Phabricator (noisy notifications, lists of task, etc.), see https://phabricator.wikimedia.org/T228575#6237124 for available options.
(For the records, two emails were sent to assignee addresses before resetting assignees. See T228575 for more info and for potential feedback. Thanks!)

Relgen addressses a lot of these issues, although, being a gadget, it's less integrated.

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy