Skip to content

Latest commit

 

History

History
183 lines (132 loc) · 7.46 KB

CONTRIBUTING.md

File metadata and controls

183 lines (132 loc) · 7.46 KB
Raw

Contributing

When contributing to this repository, please first discuss the change you wish to make via issue, email, or any other method with the owners of this repository before making a change.

Please note we have a code of conduct, please follow it in all your interactions with the project.

Development environment

earthaccess is a Python library that uses Poetry to build and publish the package to PyPI, the defacto Python repository. In order to develop new features or patch bugs etc. we need to set up a virtual environment and install the library locally. We can accomplish this with both Poetry or/and Conda.

Using Conda

If we have mamba (or conda) installed, we can use the environment file included in the binder folder, this will install all the libraries we need (including Poetry) to start developing earthaccess

>mamba env update -f binder/environment-dev.yml
>mamba activate earthaccess-dev
>poetry install

After activating our environment and installing the library with Poetry we can run Jupyter lab and start testing the local distribution or we can use the scripts inside scripts to run the tests and linting. Now we can create a feature branch and push those changes to our fork!

Using Poetry

If we want to use Poetry, first we need to install it. After installing Poetry we can use the same workflow we used for Conda, first we install the library locally:

>poetry install

and now we can run the local Jupyter Lab and run the scripts etc. using Poetry:

>poetry run jupyter lab

First Steps to fix an issue or bug

  • Read the documentation (working on adding more)
  • create the minimally reproducible issue
  • try to edit the relevant code and see if it fixes it
  • submit the fix to the problem as a pull request
  • include an explanation of what you did and why

First steps to contribute new features

  • Create an issue to discuss the feature's scope and its fit for this package
  • run pytest to ensure your local version of code passes all unit tests
  • try to edit the relevant code and implement your new feature in a backwards compatible manner
  • create new tests as you go, and run the test suite as you go
  • update the documentation as you go

Please format and lint as you go with the following scripts

scripts/lint.sh
scripts/format.sh

Requirements to merge code (Pull Request Process)

  • you must include test coverage
  • you must update the documentation
  • you must run the above scripts to format and line

Pull Request process

  1. Ensure you include test coverage for all changes
  2. Ensure your code is formatted properly following this document
  3. Update the documentation and the README.md with details of changes to the interface, this includes new environment variables, function names, decorators, etc.
  4. Update CHANGELOG.md with details about your change in a section titled Unreleased. If one does not exist, please create one.
  5. You may merge the Pull Request in once you have the sign-off of another developers, or if you do not have permission to do that, you may request the reviewer to merge it for you.

Release process

📝 The versioning scheme we use is SemVer. Note that until we agree we're ready for v1.0.0, we will not increment major version.

  1. Ensure all desired features are merged to main branch and CHANGELOG is updated.
  2. Use bump-my-version to increase the version number in all needed places, e.g. to increase the minor version (1.2.3 to 1.3.0): 
    bump-my-version bump minor
  3. Push a tag on the new commit containing the version number, prefixed with v, e.g. v1.3.0.
  4. Create a new GitHub Release. We hand-curate our release notes to be valuable to humans. Please do not auto-generate release notes and aim for consistency with the GitHub Release descriptions from other releases.

⚙️ After the GitHub release is published, multiple automations will trigger:

  • Zenodo will create a new DOI.
  • GitHub Actions will publish a PyPI release.

📝 earthaccess is published to conda-forge through the earthdata-feedstock, as this project was renamed early in its life. The conda package is named earthaccess.

Code of Conduct

Our Pledge

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.

Our Standards

Examples of behavior that contributes to creating a positive environment include:

  • Using welcoming and inclusive language
  • Being respectful of differing viewpoints and experiences
  • Gracefully accepting constructive criticism
  • Focusing on what is best for the community
  • Showing empathy towards other community members

Examples of unacceptable behavior by participants include:

  • The use of sexualized language or imagery and unwelcome sexual attention or advances
  • Trolling, insulting/derogatory comments, and personal or political attacks
  • Public or private harassment
  • Publishing others' private information, such as a physical or electronic address, without explicit permission
  • Other conduct which could reasonably be considered inappropriate in a professional setting

Our Responsibilities

Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.

Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.

Scope

This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.

Enforcement

Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at [email protected]. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.

Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.

Attribution

This Code of Conduct is adapted from the PurpleBooth's Contributing Template