| # Contributing to Recipe Recommendation Chatbot | |
| ## 📋 Ways of Working | |
| ### Project Management | |
| - All user stories and tasks tracked via GitHub Issues | |
| - Issues labeled appropriately (`feature`, `bug`, `documentation`, `week-X`) | |
| - Clear issue templates for consistency | |
| ### Documentation Standards | |
| - All documentation written in Markdown (.md) format | |
| - Documentation stored in `/docs` folder | |
| - README.md maintained with project overview and setup instructions | |
| ### Development Workflow | |
| - All changes submitted via Pull Requests (PRs) | |
| - No direct commits to `main` branch | |
| - PR review required before merging | |
| - Descriptive commit messages and PR descriptions | |
| ### Communication | |
| - Daily progress updates in PLG4 Slack channel | |
| - Weekly team meetings (Wednesdays 2 PM GMT) | |
| - Issues assigned to team members for accountability | |
| ## 🛠️ Development Process | |
| ### 1. Setting Up Your Environment | |
| ```bash | |
| # Clone the repository | |
| git clone https://github.com/A3copilotprogram/PLG4-Recipe-Recommendation-Chatbot.git | |
| cd PLG4-Recipe-Recommendation-Chatbot | |
| ### 2. Creating a Feature Branch | |
| ```bash | |
| # Create and switch to a new branch using PLG4 + issue number format | |
| git checkout -b PLG4#1-define-ways-of-working | |
| # Examples: | |
| # For feature from issue #5: PLG4#5-recipe-recommendation-engine | |
| # For bug fix from issue #12: PLG4#12-fix-ingredient-parsing | |
| # For documentation from issue #3: PLG4#3-update-api-docs | |
| ``` | |
| **Branch Naming Convention:** | |
| - Format: `PLG4#<issue-number>-<brief-description>` | |
| - Example: `PLG4#1-define-ways-of-working` for issue "Define Ways of Working #1" | |
| - Use kebab-case for descriptions (lowercase with hyphens) | |
| - Keep descriptions brief but descriptive | |
| ### 3. Making Changes | |
| - Write clear, descriptive commit messages | |
| - Add tests for new functionality | |
| - Update documentation as needed | |
| ### 4. Submitting a Pull Request | |
| 1. Push your branch to GitHub | |
| 2. Create a Pull Request with: | |
| - Clear description of changes | |
| - Reference to related issues | |
| - Screenshots (if UI changes) | |
| 3. Request review from team members | |
| 4. Address review feedback | |
| ## 📋 Working Agreements | |
| 1. **Issues**: Create GitHub issues for all user stories and tasks | |
| 2. **Documentation**: Use `.md` files for all project documentation | |
| 3. **Code Changes**: Work via Pull Requests only | |
| 4. **Reviews**: At least one team member review before merge | |
| 5. **Updates**: Daily check-ins in Slack channel | |
| ## 🧪 Testing Guidelines | |
| - Write tests for all new features | |
| - Maintain >80% code coverage | |
| - Include both unit and integration tests | |
| - Run tests before submitting PRs | |
| ## 📝 Code Style | |
| - Use meaningful variable and function names | |
| - Add docstrings to all functions and classes | |
| - Keep functions small and focused | |
| ## 🚀 Deployment | |
| - Changes merged to `main` trigger automated deployment | |
| - Test in staging environment before production | |
| - Follow deployment checklist in `docs/deployment.md` | |