Contributing Guidelines
Relevant source files
The following files were used as context for generating this wiki page:
This document provides a comprehensive guide for contributors to the Daytona project. It covers the technical requirements, community standards, and workflow processes necessary for contributing code, documentation, or feedback to the ecosystem.
Daytona welcomes contributions to enhance functionality, fix bugs, or add new capabilities. All participants are expected to uphold the project's standards of conduct and follow specific technical workflows to ensure code quality and legal compliance through the Developer Certificate of Origin (DCO).
Sources: CONTRIBUTING.md:1-5, CONTRIBUTING.md:46-50
Community Standards and Conduct
Participation in the Daytona community is governed by the Contributor Covenant Code of Conduct. This applies to all community spaces and official representations of the project.
Expected Behavior
Contributors are expected to demonstrate empathy, kindness, and respect for differing viewpoints. Positive contributions include giving constructive feedback and accepting responsibility for mistakes.
Unacceptable Behavior
Unacceptable behaviors include sexualized language, trolling, personal or political attacks, harassment, and the unauthorized publication of private information.
Enforcement Process
Community leaders investigate reports of misconduct and may issue warnings, temporary bans, or permanent bans based on the severity and frequency of the violation. Reports can be sent to codeofconduct@daytona.io.
Sources: CODE_OF_CONDUCT.md:1-75, CONTRIBUTING.md:18-23
Contribution Workflow
The code contribution process follows a structured path from local development to being merged into the main branch.
The diagram above illustrates the standard lifecycle of a code contribution in the Daytona repository.
Technical Requirements for PRs
- Forking: Changes must be made in a personal fork of the repository.
- Issue Association: Every PR should be associated with a GitHub issue.
- Documentation: Contributors must generate new CLI documentation using
./hack/generate-cli-docs.shand new API clients using./hack/swagger.shif relevant changes are made. - Linting: The project uses
golangci-lint. Contributors must rungolangci-lint runin the root directory to ensure no errors exist. - Package Management:
yarnmust be used for Node.js dependencies.
Sources: CONTRIBUTING.md:52-73, PREPARING_YOUR_CHANGES.md:5-15
Preparing Changes and Commits
Daytona enforces strict rules regarding commit structure and legal sign-offs to maintain a clean and legally sound history.
Commit Standards
- Squashing: All changes in a PR must be squashed into a single, descriptive commit.
- DCO Sign-off: Every commit must be signed off to comply with the Developer Certificate of Origin v1.1. This is done using the
--signoffflag in git. - Format: While no strict format is mandated, an optional template is provided using a present-tense verb and a capitalized first letter.
Developer Certificate of Origin (DCO)
The DCO requires the use of a "real name," defined as the name the contributor conveys to the community to be identified, allowing for future contact if legal issues arise regarding the contribution.
Sources: PREPARING_YOUR_CHANGES.md:17-84, CONTRIBUTING.md:61-65
Coding Style and Conventions
To maintain consistency across the codebase, Daytona follows specific naming conventions and architectural patterns, particularly for API and service layers.
Service Method Naming
Service methods should avoid including the model name.
| Action | Recommended Name | Discouraged Name |
|---|---|---|
| Create Sandbox | Create | CreateSandbox |
| Find Sandbox | Find | FindSandbox |
API and Service Mapping
The following table defines the mapping between HTTP methods and the corresponding logic layers:
| HTTP Method | Controller / Service / Store Action |
|---|---|
| POST | Create or Update |
| DELETE | Delete |
| PUT | Save |
| GET | Find or List |
Sources: CONTRIBUTING.md:95-120
SDK Publishing and Packaging
Daytona maintains SDKs for Python, TypeScript, and Ruby. Specific guidelines exist for those wishing to package or distribute the software independently.
Packaging Guidelines
Third-party distributors must not name their packages daytona to prevent confusion with official distributions. Acceptable names include unofficial-daytona-package.
Versioning Policy
Releases follow Semantic Versioning (SemVer) for MAJOR.MINOR.PATCH releases. Prerelease formats vary by language ecosystem:
| SDK Language | Prerelease Format | Example |
|---|---|---|
| TypeScript | X.Y.Z-alpha.1 | 0.126.0-rc.1 |
| Python | X.Y.Za1 | 1.2.0b1 |
| Ruby | X.Y.Z.alpha.1 | 0.126.0.beta.1 |
Sources: PACKAGING.md:7-17, PUBLISHING.md:71-105
Security Vulnerability Reporting
Security is a priority, and vulnerabilities should never be reported via public GitHub issues.
Reporting Channels
- Email:
security@daytona.io - GitHub: Use the private "security advisory" feature.
Disclosure Timeline
Daytona targets remediation within 90 days of a validated report. Researchers are requested to wait 30 days after a patch is released before public disclosure.
Sources: SECURITY.md:3-15, SECURITY.md:84-93
Summary
Contributing to Daytona requires adherence to technical workflows (DCO sign-off, linting, doc generation) and community standards (Code of Conduct). By following these guidelines, contributors ensure that the project remains a high-quality, legally compliant, and welcoming environment for all developers.