Contributing to GoliteFlow

Thank you for your interest in contributing to GoliteFlow! This document provides guidelines and information for contributors.

📋 Table of Contents

Getting Started

Prerequisites

Development Setup

  1. Fork the Repository

    # Fork on GitHub, then clone your fork
git clone https://github.com/YOUR_USERNAME/goliteflow.git
cd goliteflow

  2. Add Upstream Remote

    git remote add upstream https://github.com/sintakaridina/goliteflow.git

  3. Install Dependencies

    go mod tidy

  4. Verify Setup

    go test ./...
go build ./cmd/goliteflow

Contributing Process

1. Create a Feature Branch

# Make sure you're on main and up to date
git checkout main
git pull upstream main

# Create your feature branch
git checkout -b feature/your-feature-name

2. Make Your Changes

3. Test Your Changes

# Run all tests
go test ./...

# Run tests with coverage
go test -cover ./...

# Run specific package tests
go test ./internal/parser

# Format your code
go fmt ./...

# Lint your code
go vet ./...

# Build to ensure everything compiles
go build ./cmd/goliteflow

4. Commit Your Changes

# Stage your changes
git add .

# Commit with a descriptive message
git commit -m "feat: add new workflow validation feature

- Add validation for workflow dependencies
- Include comprehensive test coverage
- Update documentation with examples"

5. Push and Create Pull Request

# Push your branch
git push origin feature/your-feature-name

# Create a Pull Request on GitHub

📝 Commit Message Guidelines

We follow the Conventional Commits specification:

Format

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Types

Examples

feat(parser): add support for custom task timeouts

fix(executor): resolve memory leak in task runner

docs: update README with new examples

test(scheduler): add tests for cron validation

Testing Guidelines

Test Requirements

Test Structure

func TestFunctionName(t *testing.T) {
    tests := []struct {
        name     string
        input    InputType
        expected ExpectedType
        wantErr  bool
    }{
        {
            name:     "valid input",
            input:    validInput,
            expected: expectedOutput,
            wantErr:  false,
        },
        {
            name:     "invalid input",
            input:    invalidInput,
            expected: nil,
            wantErr:  true,
        },
    }

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            result, err := FunctionName(tt.input)
            if (err != nil) != tt.wantErr {
                t.Errorf("FunctionName() error = %v, wantErr %v", err, tt.wantErr)
                return
            }
            if !reflect.DeepEqual(result, tt.expected) {
                t.Errorf("FunctionName() = %v, want %v", result, tt.expected)
            }
        })
    }
}

Test Data

Code Style Guidelines

Go Code Style

Documentation

Error Handling

// Good
if err != nil {
    return fmt.Errorf("failed to parse config: %w", err)
}

// Avoid
if err != nil {
    return err
}

Logging

// Use structured logging
logger.Info("workflow started", "workflow", workflowName, "tasks", len(tasks))

// Avoid
logger.Info("workflow started")

📖 Documentation Guidelines

README Updates

When adding new features:

API Documentation

Examples

Bug Reports

Before Submitting

  1. Check existing issues to avoid duplicates
  2. Try to reproduce the issue
  3. Gather relevant information (OS, Go version, etc.)

Bug Report Template

**Bug Description**
A clear description of the bug.

**Steps to Reproduce**

1. Go to '...'
2. Run command '...'
3. See error

**Expected Behavior**
What you expected to happen.

**Actual Behavior**
What actually happened.

**Environment**

- OS: [e.g., Windows 10, macOS 12, Ubuntu 20.04]
- Go Version: [e.g., 1.19.3]
- GoliteFlow Version: [e.g., v1.0.0]

**Additional Context**
Any other relevant information.

Feature Requests

Before Submitting

  1. Check existing feature requests
  2. Consider if the feature aligns with project goals
  3. Think about implementation complexity

Feature Request Template

**Feature Description**
A clear description of the feature.

**Use Case**
Why is this feature needed? What problem does it solve?

**Proposed Solution**
How would you like this feature to work?

**Alternatives Considered**
Other solutions you've considered.

**Additional Context**
Any other relevant information.

Code Review Process

For Contributors

  1. Self-Review: Review your own code before submitting
  2. Address Feedback: Respond to reviewer comments promptly
  3. Update Tests: Add tests for any new functionality
  4. Update Documentation: Keep docs in sync with code changes

For Reviewers

  1. Be Constructive: Provide helpful, specific feedback
  2. Test Changes: Run tests and verify functionality
  3. Check Style: Ensure code follows project guidelines
  4. Approve Promptly: Don’t let PRs sit without review

Pull Request Guidelines

PR Template

## Description

Brief description of changes.

## Type of Change

- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update

## Testing

- [ ] Tests pass locally
- [ ] New tests added for new functionality
- [ ] Manual testing completed

## Checklist

- [ ] Code follows project style guidelines
- [ ] Self-review completed
- [ ] Documentation updated
- [ ] No breaking changes (or clearly documented)

PR Requirements

Release Process

Version Numbering

We follow Semantic Versioning:

Release Checklist

Community Guidelines

Be Respectful

Be Collaborative

Getting Help

Recognition

Contributors will be recognized in:

Additional Resources

Ready to contribute?

Start by forking the repository and creating your first pull request.

Fork on GitHub Getting Started