Skip to content

Latest commit

 

History

History
123 lines (82 loc) · 3.87 KB

CONTRIBUTING.md

File metadata and controls

123 lines (82 loc) · 3.87 KB
Raw

Contributing

Contributions are welcome, and they are greatly appreciated! Every little bit helps, and credit will always be given.

You can contribute in many ways:

Types of Contributions

Report Bugs

Report bugs at https://github.com/equinor/warmth/issues.

If you are reporting a bug, please include:

  • Your operating system name and version.
  • warmth version
  • Detailed steps to reproduce the bug.

Fix Bugs

Look through the Git issues for bugs. Anything tagged with "bug" and "help wanted" is open to whoever wants to implement it.

Implement Features

Look through the Git issues for features. Anything tagged with "enhancement" and "help wanted" is open to whoever wants to implement it.

Write Documentation

We could always use more documentation, whether as part of the official docs, in docstrings, or even on the web in blog posts, articles, and such.

Submit Feedback

The best way to send feedback is to file an issue at https://github.com/equinor/warmth/issues.

If you are proposing a feature:

  • Explain in detail how it would work.
  • Keep the scope as narrow as possible, to make it easier to implement.

Get Started!

Ready to contribute? Here's how to set up warmth for local development.

  1. Fork the warmth repo on Github equinor to your personal user

  2. Clone your fork locally

  3. Start the development container. Info

  4. Create a branch for local development:

  5. Make your changes locally.

  6. When you're done making changes, check that your changes pass flake8 and the tests

poetry run flake8 . --count --select=E9,F63,F7,F82 --show-source --statistics --exclude=docs
poetry run pytest --cov-report=term-missing --cov=warmth tests/ | tee pytest-coverage.txt
  1. Commit your changes and push your branch
  2. Submit a pull request.

Writing commit messages

Commit messages should be clear and follow a few basic rules. Example:

    ENH: add functionality X to numpy.<submodule>.

The first line of the commit message starts with a capitalized acronym (options listed below) indicating what type of commit this is. Then a blank line, then more text if needed. Lines shouldn't be longer than 72 characters. If the commit is related to a ticket, indicate that with "See #3456", "Cf. #3344, "See ticket 3456", "Closes #3456" or similar.

Read Chris Beams hints on commit messages https://chris.beams.io/posts/git-commit/.

Describing the motivation for a change, the nature of a bug for bug fixes or some details on what an enhancement does are also good to include in a commit message. Messages should be understandable without looking at the code changes. A commit message like FIX: fix another one is an example of what not to do; the reader has to go look for context elsewhere.

Standard acronyms to start the commit message with are:

    API: an (incompatible) API change (will be rare)
    PERF: performance or bench-marking
    BLD: change related to building
    BUG: bug fix
    FIX: fixes wrt to technical issues, e.g. wrong requirements.txt
    DEP: deprecate something, or remove a deprecated object
    DOC: documentation, addition, updates
    ENH: enhancement, new functionality
    CLN: code cleanup, maintenance commit (refactoring, typos, PEP, etc.)
    REV: revert an earlier commit
    TST: addition or modification of tests
    REL: related to release

Type hints

PEP 484

Docstrings

Numpy

Style guidelines

PEP 8

Pull Request Guidelines

Before you submit a pull request, check that it meets these guidelines:

  1. The pull request should include tests.
  2. If the pull request adds functionality, the docstrings and/or docs should be updated.