Skip to content

README.md

Latest commit

 

History

History
103 lines (72 loc) · 4.85 KB

README.md

File metadata and controls

103 lines (72 loc) · 4.85 KB

Contributing

Code of Conduct

We are committed to providing a friendly, safe and welcoming environment for all. See our Code of Conduct for details.

How to contribute

All contributions are appreciated! Typo fixes, bug fixes, feature requests, bug reports...

For ideas, proposals and feature request, click here, for all other contributions, read on.

For a good place to start, check out good first issues or reach out on the #contributing channel on our zulip group chat. Before making your first pull request, create a new topic in the contributing channel on zulip to discuss what you plan to do! This can avoid duplicated effort or a rejection because the change doesn't fit with the goals of the language.

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, internships, independent research, or 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:

# This actually runs the tests, it doesn't just build them.
zig build test
zig build fmt

To run a specific test:

zig build test -- --test-filter "name of test"

Contribution Tips

  • If you've never made a pull request on github before, this will be a good place to start.
  • You can find good first issues here. Once you have gained some experience you can take a look at the intermediate issues.
  • 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 important feedback sooner rather than later. Click the button "ready for review" when it's ready.
  • The Glossary file explains terms commonly used in the compiler.

Debugging tips

If you need to do some debugging, check out our tips.

Commit signing

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

⚠️ Tip for NixOS users

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?

❗ Make sure to set up signing on your device first, then continue below.

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!