Pull requests

Pull requests are the essential part of our workflow and this section describes how to create and review them.

General rules

Creating a pull request

  1. A good pull request includes only one feature or a bugfix. Fixing multiple issues or adding several features in a pull request is not a good practice and it should be avoided whenever possible.
  2. When creating a pull request make sure you write a good description. It doesn't have to be long, but it has to give context to the reviewer. Commit messages will not be considered as a description of what has been done in the pull request.
  3. If possible, provide the URL of the task which describes the feature or what the issue is.
  4. Review your own pull request before creating it. By reviewing your own pull request, you get a chance to notice some obvious stuff before assigning it to a reviewer.

Reviewing a pull request

  1. When reviewing a pull request make sure to check how the whole changes fit the current code base and the architecture. Do not approve the pull request if the changes, for no obvious reason, are not aligned with the rest of the codebase.
  2. Alongside the code inspection, checkout the branch on your machine and test it on your mobile phone. Use common sense for this, it's not important to test the changes if a pull request changes only one file, but for bigger features or fixes you should test the implementation. The idea behind is that some obvious issues (paddings, margins, user specific bugs etc.) are caught before they reach our testers.

These are guidelines, not rules, so use common sense when creating or reviewing a pull request.