Contribution Guide
Thank you for your interest in contributing to this project! This guide will help you get started.
🤝 Code of Conduct
By participating in this project, you agree to abide by our Code of Conduct. Please read it before contributing.
🐛 Reporting Bugs
If you find a bug, please create an issue using our Bug Report template.
Include:
- Clear description of the issue
- Steps to reproduce
- Expected vs actual behavior
- Environment details (OS, version, etc.)
- Screenshots if applicable
💡 Suggesting Features
We welcome feature suggestions! Please use our Feature Request template.
Include:
- Clear description of the feature
- Use case and benefits
- Possible implementation approach
- Examples or mockups if applicable
🔧 Development Setup
-
Fork the repository
# Click the "Fork" button on GitHub -
Clone your fork
git clone https://github.com/YOUR_USERNAME/rippler.git
cd rippler --recurse-submodules -
Add upstream remote
git remote add upstream https://github.com/Citi-Rippler/rippler.git -
Create a branch
git checkout -b feature/your-feature-name
📝 Making Changes
Code Style
We use automated tools to enforce code style:
- JavaScript/TypeScript: ESLint + Prettier
- Python: Flake8 + Black
- Java: Checkstyle
Commit Messages
Follow Conventional Commits:
<type>(<scope>): <description>
[optional body]
[optional footer]
Types:
feat: New featurefix: Bug fixdocs: Documentation changesstyle: Code style changes (formatting, etc.)refactor: Code refactoringtest: Adding or updating testschore: Maintenance tasks
Examples:
feat(auth): add OAuth2 login support
fix(api): resolve null pointer exception in user service
docs(readme): update installation instructions
Testing
Ensure all tests pass before submitting:
# Node.js
npm test
# Python
pytest
# Java Maven
mvn test
# Java Gradle
./gradlew test
Linting
Run linters before committing:
# Node.js
npm run lint
# Python
flake8 .
# Java Maven
mvn checkstyle:check
# Java Gradle
./gradlew checkstyleMain
📤 Submitting Changes
-
Commit your changes
git add .
git commit -m "feat: add new feature" -
Keep your branch updated
git fetch upstream
git rebase upstream/main -
Push to your fork
git push origin feature/your-feature-name -
Create a Pull Request
- Go to the original repository
- Click "New Pull Request"
- Select your fork and branch
- Fill out the PR template
- Submit the PR
✅ Pull Request Checklist
Before submitting a PR, ensure:
- Code follows the project's style guidelines
- All tests pass
- New tests are added for new features
- Documentation is updated
- Commit messages follow conventions
- Branch is up-to-date with main
- PR description clearly explains changes
🔍 Code Review Process
- Automated Checks: CI/CD pipelines run automatically
- Maintainer Review: A maintainer will review your PR
- Feedback: Address any requested changes
- Approval: Once approved, your PR will be merged
Review Timeline
- Initial response: Within 2-3 business days
- Full review: Within 1 week
- Complex features may take longer
📚 Additional Guidelines
Branch Naming
feature/feature-name- New featuresfix/bug-description- Bug fixesdocs/description- Documentationrefactor/description- Code refactoring
PR Size
- Keep PRs focused and small
- Large changes should be split into multiple PRs
- Discuss major changes in an issue first
Documentation
- Update README if adding features
- Add inline comments for complex logic
- Update API documentation if applicable
🆘 Getting Help
If you need help:
- Check the Getting Started guide
- Ask in GitHub Discussions
- Comment on the related issue
- Contact maintainers
🎉 Recognition
Contributors are recognized in:
- Contributors page
- Release notes
- Project documentation
Thank you for contributing! 🙌