Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
234 lines (180 loc) · 5.27 KB

CONTRIBUTING.md

File metadata and controls

234 lines (180 loc) · 5.27 KB

Contributing

Thank you for considering contributing! This document outlines the process for contributing to this project.

When contributing to this repository, please first discuss the change you wish to make via issue, email, or any other method with the owners of this repository before making a change.

Please note we have a code of conduct, please follow it in all your interactions with the project.

Development Workflow

We use git-flow workflow and conventional commits.

Branch Structure

  • main - Production-ready code
  • develop - Development branch
  • feature/* - New features
  • bugfix/* - Bug fixes
  • hotfix/* - Critical production fixes

Getting Started

  1. Fork the repository
  2. Clone your fork: git clone https://github.com/your-username/wp-boot.git
  3. Create a feature branch: git checkout -b feature/your-feature-name
  4. Install dependencies: composer install
  5. Make your changes
  6. Run tests: composer test
  7. Run quality checks: composer qa
  8. Commit using conventional commits
  9. Push and create a pull request

Development Setup

Requirements

  • PHP 8.0 or higher
  • Composer
  • Git

Installation

git clone https://github.com/wp-spaghetti/wp-boot.git
cd wp-boot
composer install

Running Tests

# Run all tests
composer test

# Run specific test suite
vendor/bin/phpunit tests/FooTest.php

# Run with coverage
vendor/bin/phpunit --coverage-html coverage/

Code Quality

# Run all quality checks
composer quality

# Individual tools
composer lint          # Linters
composer analysis      # Static analysis
composer security      # Security check
composer quality       # Code quality

Coding Standards

PHP Standards

  • Follow PSR-12 coding standard
  • Use strict typing: declare(strict_types=1);
  • Document all public methods with PHPDoc
  • Use meaningful variable and method names

Commit Messages

We use Conventional Commits:

type(scope): description

[optional body]

[optional footer]

Types:

  • feat: New features
  • fix: Bug fixes
  • docs: Documentation changes
  • style: Code style changes (no logic changes)
  • refactor: Code refactoring
  • test: Adding or updating tests
  • chore: Maintenance tasks

Examples:

feat(environment): add support for custom environment detection
fix(docker): improve container detection accuracy
docs(readme): update installation instructions
test(hooks): add comprehensive hook testing

Code Style

<?php

declare(strict_types=1);

namespace WpSpaghetti\ExampleNamespace;

/**
 * Class documentation.
 */
class ExampleClass
{
    /**
     * Method documentation.
     */
    public function exampleMethod(string $param): bool
    {
        // Method implementation
        return true;
    }
}

Testing Guidelines

Test Structure

  • Unit tests in tests/ directory
  • Test files should end with Test.php
  • Use descriptive test method names
  • Include both positive and negative test cases

Test Example

public function testMethodReturnsExpectedValue(): void
{
    $result = ExampleClass::get('TEST_VAR', 'default');
    self::assertSame('expected', $result);
}

Mock Data

Use the provided mock functions for testing:

  • set_mock_*()

Documentation

Code Documentation

  • All public methods must have PHPDoc blocks
  • Include @param and @return annotations
  • Document complex logic with inline comments
  • Use clear, concise language

README Updates

When adding new features:

  • Update the feature list
  • Add usage examples
  • Update the API reference if needed

Pull Request Process

  1. Create Feature Branch

    git checkout develop
git checkout -b feature/your-feature

  2. Make Changes

    • Write code following the standards above
    • Add/update tests for your changes
    • Update documentation if needed

  3. Test Your Changes

    composer quality  # Run all quality checks
composer test     # Run all tests

  4. Commit Changes

    git add .
git commit -m "feat: add new feature description"

  5. Push and Create PR

    git push origin feature/your-feature

    Then create a pull request against the develop branch.

PR Requirements

  • All tests must pass
  • Code coverage should not decrease
  • Follow the PR template
  • Link to related issues
  • Use conventional commit messages

Release Process

Releases are automated through GitHub Actions:

  1. Merge to main triggers release workflow
  2. Conventional commits determine version bump
  3. Changelog is automatically updated
  4. GitHub release is created
  5. Packagist is notified

Security

If you discover a security vulnerability, please follow our Security Policy.

Questions?

  • Create an issue for questions about usage
  • Join discussions for feature planning
  • Contact maintainers for sensitive issues

License

By contributing, you agree that your contributions will be licensed under the GPL-3.0-or-later license.

Recognition

Contributors will be recognized in:

  • GitHub contributors list
  • Release notes for significant contributions
  • README acknowledgments for major features

Thank you for contributing! 🎉