Contributing Guidelines

Thank you for considering contributing to Divekit! This document outlines our contribution process and guidelines.

Code of Conduct

• Be respectful and inclusive
• Follow professional standards
• Help others learn and grow
• Report unacceptable behavior

Getting Started

1. Fork the repository
2. Set up your development environment
3. Create a feature branch
4. Make your changes
5. Submit a pull request

Development Process

Branching Strategy

• main: Production-ready code
• develop: Integration branch
• Feature branches: feature/your-feature
• Bugfix branches: fix/issue-description

Commit Messages

Follow conventional commits:

type(scope): description

[optional body]

[optional footer]

The commit message header consists of three parts:

• type: Categorizes the type of change (see below)
• scope: Indicates the section of the codebase being changed (e.g. cli, core, config, parser)
• description: Brief description of the change in imperative mood

Examples:

• feat(cli): add new flag for verbose output
• fix(parser): handle empty config files correctly
• docs(readme): update installation instructions
• test(core): add tests for user authentication

Types:

• feat: New feature or functionality
• fix: Bug fix
• docs: Documentation changes
• style: Formatting, missing semicolons, etc. (no code changes)
• refactor: Code restructuring without changing functionality
• test: Adding or modifying tests
• chore: Maintenance tasks, dependencies, etc.

The body should explain the “why” of the change, while the description explains the “what”.

Pull Requests

1. Update documentation
2. Add/update tests
3. Ensure CI passes
4. Request review
5. Address feedback

Code Style

• Follow Go best practices and idioms
• Use gofmt for consistent formatting
• Follow the official Go Code Review Comments
• Use golint and golangci-lint
• Write clear, idiomatic Go code
• Keep functions focused and well-documented

Testing

• Write unit tests using the standard testing package
• Use table-driven tests where appropriate
• Aim for good test coverage
• Write integration tests for complex functionality
• Use go test for running tests
• Consider using testify for assertions

Documentation

• Write clear godoc comments
• Update README.md and other documentation
• Include examples in documentation
• Document exported functions and types
• Keep documentation up to date with changes

Review Process

1. Automated checks (golangci-lint, tests)
2. Code review
3. Documentation review
4. Final approval
5. Merge

Release Process

1. Version bump
2. Changelog update
3. Tag release
4. Documentation update