On required edits edit
Wikipedia is a volunteer site. Most editors are here because they want to be, not because they have to be. When teachers and bosses require that their students or employees create a page that gets through AfC and NPP or <insert bad thing here>, the result is not beneficial to the project, the possibility of future contributions from that person, and the view of Wikipedia by the public.
On socking edit
Unless you've got a very good reason, don't. You'll get caught, and that won't be fun. For you, I mean.
On fixing problems edit
If there's a problem you see, and it can be fixed in less than two minutes, don't tag it and wait for someone else to do it watch it rot in WP:BACKLOG. Just fix the problem yourself, and move on. This goes for simple copyright problems, obviously badly-licensed files, unsourced negative BLP content, and formatting issues, among other things.
On discussions you didn't hear about edit
If a discussion was listed on T:CENT, and you still didn't hear about it, that's your problem. Don't try to claim "local consensus" or "secret cabal RFC", you'll just prematurely wear out your keyboard.
On OTRS verification edit
The OTRS permissions process has existed in various forms for over a decade now. The scope and responsibilities of the permissions team are not always well communicated or understood.
First, some background edit
Wikimedia projects are free-content projects, meaning that everything on the projects should be available under a copyright license that allows anyone to use the content for any purpose as long as they credit the author and permit others to do the same. Public Domain, permissive (attribution required), and copyleft (attribution and same license for derivative works) licenses are permitted. For original content such as encyclopedia articles or own-work photographs, authors can agree to a free license when they save or upload their work. But not all works that may be useful on Wikimedia projects have been created by Wikimedia contributors. There's a large corpus of existing freely-licensed and public domain content that is in-scope on Commons or Wikipedia and would be useful. Authors often wish to contribute their content to Wikimedia projects, even if they do not wish to be contributors. Some contributors will also upload works that they do not have permission for. These are copyright violations and must be removed.
Prior to 15 March 2006, individual contributors were responsible for obtaining and storing permission from copyright holders for files on Wikimedia Commons. At one point, the Commons community decided that these statements of permission should be quoted on the file description page. These methods had two major issues: email addresses and other personal information about copyright holders was being released on file description page and individual uploaders had to be trusted to properly verify permissions. Commons administrators and patrollers often could not check that the permission was valid because they could not see the email chain or communicate with the copyright holder. These problems led to the creation of the OTRS permissions team.[1]
Scope of the permissions team edit
Members of the OTRS permissions team, also known as agents, must sign the OTRS users confidentiality agreement and agree to the Access to nonpublic personal data policy. Permissions agents are expected to have "strong knowledge of and experience with copyright issues".[2] All permissions agents have access to all permissions queues, but will generally only handle tickets in languages they speak relating to projects that they are familiar with. These agents are have the OTRS member global group and are listed at Special:GlobalUsers/otrs-member. Some agents will also have access to the photosubmission queue, which handles file upload requests. Access to OTRS is controlled by the OTRS administrators.
Broadly, the OTRS permissions team processes licensing information sent via email. Various pages describe the scope and responsibility of the OTRS team:
Sometimes Wikimedians would like to use images that do not have clear cut licensing information in articles. These images might not be licensed already, might have a license that is not permissive enough for use on Wikipedia, or might otherwise need confirmation that the copyright holder has agreed to the license shown on the projects. Wikimedians often contact the copyright holders of various images and ask them to license them so that they can be used on Wikimedia projects. The permissions team on OTRS is the one that processes these "permissions" e-mails and attempts to verify that the copyright holder releases the images under an allowable license, that they do so clearly while understanding what that means, and that they actually are allowed to license the images in such a way (e.g. they hold copyright). These e-mails are then stored in the ticket system so that they can be verified by anyone with appropriate access.
In all cases the uploader must provide appropriate evidence to demonstrate either that the file is in the public domain or that the copyright owner has released it under a suitable licence. Typically that requires at least that the source of the file be specified, along with the original source where the file is a derivative work. Also, the creator or copyright owner should be identified, if known or reasonably ascertainable. If there is any question, evidence may need to be supplied that the copyright owner has indeed released the file under the given licence.
Where the file is a photograph which shows an identifiable person, the subject's consent may be required as described at Commons:Photographs of identifiable people.
In all cases, the burden of proof lies on the uploader or other person arguing for the file to be retained to demonstrate that as far as can reasonably be determined:
- the file is in the public domain or is properly licensed, and
- that any required consent has been obtained.
Open-source Ticket Request System (OTRS) is a tool used by the Wikimedia projects, including Commons, to manage and archive email conversations. The main use of OTRS in relation to Commons is to verify and archive licensing permissions.
In some cases, sending email to OTRS may be required in order to provide evidence that the copyright holder has given permission to publish a file under a free license. Such evidence should be sent to permissions-commons
wikimedia.org (or a language specific address). OTRS is also used to handle email reports of copyright violations.
...
Each ticket will be reviewed by a volunteer. If there is sufficient evidence of a valid permission, the volunteer will mark the file(s) concerned as reviewed. The volunteer will also act to restore any files which may have been deleted before the permission could be verified, so when following the procedure described here, there is no need to request undeletion. If there is not sufficient evidence, the volunteer may request additional information from the correspondent. Volunteers will also act to ensure that any copyright violations that come to their attention are deleted.
Wikimedia has received an e-mail confirming that the copyright holder has approved publication under the terms mentioned on this page. This correspondence has been reviewed by an OTRS member and stored in our permission archive. The correspondence is available to trusted volunteers.
Permission has been received from the copyright holder to release this material under the Creative Commons Attribution-ShareAlike 3.0 Unported license. Evidence of this has been confirmed and stored by OTRS volunteers, under ticket number [...]. This template is used by approved volunteers dealing with the Wikimedia Open Ticket Request System (OTRS) after receipt of a clear statement of permission at permissions-en
- otrswiki:Help:Permissions-en-guide (non-public information)
While these various pages and templates differ in their exact wording, they all mostly align on the following:
- The OTRS permissions team handles emails about licensing issues.
- These emails should contain evidence that the copyright holder has released their work under a free license.
- OTRS agents review the provided evidence to determine if the release is valid.
- To be valid, permission must come from the copyright holder, relate to specific material, and contain a valid license.
Ticket handling edit
Now that we've established what OTRS agents do, now let's discuss how they do it. This section is a general description, not a guide. OTRS agents should consult the instructions on the private OTRS wiki instead. This section will use the OTRS software conventions of ticket, agent, owner, and customer. A ticket is an email chain between OTRS volunteers and one or more other people. An agent is someone with access to OTRS and (usually) the ticket being discussed. The owner is the agent who has most recently handled the ticket. While the OTRS software will lock a ticket to the owner on reply, this lock can be released by the owner or overridden by other agents and will expire after a limited amount of time. Current practice says that unlocked tickets can be worked on by any agent, regardless of the current owner. The customer is the person that the OTRS team is communicating with.
Emails to OTRS are initially sorted into queues depending on the email address that they were initially sent to. For example, emails to permissions-en
wikimedia.org are sorted into permissions::permissions-en, often shortened to permissions-en. Most permissions queues are sorted by language, not by project. The exception to this rule is permissions-commons, which handles content on Commons in any language. Some queues will have subqueues to sort tickets by content, such as the permissions::permissions-en::txt queue for English-language text content permissions. All permissions agents have access to all permissions queues.
When a ticket is received in permissions-en or permissions-commons, the OTRS software will send an automatic response to the customer. This response contains the ticket number and informs them that the email is received and awaiting processing. Other languages may or may not have autoresponses, depending on configuration. If Krdbot can find a link to a Commons file, it will place {{OTRS recieved}} on the file page stating that the permission is in a queue awaiting processing. Content on the English Wikipedia can be manually tagged by an OTRS agent with a similar template. These templates inform administrators and other users that the OTRS team is still working on the release statement and can prevent the content from being deleted for up to a month.
Agents will generally try to handle older permissions tickets first. If the relevant content has already been deleted, OTRS agents can ask a project administrator to undelete the content or send it to them privately. Content undeleted to permit OTRS review should always be tagged with an OTRS template with a ticket number. The OTRS agent will read the content of the email and decide if the permission is valid or if they need more information.
- What content is being released?
- Most permissions emails should include a link to the file page or article that they're trying to release. If that information is not supplied, checking the deletion logs and edit histories of relevant articles and performing a reverse-image search on images can help find the relevant page. Special:LinkSearch can also find links in warnings on user talk pages. The OTRS agent should always confirm with the customer that they've found the correct page.
- Does the on-wiki content match the content described in the email?
- Many customers are not contributors to Wikimedia projects. Even those who are can include the wrong link or attach the wrong file. If things don't match, the customer needs to clarify what they're trying to release.
- Was a standard release letter used?
- Wikimedia Commons and the English Wikipedia have standard release letters where copyright holders can release their content by filling in the blanks. The release letters also try to make sure that copyright holders understand what rights they have, what rights they waive, and what rights that re-users have. Emails without a standard release form may not include the necessary information. Sometimes, copyright holders will modify the release form in an attempt to add additional restrictions to the license. In most cases, these restrictions would create an unacceptable non-free license and the customer would have to be educated about licensing on Wikimedia projects.
- What license is specified? Is the release clear, including the specific license and version (if applicable)?
- Only free-content licenses are permitted. Some customers will try to use non-free licenses or non-specific licenses. This also includes statements like "I allow Wikipedia to use my photograph" or "I agree to release this content under the Creative Commons license". Wikipedia-specific licenses are not acceptable because anyone should be able to use the content on Wikimedia projects. There are many Creative Commons licenses, some of which are acceptable and some of which are not. Many licenses also have different versions, with different license terms. If a copyright holder specifies a versioned license but doesn't include the version number, the release is not valid.
- Was the content previously published anywhere?
- If the content specified in the email was previously published, it is even more important to make sure that the customer is the copyright holder. Sometimes previously-published works will have an exclusive license or have had their copyright transferred to someone else. If this is the case, the release may not be valid.
- Is the content attributed to someone else, on-wiki or elsewhere?
- If the uploader says that an image came from person A but person B sent the email, there's a problem. The customer might be the copyright holder, but they might be someone else entirely. In this case, further evidence that the customer is the copyright holder may be required for the release to be processed.
- Does the image have EXIF metadata that supports the release?
- Copyright information can also be stored in the EXIF metadata for an image. Many professional photographers will include their contact information in the metadata, which can help to verify who the copyright holder is. Many social networking sites and image editing software will remove or replace the metadata, obscuring the provenance of the image. In cases where the image has no relevant metadata, the customer may be asked to supply the original copy of the image with complete metadata. Image metadata can also help in cases where the customer claims that they took the image using a tripod and a timer.
- Does the email address match the published contact information for the copyright holder?
- The customer's email address is the best method we have for verifying that they are who they say they are. Many copyright holders maintain websites that include their contact information, and email addresses are often included in image metadata. If the content was previously published on a website that is directly connected to the copyright holder, an email from an address connected to that website is almost always required.
- Is the customer the copyright holder, their legal representative, or someone else?
- Copyright licenses are legal documents and can only be agreed to by the copyright holder or their legal representative. Sometimes someone will have permission to use the content but not the permission to re-license the content. If the customer claims to be the representative of the copyright holder, they will usually be asked to explain why they are their legal representative. Forwarded emails are almost always declined with a request to ask the copyright holder to email us directly.
Please do not send identifying documents such as drivers licenses or passports to OTRS. Scans of identifying documents are difficult to authenticate, contain large amounts of personally-identifying information, and are usually irrelevant. OTRS agents will not ask for scans of identifying documents, will not consider them if you do, and will ask an OTRS administrator to delete them from the system.
On a Global Code of Conduct edit
In recent years, there's been a push among online communities to adopt explicit codes of conduct that document and explain what behavior is expected by the community and what behaviors will not be tolerated by the community. Many communities have existed for a decade or more without a code of conduct, leading participants to question the need to add one now.
Established communities typically have a set of norms about how community members will communicate. These norms typically include where and when communication will take place, what topics are acceptable, the language to be used, and how community members should behave while communicating with each other. These norms are created often not by discussion, but by influential community members or by the importation of existing cultural norms. When a new member joins the community, they must learn and align with the norms through observation. If they do not conform to the community norms, in the best case an established community member will take the time to explain the norms to them and help them to join the community. In the worst case, the new member may find their contributions ignored or themselves ejected from the community. Conversely, if an established community member violates the community norms, the community's recourse to deal with the situation is often unclear. Other established community members may not acknowledge the problematic behavior or may not have the political capital to deal with it.
When online communities grow larger, this system of unwritten norms becomes more and more difficult. Established community members often don't have the time to explain how the community works to every misguided newbie, sending both established and new members on a path to frustruation and burnout. Influential community members also lose political capital as the community grows, giving them less influence over how the community operates. To deal with the new size of the community, practices and procedures are built on top of the established norms. As the founding community members lose influence or leave, the link to the original community norms becomes weaker. New members bring their own ideas about how things should be done, overwriting the existing norms. What behavior is considered problematic by the community becomes ambiguous, and what can or should be done about that behavior becomes unknown.
By establishing a code of conduct, an online community codifies the unwritten norms around behavior. A good code of conduct will define what behavior is expected, what behavior is unacceptable, and the consequences of unacceptable behavior. Codes of conduct, like all policy documents, can be broad but should not be unclear. All community members should be able to understand what the code of conduct says and where it applies. Clear codes of conduct declare what the expected standard of behavior is for everyone, allowing members of marginalized groups to be more comfortable joining the community.
The Wikimedia community is somewhat unique among online communities. Traditionally, the Wikimedia community has had close ties to the US free software and hacker movements. As the Wikimedia community has grown, however, more diverse contributors have brought their diverse backgrounds to the community. These editors do not share the same base cultural norms, which can create conflicts when they interact. For contributors to be able to engage in consensus-building discussions, they need to be able to set aside some of their pre-existing opinions and adopt the community norms. The Wikimedia community is also a community of communities, split by project, location, and language. Those smaller communities form their own norms and ideas about what is acceptable. When those smaller communities interact, the differences in local norms can create conflicts outside of the actual topic of discussion.
Existing problems:
- Large projects typically have codified standards of behavior, but smaller communities typically don't.
- The English Wikipedia, for example, has policies on civility, harassment, and personal attacks. Wikimedia Commons, however, only has draft policies and one line in the blocking policy.
- Not all communities share the same standards of behavior.
- An Amharic Wikipedia administrator and bureaucrat blocked an established global Wikimedian because their username states that they are queer, and the administrator's personal beliefs prohibited homosexuality. This action was supported by a local policy, written by that administrator and apparently not objected to by the few other Amharic editors. A steward attempted to discuss the block with the administrator, but was blocked for doing so. This second block was considered an abuse of tools and allowed another steward to desysop the administrator under emergency provisions. Almost by chance, the administrator was indefinitely blocked for harassment and personal attacks on two other wikis, meaning that a global ban proposal could be opened. A month later, the administrator was globally community banned, and a short while later the WMF banned him as well. If the administrator had not already been blocked twice for the same behavior and had not blocked a steward asking about their actions, it is not clear that their behavior would have been stopped.
To be continued