Reviewpad is an open source project to empower teams to automate their development process - issues and pull requests. We believe that teams should be able to contribute to a project the most fast and efficient way. We are very excited to see your interest on how to help us make Reviewpad the best automation tool.
Code of Conduct
Reviewpad projects have a Code of Conduct to which all contributors must adhere. Please read it before interacting with the repository or the community in any way.
All work on Reviewpad happens directly on GitHub. Both core team members and external contributors send pull requests which go through the same review process.
Reviewpad follows semantic versioning. We release patch versions for critical bugfixes, minor versions for new features or non-essential changes, and major versions for any breaking changes. When we make breaking changes, we also introduce deprecation warnings in a minor version so that our users learn about the upcoming changes and migrate their code in advance.
Every significant change is documented in each release.
Submit all changes directly to the
main branch. We don't use separate branches for development or for upcoming releases. We do our best to keep
main in good shape, with all tests passing.
Where to Find Known Issues
We are using GitHub Issues for our bugs. We keep a close eye on this and try to make it clear when we have an internal fix in progress. Before filing a new task, try to make sure your problem doesn't already exist.
Reporting New Issues
The best way to get your bug fixed is fill our bug report template. Please follow the instructions in the template and provide as much information as possible. The more information you provide, the more likely someone will be successful reproducing the bug and finding a fix.
How to Get in Touch
Please note that the Reviewpad Discord is the same used by the team. So you'll be talking directly with the team 💪
Proposing a Change
If you intend to change a piece of Reviewpad that is not yet being addressed on any issue we first invite you to fill an issue. This lets us reach an agreement on your proposal before you put significant effort into it.
If you're only fixing a bug, it's fine to submit a pull request right away but we still recommend to fill an issue detailing what you're fixing. This is helpful in case we don't accept that specific fix but want to keep track of the issue.
Your First Pull Request
Working on your first Pull Request? You can learn how from this free video series:
To help you get your feet wet and get you familiar with our contribution process, we have a list of good first issues that contain bugs that have a relatively limited scope. This is a great place to get started.
If you decide to fix an issue, please be sure to check the comment thread in case somebody is already working on a fix. If nobody is working on it at the moment, please leave a comment stating that you intend to work on it so other people don't accidentally duplicate your effort.
Sending a Pull Request
Before submitting a pull request, please make sure the following is done:
- Fork the repository and create your branch from
go getin the repository root.
- If you've fixed a bug or added code that should be tested, add tests!
- Ensure the test suite passes (
- If you need a debugger, checkout how to run our Reviewpad CLI.
- Format your code(
- Do a final check (
task check -f).
- You have GO installed with minimum version of 1.18.2.
- You have Taskfile installed.
- You have
gccinstalled or are comfortable installing a compiler if needed. Some of our dependencies may require a compilation step. On OS X, the Xcode Command Line Tools will cover this. On Ubuntu,
apt-get install build-essentialwill install the required packages. Similar commands should work on other Linux distros. Windows will require some additional steps, see the
node-gypinstallation instructions for details.
- You are familiar with Git.
After cloning Reviewpad, run
go get to fetch its dependencies.
Then, you can run several commands:
task formatformats your code.
task testruns the complete test suite.
task buildbuilds the project (no output is generated).
task build-cibuilds Reviewpad CLI and creates the executable
task checkruns the code formatter, the complete test suite, and builds the project.
We recommend running
task check -f to make sure you don't introduce any issue.
The easiest way to try your changes is to use Reviewpad CLI
./reviewpad-cli run -u [PULL_REQUEST_URL] -t [GITHUB_TOKEN] -e [GITHUB_EVENT] -f [REVIEWPAD_FILE].
Another great way to test your changes it to use
VSCode debug tool. You can do that by creating a
.vscode folder in the root of the repository, add the file
launch.json to it, and copy the following content into the file:
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"name": "Launch cli",
// Flag to run on dry run
// Absolute path to reviewpad.yml file to run
// GitHub url to run the reviewpad.yml against to
// e.g. https://github.com/reviewpad/reviewpad/pull/1
// e.g. https://github.com/reviewpad/reviewpad/issue/1
// Absolute path to JSON file with GitHub event payload (OPTIONAL)
// GitHub PAT (Personal Access Token)
We still require that your pull request contains unit tests for any new functionality. This way we can ensure that we don't break your code in the future.
As commit convention, we adopt Conventional Commits.
This is not the case for all the commits in the history but any new commit should follow it.
If you want to enforce it as a pre-hook commit, you can use tiger.
We use an automatic code formatter called gofmt.
task format after making any changes to the code.
Then, our formatter will catch most issues that may exist in your code.
By contributing to Reviewpad, you agree that your contributions will be licensed under its LGPL-3.0 license.
This documentation is based on reactjs.org contributing guidelines.