Skip to content

Contributing.md

Latest commit

 

History

History
147 lines (102 loc) · 7.97 KB

Contributing.md

File metadata and controls

147 lines (102 loc) · 7.97 KB

Contributing to Aerospace Working Group

Thank you for your interest in contributing! We appreciate your help in making this project better. Please follow the guidelines below to ensure a smooth contribution process.

Code of Conduct

The ELISA Project involves participation by industry competitors, and it is the intention of the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to agendas(e.g. topics), and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal, or foreign antitrust and competition laws. Linux Foundation Antitrust Policy

The collaboration in this project is exploratory. The opinions expressed by participants are not necessarily the policy of the companies.

No recordings of working group meetings are permitted. Special provisions may be arranged for recording in advance with explicit consent of the participants.

The kernel and LF Code of Conduct applies to all communication with this project

How to Contribute

  1. Fork the repository.
  2. Create a new branch for your feature or bug fix.
  3. Make your changes.
  4. Write tests for your changes (if applicable).
  5. Ensure all tests pass.
  6. Attend a working group meeting to discuss

Reporting Issues

If you find a bug or have a feature request, please open an issue in the repository. Be sure to include as much detail as possible.

Submitting Changes

When you're ready to submit your changes, please create a pull request. Include a description of your changes and reference any related issues.

Style Guide

Please follow the project's coding style enforced by the lint checks on your pull request. If an exception is needed, note that in the pull request details.

The super linter project is one option to help with consistency and security of repository content. The following can be setup locally to lint material before pushing to the repository (this assumes the defaults in the configuration env file.) This hook isn't a default so re-cloning the repository would require you to again setup the hook.

# Run once after checkout to setup the hook
cat > .git/hooks/pre-push <<'EOM'
#!/bin/sh

# Run the super-linter Docker container as a pre-push hook

echo "Running Super-Linter via Docker pre-push hook..."
docker run -e RUN_LOCAL=true -e LOG_LEVEL=ERROR --env-file "./.github/super-linter.env" -v "$(pwd)":/tmp/lint --rm ghcr.io/super-linter/super-linter:latest

# Check the exit status of the docker command.
# If it is non-zero, the linter failed and the push should be aborted.
if [ $? -ne 0 ]; then
  echo "Super-Linter failed. Push aborted."
  exit 1
else
  echo "Super-Linter passed. Proceeding with push."
  exit 0
fi
EOM
chmod +x .git/hooks/pre-push

License

By contributing, you agree that your contributions will be licensed under the project's license.. If approval for an alternate license or licenses for inbound or outbound contributions is required, note this in your pull request with the following details. A TSC call would need to consider this and provide feedback on an exception. A two-thirds vote is required by the TSC, see the charter for the official guidance on these exceptions.

For exceptions as part of your pull request:

  1. Describe contribution in PR description
  • Any alternative open source license(s) options
  • The justification for using an alternative open source license
  1. Add the SPDX tags to your files that need them. (Checkout other files for examples.)
  2. Add a license description file using the docker run --rm --volume $(pwd):/data fsfe/reuse download --all or manually under ./LICENSES/
  3. Add any specific exception clarification language to LICENSE or the specific file(s) under the license header. (Or at least in the GIT commit description that makes the license change.)

For any approved cases, follow the LICENSE guidance:

  1. Noting the license used in the individual files
  2. Verify the license CI workflow on the pull request passes. The results should be listed towards the bottom of the specific pull request page under "Checks."

Email communication will be treated as documentation and be received and made available by the Project under the Creative Commons Attribution 4.0 International License. Please refer to the ELISA Technical Charter section 7 subsection iv..

How to use the license checker

Here's an example of how to locally cleanup licensing on your contribution.

If you need to see what licenses are supported for use with the tool - docker run --rm --volume $(pwd):/data fsfe/reuse supported-licenses

  1. Go to the root of this repository and run docker run --rm --volume $(pwd):/data fsfe/reuse to get a report.
  2. Then if you are "not compliant", either manually add the SPDX headers or use the reuse annotate feature to help you. reuse does have a --recursive option that can be used for folders, however it marks everything.
  • Updating individual markdown files - docker run --rm --volume $(pwd):/data fsfe/reuse annotate --license CC-BY-SA-4.0 <filename>
  • Updating individual code files - docker run --rm --volume $(pwd):/data fsfe/reuse annotate --license MIT <filename>
  • Add details for binary files and items like json - docker run --rm --volume $(pwd):/data fsfe/reuse annotate --license CC-BY-SA-4.0 --fallback-dot-license <filename>
    • This creates a file with a .license suffix that has the SPDX tag
  1. Check again doing (1).

The tool has various features including automatically adding a license descriptions under LICENSE/ if you had a new license type.

Copyright

This project follows the Developer Certificate of Origin approach for any contributions. How to add a contribution sign off.

All content is copyright as follows, unless noted in the individual file. See Linux Foundation copyright guidance for guidance on this top level copyright claim that simplifies the developer workflow (i.e., it uses DCO to associate the claim.)

Copyright (c) The ELISA Aerospace Working Group Authors

Copyright (c) The ELISA Aerospace Working Group Contributors

Copyright (c) Contributors to the ELISA Aerospace Working Group

Note: Please refer to the ELISA Technical Charter section 7 for discussion on Intellectual Property roles related to Author vs Contributor.