We welcome contributions! Please read these guidelines carefully.
All contributors must adhere to our Code of Conduct.
We follow a structured branching model to ensure smooth collaboration:
master→ Stable, production-ready code.development→ Active development branch (target all PRs here).feature/<some-feature>→ New features are developed in separate branches prefixed withfeature/.bugfix/<some-bug>→ Bug fixes should be addressed in dedicatedbugfix/branches.research/<some-research>→ Experimental branches used for exploring ideas. These are sandbox environments that can later be integrated intofeature/branches and then merged intodevelopment.
🔹 Research branches (
research/) are meant for exploration and testing. Once a concept is validated, it should be merged into afeature/branch before integration intodevelopment.
- Fork the repository and create a relevant branch (
feature/,bugfix/, orresearch/). - Open PRs only to the
developmentbranch. - PRs must include:
- A clear description of changes.
- Updated documentation (if applicable).
- Follow existing code style and architecture patterns.
- Document new APIs and features thoroughly.
- Keep commits atomic and well-described.
- All code must pass existing test suites.
- New features require ≥80% test coverage.
- Manual testing steps must be documented in PRs.
To maintain a clean and meaningful commit history, follow the Conventional Commits format:
<type>(<scope>): <description>
✅ Feature Addition:
feat(auth): add OAuth2 login support
✅ Bug Fix:
fix(ui): resolve button alignment issue in navbar
✅ Documentation Update:
docs(contributing): clarify PR submission process
✅ Refactor:
refactor(api): optimize query handling for performance
✅ Chore (dependencies, CI/CD, etc.):
chore(deps): update dependency eslint to v8.3.1
Type
Description
feat
Introduces a new feature
fix
Fixes a bug
docs
Documentation updates
style
Code style (formatting, missing semicolons, etc.)
refactor
Code refactoring (no new features or bug fixes)
test
Adding or updating tests
chore
Maintenance tasks (dependencies, CI/CD, etc.)
🔹 Note: All PR titles must follow the Conventional Commits format. PRs with invalid commit messages may be rejected.
- When a pull request is raised, the CLA Assistant bot will guide you with the steps required to sign our CLA, you have to simply follow them
- Along with the steps of the bot, you have to sign with your name in CLA.md at the bottom in your own fork of the repository
- Unsigned PRs will be blocked automatically.
- 2 maintainer approvals required for merging.
- Security-critical code requires 3 approvals.
- Reviewers may request changes or additional tests.
- Early Adopter Community: Join Here
- Feature Requests: Use GitHub Discussions.
- Critical Bugs: Use the "Security Advisory" template.
Thank you for contributing to Sentient! 🚀