Skip to content

Latest commit

 

History

History
151 lines (107 loc) · 5.09 KB

CONTRIBUTING.rst

File metadata and controls

151 lines (107 loc) · 5.09 KB
Raw

Contributing

We appreciate all kinds of help, so thank you!

Contributing to the project

You can contribute in many ways to this project.

Issue reporting

This is a good point to start, when you find a problem please add it to the issue tracker. The ideal report should include the steps to reproduce it.

Doubts solving

To help less advanced users is another wonderful way to start. You can help us close some opened issues. This kind of tickets should be labeled as question.

Improvement proposal

If you have an idea for a new feature please open a ticket labeled as enhancement. If you could also add a piece of code with the idea or a partial implementation it would be awesome.

Contributor License Agreement

We'd love to accept your code! Before we can, we have to get a few legal requirements sorted out. By signing a contributor license agreement (CLA), we ensure that the community is free to use your contributions.

When you contribute to the Qiskit project with a new pull request, a bot will evaluate whether you have signed the CLA. If required, the bot will comment on the pull request, including a link to accept the agreement. The individual CLA document is available for review as a PDF.

NOTE: If you work for a company that wants to allow you to contribute your work, then you'll need to sign a corporate CLA and email it to us at qiskit@us.ibm.com.

Code

This section include some tips that will help you to push source code.

Style guide

Please submit clean code and please make effort to follow existing conventions in order to keep it as readable as possible. We use Pylint and PEP 8 style guide.

Good first contributions

You are welcome to contribute wherever in the code you want to, of course, but we recommend taking a look at the "Good first contribution" label into the issues and pick one. We would love to mentor you!

Doc

Review the parts of the documentation regarding the new changes and update it if it's needed.

Pull requests

We use GitHub pull requests to accept the contributions.

A friendly reminder! We'd love to have a previous discussion about the best way to implement the feature/bug you are contributing with. This is a good way to improve code quality in our beloved SDK!, so remember to file a new Issue before starting to code for a solution.

So after having discussed the best way to land your changes into the codebase, you are ready to start coding (yay!). We have two options here:

  1. You think your implementation doesn't introduce a lot of code, right?. Ok, no problem, you are all set to create the PR once you have finished coding. We are waiting for it!
  2. Your implementation does introduce many things in the codebase. That sounds great! Thanks!. In this case you can start coding and create a PR with the word: [WIP] as a prefix of the description. This means "Work In Progress", and allow reviewers to make micro reviews from time to time without waiting to the big and final solution... otherwise, it would make reviewing and coming changes pretty difficult to accomplish. The reviewer will remove the [WIP] prefix from the description once the PR is ready to merge.

Please follow the next rules for the commit messages:

  • It should include a reference to the issue ID in the first line of the commit, and a brief description of the issue, so everybody knows what this ID actually refers to without wasting to much time on following the link to the issue.
  • It should provide enough information for a reviewer to understand the changes and their relation to the rest of the code.

A good example:

Issue #190: Short summary of the issue
* One of the important changes
* Another important change

A (really) bad example:

Fixes #190

Documentation

The documentation for the project is in the doc directory. The documentation for the python SDK is auto-generated from python docstrings using Sphinx for generating the documentation. Please follow Google's Python Style Guide for docstrings. A good example of the style can also be found with sphinx's napolean converter documentation.

To generate the documentation, we need to invoke CMake first in order to generate all specific files for our current platform.

See the previous Building section for details on how to run CMake. Once CMake is invoked, all configuration files are in place, so we can build the documentation running this command:

All platforms:

$> cd out
doc$> make doc