Skip to content

Latest commit

 

History

History
81 lines (60 loc) · 3.46 KB

CONTRIBUTING.md

File metadata and controls

81 lines (60 loc) · 3.46 KB

How to contribute

We'd love to accept your patches and contributions to this project. We do have some guidelines to follow, covered in this document, but don't worry about (or expect to) get everything right the first time! Create a pull request and we'll nudge you in the right direction. Please also note that we have a code of conduct to make OpenFermion an open and welcoming environment.

Before you begin

Sign our Contributor License Agreement

Contributions to this project must be accompanied by a Contributor License Agreement (CLA). You (or your employer) retain the copyright to your contribution; the CLA simply gives us permission to use and redistribute your contributions as part of this project.

If you or your current employer have already signed the Google CLA (even if it was for a different project), you probably don't need to do it again.

Visit https://cla.developers.google.com/ to see your current agreements or to sign a new one.

Review our community guidelines

This project follows Google's Open Source Community Guidelines.

Contribution process

Code reviews

All submissions, including submissions by project members, require review. We use GitHub pull requests for this purpose. Consult GitHub Help for more information on using pull requests.

The preferred approach for submitting pull requests is for developers to fork the OpenFermion GitHub repository and then use a git branch from the fork to create a pull request to the main OpenFermion repo.

Development environment setup

Please refer to the section Developer install of the installation instructions for information about how to set up a local copy of the software for development.

Tests and test coverage

Existing tests must continue to pass (or be updated) when changes are introduced, and code should be covered by tests. We use pytest to run our tests and pytest-cov to compute coverage. We use the scripts ./check/pytest and ./check/pytest-and-incremental-coverage to run these programs with custom configurations for this project.

We don't require 100% coverage, but any uncovered code must be annotated with # pragma: no cover. To ignore coverage of a single line, place # pragma: no cover at the end of the line. To ignore coverage for an entire block, start the block with a # pragma: no cover comment on its own line.

Lint

Code should meet common style standards for Python and be free of error-prone constructs. We use Pylint to check for code lint, and the script ./check/pylint to run it. When Pylint produces a false positive, it can be silenced with annotations. For example, the annotation # pylint: disable=unused-import would silence a warning about an unused import.

Types

Code should have type annotations. We use mypy to check that type annotations are correct, and the script ./check/mypy to run it. When type checking produces a false positive, it can be silenced with annotations such as # type: ignore.