roc/CONTRIBUTING.md

Contributing

Code of Conduct

We are committed to providing a friendly, safe and welcoming environment for all. Make sure to take a look at the Code of Conduct!

How to contribute

All contributions are appreciated! Typo fixes, bug fixes, feature requests, bug reports are all helpful for the project.

If you are looking for a good place to start, consider reaching out on the #contributing channel on Roc Zulip. Before making your first pull request, definitely talk to an existing contributor on Roc Zulip first about what you plan to do! This can not only avoid duplicated effort, it can also avoid making a whole PR only to discover it won't be accepted because the change doesn't fit with the goals of the language's design or implementation.

If you are interested in larger, implementation- or research-heavy projects related to Roc, check out Roc Project Ideas and reach out to us on Zulip! These projects may be suitable for academic theses, independent research, or even just valuable projects to learn from and improve Roc with.

Building from Source

Check Building from source for instructions.

Running Tests

Most contributors execute the following commands before pushing their code:

cargo test
cargo fmt --all -- --check
cargo clippy --workspace --tests -- --deny warnings

Execute cargo fmt --all to fix the formatting.

Generating Docs

If you make changes to Roc's Standard Library, you can add comments to the code following the CommonMark Spec to further explain your intentions. You can view these changes locally with:

cargo run docs crates/compiler/builtins/roc/main.roc

This command will generate the documentation in the generated-docs directory.

Contribution Tips

• If you've never made a pull request on github before, this will be a good place to start.
• Create an issue if the purpose of a struct/field/type/function/... is not immediately clear from its name or nearby comments.
• You can find good first issues here. Once you have gained some experience you can take a look at the intermediate issues.
• Fork the repo so that you can apply your changes first on your own copy of the roc repo.
• It's a good idea to open a draft pull request as you begin working on something. This way, others can see that you're working on it, which avoids duplicate effort, and others can give feedback sooner rather than later if they notice a problem in the direction things are going. Click the button "ready for review" when it's ready.

Commit signing

All your commits need to be signed to prevent impersonation. Check out our guide for commit signing.

Commit signing on NixOS

On NixOS pinentry can cause problems, the following setup works well for those with a KDE desktop. From /etc/nixos/configuration.nix:

programs.gnupg.agent = {
    enable = true;
    pinentryFlavor = "qt";
    enableSSHSupport = true;
  };

Forgot to sign commits?

You can view your commits on github, those without the "Verified" badge still need to be signed. If any of those is a merge commit, follow these steps instead of the ones below.

If you have only one commit, running git commit --amend --no-edit -S would sign the latest commit 🚀.

In case you have multiple commits, you can sign them in two ways:

1. Switching to interactive rebase mode and editing the file:
   • Enter into interactive mode, by running git rebase -i HEAD~n where n is the number of commits up to the most current commit you would like to see.
   • This would display a set of commits in a text file like below:

     pick hash2 commit message 2
     pick hash1 commit message 1
     

   • On a new line below a commit you want to sign, add exec git commit --amend --no-edit -S. Do this for all your unsigned commits.
2. Or run git rebase recursively:
   • Find the oldest commit you want to sign, using the git log --show-signature command.
   • Run the command git rebase --exec 'git commit --amend --no-edit -n -S' -i HASH which would sign all commits up to commit HASH.

If you already pushed unsigned commits, you may have to do a force push with git push origin -f <branch_name>.

Can we do better?

Feel free to open an issue if you think this document can be improved or is unclear in any way.