SORTÆD: Software Role Taxonomy and Authorship Definition

Contents:

Flow of resource contributions

Software authorship

Developing research software is a dynamic, agile and collaborative effort, involving a spectrum of contributions. Examples of contributions include project management, software engineering and reporting bugs. Each of these contributions has varying impacts on the software.

The objective of Software Authorship is to give a set of definitions, guidelines and criteria to distinguish authors from non-author contributors of the software. Because of the dynamic nature of software development and maintenance, contributors may transition to and from author status as the software evolves.

By defining authors and non-author contributors, appropriate credit and citation and be given when using the software.

Who is an author?

SORTÆD recommends that software authorship be based on substantial contributions to:

  1. the conceptualization of the software; OR
  2. the source code, documentation and metadata, test code, setup or build configuration of the software; OR
  3. maintaining the software or safeguarding the continued existence or sustainability of the software project.

In contrast to authorship of textual research outputs:

  • software authorship is NOT based on approval of software versions to be released or published;
  • software authorship is NOT based on agreeing to be accountable for contributions to the software beyond legal accountability, in ensuring that questions related to the quality and integrity of the software are appropriately investigated and resolved.

All those designated as authors should meet one of the three criteria for authorship, and all who meet one of the three criteria should be identified as authors. Those who do not meet one of the four criteria due to the insubstantiality of their contribution should be acknowledged as contributors (see below). These authorship criteria are intended to reserve the status of authorship for those who deserve credit.

The responsibility for identifying who meets the authorship criteria lies is part of the governance of the software project, which may choose to recognize authorship beyond the SORTÆD criteria.

If agreement cannot be reached about who qualifies for authorship, the legal owners of the software should be asked to investigate.

Non-author contributors

Contributions to software can be made in different roles. Depending on the type of the contribution, contributors can be eligible for authorship if the contribution is substantial (see above).

Contributors who do not meet the above criteria for authorship should not be listed as authors, but they should be acknowledged. The roles that constitute contributorship are detailed in the following.

Software contributor role taxonomy

Supervision
Coordinates the project effort, possibly across organizational boundaries
Examples: Coordinator, project manager, advisor, team leader
Resources
Provision and maintenance of resources used and exposed by the software project, like computational infrastructure and cloud systems
Examples: System administrator, cloud manager
Funding
Acquisition or management of funding for effort and events that sustain the software
Examples: Principal Investigator, work package leader
Outreach
Communication with end-users and stakeholders
Examples: Training, community manager, user support
Development
Writing of the backend and frontend code as well as managing dependencies, making the software ready for release
Examples: Programmer, maintainer, UX designer, release manager
Data curation
Integration of data in the software and ensures metadata is annotated and available
Examples: Data provider, statician, data manager
Testing
Unit test, usability, integration tests, release test
Examples: Reviewer, reporting user
Documentation
Writing of all documentation related to the software, including user guidelines, roadmapping
Examples: Technical writer, metadata curator
Conceptualisation
Formulation of the idea and goals of the software, design of main features and functionalities
Examples: Principal Investigator, Architect, graphical designer, release manager, requirement gathering

Roles in software

Roles in Software

Guidelines for software projects

What do you need to do as a project?

As a research software project, it’s useful to be clear and transparent who the authors of your software are, acknowledge contributors, and describe how decisions around authorship are made.

  • Authorship: the list of authors should be clearly stated, and ideally made available in a machine readable form as well (e.g. using CodeMeta). A preferred citation for the software project (e.g. in a CFF file) should be included to make it easy to give credit to the authors.
  • Contributors: people who have made useful contributions to a project should be acknowledged in documentation, and ideally in project metadata (e.g. in the DOI metadata or in a CodeMeta file).
  • Governance: the way the project decides who is an author and who is a contributor should be transparently and publicly documented.

An appropriate place to put this information is in a contribution section in your README or a separate CONTRIBUTING file. There are good existing guidelines for how to structure a project README and CONTRIBUTING file.

Frequently Asked Questions

  1. What is the difference between a contributor and an author? A contributor is someone who has made a useful contribution to the project, through one or more of the different contributor roles. An author is someone who has made a more significant contribution to the project, as defined by the authorship criteria.
  2. When does a contributor become an author? A contributor becomes an author, when the people involved in the project governance have decided they meet the criteria.
  3. When does an author stop being an author? Generally, authorship is removed when the persons contributions to the current version of the software project are no longer meeting the criteria for authhorship. This may be because the code they have written is no longer included in the release.
  4. Who should I include as an author? This will be different for each project, however we recommend the people involved in the governance of the project use the authorship criteria and comes up with a set of questions that can be used to assess the significance of someone’s contributions. These may not just be contributions of lines of code, but the many other roles that are important in the development of research software.

Examples of use

To be added.

How to get involved in SORTÆD?

How to contribute?

If you would like to contribute to this project, please open an issue and get in touch with us.

How to become an author on this project?

To become an author on this project, please open an issue with a brief description of what you want to work on and we can discuss it.

How to cite this project?

Use the metadata for this DOI to cite this project:

Leem, Deborah, Turon, Gemma, Gruson, Hugo, Chue Hong, Neil, Kaur Bhogal, Saranjeet, Lo, Sherman, Druskat, Stephan, & Soiland-Reyes, Stian. (2023). SORTÆD: Software Role Taxonomy and Authorship Definition (0.1). Zenodo. doi:10.5281/zenodo.7896456.

SORTÆD: Software Role Taxonomy and Authorship Definition

Contents:

Flow of resource contributions

Software authorship

Developing research software is a dynamic, agile and collaborative effort, involving a spectrum of contributions. Examples of contributions include project management, software engineering and reporting bugs. Each of these contributions has varying impacts on the software.

The objective of Software Authorship is to give a set of definitions, guidelines and criteria to distinguish authors from non-author contributors of the software. Because of the dynamic nature of software development and maintenance, contributors may transition to and from author status as the software evolves.

By defining authors and non-author contributors, appropriate credit and citation and be given when using the software.

Who is an author?

SORTÆD recommends that software authorship be based on substantial contributions to:

  1. the conceptualization of the software; OR
  2. the source code, documentation and metadata, test code, setup or build configuration of the software; OR
  3. maintaining the software or safeguarding the continued existence or sustainability of the software project.

In contrast to authorship of textual research outputs:

  • software authorship is NOT based on approval of software versions to be released or published;
  • software authorship is NOT based on agreeing to be accountable for contributions to the software beyond legal accountability, in ensuring that questions related to the quality and integrity of the software are appropriately investigated and resolved.

All those designated as authors should meet one of the three criteria for authorship, and all who meet one of the three criteria should be identified as authors. Those who do not meet one of the four criteria due to the insubstantiality of their contribution should be acknowledged as contributors (see below). These authorship criteria are intended to reserve the status of authorship for those who deserve credit.

The responsibility for identifying who meets the authorship criteria lies is part of the governance of the software project, which may choose to recognize authorship beyond the SORTÆD criteria.

If agreement cannot be reached about who qualifies for authorship, the legal owners of the software should be asked to investigate.

Non-author contributors

Contributions to software can be made in different roles. Depending on the type of the contribution, contributors can be eligible for authorship if the contribution is substantial (see above).

Contributors who do not meet the above criteria for authorship should not be listed as authors, but they should be acknowledged. The roles that constitute contributorship are detailed in the following.

Software contributor role taxonomy

Supervision
Coordinates the project effort, possibly across organizational boundaries
Examples: Coordinator, project manager, advisor, team leader
Resources
Provision and maintenance of resources used and exposed by the software project, like computational infrastructure and cloud systems
Examples: System administrator, cloud manager
Funding
Acquisition or management of funding for effort and events that sustain the software
Examples: Principal Investigator, work package leader
Outreach
Communication with end-users and stakeholders
Examples: Training, community manager, user support
Development
Writing of the backend and frontend code as well as managing dependencies, making the software ready for release
Examples: Programmer, maintainer, UX designer, release manager
Data curation
Integration of data in the software and ensures metadata is annotated and available
Examples: Data provider, statician, data manager
Testing
Unit test, usability, integration tests, release test
Examples: Reviewer, reporting user
Documentation
Writing of all documentation related to the software, including user guidelines, roadmapping
Examples: Technical writer, metadata curator
Conceptualisation
Formulation of the idea and goals of the software, design of main features and functionalities
Examples: Principal Investigator, Architect, graphical designer, release manager, requirement gathering

Roles in software

Roles in Software

Guidelines for software projects

What do you need to do as a project?

As a research software project, it’s useful to be clear and transparent who the authors of your software are, acknowledge contributors, and describe how decisions around authorship are made.

  • Authorship: the list of authors should be clearly stated, and ideally made available in a machine readable form as well (e.g. using CodeMeta). A preferred citation for the software project (e.g. in a CFF file) should be included to make it easy to give credit to the authors.
  • Contributors: people who have made useful contributions to a project should be acknowledged in documentation, and ideally in project metadata (e.g. in the DOI metadata or in a CodeMeta file).
  • Governance: the way the project decides who is an author and who is a contributor should be transparently and publicly documented.

An appropriate place to put this information is in a contribution section in your README or a separate CONTRIBUTING file. There are good existing guidelines for how to structure a project README and CONTRIBUTING file.

Frequently Asked Questions

  1. What is the difference between a contributor and an author? A contributor is someone who has made a useful contribution to the project, through one or more of the different contributor roles. An author is someone who has made a more significant contribution to the project, as defined by the authorship criteria.
  2. When does a contributor become an author? A contributor becomes an author, when the people involved in the project governance have decided they meet the criteria.
  3. When does an author stop being an author? Generally, authorship is removed when the persons contributions to the current version of the software project are no longer meeting the criteria for authhorship. This may be because the code they have written is no longer included in the release.
  4. Who should I include as an author? This will be different for each project, however we recommend the people involved in the governance of the project use the authorship criteria and comes up with a set of questions that can be used to assess the significance of someone’s contributions. These may not just be contributions of lines of code, but the many other roles that are important in the development of research software.

Examples of use

To be added.

How to get involved in SORTÆD?

How to contribute?

If you would like to contribute to this project, please open an issue and get in touch with us.

How to become an author on this project?

To become an author on this project, please open an issue with a brief description of what you want to work on and we can discuss it.

How to cite this project?

Use the metadata for this DOI to cite this project:

Leem, Deborah, Turon, Gemma, Gruson, Hugo, Chue Hong, Neil, Kaur Bhogal, Saranjeet, Lo, Sherman, Druskat, Stephan, & Soiland-Reyes, Stian. (2023). SORTÆD: Software Role Taxonomy and Authorship Definition (0.1). Zenodo. doi:10.5281/zenodo.7896456.