If you've taken an interest in this project, then hooray for our shared interest in physics. Please read this document to better understand what kinds of contributions are helpful to us.
- How to file a bug report
- How to suggest a new feature
- How to set up your environment and run tests
- The types of contributions we're looking for
- Our vision for the project
- Code styles
To file a bug report, visit the Issues page, and search if the bug has already been reported. If it has not, then open a new issue, giving a short, descriptive title explaining the bug. From there, you will get a template file that outlines how to describe your bug and what information we are looking for when you submit it.
Same as filing a bug report, open a new Issue and follow the guidelines in the template.
Presently, the Visual Studio 2017 IDE is the only supported environment. Users are encouraged to suggest new environments in our Issues section.
The following contributions are greatly supported:
- Unit/Benchmark tests
- Source code documentation
- Bug fixes
- Cross-platform support
- Cross-IDE support
- Issue closers
Below are some things we think wouldn't be helpful for contributions
- Saying "I can't build on my computer" without providing details on what you tried, citing the README and the CONTRIBUTING file.
- Submitting a pull request with no description of what the code does. Even if it's a typo fix, mention that it's a typo fix.
- Submitting a pull request without opening an Issue first. Every pull request should be a solution to an existing issue. For very trivial things like typos, this is an exception. However, one line bug fix patches should still have an issue open to address the bug.
- Submitting a bug fix without an accompanying unit test to catch the bug from now on (except in cases of bugs that were typos e.g.
if (x = true)toif (x == true). - Requesting a feature that is far outside the scope of this project.
This is a simple project that pulls RA/Dec sources from source lists and does a bunch of stat stuff to them. Honestly, its scope extends to whatever I need it to do. I'd like to keep it simple but it's so easy to make a simple project become big.
Refer to our CODE STYLES guide for an in-depth discussion on how to write your code for this project.
This article does a great job describing the value of a formatted git commit message. The things to take away from it are
- Separate subject from body with a blank line
- Limit the subject line to 50 characters
- Capitalize the subject line
- Do not end the subject line with a period
- Use the imperative mood in the subject line
- Wrap the body at 72 characters
- Use the body to explain what and why vs. how
Try to comply to these rules as much as possible.