Skip to content
J.A.R.V.I.S.

Contributing

Contributors are welcome.

JARVIS is still moving fast, and high-quality contributions are useful across the whole project: docs, bug fixes, workflows, sidecars, integrations, product polish, tests, and design.

Good Ways to Contribute

Section titled “Good Ways to Contribute”
  • Improve documentation
  • Reproduce and isolate bugs
  • Fix small focused issues
  • Add tests around existing behavior
  • Improve onboarding and setup clarity
  • Improve sidecar UX and observability
  • Suggest roadmap items or product direction

Where to Start

Section titled “Where to Start”

If you are new, the easiest places to start are:

  1. Docs fixes
  2. Small reproducible bug fixes
  3. UI polish with clear before/after behavior
  4. Developer experience improvements

Before You Open a PR

Section titled “Before You Open a PR”

Try to make sure:

  • the change is scoped tightly
  • the problem statement is clear
  • the behavior is easy to review
  • the docs are updated when user-facing behavior changes

How to Contribute

Section titled “How to Contribute”

1. Discuss the idea

Section titled “1. Discuss the idea”

Use one of these:

2. Fork and branch

Section titled “2. Fork and branch”

Create a focused branch from the current default branch.

3. Make the change

Section titled “3. Make the change”

Keep the change narrow and intentional. Smaller PRs are much easier to review and merge.

4. Run the relevant checks

Section titled “4. Run the relevant checks”

At minimum, run the checks that prove your change did not break the area you touched.

5. Open the PR

Section titled “5. Open the PR”

A good PR should explain:

  • what changed
  • why it changed
  • user impact
  • validation performed

Docs Contributions

Section titled “Docs Contributions”

Docs contributions are especially welcome.

Good docs changes usually:

  • remove ambiguity
  • reduce setup confusion
  • explain real deployment mistakes
  • align the docs with the shipped product

If you notice something that is technically true but hard for users to understand, that is still a good docs problem to fix.

What Maintainers Usually Need

Section titled “What Maintainers Usually Need”

The most useful reports and PRs usually include:

  • exact error text
  • screenshots when relevant
  • current environment
  • whether Docker is involved
  • whether a reverse proxy is involved
  • what machine the daemon runs on
  • what machine sidecars or providers run on

Roadmap and Feature Ideas

Section titled “Roadmap and Feature Ideas”

If you want to suggest future product direction, also check:

Video Tutorial Placeholder

Section titled “Video Tutorial Placeholder”

Video tutorial placeholder: how to contribute to JARVIS and open a clean PR.

Add your future video link here.