Skip to content

Latest commit

 

History

History
53 lines (40 loc) · 3.88 KB

CONTRIBUTING.md

File metadata and controls

53 lines (40 loc) · 3.88 KB
Raw

Contributing to SuperNOVAS

The SuperNOVAS library is for everyone. And, it is developers like you who can make it better. Whether there is a nagging issue you would like to fix, or a new feature you'd like to see, you can make a difference yourself. Make this project a little bit your own, by submitting pull requests with fixes and enhancement. When you are ready, here are the typical steps for contributing to the project:

  1. Old or new Issue? Whether you just found a bug, or you are missing a much needed feature, start by checking open (and closed) Issues. If an existing issue seems like a good match to yours, feel free to speak up, comment, or to offer help in resolving it. If you find no issues that match, go ahead and create a new one.

  2. Fork. Is it something you'd like to help resolve? Great! You should start by creating your own fork of the repository so you can work freely on your solution. I recommend that you place your work on a branch of your fork, which is named either after the issue number, e.g. issue-192, or some other descriptive name, such as fast-nutations.

  3. Develop. Experiment on your fork/branch freely. If you run into a dead-end, you can always abandon it (which is why branches are great) and start anew. You can run your own tests locally using make test before committing your changes. If the tests pass, you should also try running make all and to ensure that all components of the package and its API documentation are also in order. Remember to synchronize your main branch by fetching changes from upstream every once in a while, and merging them into your development branch. Don't forget to:

    • Add doxygen markup your new code. You can keep it sweet and simple, but make sure it properly explains your globally exposed functions, their arguments and return values. You should also cross-reference other functions / constants that are similar, related, or relevant to what you just added.

    • Add Unit Tests. Make sure your new code has as close to full unit test coverage as possible. You can add tests to test/src/test.c as appropriate, and if you add new source files, you may need to adjust test/Makefile so that gcov coverage is generated for your new source files. You should aim for 100% diff coverage. When pushing changes to your fork, you can get a coverage report by checking the Github Actions result of your commit (click the Coveralls link), and you can analyze what line(s) of code need to have tests added. Try to create tests that are simple but meaningful (i.e. check for valid results, rather than just confirm existing behavior), and try to cover as many realistic scenarios as appropriate. Write lots of tests if you need to.

  4. Pull Request. Once you feel your work can be integrated, create a pull request from your fork/branch. You can do that easily from the github page of your fork/branch directly. In the pull request, provide a concise description of what you added or changed. Your pull request will be reviewed. You may get some feedback at this point, and maybe there will be discussions about possible improvements or regressions etc. It's a good thing too, and your changes will likely end up with added polish as a result. You can be all the more proud of it in the end!

  5. If all goes well, your pull-request will get merged, and will be included in the upcoming release of SuperNOVAS. Congratulations for your excellent work, and many thanks for dedicating some of your time for making this library a little bit better. There will be many who will appreciate it. :-)

If at any point you have questions, or need feedback, don't be afraid to ask. You can put your questions into the issue you found or created, or your pull-request, or as a Q&A in Discussions.