Contributions are what make the open source community such an amazing place to learn, inspire, and create. Any contributions you make are greatly appreciated.
Before submitting a new issue or PR, check if it already exists in the Issues or Pull Requests.
For feature requests, please wait for a core team member to approve and remove the 🚨 needs approval label before you start coding or submitting a PR.
For bugs, security, performance, documentation, etc., you can start coding immediately—even if the 🚨 needs approval label is present.
We highly value new feature ideas, but to maintain consistency in the product direction, they must go through a review and approval process.
Avoid posting third-party links (e.g., Slack threads or Linear tickets) without context. A GitHub issue or PR should stand on its own—reviewers shouldn’t have to chase information across multiple tools to understand the context.
Put yourself in the reviewer’s shoes. What would you want to know if reading this for the first time? Are there key decisions, goals, or constraints that need clarification? Does the PR assume knowledge that isn’t obvious? Are there related issues or previous PRs that should be linked?
If the task originated from a private conversation (e.g., Slack), take a moment to extract the relevant details and include them in the GitHub issue or PR. Avoid sharing sensitive information, but make sure important reasoning is captured.
Example:
“A user requested feature X to solve problem Y. I considered approaches A, B, and C, but chose C for the following reasons…”
GitHub is a shared source of truth. Every issue and PR contributes to the long-term understanding of the codebase. Write clearly enough that someone—possibly you—can revisit it months later and still understand what happened and why.
Even if the code changes are minor or self-explanatory, a short written summary helps reviewers quickly understand the intent. You can use GitHub Copilot’s auto-summarize feature, but make sure to verify it for accuracy and relevance.
Use phrases like “Closes #123” or “Fixes #456” in your PR descriptions. This automatically links your PR to the related issue and closes it once merged—keeping everything traceable and organized.
Explain how you validated your changes. It doesn’t need to be exhaustive—just enough to give reviewers confidence that things were tested and work as expected.
Example:
“Tested locally with mock data and confirmed the flow works on staging.”
Write with the future in mind. If there are trade-offs, edge cases, or temporary workarounds, document them clearly so they don’t get lost or misinterpreted later.
| Type of Issue | Priority |
| Minor improvements, non-core feature requests |
|
| Confusing UX (but still functional) |
|
| Core Features (Booking page, availability, timezone calculation) |
|
| Core Bugs (Login, Booking page, Emails not working) |
|
To ensure consistency and make files easy to fuzzy-find, we follow the naming conventions below for services, repositories, and other class-based files.
- Repository class files must include the
Repositorysuffix. - If the repository is backed by a specific technology (e.g. Prisma), prefix the filename and class name with it.
- File name must match the exported class exactly (PascalCase).
Pattern:
Prisma<Entity>Repository.ts
Examples:
// File: PrismaAppRepository.ts
export class PrismaAppRepository { ... }
// File: PrismaMembershipRepository.ts
export class PrismaMembershipRepository { ... }This avoids ambiguous filenames like app.ts and improves discoverability in editors.
- Service class files must include the Service suffix.
- File name should be in PascalCase, matching the exported class.
- Keep naming specific — avoid generic names like AppService.ts.
Pattern:
<Entity>Service.ts
Examples:
// File: MembershipService.ts
export class MembershipService { ... }
// File: HashedLinkService.ts
export class HashedLinkService { ... }Note:
- New files must avoid dot-suffixes like .service.ts or .repository.ts; these will be migrated from the existing codebase progressively.
- We still reserve suffixes such as .test.ts, .spec.ts, and .types.ts for their respective use cases.
You can build the project with:
yarn buildPlease ensure that you can make a full production build before pushing code.
More info on how to add new tests coming soon.
Run npx playwright install to download test browsers and resolve the error below when running yarn test-e2e:
Executable doesn't exist at /Users/alice/Library/Caches/ms-playwright/chromium-1048/chrome-mac/Chromium.app/Contents/MacOS/Chromium
To check the formatting of your code:
yarn lintIf you get errors, be sure to fix them before committing.
Large PRs are difficult to review and more prone to errors. We strongly encourage smaller, self-contained PRs:
- Size limits: Keep PRs under 500 lines of code changed and under 10 code files modified (excludes documentation, lock files, and auto-generated files)
- Single responsibility: Each PR should address one concern (one feature, one bug fix, or one refactor)
- Split large changes: If your task requires extensive changes, break it into multiple PRs that can be reviewed and merged independently
How to split large changes:
- Separate database/schema changes from application logic
- Split frontend and backend changes when possible
- Do preparatory refactoring in a separate PR before adding new features
- Create PRs in dependency order (infrastructure first, then features)
- Be sure to check the "Allow edits from maintainers" option when creating your PR. (This option isn't available if you're contributing from a fork belonging to an organization)
- If your PR refers to or fixes an issue, add
refs #XXXorfixes #XXXto the PR description. ReplaceXXXwith the respective issue number. See more about linking a pull request to an issue. - Fill out the PR template accordingly.
- Review the App Contribution Guidelines when building integrations.
- Lastly, make sure to keep your branches updated (e.g., click the
Update branchbutton on the GitHub PR page).