Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
58 lines (35 loc) · 3.08 KB

CONTRIBUTING.md

File metadata and controls

58 lines (35 loc) · 3.08 KB
Raw

Contributing

Thanks for your interest in making APIWeave better. This page covers how to report issues, request features, submit changes, and where to send security reports.

Filing Issues

File bug reports on GitHub Issues. Search the existing list first; a duplicate with extra context beats a "+1" comment.

A good bug report includes:

  • Steps to reproduce, in order
  • What you expected to happen
  • What actually happened (error text, screenshots, the renderer DevTools console output)
  • Your environment: OS, Node version, desktop app version
  • Whether the issue is consistent or intermittent

For desktop-side bugs, also include the contents of the main process log (the terminal that launched Electron, or your OS console). For renderer-side bugs, the DevTools console and the Network tab are usually enough.

Security Issues

Do not file security vulnerabilities on GitHub Issues. Public disclosure gives attackers a head start before a fix lands.

Report privately through GitHub Security Advisories for this repository. Include the vulnerability, its impact, and a proof of concept or reproduction steps. We aim to acknowledge reports within two business days and will coordinate disclosure timing with you.

Feature Requests

Open a GitHub Issue with the enhancement label. Describe the problem you are trying to solve rather than the specific solution you have in mind. A clear problem statement often surfaces a better fix, and helps others see whether they share the need.

Pull Requests

Open a pull request against the main branch. For development setup, scripts, lint, test, and build commands, see apiweave-context.md and AGENTS.md at the repo root. Those files are the single source of truth for the development workflow and are updated as the project evolves; this page does not duplicate them.

Before opening a PR:

  • One focused change per PR. Stack larger work as a series of smaller PRs.
  • Match the existing code style. Lint and typecheck must pass cleanly.
  • Add or update tests for the change.
  • Update docs under docs/ when user-facing behavior changes.

The PR description should explain the why. The diff already shows the what.

Publishing A Release

  1. Update the version in both app/package.json and app/package-lock.json, then merge the release commit into main.
  2. Tag that commit with a semantic version such as v0.7.8 and push the tag.
  3. The desktop release workflow verifies that the tag is on main and matches the package version before building and publishing the GitHub release.

The workflow publishes Windows x64, macOS Intel and Apple Silicon, and Linux x64 installers. Linux includes AppImage, Debian, RPM, and Pacman formats. Release notes are generated from merged changes and every release includes SHA-256 checksums.

Code of Conduct

Participation is governed by the Contributor Covenant. Read the full text at contributor-covenant.org. Report conduct violations to the maintainers privately.

Related