Hi there! We're thrilled that you'd like to contribute to this project. Your help is essential for keeping it great.
Please note that this project is released with a Code of Conduct. By participating in this project you agree to abide by its terms.
Either you faced an issue or have an new idea that would be nice to have, Issues is the right place to start with.
PRs are always welcome and can be a quick way to get your fix or improvement slated for the next release.
In general, we follow the "fork-and-pull" Git workflow
- Fork the repository to your own GitHub account
- Clone the project to your machine
- Create a branch locally with a succinct but descriptive name
- Commit changes to the branch
- Follow any guidelines specific to this repository
- Push changes to your fork
- Open a PR in our repository and follow the PR template so that we can efficiently review the changes.
When opening a pull request, consider the following:
You should be clear about which problem you're trying to solve with your contribution. For example:
Add a link to code of conduct in README.md
This doesn't tell anything about why it's being done, unlike
Add a link to code of conduct in README.md because users don't always look in the CONTRIBUTING.md
This tells the problem that you have found, and the pull request shows the action you have taken to solve it.
The same principle applies to the commit body.
- It follows the provided template
- There are no spelling mistakes
- It follows the conventional commits specification
As a main branch we use master branch. All changes directly go to the main branch from where we have beta build per each commit.
Our maintainers look at pull requests on a regular basis, and the process follows some simple steps:
- Assign
Farfetch/maestroteam for review - Wait for comments/suggestion from auto assigned reviewers. (It generally done within few workdays)
- Get 2 approvals to get PR merged
Note: We close Pull requests without any activities within 2 weeks.
Releases are made in bi-weekly basics from the master branch by our maintainers, regardless of the number of features or fixes.
For release preparation we have milestones created to have visibility on what is in progress right now.
If you are interested in testing out any features that are still not part of release, we do publish of Beta per each commit to main branch. Publish is generally made to Docker registry by using tag beta-<shot-commit-sha>
If you want to deep dive and help out with development, then first get the project installed locally. After that is done we suggest you have a look at issues that are labelled "good first issue". These are meant to be a great way to get a smooth start and won’t put you in front of the most complex parts of the system.
By sending us your contributions, you are agreeing that your contribution is made subject to the terms of our Contributor Ownership Statement