.. _attribution_ref_label:

Recognizing Contributions
=========================

We are extremely grateful to everyone who has contributed to the success of the icepyx community and software.
This document outlines our goals to give appropriate attribution to all contributors to icepyx in ways that are fair and diverse and supportive of professional goals.
We define *contributions* broadly as:

    Efforts towards achieving icepyx's goals, including (1) writing code, tests, or documentation,
    (2) development of example workflows, (3) development, significant contributions, or maintenance of
    a tailored package that broadens the functionality of icepyx, (4) feedback and suggestions,
    (5) community building, (6) etc.

We recognize contributions in the following ways.

  **Note**: These policies are not set in stone and may be changed to
  accommodate the growth of the project or the preferences of the community.


Contributors List
-----------------

This project follows the `all-contributors <https://github.com/all-contributors/all-contributors>`_ specification.
When you contribute to icepyx for the first time or in a new way, you or a maintainer can use the `All Contributors bot
to open a PR <https://allcontributors.org/docs/en/bot/usage>`_` to recognize your contribution.
Comment on an existing PR with `@all-contributors please add @<username> for <contributions>`.
This will add you (or your new contribution type) to the ``CONTRIBUTORS.rst`` file located in the top level directory;
the file is packaged and distributed with icepyx, so each release has a record of contributors and their contribution types.


Changelog
---------

Each release includes a changelog of updates.
Everyone who has made a commit since the last release is listed, with new contributors indicated.
This list is automatically generated using a Sphinx extension; where available, full names are used.
If the user's full name is not available on GitHub, their GitHub handle is used.


Example Workflows
-----------------

Many of the example workflows included within icepyx were developed by individuals or small teams for educational or research purposes.
We encourage example developers to provide proper recognition for these efforts both within the notebook itself and
by adding contributors to the `Contributors List`_ for attribution as describered herein.


Version Releases on Zenodo
--------------------------

Each new release of icepyx is `archived on Zenodo <https://zenodo.org/record/7729175>`_.

Following the collaborative approach of `The Turing Way <https://the-turing-way.netlify.app/community-handbook/acknowledgement/acknowledgement-members.html>`_,
we aim to encourage community leadership and shared ownership of icepyx.
To this end, beginning with version 0.6.4 (the full adoption of the all-contributors specification)
we collectively represent the icepyx authors in citations (including Zenodo releases) as "The icepyx Developers".

As described above, a complete list of contributors and their contribution types is available via the `Contributors List`_.

  ** A note about releases <v0.6.4: Prior version releases adhere to authorship guidelines in place at the time,
  listing individual contributors who had manually added their names to `CONTRIBUTORS.rst`.
  Authorship order was alphebetical by last name, except in cases where
  a substantial contribution was made by one or more contributors to a given release. **


Peer-Reviewed Publications (Papers)
-----------------------------------

We will occasionally prepare manuscripts describing our software and its uses for submission to peer-reviewed journals.
These efforts are typically "in addition to" contributions made directly to icepyx (community or repository) and
thus may have specific author lists.
To be eligible for authorship on a peer-reviewed publication, contributors must:

  1. Contribute to the development (including code, documentation, and examples) of icepyx.
  Substantial non-code contributions may constitute eligibility for authorship.

  2. Contribute ideas, participate in authorship discussions (see next paragraph), write, read, and review the manuscript
  in a timely manner, and provide feedback (acknowledgement of review is sufficient, but we'd prefer more).

Author order will be determined based on co-author discussion, led by the publication preparation leader, ideally during the initial
planning stages of manuscript preparation (i.e. as soon as an idea matures into a potential manuscript and before writing begins).
Authorship will continue to be evaluated throughout the manuscript preparation process.
Discussions will consider authorship norms (e.g. How does author order convey participation and prestige?
How critical is first authorship to career advancement for each member of the team?
Do an individual's contributions meet authorship criteria or are they more suited to acknowledgements?).
Author order determination may also consider metrics such as the number of commits since the last major release
with an associated paper (``git shortlog vX.0.0...HEAD -sne``), contributions that do not have associated commits,
and contributions to the preparation of the manuscript.


Motivation and References
-------------------------

Concepts and models of attribution, credit, contribution, and authorship can vary across time, application, and communities.
`FORCE11 <https://force11.org/>`_ has an entire `Attribution Working Group <https://force11.org/groups/attribution-working-group/>`_ dedicated to working on attribution for research products.
`URSSI <https://urssi.us/>`_ hosted a workshop in 2019 (`report <https://urssi.us/blog/2019/03/24/report-from-urssi-workshop-on-software-credit-citation-and-metrics/>`_)
to identify core issues and propose solutions to challenges around software credit.
For software, current best practices (`e.g. <https://arxiv.org/pdf/2012.13117.pdf>`_) emphasize the importance of having a document
such as this one to describe an individual community's policies for credit, authorship, and attribution.
This document is an effort to describe icepyx's policies, with an awareness that they may change
to accomodate community growth, best practices, and feedback.

We do not attempt to identify contribution levels through the number of commits made to the repository (e.g. ``git shortlog -sne``)
or active engagement on GitHub (e.g. through issues, discussions, and pull requests) and Discourse.
The latter is difficult to quantify, and the use of squash merges into the development branch can mask the relative complexity
of various contributions and does not necessarily capture significant conceptual contributions.


Copyright notice: Preparation of this document and our credit policies was inspired in part by these `authorship guidelines <https://github.com/fatiando/contributing/blob/master/AUTHORSHIP.md>`_ provided by `Fatiando a Terra <https://github.com/fatiando>`_
and `The Turing Way <https://the-turing-way.netlify.app/community-handbook/acknowledgement/acknowledgement-members.html>`_.
We encourage potential contributors to consider the resources provided by the `NASA High Mountain Asia Team (HiMAT) <https://highmountainasia.github.io/team-collaboration/authorship/>`_
and established or emerging best practices in their community.
Please get in touch if you would like to discuss updates to this contribution recognition policy.
