We would love for you to contribute to Mapperly and help make it even better than it is today! As a contributor, here are the guidelines we would like you to follow.
Code of Conduct
Help us keep OpenThread open and inclusive. Please read and follow our code of conduct.
Got a question or problem?
If you have a question or a problem create a new GitHub Discussion.
Found a Bug?
Missing a Feature?
You can request a new feature by submitting an issue to our GitHub repository. If you would like to implement a new feature, please consider the size of the change in order to determine the right steps to proceed:
For a major feature, first open an issue and outline your proposal so that it can be discussed. Getting early feedback will help ensure your implementation work is accepted by the maintainers. This will also allow us to better coordinate our efforts and minimize duplicated effort.
Note: Adding a new topic to the documentation, or significantly re-writing a topic, counts as a major feature.
Small Features can be crafted and directly submitted as a Pull Request.
Submitting an issue
Before you submit an issue, please search the issue tracker and discussions. An issue for your problem might already exist and the discussion might inform you of workarounds readily available.
You can file new issues by filling out the new issue template.
Submitting a pull request (PR)
Before you submit your Pull Request (PR) consider the following guidelines:
Search GitHub for an open or closed PR that relates to your submission. You don't want to duplicate existing efforts.
Be sure that an issue describes the problem you're fixing, or documents the design for the feature you'd like to add. Discussing the design upfront helps to ensure that we're ready to accept your work.
Get an overview on how Mapperly works by reading this contributing documentation, the architectural overview and related documentation.
Fork the riok/mapperly repository.
In your forked repository, make your changes in a new git branch:
git checkout -b my-fix-branch main
Commit your changes using a descriptive commit message that follows our commit message conventions. Adherence to these conventions is necessary because release notes are automatically generated from these messages. Husky and csharpier automatically format changed files when commited.
git commit --all
Note: the optional commit
-acommand-line option will automatically "add" and "rm" edited files.
If any commits have been made to the upstream main branch, you should rebase your development branch so that merging it will be a simple fast-forward that won't require any conflict resolution work.
git checkout main
git pull upstream main
git checkout my-fix-branch
git rebase main
Now, it may be desirable to squash some of your smaller commits down into a small number of larger more cohesive commits. You can do this with an interactive rebase:
# Rebase all commits on your development branch
git rebase -i main
Push your branch to GitHub:
git push origin my-fix-branch
In GitHub, send a pull request to
riok:mainand request a review from a maintainer.
Once you've submitted a pull request, all continuous-integration checks are triggered. If some of these checks fail, it could be either problems with the pull request or a failure of some test cases. For more information on the failure, check the output logs of the jobs.
Reviewing a pull request
The reviewers will provide you feedback and approve your changes as soon as they are satisfied. If we ask you for changes in the code, you can follow the GitHub Guide to incorporate feedback in your pull request.
Commit message format
Make sure you use conventional commit message format.
<type>: <short summary>
Must be one of the following:
- feat: New Feature
- fix: Bugfix
- docs: Documentation
- chore: Chores which should not lead to a changelog / release notes entry