---
title: About the credit of authorship
author: Alejandra Casas, Marc Bria
tags: rights, authorship, procedure, template
year: 2023
---

# Introduction

This document is a brief guide on how to credit the authorship of documentation works created within the framework of the PKP project.

This guide covers authors, editors, translators, and maintainers and works as an example of how to credit.

## Contributors

Authors: Alejandra Casas (PKP), Marc Bria (volunteer) - 2023

Translation: Alejandra Casas (PKP) - 2023

Maintaininers: DIG team

[Placeholder for the license type footer]

# Motivation

The documentation generated by PKP’s Documentation Interest Group (DIG) is extensive, and, as a collective project, PKP Staff has created the majority of it. However, there are documents whose authors do not belong to the organization, meaning we have a mixed scenario of creators and institutions.

We can summarize the roles involved in documentation into four types: Editor, Author, Maintainer, and Translator.

Independently of which role we choose, there are several reasons why it is essential to credit the authorship of the documents. In order of importance, the main arguments for this are:

- **Ethics:** work always means effort, so it is fair to recognize who did it.
- **Motivation/Engagement:** authors will be more involved with the work if they sign it, resulting in higher quality. At the same time, it can be an element of social recognition within the community, which in turn can motivate more contributions.
- **Future references:** when the document needs changes or in case of doubts, it is relevant to know who wrote, modified, or translated it.
- **Legal:** in some countries is mandatory to credit the author to comply with the law.

No one doubts the need to credit authors, but doing it can be complex and time-consuming.

That is why CLAs (Contributor License Agreements, where authors assign rights to their work) are used in software development to manage copyright, so in this document, we propose to use the same resource.

# Rights

(Maybe here we can include some "legal mumbo jumbo" explanations about what rights will be transferred? It could be taken from Weblate's CLA)

- The copyright holder will be PKP.
- All works will be licensed under CC-by (unless duly justified).
- The year will be explicit.

# Some Proposals

The following ideas for the management of CLAs (Contributor License Agreements) come to mind, each with its own advantages and disadvantages:

| Proposal | Tool | When? | Pros | Cons |
| -------------------------------------- | ------------------ | ----------- | ----------------------------------- | ------------------------- |
| DIG "registration" one-time form | web<br/> pkpSurvey | DIG sign-in | Only filled in once | Not doc-level granularity |
| Document-specific form | PKPSurvey | pre | Multiple fields<br/>Data protection | Tooling maintenance |
| CLA acceptance on GitHub (edit button) | GitHub | post | Centralization | Less usable |

> Comment: "Multiple fields" means we can ask for (for instance) Document title, Autor's name, Institution, License, Date, Observations...

# Contributor's Template

## Where will it be placed?

In the README document (or index.md), just after the INTRODUCTION and before the license.

## About the template

The syntax would be something like this:

> ## Contributors
>
> [ Editor/s: Full name (affiliation | volunteer) - Year ]
>
> Authors: Full name (affiliation), Full name 2 (volunteer) - Year
>
> [ Translator/s: Full name (affiliation | volunteer) - Year ]
>
> [ Mantainer/s:
> - Year: Full name. ]

In such a way that:

- The section will start with "## Contributors" title.
- After this, we will add Editors, Authors, Translators, and Maintainers (by this order), of which only Authors are mandatory.
- Contributors will decide how they write their name and their affiliation (if they have one and have been involved in the work).
If there is no affiliation, it will be indicated as voluntary work (with "volunteer").
- If there is only one contributor of one type, it will use the singular form (e.g.: Editor instead of Editors).
- After the contributor, the year or release (first edition) will be added.
- The document will keep its initial authorship until the changes are deemed to be so significant that they constitute a new work.
- Alternatively, when a list of contributors is too long, we will use a bullet list of names.
- Unless otherwise agreed by the authors, the authorship order will be alphabetical by surname.
- If desired,a collective name can preced the list.
- Authorship and Editor names will be kept identical in translations.
- Finally, the contributor list may include additional notes. For example, "Adapted and published by..." or "With the funding by..." or "Special thanks to...".

# Metadata

To display metadata consistenly wherever it is shown we could capture authorship that way: mbr

> title: About the credit of authorship
> description: This document describes why, how > and when to credit authors' work.
> authors: Alejandra Casas, Emma Uhl
> editors: Marc Bria
> translators: Nate Wright

Then we can build that data into the page template. This has two benefits:

- If we build it into the page template, we can ensure it is displayed consistently wherever it is shown.
- We can include this information in <meta name="author"> tags and JSON-LD info (https://json-ld.org/). These are machine-readable formats that may improve how the items are displayed in Google search results.

JSON-LD uses the schema.org ontology, and the article object allows us to define author, editor, publisher, funder. translationofWork, license, and translator. https://schema.org/Article

Note: A deeper study of the ontology is required to extend this Metadata-Template.

## Examples

### Ex01. A long list of authors with a final note.

> ## Contributors
>
> Authors: Coalition Publica Metadata Working Group - 2021:
>
> - Lise Brin (Canadian Association of Research Libraries)
> - Haiyun Cao (York University)
> - Jessica Clark (Coalition Publica)
> - Bart Kawula (Scholars Portal)
> - Inba Kehoe (University of Victoria)
> - Pierre Lasou (Université Laval)
> - Tomasz Mrozewski (York University)
> - Mike Nason (Chair) (University of New Brunswick)
> - Mathieu Pigeon (Érudit)
> - Brianne Selman (University of Winnipeg)
> - Sarah Severson (University of Alberta)
>
> Adapted and published by the Public Knowledge Project’s Documentation Interest Group.
>

### Ex02. Authors with an Editor.

> ## Contributors
>
> Editor: Roger Gillis - 2019
>
> Authors: Sonya Betz (University of Alberta), Jennifer Chan (?), Roger Gillis (PKP), Jeanette Hatherill (?), Suzanne Jay(?), Andrea Kosavic(?), Andrea Pritt (PKP), Dana McFarland (PKP), Mariya Maistrovskaya (PKP), Ali Moore (?), Brownen Sprout(?), Kevin Stranack (PKP) - 2019
>

### Ex03. Authors, Translators, and Maintainers

> ## Contributors
>
> Authors: Alejandra Casas (PKP), Marc Bria (volunteer) - 2023
>
> Translator: Alejandra Casas (PKP) - 2023
>

------

# Appendix

## How did we credit till now?

Some examples of how we have credited authors in the past:

- https://docs.pkp.sfu.ca/getting-found-staying-found/en/
- https://docs.pkp.sfu.ca/metadata-practices/en/
- https://docs.pkp.sfu.ca/google-scholar/
- https://docs.pkp.sfu.ca/journal-policies-workflows/en/
- https://docs.pkp.sfu.ca/admin-guide/
- https://docs.pkp.sfu.ca/learning-ojs/3.1/es/
- https://docs.pkp.sfu.ca/student-toolkit/en/
- https://docs.pkp.sfu.ca/instructor-guide/en/

## Further discussions

- Define what to do with the versions of a document.
- Decide when a version is considered a new work (the Viking ship).
- How this is "implemented" with markdown syntax? (ie: JSON-LD schema)
- Define Contributors roles DIG level