File size: 2,873 Bytes
c59d808 |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 |
# 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`
|