Skip to content

Contributing to QEDFramework

Thank you for your interest in QEDFramework. This document outlines how contributions are handled and what you can expect as a contributor.

Philosophy

QEDFramework is intentionally small and opinionated. It exists to provide a clean, consistent foundation for building test suites — not to be all things to all projects. Keeping it focused is a feature, not a limitation.

Reporting Bugs

Bug reports are welcome and genuinely useful. Please open a GitHub Issue and include:

  • A clear description of the problem
  • Expected behaviour vs actual behaviour
  • Steps to reproduce
  • Relevant environment details (JDK version, OS, etc.)

Requesting Features

Feature requests can also be submitted as a GitHub Issue. Please describe the use case clearly — not just the feature itself, but the problem it solves.

Feature requests are considered against the goals and direction of the framework. Raising an issue does not guarantee implementation.

Pull Requests

Pull requests are accepted but with the following expectations:

  • Open an issue first. Discuss the change before writing code. This avoids effort on PRs that don't align with the framework's direction.
  • Keep it focused. One concern per PR.
  • Include tests. Changes without test coverage will not be accepted.
  • Follow existing conventions. Code style, naming, and structure should be consistent with the existing codebase.

The maintainer reserves the right to close PRs that do not fit the vision of the framework, regardless of technical quality.

Out of Scope

To set clear expectations, the following types of contributions will generally not be accepted:

  • Alternative patterns that duplicate existing functionality
  • Additional third-party dependencies without a compelling case
  • Framework-level changes that serve a single project's specific needs

Code of Conduct

Be respectful. Constructive disagreement is welcome; personal attacks are not.