Thanks for helping improve FairShare. This guide covers setup, workflow, and contribution standards.
This section explains how to start contributing if you're new to the project or open source in general.
Click the Fork button at the top-right of the repository page to create your own copy of the codebase.
Clone your forked repository to your local machine:
git clone https://github.com/YOUR_USERNAME/FairShare.git
cd FairShareReplace YOUR_USERNAME with your GitHub username.
Keep your fork in sync with the main project:
git remote add upstream https://github.com/Arun-kushwaha007/FairShare.gitAlways create a new branch for your work. Use the following naming standard:
feat/your-feature-name(for new features)fix/bug-description(for bug fixes)docs/what-changed(for documentation updates)
git checkout -b feat/add-new-featureAfter making your changes, stage and commit them. Follow the conventional commit style (see below).
git add .
git commit -m "feat(scope): add helpful description"Push your changes to your fork and open a Pull Request (PR) on the main repository.
git push origin feat/add-new-featureGo to the original repository on GitHub, and you'll see a "Compare & pull request" button.
- Install dependencies:
pnpm install- Create environment files:
cp .env.example .env
cp apps/mobile/.env.example apps/mobile/.env- Start local services:
docker-compose up -d- Run apps:
pnpm devapps/backend: NestJS APIapps/web: Next.js dashboardapps/mobile: Expo apppackages/shared-types: shared types across apps
-
Create a feature branch from
main. -
Keep commits focused and readable.
-
Use conventional commit style when possible:
feat(scope): messagefix(scope): messagechore(scope): message
- TypeScript everywhere
- Keep UI changes consistent with existing design tokens
- Avoid introducing new dependencies unless necessary
- Prefer shared types in
packages/shared-types
Run what applies to your change:
pnpm lint
pnpm test
pnpm --filter web build- Changes compile and relevant tests pass
- Screenshots for UI changes (web/mobile)
- No secrets or credentials committed
- Updated README/docs if behavior changed
- Never commit
.envor real credentials - Use placeholders or local-only values for compose/dev configs
- Avoid logging tokens or sensitive payloads
- Rotate keys immediately if a secret is exposed
- Keep dependencies updated and audited
When filing a bug, include:
- Reproduction steps
- Expected vs actual behavior
- Logs or screenshots
- App version and environment