Coding Guidelines

Workflow

• Create an issue for a feature/bug.
• Discuss the implementation on the issue itself while attaching the supporting docs there.
• Create a new branch for the issue.
• Code in the branch.
• Open a PR with the very first commit and add a WIP prefix to the title of the PR. e.g. WIP: Fix #1 - add base project structure with spiders.
• When finished with the implementation, request reviews and remove the WIP prefix.
• If approved, merge the branch. If you are merging from your local CLI(instead of Github UI), make sure your merge commit message contain Fix #1 (for our example, the issue number is 1, replace it with whatever issue number you worked on).
• Go back and check if your issue is closed or not, if not just close it with a reference to the PR which closes it and then go ahead and delete the branch.

Branching Model

• Protect Master Branch
  Resources:

  • Defining the mergeability of PRs

• Branches should be created with respect to issues with the name convention as: <feature_name-#issue_number> e.g. scraper-#1.

Code standards

• We follow pep-8 for Python.
• We are using pylint for code linting and this is integrated in the CI pipeline.
• Any PR that needs to be merged must get a score > 8 to be passed from CI pipeline.

Labels in Github

We have some handful of labels to use, few of them we recommend using regularly like: wip, needs-review, bug, enhancement etc.

When to use which label?

• PRs should generally have process specific labels. e.g. when you are working on it, it should have a wip label and once work is finished, the wip should be removed and they should have a needs-review label until the final merge. After the merge we should get rid of all the wip and needs-review.
• Issues could have more intent specific label, like bug, enhancement, documentation etc.