How to Contribute
Thank you for considering contributing to Beever Atlas! We welcome contributions from everyone, whether you're fixing bugs, adding features, improving documentation, or sharing ideas.
Ways to Contribute
Code
- Fix bugs and implement features
- Write tests for new functionality
- Improve performance and code quality
Documentation
- Improve existing documentation
- Write tutorials and guides
- Add code examples and use cases
Bug Reports
- Report issues you encounter
- Provide reproduction steps
- Suggest potential fixes
Feature Requests
- Propose new features
- Share use cases
- Provide feedback on proposals
Community
- Help other users
- Share your experiences
- Participate in discussions
Getting Started
Fork and Clone
- Fork the repository on GitHub
- Clone your fork:
git clone https://github.com/your-username/beever-atlas.git
cd beever-atlas- Add upstream remote:
git remote add upstream https://github.com/beever-atlas/beever-atlas.gitSet Up Development Environment
See the Development Setup guide for detailed instructions.
Quick start:
# Install Python dependencies
uv sync
# Install bot dependencies
cd bot && npm install
# Start infrastructure
docker compose up -d
# Run the backend
uv run uvicorn beever_atlas.server.app:app --reload
# Run the frontend (in another terminal)
cd web && npm run devMaking Changes
Branch Naming
Use descriptive branch names:
fix/description-of-bugfor bug fixesfeature/description-of-featurefor new featuresdocs/description-of-changefor documentationrefactor/description-of-refactorfor refactoring
Commit Messages
Follow conventional commits format:
type(scope): description
[optional body]
[optional footer]Types:
fix: Bug fixfeat: New featuredocs: Documentation changesstyle: Code style changes (formatting)refactor: Code refactoringtest: Adding or updating testschore: Build process or tooling changes
Examples:
fix(slack): handle rate limit errors gracefully
feat(api): add streaming support for ask endpoint
docs(contributing): add pull request guidelinesCode Style
Follow the project's code style:
Python
- Use
rufffor linting and formatting - Run
uv run ruff check .to check - Run
uv run ruff format .to format
TypeScript
- Use Prettier for formatting
- Run
npm run formatin bot/ directory
Tests
- Write tests for new functionality
- Ensure all tests pass before submitting
- Aim for good test coverage
Pull Request Process
Before Submitting
Update Documentation
- Document new features
- Update relevant guides
- Add examples if applicable
Add Tests
- Write tests for your changes
- Ensure all tests pass
- Check coverage with
uv run pytest --cov
Run Linters
# Python
uv run ruff check .
uv run ruff format .
# TypeScript
cd bot && npm run lint && npm run formatSync Your Branch
git fetch upstream
git rebase upstream/mainSubmitting a PR
- Push to your fork:
git push origin feature/your-feature-name-
Create a Pull Request on GitHub
-
Fill out the PR template:
- Description of changes
- Related issues (fixes #123)
- Testing steps
- Screenshots (if applicable)
- Wait for review
- Address review feedback
- Make requested changes
- Keep the conversation going
Review Guidelines
As a contributor, you can also review PRs:
- Be constructive and respectful
- Ask questions if something is unclear
- Suggest improvements
- Test the changes if possible
Issue Templates
Bug Report
When reporting a bug, include:
Description
- Clear description of the problem
- Expected behavior
- Actual behavior
- Steps to reproduce
Environment
- OS and version
- Python/Node version
- Beever Atlas version
- Related configuration
Reproduction
# Commands or code to reproduceExpected behavior What should happen
Actual behavior What actually happens
Screenshots/logs If applicable
Feature Request
When proposing a feature:
Problem
- What problem does it solve?
- Who is it for?
Proposed Solution
- Detailed description
- API changes (if any)
- UI/UX considerations
Alternatives
- Other approaches considered
- Why this approach is best
Additional Context
- Examples
- Mockups
- References
Development Guidelines
Architecture Decisions
For significant changes, start a discussion first:
- Open an issue with the
designlabel - Describe the problem and proposed solution
- Get feedback from maintainers
- Create an ADR (Architecture Decision Record) if needed
Breaking Changes
Avoid breaking changes when possible. If necessary:
- Clearly document the breakage
- Provide migration guide
- Deprecate old functionality first
- Update all internal usage
Performance
Consider performance impact:
- Profile before optimizing
- Add benchmarks for critical paths
- Document trade-offs
Security
- Never commit secrets or credentials
- Follow security best practices
- Report vulnerabilities privately
Testing
Running Tests
# Run all tests
uv run pytest
# Run specific test file
uv run pytest tests/test_specific.py
# Run with coverage
uv run pytest --cov=beever_atlas --cov-report=html
# Run specific test
uv run pytest tests/test_specific.py::test_functionWriting Tests
Follow testing guidelines:
- Use pytest fixtures for common setup
- Mock external services (Slack, Discord, etc.)
- Test both success and failure cases
- Use descriptive test names
Communication
Channels
- GitHub Issues: Bug reports, feature requests
- GitHub Discussions: Questions, ideas
- Discord: Community chat (if available)
- Email: security@beever-atlas.com for security issues
Getting Help
- Check existing issues and discussions
- Read the documentation
- Ask questions in discussions
- Be patient and respectful
Recognition
Contributors are recognized in:
- CONTRIBUTORS.md file
- Release notes
- Project website (with permission)
Thank you for contributing to Beever Atlas!
Code of Conduct
Please read and follow our Code of Conduct.
License
By contributing, you agree that your contributions will be licensed under the Apache 2.0 License.