Skip to content

Latest commit

 

History

History
118 lines (80 loc) · 3.53 KB

CONTRIBUTING.rst

File metadata and controls

118 lines (80 loc) · 3.53 KB

Contributing

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

The Github forking workflow is used for submitting proposals for change to this repo. The following sections will give a brief overview of how this repo utilizes the workflow for managing community contributions.

Setup Development Environment

Refer the the Developer Quick Start Guide documentation for more details on setting up a development environment.

Setup Fork & Local Feature Branch

First step is to fork this repo!

Once a fork has been created, follow these steps to make a local clone and create a feature branch:

  1. Clone your fork locally:

    $ git clone [email protected]:your_name_here/flask-ligand.git

  2. Setup develop environment:

    $ cd flask-ligand/
$ make develop-venv # OR 'make develop' if you're not using virtualenvwrapper

  3. Create a branch for local development:

    $ git checkout -b name-of-your-bugfix-or-feature

Pull Request Guidelines

Run All the Tests

Before creating a commit it is essential that the changes be tested first. Also, make sure to write appropriate tests for the change you'll be proposing in the pull request!

Simply execute the following make target to run tests against all supported Python versions:

$ make test-tox

Commit Message Formatting

This repo utilizes python-semantic-release with the emoji commit parser configuration enabled. The type of change being proposed in the commit must be in brackets in the commit subject which is expressed as an emoji which represents one of the following semantic versioning change concepts:

Major:

  • 💥

Minor:

  • ✨
  • 🚸
  • 💄
  • 📱
  • 🥚
  • 📈

Patch:

  • 🚑
  • 🔒
  • 🐛
  • ⚡
  • 🥅
  • 👽
  • ♿
  • 💬
  • 🔍
  • 🍎
  • 🐧
  • 🏁
  • 🤖
  • 🍏

The body of the commit message should give a succinct description of what is being changed and why.

Example:

[:ambulance:] Fix Broken Thing

The thing feature was broken in the last release because of a typo.

DOCUMENTATION UPDATES REQUIRE A SEMANTIC VERSION!!!

Regardless of how minor a documentation change might be that in no way affects the code base, it still requires that a semantic version be attached to the commit! Otherwise the "Read the Docs" build will fail and not publish the documentation!

Create the Pull Request on GitHub

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

  1. The pull request should include tests. (Not looking for 100% coverage, but a sufficient level of testing)
  2. If the pull request adds functionality, the docs should be updated.
  3. Check GitHub Actions to make sure that all tests pass for all supported Python versions before requesting a PR review.