Contributing to NexusMind
We welcome contributions to NexusMind! Please follow these general guidelines when contributing:
Getting Started
- Fork the Repository: Start by forking the main NexusMind repository to your own GitHub account.
- Clone your fork:
- Install Dependencies: Ensure you have Poetry (version 1.2+) installed and run: This will create a virtual environment and install all necessary dependencies.
Branching Strategy
- Branch from
main
: Always create your new feature or bugfix branches from the latestmain
branch of the upstream (original) NexusMind repository. Or for bug fixes: - Naming Conventions:
- Feature branches:
feature/some-feature-description
- Bugfix branches:
fix/issue-number-short-description
(e.g.,fix/123-mcp-auth-error
) - Documentation branches:
docs/update-readme-styles
- Refactor branches:
refactor/improve-stage-loading
- Feature branches:
Development Process
- Make Changes: Implement your feature or bug fix in your created branch.
- Write Tests:
- Add appropriate tests for your changes.
- Ensure all existing and new tests pass by running:
- Test Coverage: We aim for a high test coverage of over 95%. Please ensure your contributions include relevant tests to maintain or increase this coverage.
- Check Code Quality: Run linters and type checkers:
- Commit Your Changes:
- Follow Conventional Commit guidelines if possible (e.g.,
feat: add user authentication
,fix: resolve issue with API response
). This is not strictly enforced but highly encouraged. - Write clear and concise commit messages.
- Follow Conventional Commit guidelines if possible (e.g.,
- Push to Your Fork:
- Submit a Pull Request:
- Open a pull request from your feature branch in your fork to the
main
branch of theCognitiveAreNa/NexusMind
repository. - Provide a clear title and a detailed description of your changes in the pull request. Link any relevant issues.
- Ensure all automated checks (CI/CD pipeline) pass.
- Open a pull request from your feature branch in your fork to the
Code Style
- PEP 8: Follow PEP 8 style guidelines.
ruff
helps enforce this. - Type Hints: Use type hints for all function and method signatures, and for complex variable types.
mypy
is used for static type checking. - Docstrings: Write comprehensive docstrings for all modules, classes, functions, and methods using a standard format (e.g., Google style, reStructuredText). Explain what the code does, its arguments, and what it returns.
- Imports: Organize imports according to PEP 8 (standard library, then third-party, then local application/library specific imports, each group separated by a blank line).
ruff
can help sort these.
Release Strategy
The project aims to follow Semantic Versioning (SemVer - MAJOR.MINOR.PATCH
). Releases are managed by the core maintainers. Branch protection rules are in place for the main
branch to ensure stability.
Reporting Issues
If you find a bug or have a feature request, please open an issue on the GitHub repository.
Thank you for contributing!