This guide aims to walk you through the process of working on issues and Pull Requests (PRs).
Bear in mind that you will not be able to complete some steps on your own if you do not have a “write” permission. Feel free to reach out to the maintainers to help you unlock these activities.
Please note that we have a code of conduct (CODE-OF-CONDUCT.md). Make sure that you follow it in all of your interactions with the project.
There are two options to look for the issues to contribute to.
The first is our "Up for grabs" board. There the issues are sorted by a required experience level (beginner, intermediate, expert).
The second option is to search for "good first issue"-labeled issues. Some of them might not be displayed on the aforementioned board, or vice versa.
You also need to consider labels. You can sort the issues by scope labels, such as scope/backend, scope/frontend or even scope/k8s. If any issue covers several specific areas, and you do not have a required expertise for one of them, just do your part of work — others will do the rest.
There is a bunch of criteria that make an issue feasible for development.
The implementation of any features and/or their enhancements should be reasonable, must be backed by justified requirements (demanded by the community, roadmap plans, etc.). The final decision is left for the maintainers' discretion.
All bugs should be confirmed as such (i.e. the behavior is unintended).
Any issue should be properly triaged by the maintainers beforehand, which includes:
- Having a proper milestone set
- Having required labels assigned: accepted label, scope labels, etc.
Formally, if these triage conditions are met, you can start to work on the issue.
With all these requirements met, feel free to pick the issue you want. Reach out to the maintainers if you have any questions.
Every issue “in-progress” needs to be assigned to a corresponding person. To keep the status of the issue clear to everyone, please keep the card's status updated ("project" card to the right of the issue should match the milestone’s name).
Please refer to this guide.
In order to keep branch names uniform and easy-to-understand, please use the following conventions for branch naming.
Generally speaking, it is a good idea to add a group/type prefix to a branch; e.g.,
if you are working on a specific branch, you could name it issues/xxx.
Here is a list of good examples:
issues/123
feature/feature_name
bugfix/fix_thing
Java: There is a file called checkstyle.xml in project root under etc directory.
You can import it into IntelliJ IDEA via Checkstyle plugin.
REST paths should be written in lowercase and consist of plural nouns only.
Also, multiple words that are placed in a single path segment should be divided by a hyphen (-).
Query variable names should be formatted in camelCase.
Model names should consist of plural nouns only and should be formatted in camelCase as well.
When creating a PR please do the following:
- In commit messages use these closing keywords.
- Link an issue(-s) via "linked issues" block.
- Set the PR labels. Ensure that you set only the same set of labels that is present in the issue, and ignore yellow
status/labels. - If the PR does not close any of the issues, the PR itself might need to have a milestone set. Reach out to the maintainers to consult.
- Assign the PR to yourself. A PR assignee is someone whose goal is to get the PR merged.
- Add reviewers. As a rule, reviewers' suggestions are pretty good; please use them.
- Upon merging the PR, please use a meaningful commit message, task name should be fine in this case.
- When composing a build, ensure that any install or build dependencies have been removed before the end of the layer.
- Update the
README.mdwith the details of changes made to the interface. This includes new environment variables, exposed ports, useful file locations, and container parameters.
WIP
WIP