Skip to content

Contributing

Code contributions

We accept anything that benefits the community, thanks for sharing your work with the world. We can discuss implementation details here.

Guidelines

  1. Write your idea: here
  2. Fork Makes on GitHub
  3. Git-clone your fork
  4. Hack as much as you like!
  5. Git-commit your changes.
  6. Git-push changes to your fork
  7. Create a Pull Request from your fork to Makes

Testing your local changes

You can run local changes by simply running m . <job>. If you're adding new files, make sure to git add them first.

Adding documentation

  • All changes must be documented in the same PR.
  • You can run m . /docs/dev to serve the docs site on localhost.
  • Make sure you lint the documentation with m . /lintMarkdown/all.

Adding tests

  • All new builtins must be tested.
  • You can add tests to either /makes.nix or /makes/your-builtin/main.nix depending on the nature of the builtin.
  • Make sure to add such tests to the GitHub Actions pipelines as well.

Adding yourself to the mailmap

You must add yourself to the .mailmap file. Make sure to test it with m . /lintGitMailMap.

Writing a valid commit message

  • Your commit message must follow this syntax.
  • You must sign your commits by adding a Signed-off-by line at the end of your commit message.
  • You can take a look at other commits here.
  • Make sure to test it with m . /lintGitCommitMsg.

Other PR rules

A PR must:

  • Only be one commit ahead of main.
  • Have a title and body equal to its commmit message.

Examples

All of the code that you submit to our code repository will be licensed under the MIT license.

Please add a Signed-off-by: Full Name <email> to your commits as explained here to signal that you agree to the terms of the following Developer Certificate of Origin.

Thank you!

Review process

Once a pull request is opened in the repository, a maintainer must follow the following steps to review it:

  1. Check that the proposed change has an associated issue, enough discussion has happened on it, and there is consensus in the implementation details, and if we agree that implement it is a good idea.
  2. Check if the change modifies the Architecture in any way, and that it has been updated.
  3. Check if the implementation follows the Secure Design Principles, and documents there any new interactions, or updates the documentation accordingly.
  4. Check if the implementation introduces new threats, or changes/removes an existing threat, and if the Threat Model documentation has been updated to reflect it.
  5. Check if the change adds or modifies an existing security property of the system, and if the Software Assurance documentation has been updated to reflect it.
  6. Check if the CI/CD succeeded. No job should fail unless something unrelated to the pull request happened.
  7. The Developer Certificate of Origin was accepted, normally through checking that the job in the CI/CD that verifies it succeeded.
  8. The steps mentioned in the sections above were followed, particularly check if the code is readable, maintainable, proper tests were added or updated, the corresponding docs were added or updated, and the architecture and design seems to be of good quality.