Contributing¶
Guidelines for contributing to the JDX Odoo project.
Getting Started¶
1. Clone the Repository¶
2. Set Up Development Environment¶
# Copy environment file
cp .env.example .env.test
# Start services
docker compose -f docker-compose.yml -f docker-compose.test.yml up -d
# Verify setup
./scripts/health-check.sh
3. Create a Branch¶
# Update main
git checkout main
git pull origin main
# Create feature branch
git checkout -b feature/your-feature-name
Branch Naming¶
| Type | Pattern | Example |
|---|---|---|
| Feature | feature/description |
feature/add-loyalty-points |
| Bug fix | fix/description |
fix/sms-send-error |
| Hotfix | hotfix/description |
hotfix/login-crash |
| Docs | docs/description |
docs/api-authentication |
| Refactor | refactor/description |
refactor/order-processing |
Commit Messages¶
Follow Conventional Commits:
Types¶
| Type | Description |
|---|---|
feat |
New feature |
fix |
Bug fix |
docs |
Documentation only |
style |
Code style (formatting, no logic change) |
refactor |
Code change that neither fixes bug nor adds feature |
test |
Adding or updating tests |
chore |
Build process, dependencies, configs |
Examples¶
# Feature
git commit -m "feat(sms): add bulk SMS sending capability"
# Bug fix
git commit -m "fix(auth): resolve session timeout issue"
# Documentation
git commit -m "docs(api): add authentication examples"
# Breaking change
git commit -m "feat(api)!: change response format for partners endpoint
BREAKING CHANGE: Response now returns array instead of object"
Pull Request Process¶
1. Before Creating PR¶
- Code follows Coding Standards
- Tests pass locally
- Documentation updated if needed
- Branch is up to date with main
# Update branch with main
git checkout main
git pull origin main
git checkout feature/your-feature
git rebase main
2. Create Pull Request¶
# Push branch
git push origin feature/your-feature
# Create PR via GitHub CLI
gh pr create --title "feat: add loyalty points" --body "Description of changes"
3. PR Template¶
## Summary
Brief description of what this PR does.
## Changes
- Added X
- Updated Y
- Fixed Z
## Testing
- [ ] Unit tests added/updated
- [ ] Manual testing completed
- [ ] Tested in test environment
## Screenshots (if UI changes)
[Add screenshots here]
## Related Issues
Closes #123
4. Code Review¶
- At least one approval required
- Address all review comments
- Keep PR focused (one feature/fix per PR)
5. Merge¶
After approval: 1. Squash commits if needed 2. Merge to main 3. Delete feature branch
Code Review Guidelines¶
For Authors¶
- Keep PRs small and focused
- Write clear descriptions
- Respond to feedback promptly
- Don't take feedback personally
For Reviewers¶
- Be constructive and specific
- Explain the "why" behind suggestions
- Approve when ready, don't block on minor issues
- Use conventional comments:
| Prefix | Meaning |
|---|---|
nit: |
Minor suggestion, optional |
suggestion: |
Recommended improvement |
question: |
Seeking clarification |
issue: |
Must be addressed |
Development Workflow¶
main
│
├── feature/add-loyalty ──────┐
│ │
│ [develop & test] │
│ │
│ [create PR] │
│ │
│ [code review] │
│ │
│ [merge]◄──────────────────┘
│
└── (continues)
Testing Requirements¶
New Features¶
- Unit tests for business logic
- Integration tests for API endpoints
- Manual testing checklist completed
Bug Fixes¶
- Regression test that reproduces the bug
- Fix verified in test environment
Documentation¶
- No tests required
- Verify links work
- Check formatting in preview
Release Process¶
-
Version Bump
-
Changelog
- Update CHANGELOG.md with changes
-
Group by: Added, Changed, Fixed, Removed
-
Tag Release
-
Deploy
- Deploy to staging first
- Run smoke tests
- Deploy to production
Getting Help¶
- Questions: Open a GitHub Discussion
- Bugs: Open a GitHub Issue
- Security: Email security@yourcompany.com (don't open public issue)
Code of Conduct¶
- Be respectful and inclusive
- Focus on the code, not the person
- Assume good intentions
- Help others learn