Authorship policy

General principles

• We do not view authorship as a zero-sum game.
• Authorship in publications should be explicitly discussed between everyone involved as early as possible, ideally as soon as a project starts.
• Projects that lab members bring with them do not automatically confer authorship rights to either Leo or other lab members.
• However, if work is conducted on them during the course of being present in the lab, acknowledgments would be appreciated (funding acknowledgments are necessary).
• Projects that are collaborated on between lab members confer authorship to those directly involved, whether that collaboration is intellectual, technical, or data sharing. For example, writing code to support analysis or simulation would confer authorship.
• Sharing information during group meetings does not automatically confer authorship.
• If material intellectual contributions (i.e., new directions, solutions to problems, specific and directed project ideas) are made by lab members, that would confer authorship.
• Please keep Leo apprised of the broad outlines of your external and internal collaborations.
• You do not have to involve Leo or grant him authorship in your external collaborations.

Software papers and software archives

We strive to give appropriate credit to contributors for their work on software projects led by lab members. To do so, we will attempt to define:

• Fair and diverse ways of providing recognition for contributors’ efforts.
• Define contributions in a broad way: writing code and/or documentation, providing ideas, fostering the community, etc.

The following are the ways in which individuals who have contributed will be recognized.

Changelog for each release

Every time we make a release, everyone who has made a commit to the software repository since the previous release will be mentioned in the changelog entry. This is a way of saying “Thank you”.

The AUTHORS file

Anyone who has contributed a pull request to the project is welcome to add themselves to the AUTHORS.md file. This file lives in the repository and is packaged with distributions.

This is an optional process and is opt-in. Names and affiliations will be sourced from this file for publishing source code archives.

Zenodo archives of releases

Anyone who has contributed to the repository (i.e., appears on git log) can be included as an author on the Zenodo source code archive of new releases.

To be included as an author, you must add the following to the AUTHORS.md file of the repository:

1. Full name
2. Affiliation (if omitted, we will use “Unaffiliated”)
3. ORCID (optional)

If you have contributed and do not wish to be included in Zenodo archives, there are a few options:

1. Don’t add yourself to AUTHORS.md
2. Remove yourself from AUTHORS.md
3. Indicate next to your name on AUTHORS.md that you do not wish to be included with something like (not included in Zenodo).

Scientific publications (papers)

We aim to write academic papers for most of your software packages. Ideally, we will publish updated papers for major changes or large new components of the package.

To be included as an author on the paper, you must satisfy the following criteria:

1. Have made a contribution to the repository or significant non-coding contributions.
2. Add your full name, affiliation, and ORCID to the paper. These can be submitted by pull requests to the corresponding paper repository.
3. Write and/or read and review the manuscript in a timely manner and provide comments on the paper (even if it’s just an “OK”, but preferably more).

The order of authors will be decided on a case-by-case basis by open discussion with the authors.

---

Credit and terms of reuse: This manual is based on the excellent Lab Carpentry blueprints, with material adapted from the Data Intensive Biology Lab and the Data Exploration Lab. The manual contents are available under the Creative Commons Attribution 4.0 International (CC BY 4.0) license.