Contributing Guidelines
Relevant source files
The following files were used as context for generating this wiki page:
- CONTRIBUTING.md
- CODE_OF_CONDUCT.md
- SECURITY.md
- README.md
- Makefile (referenced via CONTRIBUTING.md)
- .golangci.yml (referenced via CONTRIBUTING.md)
These guidelines outline the standards and processes for contributing to the Daco CLI project. The goal is to ensure code quality, maintainability, and a welcoming environment for all participants. Daco CLI follows the 12-Factor App principles where applicable and prioritizes simplicity over cleverness.
Sources: CONTRIBUTING.md:1-25
Development Environment Setup
To begin contributing, developers must set up a local Go environment. The project utilizes a Makefile to automate setup and build tasks.
Prerequisites
| Tool | Version | Purpose |
|---|---|---|
| Go | 1.23.0+ | Core language runtime for build and execution |
| golangci-lint | Latest | Static analysis and code linting |
| GoReleaser | v2+ | (Optional) Local release artifact testing |
| Make | Any | Build and environment automation |
Sources: CONTRIBUTING.md:27-32
Initial Setup Commands
The following flow represents the standard initialization for a local development branch:
The make setup command is critical as it configures the necessary git hooks, including pre-commit hooks for commit message validation.
Sources: CONTRIBUTING.md:34-45, CONTRIBUTING.md:100-102
Design and Quality Principles
Contributors are expected to adhere to four core design principles to maintain project integrity:
- Simplicity Over Cleverness: Code should be clear and readable rather than relying on complex abstractions.
- Idiomatic Patterns: Follow standard Go conventions and ecosystem norms.
- Minimal Dependencies: Favor the Go standard library; only add external dependencies after deliberate consideration.
- Defensive Programming: Explicitly handle errors, validate all inputs, and ensure graceful failure modes.
Sources: CONTRIBUTING.md:19-25
Contribution Workflow
The project uses a standard Fork-and-Pull-Request model. All non-trivial changes should begin with an issue discussion to gain maintainer approval before work commences.
Pull Request Lifecycle
Commit Conventions
Daco CLI enforces Conventional Commits. This standard allows for automated changelog generation and versioning.
| Type | Description |
|---|---|
feat | A new feature |
fix | A bug fix |
docs | Documentation updates |
refactor | Code changes that neither fix a bug nor add a feature |
test | Adding missing tests or correcting existing tests |
chore | Maintenance tasks (build, CI, etc.) |
Breaking changes must be indicated with a ! after the type (e.g., feat!: breaking change).
Sources: CONTRIBUTING.md:100-124
Project Architecture
Understanding the repository structure is essential for placing new contributions correctly:
cmd/daco/: The main entry point for the CLI.internal/commands/: Definitions for individual CLI commands (e.g.,ports describe).internal/opendpi/: Logic for parsing OpenDPI specifications.internal/translate/: Schema translation logic for various formats (Avro, Protobuf, Spark, etc.).internal/config/: Configuration file handling (daco.yaml).
Sources: CONTRIBUTING.md:47-64, cmd/gendocs/main.go:21-41
Code of Conduct
All contributors must adhere to the Contributor Covenant 3.0. We prioritize a safe, equitable, and welcoming environment.
Encouraged vs Restricted Behaviors
- Encouraged: Kind and honest engagement, respecting different viewpoints, and accepting constructive feedback.
- Restricted: Harassment, character attacks, stereotyping, and failing to credit sources.
Issues regarding conduct violations should be reported to community@dacolabs.com.
Sources: CODE_OF_CONDUCT.md:5-50, CODE_OF_CONDUCT.md:70-75
Security and Vulnerabilities
Security issues should never be reported via public GitHub issues. Instead, contributors should send reports to security@dacolabs.com. The team aims to acknowledge reports within 48 hours and provide an assessment within 5 business days.
Sources: SECURITY.md:11-25
Automation (Makefile Targets)
The Makefile serves as the primary interface for local development tasks.
| Target | Description |
|---|---|
make build | Compiles the CLI binary into the ./bin directory |
make test | Executes the test suite with the Go race detector enabled |
make lint | Runs golangci-lint to ensure code style compliance |
make format | Formats code using gofmt and goimports |
make release-snapshot | Simulates a release build locally using GoReleaser |
Sources: CONTRIBUTING.md:195-207, CONTRIBUTING.md:66-88