Contributing to ATOMCommon
We welcome contributions to ATOMCommon! This guide will help you understand how to contribute effectively to AECOM's engineering development kit.
🚀 Getting started
Prerequisites
- .NET 8.0 SDK or later
- Visual Studio 2022 or VS Code with C# extensions
- Git for version control
- Access to AECOM's GitHub Enterprise
Development setup
- Fork the repository on GitHub Enterprise
- Clone your fork locally:
git clone https://github.com/AECOM-Enterprise/Atom-Common.git cd Atom-Common - Install dependencies:
cd src dotnet restore - Build the solution:
dotnet build - Run tests to ensure everything works:
dotnet test
🔄 Development workflow
ATOMCommon follows a trunk-based development approach with semantic versioning.
Branch naming conventions
Choose the appropriate branch prefix based on your change type:
Feature development (creates alpha prereleases):
feature/add-new-alignment-toolsfeat/pump-station-modelingdev/experimental-geometry
Bug fixes (creates stable patch releases):
bugfix/fix-arc-calculation-errorhotfix/critical-memory-leak
Other changes:
docs/update-api-documentationinfra/update-github-workflows
Pull request process
Create a feature branch from main:
git checkout main git pull origin main git checkout -b feature/your-feature-nameMake your changes following our coding standards
Add tests for new functionality:
# Add tests in corresponding ATOM.Test folder dotnet test src/ATOM.Test/ATOM.Test.csprojUpdate documentation if needed:
- Add XML documentation comments to public APIs
- Update relevant markdown files
- Add usage examples
Commit your changes with clear messages:
git add . git commit -m "Add geometric validation for spiral curves - Implement clothoid spiral validation - Add unit tests for edge cases - Update documentation with examples"Push your branch and create a pull request:
git push origin feature/your-feature-nameCreate pull request on GitHub:
- Use our pull request template
- Add appropriate label (see labeling requirements section)
- Request review from relevant team members
🏷️ Labeling requirements
Every pull request must have exactly one label:
major- Breaking changes that affect existing API contractsminor- New features or enhancements (creates alpha prerelease)patch- Bug fixes and small improvementsinfrastructure- Infrastructure changes (workflows, docs, CI/CD - no release)
Versioning examples
Current: 0.9.0
├── feature/new-tool + minor → 0.10.0-alpha-01
├── bugfix/calc-error + patch → 0.9.1
├── hotfix/memory-leak + patch → 0.9.2
├── infra/update-workflows + infrastructure → No release
├── feature/another-tool + minor → 0.10.0-alpha-02
└── stable release → 0.10.0
🆘 Getting help
Resources
Support channels
- AECOM Teams - Real-time development support
- Code Wiki - AECOM development resources
Thank you for contributing to ATOMCommon! Your expertise helps make this library a powerful tool for AECOM's engineering teams worldwide.