Contributing to QUILL

Contributing to QUILL

Thank you for helping improve QUILL.

QUILL is a screen-reader-first Windows writing environment. Contributions should preserve that core direction: practical keyboard workflows, stable editing, accessible defaults, and clear user control.

Before you start

  1. Read the product expectations and full architecture in docs/QUILL-PRD.md (the single source of truth), and the architecture overview below.
  2. Review project conduct rules in CODE_OF_CONDUCT.md.
  3. Check existing issues and pull requests before starting overlapping work.
  4. Review project decision process in GOVERNANCE.md.

Architecture overview

QUILL is a layered desktop application with strict boundaries that exist to preserve accessibility behavior and testability. The canonical, detailed specification lives in docs/QUILL-PRD.md; this section is the short version contributors need day to day.

Layers

Primary flow

A user action enters through quill/ui/main_frame.py (MainFrame), dispatches to core.commands.CommandRegistry, reads/writes a core.document.Document, persists through io or core.storage, and surfaces the outcome through status updates and platform.windows.sr_announce.announce.

Boundary and runtime rules

Development setup

  1. Install Python 3.12.
  2. Install dependencies:
  3. Run QUILL locally:

Making changes

  1. Create a feature branch from main.
  2. Keep changes focused and small enough to review.
  3. Follow the current module boundaries:
  4. Prefer existing helpers and patterns over introducing parallel paths.
  5. Keep user-facing text clear and accessibility-friendly.

Quality checks

Run these before opening a pull request:

Type-checking is intentionally scoped to quill\core and quill\io. These layers are strict-typed and gated in CI. Do not run an unscoped whole-tree mypy scan: quill\ui is excluded (gradual typing) in pyproject.toml, so a whole-tree run is both slower and noisier without adding signal. Always use the scoped command above.

Optional: install pre-commit hooks

To catch formatting, lint, and undefined-name problems on changed files before they reach CI, install the hooks once:

pip install pre-commit
pre-commit install

The hooks run ruff format, ruff check, and an undefined-name check on the files you are committing. Commits that fail are blocked locally.

If your change updates docs/*.md, regenerate matching artifacts:

Pull request expectations

A strong PR includes:

  1. A clear summary of what changed and why.
  2. Notes on accessibility impact, if any.
  3. Notes on risk or migration impact, if any.
  4. Evidence of the checks you ran.

Please avoid mixing unrelated refactors with feature or bug-fix work.

Contributing a Quillin

Quillins are small, sandboxed extensions that add commands, snippets, menus, and hotkeys to QUILL. Contributing one has its own dedicated path:

Acknowledgments and Attribution

Quill is built on open-source foundations and integrates best practices from the accessibility community:

Contributors who integrate third-party libraries from AccessibleApps or other open-source projects should document the license, purpose, and API contract in the relevant module docstring, and update this section when adding a new external dependency.

Reporting bugs and proposing features

Security issues

Do not open public issues for vulnerabilities. Follow SECURITY.md for private reporting.

Before opening a PR, quickly sanity-check security posture:

  1. No secrets or credentials in code, tests, fixtures, or docs.
  2. No user document content added to logs/diagnostics paths.
  3. New network calls are explicit and user-controlled.
  4. New file/command paths are validated and not shell-interpolated.

Translation contributions

Localization contributors should follow:

Contributors

The following people have contributed code, tests, accessibility feedback, or documentation to QUILL. Thank you.

Release process

Releases are cut from main. Hotfixes may use short-lived release/x.y.z branches when needed.

Before tagging a release:

  1. ruff check .
  2. pytest -q
  3. python scripts/check_docs_artifacts.py
  4. Windows packaging workflow readiness (.github/workflows/windows-release.yml)

Release notes are prepared in rel.md at the repo root and converted to rel.html and rel.epub by Pandoc. CHANGELOG.md carries the same content in abbreviated form. All three files should be updated and committed before tagging.

Versioning follows semantic intent for user-visible behavior:

main is branch-protected with required checks and pull-request reviews. Admin bypass remains enabled for emergency direct commits; these must be followed by a post-merge explanation and follow-up remediation if needed.

License

By contributing, you agree that your contributions are licensed under the repository's MIT license.