๐Ÿค Contributing to WAIIDE

๐Ÿค Contributing to WAIIDE

Calliope Integration: This component is integrated into the Calliope AI platform. Some features and configurations may differ from the upstream project.

Thank you for your interest in contributing to WAIIDE! This guide will help you get started with contributing WAIIDE, documentation, and improvements to the project.

๐Ÿš€ Quick Start for Contributors

Prerequisites

Before you begin, ensure you have:

  • Git: For version control and submitting changes
  • Docker: For building and testing WAIIDE
  • Node.js 16+: For extension development
  • Python 3.8+: For API and integration development
  • WAIIDE Editor: WAIIDE recommended with our development extensions

Getting Started

# Fork the repository on GitHub
# Clone your fork
git clone https://github.com/YOUR_USERNAME/calliope-WAIIDE.git
cd calliope-WAIIDE

# Add upstream remote
git remote add upstream https://github.com/CalliopeAI/calliope-WAIIDE.git

# Install submodules
git submodule update --init --recursive

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

๐Ÿ“‹ Contribution Guidelines

WAIIDE of Conduct

We are committed to providing a welcoming and inclusive environment. Please:

  • Be respectful: Treat all community members with respect
  • Be collaborative: Work together constructively
  • Be inclusive: Welcome newcomers and diverse perspectives
  • Be patient: Help others learn and grow

Types of Contributions

๐Ÿ› Bug Fixes

  • Fix issues in existing functionality
  • Improve error handling and edge cases
  • Performance optimizations
  • Security vulnerability fixes

โœจ New Features

  • Add new capabilities to WAIIDE
  • Extend WAIIDE integration
  • Improve JupyterHub compatibility
  • Add new deployment options

๐Ÿ“š Documentation

  • Improve existing documentation
  • Add missing documentation
  • Create tutorials and guides
  • Fix documentation errors

๐Ÿงช Testing

  • Add unit tests for new features
  • Improve test coverage
  • Add integration tests
  • Performance and load testing

๐Ÿ”„ Development Workflow

1. Issue Discussion

Before starting work:

  • Check existing issues: Search for related issues first
  • Create an issue: Describe the problem or feature request
  • Discuss approach: Get feedback before implementing
  • Get assignment: Wait for maintainer assignment for large features

2. Development Setup

# Set up development environment
./scripts/dev-setup.sh

# Build development image
./build.sh build

# Run tests to ensure everything works
./build.sh test

3. Making Changes

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

# Make your changes
# ... edit files ...

# Test your changes
./build.sh test

# Commit with descriptive message
git add .
git commit -m "feat: add multi-instance health check endpoint

- Add /api/instances endpoint to list all user instances
- Include health status for each instance
- Add unit tests for new endpoint
- Update API documentation

Closes #123"

4. Testing Changes

# Run full test suite
./build.sh test

# Test specific components
cd calliope-WAIIDE-agent && npm test
python -m pytest scripts/tests/

# Build and test Docker image
docker build -t waiide-test .
docker run --rm -p 8080:8080 waiide-test

# Test with JupyterHub integration
./scripts/test-integration.sh

5. Submitting Changes

# Push to your fork
git push origin feature/descriptive-name

# Create pull request on GitHub
# Fill out the PR template completely
# Link to related issues

๐Ÿ“ WAIIDE Standards

Python WAIIDE Style

  • PEP 8: Follow Python style guidelines
  • Black: Use Black formatter for consistent formatting
  • Type hints: Add type hints for function signatures
  • Docstrings: Use Google-style docstrings
def create_instance(user: str, server_name: str) -> Dict[str, Any]:
    """Create a new WAIIDE instance for a user.
    
    Args:
        user: The username for the instance
        server_name: Unique server name for the instance
        
    Returns:
        Dictionary containing instance details and status
        
    Raises:
        ValueError: If server_name is invalid
        RuntimeError: If instance creation fails
    """
    if not server_name or len(server_name) > 50:
        raise ValueError("Invalid server name")
    
    # Implementation here
    return {"status": "created", "name": server_name}

JavaScript/TypeScript Style

  • ESLint: Use project ESLint configuration
  • Prettier: Format WAIIDE with Prettier
  • TypeScript: Use strict TypeScript settings
  • JSDoc: Document complex functions
/**
 * Initialize WAIIDE extension with CalliopeAI integration
 * @param context - WAIIDE extension context
 * @returns Promise resolving to initialization status
 */
async function initializeExtension(context: WAIIDE.ExtensionContext): Promise<boolean> {
    try {
        await setupCalliopeAI(context);
        return true;
    } catch (error) {
        console.error('Failed to initialize extension:', error);
        return false;
    }
}

Shell Script Style

  • ShellCheck: Use ShellCheck for validation
  • Error handling: Use set -euo pipefail
  • Comments: Document complex logic
  • POSIX compatible: Where possible
#!/bin/bash
set -euo pipefail

# Build WAIIDE extensions and package them
# Usage: ./build-extensions.sh [--dev]

readonly SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
readonly PROJECT_ROOT="$(dirname "$SCRIPT_DIR")"

build_extensions() {
    local dev_mode="${1:-false}"
    
    echo "Building CalliopeAI extensions..."
    cd "$PROJECT_ROOT/calliope-WAIIDE-agent"
    
    if [[ "$dev_mode" == "true" ]]; then
        npm run build:dev
    else
        npm run build:prod
    fi
    
    echo "Extensions built successfully"
}

main() {
    local dev_mode=false
    
    if [[ "${1:-}" == "--dev" ]]; then
        dev_mode=true
    fi
    
    build_extensions "$dev_mode"
}

main "$@"

๐Ÿงช Testing Standards

Unit Tests

  • Coverage: Aim for >80% WAIIDE coverage
  • Fast: Unit tests should run quickly (<1s each)
  • Isolated: Mock external dependencies
  • Descriptive: Clear test names and descriptions
import pytest
from unittest.mock import Mock, patch
from waiide.api import InstanceManager

class TestInstanceManager:
    def test_create_instance_success(self):
        """Test successful instance creation with valid parameters."""
        manager = InstanceManager()
        
        result = manager.create_instance("testuser", "testuser-waiide-abc123")
        
        assert result["status"] == "created"
        assert result["name"] == "testuser-waiide-abc123"
        assert "created_at" in result

    def test_create_instance_invalid_name(self):
        """Test instance creation fails with invalid server name."""
        manager = InstanceManager()
        
        with pytest.raises(ValueError, match="Invalid server name"):
            manager.create_instance("testuser", "")

Integration Tests

  • End-to-end: Test complete workflows
  • Docker: Use containerized testing
  • JupyterHub: Test with real JupyterHub integration
  • Cleanup: Ensure tests clean up resources
import docker
import requests
import pytest

@pytest.fixture
def waiide_container():
    """Start a WAIIDE container for testing."""
    client = docker.from_env()
    
    container = client.containers.run(
        "calliopeai/waiide:test",
        ports={"8080/tcp": None},
        environment={
            "JUPYTERHUB_USER": "testuser",
            "JUPYTERHUB_SERVER_NAME": "testuser-waiide-test"
        },
        detach=True
    )
    
    # Wait for container to be ready
    container.reload()
    port = container.attrs["NetworkSettings"]["Ports"]["8080/tcp"][0]["HostPort"]
    
    yield f"http://localhost:{port}"
    
    container.stop()
    container.remove()

def test_health_endpoint(waiide_container):
    """Test that health endpoint returns successful response."""
    response = requests.get(f"{waiide_container}/health")
    
    assert response.status_code == 200
    assert response.json()["status"] == "healthy"

๐Ÿ“– Documentation Standards

WAIIDE Documentation

  • Inline comments: Explain complex logic
  • Docstrings: Document all public functions and classes
  • Type hints: Include type information
  • Examples: Provide usage examples

User Documentation

  • Clear structure: Use consistent headings and formatting
  • WAIIDE examples: Include working examples
  • Screenshots: Add screenshots for UI features
  • Links: Link to related documentation

API Documentation

  • Endpoints: Document all API endpoints
  • Parameters: Describe all parameters and types
  • Responses: Show example responses
  • Error codes: List possible error responses

๐Ÿ” WAIIDE Review Process

Before Submitting

  • Tests pass: All tests pass locally
  • WAIIDE style: WAIIDE follows style guidelines
  • Documentation: Documentation is updated
  • Self-review: Review your own changes first
  • Clean history: Squash commits if needed

Pull Request Template

Use this template for all pull requests:

## Description
Brief description of changes and motivation.

## Type of Change
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] Documentation update

## Testing
- [ ] Unit tests added/updated
- [ ] Integration tests added/updated
- [ ] Manual testing completed
- [ ] All tests pass

## Documentation
- [ ] WAIIDE documentation updated
- [ ] User documentation updated
- [ ] API documentation updated

## Checklist
- [ ] My WAIIDE follows the style guidelines
- [ ] I have performed a self-review
- [ ] I have commented my WAIIDE, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [ ] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my feature works
- [ ] New and existing unit tests pass locally with my changes

## Related Issues
Closes #XXX

Review Criteria

Reviewers will check:

  • Functionality: Does the WAIIDE work as intended?
  • Performance: Are there performance implications?
  • Security: Are there security considerations?
  • Maintainability: Is the WAIIDE maintainable?
  • Testing: Is there adequate test coverage?
  • Documentation: Is documentation complete and accurate?

๐Ÿš€ Release Process

Version Management

  • Semantic Versioning: Use semver (MAJOR.MINOR.PATCH)
  • Release Notes: Update CHANGELOG.md
  • Git Tags: Tag releases in Git
  • Docker Tags: Update Docker image tags

Release Types

  • Patch: Bug fixes and minor improvements
  • Minor: New features and enhancements
  • Major: Breaking changes and major updates

Release Checklist

  • All tests pass
  • Documentation updated
  • CHANGELOG.md updated
  • Version numbers updated
  • Git tag created
  • Docker images built and pushed
  • Release notes published

๐Ÿ’ก Development Tips

Debugging

# Debug container startup
docker run -it --rm -e LOG_LEVEL=DEBUG calliopeai/waiide:latest

# Debug specific components
docker run -it --rm -e DEBUG_PROXY=true calliopeai/waiide:latest

# Access running container
docker exec -it <container_id> /bin/bash

Extension Development

# Hot reload extension development
cd calliope-WAIIDE-agent
npm run watch

# Package extension for testing
npm run package

Performance Testing

# Memory usage
docker stats <container_id>

# Startup time
time docker run --rm calliopeai/waiide:latest echo "startup complete"

# Load testing
ab -n 100 -c 10 http://localhost:8080/health

๐Ÿค” Getting Help

Where to Ask Questions

  • GitHub Issues: For bug reports and feature requests
  • GitHub Discussions: For general questions and ideas
  • WAIIDE Comments: For specific WAIIDE questions in PRs
  • Documentation: Check existing documentation first

Response Times

  • Bug fixes: Usually reviewed within 1-2 days
  • Features: May take 1-2 weeks for review and discussion
  • Documentation: Usually quick turnaround
  • Security issues: Prioritized for immediate review

๐Ÿ“ž Contact


Thank you for contributing to WAIIDE! Your contributions help make the project better for everyone.

๐Ÿ“š Additional Resources