Thank you for your interest in contributing to FUSION! We value your contributions and want to make the process as smooth as possible for everyone involved. This document outlines how you can contribute, our coding guidelines, the pull request process, and our code of conduct.
Before contributing, we recommend:
- Read the Documentation: Our comprehensive documentation is available at https://sdnnetsim.github.io/FUSION/
- Understand the Codebase: Review the Developer Documentation to understand the project structure
- Set Up Your Environment: Follow the Installation Guide to get started
-
Report Issues: If you find a bug or have a suggestion for an improvement, please report it using the project's issue tracker. Be sure to search for existing issues before creating a new one.
-
Submit Pull Requests: If you'd like to contribute code or documentation, please submit a pull request (PR). Ensure your PR has a clear title and description, and follows our coding guidelines and PR process outlined below.
-
Review Contributions: You can also contribute by reviewing pull requests submitted by others. Providing feedback and suggestions can greatly improve the quality of contributions.
FUSION follows strict coding standards to ensure consistency and maintainability. Please review our comprehensive coding standards document before contributing:
See CODING_STANDARDS.md for complete guidelines.
-
Naming Conventions:
- Functions:
snake_caseverbs (e.g.,load_config,validate_data) - Classes:
PascalCase - Use type hints instead of type suffixes in variable names
- Functions:
-
Code Organization:
- Each module must have a
README.md - Tests in
tests/subdirectory within each module
- Each module must have a
-
Type Annotations:
- All function parameters and returns must have type annotations
- Use modern Python type hints
-
Documentation:
- Use Sphinx-style docstrings
- Use
# TODO:for planned enhancements - Use
# FIXME:for areas needing fixes
-
Quality Tools:
- Format and lint code with
ruff - Type check with
mypy - Test with
pytest - Run
make validatebefore submitting
- Format and lint code with
- Fork and Branch: Fork the repository and create your branch from
main. - Code Quality: Ensure your code passes all quality checks:
make lint # Run all pre-commit checks make test # Run unit tests make validate # Full validation (lint + tests)
- Documentation: Update relevant documentation and add tests for new features.
- Commit Messages: Follow conventional commit format. See our Commit Message Guide.
- PR Template: Fill out the PR template completely when submitting.
- Review: You need sign-off from two other developers before merging.
Check the PR template for specific requirements.
The GitHub issue tracker is our primary medium for raising and resolving issues.
When reporting bugs, please use the bug report template and include:
- Clear description of the issue
- Steps to reproduce
- Expected vs actual behavior
- Environment details (OS, Python version, etc.)
- Relevant logs or error messages
When requesting features, please use the feature request template and include:
- Clear description of the proposed feature
- Use case and motivation
- Potential implementation approach
- Any relevant examples or references
We use Sphinx for documentation. The full documentation is hosted at:
https://sdnnetsim.github.io/FUSION/
Key documentation sections:
- Getting Started - Installation and setup
- Developer Guide - Module documentation and architecture
- API Reference - Auto-generated API docs
When contributing documentation:
- Source files are in
docs/directory - Use reStructuredText (
.rst) format - Build locally with
make -C docs html
Our project adheres to a Code of Conduct that we expect all contributors to follow. Please read the Code of Conduct document before participating in our community.
If you have any questions or comments about contributing to the FUSION project, please feel free to reach out to us. We're more than happy to help you get started or clarify any points.
Thank you for contributing to the FUSION project!