Skip to content

Latest commit

 

History

History
77 lines (57 loc) · 4.6 KB

CONTRIBUTING.md

File metadata and controls

77 lines (57 loc) · 4.6 KB
Raw

Overview

Thank you for investing your time in contributing to our project! There are numbers of ways to contribute to the project and we appreciate all of them. If you like the project please give Clad a star.

Any contribution to open source makes a difference!

Are you new to open source, git or GitHub?

To get an overview of the project, read the README. Here are some resources to help you get started with open source contributions:

Are you a contributor looking for a challenging summer project?

Various opportunities such as information about google summer of code is generally published on Clad's Wiki page. If you have used Clad and you have particular project proposal please reach out.

Ways to contribute

Submit a bug report

If something does not seem right search if an issue already exists in Clads issue tracker. If a related issue doesn't exist, you can open a new issue using a relevant issue form.

Good first issues

Some issues have been marked as "good first issues". These are intended to be a good place to start contributing.

Write documentation

Documentation is critical for any open source project, especially for complex projects such as Clad. We have our documentation in the repository which is then rendered in the clad.readthedocs website. Documentation modifications happen by proposing a pull request.

Creating a successfull pull request

To propose a code modification we use the pull requests. Pull requests which review quickly and successfully share several common traits:

  • Sharp -- intends to fix a concrete problem. Usually the pull request addresses has an already opened issue;
  • Atomic -- has one or more commits that can be reverted without any unwanted side effects or regressions, aside from what you’d expect based on its message. More on atomic commits in git.
  • Descriptive -- has a good description in what is being solved. This information is usually published as part of the pull request description and as part of the commit message. Writing good commit messages are critical. More here and here. If your pull request fixes an existing issue from the bug tracker make sure that the commit log and the pull request description mentions Fixes: #<ISSUE_NUMBER>. That will link both and will close the issue automatically upon merging.
  • Tested -- has a set of tests making sure that the issue will not resurface without a notice. Usually the codecov bots annotate the code paths that are not tested in the pull request after being run.
  • Documented -- has good amount of code comment. The test cases are also a good source of documentation. Here is a guideline about how write good code comments. Here are examples of what not to write as a code comment.

Developer Documentation

We have documented several useful hints that usually help when addressing issues as they come during developement time in our developer documentation.

In case you are interested in seeing the big picture and are just getting started with Clang, there is a document that might interest you: Introduction to Clang for Clad contributors. It covers most of the basic concepts in Clang that Clad uses and describes the operation of the latter with examples for newcomers specifically.