:loudspeaker: Pre-requisites
:whale: How to set up Docker
(TBC)
:airplane: How to run tests
(TBC)
:gem: Style Guide
: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