:loudspeaker: Pre-requisites

• Git
• VS Code, IntelliJ (as preferred)
• Java SDK
• Docker desktop
• NodeJS

  :wrench: Development

  You can find the summary of development guideline here

:whale: How to set up Docker

Build the images in the docker-compose. yml file docker-compose build Spin up the docker containers and aggregate them docker-compose up Stops containers and removes containers, networks, volumes, and images created by up docker-compose down

:airplane: How to run tests

(TBC)

:gem: Style Guide

Linting

(TBC)

:closed_book: How to do Code Review

• Always create a PR before you merge into dev or main branch. :rotating_light:No direct merge into main!. Currently we cannot force branch policy as it's a paid feature for Github Organisation. So beware!
• Assign more than one reviewers. Highly recommend to install CodeStream extensions on IDE of your choice.
• Use labelling and tagging to let people know how urgent your PR or change request is
• Use Emoji Code when reviewing the PR
• All PRs must pass all unit tests and linting requirements

Labelling

# D-N (Within N days)
“Please review this within N Working Day”

Tagging

P1 = Please reflect my change request. When a reviewer thinks the PR includes the change that gives errors in the service, you ask for changes. If a reviewee rejects this change request, the reviewee needs good reasons to persuade the reviewer

P2 = Consider my change request positively. If rejecting the change request, it is recommended to have discussions

P3 = Just a comment. If rejecting the change request, please provide reaons or update your JIRA ticket to relfect the change request in future

P4 = Approve. No need to reply to the reviewer. It's up to a reviewee to reflect the suggestion

P5 = Approve. No need to reply. A reviewee can ignore it.

:blue_book: How to create a good commit line

• Capitalized, short (50 chars or less) summary
• More detailed explanatory text, if necessary. Wrap it to about 72 characters. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together.
• Always leave the second line blank.
• Write your commit message in the imperative: "Fix bug" and not "Fixed bug" or "Fixes bug." This convention matches up with commit messages generated by commands like git merge and git revert.
• Further paragraphs come after blank lines.
  • Bullet points are okay, too
  • Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank lines in between, but conventions vary here
  • Use a hanging indent
• Please have a read at this link

Good Example

Issue #1: Fix node_modules being owned by root

A bug in the node_cache.py code resulted in the node_modules symlink
in Zulip development environments being incorrectly owned by root.
This causes that bug to be fixed the next time a user provisions.

Bad Example

gather_subscriptions: Fixing exception when given bad input