Welcome contributors
Thank you for your interest in contributing to Spring Boot Redis Rate Limiter. We welcome contributions from the community, whether it’s bug reports, feature requests, documentation improvements, or code contributions.License
This project is licensed under the Apache License 2.0. By contributing to this project, you agree that your contributions will be licensed under the same terms. Key points of the Apache 2.0 license:- Free to use, modify, and distribute
- Patent grant included
- Must preserve copyright and license notices
- Changes must be documented
- No trademark rights granted
Ways to contribute
Report bugs
If you find a bug, please open an issue on GitHub with:- Clear description of the problem
- Steps to reproduce
- Expected vs actual behavior
- Environment details (Java version, Spring Boot version, Redis version)
- Relevant logs or stack traces
Suggest features
Feature requests are welcome. Please open an issue describing:- The use case or problem you’re trying to solve
- Proposed solution or API design
- Any alternatives you’ve considered
- Examples of how it would be used
Improve documentation
Documentation improvements are always appreciated:- Fix typos or unclear explanations
- Add more examples
- Improve troubleshooting guides
- Translate documentation
Contribute code
Code contributions should:- Follow existing code style and conventions
- Include unit tests for new functionality
- Include integration tests where appropriate
- Update documentation to reflect changes
- Pass all existing tests
Development setup
Prerequisites
- Java 17 or higher
- Maven 3.8+
- Git
- Docker (for integration tests)
Clone the repository
Build the project
Project structure
Code standards
Java style
- Use Java 17 features where appropriate
- Follow standard Java naming conventions
- Keep methods focused and concise
- Add Javadoc for public APIs
- Use meaningful variable names
Testing
Unit tests:- Test individual components in isolation
- Use mocks for external dependencies
- Follow AAA pattern (Arrange, Act, Assert)
- Use descriptive test method names
- Test end-to-end behavior
- Use Testcontainers for Redis
- Name test classes with
*ITsuffix - Clean up resources after tests
Commit messages
Follow conventional commit format:feat: New featurefix: Bug fixdocs: Documentation changestest: Test additions or changesrefactor: Code refactoringperf: Performance improvementschore: Build/tooling changes
Pull request process
-
Fork the repository and create a feature branch
- Make your changes following the code standards
-
Write or update tests to cover your changes
-
Update documentation if needed
- README.md for user-facing changes
- Javadoc for API changes
- HOW_TO_USE.md for usage examples
- Commit your changes with clear commit messages
-
Push to your fork and open a pull request
-
Fill out the PR template with:
- Description of changes
- Related issue numbers
- Testing done
- Breaking changes (if any)
- Wait for review - maintainers will review and provide feedback
- Address feedback and update your PR as needed
- Merge - once approved, your PR will be merged
Testing guidelines
Unit tests
Run unit tests frequently during development:Integration tests
Run integration tests before submitting PR:- Docker must be running
- Testcontainers will automatically pull Redis image
Test coverage
Aim for high test coverage:Documentation
Code documentation
- Add Javadoc for public classes and methods
- Explain non-obvious behavior
- Include examples in Javadoc where helpful
User documentation
Update relevant files:README.md- Overview, installation, quick startHOW_TO_USE.md- Detailed usage guideCHANGELOG.md- Version history
Release process
Releases are managed by project maintainers.Versioning
Follow Semantic Versioning:- MAJOR: Breaking changes
- MINOR: New features (backward compatible)
- PATCH: Bug fixes (backward compatible)
Release to Maven Central
- Update version in
pom.xml - Update
CHANGELOG.md - Create git tag
- Deploy to OSSRH
- Close and release staging repository in Sonatype
- Publish release notes on GitHub
Getting help
If you need help:- Check existing issues
- Review the documentation
- Ask questions in issue discussions
- Review the FAQ
Code of conduct
Be respectful and constructive:- Use welcoming and inclusive language
- Respect differing viewpoints and experiences
- Accept constructive criticism gracefully
- Focus on what’s best for the community
- Show empathy towards other community members
Recognition
Contributors will be:- Listed in release notes
- Acknowledged in the repository
- Appreciated by the community