Guidelines

​

Core guidelines

• Always start with an issue. Create the issue in the Linear if an issue regarding the feature/bug doesn’t exist. While creating an issue, use the standard issue format that consists of a brief description of what needs to be done, bullet-point representation of the success criteria and bullet-point representation of the acceptance criteria.
• Mark the issue as in-progress when starting to work on the said issue, keep any discussions to that issue in the threads section under that issue itself.
• Use a consistent file and folder naming convention. Read through the established structure the project follows, try to repurpose the old code as there .
• Maintain a well documented code and explain with comments where necessary. Although don’t over-comment stuff. Try to write code in such a way that mostly commenting isn’t required.
• Try to avoid technical debt as much as possible. Document technical debt (if any) clearly in the threads section beneath the issue and prioritize on reducing it systematically.
• Use bun as the package manager for the project. Do not use npm, pnpm or yarn. Avoid unnecessary dependencies and regularly purge dependencies that are no longer being used.
• Please notify the team before introducing a new dependency (ShadCN components doesn’t count, add them anytime).
• No typescript errors should be present in the code for any PR. Also don’t ts-ignore any TS errors until absolutely necessary. Avoid using any type as much as possible.
• Double check lint errors and warnings before committing. No errors and ideally no warnings should be there in the committed code. Run bun run lint:fix as necessary.
• Do not directly commit into the main branch. Always commit into the corresponding branch of the Linear issue.
• Make atomic commits with clear and concise commit messages precisely communicating the changes that were made in the said commit.
• While opening a pull request, follow the PR description format. Include the link to the Linear issue, provide a description, bullet-point representation of the changes made in the PR and a closing note. Ask for review from at least two team members when opening the PR.

​

Standard formats and templates

​

Issue template

A short description of what the issue is about and how it affects the project.

**Success Criteria:**
- [ ] Bullet-point representation of the success criteria.
- [ ] Success criteria should be measurable and clearly defined.
- [ ] These are the expected outcomes after the issue is resolved.

**Acceptance Criteria:**
- [ ] Bullet-point representation of the acceptance criteria.
- [ ] Acceptance criteria should be specific and clearly defined.
- [ ] These are the individual and more specific changes and tasks that needs to be performed.

**Additional Notes:** (Optional)
- [ ] Any additional notes that is worth considering.
- [ ] These are the additional information that might be useful for the team to know.

A conclusion note about the issue and how it affects the project and why it is important to resolve it.

​

Commit message template

[Change type (feat/fix/docs/chore/style]: [Commit message in present indefinite tense]

​

Pull Request template

### Issue:
[Linear issue name as is](Linear issue link)

### Description:
A brief description of what the PR is about and how it affects the project.

### Changes Made:
- [ ] Bullet-point representation of the changes made in the PR.
- [ ] Changes should be specific and clearly defined.
- [ ] These are the individual and more specific changes that were made in the PR.

### Closing Note:
A conclusion note about the PR and how it affects the project and why it is important to merge it.

​

PR Review template

**Observation:** A brief observation of the PR and how it affects the project.

**Requested Changes:**
- [ ] Bullet-point representation of the requested changes.
- [ ] Changes should be specific and clearly defined.

**Remark:** (Optional) A remark about whether the PR is ready to be merged or not.