# Contributing to PicPeak First off, thank you for considering contributing to PicPeak! It's people like you that make PicPeak such a great tool for photographers worldwide. ## ๐Ÿค Code of Conduct This project and everyone participating in it is governed by the [PicPeak Code of Conduct](CODE_OF_CONDUCT.md). By participating, you are expected to uphold this code. ## ๐ŸŽฏ How Can I Contribute? ### Reporting Bugs Before creating bug reports, please check the existing issues as you might find out that you don't need to create one. When you are creating a bug report, please include as many details as possible: * **Use a clear and descriptive title** * **Describe the exact steps to reproduce the problem** * **Provide specific examples to demonstrate the steps** * **Describe the behavior you observed and what you expected** * **Include screenshots if possible** * **Include your environment details** (OS, browser, Docker version, etc.) ### Suggesting Enhancements Enhancement suggestions are tracked as GitHub issues. When creating an enhancement suggestion, please include: * **Use a clear and descriptive title** * **Provide a detailed description of the suggested enhancement** * **Provide specific examples to demonstrate the enhancement** * **Describe the current behavior and expected behavior** * **Explain why this enhancement would be useful** ### Your First Code Contribution Unsure where to begin? You can start by looking through these issues: * [Good first issues](https://github.com/the-luap/picpeak/labels/good%20first%20issue) - issues which should only require a few lines of code * [Help wanted issues](https://github.com/the-luap/picpeak/labels/help%20wanted) - issues which need extra attention ### Pull Requests 1. **Fork the repo** and create your branch from `beta` 2. **Install dependencies**: ```bash cd backend && npm install cd ../frontend && npm install ``` 3. **Make your changes** and ensure: - Code follows the existing style - Tests pass: `npm test` - Linting passes: `npm run lint` 4. **Write tests** if you've added code 5. **Update documentation** if needed 6. **Create a Pull Request** ## ๐Ÿ’ป Development Setup ### Prerequisites - Node.js 18+ - Docker & Docker Compose - Git ### Local Development ```bash # Clone your fork git clone https://github.com/your-username/picpeak.git cd picpeak # Install dependencies cd backend && npm install cd ../frontend && npm install # Set up environment cp .env.example .env # Edit .env with your settings # Start development servers docker-compose -f docker-compose.dev.yml up ``` **After pulling changes that touch `backend/package.json` / `backend/package-lock.json` (or the frontend equivalents)**, rebuild the affected image so the live-mounted source can `require()` the new deps: ```bash docker compose -f docker-compose.dev.yml up -d --build backend # (or `frontend`, or both) ``` The dev compose bakes `node_modules` into the image while live-mounting `./backend/src` and `./frontend/src` from disk. A dep added on disk won't be picked up until the image is rebuilt โ€” typical symptom is a `MODULE_NOT_FOUND` restart loop on the affected container. ### Running Tests ```bash # Backend tests cd backend && npm test # Frontend tests cd frontend && npm test # E2E tests npm run test:e2e ``` ## ๐Ÿ“ Styleguides ### Git Commit Messages * Use the present tense ("Add feature" not "Added feature") * Use the imperative mood ("Move cursor to..." not "Moves cursor to...") * Limit the first line to 72 characters or less * Reference issues and pull requests liberally after the first line * Consider starting the commit message with an applicable emoji: * ๐ŸŽจ `:art:` when improving the format/structure of the code * ๐Ÿ› `:bug:` when fixing a bug * ๐Ÿ”ฅ `:fire:` when removing code or files * ๐Ÿ“ `:memo:` when writing docs * ๐Ÿš€ `:rocket:` when improving performance * โœจ `:sparkles:` when adding a new feature ### JavaScript/TypeScript Styleguide * Use ES6+ features * Prefer async/await over promises * Use meaningful variable names * Add JSDoc comments for functions * Follow ESLint rules ### React Styleguide * Use functional components with hooks * Keep components small and focused * Use TypeScript for type safety * Follow the existing folder structure * Write tests for new components ## ๐Ÿ“ฆ Project Structure ``` picpeak/ โ”œโ”€โ”€ backend/ โ”‚ โ”œโ”€โ”€ src/ โ”‚ โ”‚ โ”œโ”€โ”€ routes/ # API endpoints โ”‚ โ”‚ โ”œโ”€โ”€ services/ # Business logic โ”‚ โ”‚ โ”œโ”€โ”€ middleware/ # Express middleware โ”‚ โ”‚ โ””โ”€โ”€ utils/ # Utilities โ”‚ โ””โ”€โ”€ migrations/ # Database migrations โ”œโ”€โ”€ frontend/ โ”‚ โ”œโ”€โ”€ src/ โ”‚ โ”‚ โ”œโ”€โ”€ components/ # Reusable components โ”‚ โ”‚ โ”œโ”€โ”€ pages/ # Page components โ”‚ โ”‚ โ”œโ”€โ”€ services/ # API services โ”‚ โ”‚ โ””โ”€โ”€ hooks/ # Custom hooks โ”‚ โ””โ”€โ”€ public/ # Static assets ``` ## ๐Ÿ”„ Release Process Releases are cut from the `beta` branch (rolling beta) and promoted to `main` (stable) on a 4โ€“6 week cadence. `release-please` handles version bumps, changelog generation, and Docker image publication automatically โ€” contributors don't update `package.json` or `CHANGELOG.md` by hand. See [RELEASING.md](RELEASING.md) for the full operational doc (promotion criteria, conflict-resolution checklist for the betaโ†’main merge, hotfix backport path, versioning rules). ## ๐Ÿ“ฎ Contact - Create an [issue](https://github.com/the-luap/picpeak/issues) for bugs or features - Join [discussions](https://github.com/the-luap/picpeak/discussions) for questions - Security issues: Open a [security issue](https://github.com/the-luap/picpeak/issues/new?labels=security) on GitHub Thank you for contributing! ๐ŸŽ‰