Contributing to RoboDSL
Thank you for your interest in contributing to RoboDSL! We welcome contributions from the community to help improve the project. This guide will help you get started with contributing to the project.
Table of Contents
- Code of Conduct
- Quick Start
- Development Environment
- Code Style
- Testing
- Pull Request Process
- Reporting Issues
- Feature Requests
- Documentation
- Code Review Guidelines
- Release Process
- License
Quick Start
- Fork the repository on GitHub
- Clone your fork locally
bash git clone https://github.com/Zedonkay/robodsl.git cd robodsl
- Set up the development environment (see below)
- Create a branch for your changes
bash git checkout -b feature/your-feature-name
- Make your changes and commit them with a descriptive message
bash git commit -m "feat: add new feature"
- Push your changes to your fork
bash git push origin feature/your-feature-name
- Open a pull request against the
main
branch
Development Environment
Prerequisites
- Python 3.8+
- ROS2 Humble or newer (for ROS2 features)
- CUDA Toolkit 11.0+ (for CUDA features)
- CMake 3.15+
- Git
Setup
-
Create and activate a virtual environment:
bash python -m venv venv source venv/bin/activate # On Windows: venv\Scripts\activate
-
Install development dependencies:
bash pip install -e ".[dev]"
-
Install pre-commit hooks:
bash pre-commit install
Code Style
We follow these coding standards:
- Python: PEP 8 with Black formatting
- C++: Google C++ Style Guide with clang-format
- CMake: Follow Modern CMake practices
- Documentation: Google-style docstrings
Pre-commit Hooks
We use pre-commit to enforce code quality. The following hooks are configured:
- Black (code formatting)
- isort (import sorting)
- flake8 (linting)
- mypy (type checking)
- clang-format (C++ formatting)
Run the pre-commit hooks manually:
pre-commit run --all-files
Testing
Running Tests
# Run all tests
pytest
# Run tests with coverage
pytest --cov=robodsl tests/
# Run a specific test file
pytest tests/test_parser.py
# Run with verbose output
pytest -v
Writing Tests
- Place test files in the
tests/
directory - Follow the
test_*.py
naming convention - Use descriptive test function names
- Include docstrings explaining test purpose
- Use fixtures for common test setup
Pull Request Process
- Ensure all tests pass
- Update documentation as needed
- Add your changes to CHANGELOG.md
- Submit a draft PR early for discussion
- Request reviews from maintainers
- Address all review comments
- Ensure CI passes before merging
Commit Message Format
We follow the Conventional Commits specification:
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
Types:
- feat
: New feature
- fix
: Bug fix
- docs
: Documentation changes
- style
: Code style changes
- refactor
: Code changes that neither fix bugs nor add features
- perf
: Performance improvements
- test
: Adding or modifying tests
- chore
: Changes to the build process or auxiliary tools
Example:
feat(parser): add support for custom node types
Add ability to define custom node types with validation.
Closes #123
Reporting Issues
When reporting issues, please include:
- Description of the problem
- Steps to reproduce
- Expected behavior
- Actual behavior
- Environment details
- Any relevant logs or error messages
Feature Requests
We welcome feature requests! Please:
- Check if the feature already exists
- Explain why this feature is valuable
- Describe the proposed solution
- Include any relevant examples
Documentation
Building Documentation
# Install documentation dependencies
pip install -e ".[docs]"
# Build the documentation
cd docs
make html
# View the documentation
open _build/html/index.html
Documentation Guidelines
- Use Markdown for all documentation
- Follow the Google Style Guide for docstrings
- Include examples for public APIs
- Update documentation when changing behavior
- Add diagrams for complex concepts
Code Review Guidelines
Reviewers
- Focus on code quality and correctness
- Check for security implications
- Verify test coverage
- Ensure documentation is updated
- Consider performance impact
Authors
- Keep PRs focused and small
- Address all review comments
- Update documentation and tests
- Be responsive to feedback
- Fix CI failures promptly
Release Process
- Update version in
pyproject.toml
- Update
CHANGELOG.md
- Create a release tag
- Build and publish packages
- Update documentation
License
By contributing to RoboDSL, you agree that your contributions will be licensed under the MIT License. See LICENSE for details.
Code of Conduct
By participating in this project, you are expected to uphold our Code of Conduct. Please report any unacceptable behavior to the project maintainers.
Getting Started
- Fork the repository on GitHub
- Clone your fork locally
bash git clone https://github.com/your-username/robodsl.git cd robodsl
- Create a branch for your changes
bash git checkout -b feature/your-feature-name
- Make your changes and commit them
bash git commit -m "Add your commit message"
- Push your changes to your fork
bash git push origin feature/your-feature-name
- Open a pull request against the main repository
Development Environment
Prerequisites
- Python 3.8+
- ROS2 (Humble/Foxy/Galactic)
- CUDA Toolkit 11.0+
- CMake 3.15+
- Git
Setup
-
Create a Python virtual environment
bash python -m venv venv source venv/bin/activate # On Windows: venv\Scripts\activate
-
Install development dependencies
bash pip install -r requirements-dev.txt pip install -e .
-
Install pre-commit hooks
bash pre-commit install
Code Style
Python
We follow the PEP 8 style guide with the following additional guidelines:
- Maximum line length: 88 characters (enforced by Black)
- Use double quotes for strings
- Use type hints for all function signatures
- Document all public APIs with docstrings
C++
We follow the Google C++ Style Guide with the following exceptions:
- Use
#pragma once
instead of include guards - Maximum line length: 100 characters
- Use C++17 features where appropriate
Formatting
We use automated tools to enforce code style:
- Python: Black, isort, flake8
- C++: clang-format
- Markdown: Prettier
Run the following command to format your code:
make format
Testing
Running Tests
# Run all tests
make test
# Run unit tests only
pytest tests/unit
# Run integration tests
pytest tests/integration
# Run tests with coverage
pytest --cov=robodsl tests/
Writing Tests
- Write tests for all new functionality
- Follow the Arrange-Act-Assert pattern
- Use descriptive test names
- Keep tests independent and isolated
- Mock external dependencies
Pull Request Process
- Ensure your code passes all tests and linters
- Update documentation as needed
- Add or update tests for your changes
- Keep your pull request focused on a single feature or bug fix
- Write a clear commit message following the Conventional Commits specification:
```
[optional scope]:
[optional body]
[optional footer] ```
Example: ``` feat(parser): add support for custom message types
Added support for defining custom message types in the DSL syntax. This allows users to create their own message types with custom fields.
Fixes #123 ```
- Reference any related issues in your pull request description
- Request reviews from at least one maintainer
Reporting Issues
When reporting issues, please include:
- A clear, descriptive title
- Steps to reproduce the issue
- Expected behavior
- Actual behavior
- Environment details (OS, Python version, ROS2 version, etc.)
- Any relevant error messages or logs
Feature Requests
For feature requests, please:
- Describe the feature you'd like to see
- Explain why this feature would be useful
- Provide any relevant examples or use cases
- Consider contributing the feature yourself if possible
Documentation
Good documentation is crucial for the success of the project. When making changes:
- Update relevant documentation
- Add docstrings to new functions and classes
- Include examples where appropriate
- Keep the README up to date
License
By contributing to RoboDSL, you agree that your contributions will be licensed under the MIT License.
Acknowledgments
Thank you to all the contributors who have helped make RoboDSL better!