Before you begin:
- Have you read the code of conduct?
- See if an issue exists for the change you want to make.
- See if we are accepting controbutions for your type of issue.
If you have a change that you would like to make, open an issue using a template. This will be the place to discuss the problem you want to fix.
Fork using GitHub Desktop:
- Getting started with GitHub Desktop will guide you through setting up Desktop.
- Once Desktop is set up, you can use it to fork the repo!
Fork using the command line:
- Fork the repo so that you can make changes without affecting the original project until you are ready to merge them.
Fork with GitHub Codespaces:
- Fork, edit, and preview using GitHub Codespaces without having to install and run the project locally.
Make the changes to the file(s) you'd like to update.
When you're done making changes and you'd like to propose them for review, use the pull request template to open your pull request.
- Once you submit your pull request, others from the Celest community will review it with you. The first thing you're going to want to do is a self-review.
- After that, we may have questions, check back on your pull request to keep up with the conversation.
- Did you have an issue, like a merge conflict? Check out the git tutorial on how to resolve merge conflicts and other issues.
Congratulations! The Celest community thanks you!
Once your pull request is merged, you will proudly be listed as a contributor in the contributor chart.
You can contribute to Celest in several ways.
Issues are used to track tasks that contributors can help with. If an issue hasn't received a reply from a Celest maintainer, then we haven't reviewed the issue yet and you shouldn't begin to work on it.
If you have found something in the code or documentation that should be updated, search open issues to see if someone else has reported the same thing. If it's something new, open an issue using a template. We'll use the issue to have a conversation about the problem you want to fix.
A pull request is a way to suggest changes in our repository.
When we merge those changes to the current develop branch, they will be deployed in the upcoming Celest release. To learn more about opening a pull request in this repo, see Opening a Pull Request below.
We are a small team working hard to keep up with the demands of a continuously changing product. Unfortunately, we just can't help with support questions in this repository. If you are experiencing a problem with GitHub, unrelated to Celest, please contact GitHub Support directly. Any issues, discussions, or pull requests opened here requesting support will be given information about how to contact GitHub Support, then closed and locked.
If you're having trouble with your GitHub account, contact Support.
You can browse existing issues to find something that needs help!
Labels can help you find an issue you'd like to help with.
- The bug label is for problems where something isn't working.
- The documentation label is for improvements or additions to documentation.
- The duplicate label is for any issue or pull request that already exists.
- The enhancement label is for a new feature or request.
- The good first issue label is a good issue for first-time contributors to work on.
- The help wanted label means extra attention is needed to the issue.
- The invalid label is for issues where there appear to be invalid results.
- The question label is to request further information.
- The wontfix label indicates the issue will not be worked on.
You can use the GitHub user interface for small changes like fixing a typo or updating a readme. You can also fork the repo and then clone it locally, to view changes and run your tests on your machine.
We review every single pull request. The purpose of reviews is to create the best content we can for people who use Celest.
- Reviews are always respectful, acknowledging that everyone did the best possible job with the knowledge that they had at the time.
- Reviews discuss content, not the person who created it.
- Reviews are constructive and start conversations around feedback.
You should always review your pull request first.
For code changes, make sure that you:
- Confirm that the changes meet the user experience and goals outlined in the content design plan (if there is one).
- Ensure that technical changes are validated against a truth. Proof of validation for non-trivial outputs will need to be presented before a pull request is approved for merging.
- Copy-edit the added documentation for grammar, spelling, and adherence to the style guide.
- If there are any failing checks in your pull request, troubleshoot them until they're all passing.
For all code additions, it is encouraged to:
- Type annotate new function and methods.
- Ensure code meets the PEP8 style guide. A useful online checker that will point out a number of PEP8 infractions can be found here.
- Ensure documentation strings are created or updated per Numpy's style guide.
When ready to open a pull request on your issue, fill out the pull request template to ensure adequate information is incorporated for faster code reviews.
We may ask for changes to be made before a pull request can be merged, either using pull request comments. You can apply suggested changes directly through the UI. You can make any other changes in your fork, then commit them to your branch.
As you update your pull request and apply changes, mark each conversation as resolved.