NASA logo
ACROSS

Contributing

So you'd like to contribute to the ACROSS Project? Below are some guidelines for contributors to follow. Contributions come in all shapes and sizes. Help is appreciated with documentation, unit tests, framework code, continuous-integration, or simply reporting bugs and improvement ideas. The ACROSS team cannot promise to accept every suggestion or bugfix, but will look into each contribution with careful consideration.

Code of Conduct

This project and everyone participating in it is governed by the ACROSS Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to the product team.

Ways to Contribute

Bug Reports

Before Reporting a Bug
  1. Perform a cursory search to see if the bug has already been reported. If a bug has been reported and the issue is still open, add a comment to the existing issue instead of opening a new one.
Reporting a Bug

If a bug is found, don't hesitate to report it:

  1. Open an issue using the bug report template in the repective git-hub repository
  2. Describe the issue.
  3. Describe the expected behavior if the bug did not occur.
  4. Provide the reproduction steps that someone else can follow to recreate the bug or error on their own.
  5. If applicable, add code snippets or references to the software.
  6. Provide the system the bug was observed on including the hardware, operating system, and versions.
  7. Provide any additional context if applicable.
  8. Provide your full name or GitHub username and your company organization if applicable.
What Happens to my Bug Report?
  1. The ACROSS team will label the issue.
  2. A team member will try to reproduce the issue with your provided steps. If the team is able to reproduce the issue, the issue will be left to be implemented by someone.

New Feature Requests

ACROSS has a multitude of users from different fields and backgrounds. Feature enhancement ideas from the community are always welcome!

Requesting a New Feature
  1. Open an issue using the feature request template.
  2. Describe the feature.
  3. Describe the solution you would like.
  4. Describe alternatives you've considered.
  5. Provide any additional context if applicable.
  6. Provide your company organization if applicable.
What Happens to my Feature Request?
  1. The project team will label the issue.
  2. The project team will evaluate the feature request, possibly asking you more questions to understand its purpose and any relevant requirements. If the issue is closed, the team will convey their reasoning and suggest an alternative path forward.
  3. If the feature request is accepted, it will be marked for implementation.

Pull Requests

Before starting your Pull Request

Ready to Add Your Code? Follow GitHub's fork-branch-pull request pattern.

  1. Fork the respective git-hub repository.
  2. Find the related issue number or create an associated issue that explains the intent of your new code.
  3. Create a new branch in your fork to work on your fix. Branch names follow the following format: ISSUE_NUMBER-<ISSUE_TITLE>.

    For example, an issue #123 titled "add my new feature to do cool thing" will be 123-add-my-new-feature-to-do-cool-thing.

  4. Add commits to your branch. For information on commit messages, review conventional commits.
Creating a Pull Request
Significant new features require design review before development begins. If your PR introduces a substantial new feature, the ACROSS team strongly recommends opening a discussion or issue to go through a design review and receive approval from the team before writing any code. Pull requests for unapproved features may not be actively monitored or reviewed, and there is no guarantee of acceptance.

When you are ready to create a PR follow the Pull Request template instructions, below is a brief summary of the information needed in a PR. It is recommended to create a pull-request as a "draft" and to commit early and often so the community can give you feedback at the beginning stages of your contribution.

  1. For the title, use conventional commits.
  2. Describe the contribution. First document which issue number was fixed using the template "Fix #XYZ". Then describe the contribution.
  3. Provide what testing was used to confirm the pull request resolves the linked issue. If writing new code, also provide the associated coverage unit tests.
  4. Provide the expected behavior changes of the pull request.
  5. Provide any additional context if applicable.
  6. Verify that the PR passes all workflow checks. If you expect some of these checks to fail, please note it in the Pull Request text or comments.
What Happens to My Pull Request?
  1. The ACROSS team will label and evaluate the pull request in their weekly stakeholder meetings.
  2. If the pull request is accepted, it will be merged into the ACROSS repository.